Kodlama aracılarında çok modelli yönlendirme stratejisi

Çok modelli yönlendirmenin bir kodlama aracısı üzerindeki etkisi

Çok modelli yönlendirme, her isteği o isteği işleyebilecek en ucuz modele gönderir. Sohbet trafiğinde bu yöntem iyi çalışır. Bir kodlama aracısında ise genellikle tasarruf ettiğinden daha fazla maliyete yol açar; çünkü bir aracının faturası, model başına önbelleğe alınan bir istem öneki (prompt prefix) tarafından domine edilir ve modeller arasında geçiş yapmak bu önbelleği geçersiz kılar.

Bu yazının savunduğu kural şudur: Erişilebilirlik için sağlayıcılar arasında yönlendirme yapın, maliyet için yalnızca görev sınırlarında katmanlar arası yönlendirme yapın ve aracı tabanlı her türlü işlem için oturum başına tek bir model sabitleyin. Aşağıdaki tüm içerik bu mantığın gerekçesidir.

Dört terim, bir kez tanımlanmıştır. Yönlendirici (router), her istek için bir model seçer. Ağ geçidi (gateway), isteğin içinden geçtiği ve yönlendirme yapıp yapmayabileceği proxy'dir. İstem önbelleği (prompt cache), isteminizin işlenmiş öneki saklayan sağlayıcıdır; böylece bu öneki tekrarlayan sonraki bir istek, girdi fiyatının bir kısmıyla faturalandırılır. KV önbelleği (key value cache), kendi çalıştırdığınız bir sunucu içinde aynı mantığı ifade eder.

Sohbet trafiği neden iyi yönlendirilirken aracı trafiği yönlendirilemiyor

Bir sohbet isteği tek bir turdan oluşur. İstek gelir, sınıflandırılır, bir modele iletilir ve yanıt döner. Bir sonraki isteğe hiçbir veri aktarılmaz. Bir yönlendirici (router), bu soruyu küçük bir modele, bir sonrakini ise büyük bir modele gönderebilir; isteklerin hiçbiri diğerinden haberdar olmaz. Neredeyse tüm yönlendirme kıyaslama testlerinin ölçtüğü iş yükü budur ve iyi yönlendiriciler bu konuda gerçekten başarılıdır.

Bir aracı (agent) turu tek bir istekten ibaret değildir. "Başarısız olan testi düzelt" gibi tek bir talimat, yirmi ila altmış adet API çağrısına dönüşür. Her çağrı tüm konuşmayı yeniden gönderir: sistem istemi (system prompt), her araç tanımı, aracının okuduğu her dosya ve gördüğü her komut çıktısı. Bağlam (context) sürekli büyür. Otuzuncu çağrıya gelindiğinde, tekrarlanan önek (prefix) on binlerce token'a ulaşırken, her çağrıdaki gerçekten yeni içerik sadece birkaç yüz token'dır.

Bu yapı, "pahalı" kelimesinin anlamını değiştirir. Sohbetlerde maliyet, kabaca modelin fiyatı ile isteğin çarpımıdır. Bir aracı döngüsünde ise maliyet, her çağrıda yeniden faturalandırılan önektir. Bu yazının geri kalanı, bu tek gerçeğe dayanmaktadır.

İstem önbelleği modele özeldir ve aracı bunun içinde yaşar

Anthropic, bir önbellek okuma işlemini temel girdi fiyatının 0,1 katı, beş dakikalık bir önbellek yazma işlemini ise 1,25 katı olarak fiyatlandırır. Bunlar, Ağustos 2026 itibarıyla yayınlanan liste fiyatlarıdır.

[
  {
    "label": "Opus 5",
    "uncached_input_usd": "5.00",
    "cache_read_usd": "0.50"
  },
  {
    "label": "Sonnet 5",
    "uncached_input_usd": "2.00",
    "cache_read_usd": "0.20"
  },
  {
    "label": "Haiku 4.5",
    "uncached_input_usd": "1.00",
    "cache_read_usd": "0.10"
  }
]

