Arsitektur Klaster GPU: Compute, Jaringan, Storage, dan Control Plane

Arsitektur klaster GPU adalah bentuk keseluruhan sistem, bukan sekadar jumlah GPU. Sebuah klaster produksi harus mengoordinasikan node komputasi, jaringan berkecepatan tinggi, storage, scheduler, kontrol akses, telemetry, dan jalur pemulihan sebelum bisa mengubah akselerator yang mahal menjadi training run yang berguna atau inference yang andal.

Pertanyaan praktisnya sederhana: apakah tim Anda bisa memindahkan data, menjadwalkan job, memulihkan kegagalan, dan mengukur biaya cukup cepat untuk menjaga GPU tetap sibuk? Jika tidak, klaster dengan kartu yang lebih bagus masih bisa menghasilkan ekonomi yang lebih buruk daripada layanan GPU terkelola yang lebih kecil atau API model.

Panduan ini memberi tim platform AI model kerja untuk gpu cluster architecture: apa yang termasuk dalam lapisan compute, apa yang harus dibuktikan oleh jaringan, bagaimana storage dan checkpointing diposisikan, bagaimana Kubernetes atau Slurm menjadi control plane, dan apa yang perlu diuji sebelum menyewa atau membeli kapasitas multi-node.

Aturan praktis Flatkey adalah memulai dari batas workload. Jika produk hanya membutuhkan output model, benchmark dulu jalur GPU cloud vs model API. Jika Anda memerlukan bobot kustom, kontrol penempatan, training yang berjalan lama, atau infrastruktur serving privat, maka rancang klaster GPU di sekitar kebutuhan compute, jaringan, storage, dan control plane dari workload tersebut.

Jawaban singkat arsitektur klaster GPU

Klaster GPU yang berguna memiliki empat plane:

multi-node gpu cluster architecture berhasil ketika plane-plane ini dirancang bersama. Compute tanpa fabric adalah kapasitas yang terisolasi. Fabric tanpa storage hanya memindahkan bottleneck. Kubernetes tanpa kuota, telemetry, dan runbook hanyalah mekanisme peluncuran.

Diagram arsitektur klaster GPU

Gunakan diagram ini sebagai kerangka peninjauan sebelum Anda membandingkan provider atau menyetujui desain rack.

                  pengguna / CI / traffic produk / klien API
                                  |
                                  v
        +------------------------------------------------------+
        | control plane                                        |
        | Kubernetes or Slurm scheduler, queues, quotas,       |
        | secrets, registry access, policy, telemetry, billing |
        +------------------------------------------------------+
              |                    |                    |
              v                    v                    v
   +-------------------+   +-------------------+   +-------------------+
   | node compute gpu  |   | node compute gpu  |   | node compute gpu  |
   | GPUs, CPU, RAM,   |   | GPUs, CPU, RAM,   |   | GPUs, CPU, RAM,   |
   | local NVMe, NICs  |   | local NVMe, NICs  |   | local NVMe, NICs  |
   +-------------------+   +-------------------+   +-------------------+
              \                  |                  /
               \                 |                 /
                v                v                v
        +------------------------------------------------------+
        | high-speed fabric                                   |
        | NVLink/NVSwitch inside node; InfiniBand, RoCE, EFA, |
        | or Ethernet across nodes; placement and routing     |
        +------------------------------------------------------+
                                  |
                                  v
        +------------------------------------------------------+
        | storage dan jalur data                              |
        | object store, shared filesystem, local scratch,      |
        | model cache, checkpoints, snapshots, backups        |
        +------------------------------------------------------+

Untuk kubernetes gpu cluster architecture diagram, tambahkan objek-objek spesifik Kubernetes di sekitar control plane:

cluster admins -> node images -> GPU Operator / device plugin -> GPU nodes
app teams      -> namespace -> quota -> job queue -> Pod / Job / RayJob
finance        -> labels -> usage export -> cost per job / team / model
security       -> secrets -> image policy -> network policy -> audit logs

Diagram ini sengaja dibuat sederhana. Tujuannya bukan untuk menggambar setiap service. Tujuannya adalah menangkap tanggung jawab yang hilang sebelum klaster menjadi ketergantungan produksi.

Mulai dari workload, bukan dari rack

Sebelum memilih Kubernetes, Slurm, reservasi cloud, atau vendor bare-metal, tulislah ringkasan workload satu halaman.

