DeepSeek V4.1 Flash di vLLM vs SGLang: Arti Angkanya

Dua angka muncul di feed saya dalam sebulan: 5x dan 35 ke 873. Keduanya tentang model yang sama, DeepSeek-V4.1-Flash, dan keduanya tampak seperti jawaban atas pertanyaan engine mana yang lebih cepat. Ternyata bukan. Sebelum bisa menyimpulkan apa pun, saya harus memeriksa dulu angka itu diukur terhadap apa.

Ini adalah hasil membaca, bukan benchmark: saya tidak menjalankan kedua engine. Saya membaca post vLLM tertanggal 7 Oktober 2026, post optimisasi kernel SGLang, model card di Hugging Face, dan post vLLM AgentX sebelumnya, dan saya hanya mengutip angka yang saya lihat di halaman-halaman itu. Jika halaman saling bertentangan atau berbeda dari headline, saya sebutkan.

Apa yang membuat model ini berbeda untuk di-serve

Model card menjelaskan causal encoder-decoder dengan 40 layer: encoder 20 layer diikuti decoder 20 layer, 8B parameter aktif per token saat prefill dan 16B saat decode, memori Engram 196B parameter, serta global KV cache 890 byte per token, sekitar seperempat DeepSeek-V4-Flash. Bobotnya berlisensi MIT dan context window sampai satu juta token. Post SGLang menurunkan angka 890 itu dari entri FP4 sebesar 288 byte main KV ditambah 68 byte indexer K, yang di-pool lintas layer.

Dua konsekuensi menggerakkan semua pembahasan berikutnya. Prompt panjang sebagian besar hanya berjalan di 20 layer pertama, karena decoder mengambil global KV dari output encoder, sementara token yang dihasilkan tetap melewati ke-40 layer. Lalu KV sliding-window adalah cache FP8 terpisah yang tidak dikompresi, mencakup 128 posisi terakhir di tiap 40 layer, dan prefix caching harus menanganinya. Kedua engine menghabiskan tiga minggunya untuk dua fakta itu.

Mengapa angka headline tidak bisa dibandingkan

Kedua post menjawab pertanyaan yang berbeda. Menaruh set-up keduanya berdampingan menunjukkan bahwa satu-satunya kesamaan mereka adalah nama modelnya. Perlu dicatat juga bahwa tanggal 10 September yang saya pakai di awal adalah post day-0 LMSYS yang di-link halaman SGLang, bukan tulisan optimisasinya sendiri, yang tidak mencantumkan tanggal di halamannya.

Jadi 873 bukan angka yang lebih cepat dari 5x; keduanya sumbu yang berbeda. Angka decode batch size 1 dengan speculative decoding menunjukkan seberapa cepat satu stream bisa menghasilkan token. Angka throughput di bawah batas interactivity menunjukkan berapa banyak sesi yang bisa dilayani satu GPU. AgentX sendiri, menurut post vLLM sebelumnya, punya median input 142K token, median output 444 token, dan prefix-cache hit rate di atas 96 persen, workload yang hampir seluruhnya prefill dan reuse cache. Kecepatan decode nyaris tidak muncul di sana.

vLLM: lewati separuh model yang tidak diperlukan

Ide tunggal terbesar di post vLLM adalah SWA bounded replay, aktif secara default di balik flag --[no-]swa-bounded-replay. Saat terjadi prefix-cache hit sepanjang H, vLLM hanya meng-cache global KV dan menjalankan ulang token H dikurangi 128 sampai H untuk membangun kembali KV sliding-window, dengan window dipotong di awal replay. Di sisi decoder, layer 20 berjalan pada setiap token untuk menghasilkan global KV, sedangkan layer 21 sampai 39 hanya berjalan pada 128 token terakhir tiap request. Untuk prompt panjang, itu melewati hampir separuh model.

# vLLM: bounded replay is ON by default (per the vLLM post).
# Serve command from the model card; no other launch flags are published.
vllm serve "deepseek-ai/DeepSeek-V4.1-Flash"

