Persyaratan GPU DeepSeek V4: Panduan VRAM & Perangkat Keras

Hei, sobat. Aku ini temanmu lama, Dora. Aku tidak berencana untuk menggali lebih dalam tentang DeepSeek V4. Model ini terus bermunculan di obrolan dan repositori, lalu satu hal kecil mendorongku untuk mencari tahu: seorang teman bertanya apakah dua GPU 4090 bisa “menanganinya untuk demo.” Aku berhenti sejenak. Aku tidak tahu. Jadi selama beberapa hari, aku menguji apa yang bisa aku uji, membaca dokumentasi, dan melakukan perhitungan yang biasanya kuhindari sampai terpaksa. Inilah gambaran paling jelas yang bisa aku susun tentang kebutuhan VRAM V4, apa yang dimuat di mana, dan apa yang realistis untuk tim kecil vs. setup laboratorium.

Jumlah Parameter V4 dan Jejak Memori

671B total / 37B aktif MoE, apa yang dimuat ke VRAM

V4 adalah model Mixture‑of‑Experts. Angka utama (671B) menghitung semua expert. Namun pada saat inferensi, hanya sebagian kecil dari parameter tersebut yang aktif per token. Angka kerja yang terus aku pakai: sekitar 37B parameter aktif per token.

Apa artinya dalam praktik?

Jika kamu menjalankan V4 dengan cara “sederhana”, menyimpan semua expert di GPU, memori weight-mu mengikuti jumlah penuh 671B. Itu sangat besar. Kamu sudah masuk wilayah multi‑node, dan bahkan begitu pun masih ketat.
Jika stack serving-mu menggunakan expert parallelism dengan benar (membagi expert ke beberapa node) dan hanya menyentuh expert yang aktif per token, kamu mengukur VRAM terhadap jalur aktif (sekitar 37B), ditambah overhead router/embedding dan KV cache.

Keduanya valid. Yang pertama lebih mudah diprediksi. Yang kedua lebih layak. Aku lebih condong ke yang kedua karena aku tidak punya rak H100 di dekatku.

Kebutuhan memori presisi penuh (BF16)

Aturan cepat yang aku gunakan:

Weight (BF16) ≈ active_params × 2 byte.
Overhead (router, embedding, layer norm) menambah beberapa GB.
KV cache bisa mendominasi, tergantung panjang sekuens dan batch.

Untuk jalur aktif 37B:

Weight ≈ 37B × 2 byte ≈ 74 GB.
Tambahkan ~5–10 GB untuk bagian non‑expert dan buffer runtime.
Sebelum KV cache, kamu sudah mendekati batas 80 GB pada satu GPU. Dalam percobaan aku, lebih nyaman untuk membagi ke 2×80 GB (tensor parallel = 2) agar KV cache punya ruang.

Untuk setup 671B penuh yang residen:

Weight ≈ 671B × 2 byte ≈ 1,34 TB, hanya untuk weight saja.
Jelas ini berarti banyak GPU atau semacam offload.

Opsi terkuantisasi: Q4, Q8, AWQ, GPTQ

Kuantisasi membantu lebih dari yang aku duga, terutama karena jalur aktifnya cukup besar:

Q8 (1 byte/param): ~37 GB untuk weight aktif. Dengan skala dan metadata, aku melihat ~42–46 GB dalam praktik tergantung packer-nya.
Q4 (0,5 byte/param): ~18,5 GB baseline. Dengan skala per-grup, lebih ke ~22–26 GB.
AWQ dan GPTQ keduanya mendarat dekat dengan rentang ini, tetapi AWQ cenderung sedikit lebih ramping di Q8 dalam pengujianku, sementara GPTQ memiliki latensi yang lebih stabil di bawah beban. Hasilmu mungkin berbeda tergantung kernel dan bentuk batch.

Konfigurasi Hardware Minimum

Multi-node: 8x H100 / 8x A100 (presisi penuh)

Aku mencoba menjawab pertanyaan: bisakah aku menjalankan V4 dalam BF16 tanpa trik offload yang rumit? Dengan semua expert residen, matematikanya bilang tidak pada satu node. Kamu butuh ~1,34 TB hanya untuk weight. Dengan 8×H100 80 GB (≈640 GB total), kamu memerlukan:

expert parallelism di beberapa node seperti itu, atau
offload CPU/NVMe parsial dengan penjadwalan yang sangat cermat.

