---
title: "Token Düzeyinde LLM Yönlendiricileri Neden Zamanlarının %95'ini Önbellek Yönetimine Harcıyor?"
url: https://blog.edumints.com/token-duzeyinde-llm-yonlendiricileri-neden-zamanlarinin-95-ini
category: "LLM"
date: 2026-10-12T07:23:01.191Z
publisher: Edumints Blog
lang: tr-TR
source_name: "dev.to"
source_url: https://dev.to/reidmarlow/why-token-level-llm-routers-spend-95-of-their-time-on-cache-bookkeeping-5959
---

# Token Düzeyinde LLM Yönlendiricileri Neden Zamanlarının %95'ini Önbellek Yönetimine Harcıyor?

Üretim ortamındaki LLM yönlendiricilerinin (Cursor, RouteLLM vb.) büyük bölümü **prompt sınırında** çalışır. Bir sınıflandırıcı görevin zorluğunu baştan tahmin eder ve seçilen tek bir model yanıtın tamamını üretir. Ancak güncel algoritmik çalışmalar daha ince taneli bir yaklaşımı öne çıkarmaktadır: Zorlu akıl yürütme istemlerinde bile üretilen token'ların çoğu kalıp ifadelerden (değişken isimleri, sözdizimi, standart import'lar) ibarettir ve 32B ya da 70B'lik dev modellere ihtiyaç duymaz.

**R2R** gibi algoritmalar sayesinde 1.5B'lik küçük bir model token'ların %95'ini çözebilir; yalnızca %5'lik kritik ve yüksek entropili dallanma token'larını 32B'lik modele devreder. Böylece AIME matematik testlerinde 32B modelin başarımına ulaşılır. Geleneksel sorgu düzeyindeki yönlendiriciler ise aynı başarıyı yakalamak için istemlerin yaklaşık %40'ını bütünüyle büyük modele göndermek zorundadır.

## Sunucular Arası Geçiş ve Kaybolan Milisaniyeler

Böylesi büyük bir tasarruf potansiyeline rağmen token düzeyinde yönlendirme pratikte neredeyse hiç kullanılmaz. Çünkü **vLLM** ve **SGLang** gibi standart çıkarım motorları, bir isteğin baştan sona tek bir modele ait olduğunu varsayar. İki ayrı sunucu birbirine bağlanıp istek her birkaç token'da bir ileri geri aktarıldığında işleme hacmi (throughput) çöker.

Tsinghua ve Carnegie Mellon Üniversitesi araştırmacılarının yayımladığı **TokenRouter** çalışması, SGLang 0.5.1 üzerinde bu gecikmeleri analiz ederek mevcut uygulamalardan 2.01 kat ila 64.15 kat daha yüksek kod çözme verimi sağlayan bir altyapı inşa etmiştir.

Standart bir kurulumda (Qwen3-0.6B ve Qwen3-32B sunucuları arasında harici bir Python dağıtıcısıyla), küçük model her belirsiz token'da isteği duraklatır, bağlamı büyük modele iletir ve yanıtı bekler. İstek küçük modele döndüğünde, sunucu bunun duraklatılmış bir istek olduğunu bilmez; sıfırdan gelen yeni bir istem (`extend`) gibi işler.

2.048 token'lık bir üretimin son 128 adımı incelendiğinde gecikme tablosu şöyledir:
- **Küçük model çıkarımı:** Yalnızca 1.56 ms (%4.20)
- **RadixCache güncellemesi:** 12.12 ms (%32.62)
- **Önek eşleme (Prefix matching):** 7.78 ms (%20.94)
- **Önbellek düğümlerini kilitleme:** 6.49 ms (%17.47)
- **Kilitleri serbest bırakma:** 5.13 ms (%13.81)

Çalışma süresinin **%95'inden fazlası**, sadece 5 ms önce GPU belleğinde olan bir istek için Radix ağacı kilit çekişmesi ve önek eşleme bürokrasisine harcanmaktadır. Maksimum çıktı uzunluğu 8.192 token'a çıktığında, kapasitenin %58.1 ila %85.2'si yalnızca önekleri yeniden taramak yüzünden kaybolur.

## Tek Bir Yanıt Paylaşılırken Çöken Varsayımlar

Önbellek tıkanıklığının ötesinde, tek modelli çıkarım motorlarının temel varsayımları bozulur:
- **Adım Senkronizasyonunun Bozulması:** 0.6B modeli (adım başına 6.0 ms) ile 32B modeli (adım başına 27.9 ms) eşleştiğinde, senkron bariyerler küçük modelin her adımda büyük modeli bekleyerek 22 ms atıl kalmasına neden olur.
- **Sürekli Toplu İşleme (Continuous Batching) Aksaklıkları:** İsteklerin kabul (admission) ve zamanlama süreçleri modeller arası sürekli geçişler sebebiyle sekteye uğrar.

## Yazılım Geliştirme Açısından Çıkarımlar

- **Sistem Düzeyi Darboğazlar:** Teorik algoritmik kazançlar, alttaki bellek kilitleri ve KV-cache yönetimi hesaba katılmadığında üretimde ciddi gecikmelere yol açabilir.
- **Önbellek Farkındalığı:** Çok modelli mimarilerde isteklerin durumunu (state) koruyan ve gereksiz önek eşlemelerini engelleyen paylaşımlı önbellek protokolleri tasarlamak kritik bir gereksinimdir.



---

Bu konuyu derinlemesine öğrenmek isterseniz: [Ölçeklendirme ve Optimizasyon](https://edumints.com/kesfet/embedding-ve-reranking-modelleri-productionda-depl-blu6) modülüne göz atın.

---

**Kaynak:** dev.to (https://dev.to/reidmarlow/why-token-level-llm-routers-spend-95-of-their-time-on-cache-bookkeeping-5959)
**Yayıncı:** [Edumints Blog](https://blog.edumints.com) · Alıntılarken bu URL'ye bağlantı verin: https://blog.edumints.com/token-duzeyinde-llm-yonlendiricileri-neden-zamanlarinin-95-ini