Mesin Inferensi DeepSeek: 5 Mitos, Kita Uji

Ketika DeepSeek mengunggah mesin inferensi LLM produksinya ke GitHub dengan lisensi Apache 2.0, repo-nya langsung mengumpulkan ribuan bintang dalam hitungan jam. Itu tidak mengejutkan. Yang memang mengejutkan adalah isi di dalamnya. DeepInfer bukan mainan riset atau demo yang dipangkas. Menurut pernyataan DeepSeek sendiri, mesin ini melayani DeepSeek-V4.1-Flash dengan klaim skala 155 triliun token per hari per klaster, dengan pendapatan sekitar $38 per jam GPU pada harga di luar jam sibuk. Angka-angka ini, kalaupun hanya kurang lebih akurat, berasal dari keputusan rekayasa yang oleh sebagian besar industri masih dianggap sebagai folklor. Jadi mari kita lakukan apa yang akan saya lakukan terhadap sistem produksi open-source yang baru rilis: baca README dengan kacamata skeptis dan uji keyakinan umum tentang mesin inferensi terhadapnya.

Mitos 1: Mesin inferensi hanyalah forward pass yang cepat

Model mental yang naif kira-kira begini: modelnya ya modelnya, mesinnya cuma pembungkus tipis yang memanggil kernel, dan performa datang dari membeli GPU yang lebih cepat. Daftar fitur DeepInfer sendiri langsung mematahkan anggapan ini. Lihat apa saja yang dianggap layak dikirim: asynchronous scheduling dengan "zero-overhead batch scheduler", speculative decoding dengan verifikasi terjadwal berbasis confidence, sliding-window-attention bounded replay, batch-invariant inference, deterministic sampling, dan structured output yang dibatasi oleh regex, skema JSON, atau grammar EBNF. Itu adalah scheduler, manajer memori, sistem verifikasi, dan compiler constraint sekaligus. Kernel hampir terasa seperti pemikiran belakangan dalam daftar ini.

Ini sejalan dengan hal yang terus dipelajari ulang oleh para praktisi. Forward pass adalah bagian yang paling mudah; masalah ini pada dasarnya sudah terselesaikan sejak FlashAttention dan library GEMM yang bagus. Bagian yang sulit adalah menjaga agar GPU tetap terisi. Setiap milidetik SM menganggur selagi CPU memutuskan request mana yang diterima, blok KV mana yang dikeluarkan, atau draft token mana yang diverifikasi adalah uang yang menguap. Async scheduler DeepInfer ada persis untuk menumpangtindihkan penjadwalan CPU dengan eksekusi di device, sehingga GPU tidak pernah menunggu Python. Kalau stack penyajianmu masih menjadwalkan secara sinkron, perubahan tunggal itu kemungkinan bernilai lebih dari pergantian kernel mana pun yang sedang kamu rencanakan.

README juga memuat pengakuan yang menarik: layanan inferensi yang lengkap masih membutuhkan sistem KV cache, prefill/decode disaggregation, dan load balancing antar replika data-parallel, yang semuanya tidak disertakan. Dengan kata lain, bahkan mesinnya sendiri hanyalah satu lapisan dari sistem yang sebenarnya. Inferensi produksi adalah masalah sistem terdistribusi yang mengenakan kostum machine learning. Ini poin yang pernah kami bahas tentang agen LLM yang sangat mirip sistem terdistribusi, dan berlaku sama besarnya satu lapisan lebih ke bawah di tumpukan.

Mitos 2: Batch yang lebih besar selalu lebih baik

Continuous batching, yaitu memasukkan request baru ke dalam batch begitu request lain selesai alih-alih menunggu seluruh batch, sekarang sudah menjadi standar minimum, dan DeepInfer jelas melakukannya. Tapi keyakinan yang lebih menarik untuk diuji adalah versi cerobohnya: "throughput naik seiring ukuran batch, jadi maksimalkan batch-nya." DeepInfer mengirim dua fitur yang justru ada karena anggapan itu salah.

