Sebuah rak server GPU bukan sekadar kabinet penuh akselerator. Ini adalah batas penerapan tempat topologi GPU, fabric jaringan, penyimpanan, manajemen, daya, pendinginan, dan penjadwalan bekerja bersama—atau menciptakan hambatan yang mahal.
Bagi pengembang AI dan engineer infrastruktur ML, pertanyaan yang berguna bukanlah “Berapa banyak GPU yang muat dalam satu rak?” Melainkan: dapatkah rak ini menyediakan perilaku komunikasi, jalur data, dan pemulihan yang dibutuhkan oleh beban kerja? Panduan ini mengubah pertanyaan tersebut menjadi daftar periksa arsitektur dan rencana penerimaan cloud.
Apa itu rak server GPU?
Rak server GPU adalah rak fisik atau alokasi berskala rak yang dikelola penyedia, yang berisi satu atau beberapa server GPU beserta komponen jaringan, daya, pendinginan, dan manajemen yang diperlukan untuk mengoperasikannya. Dalam penerapan cloud, Anda mungkin tidak mengendalikan kabinetnya sendiri, tetapi Anda tetap harus menanyakan bagian topologi mana yang dijamin: GPU per host, interkoneksi intra-host, fabric host-ke-host, jalur penyimpanan, domain pemeliharaan, dan kebijakan penempatan.
Satu server GPU adalah sebuah node. Rak server GPU adalah sistem di sekitar beberapa node. Klaster GPU dapat mencakup satu atau beberapa rak. Perbedaan tersebut penting karena layanan inferensi dapat dibatasi oleh memori GPU dan jalur PCIe/NVLink satu host, sedangkan pelatihan terdistribusi atau inferensi berskala besar dapat dibatasi oleh jalur jaringan dan penyimpanan antar-host.
Arsitektur referensi BasePOD dari NVIDIA menggambarkan perbedaannya: arsitektur ini memisahkan jaringan komputasi InfiniBand, fabric manajemen-dan-penyimpanan Ethernet, serta jaringan manajemen out-of-band. Desain Anda tidak harus menyalin arsitektur referensi tersebut, tetapi harus menjelaskan jalur yang setara sebelum Anda berkomitmen pada kapasitas. Arsitektur referensi NVIDIA DGX BasePOD
Arsitektur rak server GPU: enam hal yang perlu dipetakan
Mulailah dengan diagram rak yang menunjukkan penempatan fisik dan jalur logis. Jika penyedia tidak dapat mengungkapkan setiap komponen, catat apa yang dijamin dan uji sisanya selama periode penerimaan.
| Lapisan | Apa yang perlu didokumentasikan | Mengapa hal ini mengubah hasil |
|---|---|---|
| Node komputasi | Model GPU, jumlah GPU per host, CPU/RAM, NVMe lokal, domain penggantian | Menentukan kapasitas memori, kapasitas prapemrosesan di sisi host, dan cakupan dampak kegagalan node. |
| Topologi intra-node | Tata letak PCIe, ketersediaan NVLink/NVSwitch, afinitas GPU-ke-NIC | Menentukan apakah GPU dalam satu host dapat bertukar data secara efisien. |
| Fabric antar-node | Jenis jaringan, jumlah dan kecepatan NIC, tingkat switch, kebijakan oversubscription, penempatan dalam rak yang sama | Menentukan perilaku komunikasi kolektif setelah pekerjaan keluar dari satu server. |
| Jalur penyimpanan | Cache lokal, sistem file bersama atau penyimpanan objek, tujuan checkpoint, jalur jaringan | Mencegah pemuatan data dan pembuatan checkpoint mengambil waktu komputasi. |
| Manajemen dan kontrol | Akses BMC/out-of-band, inventaris, scheduler, metrik, kontrol perubahan | Membuat rak tetap dapat dioperasikan saat host atau driver gagal. |
| Lingkungan fasilitas | Alokasi daya rak, redundansi PDU, desain aliran udara atau pendinginan cair, akses layanan | Membatasi kepadatan berkelanjutan dan pemeliharaan—bukan hanya apa yang muat secara mekanis. |
1. Perlakukan topologi sebagai masukan beban kerja
Jumlah GPU adalah deskripsi kapasitas yang tidak lengkap. Untuk satu host, periksa bagaimana GPU terhubung satu sama lain dan ke NIC. Antar-host, identifikasi apakah sebuah pekerjaan akan tetap berada pada satu server, dalam satu rak, atau melintasi rak. Catat aturan penempatan yang diharapkan dalam spesifikasi beban kerja, alih-alih mengasumsikan bahwa “delapan GPU” menggambarkan mesin yang sama di mana pun.
NCCL menggunakan jalur peer-to-peer langsung ketika CUDA melaporkan bahwa GPU terkait dapat mengakses memori satu sama lain. NVIDIA mendokumentasikan nvidia-smi topo -p2p sebagai cara untuk memeriksa status peer-to-peer; gunakan sebagai masukan validasi, bukan sebagai pengganti benchmark beban kerja. Panduan pemecahan masalah GPU NCCL
2. Pisahkan trafik komputasi, data, dan manajemen
Rak server GPU membutuhkan lebih dari sekadar jaringan pelatihan yang cepat. Trafik manajemen, penarikan artefak, telemetri, penyimpanan bersama, dan akses pengguna dapat mengganggu trafik beban kerja ketika berbagi jalur yang kapasitasnya tidak memadai. Gunakan jalur logis atau fisik terpisah jika diperlukan oleh arsitektur Anda, lalu tentukan jalur yang membawa masing-masing hal berikut:
- komunikasi kolektif dan trafik GPU-direct;
- penarikan image, bobot model, set data, dan checkpoint;
- trafik Kubernetes, SSH, BMC, logging, dan pemantauan;
- egress ke API, penyimpanan objek, atau layanan downstream.
Hal ini khususnya penting untuk kapasitas cloud: tanyakan apakah angka bandwidth menggambarkan bandwidth host-ke-host, uplink rak, throughput penyimpanan, atau agregat best-effort. Semua itu tidak dapat dipertukarkan.
3. Rancang daya dan pendinginan sebagai batasan kapasitas
Jangan menentukan ukuran rak server GPU hanya berdasarkan unit rak. Konfigurasi yang muat secara mekanis dapat dibatasi oleh daya fasilitas, redundansi PDU, arah aliran udara, persyaratan pendinginan cair, radius tekuk kabel, atau ruang bebas untuk layanan. NVIDIA mencatat bahwa tata letak rak bervariasi sesuai daya maksimum lokal dan infrastruktur pendinginan; gunakan dokumen terbaru dari vendor server dan penyedia kolokasi Anda untuk alokasi yang sebenarnya. FAQ NVIDIA DGX SuperPOD
Sebelum menerapkan, mintalah jawaban tertulis untuk pertanyaan-pertanyaan berikut:
- Berapa batas daya rak berkelanjutan dan asumsi redundansi apa yang disertakan?
- Apakah desain pendinginannya menggunakan udara, cairan langsung ke chip, pertukaran panas pintu belakang, atau kombinasi?
- Komponen mana yang pertama kali memicu throttling atau peristiwa pemeliharaan: host, PDU, switch jaringan, atau loop fasilitas?
- Dapatkah teknisi melakukan servis pada node, kabel, atau komponen pintu belakang tanpa mengganggu kapasitas di sekitarnya?
Jika penerapannya hanya di cloud, terjemahkan pertanyaan yang sama ke dalam istilah penyedia: penempatan host khusus, domain pemeliharaan, kebijakan penggantian host, dan apakah alokasi dapat mengubah topologi setelah provisi.
4. Berikan kesadaran rak kepada scheduler hanya ketika berguna
Label rak bernilai ketika beban kerja memperhatikan lokalitas atau domain kegagalan. Pekerjaan pelatihan terdistribusi mungkin lebih memilih penempatan dalam satu rak sebelum diperluas ke beberapa rak. Layanan inferensi dengan ketersediaan tinggi dapat dengan sengaja menyebarkan replika ke berbagai rak atau host. Mulailah dengan sekumpulan label kecil yang dapat diaudit, seperti topology.rack, topology.host-class, topology.fabric, dan topology.failure-domain, lalu verifikasi bahwa penempatan scheduler mengikutinya.
Untuk Kubernetes, validasi seluruh tumpukan perangkat lunak GPU terhadap sistem operasi, Kubernetes, driver, runtime, dan opsi penerapan yang didukung—bukan hanya versi cluster. Matriks dukungan GPU Operator NVIDIA membedakan bare metal, VM GPU-passthrough, dan penerapan vGPU, serta memublikasikan detail kompatibilitas untuk lingkungan yang didukung. Dukungan platform NVIDIA GPU Operator
Cara memilih rak server GPU untuk beban kerja Anda
Gunakan ringkasan beban kerja untuk memutuskan apakah Anda memerlukan satu host berdensitas tinggi, satu rak, atau cluster multi-rak.
| Pola beban kerja | Biasanya diprioritaskan | Tanyakan kepada penyedia atau tim platform |
|---|---|---|
| Fine-tuning atau inferensi satu node | Memori GPU, topologi intra-node, penyimpanan lokal, penggantian host yang andal | GPU dan interkoneksi mana yang terpasang pada satu host? Apakah semua GPU yang diperlukan dapat dialokasikan bersama? |
| Pelatihan terdistribusi | Penempatan dalam rak yang sama, fabric jaringan, afinitas NIC, throughput checkpoint | Apa yang dijamin untuk jaringan antahost? Bagaimana penempatan lintas rak diekspos atau dihindari? |
| Inferensi multi-node | Latensi ekor, komunikasi pecahan model, keamanan rollout, observabilitas | Dapatkah replika disebarkan berdasarkan domain kegagalan sementara peringkat paralel-model tetap sadar topologi? |
| Beban kerja batch atau rendering | Perilaku antrean, cache lokal, penanganan interupsi, staging image/data | Apa jaminan penempatannya, dan bagaimana pekerjaan yang terinterupsi dipulihkan? |
| Platform internal bersama | Isolasi, kuota, kebijakan scheduler, visibilitas kapasitas, kontrol perubahan | Bagaimana partisi GPU, batas tenant, driver, dan peningkatan versi dikelola? |
Untuk penerapan baru, bandingkan keputusan rak dengan alternatif yang lebih sederhana. Jika pekerjaan tidak memerlukan kontrol atas topologi, lokalitas data, atau tumpukan serving kustom, API model terkelola mungkin memiliki beban operasional yang lebih rendah. Gunakan perbandingan cloud GPU vs. API model ini sebagai bagian dari keputusan, alih-alih menganggap rak server GPU sebagai jawaban default.
Cara mengevaluasi performa rak server GPU
Jangan menerima rak server GPU hanya berdasarkan angka puncak akselerator. Buat pengujian penerimaan singkat yang memisahkan jalur performa utama.
Langkah 1: Catat inventaris dan baseline topologi
Untuk setiap host yang dialokasikan, kumpulkan identitas GPU, versi driver dan CUDA, topologi GPU-ke-GPU, afinitas GPU-ke-NIC, tata letak CPU NUMA, penyimpanan lokal, dan antarmuka jaringan. Simpan catatan ini bersama revisi penerapan. Catatan tersebut memberi Anda titik perbandingan ketika performa berubah setelah penggantian image, firmware, driver, atau host.
nvidia-smi -L
nvidia-smi topo -m
nvidia-smi topo -p2p p
nvidia-smi topo -p2p n
Jangan mengubah pengaturan kernel, BIOS, IOMMU, atau kontrol akses PCIe berdasarkan daftar periksa umum. NVIDIA mendokumentasikan perilaku peer-to-peer yang sensitif terhadap konfigurasi pada sistem bare metal Linux; gunakan pengaturan yang didukung untuk server dan platform cloud yang benar-benar Anda operasikan. Pemecahan masalah topologi dan peer-to-peer NCCL
Langkah 2: Uji pada batas yang penting
Jalankan pengujian representatif pada tiga cakupan:
- Satu node untuk memvalidasi visibilitas GPU dan jalur NVLink/NVSwitch atau PCIe lokal.
- Rak yang sama untuk memvalidasi penempatan antahost dan fabric lokal.
- Lintas rak untuk memahami jalur yang akan digunakan scheduler Anda ketika kapasitas diperluas atau mengalami failover.
Panduan pengujian NCCL NVIDIA secara eksplisit menggunakan pengujian satu node, satu rak, dan multi-rak untuk memvalidasi visibilitas GPU, interkoneksi intra-node, fabric antar-node, dan penempatan. Catat latensi dan bandwidth beserta perintah pengujian, digest image container, daftar node, dan label penempatan agar hasil dapat direproduksi. Tutorial validasi NCCL
Langkah 3: Ukur jalur aplikasi yang sebenarnya
Kemudian jalankan beban kerja yang ingin Anda layani. Untuk pelatihan, laporkan waktu per langkah, waktu tunggu data, waktu komunikasi kolektif, waktu checkpoint, dan perilaku pemulihan. Untuk inferensi, laporkan waktu hingga token pertama, throughput output, latensi ekor, penundaan antrean, perilaku cache, serta tingkat kesalahan atau restart. Pertahankan model, profil batch/konkurensi, panjang konteks, dan status cache yang sama saat membandingkan penempatan.
Inilah cara membedakan masalah GPU dari masalah data, jaringan, scheduler, atau konfigurasi.
Langkah 4: Uji kegagalan yang direncanakan
Rak server GPU operasional memerlukan jalur pemulihan. Sebelum trafik produksi, verifikasi apa yang terjadi saat worker dikuras, sebuah node tidak tersedia, pekerjaan dipreempt, atau checkpoint perlu dilanjutkan di tempat lain. Pastikan data persisten terpisah dari komputasi yang dapat diganti serta kredensial, image, dan observabilitas tetap berfungsi pada jalur penggantian.
Terapkan rak server GPU di cloud: urutan praktis
Penerapan cloud mengubah batas kendali, bukan pekerjaan engineering. Anda tetap perlu membuat asumsi hardware dan penempatan terlihat jelas.
- Tulis kontrak beban kerja. Tentukan ukuran model, jumlah GPU, kebutuhan memori, SLO latensi atau throughput, sensitivitas jaringan, sumber data, lokasi checkpoint, target ketersediaan, dan batas anggaran.
- Pilih batas topologi. Tentukan apakah pekerjaan harus tetap berada dalam satu host, satu rak, atau fabric multi-rak yang ditentukan. Perlakukan ini sebagai persyaratan dalam permintaan kepada penyedia, bukan preferensi informal.
- Minta lembar alokasi. Minta kelas host, jumlah GPU, interkoneksi GPU, NIC, fabric jaringan, opsi penyimpanan, jaminan penempatan, kebijakan pemeliharaan, dan metadata topologi apa pun yang diekspos ke scheduler Anda.
- Tetapkan kontrak software. Catat sistem operasi, kernel, driver NVIDIA, CUDA, runtime container, versi Kubernetes, versi GPU Operator, image framework, dan digest image aplikasi. Validasi kombinasi tersebut terhadap matriks yang didukung sebelum peluncuran.
- Buat jendela penerimaan yang sempit. Jalankan pengujian inventaris, topologi, komunikasi node yang sama/rak yang sama/lintas rak, penyimpanan, aplikasi, dan pemulihan sebelum memindahkan trafik berkelanjutan.
- Instrumentasikan setiap lapisan. Buat peringatan terpisah untuk kesehatan GPU, kesalahan fabric, waktu tunggu penyimpanan, waktu tunggu scheduler, peristiwa termal atau throttling, dan SLO aplikasi. Satu metrik utilisasi tidak dapat menjelaskan insiden berskala rak.
- Pertahankan opsi keluar dan pemulihan. Pertahankan definisi image, konfigurasi infrastruktur, lokasi data persisten, checkpoint, dan rencana rollback yang independen dari alokasi tertentu.
Untuk bagian tingkat host dari urutan ini, lihat panduan penerapan server GPU. Untuk perspektif control plane dan fabric multi-node, lihat panduan arsitektur cluster GPU.
Daftar periksa penerimaan rak server GPU
Gunakan daftar periksa ini sebelum Anda menerima rak server GPU baru, alokasi cloud khusus, atau implementasi kolokasi.
- [ ] Kontrak beban kerja menyebutkan batas topologi: satu host, rak yang sama, atau multi-rak.
- [ ] Lembar alokasi mengidentifikasi jumlah GPU per host, interkoneksi akselerator, NIC, fabric jaringan, dan jalur penyimpanan.
- [ ] Daya, pendinginan, redundansi PDU, persyaratan aliran udara atau pendinginan cair, serta ruang akses servis memiliki penanggung jawab.
- [ ] Versi GPU, driver, CUDA, kernel, runtime container, dan orkestrasi dicatat.
- [ ] Scheduler mengekspos dan mematuhi label penempatan atau domain kegagalan saat beban kerja memerlukannya.
- [ ] Output topologi inventaris dan
nvidia-smidisimpan untuk setiap kelas host. - [ ] Pengujian komunikasi mencakup penempatan satu node, rak yang sama, dan lintas rak yang dapat dibuat oleh scheduler produksi.
- [ ] Pengujian aplikasi menggunakan sumber data dan profil beban kerja yang representatif.
- [ ] Jalur checkpoint, pengurasan host, penggantian, dan rollback diuji.
- [ ] Pelaporan biaya memisahkan waktu GPU produktif dari biaya idle, percobaan ulang, data, dan dukungan tanpa menghitung waktu yang sama dua kali. Untuk model biaya yang lebih luas, mulai dengan panduan penyewaan GPU ini.
Pertanyaan yang sering diajukan
Apakah rak server GPU sama dengan cluster GPU?
Tidak. Rak server GPU menggambarkan batas penerapan berskala rak yang fisik atau dikelola penyedia. Cluster GPU adalah kelompok node logis yang dapat mencakup sebagian dari satu rak, satu rak penuh, atau beberapa rak. Perbedaan ini penting ketika jaringan, penyimpanan, domain kegagalan, dan penjadwalan melintasi batas fisik.
Berapa banyak server GPU yang muat dalam rak server GPU?
Tidak ada angka universal yang berguna. Kedalaman server dan unit rak hanyalah batasan pertama. Jawaban praktis bergantung pada konsumsi daya server, desain pendinginan, kapasitas dan redundansi PDU, perutean kabel, akses servis, dan kepadatan yang disetujui fasilitas. Validasi jawabannya terhadap desain host, rak, dan pusat data persis yang akan Anda gunakan.
Apakah setiap rak server GPU memerlukan InfiniBand?
Tidak. Fabric yang sesuai bergantung pada beban kerja dan topologi. Beban kerja satu host mungkin sama sekali tidak memerlukan fabric berperforma tinggi antar-node. Beban kerja terdistribusi harus diuji pada jalur jaringan yang benar-benar akan digunakan, termasuk penempatan dalam rak yang sama dan lintas rak. Hindari memilih fabric hanya berdasarkan spesifikasi pemasaran.
Apa yang harus saya uji sebelum menerima kapasitas rak GPU cloud?
Uji alokasi yang Anda terima: inventaris perangkat keras, topologi, afinitas GPU-ke-NIC, perilaku penyimpanan lokal dan bersama, komunikasi satu node, komunikasi dalam rak yang sama, komunikasi lintas rak jika memungkinkan di produksi, perilaku aplikasi yang representatif, dan pemulihan dari kegagalan yang direncanakan.
Kapan saya harus menghindari pengoperasian rak server GPU?
Hindari operasi berskala rak ketika beban kerja Anda tidak memerlukan kontrol yang disediakannya. Jika API model terkelola dapat memenuhi persyaratan model, latensi, ketersediaan, privasi, dan biaya, API tersebut dapat menghilangkan pekerjaan terkait perangkat keras, fabric, driver, penjadwal, dan manajemen kapasitas. Buat perbandingan tersebut dengan sengaja sebelum berkomitmen pada rak server GPU.
Bangun rak berdasarkan beban kerja
Rak server GPU berhasil ketika desain fisik dan alokasi cloud-nya sesuai dengan jalur komunikasi, data, dan pemulihan dari beban kerja. Buat topologi menjadi eksplisit, pisahkan kelas lalu lintas yang dapat saling mengganggu, validasi performa pada cakupan satu node, dalam rak yang sama, dan lintas rak, serta terima kapasitas hanya setelah aplikasi nyata dan jalur kegagalan telah diuji.
Jika kontrol tingkat rak tidak diperlukan, bandingkan jalur API model sebelum Anda menanggung beban operasionalnya. Jika diperlukan, gunakan panduan ini bersama panduan server GPU, panduan arsitektur klaster GPU, dan daftar periksa biaya cloud GPU untuk mengubah kapasitas menjadi penerapan yang dapat diverifikasi.