Jika Anda tidak bisa mengisi tabel ini, jangan menandatangani kontrak kapasitas jangka panjang dulu. Sewa irisan yang lebih kecil, jalankan benchmark, dan ubah log menjadi brief pengadaan. panduan sewa klaster GPU memberikan checklist sisi pembeli setelah bentuk arsitektur menjadi jelas.

Compute plane: node GPU tidak bisa saling dipertukarkan

Compute plane mendefinisikan apa yang benar-benar dapat digunakan oleh sebuah job. Spesifikasi compute yang lengkap mencakup lebih dari sekadar "8x H100" atau "klaster B200."

Mintalah:

• Model GPU, ukuran memori, dan PCIe versus SXM jika relevan.
• Jumlah GPU per node dan topologi intra-node.
• Model CPU, jumlah CPU, RAM sistem, dan layout NUMA.
• Kapasitas NVMe lokal dan throughput yang diharapkan.
• Jumlah NIC, kecepatan NIC, dan apakah jalur GPU-direct didukung.
• Lifecycle driver, CUDA, container runtime, dan image OS.
• Kebijakan MIG, vGPU, time-slicing, atau alokasi full-GPU.
• Homogenitas node dan kebijakan penggantian.

Topologi intra-node penting karena delapan GPU dalam satu server tidak setara dengan delapan node ber-GPU tunggal. Desain node menentukan tekanan memori, bottleneck CPU, kecepatan staging lokal, dan seberapa mahal komunikasi lintas node menjadi.

Dokumentasi NVIDIA Kubernetes GPU Operator berguna di sini karena menunjukkan bagaimana driver, NVIDIA Container Toolkit, device plugin, telemetry DCGM, dan komponen terkait dapat dikelola sebagai stack klaster, bukan sebagai setup node satuan. Dokumentasi Kubernetes device plugin menjelaskan titik ekstensi umum yang digunakan untuk mengekspos perangkat vendor sebagai resource yang dapat dijadwalkan.

Network plane: buktikan fabric dengan benchmark

Pelatihan multi-node dan serving throughput tinggi bergantung pada jaringan. Spesifikasi klaster harus menyatakan fabric dan tes penerimaan, bukan hanya angka bandwidth.

Mintalah:

• Detail NVLink atau NVSwitch intra-node.
• Desain InfiniBand, RoCE, EFA, atau Ethernet lintas node.
• Jumlah dan kecepatan NIC per node.
• Jaminan placement dan failure domain.
• Rasio oversubscription.
• Dukungan GPUDirect RDMA jika relevan.
• Model jaringan container dan host.
• Observabilitas untuk error fabric, retransmit, kongesti, dan kegagalan node.

Gunakan tes penerimaan sebelum komitmen dimulai:

network acceptance test:
  run NCCL all_reduce across every rented node
  record bandwidth, latency, node IDs, GPU model, driver, CUDA, NCCL version
  repeat after installing the production container image
  save logs and compare them with the provider's quoted topology

NVIDIA NCCL dan NCCL tests adalah referensi standar untuk memvalidasi perilaku collective communication dalam beban kerja GPU terdistribusi. Intinya bukan mengejar satu angka benchmark. Intinya adalah menangkap node yang tidak cocok, placement yang buruk, kongesti fabric, atau drift driver/container sebelum full training run gagal.

Untuk inference, tes jaringan harus mencakup jalur traffic yang sebenarnya: ingress request, komunikasi model shard, perilaku KV-cache jika relevan, fetch storage, dan egress. Fabric training yang tampak kuat secara terpisah masih bisa menghasilkan latensi pengguna yang buruk jika stack serving melintasi terlalu banyak batas jaringan.

Storage plane: jauhkan data, bobot, dan checkpoint dari jalur kritis

Storage adalah tempat banyak rencana arsitektur klaster GPU menjadi mahal. Kutipan GPU terlihat. Jalur data sering tersembunyi sampai production run pertama.

Rancang storage di sekitar empat alur:

Untuk training, throughput checkpoint dan waktu restore adalah isu arsitektur, bukan detail backup. Untuk inference, pemuatan bobot model, pemanasan cache lokal, dan perilaku persistent volume memengaruhi waktu deployment dan waktu failover.

