Penyetelan Performa GPU: Memaksimalkan Throughput untuk Pelatihan dan Inferensi LLM

Diperbarui 8 Desember 2025

Pembaruan Desember 2025: Pelatihan FP8 kini siap produksi pada H100/H200 dan Blackwell, memberikan throughput 2x lipat dibanding FP16 dengan akurasi setara. Flash Attention 3 dioptimalkan untuk arsitektur Hopper mencapai percepatan 1,5-2x. vLLM 0.6+ dan TensorRT-LLM memberikan peningkatan throughput inferensi 3-5x melalui continuous batching dan speculative decoding. torch.compile dengan backend Triton kini menjadi default untuk PyTorch 2.4+. NVIDIA NeMo Framework 2.0 menyediakan pipeline pelatihan end-to-end yang teroptimasi.

Node 8-GPU yang dikonfigurasi sempurna mencapai 98% FLOPS teoretis sementara sistem identik yang dikonfigurasi buruk hanya mencapai 43%, membuang $380.000 per tahun untuk hardware yang tidak dimanfaatkan secara optimal.¹ Benchmark MLPerf mengungkapkan bahwa performer terbaik mengekstrak throughput 2,3x lebih banyak dari GPU H100 yang identik dibandingkan submission median, dengan perbedaan sepenuhnya disebabkan oleh optimasi software bukan keunggulan hardware.² Kesenjangan antara performa teoretis dan aktual menghantui setiap tim AI, di mana satu parameter yang salah dikonfigurasi dapat menggandakan waktu pelatihan atau melipattigakan biaya inferensi. Organisasi yang menguasai penyetelan performa GPU menyelesaikan pelatihan model 60% lebih cepat dan melayani permintaan inferensi dengan biaya 40% lebih rendah per token dibandingkan kompetitor yang menggunakan konfigurasi default.

Panduan optimasi NVIDIA mencakup 1.200 halaman di berbagai framework, kernel, dan konfigurasi, namun sebagian besar tim hanya mengimplementasikan kurang dari 20% optimasi yang tersedia karena kompleksitas dan keterbatasan waktu.³ Pelatihan LLM tipikal melibatkan lebih dari 300 parameter yang dapat disetel yang mempengaruhi alokasi memori, penjadwalan kernel, pola komunikasi, dan presisi numerik. Setiap parameter berinteraksi dengan yang lain secara non-linear: meningkatkan batch size meningkatkan utilisasi GPU tetapi dapat memicu error out-of-memory atau menurunkan konvergensi. Ruang optimasi menjadi sangat luas sehingga pencarian exhaustive terbukti tidak mungkin, membutuhkan pendekatan sistematis yang menyeimbangkan peningkatan performa dengan usaha engineering.

Bottleneck bandwidth memori membatasi performa LLM

LLM modern mencapai batas memori jauh sebelum batas komputasi. Bandwidth memori H100 sebesar 3,35TB/s melayani 1.979 TFLOPS komputasi, menciptakan rasio compute-to-memory 591:1.⁴ Inferensi LLM membaca weight model berulang kali untuk setiap generasi token, menjadikan bandwidth memori sebagai kendala utama. Model 70B parameter pada presisi FP16 membutuhkan 140GB hanya untuk weight, menghabiskan seluruh memori H100 dengan ruang minimal untuk aktivasi dan KV cache.

Optimasi memori dimulai dengan memahami pola akses. Pembacaan sekuensial mencapai 95% dari bandwidth teoretis sementara akses acak turun ke 15%. LLM menunjukkan pola campuran: pembacaan weight tetap sekuensial tetapi mekanisme attention menciptakan akses tidak teratur ke key-value cache. Mengoptimalkan layout memori meningkatkan throughput secara dramatis. Penyimpanan row-major versus column-major mengubah efisiensi akses memori hingga 4x untuk operasi tertentu. Padding tensor agar sejajar dengan batas 128-byte meningkatkan utilisasi bandwidth dari 72% menjadi 91%.⁵

Flash Attention merevolusi efisiensi memori dengan menggabungkan operasi dan mengurangi akses HBM. Mekanisme attention standar menulis matriks intermediate ke HBM, mengonsumsi bandwidth untuk data sementara. Flash Attention menghitung attention dalam tile SRAM, mengurangi traffic memori 10-20x.⁶ Optimasi ini memungkinkan panjang konteks 4x lebih panjang dan pelatihan 2,4x lebih cepat untuk model seperti GPT-3. Implementasi memerlukan pemilihan ukuran tile yang cermat berdasarkan arsitektur GPU: ukuran tile optimal H100 berbeda dari A100 karena kapasitas SRAM yang lebih besar.

Optimasi batch size menyeimbangkan throughput dan konvergensi

