DSpark: DeepSeek spekülatif kod çözmeyi kalabalık bir sunucuya göre yeniden tasarladı

Ne çıktı?

DeepSeek 6 Temmuz’da DSpark makalesini arXiv’e koydu. Hazırlık birkaç gün önce başlamıştı: Haziran sonunda DeepSpec adlı eğitim deposu MIT lisansıyla GitHub’a, DeepSeek-V4-Flash ve V4-Pro’nun DSpark modülü eklenmiş sürümleri de Hugging Face’e çıktı. Depoda DSpark’ın yanında iki eski yöntem (Eagle3 ve DFlash) de var, Qwen3 ve Gemma 4 için eğitilmiş taslak modellerle birlikte.

Önce temel fikir

Dil modeli cevabı token token yazıyor ve her token için büyük modelin baştan sona çalışması gerekiyor. Spekülatif kod çözmede (speculative decoding) küçük bir taslak model (drafter) önce birkaç token tahmin ediyor. Büyük model bunların hepsini tek seferde kontrol ediyor (verification). Tutan tokenlar kabul ediliyor, ilk yanlıştan sonrası atılıyor ve büyük model oradan kendi tokenını yazıyor. Kabul kuralı sayesinde çıktı, büyük modelin tek başına üreteceği dağılımla aynı. Kaç token tuttuğuna kabul uzunluğu deniyor, kazanç da buradan geliyor. Temel mantığı Muse Glimmer yazısında da anlattık.

Sorun 1: Taslak tokenlar birbirini görmüyor

İki tür taslak model var. Eagle3 gibi otoregresif olanlar tokenları sırayla, birbirine bakarak üretiyor: tutarlı ama yavaş. DFlash gibi paralel olanlar bütün bloğu tek geçişte üretiyor: hızlı ama her pozisyon ötekilerden habersiz. Makaleye göre bu yüzden bloğun ilerisine doğru kabul olasılığı düşüyor. DFlash’ta kod işlerinde 0,87’den 0,78’e, sohbette 0,72’den 0,63’e iniyor.

DSpark paralel gövdeyi koruyup arkasına çok hafif bir sıralı katman ekliyor. Varsayılan sürümde her token sadece bir önceki tokena bakarak kendi tahminini düzeltiyor. Makale buna yarı otoregresif üretim diyor. Hız büyük ölçüde paralel kalıyor, tutarlılık artıyor.

Sorun 2: Kalabalık sunucuda uzun taslak pahalı

Tek kullanıcıda uzun taslak neredeyse bedava. Ama binlerce istek aynı anda işlenirken, tutmayacak her taslak token GPU’da başka bir kullanıcıya ayrılabilecek yeri kaplıyor. Makaleye göre DeepSeek bu yüzden üretimde sadece tek tokenlık bir taslakla (MTP-1) çalışıyordu, çünkü daha uzun sabit taslaklar yoğun trafikte toplam verimi düşürüyordu.

DSpark’ın cevabı güvene göre zamanlanmış doğrulama. Taslak model her token için “bu tutar mı?” olasılığını da tahmin ediyor. Motor, açılışta ölçtüğü bir hız tablosuna bakarak bütün istekler arasında en olası tokenları seçiyor ve toplam verim artmayı bıraktığı anda duruyor. Yani kolay bir istekte daha uzun, zor bir istekte daha kısa bir taslak kontrol ediliyor.

Rakamlar

• Laboratuvarda: Qwen3 4B, 8B ve 14B’de dokuz test ortalamasında kabul uzunluğu Eagle3’e göre %26,7–30,9, DFlash’a göre %16,3–18,4 daha fazla.
• Canlı hizmette: MTP-1’e göre, aynı toplam verimde kullanıcı başına hız V4-Flash’ta %60–85, V4-Pro’da %57–78 artmış. Kullanıcıya saniyede 80 token sözü verildiğinde V4-Flash’ın toplam verimi %51 yükselmiş.

Bunlar DeepSeek’in kendi ölçümleri. Hangi GPU’larda yapıldığı yazmıyor. Makale bir sınırı da açıkça söylüyor: Zor sorularda tutmayan taslağı üretmenin maliyeti boşa gidiyor.

Hız ile toplam verim arasındaki bu pazarlık neden önemli, DeepInfer yazısında rakamlarla anlattık.

Sonra ne oldu?

DSpark DeepSeek’in standart parçası oldu. 31 Temmuz’da yayımlanan V4-Flash-0731 aynı modülle geliyor. V4.1-Flash’ın model kartı DSpark’ı mimarinin bir parçası olarak sayıyor. Ekim’de açılan DeepInfer motorunun özellik listesinde de “DSpark and confidence-scheduled verification” var, varsayılan en uzun taslak da makaledeki üretim ayarı gibi 5 token.

Düşün

• Kendi kullandığın bir modelde cevapların ne kadarı tahmin edilebilir? Kod mu, sohbet mi daha kolay tahmin edilir, neden?
• Bir sağlayıcı “kullanıcı başına saniyede X token” dediğinde, aynı anda kaç kullanıcıya hizmet verdiğini bilmeden bu rakam ne anlatır?

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