Dokumentasi GPUDirect Storage dari NVIDIA adalah sumber yang berguna ketika arsitektur memerlukan jalur data langsung antara storage lokal atau jarak jauh dan memori GPU. Tidak setiap klaster membutuhkan GPUDirect Storage, tetapi tim yang memindahkan dataset besar atau checkpoint harus secara eksplisit memutuskan apakah stack storage bersifat biasa, dioptimalkan, atau merupakan bottleneck yang mereka terima.

Control plane: Kubernetes, Slurm, atau keduanya?

Control plane mengubah hardware menjadi sebuah platform. Ia menentukan siapa dapat menjalankan apa, kapan job dimulai, bagaimana kegagalan dicoba ulang, dan bagaimana tim memahami penggunaan.

Arsitektur klaster GPU Kubernetes

Kubernetes cocok untuk platform GPU yang membutuhkan deployment layanan, namespace multi-tenant, workflow native-container, otomatisasi berbasis API, policy, dan integrasi dengan observability cloud-native. Arsitektur klaster gpu kubernetes produksi biasanya mencakup:

• Citra node dan otomatisasi bootstrap.
• GPU Operator atau manajemen driver/device plugin khusus vendor.
• Device plugin atau Dynamic Resource Allocation untuk mengekspos GPU.
• Namespace, RBAC, secrets, policy pull image, dan network policy.
• Jobs, Deployments, RayJob, training operators, atau layanan inference.
• Kueue atau lapisan antrean lain ketika keadilan batch penting.
• Kuota per tim, proyek, lingkungan, atau pelanggan.
• DCGM, Prometheus, log, trace, dan label penagihan.
• Kontrol admission untuk image, workload yang privileg, host mount, dan berbagi GPU.

Device plugin Kubernetes mengekspos GPU sebagai extended resources. Dynamic Resource Allocation Kubernetes menambahkan model resource berbasis claim yang lebih kaya untuk perangkat dan resource khusus lainnya. Kueue menambahkan konsep antrean job seperti workloads, queue, cohort, dan resource flavor untuk penjadwalan batch dan AI/ML. Bersama-sama, alat ini dapat mengubah pool GPU menjadi platform yang terkelola, bukan sekadar kumpulan mesin yang dapat diakses via SSH.

Arsitektur klaster GPU Slurm

Slurm cocok untuk banyak lingkungan gaya HPC dan riset karena dibangun di sekitar queue, partition, accounting, reservation, dan batch job. Dokumentasi GRES Slurm mencakup resource GPU dan cara job memintanya.

Slurm sering menjadi pilihan yang kuat ketika:

• Pengguna mengirim job training batch.
• Policy antrean bersifat sentral.
• Tim sudah memiliki pengalaman operasi HPC.
• Workload-nya kurang berorientasi layanan.
• MPI, pengujian NCCL, dan accounting batch adalah primitive operasional yang sudah familiar.

Beberapa organisasi menjalankan keduanya: Slurm untuk riset dan antrean training besar, Kubernetes untuk layanan inference dan API platform. Itu bisa berhasil, tetapi hanya jika identitas, akses data, observability, dan alokasi biaya dirancang lintas kedua sistem.

Observability dan kontrol biaya harus ada dalam desain awal

Jangan menambahkan telemetry setelah klaster berjalan. Pertanyaan yang penting bagi engineering dan finance dapat diprediksi:

• Job mana yang menggunakan GPU yang mana?
• Namespace, tim, pelanggan, model, atau eksperimen mana yang menyebabkan pengeluaran?
• Apa utilisasi yang berguna, bukan hanya waktu GPU yang dialokasikan?
• Berapa banyak waktu yang dihabiskan menunggu di antrean?
• Kegagalan mana yang menghabiskan GPU-hours paling banyak?
• Bottleneck storage atau jaringan mana yang menyebabkan GPU menganggur?
• Berapa biaya per run yang selesai atau output yang diterima?

Telemetry minimum sebaiknya mencakup:

• Utilisasi GPU, utilisasi memori, daya, temperatur, dan event ECC.
• Waktu berjalan per job, waktu antre, jumlah retry, alasan keluar, dan pemilik.
• Kesehatan fabric jaringan dan riwayat benchmark.
• Throughput storage, latensi, waktu checkpoint, dan waktu restore.
• Event alokasi scheduler dan penolakan kuota.
• Label penagihan atau ekspor penggunaan yang terkait dengan unit bisnis.

