Apa Itu DeepInfer? Mesin Inferensi DeepSeek, dan Bagian yang Tidak Dirilis

DeepInfer adalah kerangka kerja inferensi yang diterbitkan DeepSeek pada 16 Oktober 2026 di bawah Apache-2.0, dan kerangka kerja ini melayani tepat satu model: DeepSeek-V4.1-Flash, dengan DeepSeek-V4.1-Flash-1017 sebagai checkpoint default. Cakupan satu-model itu adalah hal pertama yang perlu dipahami, karena cakupan tersebut menjelaskan hampir semua hal lain tentang repositori ini. Ini bukan kerangka kerja penyajian umum yang kebetulan menyertakan konfigurasi DeepSeek. Ini adalah jalur kode yang dijalankan DeepSeek di produksi, dipangkas ke bagian-bagian yang dapat digeneralisasi, dan rilis ini jujur tentang pemangkasan tersebut: daftar dari README itu sendiri tentang apa yang dibutuhkan sebuah layanan inferensi lengkap, dan apa yang tidak disertakan rilis ini, menyebutkan sistem cache KV, disagregasi VE/Prefill/Decode, dan penyeimbangan beban di seluruh replika paralel data. Yang Anda dapatkan adalah jalur komputasi — kernel, paralelisme, decoding spekulatif, penjadwalan, keluaran terstruktur. Yang tidak Anda dapatkan adalah lapisan penyimpanan dan perutean yang membuat jalur komputasi murah untuk dioperasikan pada skala besar. DeepSeek menjelaskan alasannya: komponen-komponen tersebut sangat terikat pada infrastruktur internal, sehingga desainnya dijelaskan dalam tulisan yang diterbitkan sementara kodenya tetap internal.

Apa yang sebenarnya ada di dalam repositori

Daftar fitur yang dipublikasikan terbaca seperti tur atas berbagai hambatan dalam melayani model mixture-of-experts berukuran besar. Ada pustaka kernel yang telah dirilis DeepSeek sebelumnya — FlashMLA untuk attention, DeepGEMM untuk perkalian matriks, DeepEP untuk komunikasi expert-parallel, ditambah TileKernels dan DeepSelect. Ada skema paralelisme: attention berjalan sebagai data parallelism dengan context parallelism yang seimbang, bagian MoE berjalan sebagai expert parallelism dengan load balancer expert-parallel. Ada DSpark, stack speculative decoding, dengan panjang verifikasi yang dijadwalkan alih-alih tetap. Ada SWA bounded replay, yaitu mekanisme yang mencegah cache attention sliding-window memaksa komputasi ulang penuh pada setiap cache miss. Ada penjadwalan batch asinkron, inferensi batch-invariant dengan sampling deterministik, dan output terstruktur yang dibatasi oleh regex, skema JSON, atau EBNF.

Titik masuknya sengaja dibuat kecil. Setelah menyetel DEEPINFER_ACCELERATOR ke nvidia atau padanan Ascend dan menjalankan build.sh, repositori menyertakan examples/offline_inference.py, yang menjalankan checkpoint default dari awal hingga akhir. DEEPINFER_HF_MODEL_DIR mengarahkannya ke direktori bobot yang berbeda. Tolok ukur yang dipublikasikan diukur pada empat GPU SM100 untuk prefill dan 64 GPU SM100 untuk decode, yang merupakan bentuk deployment yang dirancang untuk mesin ini dan bukan demo yang cocok dijalankan di laptop.

README juga menyatakan asal kode tersebut, yang perlu diketahui sebelum membacanya. Mesin ini awalnya dibangun terutama di atas vLLM, dengan inspirasi desain yang diambil dari SGLang dan TensorRT-LLM. Silsilah itu terlihat dalam strukturnya — penjadwal, antarmuka paged attention, dan jalur sampling akan terasa familier bagi siapa pun yang pernah membaca proyek-proyek tersebut — dan itu menjelaskan mengapa rilis ini merupakan fork dari stack serving, bukan arsitektur yang ditulis dari nol. Yang ditambahkan DeepSeek adalah bagian yang spesifik untuk modelnya sendiri: deployment terdisagregasi, paralelisme pakar lebar dengan penyeimbangnya, replay jendela geser, dan DSpark.

