DeepSeek-V4.1-Flash: Modelin hafızasını küçültmek için mimariyi baştan düzenlemek

Ne çıktı?

DeepSeek 10 Eylül’de V4.1-Flash’ı duyurdu, teknik raporu da bir hafta sonra yayımladı. Ağırlıklar MIT lisansıyla Hugging Face’te. Model, uzmanlar karışımı (MoE) yapısında: Toplam 552 milyar parametrelik bir gövde var ama her token için bunun küçük bir kısmı çalışıyor. MoE’nin mantığını uzmanlar karışımı yazımızda anlatmıştık. Bağlam penceresi 1 milyon token, görüntüleri de doğrudan anlıyor.

Raporun başlığı neyin peşinde olduklarını söylüyor: KV cache sıkıştırmanın sınırlarını zorlamak.

Asıl dert: KV cache

Model bir metni okurken her token için bazı ara değerler hesaplayıp saklıyor. Bunlara KV cache deniyor, modelin kısa süreli hafızası gibi düşünebilirsin; kavramı oMLX yazısında ayrıntılı anlattık. Sorun şu: Bu hafıza bağlamla birlikte büyüyor ve ekran kartının en pahalı belleğinde (HBM) duruyor.

V4.1-Flash’ta her token için sürekli bellekte tutulan kısım yaklaşık 890 bayt. Bu, 1 milyon tokenlık bir konuşmanın bu kısmının kabaca 890 MB’a sığması demek. Rapora göre bu, V4-Flash’ın dörtte biri ve üç yıl önceki ilk DeepSeek modelinin 437’de biri. Diske yazılan kalıcı kısım da V4-Flash’ın sekizde biri.

Fikir 1: Katmanlar hafızayı paylaşıyor

Normalde modelin her katmanı kendi hafızasını tutar. V4.1-Flash’taki CSA2 adlı dikkat (attention) yönteminde katmanlar gruplara ayrılıyor. Grubun ilk katmanı hafızayı hesaplıyor ve geçmişteki tokenlardan en alakalı 512 tanesini seçiyor. Arkasından gelen katmanlar hem o hafızayı hem de o seçimi aynen kullanıyor. Sonuçta 40 katmanın sadece 8’i kendi seçimini yapıyor, 30’u bir öncekinin işini devralıyor.

Zor tarafı, farklı katmanların geçmişe farklı gözle bakması gerekmesi. Bu yüzden her katman yine kendi sorgusunu (query) hesaplıyor: Hafıza ortak, ama ona sorulan soru katmana özel.

Fikir 2: Hafızayı 4 bitle tutmak

Ortak hafızanın kendisi de küçültülüyor. Değerler, NVIDIA’nın NVFP4 formatına çok benzeyen bir şekilde 4 bitle saklanıyor: Her 16 değere bir ölçek çarpanı. V4’te bu hafıza 8 bitti, yani yer yarıya iniyor. Model bu sıkıştırmaya alışsın diye eğitimin son aşamasında da aynı formatla çalıştırılıyor. 4 bitin neden zor olduğunu NVFP4 yazısında anlattık.

Fikir 3: Prompt’u modelin yarısı okuyor

40 katman ikiye bölünmüş: 20 katmanlık bir encoder ve 20 katmanlık bir decoder. Decoder’ın ihtiyaç duyduğu hafıza, doğrudan encoder’ın son çıktısından üretiliyor. Bu yüzden uzun bir prompt’u okurken tokenların çoğu sadece encoder’dan geçiyor. Okuma sırasında token başına 8 milyar, cevap yazarken 16 milyar parametre çalışıyor. Rapora göre okuma maliyeti neredeyse yarıya iniyor.

Peki daha iyi mi?

Taban modelleri karşılaştıran tabloda tablo karışık. V4.1-Flash, kendisinden üç kat büyük V4-Pro’yu MMLU-Pro ve HumanEval’de geçiyor. Ama bilgi sorularında (SimpleQA) ve uzun metin testinde (LongBench-V2) geride. DeepSeek yine de kendine güveniyor: 14 Eylül’den itibaren API’de V4-Pro’ya gelen istekleri V4.1-Flash’a yönlendirdi.

Two Minute Papers’ın denemelerine göre model uzun düşünüyor ve çok token harcıyor. 552 milyar parametreyle evde çalıştırmak da gerçekçi değil.

Aynı takıntı, başka bir yol

DeepSeek’in hafıza konusundaki ilk deneyi bu değildi. Two Minute Papers’ın ele aldığı DeepSeek-OCR (Ekim 2025), uzun metni görüntüye çevirip daha az tokenla saklamayı denemişti. Makaleye göre yaklaşık 10 kat sıkıştırmada metnin %97’si geri okunabiliyor, 20 katta bu oran %60’a düşüyor. V4.1-Flash başka bir teknikle ama aynı soruya cevap arıyor: Model daha azını hatırlayarak aynı işi yapabilir mi?

DeepSeek’in bu modeli sunduğu çıkarım motorunu Ekim’de açmasını DeepInfer yazısında anlattık.

Düşün

• Bir ajan saatlerce çalışırken modele okuttuğu metin mi daha çok, yazdırdığı metin mi? Bu, model seçerken neye bakman gerektiğini nasıl değiştirir?
• Katmanların hafızayı paylaşması, bir ekipte herkesin aynı not defterini kullanmasına benziyor. Bunun avantajı ve riski ne olabilir?

Kendi cümlelerimizle yazılmış bir özettir, çeviri değildir. Tüm kaynaklar yukarıda.