Daha az token değil. Daha doğru hesap.

Bir LLM isteğinin ekonomisi: prefill ve decode aynı iş değildir

Bir inference isteği en az queue, prefill, first-token ve autoregressive decode fazlarına ayrılır. Prefill bütün input token’larını paralel işleyip attention durumunu ve KV cache’i üretir; uzun bağlamlarda compute yoğun olabilir ve Time to First Token’ı büyütür. Decode ise her yeni token için geçmiş K/V bloklarını tekrar okur; çıktı uzadıkça bellek bant genişliği ve seri bağımlılık öne çıkar. Bu yüzden yalnız uçtan uca ortalama latency, darboğazın bağlam mı, üretim mi, queue mu olduğunu söylemez.

İzlenmesi gereken minimum ayrım TTFT, inter-token latency veya TPOT, input/output token, cached token, queue süresi ve p50/p95/p99’dur. FlashAttention exact attention’ı IO-aware tiling ile hızlandırır; FlashInfer serving senaryoları için özelleştirilebilir attention kernel’leri sunar. [10] [11] Bunlar prompt kısaltmanın yerine geçmez: kernel, scheduler, cache ve bağlam seçimi farklı katmanlarda çalışır. Optimizasyonun ilk kuralı, hangi fazın baskın olduğunu gerçek trafik dilimlerinde ölçmektir.

KV cache ve prefix caching: hesaplanmış bağlamı yeniden kullanmak

Autoregressive model her yeni token’da geçmiş token’ların key/value temsillerini yeniden hesaplamak yerine KV cache’den okur. Bu, decode’u mümkün kılar fakat aktif her sequence için katman × head × token boyunca bellek tüketir. PagedAttention, KV bloklarını işletim sistemindeki sanal bellek gibi sabit boyutlu sayfalara ayırarak fragmentation ve rezervasyonu azaltır; vLLM çalışması kendi deneylerinde güçlü serving kazanımları raporlar, fakat oranlar model ve donanıma özgüdür. [01] KIVI gibi yöntemler KV cache’i düşük bite quantize ederek kapasiteyi büyütmeyi araştırır; kalite etkisi görev üzerinde doğrulanmalıdır. [09]

Prefix caching, aynı başlangıç token dizisinin KV bloklarını istekler arasında yeniden kullanır. Sistem talimatı, tool şemaları, rol kriterleri veya ortak doküman bağlamı sabitse prefill maliyeti tekrar edilmeyebilir. Fakat cache ancak gerçekten eşleşen prefix’te çalışır; dinamik veriyi başa eklemek, tool tanımında küçük değişiklik veya tenant/sürüm sınırını cache anahtarına katmamak hem hit oranını hem güvenliği bozar. vLLM, OpenAI, Anthropic ve Gemini dokümantasyonları farklı caching davranışları sunar; TTL, fiyat ve saklama şartları uygulama anında resmi kaynaktan doğrulanmalıdır. [02] [12] [14] [16]

• Statik talimat ve şemaları başa, değişken vaka verisini sona koy.
• Cache key’e tenant, politika, belge ve sürüm sınırlarını dahil et.
• Hit oranını token ağırlıklı ölç; istek sayısı tek başına yanıltır.
• Cache hit’i kalite sinyali sanma; kaynak ve sürümü ayrıca doğrula.

Speculative decoding: küçük model önerir, hedef model doğrular

Speculative decoding, daha ucuz draft modelin birden çok token önermesini ve hedef modelin bunları tek paralel doğrulama geçişinde sınamasını sağlar. Leviathan ve arkadaşlarının yöntemi kabul/ret düzeltmesiyle hedef model dağılımını korur; kazanç draft hızına, acceptance rate’e ve doğrulama maliyetine bağlıdır. [03] Draft model hedefin devamını iyi öngöremiyorsa, ek draft ve verification işi latency’yi azaltmak yerine artırabilir.

Bu nedenle production telemetry accepted tokens per draft step, acceptance rate, target verification süresi ve concurrency altında GPU verimini birlikte izlemelidir. Uzun, düşük entropili ve biçimi belirgin çıktılarda kabul oranı yüksek olabilir; yaratıcı veya alan dışı görevlerde düşebilir. Sağlayıcı ya da açık kaynak engine’in ‘speculative’ etiketi exact-distribution garantisi anlamına gelmez; tree-based, n-gram veya approximate varyantlar ayrı değerlendirilmelidir. En güvenli karar, aynı kalite test setinde p95 latency ve toplam compute’u A/B ölçmektir.

Context compression: token silmek değil, karar için kanıtı korumak

Uzun context’in pencereye sığması modelin bütün kanıtı eşit kullandığı anlamına gelmez. Lost in the Middle, ilgili bilgi context ortasında olduğunda performansın düşebildiğini gösterdi. [06] LLMLingua ve LongLLMLingua, düşük bilgi taşıyan token’ları seçerek prompt compression araştırır. [04] [05] Ancak CV kanıtı, sözleşme istisnası, tutar, tarih ve kaynak sürümü kaybolduğunda daha ucuz çağrı daha pahalı bir iş hatası üretir. Compression modeli de latency, maliyet ve kendi hata yüzeyini ekler.