Apa yang tidak ada di dalamnya, dan mengapa hal itu lebih penting

Tiga bagian yang hilang itu bukanlah kelalaian kecil. Masing-masing merupakan sistem yang harus ada sebelum mesin tersebut melayani lalu lintas produksi, dan masing-masing mahal dengan caranya sendiri.

• Sistem cache KV. Penggunaan ulang prefiks adalah bagian dengan penghematan terbesar dalam beban kerja chat, karena cache hit menggantikan prefill. Tanpa penyimpanan cache, setiap permintaan menghitung ulang prompt-nya. Tulisan DeepSeek sendiri menjelaskan penyimpanan yang digunakannya: klaster 3FS khusus alih-alih memori host lokal, tepatnya agar mesin prefill mana pun dapat mengenakan prefiks mana pun dan kapasitas cache dapat diskalakan secara independen dari komputasi.

• Disagregasi VE/Prefill/Decode. README mencatat bahwa sebagian besar fungsionalitas di sisi mesin sudah ada dalam rilis; yang belum ada adalah penerapannya. Mendisagregasikan vision encoder, prefill, dan decode memungkinkan Anda menyesuaikan ukuran setiap tahap terhadap bottleneck-nya sendiri dan mengontrol time-to-first-token secara terpisah dari time-between-tokens. Itu adalah keputusan infrastruktur, bukan flag.

• Penyeimbangan beban di seluruh replika paralel-data. DeepSeek menjalankan empat penyeimbang — prefill, decode, vision encoder, dan expert-parallel — dan menjelaskan keempatnya dalam tulisan tersebut. Tidak ada logika perutean yang disertakan. Tanpanya, armada replika hanya sebaik router apa pun yang Anda pasang di depannya, dan router round-robin naif akan menghancurkan rasio cache hit yang ingin dilindungi oleh penyimpanan itu.

Dibaca bersama-sama, penghilangan itu memberi tahu Anda jenis artefak ini. DeepInfer adalah implementasi referensi dari jalur komputasi, diterbitkan agar pekerjaan kernel dan penjadwalan dapat diperiksa dan digunakan kembali, bukan distribusi yang Anda pasang lalu arahkan trafik ke sana.

Gerbang perangkat keras adalah filter sesungguhnya

DeepInfer menargetkan NVIDIA SM100 dan Huawei Ascend 950. Tidak ada jalur Ampere dan tidak ada jalur Hopper, yang mengecualikan sebagian besar GPU di sebagian besar klaster saat ini. Bagian lain dari toolchain juga sama spesifiknya: hanya Linux, GCC 13 atau yang lebih baru, Python 3.12, CUDA 13 untuk NVIDIA atau CANN 9.2 untuk Ascend. Dan tidak ada rilis sama sekali — repositori tersebut tidak memiliki rilis yang dipublikasikan saat dibaca pada 21 Oktober 2026, jadi tidak ada yang bisa diunduh dan tidak ada yang bisa dipatok. Anda mengkloningnya dan membangunnya dengan toolchain Anda sendiri.

Kombinasi itu tidak biasa untuk rilis sumber terbuka yang mendapat begitu banyak perhatian, dan sebaiknya dibaca sebagai pernyataan cakupan yang akurat, bukan sebagai kelalaian. Kernel di repositori ditulis untuk set instruksi tertentu dan interkoneksi tertentu; angka-angka di README berasal dari perangkat keras tersebut. Mem-porting jalur komputasi turun satu generasi adalah persis jenis pekerjaan yang cepat dilakukan komunitas dan tidak dapat dijanjikan oleh organisasi rekayasa. Dalam hitungan hari setelah rilis, port pihak ketiga yang menyasar komponen NVIDIA lama muncul di GitHub, yang merupakan sinyal berguna tentang permintaan dan sama sekali bukan sinyal tentang apakah angka throughput yang dipublikasikan tetap bertahan setelah port tersebut.