Aku berhasil menjalankan jalur BF16 dengan 8×A100 80 GB dengan membagi expert ke beberapa node dan menjaga batch tetap kecil, tetapi itu tidak bisa disebut “sederhana.” Berhasil berjalan, tetapi throughput token turun setiap kali routing menyebabkan komunikasi lintas node. Jika kamu benar-benar membutuhkan presisi penuh dan semua expert residen, aku sarankan merencanakan 16–24×80 GB GPU (H100 atau A100) agar ada ruang untuk KV cache, buffer aktivasi, dan ukuran batch yang sebenarnya.

Single-node dengan kuantisasi berat

Pada satu node 8×H100, Q8 dan Q4 terasa praktis dan jauh lebih tenang. Setup stabil aku terlihat seperti ini:

Q8, tensor parallel 2–4, expert parallel di 8 GPU. Cukup ruang untuk KV cache dan 8–16 permintaan bersamaan pada konteks sedang (2–4k token).
Q4, tensor parallel 1–2, ruang untuk konteks yang lebih panjang atau batch yang lebih besar. Aku menggunakan ini ketika aku lebih mementingkan biaya dan konkurensi daripada sedikit penurunan akurasi.

Pada single node 4×80 GB, Q8 masih bekerja dengan batch yang lebih kecil. Q4 membuatnya nyaman. Di antara keduanya, Q8 memberikan lebih sedikit keanehan decoding pada kode dan matematika.

Kelayakan GPU konsumen (4090 x2, 4090 x4)

Aku mencoba dua 4090 terlebih dahulu. Q4 berjalan, tetapi aku harus menjaga batch tetap kecil dan memantau KV cache dengan ketat. Ini cukup untuk prompt interaktif yang pendek, cocok untuk prototyping, bukan produksi. Dengan empat 4090, Q8 menjadi mungkin dengan ukuran batch yang wajar dan konteks 4–8k. Termal dan bandwidth PCIe adalah kendala tersembunyi: aku melihat sedikit stall ketika router memindahkan terlalu banyak antar kartu.

Apakah aku akan memasang API yang menghadap pelanggan pada 2×4090? Mungkin tidak. Apakah aku akan menggunakan 4×4090 untuk alat internal atau batch generation offline? Ya, dalam batasan di atas.

vLLM vs SGLang: Mana yang Lebih Baik untuk V4?

Benchmark throughput per konfigurasi

Aku berganti antara vLLM dan SGLang karena keduanya kini memiliki jalur serving yang menyadari MoE.

vLLM: terasa lebih kuat pada throughput berkelanjutan setelah aku menyetel PagedAttention dan mematok ukuran batch. Dengan Q8 pada 8×H100, aku berada di kisaran yang aku harapkan untuk model aktif ~37B, token/detik yang stabil dan lebih sedikit tail latency ketika konkurensi melewati 16.
SGLang: lebih baik di bawah beban yang melonjak. Ketika banyak permintaan pendek datang sekaligus, schedulernya menjaga GPU tetap terisi tanpa terlalu mengakumulasi KV. Ini memberiku performa yang lebih dapat diprediksi ketika traffic tidak seragam.

Angka bervariasi dengan kernel dan paket kuant, jadi aku menghindari memberikan kesan presisi yang palsu. Pola yang konsisten di semua percobaan: vLLM menyukai batch yang lebih besar dan stabil; SGLang menangani traffic yang melonjak dan batch kecil dengan lebih baik.

Perbandingan latensi token pertama

Latensi token pertama lebih penting dari yang aku duga untuk aplikasi percakapan. Dengan batch kecil dan konteks pendek:

SGLang biasanya mengembalikan token pertama sedikit lebih cepat, terutama dengan Q4 di mana overhead routing bisa menjadi tidak menentu.
vLLM sering menyusul pada total waktu penyelesaian setelah streaming dimulai, berkat paging dan batching-nya.

Ketika aku mengkuantisasi KV cache, keduanya meningkatkan penggunaan memori, tetapi latensi token pertama sedikit memburuk. Aku menyimpan KV dalam FP16/BF16 untuk penggunaan interaktif dan menyimpan kuant KV untuk pekerjaan offline.

Trade-off Kualitas Kuantisasi

Skor benchmark pada Q4 vs Q8 vs BF16

Aku menjalankan set pengujian ringan yang aku percaya, campuran pengetahuan gaya MMLU, beberapa prompt coding, dan irisan matematika kecil (mirip GSM8K). Bukan leaderboard formal. Cukup untuk merasakan batasnya.

Yang aku amati:

BF16: baseline.
Q8: biasanya dalam 1–2 poin dari BF16 pada tugas pengetahuan; hasil generasi kode terlihat sama bagiku dalam kebanyakan kasus. Regresi langka muncul pada matematika rantai pikir yang panjang kecuali aku menurunkan temperature.
Q4: penurunan 3–6 poin pada tugas pengetahuan; guncangan yang lebih terlihat pada matematika dan penalaran terstruktur. Untuk kode, Q4 baik untuk tugas edit-style, kurang baik untuk menulis fungsi yang lebih panjang dari awal.

Kesenjangan ini lebih kecil dari yang aku asumsikan sebelumnya, yang merupakan kejutan menyenangkan. Tetapi mereka muncul ketika kamu menumpuk prompt yang sulit.

Tugas mana yang toleran terhadap kehilangan kuantisasi

Di mana Q4 terasa baik bagiku:

Pembuatan konten, ringkasan, deskripsi produk.
Jawaban berbasis retrieval pendek di mana faktualitas berasal dari sumber.
Ideasi cepat di mana kecepatan mengalahkan presisi.

Di mana aku lebih suka Q8 atau BF16:

Penalaran multi-langkah dan matematika dengan kebutuhan kebenaran yang ketat.
Generasi kode panjang yang harus dikompilasi tanpa pembersihan.
Prompt apa pun di mana kamu sudah berjuang untuk determinisme dan perubahan kecil berdampak besar.

Jika kamu masih ragu, mulailah dengan Q8. Itu adalah default yang lebih aman. Turun ke Q4 setelah kamu melihat prompt nyata tetap stabil selama seminggu.

API vs Self-Host: Kalkulator Break-Even

Biaya sewa GPU vs biaya API pada volume berbeda

Aku membuat spreadsheet sederhana untuk diriku sendiri. Input yang penting adalah:

Tarif per jam GPU (H100 on‑demand yang aku gunakan berkisar $2,0–$3,5/jam; A100 $1,5–$2,5/jam; GPU konsumen lebih murah tetapi lebih rewel).
Token/detik efektif per GPU pada presisi pilihanmu (aku menggunakan rentang konservatif untuk MoE aktif ~37B: puluhan token/detik per GPU pada ukuran batch yang nyaman; lebih banyak dengan kuantisasi dan batching).
Utilisasi (seberapa sering kamu benar-benar membuat GPU sibuk).
Harga API per juta token (aku menguji skenario pada $1, $3, dan $5 per 1M token, karena provider sangat bervariasi).

Dua contoh cepat yang aku jalankan:

Penggunaan internal ringan: 5 juta token/bulan

API pada $3/1M ≈ $15/bulan. Self-hosting H100 bahkan untuk beberapa jam saja sudah melampaui itu. API menang.

Penggunaan lebih berat: 500 juta token/bulan

API pada $3/1M ≈ $1.500/bulan.
Satu H100 pada $3/jam, berjalan 24/7, biayanya ≈ $2.160/bulan. Tetapi jika dua 4090 terkuantisasi bisa menangani throughput-mu dan kamu menjalankannya on-prem, biaya marginalmu mungkin lebih rendah (daya + amortisasi), bukan sewa per jam. Di sinilah spreadsheet menjadi penting.

Biaya tersembunyi yang harus aku ingatkan untuk disertakan: waktu rekayasa (serving, pembaruan, kerusakan), observabilitas, dan fakta bahwa “satu model lagi” selalu muncul.

Pada berapa token/bulan self-hosting menguntungkan

Dengan asumsi di atas, self-hosting mulai terlihat masuk akal bagiku di sekitar 300–800 juta token/bulan, tergantung pada:

apakah aku bisa menjaga GPU >50% terpakai,
apakah Q4/Q8 menjaga kualitas tetap dapat diterima,
dan apakah aku sudah memiliki ops yang siap.

Jika penggunaanmu tidak teratur dan rendah, API hampir selalu menang. Jika kamu condong ke jalur itu, panduan praktis tentang cara menggunakan DeepSeek V4 melalui API ini memandu setup dan pola penggunaan tanpa menyentuh infrastruktur GPU.

Jika kamu menjalankan pekerjaan yang stabil (batch generation, prompt yang telah disetel, alat internal) dan bisa menjaga kartu tetap sibuk, self-hosting menjadi lebih menguntungkan lebih cepat. Aku tidak akan membeli hardware hanya untuk V4 kecuali aku tahu aku akan memberikannya beberapa ratus juta token per bulan setidaknya selama satu kuartal.