Batch yang lebih besar meningkatkan utilisasi GPU tetapi mempengaruhi konvergensi model secara tidak terduga. Setiap GPU mengeksekusi paling efisien pada kelipatan batch size tertentu yang ditentukan oleh dimensi Tensor Core. H100 Tensor Core memproses operasi FP16 dalam tile matriks 16x16, membuat batch size yang habis dibagi 16 menjadi optimal.⁷ Batch size 127 hanya mencapai utilisasi 61% sementara batch size 128 mencapai 94%. Perbedaan dramatis ini berasal dari penjadwalan hardware yang selaras sempurna dengan dimensi pangkat-2.

Gradient accumulation memungkinkan batch size efektif yang besar tanpa kendala memori. Pelatihan dengan batch size 2048 mungkin melebihi memori, tetapi mengakumulasi gradien selama 32 langkah dengan batch size 64 mencapai hasil yang setara. Teknik ini mempertahankan kesetaraan matematis sambil tetap sesuai dengan batas memori. Overhead komunikasi sedikit meningkat karena sinkronisasi gradien terjadi lebih jarang. Implementasi cerdas melakukan overlap komputasi gradien dengan komunikasi, menyembunyikan latensi sepenuhnya.

Dynamic batch sizing beradaptasi dengan panjang sequence yang bervariasi dalam pelatihan LLM. Batch size tetap membuang komputasi pada padding token ketika sequence bervariasi panjangnya. Dynamic batching mengemas sequence secara efisien, meningkatkan throughput 20-35%.⁸ Kompleksitas implementasi meningkat karena alokasi memori menjadi tidak terduga. Strategi pre-allocation dengan pooling mencegah fragmentasi sambil mempertahankan performa.

Pelatihan mixed precision mempercepat tanpa kehilangan akurasi

Pelatihan dalam FP16 menggandakan throughput dibandingkan FP32 sambil mempertahankan kualitas model melalui manajemen numerik yang cermat. Tensor Core mencapai 312 TFLOPS dalam FP32 tetapi 989 TFLOPS dalam FP16 pada GPU H100.⁹ Keunggulan komputasi 3,2x dikombinasikan dengan penghematan memori 2x, memungkinkan model atau batch size yang lebih besar. Framework Automatic Mixed Precision (AMP) menangani manajemen presisi secara transparan, tetapi memahami internal memungkinkan optimasi yang lebih baik.

Loss scaling mencegah gradient underflow dalam pelatihan FP16. Gradien sering turun di bawah nilai minimum yang dapat direpresentasikan FP16 (5.96e-8), muncul sebagai nol dan menghentikan pembelajaran.¹⁰ Mengalikan loss dengan 2^16 menggeser gradien ke rentang yang dapat direpresentasikan FP16. Dynamic loss scaling menyesuaikan multiplier berdasarkan statistik gradien, mencegah underflow maupun overflow. Faktor scaling optimal bervariasi berdasarkan arsitektur model dan dataset.

Salinan master weight dalam FP32 mempertahankan presisi update sambil menghitung dalam FP16. Update gradien kecil pada weight besar menghilang dalam aritmatika FP16. Mempertahankan weight dalam FP32 mengakumulasi update secara presisi. Overhead menambah 50% memori untuk weight tetapi biaya komputasi yang dapat diabaikan. Implementasi lanjutan menggunakan stochastic rounding untuk menyuntikkan noise yang sesuai, meningkatkan konvergensi dalam beberapa kasus.

Kernel fusion menghilangkan bottleneck memori

Kernel GPU yang diluncurkan secara individual menciptakan traffic memori untuk hasil intermediate. Layer normalization sederhana melibatkan kernel terpisah untuk mean, variance, pengurangan, pembagian, dan scaling. Setiap kernel membaca dari dan menulis ke HBM, mengonsumsi bandwidth 5x dari yang diperlukan. Kernel yang digabungkan menghitung seluruh operasi dalam register dan shared memory, menyentuh HBM hanya untuk input dan output.

Kernel kustom mengoptimalkan arsitektur model tertentu. Kernel GEMM standar menangani perkalian matriks umum tetapi melewatkan peluang optimasi dalam blok transformer. Kernel khusus untuk attention, feedforward network, dan layer normalization meningkatkan throughput 30-50%.¹¹ Pengembangan memerlukan keahlian CUDA dan penyetelan khusus arsitektur. Library seperti Apex dan TransformerEngine menyediakan kernel yang dioptimalkan untuk operasi umum.

Framework kompilasi mengotomatisasi kernel fusion melalui optimasi graph. torch.compile PyTorch menganalisis computation graph dan menghasilkan kernel yang digabungkan secara otomatis.¹² XLA juga mengoptimalkan model TensorFlow dan JAX. Overhead kompilasi teramortisasi selama pelatihan yang panjang. Kompilasi awal memakan waktu beberapa menit tetapi iterasi berikutnya berjalan 20-40% lebih cepat. Profile-guided optimization lebih lanjut meningkatkan performa dengan mengkhususkan untuk bentuk input yang diamati.

Optimasi komunikasi untuk pelatihan terdistribusi

