Mengapa DeepSeek murah dalam skala besar tetapi mahal secara lokal

• Beberapa model AI seperti DeepSeek-V3 murah dan cepat saat disajikan dalam skala besar, tetapi lambat dan mahal saat dijalankan secara lokal
• Alasannya terletak pada trade-off mendasar antara throughput (kapasitas pemrosesan) dan latency (latensi) yang berkaitan dengan efisiensi pemanfaatan GPU
• Jika ukuran batch diperbesar, GPU dapat bekerja lebih efisien, tetapi pengguna harus menunggu sampai token terkumpul sehingga terjadi peningkatan latensi
• Model dengan arsitektur Mixture-of-Experts dan pipeline yang dalam membutuhkan batch besar dan latensi tinggi
• Dalam lingkungan pengguna tunggal lokal, sulit membentuk batch yang cukup besar, sehingga muncul masalah penurunan kinerja dan peningkatan biaya
• OpenAI, Anthropic, dan lainnya mewujudkan respons cepat lewat efisiensi arsitektur itu sendiri, strategi batching tingkat lanjut, atau dengan mengerahkan GPU secara berlebihan

---

Inferensi batch dan efisiensi GPU

• GPU adalah perangkat keras yang dioptimalkan untuk perkalian matriks skala besar (GEMM)
• Saat token dari banyak pengguna digabung sekaligus dan dijalankan sebagai matriks besar dalam batch, overhead round-trip yang rendah dan efisiensi memori membuat throughput meningkat tajam
• Server inferensi menumpuk token dari banyak permintaan di antrean, lalu memilih batch dengan ukuran yang sesuai untuk menjalankan operasi GEMM skala besar
• Dalam proses ini, server harus memilih trade-off antara ukuran batch (throughput meningkat) dan waktu tunggu (latency meningkat)

Mengapa beberapa model dioptimalkan untuk batch besar

Mixture of Experts (MoE) dan batch

• Arsitektur MoE (DeepSeek-V3, perkiraan GPT-4) adalah penyebab utama rendahnya efisiensi GPU
• Karena ratusan blok “expert” masing-masing memerlukan perkalian matriks yang terpisah, pada batch kecil tiap expert hanya punya sedikit pekerjaan sehingga efisiensinya menurun
• Semua expert baru bisa dimanfaatkan secara memadai jika ada banyak permintaan simultan, sehingga pada level layanan batch besar menjadi hal yang esensial
• Pada waktu tunggu singkat (window 5ms) expert sering menganggur, sedangkan pada waktu tunggu panjang (window 200ms) efisiensi tinggi bisa dimaksimalkan

Masalah batch pada model pipeline yang dalam

• Transformer besar dengan ratusan lapisan dijalankan dengan membagi layer per GPU (pipelining)
• Jika jumlah token dalam satu batch lebih sedikit daripada jumlah langkah pipeline, muncul fenomena pipeline bubble, yang berujung pada penurunan throughput
• Untuk mencegahnya, batch besar (waktu tunggu lebih lama) menjadi keharusan, dan akibatnya waktu respons model memanjang

Mengapa antrean tidak selalu bisa dipenuhi

• Secara teori, jika antrean selalu terisi oleh trafik simultan yang besar, bubble tampaknya bisa dihindari
• Namun dalam praktiknya, karena ukuran matriks (panjang) pada tahap attention Transformer harus sama agar bisa dibatch, sulit membuat satu antrean tunggal bekerja sempurna
• Selain itu, jika tahap FFN dan attention dipisahkan, akan muncul masalah lonjakan overhead memori serta inefisiensi perpindahan data

Ringkasan dan kesimpulan

• Pemrosesan batch besar penting untuk menurunkan biaya GPU dan meningkatkan throughput, tetapi pengguna harus menghadapi waktu tunggu yang lebih panjang
• Model dengan Mixture-of-Experts dan arsitektur pipeline besar pada dasarnya dioptimalkan untuk lingkungan batching berefisiensi tinggi yang berbasis waktu tunggu
• Dalam lingkungan dengan trafik rendah seperti lokal, konfigurasi batch besar yang optimal tidak bisa dibentuk, sehingga efisiensi GPU turun drastis dan biaya eksekusi meningkat
• OpenAI, Anthropic, dan lainnya menunjukkan respons yang cepat karena
  • (1) Bisa jadi mereka memakai arsitektur yang lebih efisien dan bukan MoE
  • (2) Menerapkan optimasi batch/pipeline serta trik inferensi tingkat lanjut
  • (3) Bisa jadi mereka mengerahkan lebih banyak GPU daripada yang diperlukan untuk “membeli” kecepatan

