Cara Menjalankan DeepSeek-V4.1-Flash Secara Lokal

DeepSeek menempatkan bobot DeepSeek-V4.1-Flash di Hugging Face di bawah lisensi MIT pada 10 September 2026, pada hari yang sama model tersebut dirilis secara umum (GA) di API. Ini adalah waktu yang tidak biasa. Kebanyakan laboratorium mengirimkan *endpoint* yang di-hosting terlebih dahulu dan merilis bobot beberapa minggu kemudian, jika memang dirilis.

Angka utama akan menakut-nakuti sebagian besar pembaca: 552 miliar parameter di *backbone*, 763 miliar dengan *vision encoder*. Namun, desain di baliknya lebih ramah untuk *self-hosting* daripada yang disarankan oleh ukurannya. Hanya 8B parameter yang aktif selama *prefill* dan 16B selama *decode*, dan *cache* FP4 KV yang baru membutuhkan 890 byte per token, kira-kira seperempat dari yang dibutuhkan V4-Flash. Komputasi murah. Memori adalah batasnya.

Orang-orang akan mencoba bagaimanapun juga. Panduan ini memberi Anda perhitungan memori, jalur realistis pada setiap tingkatan perangkat keras, perintah penyiapan umum, dan cara untuk menguji *endpoint* lokal yang kompatibel dengan OpenAI terhadap API yang di-hosting di Apidog. Jika Anda ingin gambaran umum model terlebih dahulu, baca Apa itu DeepSeek-V4.1-Flash? dan kembali lagi.

button

TL;DR

Bobot: *backbone* MoE 552B, lisensi MIT. Sekitar 552 GB pada 8-bit, sekitar 280 GB pada 4-bit, hanya *backbone*.
*Cache* KV: 890 byte per token. Konteks 1M-token penuh membutuhkan sekitar 0,9 GB. Bagian itu sudah terpecahkan.
*Serving* 4-bit yang realistis membutuhkan 4 hingga 8 GPU di kelas 80 GB. Apapun di bawah itu adalah *offload* CPU atau SSD, dan lambat.
API yang di-hosting membebankan biaya $0,15 per 1M token masukan *cache-miss* di luar jam sibuk. Bagi sebagian besar tim, ini mengalahkan biaya listrik saja.

Apa yang Anda Unduh

Kartu model menjelaskan *backbone* Mixture-of-Experts 552B-parameter dengan tata letak Encoder-Decoder Kausal baru: 40 *layer*, dibagi 20 *encoder* dan 20 *decoder*. Setiap *layer* mengarahkan ke 384 *expert* ditambah 1 *expert* bersama. *Vision encoder* DeepSeek-ViT mendorong *checkpoint* penuh hingga 763B parameter, dan Anda mengunduh semuanya meskipun Anda hanya membutuhkan teks.

Tiga detail penting untuk inferensi lokal:

Parameter aktif kecil. 8B aktif selama *prefill*, 16B selama *decode*. FLOPs per token terlihat seperti model padat berukuran menengah. Masalahnya adalah setiap 552B parameter harus berada di suatu tempat yang dapat dijangkau oleh *forward pass*.
*Cache* KV adalah FP4. Catatan rilis mengatakan *cache* menggunakan 1/4 HBM dan 1/8 penyimpanan SSD dari generasi sebelumnya. Dengan 890 byte per token, konteks panjang bukan lagi masalah memori seperti dulu.
Perhatian dirancang secara jarang (sparse). Compressed Sparse Attention 2 dengan tiga mode statis dilatih pada konteks 64K dan diperluas menjadi 1M di akhir *run* 45T-token. Itulah mengapa angka KV tetap kecil pada 1M.

Laporan teknis mencakup arsitektur secara lengkap. Setiap angka *benchmark* pada kartu dilaporkan oleh DeepSeek; perlakukan angka-angka tersebut sebagai klaim.

Perhitungan Memori

Angka-angka di bawah ini adalah perkalian langsung, bukan pengukuran, dan tidak termasuk *overhead engine*, aktivasi, dan *vision encoder*.

Komponen	Ukuran	Cara perhitungan
Bobot backbone, 8-bit	~552 GB	552B parameter x 1 byte
Bobot backbone, 4-bit	~280 GB	552B parameter x 0,5 byte
Cache KV, per token	890 byte	Dari kartu model
Cache KV pada konteks 128K	~0,11 GB	890 x 128.000
Cache KV pada konteks 1M	~0,89 GB	890 x 1.000.000

Dua hal menonjol. Pertama, *cache* KV adalah kesalahan pembulatan. Sesi 1M-token muat di bawah satu gigabyte, jadi Anda dapat menampung lusinan sesi panjang tanpa menyentuh anggaran bobot. Kedua, bobot adalah keseluruhan masalah. Tidak ada trik kuantisasi yang membuat 552B parameter muat pada satu GPU konsumen, dan desain 8B-aktif tidak membantu, karena *routing* MoE masih membutuhkan setiap *expert* dimuat dan dapat diakses.