Bentuk deployment yang benar-benar dijalankan DeepSeek

Uraian arsitektur adalah tempat asumsi-asumsi repositori menjadi dapat dipahami. Sistem ini dipisahkan menjadi encoder visi, prefill dan decode, ditambah node penyimpanan khusus. Prefill menggunakan paralelisme pakar 2 hingga 8 dengan paralelisme data yang sepadan, memilih konfigurasi terkecil yang diizinkan HBM. Decode sebaliknya: paralelisme pakar dan paralelisme data 64 hingga 128, yang disebut DeepSeek sebagai Wide-EP, menggunakan konfigurasi terbesar yang diizinkan GPU yang tersedia. Paralelisme tensor dan paralelisme konteks tidak digunakan sama sekali. Encoder visi menjalankan satu GPU per instans, dengan GPU yang lebih murah direkomendasikan, karena encoder bukan bagian yang menghabiskan biaya besar.

Deployment terkecil yang masuk akal mengikuti angka-angka itu. Satu GPU prefill dan satu GPU decode akan berjalan, dan dalam praktiknya rasio antara kedua kumpulan itu kira-kira satu banding satu. Namun karena decode membutuhkan 64 GPU atau lebih untuk mendapatkan manfaat expert-parallel, unit efisien terkecil adalah 64 GPU prefill ditambah 64 GPU decode. Itulah angka yang perlu dipegang saat membaca klaim apa pun tentang efisiensi DeepInfer: angka-angka tersebut menggambarkan deployment 128 GPU, dan separuhnya adalah satu tahap.

Memisahkan prefill dan decode di seluruh pusat data secara teknis mungkin dilakukan karena DeepSeek-V4.1-Flash mengompresi KV cache-nya secara substansial, dan deployment DeepSeek sendiri menempatkan node inferensi di pusat data yang berbeda tetapi berdekatan. Anggarannya kira-kira 400 Gbps interkoneksi per delapan GPU, dan tulisan tersebut jujur tentang biaya keandalan — serat optik antar bangunan mudah terpotong.

Mengapa decode tersebar begitu luas?

Paralelisme pakar yang lebar adalah pilihan paling berkonsekuensi dalam desain ini, dan mudah disalahpahami sebagai trik penskalaan. Dalam lapisan mixture-of-experts, setiap token menyentuh sejumlah kecil pakar, sehingga biaya langkah dekode didominasi oleh pemindahan bobot pakar dan aktivasi, bukan oleh intensitas aritmetika. Menyebarkan pakar ke 64 atau 128 GPU mengurangi lalu lintas memori per langkah yang disumbangkan setiap GPU, yang meningkatkan token per detik jika — dan inilah syaratnya — beban di antara pakar tetap merata. Itulah gunanya penyeimbang beban paralel pakar.

Pengaturan DeepSeek cukup spesifik untuk disalin. Untuk prefill, setiap GPU menyimpan empat expert redundan di luar expert yang dimilikinya, statistik dikumpulkan selama jendela 100 langkah, dan expert dialokasikan ulang setiap 1.000 langkah, dengan bobot diacak dalam grup melalui memori bersama NVLink. Ketidakseimbangan terukur — rank paling lambat dibagi rata-rata — sebesar 1,074 untuk konfigurasi EP4/DP4 dan 1,045 untuk EP2/DP2. Untuk decode, pengaturannya meluas: satu expert redundan per GPU, jendela statistik 1.000 langkah, realokasi setiap 10.000 langkah, dan ketidakseimbangan terukur 1,090. Perbedaan antara keduanya adalah intinya. Prefill menghadapi pekerjaan yang bursty dan heterogen serta membutuhkan penyeimbangan ulang yang cepat; decode menghadapi aliran yang stabil dan dapat menanggung jendela panjang, sehingga jarang menyeimbangkan ulang dan hampir tidak membayar apa pun untuk keistimewaan itu.