Nekibu için önce kayıpsız temizlik uygulanmalıdır: tekrar, boilerplate, gereksiz serialization ve eski tool çıktıları kaldırılır. Ardından retrieval ve reranking görevle ilgili parçaları seçer. Para, tarih, para birimi, oran, yükümlülük, eşik ve kaynak URI gibi korunan alanlar deterministik/şemalı çıkarılır; üretken özet bunlara bağlanır. Her silme kararının gerekçesi ve sıkıştırma öncesi/sonrası token sayısı trace’de kalır. Aynı dokümanın her görev için tek ideal özeti yoktur; bağlam derleme sorgu ve risk bağımlı olmalıdır.

Batching, scheduling ve routing: GPU’yu doldururken kullanıcıyı bekletmemek

Sabit batch’te kısa istekler uzun isteği bekler ve boşalan kapasiteye yeni sequence hemen giremez. Orca, iteration-level scheduling ile batch üyeliğini her decode adımında düzenler; kendi GPT-3 deneyinde belirgin throughput kazanımı raporlamıştır. [07] Prefill ve decode aynı batch’te karıştığında uzun prefill, devam eden kullanıcı decode’unu duraklatabilir. Sarathi-Serve, prefill’i chunk’lara bölüp decode ağırlıklı batch’e yerleştirir; raporlanan serving capacity kazanımları kendi model/donanım düzeniyle sınırlıdır. [08] Scheduler maksimum throughput’a değil p95/p99 SLO’larına göre ayarlanmalıdır.

Model routing her isteği en güçlü modele göndermemeyi hedefler; fakat kolay soru = ucuz model sezgisi güvenli değildir. RouteLLM tercih verisiyle güçlü/zayıf model arasında yönlendirme araştırır ve distribution shift altında router’ın bozulabileceğini de gösterir. [09] Üretim router’ı görev tipi, bağlam, risk, geri döndürülebilirlik, belirsizlik, şema doğrulaması ve fallback’i birlikte kullanmalıdır. Kesin kurallar deterministik katmana; yüksek hacimli iyi tanımlı dönüşümler ekonomik modele; çelişkili veya yüksek etkili karar desteği güçlü model ve gerektiğinde insan onayına yönlenmelidir.

Nekibu ürünleri için uygulanabilir inference mimarisi

ATS’de rol kriterleri, rubrik, çıktı şeması ve tool tanımları statik prefix; aday CV’si ve güncel soru dinamik bölüm olabilir. Yüksek hacimli ilk geçiş ekonomik model veya asenkron batch ile; eksik/çelişkili kanıt güçlü model ve inceleyiciyle yürütülür. Studio’da her workflow düğümü ayrı kalite ve latency bütçesi taşır; kesin kontroller modelden çıkarılır, bağımsız düğümler paralelleştirilir. Documents’ta ham dosya her soruda serialize edilmez; retrieval az fakat yetkili parça getirir ve cache doküman sürümü/ACL ile namespace edilir. Procurement’da sayılar şemalı çıkarılır, model doğrulanmış alanlar üzerinden açıklama üretir.

Ortak hat yetki ve görev sınıflandırma ile başlar; retrieval/korunan alanlar/compression bağlam paketini üretir; versionlanmış prefix cache anahtarı kurulur; risk-temelli router online scheduler veya async batch yolunu seçer; inference ardından şema, kaynak ve deterministik kurallar doğrulanır; gerekirse insan onayı alınır. Trace input/output/cached token, model route’u, queue/TTFT/TPOT, tekrar, kaynak kapsamı, şema sonucu ve insan override’ını aynı karar kimliğinde toplar.

• ATS: aday başına token değil, geçerli kanıtla tamamlanan değerlendirme başına maliyet.
• Studio: node başına model, SLO, retry ve insan onayı politikası.
• Documents: doğru sürüm ve ACL doğrulanmadan cache hit başarı değildir.
• Procurement: en az token değil, aynı karar dosyası kalitesinde en düşük toplam işlem maliyeti.

Kalite – maliyet – gecikme: tek skor değil Pareto yüzeyi

En düşük maliyetli konfigürasyon en yavaş veya düşük kaliteli; en hızlı konfigürasyon düşük batch verimi nedeniyle pahalı olabilir. Optimizasyon model, prompt, retrieval bütçesi, cache, scheduler ve decode ayarlarından oluşan x konfigürasyonunda beklenen maliyeti minimize ederken görev kalitesini, TTFT/uçtan uca SLO’yu ve kritik risk sınırını koruyan kısıtlı problemdir. Genel chatbot puanı yerine ATS’de kriter-kanıt uyumu, Documents’ta kaynak/sürüm doğruluğu, Procurement’da sayısal doğruluk, Studio’da doğru tool/parametre ve task success ölçülmelidir.

Deney için kişisel verisi giderilmiş gerçek trafik replay kümesi oluşturulur; baseline model sürümü, prompt, concurrency ve donanımla dondurulur; her deneyde tek kaldıraç değiştirilir; ortalama yerine p95/p99 ve görev dilimleri raporlanır. Maliyet kazancı yalnız kalite alt sınırı sağlandığında kabul edilir. Router ve compression yeni/az görülen görevlerle OOD testine sokulur. Sağlayıcı fiyatı, cache davranışı veya model sürümü değiştiğinde eski oran kalıcı ürün iddiası yapılmadan benchmark yenilenir.