İkinci seriyi birincisine göre, sütunlar yerine satırlar boyunca okuyun. Opus 5 üzerinde bir önbellek okuma işlemi, milyon token başına 0.50 dolardır. Listelenen en ucuz model olan Haiku 4.5 üzerinde önbelleğe alınmamış girdi ise 1.00 dolardır. Dolayısıyla, en pahalı modelde sıcak bir öneki yeniden okumak, aynı öneki en ucuz modelde soğuk olarak okumaktan girdi token'ı başına daha düşük maliyetlidir.

Bu tek karşılaştırma, çoğu yönlendirme planını geçersiz kılar. İşi bir alt kademeye taşıyan bir yönlendirici, liste fiyatlarını karşılaştırır. Ancak oturum ortasındaki bir aracı, halihazırda kullandığı model için liste fiyatını ödemez. Aracı, zaten ucuz modelin önbelleğe alınmamış oranının altında kalan önbellek okuma fiyatını öder.

Önbellekler, istem önekinin bir hash değerine göre anahtarlanır ve modele özeldir. Farklı bir modele yapılan istek, daha önce hiç görmediği bir depoya göre hash'lenir; bu nedenle hiçbir şey bulamaz ve tam fiyatı öder. Önbellek aynı zamanda bir hiyerarşidir: önce araçlar, sonra sistem, ardından mesajlar. Herhangi bir seviyedeki değişiklik, o seviyeyi ve sonrasındaki her şeyi geçersiz kılar; bu da bir araç tanımını düzenlemenin, arkasında duran sistem istemi önbelleğini çöpe atması anlamına gelir. Çalışma zamanında araç kaydeden aracılar, bir yönlendiriciye hiç dokunmadan bu durumla karşılaşırlar.

Tek bir oturum içi geçişin gerçek maliyeti

Bir ajanın birkaç dosya okumasından sonra ulaşılan olağan bir boyut olan 40.000 token'lık sabit önekli (prefix) bir oturumu ele alalım. Aşağıda, yukarıdaki liste fiyatlarından hesaplanan tek bir tur için önek maliyeti yer almaktadır.

[
  {
    "label": "Opus 5, cache warm",
    "prefix_cost_usd": "0.020"
  },
  {
    "label": "Sonnet 5, turn after switch",
    "prefix_cost_usd": "0.100"
  },
  {
    "label": "Opus 5, cache re-warmed",
    "prefix_cost_usd": "0.250"
  }
]

Opus 5 üzerinde sıcak önbellekle (warm cache) kalmak, o turun öneki için 0.020 dolar maliyet oluşturur. Sonnet 5'e yönlendirme yapıldıktan sonraki ilk turun maliyeti 0.100 dolardır; çünkü Sonnet bu önek için hiçbir kayıt tutmaz ve yeni bir kayıt oluşturması gerekir. Opus 5'e geri dönmenin maliyeti ise 0.250 dolardır; çünkü oturum başka bir modeldeyken orijinal kayıt süresi dolmuştur.

Sonuç olarak, iki önbellek okumasından kaçınmak için gidiş-dönüşte iki önbellek yazma işlemi ödenmiş olur. Buna karşılık geçiş, Opus'un çıktı fiyatı yerine Sonnet'in çıktı fiyatı üzerinden bir tur çıktı kazandırır. Detaylar bloğu tüm süreci hesaplar: tasarruf sentin kesirleri düzeyindeyken, önbellek cezası onlarca sent düzeyindedir. Ceza, tasarruftan bir büyüklük derecesinden daha fazladır ve tasarruf miktarı sabit kalırken ceza önek uzunluğuyla birlikte artar.

Opus 5, warm read     40,000 x $0.50 / 1e6  = $0.020
Sonnet 5, cache write 40,000 x $2.50 / 1e6  = $0.100   (1.25 x $2 base)
Opus 5, cache write   40,000 x $6.25 / 1e6  = $0.250   (1.25 x $5 base)

800 x ($25 - $10) / 1e6 = $0.012

Araç çağırma formatları sağlayıcılar arasında aynı değildir

