- CommaAI menjalankan seluruh pelatihan model dan pemrosesan data di pusat data miliknya sendiri, dan saat ini mengoperasikan infrastruktur senilai sekitar 5 juta dolar secara langsung
- Ketergantungan pada cloud dapat berujung pada kenaikan biaya dan hilangnya kendali, sementara mengoperasikan komputasi sendiri memungkinkan peningkatan kualitas engineering dan penghematan biaya
- Pusat data ini terdiri dari sekitar daya 450kW, 600 GPU, penyimpanan SSD 4PB, serta struktur pendinginan dan jaringan yang sederhana
- Stack perangkat lunaknya dirancang dengan Ubuntu + Salt, penyimpanan minikeyvalue (mkv), scheduler Slurm, pelatihan terdistribusi PyTorch, dan komputasi terdistribusi miniray
- Dengan struktur ini, comma.ai mengotomatiskan sepenuhnya pelatihan model kendaraan otonom dan mencapai penghematan biaya sekitar 5x dibanding cloud
Alasan Mengoperasikan Pusat Data Sendiri
- Ketergantungan pada cloud menimbulkan kenaikan biaya dan vendor lock-in
- Perusahaan cloud dirancang agar onboarding mudah, tetapi offboarding sulit
- Dalam penggunaan jangka panjang, mudah terjebak dalam struktur biaya yang tinggi
- Mengoperasikan komputasi sendiri mendorong kemandirian teknis dan budaya engineering yang efisien
- Cloud menuntut pengelolaan yang berpusat pada API dan sistem pembayaran, sedangkan pusat data menuntut penyelesaian masalah teknis nyata yang berfokus pada daya, komputasi, dan bandwidth
- Dari sisi ML engineering, keterbatasan sumber daya mendorong optimasi kode dan perbaikan mendasar
- Di cloud, masalah sering diselesaikan dengan sekadar menambah anggaran, tetapi pada infrastruktur sendiri peningkatan performa menjadi keharusan
- Dari sisi biaya, comma.ai menginvestasikan sekitar 5 juta dolar, dan memperkirakan bahwa pekerjaan yang sama di cloud akan membutuhkan lebih dari 25 juta dolar
Komponen Pusat Data
-
Daya
- Penggunaan maksimum 450kW, biaya listrik tahun 2025 sebesar 540.112 dolar
- Tarif listrik di San Diego mencapai 40 sen/kWh, sekitar 3x rata-rata global
- Disebutkan pula rencana produksi listrik sendiri di masa depan
-
Pendinginan
- Menggunakan pendinginan udara luar, lebih efisien daya dibanding sistem CRAC
- Sirkulasi udara dilakukan dengan masing-masing 2 buah kipas intake dan exhaust 48 inci
- Loop kontrol PID mengatur suhu dan kelembapan secara otomatis (dipertahankan di bawah 45%)
- Konsumsi dayanya berada pada kisaran puluhan kW
-
Server dan penyimpanan
- Terdiri dari 75 unit TinyBox Pro (total 600 GPU), dibuat sendiri
- Setiap perangkat memiliki 2 CPU + 8 GPU, digunakan untuk pelatihan dan komputasi umum
- Produksi internal memudahkan pemeliharaan
- Penyimpanan berbasis Dell R630/R730, total 4PB SSD
- Struktur non-redundant, dengan kecepatan baca 20Gbps per node
- Jaringannya terdiri dari 3 switch Z9264F 100Gbps dan 2 switch Infiniband
Infrastruktur Perangkat Lunak
-
Konfigurasi dasar
- Semua server menggunakan Ubuntu + boot PXE, dikelola dengan Salt
- Struktur single master mempertahankan uptime 99%
-
Penyimpanan terdistribusi — minikeyvalue (mkv)
- Data berkendara untuk pelatihan disimpan di penyimpanan non-redundant 3PB
- Kecepatan baca 1TB/s, sehingga pelatihan langsung tanpa caching dimungkinkan
- Array cache 300TB dan array penyimpanan redundan menyimpan model serta metrik
- Setiap array dikelola oleh server master tunggal
-
Manajemen pekerjaan — Slurm
- Menjadwalkan pekerjaan pelatihan PyTorch dan pekerjaan terdistribusi miniray
-
Pelatihan terdistribusi — PyTorch + FSDP
- Mengoperasikan dua partisi pelatihan yang terhubung melalui jaringan Infiniband
- Framework pelatihan internal mengotomatiskan training loop
- Menyediakan layanan pelacakan eksperimen model
-
Komputasi terdistribusi — miniray
- Scheduler tugas open source yang ringan untuk menjalankan kode Python di mesin yang sedang idle
- Lebih sederhana daripada Dask, dengan server pusat Redis untuk mengelola tugas
- Worker GPU menjalankan inferensi model melalui Triton Inference Server
- Dapat diskalakan paralel ke ratusan mesin
- Contoh: rekor Controls Challenge dicapai dengan penggunaan pusat data selama 1 jam
-
Manajemen kode — monorepo berbasis NFS
- Seluruh codebase berukuran di bawah 3GB dan direplikasi ke semua workstation
- Saat pekerjaan dimulai, kode lokal dan paket disinkronkan, selesai dalam 2 detik
- Menjamin semua pekerjaan terdistribusi berjalan pada kode dan environment yang sama
Pipeline Pelatihan Terintegrasi
- Pekerjaan paling kompleks di comma adalah melatih model berkendara dengan pendekatan on-policy
- Untuk pelatihan seperti ini, perlu menjalankan simulasi berkendara dengan bobot model terbaru untuk menghasilkan data pelatihan
- Seluruh pipeline dapat dijalankan dengan satu perintah berikut
./training/train.sh N=4 partition=tbox2 trainer=mlsimdriving dataset=/home/batman/xx/datasets/lists/train_500k_20250717.txt vision_model=8d4e28c7-7078-4caf-ac7d-d0e41255c3d4/500 data.shuffle_size=125k optim.scheduler=COSINE bs=4
- Untuk menjalankan pelatihan tersebut, seluruh infrastruktur yang dijelaskan di atas digunakan
- Hanya satu perintah sederhana, tetapi berperan mengoordinasikan banyak komponen
Kesimpulan
- comma.ai mencapai penghematan biaya dan kemandirian teknis dengan mengoperasikan pusat data sendiri
- Dengan pendekatan yang sama, perusahaan maupun individu juga dapat membangun infrastruktur sendiri
3 komentar
Memori mahal, katanya!
wwwwwwwwwwwwwwww
Komentar Hacker News
Di industri tempat kami berada, kepemilikan vs cloud berada di dua ujung spektrum
① cloud punya beban investasi awal (capex) dan kebutuhan tenaga kerja yang rendah, tetapi biaya operasional (opex) besar dan volatil
② Managed Private Cloud adalah pekerjaan kami, dikelola berbasis open source dan sekitar 50% lebih murah daripada AWS
③ Rented Bare Metal adalah model yang menangani pembiayaan hardware, dan 90% lebih murah daripada AWS
④ membeli langsung lalu colocate adalah yang paling murah jika Anda punya kemampuan teknis dan skala
Perusahaan seperti Hetzner beroperasi dengan ROI 3 tahun sebagai patokan, dan opsi 3~4 cocok untuk perusahaan berskala besar atau yang menjadikan infrastruktur sebagai inti
Untuk startup, opsi 1 realistis; untuk UKM, opsi 2 lebih realistis (lithus.eu)
Masalahnya, struktur biaya cloud bukan semata karena harga hardware, melainkan karena orang didorong ke arsitektur yang kompleks sehingga inefisiensi membesar
Layanan ‘managed service’ AWS punya struktur di mana makin efisien pengguna menjalankan server, makin kecil pendapatan AWS
Jika hanya menaruh 4 server Java dan DB replikasi di atas EC2, hasilnya jauh lebih efisien
Pada akhirnya, tagihan AWS yang tidak masuk akal muncul saat terlalu banyak layanan disalahgunakan
(derek@ dari Carolina Cloud) Kami juga lebih suka model (4), tetapi pengguna yang kurang punya kemampuan teknis akan bertahan di model 1~3 dan terjebak dalam struktur biaya tinggi public cloud
Katanya ‘berbasis pemakaian’, tetapi kenyataannya ada biaya dasar dan minimum usage fee sehingga jauh lebih mahal (carolinacloud.io)
Hetzner adalah opsi yang menarik
Harus mengelola sendiri layanan seperti Postgres atau VPN memang terasa berat, tetapi di atas 10~15 ribu dolar per bulan, ia lebih menguntungkan daripada AWS
Ada risiko, tetapi layak diambil
Saya menyewa server bare metal seharga 500 dolar per bulan, dan waktu pengelolaannya hanya beberapa jam per tahun
Mungkin karena kebutuhan saya sederhana, tetapi rasanya jauh lebih baik daripada cloud yang terlalu kompleks
Saya pindah ke colocasi sejak 2 tahun lalu, dan sekarang mendapat kapasitas lebih besar dengan 30% biaya
Ada juga manfaat dari turunnya harga RAM/storage dari waktu ke waktu
Hanya saja, pengelolaan compliance memang perlu sedikit lebih diperhatikan
Dulu orang hanya menyebut ini sebagai data center
Ini adalah konsep yang sudah ada sebelum cloud, dan pada akhirnya hanya pengulangan antara memiliki vs menyewa, sentralisasi vs desentralisasi
Saat perusahaan memilih terlalu ekstrem ke salah satu sisi, mereka akan kembali menghadapi masalah yang sama
Yang menarik, alasan cloud dulu menarik bagi tim keuangan adalah efek penghematan pajak
Namun, dengan regulasi terbaru (OBB) yang memungkinkan CapEx dibukukan sebagai biaya, kini ada angin kembali ke on-prem
Kalau begitu, mengapa alternatif cloud yang kompetitif dari sisi harga tidak muncul?
AWS dan Azure menguasai pasar sehingga tidak punya insentif untuk menurunkan harga, sementara Google punya risiko penghentian layanan yang besar
Sebelum cloud, tim infrastruktur internal adalah bottleneck
Cloud menstandarkan hal ini dan menyederhanakannya lewat sistem billing tunggal
Selain itu, di luar AS pengadaan server lebih lambat, jadi keunggulan kecepatan cloud jauh lebih besar
Data center on-prem punya beban operasional yang besar dan menyedot banyak resource engineering
Karena itu perdebatan ini terus berulang
Inovasi sejati cloud adalah “membuat biaya per layanan menjadi jelas”
Alih-alih “saya harus minta tolong ke siapa?”, kini semuanya bisa diakses lewat API
Konteks terkait dirangkum dengan baik di tulisan ini
Bahkan di daerah seperti San Diego yang mudah dikendalikan suhunya, pendinginan dengan udara luar tetap berisiko
Kelembapan dan polutan bisa merusak server dengan cepat
Sebaliknya, pendekatan seperti enthalpy wheel cooler (kyotocooling) efisien dan butuh daya lebih kecil dibanding efisiensi pendinginannya
Pendinginan udara luar punya risiko besar memperpendek umur perangkat, jadi perlu hati-hati
Ada juga kasus yang mendapatkan hasil cukup baik dengan filtrasi dan menjaga kelembapan di bawah 45%
Saya tidak tahu sebelumnya bahwa hal seperti ini perlu diperhatikan
Jadi saya pakai cloud saja — bisa menghindari risiko ‘yang tidak kita tahu’ seperti ini
Menjalankan on-prem dan cloud secara paralel adalah pendekatan yang realistis
Infrastruktur inti dipercayakan ke cloud yang andal, sementara hal seperti pekerjaan Slurm dijalankan di server sendiri
Colocation juga masih merupakan opsi yang valid, dan HPC untuk riset juga layak dipertimbangkan
Di Norwegia, perusahaan swasta juga bisa memakai HPC riset dengan berbayar
Saya pernah mengoperasikan server farm di dua lokasi di Italia, dikelola 5 staf dan mempertahankan uptime hampir 100%
Dengan 800 ribu euro per tahun, kami menghemat biaya cloud sebesar 7~8 juta euro
Banyak developer salah mengira bahwa mereka tidak bisa melakukan hosting sendiri
Kenyataannya jauh lebih mudah daripada yang dibayangkan, dan menyenangkan juga menyelesaikan masalah teknisnya
Jika menyewa ruang di tempat seperti Equinix atau Global Switch, listrik, pendinginan, kabel, dan lain-lain semuanya dikelola untuk Anda
Bahkan memiliki dua server room sendiri di dua lokasi juga sangat mungkin dilakukan
Kami masih memakai Azure untuk layanan pengguna
Untuk layanan web yang tidak butuh GPU, cloud lebih efisien
GitHub juga masih dipakai sebagai layanan yang dapat diandalkan
(bercanda) Pernah ada daemon Postgres kusut di pool Slurm sampai Rust mengamuk
Akhirnya stabil juga, tetapi dari sudut pandang engineer hardware, dunia software memang kacau
Di awal proyek, mulai di AWS dengan 250 dolar per bulan, lalu saat mencapai 30 ribu dolar per bulan pindah ke colocasi
Intinya adalah kemampuan menghitung biaya — engineer yang baik harus bisa mengusulkannya ke manajemen dengan dasar itu
Bukan sekadar hitung-hitungan sederhana, Anda juga harus mempertimbangkan talenta seperti apa yang ingin ditarik dan bisnis seperti apa yang ingin dibangun
Jika perusahaannya melatih model ML, infrastruktur sendiri mungkin lebih cocok
Namun di sebagian besar perusahaan, engineer tidak bisa ikut terlibat dalam pemilihan platform
Dalam 99.999999% kasus, manajemen sudah memutuskan lebih dulu lalu hanya memberi tahu
Di awal karier saya, cloud adalah pilihan yang jelas, tetapi sekarang on-prem kembali tren
Mungkin 10 tahun lagi arusnya akan berbalik lagi
Dari pengalaman saya, tim yang mendorong on-prem selalu meremehkan kelelahan pemeliharaan
Di tempat seperti startup yang butuh pengembangan cepat, itu justru jadi penghambat
Sebaliknya, di perusahaan yang sudah masuk mode maintenance, on-prem efisien
Makin bertambah usia, “selesai cepat dan sesuai anggaran” terasa makin penting, dan daya tarik mengelola infrastruktur sendiri pun berkurang
Arus kali ini bukan sekadar siklus teknologi, melainkan reaksi terhadap ‘masyarakat yang tak bisa memiliki apa pun’
Ketika musik, rumah, sampai mobil semuanya berubah menjadi model langganan, perusahaan juga bergerak untuk merebut kembali kedaulatan komputasi
Siklus seperti ini selalu ada
Mainframe → PC → server room → cloud → edge computing adalah pengulangan sentralisasi ↔ desentralisasi
Pada akhirnya, ketika teknologi dan prioritas berubah, semuanya kembali lagi
Begitu ungkapan “network is the computer” muncul lagi, berarti satu putaran sudah terulang
(bercanda) Berikutnya mungkin tahap space (Skynet)
Alasan kebanyakan perusahaan menghindari on-prem adalah karena manajemen risiko
Perusahaan yang baik memusatkan risiko pada kompetensi inti mereka
Penilaiannya seharusnya bukan sekadar biaya, tetapi biaya yang telah disesuaikan dengan risiko
Namun belakangan ini saya juga ragu apakah perusahaan-perusahaan benar-benar punya kemampuan untuk menilai risiko itu secara akurat
Karena daya saing harga pada akhirnya juga merupakan salah satu faktor pembeda
Intinya adalah fokus pada bisnis utama
Jika itu tidak membantu menjual produk yang tadinya tidak laku menjadi lebih laku, jangan buang waktu di data center
Pengecualiannya hanya kasus seperti Google, ketika infrastrukturnya sendiri adalah daya saing produk
Pada akhirnya, kebanyakan ini adalah pertarungan Opex mengalahkan Capex
Keunggulan sejati on-prem adalah kebebasan, kontrol, dan privasi
Ini bukan sekadar soal uang, melainkan seperti pertanyaan apakah Anda memiliki rumah atau menyewanya
Doktrin ala MBA pada 2010-an adalah “pindahkan semuanya ke cloud”
Memindahkan risiko dan biaya ke pihak ketiga dianggap sebagai jawaban yang benar
Tetapi kenyataannya, data center kami jauh lebih murah, dan laju kenaikan biaya langganan software jauh lebih tinggi daripada hardware
Tetapi jika biaya tenaga kerja dan operasional ikut diperhitungkan, perbandingan biaya sederhana menjadi tidak berarti
Satu tornado saja bisa menghancurkan perusahaan, jadi pada akhirnya keputusan harus dinilai berdasarkan nilai dibanding risikonya