Tambahan: perbedaan antara batch prefill dan batch isi utama

• Transformer juga dapat menjalankan prefill (input panjang) dari satu prompt pengguna secara batch sehingga inferensi awal bisa berlangsung cepat
• Namun batch yang dibahas dalam artikel ini adalah batching pada tahap pembuatan token utama dari banyak permintaan pengguna, tempat trade-off throughput-latency itu terjadi
• Batch prefill tidak berkaitan langsung dengan batching besar simultan yang disebutkan dalam artikel ini

Catatan tambahan

• Sistem inferensi nyata juga menggunakan metode continuous batching, yang langsung mengeksekusi saat batch sudah terisi
• Namun struktur dasar trade-off throughput-latency tetap berlaku sama

[GN⁺]

Komentar Hacker News

• Saya menjalankan DeepSeek V3 sendiri di rumah, dan menurut saya biayanya masih terjangkau dengan kecepatan serta performa yang memuaskan. Banyak orang mengira model besar tidak bisa dijalankan tanpa GPU, tetapi dari pengalaman saya justru server CPU lebih hemat daya dan lebih praktis. Server rumah saya memakai board Supermicro berbasis EPYC 9004 series kelas menengah dengan RAM 384GB, total biayanya sekitar 4000 dolar. Tanpa GPU, jika hanya mengandalkan RAM besar, konsumsi dayanya sering kali lebih rendah daripada desktop gaming. Saya memakai model Unsloth Dynamic GGUF dengan penggunaan RAM sekitar 270GB, dan dalam praktiknya kualitasnya hampir setara dengan model asli sambil tetap mendukung beragam tugas. Biasanya saya menjalankannya dengan konteks 16k dan memperluas hingga 24k bila perlu. Kecepatan generasi token sekitar 9~10 token per detik, turun ke 7 jika konteks diperbesar. Ada juga contoh menjalankan seluruh model dengan kecepatan token yang lebih tinggi di lingkungan 2CPU
  • Saya penasaran seberapa dekat performa Unsloth Dynamic GGUF dengan model aslinya. Dari pengalaman saya, untuk tugas sederhana bedanya tidak besar, tetapi pada tugas yang kompleks atau konteks panjang perbedaannya kadang terlihat jelas. Memang benar Unsloth melakukan pekerjaan yang luar biasa, tetapi sayangnya masih kurang materi evaluasi yang membandingkannya langsung dengan model asli yang belum dikuantisasi. Kenyataannya, banyak orang dan perusahaan juga tidak punya sumber daya untuk menjalankan model asli secara langsung
  • Saya penasaran apakah mungkin menjalankan DeepSeek untuk pembuatan kode dengan tool seperti Ollama pada CPU 40 core dan RAM 256GB. Saya membayangkan mengalokasikan sekitar 200GB memori untuk modelnya
  • Ada komentar bahwa situs pribadinya tidak bisa diakses. Ia memperkenalkan diri sebagai Jeff Carr, salah satu pendiri DigitalOcean, dan berharap bisa terhubung
  • Saya tadinya mengira GPU dengan memori cepat itu wajib, tetapi benarkah inferensi bisa dilakukan tanpa GPU hanya dengan memori besar? Saya penasaran bagaimana ini bisa dilakukan hanya dengan memori non-terpadu
  • Saya setuju bahwa DeepSeek V3 adalah salah satu model open-weight yang benar-benar praktis digunakan. Banyak tugas ternyata tidak memerlukan reasoning token tingkat tinggi sebanyak yang dibayangkan, dan kelebihannya adalah tidak perlu menunggu. Jika diperlukan, kita juga bisa kapan saja memilih opsi reasoning yang lebih tinggi. Kalau tidak menjalankannya sendiri, ada juga beberapa penyedia yang menawarkan konteks penuh (16k) dan 80tps sambil berjanji tidak memanfaatkan data pengguna. Contoh penggunaan home server 9004 itu konfigurasi yang keren