Bir ajan, bir araç çağırma döngüsüdür; bu nedenle araç çağırma formatı, sohbet uygulamalarında hiç olmadığı kadar büyük bir önem taşır. Anthropic'in Messages API'si bir tool_use içerik bloğu döndürür ve karşılığında bir tool_result bloğu bekler. OpenAI uyumlu API'ler ise, function.arguments kısmının iç içe geçmiş bir nesne yerine JSON kodlu bir dizgi olduğu bir tool_calls dizisi döndürür. Bir ağ geçidi (gateway) bu iki format arasında çeviri yapar ve standart çağrılar için bu çeviri sorunsuzdur.

Sorunlar uç noktalarda ortaya çıkar. Bir modelin tek bir yanıtta birden fazla çağrı ürettiği paralel araç çağrıları, farklı şekillerde temsil edilir ve her yerde aynı şekilde desteklenmez. Katı şema zorunluluğu (strict schema enforcement) sağlayıcıya özgü bir özelliktir; bu nedenle bir uç noktada şema geçerliliği garantisi veren bir model, başka bir uç noktada yalnızca geçerli argümanlar üretme eğilimindedir. Ajan, bu farkı bir ayrıştırma hatası içeren araç sonucu olarak görür ve ardından başka bir tur harcayarak bunu düzeltmeye çalışır. Bu düzeltme turları tam önek (prefix) fiyatı üzerinden faturalandırılır; dolayısıyla bir format uyumsuzluğu, transkriptte olduğu kadar faturada da kendini gösterir.

Kendi sunucunuzda barındırdığınız uç noktaların bu konuda açıkça yapılandırılması gerekir. vLLM'in OpenAI uyumlu sunucusu, model ailesiyle (hermes, mistral, llama3_json ve diğerleri) eşleşen bir --tool-call-parser ile birlikte --enable-auto-tool-choice parametresini ve araç rolü mesajlarını işleyen bir sohbet şablonunu gerektirir. vLLM belgeleri, bu yolun sınırları konusunda nettir: tool_choice="auto" ile ve katı şema kısıtlaması olmadan, vLLM araç çağrılarını ham metinden çıkarır; bu nedenle argümanlar bazen hatalı biçimlendirilmiş olabilir veya fonksiyonun parametre şemasını ihlal edebilir. Modeliniz için yanlış ayrıştırıcıyı seçmek, ajanın araç çağıramaması şeklinde ortaya çıkan bir yapılandırma hatasıdır; trafiği yönlendirmeden önce modelleri kendiniz sunmak için Ollama ve vLLM arasındaki fark konusunu bilmek bu yüzden önemlidir, çünkü bu iki araç, araç çağırma özelliğini farklı şartlar altında sunar.

Görev ortasında gerçekleşen geri dönüş (fallback) hatasız şekilde davranış değiştirir

Geri dönüş yönlendirmesi, yanlışlıkla etkinleştirilme olasılığı en yüksek özelliktir. Bir ağ geçidi (gateway), ilk model bir hız sınırı veya 5xx hatası döndürdüğünde başka bir model üzerinde yeniden deneme yapacak şekilde yapılandırılır ve ardından başarısız olan modeli birkaç saniyeliğine bekleme moduna alır. Sohbet trafiğinde bu tam olarak doğru bir yaklaşımdır. Ancak uzun bir aracı (agent) görevinin içinde bu, görevin ikinci yarısının seçmediğiniz bir model üzerinde çalışması anlamına gelir.

Bu durum hiçbir yerde raporlanmaz. Görev başarısız olmaz, aracı uyarı vermez ve çıkış durumu başarılı olarak döner. Sonuçta elinizde, planı bir model tarafından yazılmış, düzenlemeleri ise başka bir model tarafından yapılmış; tonu ve alışkanlıkları yarı yolda değişmiş bir görev kalır. Tek güvenilir sinyal, ağ geçidinin istek günlüğündeki veya yanıt üst verilerindeki model alanıdır. Bu nedenle, geri dönüş mekanizmalarını kullanıyorsanız, bu alanı her istek için kaydedin ve sonuç sizi şaşırttığında bu kayıtları inceleyin. Hangi modelin hangi çıktıyı ürettiğini bilmeden hata ayıklamak, geri dönüşün sağladığı zaman tasarrufundan daha fazlasını kaybettirir.