# Wrong: comparing outputs across runs with replay on and expecting identical text.
# Right: turn the approximation off for regression and replay tests.
vllm serve "deepseek-ai/DeepSeek-V4.1-Flash" --no-swa-bounded-replay

# What the replay does, as described in the post (H = prefix-cache hit length):
#   encoder: cache global KV only, rerun tokens [H - 128, H) to rebuild SWA KV
#   decoder: layer 20 on every token; layers 21-39 only on the last 128 tokens
#   CUDA graphs: layers 0-20 on the full batch, 21-39 on the trimmed batch (PIECEWISE)

Layer yang dipangkas itu kecil, sehingga bila dijalankan eager mereka dibatasi biaya kernel launch, bukan compute. vLLM meng-capture layer 0 sampai 20 sebagai CUDA graph pada batch penuh dan layer 21 sampai 39 secara terpisah pada batch yang dipangkas, memakai breakable PIECEWISE graph. Dengan graph, decoder replay memangkas waktu compute prefill 30 sampai 40 persen. Tanpa graph, prompt pendek justru lebih lambat dari baseline, sampai 12 persen pada 1K token di DEP2.

Klaim TTFT juga perlu hati-hati. Ringkasan menyebut TTFT turun sekitar 30 persen dari bounded replay, sedangkan keterangan gambar menyebut hampir 70 persen pada throughput sekitar 100K dari tiga optimisasi yang digabung. Pengukurannya adalah median tiga run di GB200 dengan prefix caching mati. Saya tidak akan mengutip salah satunya tanpa menyebut yang mana.

vLLM: daftar kernel, dan jarak antara kernel dan end-to-end

Sisa gain vLLM sebagian besar berasal dari integrasi kernel fused milik DeepSeek. Tabel berikut mendaftar apa yang di-fuse tiap kernel dan efek yang dilaporkan post, dan satuannya penting: sebagian angka per kernel, sebagian per layer, sebagian end to end.

Baca baris sparse MQA dua kali. Speedup layer 14 sampai 23x pada konteks 512K terdengar revolusioner, dan ia berubah menjadi gain decode 3 sampai 6 persen secara end to end, karena layer itu hanya porsi kecil dari satu langkah decode. Ringkasan jujur tabel ini: tidak ada satu kernel pun yang menghasilkan 5x. Angka 5x adalah grafik di post tanpa data mentah di teksnya, dan ia merupakan akumulasi footprint KV yang lebih kecil, layer yang dipangkas, graph, dan banyak fusion kecil.

Pemisahan konfigurasi adalah bagian yang bisa digeneralisasi. Untuk low latency, vLLM memakai TP4 dengan attention FlashInfer; mereka mencoba MegaAttention di sana, tetapi gainnya kecil dan FlashInfer lebih cepat. Untuk high throughput mereka memakai DEP2, attention data-parallel dengan expert dibagi antar GPU, karena DP menghindari replikasi shared KV latent yang akan diduplikasi TP, dan session affinity menjaga lokalitas prefix-cache lintas turn. NVFP4 KV hampir menyetengahkan KV per request dibanding FP8, sehingga concurrency per GPU naik.

SGLang: tangga dari 35 ke 873 token per detik

Post SGLang adalah tangga kumulatif di empat GB300 dengan attention TP4, dan lebih berguna daripada headline-nya karena setiap anak tangga punya angka. Dibaca anak tangga demi anak tangga, judulnya tidak lagi berarti seperti kesan pertamanya.

Langkah 2 adalah pelajarannya. Sebagian bobot FP8 dense jatuh ke jalur yang lebih lambat karena layout block dan scale tidak cocok dengan kernel cepat, dan memperbaiki layout menaikkan build dari 35,2 ke 117,8, sekitar 3,3 kali (hitungan saya dari tabel mereka). Para penulis menyatakan memeriksa kernel mana yang sebenarnya dipanggil sebuah GEMM lebih bernilai daripada tuning tile. Sisa plain decode, langkah 3 sampai 10, menambah sekitar 1,7 kali lagi lewat fusion operasi kecil dan overlap statistik mHC di stream kedua.