Pertama, batch-invariant inference (DEEPINFER_BATCH_INVARIANT=1). Biasanya, output sebuah request bisa bergeser tergantung apa lagi yang kebetulan ada di batch-nya, karena urutan reduksi di kernel berubah mengikuti komposisi batch dan penjumlahan floating-point tidak bersifat asosiatif. DeepSeek menganggap layak untuk berinvestasi dalam rekayasa agar hasilnya identik di berbagai komposisi batch. Kenapa? Karena begitu melayani dalam skala besar, kamu akan menemukan bahwa pelanggan dan pipeline evaluasi menyadari ketika prompt yang sama menghasilkan token berbeda di hari yang berbeda. Jika memaksimalkan ukuran batch berarti menerima nondeterminisme, DeepSeek memilih mengorbankan throughput untuk mendapatkan kembali determinisme. Itu menunjukkan bahwa fungsi tujuan yang sebenarnya bukan sekadar token per detik mentah, melainkan token per detik yang bisa dipercaya.

Kedua, confidence-scheduled verification untuk speculative decoding. Engine membuat draft token (panjang draft maksimum default 5) dan menggunakan estimasi confidence untuk memutuskan seberapa banyak kerja verifikasi yang dijadwalkan. Pendekatan naif memverifikasi draft dengan panjang tetap di setiap langkah; pendekatan pintar mengakui bahwa jumlah kerja spekulatif yang optimal bervariasi per request dan per langkah. Membatch lebih banyak kerja spekulatif daripada yang dijamin confidence hanya membuang compute untuk token yang nantinya dibuang. Membatch lebih sedikit berarti melewatkan speedup. Scheduler ini memecahkan masalah optimasi di setiap langkah, bukan sekadar menjejalkan request bersama-sama.

• Ukuran batch menaikkan throughput tapi juga latensi — time-to-first-token memburuk seiring membesarnya batch prefill.
• Komposisi batch mengubah numerik — kecuali kamu membayar untuk kernel batch-invariant, output akan bergeser.
• Kerja spekulatif punya hasil yang semakin menurun — tingkat penerimaan draft turun seiring panjang draft, jadi jadwal tetap membuang FLOP.
• KV cache adalah batas sebenarnya — batch tidak bisa tumbuh melebihi apa yang bisa ditampung memori, itulah sebabnya tata letak memori lebih penting daripada kebijakan batch.

Mitos 3: Manajemen KV cache sudah menjadi masalah yang terselesaikan

PagedAttention mempopulerkan pendekatan ala OS: alokasikan KV cache dalam halaman berukuran tetap, bagikan seperti memori virtual, dan berhenti terfragmentasi. vLLM membuktikan bahwa ini bekerja, dan DeepInfer, menurut pengakuannya sendiri, awalnya dibangun terutama di atas vLLM. Jadi KV cache berhalaman seharusnya sudah tuntas, kan? Tidak juga. README DeepInfer dengan santai menyebutkan sesuatu yang jauh lebih agresif: salah satu tujuan desain sistem produksinya adalah mempertahankan KV cache selama lebih dari 72 jam.

Pikirkan apa implikasinya. HBM pada GPU terbesar pun diukur dalam ratusan gigabyte; cache 72 jam di klaster yang sibuk berarti state sebesar petabyte. Kamu tidak bisa menyimpannya di perangkat. Kamu butuh sistem KV bertingkat: HBM, DRAM host, NVMe, mungkin penyimpanan jarak jauh, dengan kebijakan eviction dan prefetch yang cukup pintar agar menarik kembali prefix usang tidak merusak SLO latensimu. Inilah alasan README mencantumkan "sistem KV cache" sebagai sesuatu yang tidak disertakan dalam rilis: itu infrastruktur tersendiri yang serius. Kalau kamu selama ini memperlakukan KV cache sebagai masalah paging di dalam GPU, frontier sudah bergeser ke memperlakukannya sebagai sistem penyimpanan. Kami pernah membahas versi skala kecil dari masalah ini di apa yang harus dilakukan ketika GPU kehabisan VRAM, tapi ini adalah masalah yang sama pada skala datacenter.

