Membangun klaster penyimpanan untuk pretraining dengan hard drive 30 petabyte

• Untuk pretraining model guna memecahkan masalah penggunaan komputer, dilakukan pembangunan langsung klaster penyimpanan di pusat kota San Francisco dengan target menyimpan data video sebanyak 90 juta jam
• Memilih pendekatan on-premises, sehingga infrastruktur penyimpanan 30PB dapat dioperasikan dengan biaya tahunan $354k (5 miliar won). Dibandingkan AWS yang memerlukan $12m (17 miliar won), ini menghemat biaya sekitar 34 kali
• Berbeda dari kebanyakan cloud publik, sistem ini tidak memprioritaskan ketersediaan tinggi dan integritas; sesuai karakteristik data pelatihan, diterapkan strategi menoleransi kehilangan data
• Dioperasikan dengan perangkat lunak sederhana berbasis Rust dan Nginx, dan alih-alih memakai sistem kompleks seperti Ceph atau MinIO, pengelolaan dilakukan dengan program buatan sendiri sepanjang 200 baris
• Dalam proses proyek, tim mengalami berbagai trial and error serta memperoleh know-how praktis terkait penataan fisik, konfigurasi jaringan, dan manajemen kabel

---

Pendahuluan dan latar belakang

• Pretraining model untuk penggunaan komputer memerlukan data video dalam skala besar
• LLM teks umum (misalnya LLaMa-405B) cukup dengan sekitar 60TB data, tetapi pelatihan berbasis video membutuhkan 500 kali lebih banyak ruang penyimpanan
• Jika menggunakan cloud publik seperti AWS, biayanya mencapai 12 juta dolar per tahun, tetapi dengan menyewa pusat kolokasi dan membangunnya sendiri, biaya itu bisa ditekan drastis menjadi sekitar 354 ribu dolar
• Dengan menyimpan data skala besar secara mandiri, masalah bahwa biaya data adalah kendala terbesar dapat diatasi

Mengapa membangunnya sendiri

• Cloud berfokus pada keandalan tinggi, redundansi, dan integritas data, tetapi data untuk pretraining tidak terlalu kritis hingga bahkan kehilangan 5% masih bisa ditoleransi
• Berkat karakteristik ini, dapat dipilih persyaratan keandalan yang jauh lebih longgar dibanding perusahaan biasa (2 nines alih-alih 13 nines)
• Harga penyimpanan ditetapkan jauh lebih tinggi daripada biaya dasar sebenarnya
• Karena data adalah komponen biaya terbesar, dan biayanya cukup dapat diprediksi, pembangunan pusat data lokal dinilai lebih menguntungkan

Perbandingan biaya: cloud vs membangun sendiri

• Biaya berulang bulanan: internet $7,500 + listrik $10,000 = total $17,500
• Biaya satu kali: hard drive $300,000, chassis $35,000, node CPU $6,000, biaya instalasi $38,500, tenaga kerja $27,000, jaringan dan biaya instalasi lain $20,000 → total $426,500
• Dengan memasukkan depresiasi (3 tahun), biaya tetap bulanan dihitung $29,500
• AWS $1,130,000 per bulan, Cloudflare R2 $270,000 per bulan, membangun sendiri $29,500 per bulan
  • AWS: sekitar $38 per TB/bulan
  • Cloudflare: sekitar $10 per TB/bulan
  • Membangun sendiri: $1 per TB/bulan
• Dalam pelatihan model skala besar, bahkan Cloudflare mengalami masalah rate-limit akibat beban berat pada sistem internal, sedangkan pada lingkungan yang dibangun sendiri masalah itu diatasi dengan jalur khusus 100Gbps

Pembangunan dan proses

• Untuk pembangunan cepat, direncanakan Storage Stacking Saturday(S3), dengan bantuan kenalan sekitar dan kontraktor profesional
• Dalam 36 jam, sebanyak 2.400 hard drive dipasang ke rak, menyelesaikan perangkat keras 30PB
• Perangkat lunaknya adalah Rust (menangani penulisan, 200 baris) + nginx (menangani pembacaan) + SQLite (pelacakan metadata)
  • Ceph, MinIO, Weka, Vast, dan lain-lain tidak digunakan karena masalah kompleksitas/biaya (terlalu rumit, tidak diperlukan, beban pemeliharaan, dan sebagainya)
  • Semua drive diformat dengan XFS

