GPU NVIDIA H100: Arsitektur, Performa, dan Panduan Deployment Cloud
GPU NVIDIA H100 adalah akselerator pusat data generasi Hopper yang dibangun untuk pelatihan AI, inferensi berthroughput tinggi, dan komputasi teknis. Nilainya di cloud tidak hanya berasal dari angka FLOPS utama. Pertanyaan yang berguna adalah apakah kapasitas memori, bandwidth memori, dukungan presisi, fabric GPU-ke-GPU, dan model operasionalnya sesuai dengan model dan layanan yang perlu Anda jalankan.
Bagi pengembang AI atau engineer infrastruktur ML, keputusan terkait GPU NVIDIA H100 memiliki tiga lapisan:
- Apakah model, cache KV, status optimizer, dan workspace dapat dimuat dengan margin aman?
- Apakah workload memerlukan satu GPU, node multi-GPU yang terhubung erat, atau klaster terdistribusi?
- Apakah deployment dapat memenuhi target latensi, throughput, keandalan, dan biaya setelah diinstrumentasikan dalam produksi?
Panduan ini menerjemahkan lembar spesifikasi menjadi pilihan deployment tersebut. Panduan ini berfokus pada fakta hardware terkini yang dapat diverifikasi serta proses rollout cloud yang dapat diulang—bukan snapshot harga penyedia yang belum diverifikasi.
Untuk apa GPU NVIDIA H100 dibuat
GPU NVIDIA H100 didasarkan pada arsitektur NVIDIA Hopper. Hopper memperkenalkan Tensor Core generasi keempat, Transformer Engine dengan dukungan FP8, memori HBM3 pada konfigurasi H100 SXM, NVLink, dan kemampuan Multi-Instance GPU (MIG). Fitur-fitur tersebut penting karena alasan yang berbeda:
- Tensor Core dan Transformer Engine memengaruhi jalur presisi campuran yang dapat digunakan oleh framework AI atau engine inferensi.
- Kapasitas dan bandwidth HBM memengaruhi apakah bobot model, aktivasi, dan cache KV dapat dimuat serta seberapa cepat pekerjaan yang terikat memori dapat memindahkan data.
- NVLink dan topologi sistem memengaruhi biaya komunikasi ketika workload mencakup beberapa GPU.
- MIG dapat mempartisi GPU yang didukung menjadi instance terisolasi untuk workload yang lebih kecil dan kompatibel.
Keluarga produk H100 bukanlah satu bentuk cloud tunggal. Sebelum membandingkan penawaran, tentukan apakah Anda melihat sistem H100 SXM, konfigurasi H100 NVL, atau penawaran lain berbasis H100 PCIe. Faktor bentuk dan interkoneksi dapat mengubah rencana paralelisme, penjadwalan, dan benchmark yang tepat.
Arsitektur GPU NVIDIA H100: fakta yang relevan untuk deployment
NVIDIA mencantumkan H100 SXM dengan memori HBM3 80 GB, bandwidth memori GPU 3,35 TB/s, bandwidth NVLink hingga 900 GB/s, dan hingga tujuh instance MIG 10 GB. NVIDIA mencantumkan H100 NVL secara terpisah dengan memori 94 GB, bandwidth 3,9 TB/s, bandwidth NVLink hingga 600 GB/s, serta faktor bentuk PCIe dual-slot berpendingin udara. Perlakukan hal tersebut sebagai fakta konfigurasi produk, bukan janji bahwa setiap listing cloud menyediakan topologi atau kapasitas yang dapat digunakan sama. Konfirmasikan bentuk instance yang tepat sebelum melakukan deployment. Spesifikasi produk NVIDIA H100
| Kemampuan | Mengapa penting dalam deployment cloud | Hal yang perlu diverifikasi sebelum berkomitmen |
|---|---|---|
| Kapasitas HBM | Menentukan seberapa banyak ruang yang tersedia untuk bobot, cache KV, aktivasi, workspace, dan ruang cadangan untuk fragmentasi. | VRAM tepat per GPU, memori yang dapat digunakan setelah runtime dimulai, serta penggunaan cache KV puncak pada panjang konteks target Anda. |
| Bandwidth HBM | Sering kali penting untuk inferensi dan fase pelatihan yang terikat memori. | Token/detik atau langkah/detik spesifik workload pada batch, panjang sekuens, dan presisi yang Anda inginkan. |
| Tensor Core dan dukungan FP8 | Dapat memungkinkan jalur presisi yang efisien ketika model, framework, dan target kualitas mendukungnya. | Jalur presisi yang didukung, proses kalibrasi atau kuantisasi, serta kriteria regresi kualitas. |
| Topologi NVLink / NVSwitch | Penting ketika worker tensor, pipeline, atau data-paralel bertukar tensor besar. | Jumlah GPU, output nvidia-smi topo -m, kesehatan fabric, dan hasil pengujian komunikasi kolektif. |
| MIG | Dapat meningkatkan utilisasi untuk workload kecil yang kompatibel, tetapi mengubah penentuan ukuran resource dan batas isolasi. | Profil yang didukung, eksposur scheduler, label pemantauan, dan apakah setiap tenant memerlukan GPU penuh. |
Detail arsitektur Hopper NVIDIA menjelaskan alasan komponen-komponen ini saling melengkapi: Tensor Core generasi keempat menambahkan FP8 dan Transformer Engine, sementara H100 SXM menggabungkan HBM3 dengan bandwidth memori lebih dari 3 TB/s. Ringkasan arsitektur NVIDIA Hopper
Jangan gunakan komputasi puncak sebagai estimasi deployment Anda
Throughput Tensor Core puncak berguna untuk perbandingan hardware, tetapi bukan SLA aplikasi. Dalam produksi, performa terukur bergantung pada arsitektur model, presisi, ukuran batch, campuran panjang sekuens, pemilihan kernel, caching, pemuatan data, overhead komunikasi, dan batas latensi tingkat layanan.
Untuk deployment GPU NVIDIA H100 baru, tetapkan terlebih dahulu pengujian penerimaan workload. Untuk layanan LLM, hal ini umumnya mencakup waktu hingga token pertama, latensi antartoken, latensi end-to-end p50/p95, token output yang diterima per detik, waktu antrean, tingkat kesalahan, dan pemeriksaan kualitas. Untuk pelatihan, lacak waktu per langkah, sampel per detik, waktu checkpoint, perilaku konvergensi, dan kesehatan all-reduce.
Pilih topologi H100 sebelum memilih kontrak cloud
Akselerator yang sama dapat di-deploy dengan cara yang sangat berbeda. Mulailah dari pola komunikasi, bukan nama GPU.
| Pola deployment | Biasanya tepat ketika | Pertimbangan desain utama |
|---|---|---|
| Satu GPU H100 | Sebuah model muat pada satu perangkat, atau Anda sedang memvalidasi layanan inferensi sebelum melakukan scale-out. | Kecukupan memori, konkurensi permintaan, penyimpanan persisten, dan benchmark baseline yang bersih. |
| Dua hingga empat GPU dalam satu node | Model atau batch memerlukan sharding, tetapi satu host dapat menampung seluruh grup serving atau pelatihan. | Topologi, komunikasi kolektif, keseimbangan CPU/RAM, dan pemulihan kegagalan. |
| Empat hingga delapan GPU H100 SXM dalam node bergaya HGX | Workload mendapatkan manfaat dari domain multi-GPU yang terhubung erat. | Visibilitas NVLink/NVSwitch, validasi NCCL, lokalitas data, dan rollout terkoordinasi. |
| Beberapa node | Job tidak dapat dimuat dalam satu node atau memerlukan throughput agregat yang lebih besar daripada yang dapat disediakan sebuah node. | Fabric jaringan, throughput penyimpanan, checkpointing, penempatan rank, dan isolasi kegagalan. |
| Kapasitas yang dipartisi dengan MIG | Beberapa workload kecil yang kompatibel dapat berbagi GPU fisik tanpa masing-masing memerlukan kapasitas perangkat penuh. | Penentuan ukuran profil, kebijakan scheduler, isolasi tenant, dan observabilitas per slice. |
Sebuah GPU NVIDIA H100 dalam VM satu GPU dapat menjadi langkah produksi awal yang masuk akal. Deployment H100 multi-GPU harus diperlakukan sebagai sebuah sistem: topologi host, interkoneksi, jaringan, CPU, penyimpanan, software stack, dan scheduler semuanya berkontribusi pada hasil. Untuk pandangan sistem perangkat keras yang lebih luas, lihat panduan deployment server GPU dari Flatkey.
Workflow deployment cloud yang praktis
1. Tulis ringkasan workload sebelum provisioning
Catat fakta yang membuat benchmark dapat direproduksi:
- Nama model, revisi, jumlah parameter, dan presisi.
- Panjang konteks target, campuran input/output, dan profil konkurensi.
- Tujuan pelatihan, fine-tuning, inferensi batch, atau online serving.
- SLO latensi, target throughput, serta batas kualitas atau akurasi.
- Region yang diperlukan, batas data, penyimpanan persisten, eksposur jaringan, dan target waktu pemulihan.
Untuk inferensi LLM, tentukan ukuran memori sebagai anggaran, bukan sebagai kalkulasi bobot model saja:
required GPU memory = model weights + KV cache at target concurrency
+ runtime workspace + communication buffers
+ safety margin for fragmentation and rollout variance
Nilai yang tepat berasal dari uji beban yang representatif. Model yang berhasil dimulai tetap dapat gagal memenuhi target konkurensi atau konteks panjangnya saat KV cache membesar.
2. Periksa instance, bukan hanya label akselerator
Sebelum memesan kapasitas, catat detail persis dari penawaran cloud:
- Varian H100, jumlah GPU, dan VRAM per perangkat.
- Topologi GPU-ke-GPU serta apakah listing mengekspos NVLink atau node yang didukung NVSwitch.
- Core CPU, RAM host, NVMe lokal, dan antarmuka jaringan.
- Kompatibilitas driver, CUDA, container runtime, dan framework.
- Apakah kapasitas bersifat dedicated, interruptible, atau tunduk pada kebijakan reclaim.
- Cara kerja snapshot, checkpoint, jaringan privat, dan ekspor metrik.
Gunakan shape GPU baru sebagai hipotesis, bukan sebagai desain yang telah selesai. Jalankan preflight kecil sebelum memigrasikan traffic atau berkomitmen pada reservasi jangka panjang.
3. Validasi hardware dan fabric
Setidaknya, pastikan bahwa sistem operasi, container runtime, dan workload dapat melihat perangkat yang Anda harapkan. Pada node multi-GPU, catat topologinya dan uji jalur kolektif yang akan digunakan oleh engine pelatihan atau serving Anda.
nvidia-smi
nvidia-smi topo -m
# Run inside the same CUDA-compatible image your workload will use.
nvidia-smi --query-gpu=name,memory.total,driver_version --format=csv
Untuk job multi-node, perluas uji penerimaan ke jalur jaringan aktual, penempatan rank, pembacaan penyimpanan, penulisan checkpoint, dan perilaku restart. Inventaris GPU yang sehat saja tidak membuktikan bahwa job terdistribusi dapat mempertahankan throughput.
4. Gunakan Kubernetes hanya ketika menyelesaikan masalah operasional
Kubernetes berguna ketika beberapa tim atau layanan memerlukan scheduling, kuota, isolasi, rollout yang dapat diulang, atau observabilitas di seluruh cluster. Kubernetes tidak wajib untuk satu VM yang dikelola dengan cermat.
Untuk deployment Kubernetes, GPU Operator NVIDIA mengotomatiskan driver NVIDIA, Container Toolkit, device plugin, GPU Feature Discovery, pemantauan berbasis DCGM, dan komponen GPU terkait. Instalasi default-nya juga men-deploy MIG Manager pada worker GPU. Tinjau matriks dukungan dan prasyarat instalasi terbaru sebelum menginstalnya—penawaran Kubernetes terkelola mungkin sudah menyediakan sebagian stack tersebut. Dokumentasi NVIDIA GPU Operator Panduan instalasi
Permintaan perangkat minimal sengaja dibuat sederhana:
resources:
limits:
nvidia.com/gpu: 1
Permintaan tersebut hanyalah permulaan. Tambahkan kebijakan pemilihan node, toleration, kuota sumber daya, pemeriksaan kompatibilitas image, perilaku volume persisten, dan metrik tingkat layanan sebelum menganggap workload siap produksi. Jika Anda membangun operasi multi-node, panduan klaster GPU Kubernetes Flatkey membahas kontrol tingkat platform yang perlu direncanakan.
5. Pilih stack inferensi atau pelatihan secara sengaja
Perangkat keras H100 tidak memilih runtime yang tepat untuk Anda. Gunakan stack serving yang mendukung model dan batasan operasional Anda, lalu validasikan dengan traffic yang menyerupai produksi. TensorRT-LLM, misalnya, menyediakan API dan runtime untuk inferensi LLM yang dioptimalkan pada GPU NVIDIA; performanya tetap perlu diukur dengan model, presisi, kebijakan batch, dan target latensi Anda. dokumentasi TensorRT-LLM
Untuk peluncuran inferensi produksi:
- Mulai dengan satu replika dan jejak permintaan yang representatif.
- Ukur kualitas, latensi, throughput, memori, antrean, dan perilaku error.
- Ubah satu faktor pada satu waktu: presisi, batch maksimum, batas konteks, paralelisme tensor, atau jumlah replika.
- Ulangi pengujian yang sama setelah perubahan driver, runtime, model, atau topologi.
- Alihkan traffic secara bertahap dan pertahankan jalur rollback dengan artefak terakhir yang terbukti baik.
6. Instrumentasikan GPU NVIDIA H100 sebagai bagian dari layanan
Pantau sinyal perangkat keras dan aplikasi. GPU NVIDIA H100 yang digunakan sepenuhnya dapat menunjukkan batching yang sehat, jalur permintaan yang terhenti, atau bottleneck di tempat lain; interpretasi memerlukan metrik layanan di sampingnya.
| Lapisan | Sinyal yang perlu dipantau |
|---|---|
| GPU | Utilisasi, memori yang dialokasikan/dicadangkan, daya, suhu, clock, peristiwa ECC/Xid, dan profil MIG. |
| Fabric | Topologi GPU, waktu operasi kolektif, pengiriman ulang jaringan, dan ketidakseimbangan rank. |
| Runtime | Kedalaman antrean, ukuran batch, okupansi cache, OOM/restart, pembatalan permintaan, dan waktu pemuatan model. |
| Pengalaman pengguna | Waktu hingga token pertama, latensi antar-token, latensi end-to-end p50/p95, permintaan yang berhasil, dan evaluasi kualitas. |
| Biaya dan kapasitas | Waktu instance berbayar, biaya penyimpanan/jaringan, waktu idle, utilisasi selama periode berbayar, dan pekerjaan berhasil yang diselesaikan. |
Tentukan peringatan berdasarkan gejala yang terlihat oleh pengguna. Misalnya, berikan peringatan saat penurunan berkelanjutan pada p95 waktu hingga token pertama disertai antrean yang bertambah, lalu gunakan telemetri GPU dan fabric untuk menyelidiki penyebabnya. Peringatan utilisasi mentah jarang cukup.
Optimasi performa: urutan operasi yang aman
Ketika layanan GPU NVIDIA H100 tidak memenuhi target, optimalkan dalam urutan berikut:
- Konfirmasikan target. Apakah kegagalan terkait latensi, throughput, biaya per tugas yang diselesaikan, kualitas, atau keandalan?
- Verifikasi baseline. Jalankan ulang jejak yang sama dengan model, image, driver, topologi, dan konkurensi yang sama.
- Temukan sumber daya yang membatasi. Ini mungkin VRAM, bandwidth memori, komputasi, tokenisasi CPU, komunikasi PCIe/NVLink, jaringan, penyimpanan, atau kebijakan antrean.
- Ubah satu variabel. Contohnya mencakup kebijakan batch, konteks maksimum, derajat paralel tensor, presisi, jumlah replika, atau konfigurasi cache.
- Jalankan ulang pemeriksaan fungsional dan kualitas. Output yang lebih cepat bukan kemenangan jika meningkatkan timeout atau mengubah kualitas model di luar rentang yang diterima.
- Dokumentasikan batas operasi. Catat pengaturan, hasil terukur, dan kondisi yang membuat hasil tersebut valid.
Pendekatan ini mencegah kesalahan umum: langsung beralih ke lebih banyak GPU ketika bottleneck sebenarnya adalah kebijakan konteks yang terlalu besar, jalur permintaan yang dibatasi CPU, atau pembagian traffic yang buruk.
Kontrol biaya tanpa perbandingan harga per jam yang rapuh
Harga, ketersediaan, dan ketentuan penagihan H100 cloud bervariasi menurut penyedia, wilayah, komitmen, dan jenis kapasitas. Alih-alih menggunakan daftar harga yang usang sebagai aturan pengambilan keputusan, bandingkan pekerjaan yang diselesaikan:
biaya per hasil yang berhasil =
(waktu instance GPU + penyimpanan + jaringan + overhead operasional)
/ hasil yang berhasil dalam jangka waktu pengukuran yang sama
Untuk layanan inferensi, definisikan “hasil yang berhasil” secara tepat: token yang diterima, permintaan yang selesai, gambar yang dihasilkan, dokumen yang dievaluasi, atau output lain yang memenuhi gerbang kualitas dan SLO Anda. Sertakan waktu berbayar tetapi idle dan percobaan ulang. Kemudian bandingkan angka tersebut dengan alternatif API model terkelola ketika produk tidak memerlukan kontrol tingkat GPU.
Gunakan panduan biaya per juta token LLM yang di-host sendiri Flatkey untuk model biaya yang dapat direproduksi, dan panduan cloud GPU vs. API model untuk batas keputusan antara kepemilikan infrastruktur dan akses model.
Checklist deployment GPU NVIDIA H100
Sebelum menyatakan layanan siap, verifikasi semua hal berikut:
- [ ] Konfigurasi H100 yang tepat, VRAM, topologi, CPU/RAM, penyimpanan, dan jaringan didokumentasikan.
- [ ] Anggaran memori model mencakup bobot, cache KV, ruang kerja runtime, buffer komunikasi, dan cadangan.
- [ ] Kompatibilitas driver, CUDA, framework, dan image container telah diuji pada shape target.
- [ ] Pengujian topologi dan kolektif GPU tunggal serta, jika relevan, multi-GPU berhasil.
- [ ] Trace yang menyerupai produksi memenuhi target latensi, throughput, kualitas, dan error.
- [ ] Sinyal GPU, fabric, runtime, pengalaman pengguna, dan biaya terlihat dalam satu tampilan operasional.
- [ ] Rollout bertahap, artefak rollback, strategi checkpoint, dan pemilik insiden telah ditetapkan.
- [ ] Biaya pekerjaan yang selesai dibandingkan dengan alternatif yang paling kredibel, bukan hanya harga GPU per jam.
Bagaimana H100 sesuai dalam pemilihan GPU AI
GPU NVIDIA H100 sangat sesuai ketika suatu workload mendapat manfaat dari fitur Tensor Core era Hopper, bandwidth HBM tinggi, topologi multi-GPU, atau deployment yang memerlukan kontrol atas runtime dan aliran data. Namun, H100 tidak otomatis menjadi pilihan yang tepat untuk setiap tugas AI. Akselerator yang lebih kecil, GPU yang lebih baru dan berfokus pada memori, atau API model terkelola mungkin lebih tepat ketika modelnya sederhana, permintaan bersifat sporadis, tim tidak dapat menjalankan layanan GPU, atau optimasi khusus perangkat keras tidak mengubah hasil produk.
Untuk keputusan terkait, bandingkan H100 vs. A100 saat mengevaluasi generasi sebelumnya, dan baca panduan deployment GPU H200 ketika kapasitas HBM3e yang lebih besar dapat mengubah kecocokan untuk inferensi.
Untuk melihat perbandingan berdampingan antara H100 dan saudaranya yang memiliki memori lebih besar, baca H200 vs H100 (2026).
Pertanyaan yang sering diajukan
Untuk apa GPU NVIDIA H100 digunakan?
GPU NVIDIA H100 digunakan untuk pelatihan AI, fine-tuning, inferensi LLM, komputasi ilmiah, dan workload terakselerasi lainnya. Konfigurasi yang sesuai bergantung pada jejak memori model, pola komunikasi, presisi, konkurensi, dan kebutuhan operasional.
Apakah H100 SXM berbeda dari penawaran H100 PCIe atau H100 NVL?
Ya. Faktor bentuk, konfigurasi memori, bandwidth NVLink, batas daya, pendinginan, dan topologi sistem dapat berbeda. Bacalah spesifikasi tepat dari penawaran cloud tersebut, alih-alih menganggap “H100” sebagai deskripsi konfigurasi yang lengkap.
Berapa besar memori GPU yang dimiliki H100?
NVIDIA mencantumkan H100 SXM dengan memori HBM3 80 GB dan H100 NVL dengan 94 GB. Perhitungan kapasitas yang tepat juga harus mencakup ruang kerja runtime, cache KV, memori aktivasi atau pelatihan, buffer komunikasi, dan margin keamanan. Spesifikasi NVIDIA H100
Apakah saya memerlukan Kubernetes untuk menjalankan workload H100 di cloud?
Tidak. VM dapat menjadi titik awal yang tepat untuk satu workload yang kepemilikannya jelas. Kubernetes menjadi lebih berguna ketika Anda memerlukan penjadwalan, tenancy, kuota, deployment yang dapat diulang, atau observabilitas bersama di seluruh worker GPU.
Haruskah saya memilih H100 atau H200 untuk inferensi LLM?
Mulailah dari kebutuhan memori dan konkurensi. Jika panjang konteks target dan cache KV Anda memerlukan cadangan memori yang lebih besar, H200 mungkin lebih sesuai; jika workload dapat ditampung dengan nyaman dan benchmark Anda memenuhi SLO, deployment H100 mungkin sudah memadai. Bandingkan sistem lengkap dan biaya pekerjaan yang selesai, bukan memilih hanya berdasarkan nama keluarga produk.
Intinya
GPU NVIDIA H100 menjadi berguna di produksi hanya ketika arsitekturnya dihubungkan dengan workload yang terukur dan model operasional yang andal. Verifikasi konfigurasi cloud yang tepat, anggaran memori model, topologi, kompatibilitas runtime, dan metrik penerimaan sebelum melakukan scale-out. Kemudian optimalkan bottleneck yang sebenarnya—dan bandingkan biaya berdasarkan pekerjaan berhasil yang diselesaikan, bukan berdasarkan label GPU atau tarif per jam yang terpisah.
Jika Anda masih memilih lapisan infrastruktur, gunakan panduan pemilihan GPU AI Flatkey untuk membandingkan kecocokan workload di berbagai keluarga GPU dan model deployment.
