Ollama'da bildirilen 13.826 tok/s prefill hızı aslında cache hesabından dolayı 43'tü

dev.to'da yayımlanan bir yazı, yerel model throughput'unun Ollama üzerinden nasıl ölçüldüğüne dair yeniden üretilebilir bir kusuru belgeliyor: aynı daemon'a yaklaşık otuz saniye arayla iki kez gönderilen aynı prompt, ilk istekte saniyede 2.272 token, ikincisinde ise 13.826 token bildirilen bir prefill hızı üretti — oysa ikinci isteğin gerçek hızı kabaca saniyede 43 tokendi.

Ollama 0.34.0 ve qwen2.5:7b ile yapılan testte, yazıya göre bu uçurumun kaynağı, birimleri artık örtüşmeyen iki API alanı. prompt_eval_count promptun tam uzunluğunu bildiriyor — testte 318 token — buna karşılık prompt_eval_duration yalnızca daemon'un gerçekten hesapladığı tokenları zamanlıyor. Warm istekte bu 318 tokenın 317'si KV cache'ten sunulduğu için, 23 milisaniyelik hesaplama, tüm bir prompta ait token sayısına bölünmüş oldu.

Şişirme oranı cache'inizle ölçekleniyor

Hata sabit bir yük değil. Yazarın ortaya koyduğu gibi, şiştirme çarpanı tam olarak toplam prompt token sayısının cache'lenmemiş token sayısına oranı, yani cache isabet oranı. Cache ne kadar iyi çalışırsa, sayı o kadar çok yalan söyler: soğuk bir prompt dürüstçe raporlanırken, tamamen ısınmış bir prompt kabaca sistem promptunun uzunluğu kadar sapar. Bir konuşma boyunca saniyede prefill tokenı çizen her dashboard, aslında kendi cache isabet oranını çizip buna throughput etiketi yapıştırıyor.

Düzeltme tek bir çıkarma işlemi: geçen süreye bölmeden önce toplamdan cache'lenmiş sayıyı çıkarın. Yazı, Ollama'nın dahili Metrics.Summary() fonksiyonunun oranı zaten bu şekilde hesapladığına dikkat çekiyor; yani daemon kendisiyle çelişmiyor — yalnızca yanlış bir birleşime davet eden iki alan açığa çıkarıyor ve bariz olan birleşimi mevcut kodların çoğu zaten kullanıyordu.

İki uç durum işaret edilmiş. 0.33.3'ten eski daemon'lar prompt_eval_cached_count alanını hiç döndürmüyor ve eksik bir alanı sıfıra varsaymak, "bilinmiyor"u sessizce "hiçbir şey cache'lenmedi" şeklinde kendinden emin bir iddiaya dönüştürüyor. Ve tüm tokenlar cache'lendiğinde hiç prefill hızı yoktur — yazar, sıfır ya da sonsuz yerine hiçbir şey raporlanmasını savunuyor.

Üç endpoint, üç isim

Cache'lenmiş token sayısı her API'de farklı bir isimle karşımıza çıkıyor. Native /api/chat endpoint'i buna prompt_eval_cached_count diyor, OpenAI uyumlu endpoint usage.prompt_tokens_details.cached_tokens olarak raporluyor, Anthropic uyumlu endpoint ise usage.cache_read_input_tokens olarak açığa çıkarıyor. Yazarın testlerinde üçü de aynı warm prompt için 317 döndürdü.

Anthropic uyumlu yüzey ekstra bir tuzak barındırıyor: 318 tokenlık bir prompt için input_tokens: 1 döndürdü, çünkü o alandaki anlam toplam eksi cache okumaları. Yükü tahmin etmek için bunu tur tur toplayan biri, iki alanı birlikte eklemedikçe warm turların neredeyse hiç katkı yapmadığını görür.

Prompt düzeni ölçülebilir hale geliyor

Cache sayıları okunabilir hale gelince yazar, değişen tek bir zaman damgası içeren 227 tokenlık bir gövdeyle prompt düzenini test etti. Zaman damgası öndeyken yalnızca 40 token yeniden kullanıldı ve prefill 41,2 ms sürdü; arkadayken 211 token yeniden kullanıldı ve prefill 16,3 ms sürdü — yalnızca yerleşimden kaynaklanan 2,5 katlık bir fark. Öndeki durumda hâlâ yeniden kullanılan 40 token, kullanıcının içeriğinden değil, sohbet şablonunun kararlı başlangıç bölümünden geliyordu.

Pratik kural gösterişsiz: kararlı metni öne, oynak değerleri — tarihler, oturum ID'leri, tur başına alınan parçalar — en sona koyun.

Yazar başlangıçtaki metodolojik bir hatayı da itiraf ediyor: cache'i bir prompt düzeniyle ısıtıp farklı bir düzenle ölçmek tersine dönük bir sonuç üretti. Sağlam yaklaşım, aynı düzeni iki kez göndermek, gönderimler arasında yalnızca oynak değeri değiştirmek ve ikinci isteği ölçmektir; çünkü gerçek trafik iki düzen arasında gidip gelmek değil, bir düzeni tekrarlar.

Neden önemli

Saniye başına token sayısı yerel çıkarım için ana metrik ve karşılaştırmalara, kapasite planlamasına, dashboardlara besleniyor. Bir test araçları bütünü toplam prompt token sayısını, cache'lenmiş işi hariç tutan bir süreye bölerse, her warm-cache ölçümü cache isabet oranı kadar — büyüklük mertebeleri kadar — şişirilir ve modeller ya da makineler arası karşılaştırmalar anlamsızlaşır. Yazıdaki sayılar tek bir makineden geldiği için büyüklükler değişecektir ama hatanın yönü değişmez. Apache-2.0 lisanslı yerel gözlemlenebilirlik aracı LLMxRay'ı geliştiren yazar, prefill hızı raporlayan herkese, kodlarının hangi çıkarma işlemini yaptığını kontrol etmek için otuz saniye ayırması çağrısında bulunuyor.