Umpan balik proyek dan pelajaran

Hal yang berjalan baik

• Trade-off redundansi/kinerja diterapkan dengan tepat sehingga jaringan 100G dapat dimanfaatkan hampir penuh
• Karena dibangun di lokasi yang dekat secara fisik, debugging dan pemeliharaan menjadi mudah
• Vendor dicari lewat eBay, tetapi pembelian aktual dilakukan langsung dengan pemasok individual, dengan penekanan pada pentingnya garansi
• Jalur internet 100G memberi banyak keuntungan, dan masalah jaringan juga lebih mudah di-debug sendiri
• Manajemen kabel berkualitas tinggi sangat membantu pemecahan masalah di kemudian hari
• Prinsip penyederhanaan diterapkan alih-alih memakai sistem penyimpanan open-source yang kompleks, sehingga beban pemeliharaan diminimalkan
• Estimasi biaya waktu/tenaga kerja juga akurat, dan efek penghematannya terkonfirmasi jelas

Hal yang sulit dan trial and error

• Penggunaan front loader membuat pemasangan satu per satu dari 2.400 HDD menjadi merepotkan
• Kepadatan penyimpanan kurang, dan jika sejak desain awal dipilih kepadatan lebih tinggi, biaya tenaga kerja bisa ditekan
• Daisy chain menimbulkan bottleneck kecepatan; idealnya setiap chassis dihubungkan ke HBA terpisah
• Untuk komponen jaringan, kompatibilitas merek penting, terutama pada transceiver optik
• Eksperimen/konfigurasi jaringan memakan waktu; alih-alih DHCP/NAT, konfigurasi difokuskan pada performa dan kemudahan (hanya syarat minimum firewall/secure_link yang diterapkan)
• Pentingnya akses fisik serta pengkabelan monitor/keyboard saat setup sangat terasa

Ide yang layak dicoba

• Memanfaatkan KVM dan IPMI untuk meningkatkan efisiensi pengelolaan jarak jauh
• Disarankan membangun jaringan Ethernet terpisah untuk administrasi
• Overprovisioning jaringan (misalnya mempertimbangkan jaringan internal 400G)
• Dengan server berkepadatan lebih tinggi (misalnya Supermicro 90-drive/20TB HDD)
  lebih menguntungkan untuk pengurangan jumlah rak, penghematan daya, efek konsolidasi CPU, dan sebagainya

Bagaimana membangunnya sendiri

Konfigurasi penyimpanan

• 10 node head CPU (misalnya Intel RR2000, direkomendasikan dual Intel Gold 6148/128GB ECC DDR4 RAM per server)
  • Untuk fitur dengan beban CPU tinggi (seperti ZFS), bisa memilih perangkat yang lebih bertenaga
• 100 chassis DS4246 (masing-masing memuat 24 HDD)
• 2.400 HDD 3.5" (jika memungkinkan disarankan drive SAS, karena keunggulan kecepatan)
  • Kombinasi berbagai kapasitas (12TB, 14TB, dan sebagainya); kapasitas besar lebih menguntungkan untuk penempatan dan nilai jual bekas
• Rel/braket untuk pemasangan fisik, pengkabelan perangkat, dan kabel
• Beberapa crash cart untuk debugging masalah jaringan (monitor + keyboard)

Infrastruktur jaringan

• Switch 100GbE (misalnya Arista bekas, port QSFP28)
• HBA per server (rekomendasi: Broadcom 9305-16E, dan sebagainya), termasuk metode koneksi port HBA/chassis
• Kartu jaringan (misalnya Mellanox ConnectX-4, harus mode Ethernet)
• Kabel DAC/AOC—jika mempertimbangkan jarak antarrak, DAC punya keunggulan kompatibilitas
• Saat membeli node head CPU, disarankan memakai pemasok yang sudah memasang HBA/NIC sebelumnya
• Kabel serial, jaringan Ethernet manajemen terpisah (alternatif adaptor nirkabel cadangan + mini switch)