• Tulisan blog ini dinilai mengesankan. Saya setuju dengan kesimpulannya ("butuh batching"), tetapi menurut saya pembahasan inferensi model MoE perlu lebih berlapis. Alasan batch besar penting adalah karena bottleneck inferensi LLM bukan kekurangan komputasi, melainkan memuat semua weight dari VRAM. Jika membandingkan TFLOPS dan bandwidth memori H100, secara hitungan sebenarnya ada ruang untuk memproses 300 FLOP per byte. Semakin besar batch, semakin banyak komputasi yang bisa dilakukan untuk setiap parameter yang sudah dimuat, jadi ukuran batch perlu dimaksimalkan. Karena itu dipakai istilah "roofline model". Saat model makin besar dan tidak lagi muat seluruhnya di VRAM, model harus didistribusikan ke beberapa GPU atau node. Bahkan dengan NVLink atau Infiniband, bottleneck tetap muncul karena tidak secepat memuat langsung dari VRAM. Kekuatan MoE ada pada expert parallelism, yaitu menaruh expert yang berbeda di node yang berbeda sambil meminimalkan komunikasi antar-node. Namun ini hanya mungkin jika jumlah node cukup banyak sehingga semua expert bisa masuk di VRAM sekaligus menampung overhead seperti KV cache. Pada akhirnya ukuran batch akan membesar secara alami, dan memang harus begitu agar tiap GPU bisa bekerja efisien
  • Ada usulan untuk menempatkan "expert" yang berbeda pada satu node dengan cara round-robin, lalu hanya mengelompokkannya secara oportunistik menjadi batch saat beberapa request memakai expert yang sama. Ini seperti memakai antrean alih-alih batch, jadi latensinya naik, tetapi dalam lingkungan seperti workflow riset mendalam itu masih cukup bisa diterima
  • Ada contoh nyata bahwa ketika model tidak muat dalam satu GPU, inferensi tetap bisa dilakukan dengan membaginya per layer lalu mengirim vektor kecil ke GPU yang bertanggung jawab atas layer berikutnya untuk melanjutkan komputasi. Di Cerebras, pendekatan seperti ini menghasilkan 2500 triliun token per detik pada Llama 4 Maverick. Pengiriman vektor di atas fabric sangat cepat sehingga hampir tidak ada idle time
  • Ada yang membayangkan apakah semuanya bisa berjalan jauh lebih cepat jika semua node dan weight ditempatkan dalam rangkaian analog
  • Salah satu logika berinvestasi di AMD adalah bahwa seluruh model bisa masuk ke satu chassis, sehingga keuntungan model map/reduce bisa didapat sekaligus mengurangi biaya peralatan jaringan. Ia meminta insight jika ada pendapat sebaliknya
• Ringkasan satu kalimat untuk orang yang ingin hemat waktu: jawabannya adalah inferensi batch. Ini adalah cara memasukkan prompt dari banyak orang ke instance model secara bersamaan, dan secara praktis jauh lebih efisien daripada sekadar pembagian waktu yang rapat. Akibatnya, meski suhu dan nilai seed dikunci, respons layanan bisa berbeda-beda setiap kali, karena kita tidak bisa mengendalikan prompt apa saja yang dibatch bersama prompt kita. Ada yang membayangkan fenomena ini bisa menjadi vektor serangan untuk pencurian data
  • Salah satu keuntungan batch adalah saat ingin mengevaluasi konten yang sama berulang kali dan memeriksa apakah benar ada "hallucination", kita bisa langsung melemparkannya sebanyak batch-size. Sebenarnya konsep batch sudah ada di LLM sejak awal, tetapi biasanya orang baru benar-benar merasakan nilainya seiring waktu
  • Saya tadinya mengasumsikan penyedia layanan selalu melakukan batching pada semua model, tetapi saya penasaran apakah ini hanya diterapkan pada keluarga model tertentu
  • Saya penasaran mengapa jika prompt dibatch bersama prompt lain, respons model bisa menjadi bervariasi
  • Jika prompt kita bisa dibundel bersama prompt orang lain, ada kekhawatiran bahwa ini bisa menjadi vektor serangan yang sangat efektif