Ada juga trik KV yang lebih halus dan layak dicuri: SWA bounded replay. Untuk layer sliding-window attention pada decoder, kamu tidak perlu mengulang seluruh prompt saat prefill, cukup suffix terbatas yang menutupi jendela attention ditambah panjang backtracking maksimum (default: simpan 140 token). Ini langsung mengurangi compute prefill untuk konteks panjang, dan ini jenis optimasi yang baru kamu temukan ketika memprofil di mana FLOP prefill sebenarnya dihabiskan. Engine generik tidak bisa melakukan ini dengan aman; dibutuhkan pemahaman mendalam tentang arsitektur attention model. Engine yang spesifik untuk model kembali menang.

Mitos 4: Speculative decoding adalah throughput gratis

Speculative decoding punya janji yang hampir magis: menghasilkan beberapa token per forward pass menggunakan draft yang murah, memverifikasinya secara paralel, lalu menyimpan yang cocok. Benchmark menyukainya. Tapi anggapan bahwa ini "gratis" runtuh begitu kamu membaca bagaimana DeepInfer benar-benar menerapkannya. Flag-nya bercerita: DEEPINFER_ENABLE_MTP_VARLEN=1 untuk mengaktifkannya, DEEPINFER_USE_NEXTN_DECODE untuk membatasi panjang draft, dan lapisan penjadwalan confidence yang terpasang di atasnya. Kalau ini gratis, kamu tidak butuh semua itu, cukup selalu membuat draft.

Ekonominya bekerja begini. Membuat draft dan memverifikasi menghabiskan FLOP tambahan di setiap langkah. Kamu baru untung ketika tingkat penerimaan cukup tinggi sehingga kenaikan token per langkah melampaui overhead-nya. Tingkat penerimaan bergantung pada mekanisme draft, domain (kode cocok sekali untuk di-draft; prosa yang bertele-tele kurang), dan yang paling krusial, beban batch. Pada ukuran batch besar, GPU sudah terikat compute, sehingga FLOP verifikasi tambahan langsung menggeser pekerjaan yang sebenarnya. Speculative decoding bersinar di rezim yang terikat latensi dan bisa justru merugikan di rezim yang terikat throughput. Engine produksi yang melayani kedua rezim perlu menjadwalkannya secara adaptif, dan itulah yang dilakukan verifikasi terjadwal berbasis confidence.

Opini saya, setelah melihat banyak tim menempelkan speculative decoding ke stack penyajian mereka: perlakukan ini sebagai fitur latensi, bukan fitur throughput. Kalau bottleneck-mu adalah token per dolar pada utilisasi tinggi, perbaiki scheduler dan tata letak KV-mu dulu. Kalau bottleneck-mu adalah p99 latency untuk pengguna interaktif pada beban sedang, speculative decoding adalah salah satu alat terbaik yang tersedia, dan DeepInfer memberimu referensi yang sudah teruji tentang cara mengaturnya.

Mitos 5: Kamu butuh restu NVIDIA (dan hanya itu) untuk melayani dalam skala besar

DeepInfer mendukung tepat dua target hardware: GPU NVIDIA SM100 dan NPU Huawei Ascend 950. Ia memelihara file requirement terpisah per platform (requirements-nvidia.txt, requirements-ascend.txt) dan mengatur fitur sesuai itu. Batch-invariant inference, misalnya, hanya untuk NVIDIA. Ini pernyataan yang tenang tapi signifikan. Mesin produksi kelas atas memperlakukan akselerator non-NVIDIA sebagai warga kelas satu, dengan model, scheduler, dan arsitektur penyajian yang sama.