Aynı tuzak bağlam sıkıştırma (context compression) için de geçerlidir. Birçok aracı, uzun geçmişi küçük bir modeli çağırarak özetler. Eğer bu çağrı farklı bir model veya farklı bir sistem istemi (system prompt) kullanıyorsa, kendi önbellek girişini yazar ve ana oturumun önbelleğini yenilemez; bu nedenle bir sonraki tam turda soğuk bir ön ek (cold prefix) maliyeti oluşur. Sıkıştırma işlemi token tasarrufu sağlarken önbelleği kaybetmiş olur.

Yönlendirme yükü gerçektir ancak gecikme sorunun asıl kaynağı değildir

Yönlendiriciler her istek için ek iş yükü oluşturur ve bu yükün miktarını doğru belirlemek önemlidir. DigitalOcean, Arch-Router modellerinin yönlendirme amacını yaklaşık 51 milisaniyede çözdüğünü ve kendi değerlendirmelerinde %93.17 yönlendirme doğruluğuna ulaştığını bildirmektedir. Bunlar, kendi ölçümlerinden ve kıyaslamalarından elde edilen verilerdir; bizim verilerimiz veya evrensel bir sonuç değildir. Bu verileri olduğu gibi kabul ettiğinizde ulaşılan sonuç güven vericidir: kırk aracı çağrısı boyunca 51 milisaniye, birkaç dakika süren bir görev için yaklaşık iki saniyelik bir ek süre anlamına gelir.

Burada yönlendirmeyi maliyetli kılan şey iki saniyelik bu süre değildir. Asıl sorun yaratan yük, tam bir model çağrısı ile sınıflandırma yapan yönlendiricidir; çünkü bu, her istekte ikinci bir çıkarım (inference) yapılması demektir ve diğer tüm işlemler gibi faturalandırılıp kuyruğa alınır. Her ikisinin altında ise yukarıda bahsedilen önbellek aritmetiği yatar ki bu aslında bir yük değildir. Bu, yönlendirmenin optimize etmesi beklenen işin kendi maliyetidir.

Kendi yönettiğiniz bir sunucuda aynı kural daha az hareket alanı ile geçerlidir. Prompt önbelleğinin yerel karşılığı, GPU belleğinde tutulan KV önbelleğindeki önek (prefix) önbelleklemedir. Bir GPU üzerinde iki model barındırmak, belleği bu modeller arasında böler; dolayısıyla her biri daha küçük bir KV önbelleğine sahip olur ve önekleri daha erken siler (evict). Bu nedenle, iki yerel model arasında yönlendirme yapmak her ikisinin de önbellek isabet oranını aynı anda düşürebilir. Donanım boyutlandırması yapıyorsanız, yönlendiriciden ziyade bir kodlama aracısının bir VPS üzerinde gerçekten ihtiyaç duyduğu bellek ve CPU miktarı ile başlamak daha faydalı olacaktır.

Karar kuralı

• Erişilebilirlik için sağlayıcılar arasında yönlendirme yapın. Alternatif başarısız bir istek olduğunda, her maliyet doğru maliyettir. Yedekleme (fallback) mekanizmasını aynı araç çağırma (tool call) formatına sahip bir modele sabitleyin; böylece aracın döngüsü çalışmaya devam eder ve hangi modelin hangi çağrıya hizmet verdiğini günlüğe kaydedin.
• Maliyet için katmanlar arası yönlendirmeyi yalnızca görev sınırlarında yapın. Yeniden adlandırma işlemi için Haiku'yu, kod düzenleme (refactor) için Opus'u seçmek, oturum başlamadan önce verilen iyi bir karardır. Oturumun otuzuncu adımında bu kararı vermek ise hatalıdır.
• Aracı (agentic) işlemler için oturum başına bir modeli sabitleyin. Bir oturumun değeri, sıcak önbelleğidir (warm cache). Model değiştirmeyi, önbelleği temizlemekle aynı şekilde değerlendirin; çünkü yapılan işlem tam olarak budur.
• Alt aracıları (subagent) serbestçe yönlendirin. Yeni ve küçük bir bağlamla başlayan bir alt aracının kaybedecek sıcak önbelleği yoktur, bu nedenle işine uygun olan herhangi bir modelde çalışabilir. Bir aracın içinde yönlendirmenin neredeyse maliyetsiz olduğu tek yer burasıdır.