Pelatihan multi-GPU memerlukan optimasi yang cermat terhadap pola komunikasi. NCCL (NVIDIA Collective Communications Library) menyediakan primitif yang dioptimalkan tetapi memerlukan konfigurasi yang tepat. Ring allreduce secara teoretis mencapai komunikasi yang optimal bandwidth, tetapi implementasi nyata mengalami overhead sinkronisasi. Algoritma tree mengurangi latensi untuk pesan kecil sementara algoritma ring memaksimalkan throughput untuk transfer besar.

Kesadaran topologi jaringan meningkatkan efisiensi komunikasi secara dramatis. GPU yang terhubung melalui NVLink mencapai bandwidth bidireksional 900GB/s sementara PCIe terbatas pada 64GB/s.¹³ Strategi penempatan yang menempatkan GPU yang sering berkomunikasi pada node yang terhubung NVLink mengurangi waktu komunikasi hingga 5x. Hierarchical allreduce melakukan reduksi lokal melalui NVLink sebelum komunikasi inter-node melalui InfiniBand.

Kompresi gradien mengurangi volume komunikasi dengan biaya akurasi minimal. Mentransmisikan hanya gradien top-k atau mengkuantisasi ke INT8 mengurangi traffic 100-1000x.¹⁴ Mekanisme error feedback mengakumulasi gradien yang terpotong untuk iterasi berikutnya. Rasio kompresi bergantung pada sparsity model dan distribusi gradien. Skema adaptif menyesuaikan kompresi berdasarkan fase pelatihan, menggunakan kompresi lebih sedikit selama periode konvergensi kritis.

Tim performance engineering Introl telah mengoptimalkan lebih dari 10.000 deployment GPU di seluruh area cakupan global kami, secara konsisten mencapai 85-95% dari performa teoretis untuk workload LLM.¹⁵ Playbook optimasi kami mengurangi waktu deployment hingga 40% sambil memastikan utilisasi hardware maksimal sejak hari pertama.

Optimasi khusus inferensi

Optimasi inferensi berbeda secara fundamental dari optimasi pelatihan. Latensi lebih penting daripada throughput untuk aplikasi yang berhadapan dengan pengguna. Bandwidth memori menjadi bottleneck, bukan komputasi. Biaya serving mendominasi total pengeluaran, membuat efisiensi menjadi krusial.

Manajemen key-value cache menentukan efisiensi inferensi. Setiap generasi token membaca seluruh KV cache, mengonsumsi bandwidth memori proporsional dengan panjang sequence. PagedAttention memvirtualisasi memori KV cache, mengurangi pemborosan dari 60% menjadi di bawah 5%.¹⁶ Teknik ini memungkinkan throughput 4x lebih tinggi untuk sequence panjang. Implementasi memerlukan manajemen memory pool yang cermat dan penjadwalan request.

Kuantisasi mengurangi ukuran model dan kebutuhan bandwidth. Kuantisasi INT8 memotong penggunaan memori setengah sambil mempertahankan 99% akurasi FP16 untuk sebagian besar model.¹⁷ INT4 mencapai kompresi 4x dengan retensi akurasi 97%. Quantization-aware training menghasilkan model yang robust terhadap presisi yang dikurangi. Post-training quantization berfungsi untuk banyak model tetapi memerlukan pemilihan calibration dataset.

Continuous batching memaksimalkan throughput inferensi dengan memulai request baru segera setelah kapasitas tersedia. Static batching menunggu semua request selesai sebelum memulai yang baru, membuang resource pada sequence pendek. Continuous batching meningkatkan throughput 2,5x untuk request dengan panjang bervariasi.¹⁸ Kompleksitas implementasi meningkat karena manajemen memori dinamis dan persyaratan penjadwalan.

Hasil optimasi dunia nyata

Studi Kasus 1: Pelatihan LLM Layanan Keuangan - Model: Arsitektur kustom 70B parameter - Hardware: 64x GPU H100 - Baseline: 847 token/detik/GPU - Optimasi: Flash Attention, mixed precision, gradient accumulation - Hasil: 1.923 token/detik/GPU (peningkatan 2,27x) - Waktu pelatihan berkurang dari 18 hari menjadi 8 hari - Penghematan biaya: $240.000 per pelatihan

Studi Kasus 2: Sistem Inferensi Kesehatan - Model: Asisten medis 13B parameter - Hardware: 8x GPU A100 - Baseline: Latensi 142ms per token, throughput 820 token/detik - Optimasi: PagedAttention, kuantisasi INT8, continuous batching - Hasil: Latensi 47ms, 2.140 token/detik (throughput 2,6x) - Biaya per juta token: $0,73 → $0,28

Studi Kasus 3: Mesin Rekomendasi E-commerce - Model: Model MoE 175B parameter - Hardware: 128x GPU H100 - Baseline: 43% MFU (Model FLOPS Utilization) - Optimasi: Expert parallelism, kernel fusion, topology-aware placement - Hasil: 71% MFU (peningkatan 1,65x) - In

[Konten terpotong untuk terjemahan]