Persyaratan pusat data

• Daya konsumsi 3.5kW per kabinet, dengan asumsi konfigurasi 4U×10 + 2U×1 pada standar 42U
• 3PB per kabinet, serta 1 kabinet 42U cadangan untuk switch atau pengganti chassis 1U
• Cross-connect khusus 100G (umumnya sepasang optik QSFP28 LR4), dan perlu memastikan lebih dulu kompatibilitas form factor serta merek
• Lokasi dekat kantor (kolokasi) direkomendasikan karena memungkinkan respons fisik cepat saat masalah muncul, sehingga produktivitas debugging dan operasi optimal

Tips pengaturan awal

• Setelah konfigurasi konsol lokal awal switch, verifikasi lebih dulu pengaturan port uplink 100GbE dan kompatibilitas transceiver optik
  • Jika perlu, hubungkan langsung fiber ISP ke NIC untuk memastikan link-up, lalu pindahkan ke switch
• Saat instalasi Ubuntu, lebih mudah menyelesaikan pengaturan jaringan node dengan Netplan
• Setelah node terhubung ke internet, lanjutkan dengan urutan koneksi 1 kabel per DS4246 → format/mount → pemeriksaan status untuk mendeteksi lebih awal masalah pengkabelan atau disk rusak

Catatan performa, stabilitas, dan keamanan

• Dengan asumsi keamanan bahwa sistem ini khusus untuk data pelatihan, operasional disederhanakan dengan IP publik langsung + firewall port + nginx secure_link
  • Jika menangani data pelanggan, konfigurasi yang sama tidak cocok, dan DHCP/NAT/firewall tersegmentasi wajib
• Daisy chain memudahkan pengelolaan dan pengkabelan, tetapi menyebabkan bottleneck bandwidth; jika memungkinkan, disarankan HBA khusus per chassis
• Transceiver optik sangat terikat pada merek, jadi bisa mencari dari FS.com dan Amazon secara paralel, tetapi harus memastikan spesifikasi dan merek benar-benar cocok

Kesimpulan dan makna

• Dengan penyimpanan mandiri berbiaya sangat rendah di tingkat $1/TB-bulan, pretraining video 30PB menjadi realistis, dan tercapai penghematan biaya 10–38 kali dibanding cloud
• Arsitektur sederhana dan kemudahan akses di lokasi mengurangi waktu dan risiko, sementara jalur khusus 100G mengatasi bottleneck I/O
• Di era model multimodal dan video skala besar, infrastruktur data berkapasitas besar berbiaya rendah menjadi daya saing inti, dan pendekatan ini memberi referensi praktis yang dapat diwujudkan bahkan oleh tim kecil

Penutup dan ajakan kolaborasi

• Jika Anda membangun klaster penyimpanan serupa dengan merujuk pada tulisan ini, diharapkan berbagi perbaikan dan pengalaman
• Sedang merekrut peneliti AI untuk pretraining model penggunaan komputer skala besar serta riset AI yang terkait generalisasi dan nilai manusia (kontak: [e-mail])

[GN⁺]

Opini Hacker News