Sisi perutean memiliki karakter yang sama. Permintaan prefill dikelompokkan berdasarkan panjang konteks total ke dalam empat tingkatan — di bawah 16K, 16 hingga 64K, 64 hingga 256K, dan 256K ke atas — dan mesin ditetapkan ke tingkatan sesuai porsi permintaan komputasi setiap tingkatan pada putaran sebelumnya. Di dalam GPU, ukuran chunk untuk setiap langkah prefill tidak tetap: model biaya kuadratik yang telah difit memprediksi berapa lama suatu langkah akan berjalan berdasarkan jumlah token urutan dan prefiks yang sudah dihitung, dan penjadwal mencari chunk terbesar yang muat dalam anggaran 32.768 token di sisa waktu. Penyeimbang decode menyeimbangkan dua dimensi sekaligus, jumlah permintaan dan panjang total cache KV, mengirim permintaan pendek ke GPU dengan konkurensi rendah dan cache panjang, serta permintaan panjang ke GPU dengan cache kecil. Ringkasan DeepSeek sendiri tentang seberapa besar manfaat semua ini: sekitar 80 persen dari tolok ukur offline yang seimbang sempurna.

Cache, dan pertanyaan tiga hari

Cache KV berada di cluster 3FS khusus, bukan di memori host lokal, dan keputusan itu mendorong sisa desain penyimpanan. Data disimpan dengan erasure coding 10+2, sehingga setiap grup pengodean bertahan terhadap dua kegagalan node secara bersamaan; sebuah pembacaan mengirimkan permintaan ke semua 11 node dalam grup dan 10 respons apa pun cukup untuk mendekode. Pekerja garbage collection berjalan di setiap node penyimpanan dan mengeluarkan data berdasarkan LRU setelah melewati ambang batas. Server yang direkomendasikan memiliki 20 solid-state drive masing-masing berkapasitas 30,73 TB dan mempertahankan setidaknya 40 GB/s baca dan 5 GB/s tulis, dengan ukuran untuk menyimpan sekitar 24 jam data per server. Dalam praktiknya, cluster berjalan pada sekitar 14,4 TB cache logis per GPU online, dengan kapasitas fisik lebih besar dari itu.

Residensi adalah titik ketika trade-off menjadi terlihat. Tidak ada logika kedaluwarsa di sisi cache; TTL ditetapkan di sisi penyimpanan selama tiga hari untuk lalu lintas agen dan tujuh hari untuk lalu lintas chatbot, pada klaster yang menampung sekitar 100 petabyte penyimpanan solid-state. Pemisahan ini ada karena lalu lintas chatbot memiliki long tail hit yang jauh lebih berat — sejumlah kecil cache dibaca berkali-kali, sehingga kehilangannya menurunkan hit rate secara keseluruhan lebih besar daripada yang diperkirakan dari volumenya. Biaya yang terukur dari pemangkasan retensi chatbot oleh DeepSeek menjadi tiga hari adalah 0,5 hingga 1 persen dari cache hit rate. Itu adalah angka kecil yang kebetulan mewakili sejumlah besar prefill yang dihitung ulang.

Atensi jendela geser mendapat cache terpisah dengan aturan berbeda. Cache SWA tidak masuk ke blok paged; setiap urutan menempati satu slot berukuran tetap di memori host, dan untuk DeepSeek-V4.1-Flash layer yang disimpan adalah 20 layer pertama. Hanya wilayah itu yang persisten — 20 layer kali 134 token kali 528 byte, yaitu 1.415.040 byte per urutan dalam format MXFP8. Tidak ada yang dikirim ke kluster penyimpanan; data tetap berada di memori mesin yang menghasilkannya, dengan direktori di memori yang mencatat mesin mana menyimpan apa, dan hit lintas mesin menariknya kembali melalui VLAN 400 Gbps.

Dua mekanisme yang menghasilkan angka-angka utama