Baseline model/API Flatkey penting di sini. Jika API model terkelola menghasilkan output yang sama yang diterima dengan biaya unit yang lebih jelas dan beban operasional yang lebih rendah, klaster harus mengungguli baseline itu setelah waktu idle, retry, storage, dan tenaga kerja diperhitungkan.

Keamanan, isolasi, dan desain akses

Klaster GPU sering dimulai sebagai proyek engineering dan menjadi infrastruktur bersama. Perlakukan desain akses sebagai bagian dari arsitektur.

Definisikan:

• Autentikasi dan sumber identitas.
• Isolasi namespace, proyek, atau akun.
• Kebijakan SSH, jika ada.
• Registry image container, penandatanganan, dan pemindaian.
• Manajemen secrets.
• Policy egress jaringan.
• Penghapusan data dan pembersihan setelah job.
• Retensi audit log.
• Akses break-glass.
• Akses dukungan vendor dan alur kerja remote hands.

Untuk klaster multi-tenant, putuskan apakah berbagi GPU diizinkan. Alokasi full-GPU lebih sederhana. MIG, vGPU, atau time-slicing dapat meningkatkan utilisasi, tetapi juga mengubah isolasi, telemetry, penjadwalan, dan ekspektasi performa.

Ukuran klaster: ubah arsitektur menjadi angka

Penentuan ukuran harus didorong oleh unit yang berguna:

required_gpu_capacity =
  target_work_completed_per_month
  / useful_work_per_gpu_month_after_failures_idle_and_retries

Lalu uji tekan itu:

Untuk model biaya, hubungkan artikel ini dengan lembar kerja TCO klaster GPU Anda:

effective_cluster_unit_cost =
  (compute + network + storage + support + operations + idle + retries)
  / accepted workload units

Penyebutnya harus sesuai dengan produk: run pelatihan yang selesai, token inferensi yang diterima, job media yang dihasilkan, pembaruan indeks pencarian, atau permintaan pelanggan.

Daftar periksa tinjauan arsitektur

Gunakan daftar periksa ini sebelum menyetujui diagram arsitektur klaster gpu multi node atau penawaran provider.

Referensi resmi yang perlu tetap dibuka

Gunakan dokumentasi resmi sebagai pemeriksaan sumber selama tinjauan arsitektur:

Anggap ini sebagai referensi arsitektur, bukan pengganti pengujian penerimaan pada klaster persis yang akan Anda jalankan.

Kapan klaster GPU adalah arsitektur yang salah

Jangan membangun atau memesan klaster hanya karena harga per jam GPU terlihat menarik. Klaster GPU langsung bisa menjadi arsitektur yang salah ketika:

• Produk hanya membutuhkan output model.
• Campuran model berubah setiap minggu.
• Tim tidak dapat mengoperasikan driver, scheduler, storage, networking, dan insiden.
• Workload bersifat bursty dan utilisasinya rendah.
• Perpindahan data lebih dominan daripada compute.
• Pengadaan menginginkan komitmen tiga tahun sebelum bukti benchmark tersedia.
• Keuangan tidak dapat memetakan pengeluaran klaster ke output yang diterima.

Dalam kasus tersebut, bandingkan dulu harga sewa GPU cloud, serverless GPU, atau model API. Arsitektur yang tepat adalah yang menghasilkan output yang diterima secara andal dengan total biaya operasional terendah, bukan yang memiliki inventaris akselerator terbesar. Untuk pemindaian pasar di tingkat provider, gunakan perbandingan cloud GPU sebelum Anda meminta penawaran.

Kesimpulan akhir

arsitektur klaster GPU yang kuat adalah desain sistem: node compute yang cocok dengan beban kerja, fabric jaringan yang terbukti oleh benchmark, storage yang tidak membuat GPU kekurangan pasokan, dan control plane yang dapat menjadwalkan, mengamankan, mengamati, serta membebankan penggunaan kembali.

Untuk eksperimen kecil, mulailah dengan sewa atau API terkelola. Untuk pelatihan multi-node yang serius atau inference privat, gunakan diagram dan checklist di atas sebelum berkomitmen pada penyedia, rack, atau reservasi. Kesalahan mahal bukanlah memilih Kubernetes alih-alih Slurm, atau H100 alih-alih H200. Kesalahan mahal adalah membeli kapasitas GPU sebelum arsitektur membuktikan bahwa kapasitas itu dapat diubah menjadi pekerjaan yang berguna.