• Saat memulai karier dulu, lingkungan on-premises adalah hal yang wajar; hardware yang berumur panjang pada akhirnya jadi diperlakukan dengan penuh perhatian dan tiap server mengakumulasi kondisinya sendiri. Seiring waktu, ketika performa hardware tidak lagi memadai, kita harus memilih hardware baru dari daftar yang ada lewat tim internal dan juga meminta persetujuan biaya tambahan, jadi cukup merepotkan. Proses penggantian hardware, atau memisahkan secara menyeluruh perangkat yang sudah dirawat seperti hewan peliharaan lalu beralih ke perangkat baru, kadang juga menunda proyek. Ketika cloud muncul, saya sempat berpikir, “sekarang wajib pindah ke cloud.” Namun setelah waktu berlalu, diri kita dan organisasi jadi lupa cara mengelola hardware secara langsung, dan pada akhirnya kalau kemampuan itu tidak dihidupkan kembali, cloud yang tadinya pilihan bagus jadi makin kurang menarik. Jadi terima kasih karena sudah membantu menumbuhkan kembali kemampuan seperti ini.

  • Kami ada di situasi yang agak unik. Sejak awal, kami memang tidak mampu menanggung biaya operasional hyperscale cloud, jadi mau tak mau kami mengembangkan kemampuan internal sendiri. Ternyata tidak sesulit yang dibayangkan, dan untuk sementara kami akan terus memakai pendekatan ini. Meski begitu, masalah akumulasi kondisi yang disebut tadi mulai terlihat juga.

  • Dalam ingatan saya, on-premises selalu lebih murah. Ada berbagai hambatan logistik yang hilang, dan kenyamanan dari satu tagihan saja memang ada. Saat cloud sedang sangat dipuja, nasihat yang selalu saya dengar adalah tetap gunakan on-premises, dan pakai cloud hanya saat traffic naik turun secara mendadak. Tapi penggunaan untuk scaling sementara itu makin lama jadi penggunaan permanen, dan para developer jadi bergantung pada kemampuan menyalakan mesin baru secara instan. Sekarang semua orang menganggap cloud sebagai keadaan default. Dalam proses itu, kita kehilangan dasar untuk benar-benar merasakan biaya riil, dan selisih biaya antara cloud dan on-premises makin melebar.

  • Docker adalah alat yang sangat bagus untuk membuat server tidak lagi diperlakukan seperti hewan peliharaan. Server di rak jadi sekadar dianggap sebagai node K3 atau K8 lainnya, sehingga tidak diperlakukan seperti aset yang disayang-sayang. Itu sangat saya sukai. Hal serupa mungkin bisa dikatakan untuk VM, tetapi pada akhirnya VM itu sendiri justru menjadi “peliharaan”. Memang bisa membuat image atau snapshot, tetapi rasanya tetap berbeda dibanding perubahan yang terasa dengan Docker.

  • Pertanyaan bercanda: apakah ingin mencoba tantangan seperti ini sekali lagi?

• Startup yang uangnya cukup banyak sampai bisa santai membeli domain dua huruf .inc berarti punya dana yang berlebihan. Ini seperti menghitung berapa banyak kursi Aeron di kantor startup dulu; bukan sinyal yang bagus.

  • Domain dua huruf .inc yang belum terpakai dijual seharga $2300 per tahun. Itu bahkan tidak sampai 5% dari biaya satu orang developer.

  • Saya ragu nama domain .inc punya nilai nyata.

• Tulisan yang menyenangkan, saya ikut merasa puas saat membacanya. Akan lebih seru lagi kalau ada lebih banyak foto.

  • Kalau para penulis ikut berkomentar, saya penasaran Standard Intelligence PBC itu sebenarnya mengerjakan apa; apakah maksudnya Public Benefit Corporation, atau mereka sedang menjalankan proyek seperti apa.

• Senang karena aspek teknisnya ditulis dengan detail. Saya penasaran bagaimana proses mencari ruang colocation; apakah memakai broker, dan lewat negosiasi harga seberapa jauh harga akhir berbeda dari penawaran awal.

  • Kami meminta penawaran dari sebagian besar penyedia colocation di San Francisco dan Fremont. Tidak ada perbedaan antara harga penawaran dan harga yang benar-benar kami bayar, tetapi syarat dan biaya satu kali sempat kami negosiasikan.

• Postingan blog Discord yang ditautkan juga menarik. Isinya kebanyakan serius, tetapi ada bagian lucu seperti ini: ketika ada gol di Piala Dunia, data itu langsung tercermin di grafik monitoring sehingga anggota tim bisa berdalih bahwa mereka menonton pertandingan sepak bola saat rapat demi “monitoring kerja”. Itu juga dikutip sebagai bukti penggunaan sistem nyata, atau sebagai dasar bahwa Discord menyimpan pesan dengan storage “kurang dari petabyte”. Dugaan saya, jika dihitung dari ukuran dan jumlah node pada tulisan ini, klaster lama sekitar 708TB dan setup baru sekitar 648TB, termasuk ruang untuk pertumbuhan.

