AI-translated from English; not yet reviewed by a fluent editor.

# Jalur decode Kimi K3 di vLLM mencapai 842 token per detik dalam pengujian GB300 tertentu

> vLLM melaporkan 842 versus 488 token decode agregat per detik untuk Kimi K3 pada 16 GPU GB300 dengan pengaturan DSpark tertentu. Prefill tidak dihitung.

By BIG CHANGE Editorial

Published: 2026-10-18T20:03:34.885Z
Updated: 2026-10-18T20:03:34.885Z
Canonical: https://bigchange.ai/blog/kimi-k3-vllm-gpu-inference-benchmark

![Conceptual charcoal illustration of the rear of a generic compute cabinet with rack units and secured cables in a data-center aisle.](https://bigchange.ai/api/media/file/kimi-k3-decode-cabinet-concept-v1.png)
AI-generated conceptual illustration by BIG CHANGE; no actual GB300 chassis, vLLM installation or measured result is depicted.

vLLM telah menggabungkan jalur decode opsional khusus Kimi K3 pada GPU NVIDIA Blackwell. Dalam [penjelasannya pada 16 Oktober](https://vllm.ai/blog/2026-10-16-kimi-k3-megakernel), proyek ini melaporkan 842 token yang dihasilkan per detik dibandingkan 488 pada vLLM standar, atau peningkatan 1.73×. Perbandingan ini memiliki batas sempit: satu permintaan setiap kali, paralelisme tensor pada 16 GPU GB300, speculative decoding DSpark dengan tujuh token draf, panjang penerimaan sintetis enam, input satu token, dan output 1000 token. Angka ini mengukur throughput decode agregat setelah prefill. Ini bukan pengukuran seberapa cepat seluruh permintaan pengguna selesai.

Bagi insinyur yang memutuskan apakah akan mengevaluasi jalur ini, perkembangan yang berguna adalah gabungan hasil decode yang besar dengan penjelasan cukup tegas tentang cakupan penerapannya. [Implementasi yang telah digabungkan](https://github.com/vllm-project/vllm/pull/61867) diaktifkan secara opsional melalui `decode_backend: latency_specialized`; pengaturan bawaan `auto` tetap menggunakan decode standar. Menurut vLLM, jalur khusus ini ditujukan untuk penerapan GB300 dengan delapan atau 16 GPU dalam satu domain NVLink, sedangkan prefill, batch campuran, dan langkah yang tidak didukung kembali ke jalur forward model standar.

## Ke mana waktu terpakai

Kimi K3 merupakan model mixture-of-experts besar, menurut [kartu modelnya](https://huggingface.co/moonshotai/Kimi-K3). Saat decode, sistem penyajian berulang kali menjalankan attention, memilih pakar, dan bertukar data antar-GPU untuk menghasilkan token berikutnya. Tim vLLM membangun jalur CuTe DSL yang mengkhususkan operasi tersebut untuk bentuk tensor yang diharapkan. Penjelasannya mencakup kernel proyeksi attention berbeda untuk batch kecil dan lebih besar; penggabungan proyeksi output attention, reduksi antar-GPU, dan pekerjaan residual berikutnya; perhitungan router yang dibagi ke beberapa bagian; tumpang tindih pakar bersama dan pakar yang dirutekan; serta pengambilan awal bobot selama komunikasi. Pada jejak per lapisan yang ditampilkan, jalur khusus memakai 13 kernel dan 69 mikrodetik, sedangkan vLLM standar memakai 23 kernel dan 130 mikrodetik. Ini adalah jejak yang dilaporkan untuk pengaturan yang diperlihatkan, bukan angka latensi aplikasi.

Cakupan sama pentingnya dengan rancangan kernel. [Pull request](https://github.com/vllm-project/vllm/pull/61867) menjelaskan validasi GB300 pada TP8 dan TP16, decode non-spekulatif hingga batch 64, verifikasi DSpark dengan tiga hingga tujuh token draf, dan paralelisme konteks decode opsional. Disebutkan bahwa pekerjaan performa memakai cache KV FP8, cache SSM FP32, dan bobot penyedia model. Jalur ini tidak mengubah bobot model, penjadwalan, sampling, atau pembuat draf DSpark. Tim penyajian dapat membandingkan implementasi decode yang berubah dengan tumpukan perangkat sekitarnya yang sudah dikenal, tetapi ini juga berarti optimasi tidak mempercepat setiap bagian penyajian.

## Baca kedua tabel benchmark secara terpisah

Hasil 842 versus 488 menggunakan **TP16 pada 16 GPU GB300, batch 1, DSpark dengan tujuh token draf, panjang penerimaan sintetis enam, DL=7, ISL=1, dan OSL=1k**. vLLM menyebut metrik ini token decode agregat per detik dan tidak memasukkan prefill. Penerimaan sintetis menetapkan jumlah token usulan yang diterima benchmark; ini bukan tingkat penerimaan yang diukur dari prompt pengguna. Penerapan dengan prompt, perilaku penerimaan, ukuran batch, atau panjang input berbeda memerlukan pengukurannya sendiri.

Postingan tersebut juga menyajikan [tabel non-spekulatif](https://vllm.ai/blog/2026-10-16-kimi-k3-megakernel#decode-performance-without-speculation). Pada TP16, misalnya, dilaporkan 256.4 token per detik pada batch 1 dan 3606.1 pada batch 64, dengan peningkatan 1.88× dan 1.62× dibandingkan masing-masing konfigurasi standar. Itu adalah hasil agregat kelompok TP tanpa speculative decoding. Angka tersebut tidak dapat digabung dengan angka DSpark untuk mengklaim pengalaman per pengguna yang lebih cepat pada batch 64.

Angka lain dalam postingan berkaitan dengan [AgentX](https://vllm.ai/blog/2026-10-16-kimi-k3-megakernel#improvement-on-agentx), beban kerja yang memutar ulang pola lalu lintas agen pemrograman dengan konten sintetis. vLLM melaporkan interaktivitas P90 sebesar 403.2 versus 223.7 token per detik per pengguna pada konkurensi satu. Hasil yang dioptimalkan dijalankan pada **16 GPU GB300**, sedangkan pembanding sebelumnya dijalankan pada **delapan**. Karena jumlah GPU berubah bersamaan dengan implementasi, perbandingan 1.8× itu tidak mengisolasi peningkatan jalur decode. AgentX juga mencakup konteks lebih panjang, giliran, jeda, dan penggunaan ulang cache, sehingga metriknya menjawab pertanyaan berbeda dari benchmark decode murni.

Ada sedikit perbedaan antara postingan publik dan [tabel performa pull request sebelumnya](https://github.com/vllm-project/vllm/pull/61867): tabel tersebut mencantumkan 838 versus 489 token per detik untuk TP16, batch 1, DSpark DL7, dan penerimaan sintetis enam. Perbandingan 842 versus 488 dalam postingan menjadi sumber angka 1.73× di sini. Tabel sebelumnya merupakan bukti berguna tentang pengujian serupa, tetapi kedua pasangan angka tidak boleh dicampur. vLLM telah menerbitkan kode dan validasinya sendiri; BIG CHANGE belum mereproduksi salah satu pengujian itu.

## Apa yang diperlukan untuk evaluasi

Perbandingan lokal yang bermakna dimulai dari [PR yang telah digabungkan beserta konfigurasi yang dinyatakan](https://github.com/vllm-project/vllm/pull/61867): bobot Kimi K3 dari penyedia model yang sama, sistem GB300 dengan 16 GPU dalam satu domain NVLink, TP16, format cache, serta pengaturan DSpark persis untuk pengujian utama. Jalankan mode standar `auto` dan mode opsional `latency_specialized` pada beban kerja yang sama, lalu catat throughput decode secara terpisah dari prefill, waktu menuju token pertama, throughput output, dan latensi tingkat permintaan. Workstation atau kumpulan GPU lebih kecil tidak bisa langsung mereproduksi angka utama dengan 16 GB300. Postingan tidak menetapkan biaya sewa pengaturan tersebut.

Adapun [penjelasan validasi PR](https://github.com/vllm-project/vllm/pull/61867) melaporkan pemeriksaan numerik dan evaluasi model termasuk AIME25, GPQA-Diamond, serta pengujian MRCR konteks panjang. Penjelasan itu juga menyebut kesalahan sinkronisasi yang ditemukan saat pengembangan dan variasi dalam pengujian output panjang. Pemeriksaan ini memberi pembaca lebih banyak hal untuk ditelaah daripada grafik kecepatan, tetapi tetap merupakan bukti dari pelaksana implementasi. Tim penyajian perlu menilai apakah perangkat keras nyata, batching, panjang konteks, dan penerimaan spekulatif mereka cukup menyerupai konfigurasi yang didukung untuk membenarkan pengukuran jalur opsional ini pada lalu lintas mereka sendiri.

## Perubahan besar

Jalur Kimi K3 yang digabungkan ke vLLM menyediakan implementasi decode GPU khusus dan opsional, lengkap dengan benchmark dan rekam validasi yang terdokumentasi. Angka publik utama yang paling kuat adalah **842 versus 488 token decode agregat per detik, atau 1.73×, untuk TP16 pada 16 GPU GB300 dengan batch 1, tujuh token draf DSpark, dan panjang penerimaan sintetis enam**. Prefill tidak dihitung. Apakah ini memperbaiki layanan tertentu bergantung pada perangkat keras layanan tersebut dan keseluruhan beban kerja permintaannya.

## Sumber dan bacaan lanjutan

- [Postingan teknis vLLM pada 16 Oktober](https://vllm.ai/blog/2026-10-16-kimi-k3-megakernel) menjelaskan perubahan decode dan menyediakan pengaturan 842/488, tabel non-spekulatif, serta perbandingan AgentX. Hasilnya dilaporkan oleh proyek dan kontributor NVIDIA Benjamin Chislett.
- [Pull request vLLM #61867 yang telah digabungkan](https://github.com/vllm-project/vllm/pull/61867) mendokumentasikan pengaktifan opsional, konfigurasi yang didukung, batas implementasi, validasi, serta tabel DSpark 838/489 sebelumnya. Ini adalah rekam kode dan hasil, bukan replikasi independen.
- [Kartu model Kimi K3 dari Moonshot AI](https://huggingface.co/moonshotai/Kimi-K3) mengidentifikasi model dan bobot yang dirujuk implementasi.
- [Metodologi AgentX](https://inferencex.semianalysis.com/agentx) menjelaskan beban kerja pemutaran ulang lalu lintas di balik perbandingan interaktivitas yang terpisah.

## Sources

- [vLLM, Mengoptimalkan Kimi K3 secara Mendalam di vLLM: Bergerak Cepat dan Bertanggung Jawab (2026-10-16)](https://vllm.ai/blog/2026-10-16-kimi-k3-megakernel) — Penjelasan teknis langsung dan sumber hasil 842/488, 1.73×. Menetapkan TP16 pada 16 GPU GB300, batch 1, DSpark DL7, AL6 sintetis, ISL1, OSL1k, dan TPS decode agregat tanpa prefill. Juga menyediakan hasil non-spekulatif dan AgentX yang berbeda.
- [Pull request vLLM #61867, decode khusus Kimi K3](https://github.com/vllm-project/vllm/pull/61867) — Implementasi yang telah digabungkan dan catatan validasi oleh penulis. Mendokumentasikan pengaturan opsional akhir, konfigurasi yang didukung, dan jalur fallback. Tabel DSpark sebelumnya menyebut 838/489 pada TP16 B1 AL6 sintetis, sehingga angka itu tidak digabung dengan pasangan pada blog.
- [Moonshot AI, kartu model Kimi K3](https://huggingface.co/moonshotai/Kimi-K3) — Mengidentifikasi model dan bobot penyedia model; tidak secara independen membuktikan performa vLLM.
- [InferenceX, Metodologi dan Dataset AgentX](https://inferencex.semianalysis.com/agentx) — Menjelaskan beban kerja pemutaran ulang lalu lintas yang digunakan untuk perbandingan interaktivitas yang dilaporkan terpisah. Perbandingan vLLM juga mengubah jumlah GPU.