Replay terbatas adalah yang lebih menarik dari keduanya karena mengubah biaya yang tak terbatas menjadi konstan. Biasanya, cache miss pada jendela geser berarti menghitung ulang jendela dari awal, dan biayanya tumbuh seiring panjang konteks dan jumlah lapisan. DeepSeek sebaliknya hanya menghitung ulang 128 token terbaru dan memotong jendela atensi ke segmen tersebut, sehingga menghasilkan cache SWA perkiraan dengan biaya tetap. Di sisi encoder, ini sepenuhnya memisahkan panjang hit prefix-cache dari cache SWA: jika cache SWA hilang, 128 token terakhir dari prefix yang hit diputar ulang sementara cache blok digunakan kembali tanpa disentuh.

Sisi decoder adalah tempat penghematannya besar. Dalam arsitektur ini, cache blok milik lapisan-lapisan decoder diproyeksikan dari hidden state lapisan encoder terakhir, sehingga hanya cache SWA decoder yang perlu dihitung per lapisan — dan merekonstruksinya secara persis berarti mendorong 2.560 token terakhir melalui 20 lapisan decoder pada setiap prefill. Dengan memutar ulang 128 token saja, dan menggunakan hasilnya hanya untuk decode alih-alih membiarkannya masuk ke cache prefix, komputasi prefill total hampir berkurang setengah. Perubahan tunggal itu bernilai lebih besar daripada sebagian besar optimisasi kernel, dan itulah jenis hal yang hanya bisa dilakukan oleh tim yang memiliki arsitektur modelnya.

Kontribusi DSpark lebih kecil dan lebih konvensional. Token draf memiliki probabilitas penerimaan yang berbeda-beda tergantung permintaan dan posisinya, sehingga memverifikasi lima draf secara tetap per langkah membuang komputasi pada token yang akan ditolak. Sebuah confidence head memprediksi tingkat penerimaan setiap token draf, dan penjadwal mengurutkan draf berdasarkan ekspektasi imbal hasil lalu hanya memverifikasi prefiks yang memaksimalkan throughput. Dalam produksi, model draf tetap menghasilkan lima token per langkah; jumlah yang diverifikasi turun dari 5,00 menjadi antara 3,2 dan 4,4, pengurangan sekitar 30 persen, sementara panjang yang diterima hampir tidak berubah — 3,29 versus 3,20. Berdasarkan data benchmark EP64/DP64, itu berarti throughput 4 hingga 7 persen lebih tinggi pada sekitar 60 sekuens bersamaan per rank. Tepat pada 60, throughput per rank naik dari 13.730 menjadi 14.466 token per detik. Di bawah sekitar 16 sekuens bersamaan, teknik ini merupakan kerugian bersih yang kecil, yang perlu diketahui sebelum mengadopsinya untuk penerapan lalu lintas rendah.

Apa arti angka 155 triliun itu

Angka yang paling banyak dikutip yang melekat pada rilis ini adalah satu klaster yang melayani 155 triliun token per hari dengan pendapatan keseluruhan 38 dolar AS per GPU-jam pada harga valley. Kedua bagian itu dilaporkan vendor dan tidak satu pun merupakan benchmark yang dapat Anda reproduksi, yang tidak membuatnya tidak menarik — angka pendapatan per GPU-jam adalah jenis klaim yang benar-benar berbeda dari angka throughput, karena merangkum utilisasi, harga, dan rasio cache hit dalam satu baris. Ini juga angka yang paling mungkin dikutip tanpa kualifikasinya, jadi kualifikasi itu layak dicatat: satu klaster, harga valley, pendapatan bukan biaya, dan agregat di seluruh prefill, decode, dan vision encoder.

Dua pengungkapan yang lebih kecil lebih berguna secara langsung. Kernel decoding FlashMLA di repositori publik kehilangan satu optimasi assembly yang disetel manual yang dimiliki versi internal, sehingga 5 hingga 10 persen lebih lambat secara terisolasi; DeepSeek menyatakan performa end-to-end paling berbeda 5 persen. Dan model draf internal untuk decoding spekulatif lebih baru daripada yang dipublikasikan, dengan perbedaan performa yang digambarkan kecil. Kedua pernyataan itu menetapkan ekspektasi tentang seberapa besar performa yang dipublikasikan dapat dicapai pihak ketiga dengan menyalin kode, dan jawabannya adalah: sebagian besar, asalkan perangkat kerasnya cocok.