• Penyimpanannya sendiri sangat murah. Tapi saya kurang paham bagian setup training dan networking. Dari komentar lain saya dengar GPU-nya tidak berada di satu tempat, jadi berarti data training harus dipertukarkan antar-site hanya lewat 100Gbps. Saya khawatir ini akan menjadi bottleneck dalam proses pretraining.

  • Saat ini kami hanya punya satu link 100G, dan untuk sekarang klaster GPU juga hanya mampu menangani kirim-terima data sebesar itu. Ke depan, sambil memperluas skala, kami akan menambah bandwidth dan storage juga. Sebagai catatan, kami punya beberapa 4090 di colo, dan itu sangat berguna untuk pekerjaan seperti data sharding atau embedding.

• Untuk workload dengan ukuran seperti ini, Anda seharusnya bisa mendapatkan penawaran privat dari AWS atau cloud lain. Dalam kasus S3, bahkan di 0.5PB saja Anda bisa meminta penawaran khusus. Ini bukan berarti total biayanya pasti lebih murah daripada mengelolanya sendiri, tetapi membandingkan harga retail CSP dengan peralatan hasil beli di eBay + tenaga kerja gratis (selain pizza) bukan perbandingan yang sepenuhnya adil.

  • Di AWS atau cloud, biaya egress benar-benar faktor utama. Soal itu, meskipun dicoba dinegosiasikan, mereka sama sekali tidak mau mengalah. Untuk AI training, biayanya sampai di level yang praktis tidak bisa dipakai. Penawaran Cloudflare termasuk yang murah di antara storage bucket objek terkelola, jadi setelah membangun klaster sendiri, selisihnya dengan layanan terkelola memang mengecil. Membangun sendiri juga memberi daya tawar dalam negosiasi. Namun bucket terkelola terlalu overkill untuk sekadar storage pretraining sederhana. Glacier punya value bagus untuk arsip, tetapi belum ada produk yang benar-benar pas untuk kebutuhan ML.

  • Secara konkret, deal seperti apa yang bisa didapat? Apakah diskon lebih dari setengah juga mungkin?

• Menyenangkan bisa ikut memasang drive. Bekerja langsung dengan data sebanyak ini memang pengalaman yang paling seru :P

• Tidak ada pembahasan soal tingkat kegagalan disk. Saya penasaran bagaimana kondisinya setelah beberapa bulan.

  • Ini pengalaman yang pernah saya bagikan dulu: saat memasang beberapa disk array, pernah terjadi kegagalan drive dalam jumlah besar. Hari Jumat sore kami menata rak lalu membiarkannya tanpa disentuh selama akhir pekan sambil menjalankan tes baca/tulis data dengan shell script sederhana. Hari Senin saat kembali, hampir setengah disk sudah mati tanpa meninggalkan log apa pun. Tidak ada cara untuk tahu apakah ada masalah saat proses striping, apakah jebol karena stress test, atau karena batch cacat pabrik. Beberapa pelanggan lain dari perusahaan yang sama juga mengeluh. Pabrikan mengganti semuanya, dan yang tertunda hanya masuk ke produksi. Setelah itu, selama setahun tidak ada kegagalan sama sekali.

  • Dibandingkan 10 tahun lalu, tingkat kegagalan disk sekarang jauh lebih rendah. Dulu saya sampai mengganti lebih dari 10 per minggu, tetapi sekarang itu kejadian yang jarang. Menurut saya cukup lihat statistik hard disk dari Backblaze.

  • Mereka bilang klaster tersebut memakai drive enterprise. Kalau terlalu berhemat di biaya, nanti kerugiannya bisa lebih besar. Saya pribadi pernah memakai drive bekas untuk home server, dan variasi performanya terlalu besar jadi kurang bagus.

  • Poin yang bagus.