GPU H200: Panduan Arsitektur, Performa, dan Deployment Cloud
GPU NVIDIA H200 adalah akselerator pusat data generasi Hopper yang fitur deployment penentunya adalah memori: 141 GB HBM3e dan bandwidth memori 4,8 TB/s per GPU. Hal ini mengubah cara Anda merencanakan inferensi konteks panjang, batch besar, dan pekerjaan HPC yang dibatasi memori—tetapi tidak menjadikan perencanaan kapasitas atau validasi cloud sebagai sesuatu yang opsional.
Panduan ini menjelaskan apa itu GPU H200, perbedaan H200 SXM dan H200 NVL, kapan GPU ini sesuai untuk suatu beban kerja, serta cara memvalidasi deployment cloud sebelum berkomitmen pada armada yang lebih besar. Panduan ini sengaja menghindari snapshot harga penyedia yang dapat berubah-ubah. Gunakan daftar periksa di bawah ini dengan region, jenis mesin, topologi, dan kontrak yang tepat yang tersedia bagi Anda.
Jawaban singkat
Pilih GPU H200 ketika beban kerja Anda dibatasi oleh kapasitas atau bandwidth memori GPU, dan ketika Anda dapat memvalidasi sistem di sekelilingnya—bukan hanya akseleratornya. Untuk server model satu GPU, ini berarti membuktikan bahwa bobot model, workspace runtime, dan cache KV dapat termuat dengan ruang cadangan. Untuk pelatihan atau serving multi-GPU, ini berarti membuktikan fabric GPU-ke-GPU dan, jika berlaku, jaringan antarnode.
GPU H200 bukan peningkatan universal. Jika permintaan singkat, ukuran batch rendah, atau beban kerja dibatasi oleh CPU, penyimpanan, atau jaringan, memori tambahannya mungkin tidak mengubah hasil yang penting. Mulailah dengan ringkasan beban kerja, lalu uji trace yang representatif.
Spesifikasi GPU H200: hal yang mengubah rencana deployment Anda
NVIDIA mencantumkan H200 sebagai GPU berarsitektur Hopper dengan memori HBM3e 141 GB dan bandwidth memori 4,8 TB/s. GPU ini tersedia sebagai H200 SXM dan H200 NVL, dengan angka memori utama yang sama tetapi faktor bentuk, batas daya, dan opsi penskalaan yang berbeda. Angka puncak Tensor Core yang dipublikasikan NVIDIA berguna untuk membandingkan konfigurasi produk, tetapi bukan jaminan throughput aplikasi: angka tersebut mencakup kondisi pengujian dan asumsi sparsity yang dinyatakan. Tinjau spesifikasi produk H200 terkini sebelum memilih SKU.
| Spesifikasi yang relevan untuk deployment | H200 SXM | H200 NVL | Mengapa penting |
|---|---|---|---|
| Arsitektur | Hopper | Hopper | Kompatibilitas perangkat lunak dan fitur yang didukung berawal dari platform, bukan nama model. |
| Memori GPU | 141 GB HBM3e | 141 GB HBM3e | Lebih banyak ruang untuk bobot, cache KV, aktivasi, dan ruang cadangan runtime. |
| Bandwidth memori | 4,8 TB/s | 4,8 TB/s | Penting untuk beban kerja yang berulang kali memindahkan set kerja besar melalui memori. |
| Faktor bentuk | SXM | PCIe dual-slot berpendingin udara | Menentukan desain server dan pilihan fabric yang tersedia. |
| TDP maksimum yang tercantum | Hingga 700 W, dapat dikonfigurasi | Hingga 600 W, dapat dikonfigurasi | Memengaruhi pilihan daya host, pendinginan, rak, dan instans cloud. |
| Interkoneksi GPU | NVLink, tercantum sebesar 900 GB/s | Bridge NVLink 2 atau 4 arah, tercantum sebesar 900 GB/s per GPU; PCIe Gen5 | Topologi harus diperiksa sebelum mengasumsikan performa kolektif multi-GPU. |
| Partisi | Hingga tujuh MIG, masing-masing 18 GB | Hingga tujuh MIG, masing-masing 16,5 GB | Memungkinkan penggunaan bersama yang terkendali, tetapi mengubah model sumber daya dan observabilitas. |
Ini adalah angka yang dipublikasikan vendor, dan NVIDIA menandainya sebagai sementara pada halaman produknya. Perlakukan angka tersebut sebagai baseline konfigurasi, lalu verifikasi SKU cloud yang tepat beserta topologinya di lingkungan tempat Anda akan menjalankannya.
Mengapa HBM3e penting untuk inferensi LLM
Untuk serving LLM, memori GPU digunakan untuk lebih dari sekadar bobot model. Persamaan kapasitas awal yang berguna adalah:
required GPU memory = weights + runtime workspace + KV cache at p95 context and concurrency + operational headroom
GPU H200 dapat menarik ketika cache KV menjadi faktor pembatas: prompt yang lebih panjang, lebih banyak sekuens simultan, atau batch yang lebih besar semuanya dapat meningkatkannya. HBM tambahan tidak menghilangkan risiko kehabisan memori, karena kebijakan cache, perilaku allocator, kuantisasi, paralelisme model, dan bentuk trafik tetap berpengaruh. Untuk deployment konteks panjang, padukan keputusan ini dengan rencana offload dan tiering cache KV alih-alih mengasumsikan bahwa lebih banyak memori lokal adalah keseluruhan jawabannya.
H200 SXM atau H200 NVL: pilih topologinya, bukan hanya kartunya
Faktor bentuk adalah pilihan deployment.
- H200 SXM sesuai untuk desain sistem HGX H200 dan NVIDIA-Certified dengan empat atau delapan GPU. Biasanya ini adalah titik awal yang tepat ketika satu beban kerja memerlukan sistem multi-GPU yang terintegrasi erat dan aplikasi akan sering bertukar data antargpu.
- H200 NVL adalah desain PCIe dual-slot berpendingin udara. NVIDIA mencantumkan konfigurasi bridge NVLink 2 atau 4 arah, sementara sistem mitra dan tersertifikasi dapat berisi hingga delapan GPU. Jangan menyimpulkan bahwa setiap server delapan GPU menyediakan jalur GPU-ke-GPU langsung yang sama; periksa topologi aktual dan benchmark operasi kolektif yang digunakan runtime Anda.
- Replika independen tidak secara otomatis memerlukan fabric yang paling terintegrasi erat. Jika setiap replika melayani permintaannya sendiri, prioritaskan kapasitas, ketersediaan, sumber daya host, dan batas penjadwalan yang jelas sebelum membayar topologi yang tidak akan digunakan oleh beban kerja.
| Pola beban kerja | Pertanyaan desain awal H200 | Hal yang harus divalidasi terlebih dahulu |
|---|---|---|
| Satu server model pada satu akselerator | Apakah anggaran memori p95 sesuai dengan ruang cadangan yang aman? | Stabilitas alokasi, TTFT, latensi antar-token, dan watermark memori. |
| Satu model dibagi di beberapa GPU | Apakah strategi paralelisme model sesuai dengan topologi NVLink/NVSwitch yang sebenarnya? | nvidia-smi topo -m, perilaku kolektif, dan latensi end-to-end. |
| Beberapa replika serving | Apakah replika bersifat independen atau berbagi host maupun jaringan yang menjadi bottleneck? | Throughput per replika, antrean, perilaku noisy neighbor, dan I/O host. |
| Pelatihan atau fine-tuning terdistribusi | Apakah fabric dan jaringan antar-node sesuai dengan pola kolektif? | Startup NCCL, bandwidth kolektif, I/O checkpoint, dan tingkat straggler. |
| Inferensi multi-tenant | Apakah GPU penuh, instance MIG, atau sumber daya yang diiris berdasarkan waktu merupakan tingkat isolasi yang tepat? | Isolasi memori, isolasi kegagalan, chargeback, dan observabilitas per tenant. |
NVIDIA mendokumentasikan kapasitas MIG H200, tetapi jangan menganggap mode berbagi GPU dapat saling dipertukarkan. Di Kubernetes, MIG membuat instance GPU yang diisolasi oleh hardware, sedangkan time slicing menyelang-selingkan pekerjaan dan tidak menyediakan isolasi memori atau kegagalan antar-replika. Panduan berbagi GPU Operator menjelaskan trade-off dan batasan pemantauannya.
Untuk perbandingan pembelian yang lebih mendalam, lihat H200 vs. H100. Perbandingan tersebut berguna untuk pengambilan keputusan; halaman ini adalah playbook deployment setelah H200 menjadi kandidat.
Kapan GPU H200 merupakan pilihan yang tepat
GPU H200 umumnya layak diuji ketika salah satu batasan berikut nyata di lingkungan produksi:
- Inferensi LLM yang terikat memori. Panjang konteks atau konkurensi p95 Anda menghabiskan anggaran memori praktis sebelum komputasi digunakan sepenuhnya.
- AI atau HPC yang sensitif terhadap bandwidth. Profiling menunjukkan pekerjaan menghabiskan waktu yang signifikan untuk menunggu perpindahan memori, alih-alih sekadar menjenuhkan komputasi Tensor Core.
- Working set lebih besar yang berada di memori. Anda memerlukan lebih banyak ruang untuk model, konteks retrieval, batch, cache, atau struktur data ilmiah tanpa harus segera menambahkan GPU lain.
- Pekerjaan multi-GPU yang terikat erat. Anda dapat menggunakan sistem bergaya H200 SXM/HGX dan memiliki bukti bahwa aplikasi memperoleh manfaat dari fabric-nya.
- Kebutuhan partisi yang terkendali. Anda memiliki alasan jelas untuk menggunakan konfigurasi MIG yang tercantum, ditambah scheduler dan model chargeback yang sesuai dengannya.
Jangan menentukan pilihan GPU H200 hanya berdasarkan jumlah parameter model. Jumlah parameter hanya sedikit menjelaskan presisi, workspace runtime, kebijakan KV-cache, konteks maksimum, bentuk batch, dan margin ketersediaan. Hal tersebut juga tidak menjelaskan bottleneck CPU host, RAM, penyimpanan, atau jaringan yang dapat mendominasi beban kerja cloud.
Buat rencana kapasitas H200 sebelum menyewa GPU cloud
Gunakan ringkasan satu halaman ini sebelum membuat instance atau meminta node pool cluster.
| Input | Catat | Mengapa hal ini mengubah hasil |
|---|---|---|
| Model dan presisi | Revisi model yang tepat, format bobot, kuantisasi, dan runtime | Menentukan batas dasar memori dan software stack yang kompatibel. |
| Distribusi permintaan | Token prompt p50/p95, token output, tingkat kedatangan, dan konkurensi | Rata-rata menyembunyikan kondisi cache dan antrean yang menyebabkan SLO latensi gagal. |
| Tujuan layanan | Waktu p95 hingga token pertama, latensi antar-token p95, anggaran error, dan target pemulihan | Menentukan apakah Anda memerlukan replika, kapasitas siap pakai, atau fabric yang lebih cepat. |
| Rencana paralelisme | GPU tunggal, tensor parallel, pipeline parallel, data parallel, atau replika independen | Menentukan apakah memori lokal, NVLink, atau jaringan menjadi jalur kritis. |
| Lingkungan deployment | VM tunggal, node pool terkelola, atau cluster Kubernetes | Mengubah kepemilikan driver, penjadwalan, observabilitas, dan tanggung jawab upgrade. |
| Jalur data | Sumber artefak model, penyimpanan checkpoint, indeks vektor, jalur egress, dan kebijakan jaringan | Mencegah akselerator cepat menunggu penyimpanan atau jaringan. |
| Unit finansial | Permintaan yang diterima, batch yang selesai, epoch pekerjaan, atau satu juta token yang diterima | Mencegah penawaran GPU per jam menjadi satu-satunya metrik biaya. |
Nilai ringkasan ini adalah membuat ketidaksesuaian terlihat lebih awal. Sebagai contoh, konfigurasi satu GPU dapat gagal akibat tekanan konteks dan cache p95, bahkan ketika pengujian sintetis dengan prompt pendek terlihat sangat baik. Sebaliknya, konfigurasi multi-GPU dapat berkinerja buruk jika dibagi di seluruh fabric yang tidak digunakan secara efisien oleh runtime.
Deployment cloud: runbook GPU H200 bertahap
1. Konfirmasikan bentuk cloud yang tepat
Mintalah penyedia atau tim platform untuk form factor akselerator yang tepat, jumlah GPU, alokasi CPU/RAM, penyimpanan lokal dan persisten, karakteristik jaringan, serta topologi GPU. Catat jawabannya dalam tiket deployment. “H200” saja bukan informasi yang cukup untuk memperkirakan performa multi-GPU.
Sebelum memesan kapasitas, validasi detail berikut dalam pilot jangka pendek:
- H200 SXM atau H200 NVL
- jumlah GPU dan output dari
nvidia-smi topo -m - apakah instance bersifat eksklusif, dipartisi, atau diiris berdasarkan waktu
- versi driver, CUDA, container-runtime, dan framework
- RAM host, inti CPU, throughput penyimpanan, dan jalur jaringan yang tersedia
- waktu penarikan image, pengunduhan model, checkpoint, dan restart
2. Instal jalur perangkat lunak yang didukung
Untuk deployment Kubernetes, GPU Operator NVIDIA dapat mengelola driver NVIDIA, container toolkit, device plugin, GPU Feature Discovery, pemantauan berbasis DCGM, dan komponen terkait. Panduan instalasi resmi menyoroti konsistensi sistem operasi node saat Operator mengelola driver, serta prasyarat runtime container dan keamanan namespace. Ikuti panduan instalasi GPU Operator saat ini, alih-alih menyalin versi chart yang sudah usang.
Instalasi awal mengikuti pola ini; ganti versinya dengan versi yang telah Anda validasi terhadap cluster dan kebijakan driver Anda:
helm install --wait gpu-operator \
-n gpu-operator --create-namespace \
oci://nvcr.io/nvidia/cloud-native-charts/gpu-operator \
--version=<validated-operator-version>
Setelah instalasi, validasi pod Operator dan status ClusterPolicy sebelum mengirimkan workload pertama. Panduan Operator juga menunjukkan cara mengonfirmasi bahwa node melaporkan resource nvidia.com/gpu yang dapat dialokasikan.
3. Buat penjadwalan eksplisit
Mulailah dengan permintaan GPU penuh yang eksklusif, kecuali Anda memang telah merancang untuk mode berbagi:
resources:
limits:
nvidia.com/gpu: 1
Gunakan label node pool milik platform atau selector cloud untuk menargetkan node H200 yang telah diverifikasi; jangan hard-code label produk dari cluster contoh. Kubernetes mendokumentasikan penjadwalan GPU melalui device plugin dan extended resources, termasuk pola batas resource di atas. Lihat dokumentasi penjadwalan GPU Kubernetes untuk kontrak terkini.
Jika Anda mengaktifkan MIG, drain atau cordon node yang relevan terlebih dahulu. NVIDIA mencatat bahwa mengubah mode atau geometri MIG mengharuskan workload pengguna tidak berada di GPU dan mungkin memerlukan reboot di beberapa lingkungan cloud. Tinjau prosedur MIG GPU Operator sebelum menganggap perubahan partisi sebagai operasi online.
4. Buktikan workload sederhana, lalu workload nyata Anda
Jalankan tiga gerbang secara berurutan:
- Gerbang platform: Driver dan CUDA dimuat; scheduler melihat jumlah GPU yang diharapkan; container dapat membuat konteks CUDA.
- Gerbang fabric: Topologi sesuai dengan desain yang diharapkan; runtime multi-GPU melakukan inisialisasi dan menyelesaikan pengujian kolektif yang representatif.
- Gerbang aplikasi: Pemutaran ulang prompt representatif, ukuran batch, panjang konteks, pola checkpoint, atau input simulasi mencapai target latensi, throughput, dan error yang diperlukan.
Gerbang ketiga adalah gerbang pengambilan keputusan. Benchmark generik dapat memberi tahu Anda bahwa GPU berfungsi; benchmark tersebut tidak dapat memberi tahu apakah distribusi traffic, server model, dan kebijakan cache Anda berfungsi.
Validasi performa sebelum melakukan penskalaan
Bangun pengujian penerimaan berdasarkan bottleneck yang Anda perkirakan, lalu periksa hasil yang dapat membantah asumsi tersebut.
| Asumsi | Pengujian | Sinyal keberhasilan | Kegagalan yang perlu diinvestigasi |
|---|---|---|---|
| Model muat | Jalankan trace konteks/konkurensi p95 dengan watermark memori | Alokasi stabil dengan headroom yang eksplisit | OOM, eviction thrash, atau lonjakan latensi saat cache bertambah. |
| Fabric memadai | Jalankan mode paralelisme yang tepat dan pengujian kolektif yang relevan | Tidak ada hang; waktu kolektif dan end-to-end stabil | Kesalahan inisialisasi NCCL, rank yang tidak merata, atau peer yang lambat. |
| Layanan memenuhi SLO-nya | Ukur TTFT p50/p95, latensi antar-token, latensi end-to-end, dan permintaan yang selesai | Target terpenuhi pada beban representatif | Antrean, latensi long-tail, atau pertumbuhan retry. |
| Node sehat | Periksa telemetri pasif dan diagnostik aktif dalam jendela pemeliharaan | Tidak ada temuan hardware, fabric, atau deployment yang dapat ditindaklanjuti | Peristiwa ECC/Xid, batas termal/daya, temuan PCIe/NVLink. |
| Ekonominya layak | Bagi waktu yang dibebani penuh dengan pekerjaan berguna yang telah selesai | Biaya berada dalam ambang peluncuran | Kapasitas menganggur, pekerjaan gagal, atau overhead penyimpanan/jaringan yang belum diperhitungkan harganya. |
NVIDIA DCGM memisahkan pemantauan kesehatan pasif dari diagnostik aktif. Alur kerja diagnostiknya dapat menguji jalur deployment, memori, PCIe, NVLink, komputasi, daya, termal, dan komunikasi, tetapi menggunakan resource serta dapat berkonflik dengan pekerjaan produksi. Lakukan drain atau jadwalkan jendela pemeliharaan sebelum menjalankan diagnostik invasif. Gunakan panduan diagnostik DCGM terkini untuk memilih tingkat pengujian yang sesuai.
Untuk layanan LLM, lacak sinyal aplikasi dan infrastruktur:
- waktu p50/p95 hingga token pertama dan latensi antartoken
- token output yang diterima per detik dan permintaan yang selesai per detik
- kedalaman antrean, pembatalan, percobaan ulang, dan tingkat kesalahan
- memori GPU yang dialokasikan dibandingkan dengan yang dicadangkan, utilisasi GPU, daya, dan suhu
- perilaku cache hit/offload dan kegagalan terkait cache
- saturasi CPU host, tekanan RAM, I/O model/checkpoint, dan latensi jaringan
Jika satu metrik membaik sementara metrik lain memburuk, jangan lakukan penskalaan terlebih dahulu. Laju token yang lebih tinggi dengan latensi p95 atau percobaan ulang yang meningkat dapat menjadi kemunduran bagi layanan yang berhadapan dengan pelanggan.
Optimalkan biaya berdasarkan pekerjaan yang selesai, bukan waktu GPU per jam
Tarif GPU H200 cloud bervariasi menurut wilayah, jangka waktu reservasi, konfigurasi host, dan ketersediaan, sehingga tabel harga statis cepat usang. Sebagai gantinya, gunakan unit beban kerja yang mengungkapkan waktu idle dan pekerjaan yang gagal:
fully loaded hourly cost = accelerator + attached CPU/RAM + storage + network + licenses + operating overhead
cost per completed request = fully loaded hourly cost / completed requests per hour
cost per million accepted output tokens = fully loaded hourly cost / accepted output tokens per hour × 1,000,000
Hitung ini pada campuran trafik yang Anda rencanakan untuk diluncurkan, bukan pada demo throughput maksimum. Sertakan kapasitas yang ditahan untuk failover, pemuatan model, checkpoint, dan pemeliharaan. Untuk model yang lebih terperinci, lihat Biaya LLM Self-Hosted per Juta Token.
Ada juga pertanyaan batasan: apakah Anda perlu mengoperasikan runtime, atau apakah Anda memerlukan akses yang andal ke output model? Jika Anda memerlukan kernel kustom, runtime tertentu, lokalitas data khusus, atau eksperimen hardware yang terkontrol, pilot GPU H200 cloud mungkin dapat dibenarkan. Jika Anda terutama memerlukan API model, bandingkan beban operasional dengan jalur API sebelum berkomitmen pada infrastruktur. panduan deployment server GPU dan panduan klaster GPU Kubernetes dapat membantu memperjelas batasan tersebut.
Daftar periksa deployment GPU H200
Sebelum menyatakan deployment H200 siap, verifikasi semua hal berikut:
- [ ] Faktor bentuk H200 yang tepat, jumlah GPU, dan topologi telah dicatat
- [ ] Anggaran memori diuji pada konteks p95 dan konkurensi yang diharapkan
- [ ] Kompatibilitas driver, CUDA, framework, dan image container telah divalidasi
- [ ] Kesehatan GPU Operator/device plugin telah dikonfirmasi jika menggunakan Kubernetes
- [ ] Scheduler mengekspos kapasitas
nvidia.com/gpuyang diharapkan - [ ] Pengujian kolektif multi-GPU lulus pada topologi produksi
- [ ] Uji beban representatif memenuhi target TTFT, latensi, throughput, dan kesalahan
- [ ] Kesehatan DCGM dan diagnostik jendela pemeliharaan yang sesuai merupakan bagian dari runbook
- [ ] Jalur storage, jaringan, pemuatan model, checkpoint, dan restart telah diukur
- [ ] Biaya dihitung per unit berguna yang selesai, termasuk kapasitas idle dan pemulihan
Pertanyaan yang sering diajukan
Berapa banyak memori yang dimiliki GPU H200?
NVIDIA mencantumkan memori HBM3e 141 GB dan bandwidth memori 4,8 TB/dtk untuk H200 SXM maupun H200 NVL. Konfirmasikan SKU dan konfigurasi sistem yang tepat kepada penyedia, karena faktor bentuk kartu dan interkoneksinya berbeda. spesifikasi H200 NVIDIA adalah sumber angka dalam panduan ini.
Apakah GPU H200 lebih baik daripada H100 untuk inferensi LLM?
Bisa, terutama ketika kapasitas memori atau bandwidth memori membatasi beban kerja. Jawaban praktisnya bergantung pada presisi model, panjang konteks, perilaku KV-cache, konkurensi, runtime serving, dan topologi sistem. Bandingkan beban kerja menggunakan trace yang representatif; jangan anggap benchmark vendor sebagai pengganti SLO layanan Anda. Lihat perbandingan H200 vs. H100 untuk kerangka pengambilan keputusan hardware.
Haruskah saya memilih H200 SXM atau H200 NVL?
Pilih berdasarkan topologi terlebih dahulu. H200 SXM cocok untuk konfigurasi multi-GPU bergaya HGX yang terintegrasi erat. H200 NVL adalah opsi PCIe berpendingin udara dengan konfigurasi bridge NVLink 2 atau 4 arah. Verifikasi topologi, host, dan pola komunikasi beban kerja, alih-alih memilih berdasarkan memori saja.
Apakah GPU H200 mendukung MIG?
NVIDIA mencantumkan hingga tujuh instance MIG untuk H200 SXM dan H200 NVL, dengan ukuran memori per instance yang tercantum berbeda. Gunakan MIG ketika Anda memerlukan isolasi memori dan fault yang didukung hardware. Jangan menggantinya dengan time slicing ketika properti isolasi tersebut diperlukan.
Berapa banyak GPU H200 yang saya perlukan?
Mulailah dengan konfigurasi terkecil yang lulus pengujian memori, latensi, throughput, dan pemulihan yang representatif. Tambahkan GPU hanya ketika anggaran memori, jumlah replika, atau rencana paralelisme yang telah divalidasi memerlukannya. Jumlah GPU yang lebih besar tanpa beban kerja yang sadar fabric dapat menambah biaya dan kompleksitas operasional tanpa membantu hasil yang berhadapan dengan pelanggan.
Mulai dengan pilot GPU H200 yang tervalidasi
Deployment GPU H200 yang tepat adalah sistem yang terukur: memori accelerator, topologi, scheduler, runtime, jalur data, observabilitas, dan ekonomi beban kerja semuanya harus selaras. Mulailah dengan pilot yang terinstrumentasi, putar ulang trafik realistis, dokumentasikan mode kegagalan, dan lakukan penskalaan hanya setelah bukti mendukung langkah kapasitas berikutnya.