Lompatan dari 203,3 ke 558,2 di langkah 11 adalah speculative decoding yang diaktifkan, bukan kernel. DSpark memakai block size 5 dengan tiga draft block, dan tabel benchmark di post itu sendiri memberi 223,50 token per detik saat mati dan 853,49 saat hidup, keduanya EP4. Anak tangga terakhir, 873,63, berasal dari memindahkan MoE dari EP4 ke TP4 dengan dimensi intermediate expert di-pad dari 576 ke 640 per GPU, gain 2,22 persen pada ronde yang sama. Jadi sebagian besar 25x di judul adalah speculation dengan accept length simulasi.

Konfigurasi yang benar-benar bisa dijalankan

Hanya SGLang yang menerbitkan launch command lengkap. Post vLLM hanya memberi satu flag dan menjelaskan TP4 dan DEP2 dalam prosa, jadi blok vLLM di bawah memakai perintah serve dari model card dan menandai sisanya sebagai celah, bukan mengarang flag. Blok SGLang disalin dari bagian reproduksi di post, beserta environment variable yang tercantum.

# vLLM: not published as commands. The post names the shapes only:
#   low latency     TP4 + FlashInfer attention
#   high throughput DEP2 (DP attention, experts split across GPUs) + session affinity
# Check your installed version's docs for the exact flags before copying anyone's.

# SGLang: reproduction block from the post (4x GB300, attention TP4).
export MODEL_PATH=/path/to/DeepSeek-V4.1-Flash
export SGLANG_RAGGED_VERIFY_MODE=static
export SGLANG_SIMULATE_ACC_LEN=5.5          # simulated accept length, NOT measured
export SGLANG_SIMULATE_ACC_METHOD=match-expected

CUDA_VISIBLE_DEVICES=0,1,2,3 PYTHONPATH="$PWD/python" MAX_JOBS=16 python -m sglang.launch_server   --model-path "$MODEL_PATH"   --served-model-name deepseek-ai/DeepSeek-V4.1-Flash   --tp 4 --ep-size 1 --trust-remote-code   --moe-a2a-backend none --moe-runner-backend flashinfer_mxfp4   --mem-fraction-static 0.80 --max-total-tokens 33554432   --chunked-prefill-size 4096   --cuda-graph-bs-decode 1 2 4 8 16 32 64   --max-running-requests 128   --speculative-algorithm DSPARK --speculative-dspark-block-size 5   --skip-server-warmup --reasoning-parser deepseek-v41   --random-seed 42 --decode-log-interval 10   --host 127.0.0.1 --port 30021
# EP4 comparison in the post: change --ep-size 1 to --ep-size 4.

Perhatikan apa yang dikunci command SGLang: random seed, max total tokens 33.554.432, chunked prefill 4.096, CUDA graph untuk decode batch size 1 sampai 64, dan accept length simulasi lewat environment variable. Hapus simulasinya dan angka 873 bukan lagi yang akan Anda lihat. Post itu juga menyatakan bahwa tidak ada hasilnya yang memakai kernel baru yang dirilis DeepSeek bersama V4.1, jadi kedua post bahkan tidak mengoptimalkan set kernel yang sama.

Di mana angka-angka ini rusak

Empat hal di sumber seharusnya mencegah Anda menyalin sebuah kesimpulan. Pertama, halaman vLLM tidak konsisten dengan dirinya sendiri: TL;DR menyebut 5,3x dengan batas 150 TPS sedangkan isi dan gambar menyebut sekitar 5x, dan batas itu tidak diulang di isi. Kedua, angka 1,9x dan 5x hanya ada di grafik, sehingga tidak bisa saya cek terhadap teks. Ketiga, tabel hasil akhir SGLang punya satu nilai accept length lebih sedikit dari jumlah kolomnya, sehingga accept length akhir ambigu. Keempat, throughput SGLang tidak menyertakan prefill penuh dan diukur dari event stream pertama sampai terakhir.