Repositori, sebagaimana adanya saat ini

Tangkapan layar di atas dibuat pada 21 Oktober 2026 dan menunjukkan halaman yang terbaca 16.3k bintang. GitHub API, yang dikueri pada hari yang sama, mengembalikan 16,590 bintang, 1,649 fork, dan 176 issue terbuka, dengan issue dinonaktifkan dan diskusi dialihkan ke GitHub Discussions. Jumlah bintang terus naik sejak itu, jadi baca setiap angka di sini sebagai stempel waktu, bukan sebagai properti kode. Trafik sebesar itu dalam waktu kurang dari sepekan lebih menunjukkan minat pada stack penyajian DeepSeek daripada kesiapan kode, dan jumlah rilis nol menjelaskan sisanya.

Jika Anda berpikir untuk menjalankannya sendiri

Ringkasan jujurnya adalah bahwa DeepInfer layak dibaca dengan saksama dan sulit dioperasikan. Empat pertanyaan akan memberi tahu Anda apakah ini cocok.

• Apakah Anda memiliki SM100 atau Ascend 950? Semua hal lain dalam rantai alat mengikuti dari satu hal ini. Tanpa akselerator yang tepat, angka-angka yang dipublikasikan tidak dapat dialihkan, dan port komunitas belum tervalidasi pada skala produksi.

• Apakah Anda dapat menjalankan 64 GPU decode dalam satu domain komunikasi? Paralelisme pakar yang lebar bukanlah optimasi yang bisa dilewati; itulah konfigurasi yang menjadi dasar perancangan jalur decode. Di bawah skala tersebut, Anda menjalankan sistem yang berbeda dengan nama yang sama.

• Apakah Anda sudah memiliki prefix cache? Jika tidak, Anda membandingkan jalur komputasi DeepInfer dengan stack pesaing yang sudah menyertakannya, dan perbandingannya akan terlihat lebih buruk daripada yang seharusnya menurut desain.

• Apakah Anda sanggup menulis lapisan perutean? Prefill bucketing, decode balancing, dan expert reassignment dijelaskan cukup baik untuk diimplementasikan ulang, dan mengimplementasikannya kembali adalah pekerjaan berminggu-minggu yang tidak dilakukan repositori untuk Anda.

Jika Anda lebih memilih untuk tidak memiliki satu pun dari yang disebutkan di atas

Bagi sebagian besar tim, pertanyaan praktisnya bukanlah bagaimana men-deploy DeepSeek-V4.1-Flash, melainkan di mana memanggilnya. Model ini tersedia melalui API yang kompatibel tanpa perlu membangun klaster 128-GPU atau mengimplementasikan ulang load balancer, dan itu adalah model yang sama yang arsitekturnya telah dijelaskan artikel ini — penanganan konteks yang sama, perilaku output terstruktur yang sama, tanpa pekerjaan disagregasi.

Perbandingan yang perlu dilakukan bukanlah mesin mana yang lebih cepat secara abstrak, karena angka-angka yang dipublikasikan adalah pengukuran yang dilaporkan vendor pada perangkat keras yang sebagian besar pembaca tidak miliki. Yang perlu dibandingkan adalah apakah beban kerjanya adalah beban di mana TTL cache 3 hari dan kumpulan decode 64-GPU mengubah harga, atau beban di mana permintaan setiap beberapa detik melalui API sederhananya lebih murah daripada operasi apa pun yang dijelaskan di atas. Untuk kasus kedua — yang merupakan sebagian besar kasus — jumlah DeepInfer yang tepat untuk digunakan adalah nol, dan jumlah yang tepat untuk dibaca adalah semuanya. Mulai dari halaman model DeepSeek V4.1 Flash jika Anda menginginkan endpoint; mulailah dari README repositori jika Anda ingin mengetahui apa yang dilakukan endpoint tersebut.