Itu juga mengapa pengaturan *offloaded* terasa tidak seimbang. *Prefill* memproses *batch* di seluruh *prompt* dan tetap terikat komputasi. *Decode* memuat 16B parameter aktif dari RAM atau SSD untuk setiap token. Bandwidth, bukan FLOPs, yang menentukan token per detik Anda.

Tingkatan Perangkat Keras Realistis

Tidak ada angka *throughput* di sini. Tidak ada orang di luar DeepSeek yang memiliki bobot cukup lama untuk mempublikasikan *benchmark* yang dapat dipercaya.

Tingkat 1: *server* multi-GPU, 4 hingga 8 kartu di kelas 80 GB. Empat kartu 80 GB memberi Anda 320 GB, cukup untuk bobot 4-bit dengan margin tipis untuk *cache* KV dan *overhead engine*. Delapan kartu memberi Anda 640 GB, cukup untuk *checkpoint* 8-bit atau *deployment* 4-bit yang nyaman dengan *batch* besar. Ini adalah satu-satunya tingkatan di mana "jalankan secara lokal" berarti *serving* tingkat produksi dengan paralelisme tensor, dan ini adalah pembelian lima atau enam digit atau sewa *cloud* multi-dolar per jam.

Tingkat 2: *workstation* memori tinggi tunggal dengan *offload* CPU. Sebuah kotak dengan RAM sistem 512 GB atau lebih dan satu atau dua GPU dapat menampung bobot 4-bit di RAM dan mengalirkan *expert layer* ke GPU sesuai permintaan. Ini berfungsi, dan lambat, karena *bandwidth decode* adalah bus DDR5 Anda alih-alih HBM. Gunakan untuk pekerjaan *batch* dan evaluasi semalaman, bukan obrolan interaktif.

Tingkat 3: Apple Silicon dengan *streaming* SSD. Jalur para penghobi. Mac Studio 512 GB menampung bobot 4-bit dalam memori terpadu, yang merupakan pilihan nyata jika Anda sudah memilikinya. Di bawah itu, Anda berada di wilayah thread Kimi K3 HN: bobot terbagi di seluruh SSD eksternal, *mmap* melakukan pekerjaan berat, sekitar 1 token per detik. Ini membuktikan model berjalan, bukan bahwa itu berguna di mesin itu. Panduan kami untuk menjalankan Kimi K3 secara lokal mencakup *trade-off* yang sama pada model yang lebih besar, dan cara menjalankan DeepSeek V4 secara lokal mencakup generasi sebelumnya.

Jalur Penyiapan

Dengan perangkat keras yang sudah tersedia, alurnya adalah: unduh, sajikan di balik *endpoint* yang kompatibel dengan OpenAI, uji.

pip3 install -U "huggingface_hub[cli]"
huggingface-cli download deepseek-ai/DeepSeek-V4.1-Flash \
  --local-dir ./models/deepseek-v4.1-flash \
  --max-workers 8

Pada jalur 1 Gbps, setiap 100 GB membutuhkan waktu sekitar 15 menit pada kecepatan penuh. Anggarkan satu jam atau lebih.

*Serving* adalah tempat peringatan berada. Dukungan hari-0 di vLLM, SGLang, llama.cpp, dan Ollama untuk arsitektur CED dan perhatian CSA2 adalah [VERIFIKASI]; jenis *layer* baru biasanya membutuhkan *patch engine* sebelum bobot dimuat, dan catatan rilis tidak menyebutkan *engine* spesifik. Cari *changelog* setiap proyek untuk “DeepSeek-V4.1” sebelum Anda berkomitmen untuk mengunduh. Setelah dukungan ada, *serving* dengan vLLM di 8 GPU terlihat seperti ini:

vllm serve ./models/deepseek-v4.1-flash \
  --tensor-parallel-size 8 \
  --max-model-len 131072 \
  --served-model-name deepseek-flash \
  --port 8000

Sebuah `llama-server` llama.cpp atau model Ollama mengekspos *endpoint* gaya `http://localhost:8000/v1` yang sama setelah konversi GGUF ada, jadi klien OpenAI SDK apa pun berfungsi dengan mengubah satu baris:

from openai import OpenAI

client = OpenAI(base_url="http://localhost:8000/v1", api_key="local")

response = client.chat.completions.create(
    model="deepseek-flash",
    messages=[{"role": "user", "content": "Summarize this incident report and list the three root causes."}],
    temperature=1.0,
    top_p=0.95,
)
print(response.choices[0].message.content)

Nilai `temperature=1.0` dan `top_p=0.95` cocok dengan pengaturan yang direkomendasikan kartu model. Untuk Ollama, panduan Ollama kami mencakup alur Modelfile, dan panduan vLLM mencakup *flag* multi-GPU secara mendalam.

Alternatif Pragmatis: API yang Di-hosting