Biar jelas apa arti ini dan apa yang tidak. Ini tidak berarti jalur Ascend sudah matang, dan tidak berarti parit CUDA hilang dalam semalam. Fitur khusus CUDA di README yang sama membuktikan bahwa kesenjangan ekosistemnya nyata. Yang berarti adalah bahwa masalah perangkat lunak paling sulit dalam portabilitas inferensi (engine, scheduler, strategi paralelisme) kini terbuka, berlisensi Apache, dan dirancang untuk dua target sejak awal. Bagi lab kecil dan vendor hardware, ini adalah fondasi untuk dibangun, bukan tembok untuk ditiru. Siapa pun yang mengamati ujung pasar model flash tahu betapa ekonominya bergantung pada hal ini; kami pernah berargumen bahwa model kelas flash adalah cerita sebenarnya tentang efisiensi inferensi, dan keberagaman hardware memperkuatnya.

Desain paralelisme juga layak disebut: attention data-parallel dengan context-parallel yang seimbang, ditambah expert-parallel untuk layer MoE dengan load balancer expert-parallel. Kombinasi ini disetel untuk deployment persis seperti yang digambarkan DeepSeek, yaitu segelintir GPU untuk prefill dan puluhan untuk decode, yang dipisahkan. Disaggregation dengan dominasi decode menjadi arsitektur default untuk fleet penyajian besar, dan alasannya sederhana: prefill terikat compute dan decode terikat bandwidth memori, jadi menggabungkan keduanya memaksamu membeli hardware yang tidak optimal untuk keduanya.

Mitos 6: Kamu tinggal ambil dan jalankan

Satu keyakinan terakhir untuk dipatahkan, ditujukan kepada semua orang yang sudah memberi bintang pada repo ini dan berencana menyambungkannya ke stack mereka akhir pekan ini. DeepInfer saat ini hanya melayani satu keluarga model: DeepSeek-V4.1-Flash. Ia membutuhkan Linux, GCC 13+, Python 3.12, CUDA 13, dan hardware SM100, yaitu generasi Blackwell, yang tidak dimiliki kebanyakan dari kita begitu saja. Benchmark diukur dengan 4 GPU untuk prefill dan 64 untuk decode dalam satu scale-up domain. Dan tiga hal yang kamu butuhkan untuk layanan sungguhan, yaitu sistem KV cache, plumbing disaggregation, dan load balancing replika, secara eksplisit di luar cakupan. Ini adalah mesinnya, bukan mobilnya.

Tapi menganggapnya tidak bisa dipakai melewatkan intinya, dan di sinilah saya akan beropini. Rilis ini berharga bukan terutama sebagai perangkat lunak untuk di-deploy, melainkan sebagai spesifikasi tentang apa arti sebenarnya dari kelas produksi. Batch-invariant inference sebagai flag kelas satu. Deterministic sampling dengan seq_seed tetap untuk reproduktibilitas. Structured output yang dikompilasi ke dalam sampler, bukan ditempel belakangan dengan retry. Speculation dengan penjadwalan confidence. Async scheduling sebagai default, bukan eksperimen. Kalau kamu sedang membangun atau membeli stack inferensi, README ini adalah daftar periksa. Kalau kamu menjalankan model besar sendiri, dan kami punya panduan praktis menjalankan LLM di hardware sendiri untuk skala kecilnya, prioritasnya tetap sama, hanya pada skala berbeda: scheduler dulu, tata letak memori kedua, kernel ketiga.

Forward pass adalah bagian yang paling mudah. Inferensi produksi adalah scheduler, manajer memori, dan sistem verifikasi yang kebetulan memanggil kernel.

Waktu geopolitiknya, rilis ini mendarat hanya beberapa jam setelah perintah pengecualian federal AS, dengan komentar yang menyebutnya mulai dari hadiah hingga sabotase, pasti akan mendominasi judul berita. Silakan saja. Tapi jika drama itu dikesampingkan, kesimpulan engineering-nya tetap berdiri sendiri: sebagian besar yang kita yakini tentang mesin inferensi sudah basi satu generasi. Pekerjaan yang menarik tidak lagi ada di kernel. Ia ada di segala sesuatu di sekitarnya.