Artikel
Latensi Lebih Rendah dan Throughput Lebih Tinggi dengan Penerapan Multi-Node DeepSeek
Dalam kebanyakan sistem, latensi dan throughput sering kali menjadi tujuan yang bertentangan yang memerlukan kompromi selama desain dan penyebaran. Misalnya, dalam model bahasa besar yang padat, meningkatkan ukuran batch dapat meningkatkan throughput tetapi juga meningkatkan latensi; meningkatkan paralelisme tensor dalam satu mesin dapat mengurangi latensi tetapi mengurangi jumlah replikasi, yang mengarah pada throughput yang lebih rendah.
Model Mixture of Experts (MoE) seperti DeepSeek-V3/R1 baru-baru ini menunjukkan kemampuan model yang luar biasa dan efisiensi operasional. Misalnya, model DeepSeek-V3/R1 memiliki total 671B parameter, tetapi setiap token hanya menggunakan 37B parameter selama inference. Arsitektur model ini menghadirkan tantangan dan peluang bagi sistem inference.
Artikel ini menunjukkan bahwa, bertentangan dengan sistem konvensional, model MoE seperti DeepSeek-V3/R1 dapat mencapai throughput yang lebih tinggi dan latensi yang lebih rendah secara bersamaan ketika menggunakan lebih banyak GPU dalam penyebaran multi-node di sebagian besar skenario.
Arsitektur Penyebaran
Karena model memiliki banyak ahli kecil, penyebaran harus tersebar di berbagai perangkat. Kami mempertimbangkan penyebaran single-node pada satu node dengan 8xH200 GPU dan penyebaran multi-node pada 8xH100 GPU.
Kedua arsitektur penyebaran memanfaatkan Paralelisme Data, diorkestrasi melalui penjadwal permintaan internal kami. Implementasi paralelisme data melibatkan peluncuran beberapa instance mesin inferensi, masing-masing beroperasi secara independen untuk melayani dan mempertahankan permintaan. Penjadwal permintaan, yang berinteraksi dengan mesin melalui GRPC, bertanggung jawab untuk menyebarkan permintaan secara merata, sekaligus memfasilitasi penggunaan kembali KV, mengirim permintaan dengan prefiks yang cocok sebagian ke server yang mengandung cache. Instance mesin tidak melintasi beberapa node. Mereka dapat memilih untuk menggunakan paralelisme tensor untuk memecah perhatian di berbagai perangkat. Instance terhubung melalui NVLink dalam kasus satu node atau InfiniBand untuk kasus multi-node, mendistribusikan dan mengumpulkan ahli.
Konfigurasi penyebaran satu-node memberikan latensi yang unggul dengan ukuran batch kecil; namun, kinerja menurun dengan cepat di bawah kondisi beban meningkat.
Untuk menyebarkan mesin penyajian, kami meluncurkan satu pod per node yang menampung beberapa instance mesin. PyTorch bertanggung jawab untuk mengatur komunikasi terdistribusi dan merundingkan inisialisasi NVSHMEM. Untuk komunikasi, kami mengandalkan kernel CUDA kustom yang dijelaskan dalam posting blog sebelumnya. Implementasi dua penyebaran ini hampir identik, dengan model memilih kernel yang tepat untuk digunakan berdasarkan rancangan paralelisme ahli.
Teknik Paralelisasi
Sebelum terjun ke perbandingan kinerja kami, penting untuk memahami strategi paralelisasi utama yang memungkinkan diterapkannya model MoE yang besar seperti DeepSeek-V3/R1.
Paralelisme Tensor
Dalam inference LLM, Paralelisme Tensor (TP) biasanya digunakan untuk mengurangi penggunaan memori dan perhitungan per GPU, sehingga mengurangi latensi. Biasanya, kami dapat memecah Proyeksi Linear dalam Lapisan Attention dan MLP di sepanjang dimensi baris atau kolom, dan memecah operasi Attention di sepanjang dimensi kepala perhatian.
Dengan TP, arsitektur Llama-3 tidak memiliki perhitungan yang diduplikasi untuk Proyeksi Linear dan operasi Attention di seluruh GPU, yang merupakan metode pemecahan ideal. Namun, dalam model DeepSeek-V3/R1, TP tidak dapat mencapai ini.
Model DeepSeek-V3/R1 menggunakan Multi-Latent Attention (MLA). Lapisan MLA pertama menggunakan Proyeksi Linear kv_a_proj untuk menghitung vektor laten, lalu menggunakan Proyeksi Linear lainnya kv_b_proj untuk mengubahnya ke dalam ruang setiap kepala perhatian. Karena semua kepala perhatian berbagi vektor laten yang sama, TP tidak dapat memecah vektor laten, jadi semua Peringkat TP perlu mereplikasi parameter dan perhitungan dari kv_a_proj dan kv_b_proj. Demikian juga, karena MLA menyimpan vektor laten dalam Cache KV, setiap Peringkat TP menyimpan salinan identik dari Cache KV.
Meskipun ada beberapa duplikasi dalam MLA, Paralelisme Tensor masih memberikan pengurangan sebagian dalam tuntutan komputasi, membuatnya berharga untuk skenario yang membutuhkan kecepatan keluaran yang tinggi.
Paralelisme Ahli
Model DeepSeek-V3/R1 menggantikan Lapisan MLP dengan Lapisan MoE. Lapisan MoE memiliki 256 ahli terarah dan satu ahli bersama. Setiap token dikirim ke 8 ahli terarah untuk komputasi, dan hasilnya dijumlahkan secara berbobot. Setiap token juga dihitung dalam ahli bersama, dan hasilnya ditambahkan ke hasil dari ahli terarah.
Paralelisme Ahli (EP) berfungsi sebagai pendekatan pemecahan khas untuk Lapisan MoE, dengan masing-masing GPU mengelola 256 / EP ahli terarah sambil mempertahankan salinan ahli bersama. Dibandingkan dengan TP, keuntungan EP adalah bahwa ia dapat mendistribusikan perhitungan ke lebih banyak GPU, mengurangi penggunaan komputasi dan memori per GPU.
Sebelum melakukan perhitungan ahli, semua GPU perlu melakukan komunikasi AllToAll untuk mengirimkan token ke GPU tempat para ahli yang sesuai berada; setelah perhitungan ahli, komunikasi AllToAll lain diperlukan untuk mengumpulkan hasil perhitungan dari berbagai GPU dan melakukan penjumlahan berbobot. Kami telah mengimplementasikan versi yang dioptimalkan dari dua Kernel komunikasi AllToAll ini, Dispatch dan Combine, menggunakan NVSHMEM. Dalam posting blog kami sebelumnya, kami merinci implementasi, dan kernel kami telah dibuka sumber di GitHub.
Paralelisme Data
Dengan EP, kami dapat mendistribusikan komputasi MoE di lebih dari 128 atau lebih GPU. Namun, komputasi MLA tidak dapat dipartisi dengan EP. Pada titik ini, kami dapat memperkenalkan Paralelisme Data (DP). Setiap Kelompok DP memiliki salinan lengkap dari Lapisan MLA. Setiap Kelompok DP menerima input yang berbeda dan melakukan komputasi Lapisan MLA secara independen.
DP dan TP lapisan MLA dapat digabungkan, dengan satu Kelompok DP dibagi menjadi beberapa Peringkat TP. EP lapisan MoE dapat digabungkan dengan DP/TP lapisan MLA. EP = DP * TP. Sebagai contoh, pada 16 mesin, EP128 DP32 TP4 berarti mendistribusikan ahli terarah di 128 GPU, dengan setiap 4 GPU membentuk Kelompok DP, untuk total 32 Kelompok DP independen.
Satu-Node vs Multi-Node
Parameter 671B milik DeepSeek melebihi kapasitas memori satu mesin H100 8-GPU (80 GB * 8), tetapi mesin H200 8-GPU dapat sepenuhnya menampung seluruh model (141 GB * 8). Menggunakan konfigurasi EP8 DP8 TP1, model menggunakan sekitar 100 GB memori per GPU, menyisakan sekitar 40 GB untuk Cache KV dan hasil perantara lainnya. Satu token menduduki 70.272 byte dari Cache KV. Dengan asumsi setiap permintaan memiliki 5.000 token, setiap GPU dapat menampung sekitar 100 permintaan.
Kami ingin memahami perbedaan kinerja antara penyebaran satu-node dan multi-node di bawah konfigurasi yang berbeda. Kami menggunakan satu mesin H200 untuk penyebaran satu-node dan hingga 16 mesin H100 untuk penyebaran multi-node. Untuk setiap lingkungan penyebaran, kami menggunakan kombinasi TP 1, 2, 4, 8, dan ukuran batch per GPU dari 1, 2, 4, 8, 16, 32, 64, 128. Kami menganggap setiap permintaan memiliki panjang Cache KV 5.000 token. Kami juga menganggap Prediksi Multi-Token (MTP) meramalkan 1 token tambahan (yaitu, panjang kueri setiap permintaan adalah 2), dan dengan hati-hati menganggap tingkat penerimaan 60%. Gambar di bawah ini menunjukkan throughput dan kecepatan keluaran untuk berbagai konfigurasi.
Sumbu horizontal mewakili kecepatan keluaran per permintaan dalam token/s. Sumbu vertikal menggunakan skala logaritmik untuk menunjukkan throughput per mesin dalam token/s. Kami menandai Pareto Frontier untuk setiap konfigurasi EP dengan garis berwarna berbeda.
Dalam skenario dengan persyaratan kecepatan keluaran ekstrem tinggi, menggunakan single-node EP8 DP1 TP8 dengan ukuran batch 1 dapat mencapai kecepatan keluaran melebihi 100 token/s, tetapi throughputnya sangat rendah, setara dengan kecepatan keluaran. Dalam skenario ini, seluruh batch hanya memiliki 2 token, yang dapat dikirim ke paling banyak 2*8=16 ahli, mengaktifkan total paling banyak 57B parameter.
Dalam rentang kecepatan keluaran 80-40 token/s, seiring dengan peningkatan throughput, kecepatan keluaran menurun secara signifikan. Sebaliknya, EP128 memiliki throughput sekitar 5x lebih tinggi daripada penyebaran satu-node pada kecepatan keluaran yang sama.
Fenomena ini dapat dijelaskan dengan memeriksa bagaimana penyebaran satu-node berperilaku: peningkatan ukuran batch berhubungan langsung dengan peningkatan ahli yang diaktifkan. Ketika ukuran batch adalah 1, jumlah rata-rata ahli yang diaktifkan per GPU adalah 2 * 8 / 8 = 2. Ketika batch sudah cukup besar, semua ahli teraktifkan, artinya setiap GPU mengaktifkan 256 / 8 = 32 ahli. Mengaktifkan lebih banyak ahli berarti GPU perlu membaca lebih banyak parameter dari memori, secara signifikan meningkatkan tekanan bandwidth memori. Karena fase decode dari model bahasa besar sudah terhambat oleh bandwidth memori daripada kinerja komputasi, meningkatkan ukuran batch dalam penyebaran satu-node secara signifikan mengurangi kecepatan keluaran.
Perbandingan dari empat konfigurasi penyebaran multi-node (EP16, EP32, EP64, dan EP128) mengungkapkan bahwa nilai EP yang lebih tinggi menggeser Pareto Frontier menuju peningkatan throughput dan kecepatan keluaran secara bersamaan.
Menggunakan nomor EP yang lebih tinggi berarti setiap GPU dialokasikan lebih sedikit ahli. Misalnya, EP128 berarti setiap GPU bertanggung jawab atas 256 / 128 = 2 ahli, sehingga tekanan bandwidth memori berkurang secara signifikan. Dengan kata lain, dengan menggunakan nomor EP yang lebih besar, kita efektif mendapatkan lebih banyak bandwidth memori. Ketika ukuran batch per-GPU kurang dari 64, meningkatkan ukuran batch tidak secara signifikan memengaruhi kecepatan perhitungan ahli karena peningkatan jumlah input tidak secara signifikan meningkatkan tekanan bandwidth memori. Oleh karena itu, kami mengamati bahwa ketika menggunakan EP128, meningkatkan ukuran batch tidak mempengaruhi kecepatan keluaran secara signifikan.
Menariknya, pada ukuran batch yang lebih besar (64 permintaan per GPU), kami mengamati fenomena baru: throughput penyebaran satu-node sedikit lebih tinggi daripada penyebaran multi-node. Sebagian alasannya adalah karena NVLink intra-node memiliki bandwidth lebih tinggi daripada InfiniBand antar-node. Bagian lainnya disebabkan oleh keterbatasan dalam implementasi kami. Kami akan menganalisis fenomena ini lebih lanjut nanti.
Karena keterbatasan kapasitas memori, konfigurasi EP8 DP8 TP1 tidak dapat mencapai ukuran batch 128 per GPU, sehingga penyebaran multi-node masih menjadi pilihan yang lebih baik dalam skenario yang mengejar throughput yang lebih tinggi.
Overlapping Perhitungan dan Komunikasi
Seperti yang telah dibahas sebelumnya mengenai Paralelisme Ahli, GPU menganggur selama komunikasi Lapisan MoE. Untuk mengurangi pemborosan waktu dan mengurangi latensi, kita perlu menemukan tugas perhitungan data-independent untuk mengisi waktu senggang ini.
Bagian atas dari gambar di atas menunjukkan alur perhitungan satu lapisan. Perhitungan MoE tergantung pada Dispatch, dan komputasi lapisan berikutnya tergantung pada hasil Combine.
Kami menempatkan ahli bersama di setiap GPU. Dengan cara ini, perhitungan ahli bersama tidak memerlukan komunikasi AllToAll. Oleh karena itu, kami dapat melakukan perhitungan ahli bersama segera setelah kiriman Dispatch, lalu menunggu penerimaan Dispatch selesai. Kami menyebut skema overlap ini "Dispatch Overlap".
Dispatch Overlap menawarkan implementasi yang mudah dan broad applicability. Teknik ini menyembunyikan waktu perhitungan ahli bersama di semua ukuran EP dan ukuran batch.
Untuk lebih meningkatkan overlapping perhitungan dan komunikasi, kami menggunakan micro batching yang disebutkan dalam laporan teknis DeepSeek untuk memecah data dependency. Seperti yang ditunjukkan di bagian bawah pada gambar, kami membagi perhitungan satu Lapisan Transformer menjadi 5 tahap:
Tahap 1: InputNorm, QKVProj, AppendKV, BMM
Tahap 2: BMM, Attn, OProj, PostNorm, Gate
Tahap 3: Kiriman Dispatch, Ahli Bersama
Tahap 4: Penerimaan Dispatch, MoE, Kiriman Kombinasi
Tahap 5: Penerimaan Kombinasi
Dalam tiga Lapisan Transformer Padat pertama, kami menggunakan seluruh batch. Dalam 58 Lapisan Transformer MoE berikutnya, kami membagi batch secara merata menjadi dua mikro batch. Kedua mikro batch dieksekusi secara bergantian, dengan offset 3 tahap. Oleh karena tidak ada data dependency antara kedua mikro batch ini, kami dapat beralih ke perhitungan mikro batch lain setelah Kiriman Dispatch dan setelah Kiriman Kombinasi.
Pembagian Latensi
Selanjutnya, kami membandingkan efek overlapping melalui percobaan, serta membandingkan perbedaan kinerja antara penyebaran satu-node EP8 dan penyebaran multi-node EP128. Untuk kemudahan perbandingan, kami menggunakan GPU H100 untuk percobaan berikut. Kami menggunakan TP1, ukuran batch 128 per GPU, Panjang Kueri 2 per permintaan, dan Panjang Cache KV 5000.
Gambar di atas menunjukkan total waktu yang dihabiskan untuk satu Lapisan Transformer MoE dan proporsi latensi dari jenis kernel yang berbeda. Kecuali untuk Dispatch, Combine, dan GroupGEMM, waktu eksekusi kernel lainnya harus sama pada seri EP8, EP128 NoOverlap, dan EP128 DispatchOverlap karena ukuran batchnya sama.
Overlapping
Marilah kita pertama membandingkan efek dari tiga metode overlapping. NoOverlap memerlukan waktu total 2667µs, DispatchOverlap memerlukan 2651µs, menghemat 16µs atau hanya 0.6%. MicroBatch menunjukkan peningkatan yang sangat signifikan, hanya memerlukan waktu 1896µs, peningkatan kecepatan sebesar 29%. Waktu untuk Dispatch dan Combine berkurang secara signifikan. Dispatch berkurang dari 593µs menjadi 367µs, dan Combine dari 1012µs menjadi 237µs.
Perhatikan bahwa untuk kernel komputasi, membagi batch berukuran 128 menjadi dua batch ukuran 64 meningkatkan total waktu eksekusi. Oleh karena itu, meskipun waktu komunikasi berkurang 1001µs, total waktu hanya berkurang 771µs. Kami akan menjelaskan alasannya menggunakan model Roofline pada bagian berikut.
Karena alasan ini, mikro batching tidak selalu meningkatkan kinerja.
Gambar di atas menunjukkan peningkatan kinerja Microbatch dibandingkan dengan DispatchOverlap untuk ukuran batch 4-128. Ketika ukuran batch kurang dari 32, Microbatch mengurangi kinerja sebesar 5%-40%. Ketika ukuran batch lebih besar dari atau sama dengan 32, Microbatch dapat meningkatkan kinerja sebesar 10%-35%.
EP8 vs EP128
Marilah kita kembali ke gambar sebelumnya dan membandingkan EP8 dan EP128 Microbatch. EP8 memerlukan total 1802µs, sedikit kurang dari EP128 1896µs. Selain peningkatan waktu eksekusi kernel yang dibawa oleh Microbatch yang disebutkan di atas, perbedaan utama ada pada GroupGEMM yang digunakan untuk komputasi MoE, dan dua kernel komunikasi, Dispatch dan Combine.
GroupGEMM EP8 memerlukan 555µs, sedangkan GroupGEMM EP128 memerlukan 270µs, berkurang setengahnya. Ini adalah keunggulan inti dari penyebaran multi-node.
Sayangnya, waktu yang dihabiskan untuk komunikasi meningkat sebesar 213µs, yang sangat mengimbangi keunggulan dari GroupGEMM. Dalam tes performa terpisah dari kernel komunikasi kami, kami menemukan bahwa mereka hanya dapat mencapai setengah dari bandwidth Infiniband. Kami akan terus mengoptimalkan kernel komunikasi kami.
Kernel lain yang tertinggal secara signifikan adalah GEMM. Mikro batching meningkatkan GEMM sebesar 95µs. Kami akan menganalisis GEMM lebih mendalam pada bagian berikut menggunakan Model Roofline. Kami percaya bahwa implementasi GEMM saat ini belum mencapai kinerja optimal.
Roofline
Model Roofline adalah alat yang baik untuk menganalisis kinerja kernel. Sumbu horizontalnya adalah Intensitas Aritmatik, rasio antara FLOP dan byte I/O memori. Nilai sumbu horizontal dapat dihitung langsung dari semantik kernel. Sumbu vertikal mewakili kinerja yang dicapai, dihitung dengan membagi FLOP dengan latensi benchmark.
Batas atas teoritis kinerja kernel ditentukan langsung oleh spesifikasi GPU. Kinerja puncak FP8 H100 adalah 1979 TFLOP/s, direpresentasikan sebagai garis horizontal dalam model Roofline. Bandwidth memori H100 adalah 3.35 TB/s, direpresentasikan sebagai kemiringan garis yang melewati titik asal. Kedua garis tersebut memberikan batasan kinerja untuk kernel yang terikat komputasi dan memori, masing-masing.
Di bawah ini, kami akan membahas kinerja dari kernel GroupGEMM dan GEMM.
GroupGEMM
Kernel GroupGEMM dalam MoE melakukan perhitungan berikut: Ada g grup secara keseluruhan, grup ke-i memiliki m_i token, melakukan perkalian matriks [m_i, k] x [k, n] -> [m_i, n]. Dalam pengujian kinerja, kami menganggap jumlah token dalam setiap grup sama, dinyatakan sebagai m_i = m. Kemudian hitungan FLOP untuk GroupGEMM adalah 2 * g * m * k * n, dan byte I/O memori adalah g * (m * k + n * k + m * n).
Dalam model DeepSeek-V3/R1, ada 256 ahli, dan setiap token dikirim ke 8 ahli untuk dikomputasi. Dengan asumsi ukuran batch 128, panjang kueri 2, menggunakan konfigurasi EP128 DP128, rata-rata jumlah token yang diterima oleh setiap ahli (yaitu, m) adalah 128 * 2 * 8 * 128 / 256 = 1024. Begitu juga, kami dapat menghitung m untuk konfigurasi dan ukuran batch lainnya.
Kami menggunakan implementasi GroupGEMM dari DeepGEMM untuk pengujian kinerja. Titik uji meliputi kombinasi konfigurasi EP8, EP16, EP32, EP64, EP128 dengan TP1 dan ukuran batch 1-128.
Gambar di atas menunjukkan model Roofline untuk GroupGEMM di bawah konfigurasi EP yang berbeda. EP yang berbeda sesuai dengan jumlah grup yang berbeda. Gambar tersebut menggambarkan garis kinerja yang hampir tumpang tindih, menunjukkan bahwa kinerja GroupGEMM terutama ditentukan oleh jumlah total token (diwakili sebagai g * m).
Bintang menandai titik data yang sesuai dengan ukuran batch 128 per GPU untuk setiap konfigurasi EP. Dengan membandingkan titik data berbintang ini, kami dapat melihat bahwa seiring dengan peningkatan EP (dan DP meningkat secara sinkron), jumlah token per ahli m juga meningkat. Pada EP8, m=128, sedangkan pada EP128, m=2048.
Saat m meningkat, Intensitas Aritmatika juga meningkat. Dalam sebagian besar konfigurasi, GroupGEMM dibatasi oleh bandwidth memori, sehingga peningkatan m meningkatkan kinerja.
GEMM
Kernel GEMM berhubungan dengan Proyeksi Linear dalam model, seperti Proyeksi Q/K/V/O. Untuk perkalian matriks [m, k] x [k, n] -> [m, n], hitungan FLOP adalah 2 * m * k * n, dan byte I/O memori adalah m * k + n * k + m * n. Kami juga dapat memeriksa latensi untuk ukuran batch 1-128.
Gambar di atas menunjukkan model Roofline untuk GEMM di bawah konfigurasi EP yang berbeda. Kami dapat melihat bahwa kinerja GEMM dibatasi oleh bandwidth memori. Seiring dengan peningkatan ukuran batch, Intensitas Aritmatika juga meningkat, sehingga meningkatkan kinerja.
Microbatch
Saat menggunakan mikro batching, kami membagi batch secara merata menjadi dua bagian. Dari dua gambar di atas, kita dapat melihat bahwa ketika m menjadi m/2, efisiensi dari perkalian matriks menurun. Oleh karena itu, melakukan dua perkalian matriks ukuran m/2 memakan waktu lebih lama daripada melakukan satu perkalian matriks ukuran m.
Prediksi Multi-Token
Sepanjang artikel ini, kami telah menganggap penggunaan Prediksi Multi-Token (MTP) untuk decoding spekulatif. MTP mengubah panjang kueri per permintaan dari 1 menjadi 2. Untuk perkalian matriks, ini setara dengan mengubah m menjadi m * 2, sehingga meningkatkan efisiensi perkalian matriks. Di sisi lain, jika kita menggambar model Roofline untuk MLA, kita akan menemukan bahwa peningkatan panjang kueri secara signifikan meningkatkan efisiensi kernel MLA.
Oleh karena itu, penggunaan MTP memainkan peran penting dalam efisiensi model.
Implementasi & Optimasi
Di bagian ini, kami akan memperkenalkan beberapa detail implementasi dan optimasi untuk model DeepSeek-V3/R1 kami.
Kuantisasi
DeepSeek-V3/R1 dilatih secara native pada FP8 menggunakan skema kuantisasi per-blok, dengan bobot dikuantisasi secara statis dan aktivasi dikuantisasi secara khusus. Sebagai pengganti menghitung faktor skala per saluran atau per matrix secara statis, faktor skala dihitung di seluruh vektor elemen 128 untuk aktivasi dan 128x128 elemen bagi matriks, membatasi degradasi akurasi akibat kuantisasi.
Di Perplexity, kami mengandalkan campuran kernel CUDA dan Triton untuk mendukung inference, dengan CUDA digunakan untuk kernel yang paling sensitif terhadap kinerja dan jarang dimodifikasi (seperti perhatian dan GEMM), dengan Triton mengimplementasikan berbagai kernel aktivasi, normalisasi, dan utilitas. Triton memungkinkan kami untuk dengan cepat menyesuaikan kernel ke skema kuantisasi blok.
Untuk lapisan linear dan MoE, kami mencampur kernel Deep GEMM dengan kernel Triton GEMM kami sendiri, karena kami telah memperhatikan bahwa untuk dimensi matriks tertentu dan ukuran batch rendah, Split-K memberikan latensi lebih rendah. Jika lapisan yang tidak dikuantisasi melakukan perkalian (M, K) x (K, N), ia membutuhkan (M x ceil_div(K, 128)) x (ceil_div(K, 128), ceil_div(N, 128)) faktor skala untuk kuantisasi blok. Untuk kuantisasi blok, faktor skala untuk aktivasi dihitung secara on-the-fly, alih-alih dikalibrasi sebelumnya. Karena faktor skala aktivasi diakumulasi hanya di sepanjang K dan tidak di sepanjang dimensi M, kernel memerlukan penyesuaian sedikit untuk mendukung skema tersebut.
Fungsi aktivasi SiLU yang digunakan oleh DeepSeek-V3/R1 memerlukan perubahan substansial untuk mendukung grafik CUDA, kuantisasi blok, dan jumlah token yang diarahkan secara dinamis. Kuantisasi blok dapat menjadi masalah karena memperkenalkan reduksi horizontal, namun kernel sudah membagi aktivasi di sepanjang dimensinya menjadi blok-blok elemen 1024. Di dalam satu blok, tensor yang akan dikuantisasi lebih lanjut dibagi menjadi blok-blok elemen 128 untuk menghitung nilai absolut terbesar, dengan Triton menghasilkan reduksi maximum cross-warp yang efisien, menambahkan overhead minimal.
Untuk mendukung routing MoE di bawah grafik CUDA, kernel harus menyadari informasi routing yang menunjukkan jumlah token per ahli, alih-alih menjadwalkan pekerjaan berdasarkan ukuran buffer yang dialokasikan untuk menampung batas atas dari jumlah token. Kami tidak dapat membagi masalah berdasarkan pada dimensi tensor input, sehingga kami meluncurkan sejumlah tetap dari kernel persisten yang membaca informasi routing untuk menentukan berapa banyak token yang diisi dan membagi pekerjaan memproses aktivasi di antara mereka secara dinamis.
Kami telah menaikkan beberapa kernel kami ke proyek FlashInfer dan di masa depan kami akan membuka-sumberkan lebih banyak kode kami.
Lapisan MLA
Kami menggunakan FlashInfer untuk komputasi MLA. FlashInfer mendukung Pengaturan Tabel Halaman yang fleksibel dan kinerja yang sangat tinggi.
Kami menggabungkan q_a_proj dan kv_a_proj menjadi satu qkv_a_proj. Latensi menurun dari 15.4 µs + 14.8 µs = 30.2 µs menjadi 16.7 µs.
Kami memecah kv_b_proj menjadi dua matriks, k_b_proj dan v_b_proj. Kami menulis kernel BMM Yang Diklarifikasi Blok FP8 untuk hitungan terkait dengan kedua matriks ini.
Cuda Graph
Cuda Graph dapat secara signifikan mengurangi overhead peluncuran kernel, yang sangat penting untuk kinerja. Kami membuat Cuda Graph untuk setiap ukuran batch.
Sebelum mengembangkan Kernel AllToAll kami, kami menggunakan torch.all_to_all_single() untuk komunikasi AllToAll. Operasi ini mengharuskan semua GPU menggunakan ukuran batch yang sama. Namun, grup DP yang berbeda mungkin menjalankan ukuran batch yang berbeda.
Untuk memastikan all_to_all_single() kompatibel dengan berbagai grup DP yang menggunakan ukuran batch yang berbeda, terlebih dahulu kami menggunakan operasi allreduce() sebelum setiap operasi model untuk mendapatkan ukuran batch maksimum di antara semua grup DP. Kemudian kami membuat semua grup DP menggunakan ukuran batch ini untuk dijalankan.
Walaupun pendekatan ini memastikan bahwa kita dapat menggunakan Cuda Graph, ia memiliki tiga kelemahan. Pertama, ia memerlukan operasi allreduce() tambahan. Kedua, grup DP dengan ukuran batch yang lebih kecil dipaksa untuk menambah. Ketiga, ini membuat kode implementasi kami menjadi kompleks.
Setelah mengimplementasikan Kernel AllToAll kita sendiri, kami tidak lagi memerlukan semua GPU untuk menggunakan ukuran batch yang sama. Oleh karena itu, kita tidak lagi perlu melakukan operasi allreduce() tambahan atau menambah ukuran batch.
Router MoE
Router MoE diimplementasikan dalam Triton, mengandalkan modifikasi derivasi dari pustaka standar yang juga melacak indeks elemen yang disorting. Implementasinya dibagikan di semua model MoE, karena routing Mixtral adalah kasus khusus dari rute DeepSeek di mana grup Top-K sama dengan grup semua ahli. Kernel sparse mengonsumsi indeks dan skor Top-K secara langsung, sedangkan skema dispatch/combine yang padat mengandalkan all-to-all memerlukan informasi routing untuk diakumulasikan per ahli, bukan atas dasar per token.
Pekerjaan Masa Depan
Dalam pekerjaan masa depan, kami berencana untuk lebih mengoptimalkan kinerja model DeepSeek.
Optimasi berikutnya yang paling penting adalah Penyebaran Prefill. Fase Prefill dan fase Dekode dari model DeepSeek-V3/R1 memiliki karakteristik komputasi yang sangat berbeda. Keduanya dapat menggunakan strategi optimasi dan skema penyebaran yang berbeda.
Untuk Lapisan MLA, dalam fase Decode, kami menggunakan Absorpsi Matriks untuk mengurangi hitungan FLOP dari komputasi MLA. Dalam fase Prefill, pertama-tama memproyeksikan vektor laten ke dalam ruang K/V kemudian menghitung dalam bentuk Multi-Head Attention (MHA) akan bekerja lebih baik.
Jika Prefill dan Decode berjalan di GPU yang sama, untuk mengurangi dampak Prefill pada kecepatan keluaran Decode, kami biasanya menggunakan Prefill terpecah untuk membagi kueri menjadi beberapa bagian untuk Prefill. Karena Cache KV menyimpan vektor laten, menjadi sulit untuk mengonversi MLA menjadi bentuk MHA.
Untuk Lapisan MoE, dalam fase Decode, kami menggunakan EP dan DP sebesar mungkin untuk meningkatkan jumlah token input per ahli, sehingga meningkatkan kinerja GroupGEMM. Pada fase Prefill, karena jumlah token sudah cukup besar, GroupGEMM sudah dibatasi komputasi. Oleh karena itu, untuk Prefill, kami dapat menggunakan EP dan DP yang lebih kecil.
Jika Prefill dan Decode berjalan di GPU yang sama, selama ada Kelompok DP yang melakukan Prefill, latensi dari Lapisan MoE pada semua GPU akan meningkat, secara signifikan mempengaruhi kecepatan keluaran Decode.
Selain Penyebaran Prefill, kami juga merencanakan untuk mengoptimalkan aspek berikut:
Performa AllToAll: Kernel AllToAll kami saat ini hanya dapat mencapai 1/3 dari bandwidth Infiniband. Kami akan terus mengoptimalkan kernel ini.
Decoding Spekulatif gaya EAGLE: Dalam data di atas, kami mengasumsikan menggunakan decoding spekulatif untuk memprediksi 1 token. EAGLE dapat menggunakan struktur pohon untuk memprediksi banyak token, meningkatkan panjang penerimaan, yang dapat secara signifikan meningkatkan kecepatan keluaran.
Kernel GEMM: Dalam Model Roofline yang ditunjukkan sebelumnya, kami dapat menemukan bahwa efisiensi dari kernel GEMM masih jauh dari batas teoritis. Kami akan terus mengoptimalkan kernel ini.
GB200 NVL72: Dalam solusi GB200 NVL72 terbaru dari NVIDIA, 72 GPU Blackwell dihubungkan melalui NVLink berkecepatan tinggi. Bagi model arsitektur MoE, ini adalah peluang dan tantangan yang sangat besar.
Kesimpulan
Penyebaran multi-node model MoE DeepSeek mencapai apa yang biasanya mustahil dengan LLM padat: meningkatkan throughput dan latensi secara bersamaan. Dengan mendistribusikan ahli di lebih banyak GPU, kami mengurangi tekanan bandwidth memoriper perangkat, memungkinkan pemrosesan lebih cepat dan throughput sistem yang lebih tinggi. Percobaan kami menunjukkan konfigurasi EP128 mencapai hingga 5x throughput lebih tinggi pada kecepatan keluaran yang setara dibandingkan dengan penyebaran satu-node.
Teknik overlapping perhitungan-komunikasi seperti micro-batching secara signifikan mengurangi overhead komunikasi multi-node, dengan implementasi kami menunjukkan peningkatan kecepatan hingga 40%. Kernel komunikasi AllToAll kustom kami dan implementasi kernel yang dioptimalkan telah memungkinkan penyebaran model parameter 671B yang efisien.
Seiring dengan meningkatnya popularitas arsitektur MoE karena kemampuannya, strategi penyebaran ini memberikan wawasan berharga untuk skala model seperti itu secara efisien.