Risiko operasionalnya terpisah. Bounded replay membuat output tidak reproducible terhadap baseline yang exact. Layer Engram mengandalkan transparent huge pages untuk kernel lookup hingga 10 kali lebih cepat pada prefill, dan vLLM menambahkan fallback untuk sistem yang kekurangan huge pages, yang berarti host dengan konfigurasi memori salah diam-diam mengambil jalur lambat. Angka DSpark SGLang mengasumsikan accept length yang mungkin tidak tercapai traffic nyata: batas atasnya 6, dan prompt Anda yang menentukan nilai sebenarnya.

Kesalahan saya sendiri saat membaca adalah peringatan yang berguna. Awalnya saya mengira 35 ke 873 berarti satu engine menjadi 25 kali lebih cepat dalam serving. Itu adalah satu stream, dengan speculation, pada acceptance simulasi, dibandingkan build pertama yang punya bug layout. Setiap kualifikasi itu ada di halaman; tidak ada satu pun di judul.

Apa yang dilakukan pada hari Senin

Anda tidak perlu GB300 untuk memanfaatkan pelajaran dari post ini. Lakukan hal berikut, berurutan, pada apa pun yang Anda serve.

1. Tulis bentuk workload Anda sendiri sebelum tuning: median input, median output, prefix-cache hit rate, dan turn per sesi. AgentX menerbitkan keempatnya untuk trace-nya; angka Anda menentukan apakah decode atau prefill dan reuse cache yang penting.
2. Pastikan kernel mana yang dipanggil GEMM terbesar Anda. 3,3x di SGLang berasal dari layout yang tidak cocok, bukan dari tuning.
3. Masukkan footprint KV per token ke lembar kapasitas Anda dan hitung ulang concurrency per GPU. KV cache yang lebih kecil membeli concurrency sebelum membeli kecepatan.
4. Laporkan dua konfigurasi, bukan satu: satu low-latency dan satu high-throughput, seperti yang dilakukan vLLM dengan TP4 dan DEP2.
5. Jalankan setiap optimisasi bounded atau aproksimasi pada evaluation set Anda sendiri dengan flag hidup dan mati sebelum mengaktifkannya di production.

# bench-card.yaml: fill this in before you quote any serving number.
engine:            vllm | sglang   # exact version or commit
model:             deepseek-ai/DeepSeek-V4.1-Flash
hardware:          4x GB300        # chip, count, interconnect
parallelism:       TP4 | DEP2 | EP4
kv_dtype:          fp8 | nvfp4
speculation:       off | dspark    # if on: simulated or measured accept length?
approximations:    swa-bounded-replay on | off
workload:
  input_tokens:    4096            # SGLang: random ids, seed 42, no chat template
  output_tokens:   1024            # temperature 0, ignore_eos true
  concurrency:     1               # or the session count for an agentic trace
  prefix_cache:    cleared before each run
runs:              6               # one warm-up discarded; report the median
metric:            decode tokens/s | TPGS at P90 interactivity above 50 tok/s
excludes:          full prefill?   # SGLang measures first to last streamed event
quality_checked:   yes | no        # no means the speed number is unverified

Kartu di atas adalah template saya untuk mencatat sebuah perbandingan. Isinya menyalin field yang dikunci SGLang, karena hasil tanpa field itu tidak bisa direproduksi dan tidak bisa dibandingkan dengan post berikutnya.

Klaim speedup serving adalah klaim tentang workload, baseline, dan metrik, baru kemudian tentang engine. vLLM dan SGLang sama-sama membuat DeepSeek-V4.1-Flash cepat dalam tiga minggu lewat jalur yang membosankan: kecilkan KV cache, lewati layer yang bisa dilewati, fuse kernel kecil, dan periksa apa yang benar-benar dipanggil. Salin jalurnya, bukan angkanya.