Bunun nasıl oluşturulacağı konusunda işi ağ geçidi (gateway) yapar: model takma adları ve açık yedekleme listeleri. Minimal bir LiteLLM proxy yapılandırması şu şekildedir.

model_list:
  - model_name: agent-primary
    litellm_params:
      model: anthropic/claude-opus-5
      api_key: os.environ/ANTHROPIC_API_KEY
  - model_name: agent-standby
    litellm_params:
      model: anthropic/claude-sonnet-5
      api_key: os.environ/ANTHROPIC_API_KEY

router_settings:
  fallbacks: [{"agent-primary": ["agent-standby"]}]
  num_retries: 2
  cooldown_time: 30

Aracı agent-primary adresine yönlendirin; böylece o model erişilemez hale gelene kadar aynı model üzerinde kalır. Her iki girdi de aynı sağlayıcı üzerinde yer alır, bu nedenle yedekleme devreye girdiğinde araç çağırma formatı değişmez. O anda bir katman değişikliğini kabul etmiş olursunuz; bu, yalnızca alternatifi başarısız bir istek olduğu için yapmaya değer bir takastır. Bu, maliyet yönlendirmesi içermeyen erişilebilirlik yönlendirmesidir ve çoğu kodlama aracının istediği kombinasyon budur. Anahtarlar ve bütçeler dahil olmak üzere tam kurulum, kendi VPS'inizde LiteLLM ağ geçidini self-host olarak çalıştırma bölümünde ele alınmıştır ve bu yazı kasıtlı olarak bunu tekrar etmemektedir.

İyi seçilmiş bir modelin her türlü yönlendiriciyi geride bıraktığı durumlar

Yönlendirme (routing), istek zorluklarındaki değişkenliğe karşı bir çözümdür. Bir kodlama aracısı, göründüğünden daha az değişkenliğe sahiptir; çünkü her çağrının maliyetli kısmı, çağrının ne istediğinden bağımsız olarak aynı olan önek (prefix) kısmıdır. Önek baskın hale geldiğinde, ucuz katmanınız ile pahalı katmanınız arasındaki fark, çıktı fiyatlarındaki farka doğru daralır ve çıktı, bir aracının token'larının küçük bir kısmını oluşturur.

Bu nedenle dürüst varsayılan yaklaşım; önbelleğe alma (caching) açık ve bir farkı (diff) okumak için durduğunuzdaki boşlukları kapsayacak kadar uzun bir TTL (yaşam süresi) değerine sahip, tek seferde seçilmiş tek bir model kullanmaktır. Anthropic, temel girdi maliyetinin 2 katı fiyatla bir saatlik önbellek yazma imkanı sunar; bu, iki okumadan sonra kendini amorti eder ve genellikle herhangi bir yönlendiriciden daha iyi bir kaldıraçtır. Katmanı Opus, Sonnet ve Haiku'nun doğrudan karşılaştırması üzerinden bilinçli bir şekilde seçin. Eğer fatura hala bir sorun teşkil ediyorsa, oturum ortasında geçiş yapmak yerine bir VPS üzerinde yapay zeka aracısı maliyetlerini kontrol etme başlığında olduğu gibi bütçeler ve daha küçük bağlamlar (context) ile maliyeti düşürün.

İstekler bağımsız ve kısa olduğunda veya alt aracılar (subagents) yeni bağlamlarla başladığında yönlendirme yapın. Tek bir işi yapan uzun bir oturumunuz olduğunda ise modeli sabitleyin (pin). Çoğu kodlama aracısı çalışması ikinci türe girer; bu yüzden sohbet ürününüzde tasarruf sağlayan yönlendirici, burada size sessizce maliyet çıkaracaktır. Henüz aracının kendisine karar vermediyseniz, Claude Code'un Cursor, Codex ve Copilot ile karşılaştırması her birinin model seçimini nasıl ele aldığını açıklar ve bazıları bu kararı sizin yerinize verir.

FAQ

Oturum ortasında model değiştirmek gerçekten prompt önbelleğini kaybettirir mi?