Di luar jam sibuk, halaman harga mencantumkan `deepseek-flash` seharga $0,15 per 1M token masukan *cache-miss*, $0,003 per 1M token masukan *cache-hit*, dan $0,60 per 1M token keluaran. Jam sibuk menggandakan angka-angka tersebut. Jadi 1 miliar token masukan ditambah 200 juta token keluaran per bulan berharga sekitar $270 di luar jam sibuk dan $540 pada jam sibuk, sebelum *cache hit* menurunkan sisi masukan lebih jauh. Sebuah *server* 8-GPU di kelas 80 GB berharga lebih dari itu per bulan hanya untuk listrik dan pendinginan di bawah beban berkelanjutan, sebelum Anda mengamortisasi perangkat keras atau membayar seseorang untuk mengawasinya. Kecuali Anda memiliki aturan residensi data atau perangkat keras yang sudah tidak terpakai, API menang dalam hal biaya. Pergantiannya hanyalah satu perubahan `base_url`; panduan API DeepSeek-V4.1-Flash kami menjelaskannya.

Lokal menang ketika kendalanya bukan uang: lingkungan *air-gapped*, data *prompt* yang tidak dapat Anda kirim ke mana pun, atau penelitian yang perlu memodifikasi bobot.

Uji Endpoint Lokal terhadap API yang Di-hosting di Apidog

Jalur mana pun yang Anda pilih, buktikan bahwa *server* lokal berperilaku seperti referensi sebelum Anda mengarahkan lalu lintas ke sana. *Quantization drift*, *chat template* yang salah, atau *stop token* yang hilang semuanya muncul sebagai perbedaan *output* yang halus. Berikut adalah alur kerja di Apidog:

Buat dua lingkungan. Satu bernama `local` dengan `base_url` diatur ke `http://localhost:8000/v1`, satu lagi bernama `hosted` dengan `base_url` diatur ke `https://api.deepseek.com` dan kunci asli Anda. Setiap permintaan menggunakan `{{base_url}}/chat/completions` dan `Bearer {{api_key}}`.
Simpan set *prompt* kecil sebagai permintaan. Lima hingga sepuluh *prompt* yang mewakili beban kerja Anda: ekstraksi JSON, perbaikan kode, ringkasan konteks panjang. Atur `model` ke `deepseek-flash` di semuanya; ini berfungsi di kedua *server*.
Tambahkan *assertion*. Untuk tugas JSON, *assert* bahwa respons diurai dan kunci yang diperlukan ada. Untuk setiap permintaan, *assert* `finish_reason` sama dengan `stop`, yang menangkap pemotongan dari pengaturan konteks yang buruk.
Jalankan set terhadap kedua lingkungan. Alihkan *dropdown* lingkungan dari `hosted` ke `local` dan jalankan ulang skenario pengujian yang sama. Kegagalan yang hanya muncul di `local` adalah masalah kuantisasi atau *template* Anda, terisolasi dalam satu klik.
Tonton *streaming*. Atur `stream: true` dan gunakan tampilan SSE untuk melihat peristiwa tiba satu per satu. *Server* lokal yang menyangga seluruh respons sebelum mengirim akan terlihat baik pada panggilan non-*streaming* dan salah di sini.
Masukkan ke CI. Jalankan skenario dengan `apidog-cli` pada setiap peningkatan *engine*, sehingga *chat template* yang rusak akan menyebabkan *pipeline* gagal alih-alih pengguna.

Unduh Apidog dan seluruh alur berjalan dari satu proyek.

FAQ

Bisakah saya menjalankan DeepSeek-V4.1-Flash di laptop? Tidak terlalu berguna. *Backbone* 4-bit berukuran sekitar 280 GB. Sebuah laptop dapat mengalirkannya dari SSD seperti yang dilakukan eksperimen Kimi K3, dengan kecepatan sekitar 1 token per detik, yang merupakan demo, bukan alur kerja. Gunakan API atau salah satu pilihan di cara menggunakan DeepSeek-V4.1-Flash secara gratis.

Apakah 8B parameter aktif berarti saya hanya membutuhkan 8 GB VRAM? Tidak. Parameter aktif mengatur komputasi per token, bukan memori. *Routing* MoE dapat memilih salah satu dari 384 *expert* per *layer* untuk setiap token, jadi semua 552B parameter harus dimuat dan dapat dijangkau.

Berapa banyak memori yang dibutuhkan konteks 1M? Sekitar 0,89 GB *cache* KV pada 890 byte per token. Itu adalah bagian murah dari model ini. Bobot adalah bagian yang mahal.

Apakah lisensinya aman untuk penggunaan komersial? Ya. Bobotnya MIT, sesuai kartu model Hugging Face.

Kesimpulan

DeepSeek-V4.1-Flash bersifat *open* dalam hal yang penting secara hukum dan teknis: bobot MIT, laporan teknis publik, dan desain *cache* KV yang membuat sesi 1M-token hampir gratis dalam memori. Namun, ia tidak *open* dalam arti yang memungkinkan Anda menjalankannya di mesin di bawah meja Anda. Bagi sebagian besar tim, langkah yang tepat adalah API yang di-hosting seharga $0,15 per 1M token masukan di luar jam sibuk, dengan *deployment* lokal dicadangkan untuk data yang tidak dapat keluar dari gedung.

Bagaimanapun, uji sebelum Anda percaya. Arahkan Apidog ke kedua *endpoint*, jalankan permintaan yang sama yang tersimpan, dan biarkan *assertion* memberi tahu Anda apakah *build* lokal Anda cocok dengan referensi.