• Kalau diringkas secara padat:<br>- Model dengan sparsity tinggi memerlukan batch besar (jumlah request simultan) agar satu operasi perkalian matriks cukup padat secara komputasi<br>- Untuk menangani batch sebesar itu, dibutuhkan sekitar 8~16 GPU agar weight model dan cache MLA/KV muat di HBM. Namun dengan 8~16 GPU, throughput keseluruhan tetap rendah sehingga kecepatan respons per pengguna menjadi sangat lambat. Agar pengalaman penggunaan terasa nyaman, dibutuhkan sekitar 256 GPU
  • Saya menjalankan layanan DeepSeek pada lingkungan 16 H100 (2 node). Saya melihat 50~80 token per detik per request, dengan throughput stabil hingga ribuan token secara keseluruhan. Waktu token pertama juga stabil, dan pengalamannya lebih cepat daripada layanan cloud mana pun yang bisa kami gunakan
  • Ada yang berkata bahwa sparsity tinggi = butuh batch besar, tetapi hubungan keduanya kurang bisa dipahami. Ia menyindir dengan menganggap sparse matmul pada dasarnya hanyalah matmul dengan banyak angka 0
• Dinilai sebagai penjelasan yang sangat bagus dari sudut pandang LLM. Ada prediksi bahwa perusahaan LLM hyperscale benar-benar menganalisis trace komputasi secara detail untuk menemukan bottleneck, lalu sangat serius mengoptimalkan workload dengan load balancer, arsitektur pipeline, scheduler, dan sebagainya. Namun, "prasyarat batching" untuk efisiensi bisa merugikan aplikasi dengan keamanan tinggi, karena isolasi query menjadi sangat mahal. Virtualisasi vGPU dari nVidia membagi memori GPU dengan time-slicing, tetapi diduga perlu unload/reload setiap context switch dan tidak ada deduplikasi. MIG juga membagi memori secara statis per pengguna, dan untuk mengubah pembagian perlu reboot GPU; wajar jika orang enggan membelah GPU 96GB menjadi 4x24GB. Ada juga bayangan bahwa jika board GPU ditambah memori sekunder (DRAM), mungkin berbagai data matriks bisa dinaikkan lebih cepat daripada lewat PCIe, dengan HBM berperan sebagai cache.<br>Gaya penulisan yang jujur di Software Engineering Survival Guidebook juga dipuji
• Ada pendapat bahwa ruang optimasi perangkat lunak untuk DeepSeek masih sangat besar. Saat ini optimasi yang berfokus pada aksesibilitas praktisnya hanya ada pada dua tipe sistem: GPU kecil dengan RAM besar (ktranformers) atau sistem dengan VRAM sangat besar. Struktur dengan 192GB VRAM + sisa memori biasa (DGX station, 2xRTX Pro 6000, dan sejenisnya) tampaknya bisa menjalankan DeepSeek 4bit dengan cukup cepat berkat kekuatan MoE. Jika prompt DeepSeek bukan dalam bahasa Mandarin, sebagian besar expert tidak akan aktif. Ini juga membuat pruning lebih mudah. Ke depan, arah sistem enthusiast tampaknya cocok dengan optimasi perangkat lunak semacam ini. Di Reddit juga ada contoh sistem 16x3090 (PCIe 3.0 x4) yang mencapai sekitar 7 token/detik di llama.cpp, dan bahkan satu 3090 saja secara teori bisa memindai seluruh VRAM 39 kali per detik, jadi tampaknya ada bottleneck performa lain
  • Konsumsi daya sistem 16x3090 mencapai 5KW. Dengan level seperti itu, kalau memikirkan biaya listrik, memakai API justru lebih murah. Karena banyak expert tidak aktif saat tidak memakai prompt Mandarin di DeepSeek, muncul bayangan tentang peringanan model dan cara merutekan token ke expert yang lebih dekat
  • Satu unit MI300x bisa menyediakan 192GB VRAM