Evet. Prompt önbellekleri, prompt önekinin bir hash değerine göre anahtarlanır ve model bazında saklanır; bu nedenle farklı bir modele gönderilen istek, o öneki daha önce hiç görmemiş bir depolama alanında hash'lenir. Sistem hiçbir şey bulamaz ve önbelleğe alınmamış tam girdi ücretini öder, ardından önbelleğe alma etkinse bir de önbellek yazma ücreti öder. Geri dönmek de orijinal girdiyi kurtarmaz, çünkü varsayılan beş dakikalık yaşam süresi genellikle o zamana kadar dolmuş olur. Yanıt kullanım nesnesindeki cache_read_input_tokens ve cache_creation_input_tokens alanlarını kontrol edin: uzun bir oturumda sıfır önbelleğe alınmış token okuyan bir tur, bunun belirtisidir.

Bir aracı (agent) için daha ucuz bir modele yönlendirme yapmak her zaman daha mı ekonomiktir?

Sadece kaybedilecek sıcak bir önbellek olmadığında. Anthropic üzerinde bir önbellek okuma işlemi, temel girdi maliyetinin 0.1 katıdır; bu da Opus 5 üzerindeki sıcak bir okumayı, Haiku 4.5 üzerindeki önbelleğe alınmamış girdi oranının altına çeker. Bir oturum büyük bir önbelleğe alınmış öneke sahip olduğunda, mevcut model girdi maliyeti açısından zaten ucuz olan seçenektir. Yönlendirme, bağlam taze ve küçük olduğunda kazanç sağlar: bir görevin başlangıcında veya sadece ihtiyaç duyduğu bağlamı taşıyan bir alt aracıda.

Aracım neden bir görevin yarısında farklı davrandı?

Bir ağ geçidi (gateway) yedekleme mekanizmasının devreye girip girmediğini kontrol edin. Birincil modeldeki hız sınırı veya 5xx hatası, ağ geçidinin yedek model üzerinde yeniden deneme yapmasına ve birincil modeli birkaç saniyeliğine soğumaya (cooldown) almasına neden olur; böylece görevin geri kalanı başka bir yerde çalışır. Bu durum hata veya uyarı üretmez ve görev hala başarılı olarak raporlanır. Ağ geçidi istek günlüğündeki veya yanıt meta verilerindeki model alanı tek güvenilir kayıttır, bu nedenle yedekleme mekanizması kullanıyorsanız bunu her istek için günlüğe kaydedin.

Araç çağrıları (tool calls) her sağlayıcıda aynı şekilde mi çalışır?

Tam olarak değil. Anthropic'in Messages API'si tool_use ve tool_result içerik bloklarını kullanırken, OpenAI uyumlu API'ler function.arguments kısmı JSON kodlu bir dize olan bir tool_calls dizisi kullanır. Bir ağ geçidi yaygın durumları iyi bir şekilde çevirir, ancak paralel araç çağrıları ve katı şema zorlamaları sağlayıcıya göre farklılık gösterir. Kendi kendine barındırılan vLLM üzerinde --enable-auto-tool-choice ve model ailenizle eşleşen bir --tool-call-parser ayarlamanız gerekir; vLLM belgeleri, katı bir şema kısıtlaması olmadığında sunucunun araç çağrılarını ham metinden çıkardığını, bu nedenle argümanların bazen hatalı biçimlendirilebileceğini belirtir.

Bir kodlama oturumu için önbellek TTL süresini ne kadar ayarlamalıyım?

Sürekli çalışma için varsayılan beş dakikalık yaşam süresini, bir insan turlar arasındaki farkları (diff) okuduğunda ise bir saatlik seçeneği kullanın. Anthropic, beş dakikalık yazma işlemini temel girdinin 1.25 katı, bir saatlik yazma işlemini ise 2 katı olarak fiyatlandırır; okuma işlemi ise 0.1 katıdır. Beş dakikalık yazma maliyeti tek bir okuma ile, bir saatlik yazma maliyeti ise iki okuma ile karşılanır. Bu nedenle, geri dönüp devam etmeyi beklediğiniz her oturumda, daha uzun yaşam süresi genellikle soğuk bir önek için ödeme yapmaktan daha az maliyetlidir.