• Saya bukan peneliti ML maupun engineer, jadi mohon anggap komentar ini dengan konteks itu. DeepSeek V3/R1 memang jauh lebih besar daripada model lokal sebelumnya, sehingga wajar jika menjalankannya secara lokal itu mahal. Parameter aktifnya memang lebih sedikit daripada ukuran total, tetapi itu hanya mengurangi kebutuhan komputasi, bukan kebutuhan memori, sehingga dalam praktiknya hampir mustahil dipakai serius tanpa GPU raksasa. Juga tidak mungkin membandingkannya langsung dengan model frontier utama yang proprietary, karena informasi seperti ukuran modelnya tidak dibuka. Tidak ada dasar kuat juga untuk berharap model-model itu akan lebih murah dijalankan secara lokal. Bahkan, MoE justru memberi trade-off yang lebih cocok untuk lingkungan lokal/single-user karena inefisiensi batching tidak terlalu besar di sana. Saat batch diperbesar, latensi tunggu per token bisa naik sampai 200ms, tetapi operasi feed-forward (GEMM) juga membesar sehingga komputasinya menjadi lebih efisien. Saya penasaran apakah memperbesar batch memang membuat matriksnya sendiri menjadi lebih besar. Dalam model mental saya, tujuan batch bukan "memperbesar ukuran matriks input", melainkan "memindahkan batasan dari bandwidth memori ke bottleneck komputasi". Weight sudah dipecah per layer lalu dimuat dari HBM ke SRAM, dikalikan per potongan, lalu hasil akhirnya digabungkan. Keuntungan batching adalah memakai weight yang sama untuk memproses banyak operasi sekaligus sehingga FLOPS bisa dimaksimalkan secara efisien. Saya juga merasa klaim bahwa model skala besar seperti OpenAI atau Anthropic merespons cepat itu sendiri belum terlalu kuat, karena tulisan blog tersebut tidak memberikan angka time to first token
  • Saya adalah penulis tulisan aslinya. Saya bukan peneliti ML, hanya engineer yang sangat tertarik pada topik ini. Dalam skenario lokal single-user untuk MoE, maksudnya adalah tanpa keuntungan batching multi-user, throughput per GPU turun drastis. Jadi kecuali ada inferensi paralel dalam jumlah besar, situasinya memang seperti itu. Dengan batching, ukuran matriks input membesar; jika batch = 1, operasinya menjadi matriks 1xdim, dan saat batch bertambah menjadi batch-size x dim, pemanfaatan GPU melonjak sehingga bottleneck bisa bergeser ke komputasi. Terakhir, kalau DeepSeek dipakai cukup banyak, memang terasa lebih lambat dibanding model lain
• Mixture of experts membutuhkan batch besar, tetapi dengan Apple Silicon orang menganggapnya masih cukup layak bahkan pada batch size 1. Berkat unified memory, model besar bisa dijalankan secara lokal, meski bandwidth dan FLOPS lebih rendah sehingga kecepatannya juga relatif lambat. Ciri MoE adalah jumlah parameter yang harus diproses setiap kali lebih sedikit, sehingga beban komputasinya lebih ringan. Nyatanya ada banyak pengalaman orang yang menjalankan DeepSeek di Mac dengan kecepatan yang cukup berguna untuk inferensi single-batch. Tentu saja, biaya pembelian tetap mahal jika ingin memasang memori yang cukup besar. Jika nanti lebih banyak mesin seperti Mac atau arsitektur serupa muncul, banyak yang menilai itu akan menjadi pasangan ideal untuk model MoE. Sebagai perbandingan, menjalankan model dense pada Mac dengan upgrade RAM besar terasa jauh lebih menyiksa
• Setelah berdiskusi dengan rekan kerja, saya sampai pada kesimpulan bahwa untuk dukungan pemrograman, LLM justru berkembang ke arah yang menjauh dari optimasi yang paling esensial. Karena aturan internal, saya membandingkan hampir semua pekerjaan dengan model lokal 4~30B dan berbagai seri GPT. Khususnya GPT-4o rata-rata memberi hasil yang unggul, tetapi juga punya kecenderungan "mengarang sebagian respons", sehingga saya harus menghabiskan banyak waktu untuk verifikasi dan iterasi. Akibatnya, saya merasa "perbedaan antara model lokal berparameter rendah dan usaha yang dibutuhkan ternyata tidak sebesar yang dibayangkan". Masalahnya, keduanya sama-sama sangat lambat sehingga iterasi cepat tidak mungkin dilakukan. Saya pribadi merasa model berkonteks besar dengan kualitas lebih rendah tetapi respons yang secepat kilat jauh lebih nyaman dipakai. Saya berharap yang ditingkatkan bukan hanya skor evaluasi kualitas, tetapi juga "kecepatan iterasi yang terasa" dalam penggunaan nyata
• Ada yang menolak klaim "lambat dan mahal". Bahkan dengan workstation lama berbasis memori DDR4, menggunakan llama.cpp ada contoh sistem sekitar 1000 dolar yang bisa menghasilkan 3 token per detik
  • Ada yang menunjukkan bahwa mungkin Anda sebenarnya memakai versi distill, bukan model DeepSeek yang asli. Tanpa setidaknya 192GB RAM, model yang sesungguhnya tidak bisa dijalankan