LLM Router Nedir? RouteLLM ve Model Yönlendirme

GPT-4 her soruya yanıt verebilir. Ama her soru GPT-4 gerektirmez.

Bir kullanıcı “İstanbul’un nüfusu nedir?” diye sorduğunda bu soru, yüzde elli çıkarım maliyetiyle çalışan frontier modeli tetiklemek zorunda mı? Hayır. Peki “Bu karmaşık sözleşmeyi analiz et, gizli maddeleri çıkar ve alternatif taslak öner” sorusu ne olacak? O farklı. İki uç arasındaki bu uçurum, LLM router’ın neden var olduğunu açıklar.

Gerçek dünyada üretim yapan uygulamalar, kullanıcı sorgularının büyük çoğunluğunun basit ve kısa olduğunu görür. Küçük bir model bu sorguları aynı kalitede karşılayabilir; maliyetin çok küçük bir kısmıyla. LLM router, her sorguyu değerlendirip doğru modele yönlendirir. Kalite kaybı olmadan yüzde altmış ila seksen maliyet tasarrufu vaat eden bu mimari katman, 2026’da büyük ölçekli AI deployment’larında fiili standart haline geliyor.

LLM Router nedir?

LLM router, gelen kullanıcı sorgularını karmaşıklık, konu ve bağlama göre değerlendirip uygun modele yönlendiren bir ara katmandır. Basit sorgular küçük ve ucuz modele, karmaşık ya da uzmanlık gerektiren sorgular güçlü ve pahalı modele gider.

Terminolojik kargaşaya dikkat: “router” üç farklı şeyi ifade etmek için kullanılıyor.

• Proxy router: API katmanında modeller arası trafik yönetimi yapar. LiteLLM bu kategoride.
• Orkestrasyon router: Multi-agent pipeline’larında hangi ajanın devreye gireceğine karar verir.
• Sınıflandırıcı router: Sorgu karmaşıklığını tahmin eden küçük bir ML modeli. RouteLLM bu kategoride.

Üçü de “router” adıyla anılıyor, ama çalışma şekilleri farklı. Bu yazı ağırlıklı olarak sınıflandırıcı router’a odaklanıyor, proxy router’a da değiniyor.

Temel akış son derece sade:

kullanıcı sorgusu → router → [küçük model | büyük model] → yanıt

Router çoğu durumda yanıta fark edilir gecikme eklemez; sınıflandırma işlemi 10-50 ms içinde tamamlanır. Kullanıcı bunu hiç fark etmez, arka planda maliyet yapısı kökten değişmiştir.

Bunu somut bir örnekle düşünelim. Bir e-ticaret sitesi günde 50.000 müşteri sorusu alıyor. “Siparişim nerede?” ve “İade süreci ne kadar sürer?” türündeki sorgular toplam isteğin yüzde altmış beşini oluşturuyor. Bunlar kısa, bağlamı net, doğru yanıtı tahmin edilebilir sorgular. Router bu grubu küçük, ucuz bir modele yönlendirir. Geriye kalan “Garanti kapsamım üç yıl önce aldığım ürünü de kapsıyor mu, hukuki haklarım neler?” gibi sorgular büyük modele gider. Kullanıcı herhangi bir fark görmez; sistem arkada hangi modelin devreye girdiğini sessizce seçer.

Nasıl çalışır? Routing stratejileri

Bir router’ın kalbi, “bu sorgu ne kadar güçlü model ister?” sorusuna cevap vermektir. Bunu yapmanın birkaç yolu var.

Kural tabanlı routing

En basit yaklaşım. Token sayısı 200’ün altındaysa küçük modele git; “hukuk”, “sözleşme”, “kod” gibi anahtar kelimeler varsa büyük modele yönlen. Kurulum ML bilgisi gerektirmez, ama sabit kurallar uç senaryolara karşı kırılgandır. Bir kullanıcı tek satırda gerçekten zor bir matematik sorusu sorduğunda kural tabanlı router yanılır.

Sınıflandırıcı tabanlı routing

Küçük bir makine öğrenmesi modeli (çoğunlukla BERT türevi veya distilled LLM) sorguyu embedding uzayında değerlendirir ve “küçük model yeterli” ya da “büyük model gerek” şeklinde etiketler. RouteLLM’in temel yöntemi bu. Sınıflandırıcı, Chatbot Arena gibi insan tercih verisiyle eğitildiğinden “zor soru” kavramını öğrenir; salt token uzunluğuna bakmaz.

Matrix factorization ve benzerlik routing

RouteLLM’in SW-Ranking (Similarity-Weighted Ranking) yaklaşımı, geçmiş sorgu-model çiftlerini matris çarpanlarına ayırır. Yeni bir sorgu geldiğinde, geçmiş verilerle benzerliğine bakılarak hangi modelin daha iyi performans göstereceği tahmin edilir. Eğitim verisi zenginleştikçe öngörü kalitesi artar; soğuk başlangıç problemi vardır ama pratik ortamlarda hızlı olgunlaşır.

LLM-as-judge (cascade)

İki aşamalı bir yaklaşım: önce küçük model yanıt verir, sonra bir değerlendirici (başka küçük model ya da kural seti) yanıtın kalitesini ölçer. Yetersiz bulunursa sorgu büyük modele eskalasyon edilir. Gecikmeye maliyet ekler çünkü iki model zincirleniyor, ama kalitenin yüksek tutulduğu senaryolarda doğruluk kayıpları minimuma iner.

Hangi stratejiyi seçeceğinizi belirleyen iki ana faktör var: mevcut geliştirme kapasitesi ve trafik hacmi. Kural tabanlı routing birkaç saatte kurulur ve küçük ekipler için makul bir başlangıç noktasıdır. Sınıflandırıcı tabanlı routing ise yeterli tarihsel veriniz varsa günde birkaç bin isteğin üzerinde maliyeti görünür biçimde düşürür. Matrix factorization ve cascade yaklaşımları güçlü araçlardır, ama doğru kurulum ve sürekli bakım ister; erken aşamada fazla yük getirebilir.

Başlıca LLM router araçları

RouteLLM (LMSys)

LMSys Research’ün geliştirdiği açık kaynak kütüphane, 2024 ortasında yayımlandıktan kısa süre içinde 40 binin üzerinde GitHub yıldızı topladı. Dört yerleşik router stratejisi sunar: matrix factorization, BERT sınıflandırıcı, cosine similarity ve LLM sınıflandırıcı. Chatbot Arena’nın milyonlarca insan tercihi verisiyle önceden eğitilmiş ağırlıkları kutudan çıkar çıkmaz kullanılabilir.

from routellm.controller import Controller

client = Controller(
    routers=["mf"],  # matrix factorization
    strong_model="gpt-4o",
    weak_model="gpt-4o-mini",
)

response = client.chat.completions.create(
    model="router-mf-0.11593",
    messages=[{"role": "user", "content": "Türkiye'nin başkenti neresi?"}]
)

0.11593 eşik değeri ayarlanabilir; düşürdükçe daha az sorgu güçlü modele gider.

LiteLLM Router

Yüz artı provider’ı tek OpenAI uyumlu API arkasına toplayan bir proxy. Routing, load balancing ve failover tek pakette. Bir provider hata verdiğinde otomatik olarak yedeğe geçer; maliyet bazlı yönlendirme kuralları tanımlanabilir. Özellikle çok modelli üretim ortamlarında tek API anahtarı yönetimi karmaşıklığını ortadan kaldırır.

from litellm import Router

router = Router(
    model_list=[
        {"model_name": "gpt-4o", "litellm_params": {"model": "openai/gpt-4o", "rpm": 200}},
        {"model_name": "gpt-4o-mini", "litellm_params": {"model": "openai/gpt-4o-mini", "rpm": 1000}},
    ],
    routing_strategy="cost-based-routing"
)

response = router.completion(model="gpt-4o-mini", messages=[...])

OpenRouter

Tek bir endpoint üzerinden yüzlerce modele erişim sunan bir API marketplace. Yerleşik model fallback, otomatik retry ve birleşik faturalandırma özellikleriyle özellikle prototipleme aşamasında pratik. Modeller arası fiyat karşılaştırma arayüzü, hangi modelin ne kadara mal olduğunu gerçek zamanlı gösterir.

import openai

client = openai.OpenAI(
    base_url="https://openrouter.ai/api/v1",
    api_key="<OPENROUTER_KEY>",
)

response = client.chat.completions.create(
    model="openai/gpt-4o-mini",
    messages=[{"role": "user", "content": "Merhaba"}],
    extra_headers={"X-OR-Fallback": "anthropic/claude-haiku-3"}
)

Portkey AI

Guardrail, önbellekleme, analitik ve routing’i tek platformda birleştiren kurumsal bir çözüm. Her API çağrısını loglar, hata oranlarını izler ve karmaşık routing mantığı için görsel iş akışı editörü sunar.

Araç seçimi ihtiyaca göre şekillenir: yalnızca maliyet optimizasyonu istiyorsanız RouteLLM yeterlidir; multi-provider failover kritikse LiteLLM Router öne çıkar; kurumsal gözlemlenebilirlik şartsa Portkey değerlendirmeye alınır.

Maliyet hesabı: gerçek senaryo

Sayılarla bakalım. Günde 100.000 kullanıcı isteği işleyen bir müşteri destek chatbotu varsayalım. Sorguların yüzde yetmişi basit (“Kargo takip numaramı nerede bulabilirim?”), yüzde otuzu karmaşık (“Bu iade politikası hangi koşullarda geçersiz sayılır, madde madde açıkla.”).

Router olmadan, tüm sorgular GPT-4o’ya gider. Günde 100.000 istek, istek başına ortalama 800 token, toplam 80 milyon token. 0,005 dolar per 1K token hesabıyla günde yaklaşık 400 dolar, aylık 12.000 dolar.

Aylık fark: 12.000 dolar ile 3.850 dolar. Tasarruf yüzde 68. Bu tek bir yük tipi için. Basit sorgu oranı yükseldikçe oran daha da açılır.

Router altyapısının kendisi de compute maliyeti üretir, ama bu genellikle toplam tasarrufun yüzde birinden ikisine kadar kalır.

Ne zaman LLM router kullanmalı?

Her mimari bileşen gibi router da her senaryoya uymaz.

Günde on binlerin üzerinde istek işliyorsanız maliyet avantajı hissedilir hale gelir. RAG pipeline’larında basit fact-lookup sorguları ile karmaşık sentez görevleri farklı model kapasitesi ister; router burada işe yarar. Çok kiracılı SaaS ürünlerde her kullanıcının sorgu karmaşıklığı farklı dağılım gösterir; tüm kiracılara aynı modeli uygulamak hem israf hem de dengesiz fiyatlandırmaya yol açar. vLLM gibi self-hosted çıkarım altyapısıyla birleştiğinde router, küçük modeli yerel GPU’da çalıştırıp büyük modeli API üzerinden çağırma stratejisine kapı açar.

Öte yandan, günde birkaç yüz istek işleyen prototip aşamasındaki bir uygulama için router eklemek erken optimizasyondur. Ek karmaşıklık, hata ayıklama yükü ve bakım maliyeti faydasını geçer. Latency kritik sistemlerde ek 30-50 ms bile sorun yaratabilir. Tüm sorgular zaten aynı model tipini gerektiriyorsa router’ın yönlendirecek alternatifi yoktur; katman gereksiz kalır.

Karar vermek için pratik bir kural: aylık API faturanız 500 doların üzerine çıkmışsa ve sorgularınızın en az yüzde ellisi kısa ve yapısal olarak tahmin edilebilir içerikten oluşuyorsa router yatırımı kendini birkaç haftada geri öder. Bu eşiğin altında kalıyorsanız daha basit araçlarla ilerlemek mantıklıdır.

LLM router ve çıkarım optimizasyonu

LLM router tek başına çalışmaz; diğer çıkarım optimizasyon teknikleriyle bir arada kullanılabilir.

Speculative decoding, büyük modelin yanıt hızını artırmak için küçük bir taslak model kullanır. Router ise hangi modelin çalışacağına karar verir. İkisi birlikte çalıştığında büyük modele sadece gereken sorgular gider ve o sorgular speculative decoding ile hızlanır.

Quantization modelleri bellek ve hesaplama açısından küçültür. Router’ın “küçük model” tarafı çoğunlukla quantized versiyonlardır; 4-bit veya 8-bit modeller GPU belleğinde çok daha az yer kaplarken yeterli kaliteyi korur.

Prompt engineering ve router birbirleriyle etkileşir: iyi yapılandırılmış bir prompt, sınıflandırıcının görev tipini daha doğru tahmin etmesini kolaylaştırır. Belirsiz, yapılandırılmamış sorgular router’ı zorlar.

Router yapılandırmasının kendisi de bir model değerlendirme sorunudur. LLM eval araçları, router eşiğini farklı değerlerde test ederek kalite-maliyet dengesinin nerede olduğunu bulmak için kullanılır. Hangi eşik değerinin gerçek kullanıcı sorgularında çalıştığını anlamak için aklı yürüten modeller üzerine yazımız da faydalı bir referans noktası sunar.

Router’ı production’a taşımadan önce

Bir router kurulumu tek satır pip install ile bitmez. Gerçek değer dikkatli bir rollout ve düzenli gözlemle ortaya çıkar.

İlk adım trafiği ikiye bölmek. Gelen sorguların yüzde onunu router üzerinden geçirin, kalanı doğrudan büyük modele yönlendirin. İki haftanın sonunda kullanıcı memnuniyeti, yanıt süresi ve hata oranını karşılaştırın. Router kontrol grubuna yakın kalite üretemiyorsa eşik değerini yeniden ayarlayın; acele etmeyin.

Her yönlendirilen sorgu için hangi modelin seçildiğini, gecikmeyi ve yönlendirme oranını loglayın. Küçük modele giden oran aniden yüzde seksenin üzerine çıkıyorsa eşik çok düşük ayarlanmış olabilir; kalite sorunu doğmadan önceden yakalarsınız. Bu nedenle temel bir metrik panosu production öncesi kurulmalıdır.

Matrix factorization yaklaşımı geçmişten öğrenir. İlk birkaç gün eğitim verisi kıt olan bir router zayıf kararlar verebilir. Bu geçiş dönemini sınıflandırıcı tabanlı modelle tamamlayın, yeterli veri birikince geçiş yapın. Tüm trafiği bir günde router’a vermek yerine yüzde beş, yüzde on, yüzde yirmi beş gibi aşamalı artışlarla ilerleyin. Her adımda metrikler sabitlenene kadar bekleyin; beklenmedik bir aksaklıkta geri dönüş pencereniz açık kalır.

Üretimde sık karşılaşılan bir sorun tek eşikle tüm görev türlerini kapsamaya çalışmaktır. Müşteri hizmetleri sorguları ile kod üretme görevleri farklı karmaşıklık dağılımı gösterir. Görev tipine göre ayrı router havuzları tanımlamak, tek küresel eşiğe kıyasla hem maliyet hem kalite açısından tutarlı biçimde daha iyi sonuç verir.

Hangi router’dan başlamalı?

Yeni başlıyorsanız RouteLLM mantıklı bir başlangıç noktasıdır. Açık kaynak, kurulumu basit ve Chatbot Arena verisiyle önceden eğitilmiş ağırlıklar hazır. Bir hafta içinde production-benzeri ortamda A/B testi yapabilirsiniz.

Zaten LiteLLM kullanıyorsanız cost-based routing’i tek satır konfigürasyonla etkinleştirebilirsiniz; yeni bir kütüphane eklemenize gerek yok.

Kurumsal düzeyde gözlemlenebilirlik, guardrail ve destek şartı arıyorsanız Portkey’i değerlendirin; ek kurulum maliyeti ölçekte amorti olur.

Her durumda threshold kalibrasyonu kritik bir adımdır. Varsayılan değerlerle başlayın, gerçek üretim trafiğini birkaç gün izleyin, ardından eşiği kalite-maliyet dengesi için ayarlayın. RouteLLM’in Chatbot Arena puanlarına dayalı kalibrasyon araçları bu süreci hızlandırır.

LLM router, AI altyapısının görünmez ama kritik bir parçasıdır. Kullanıcı aynı yanıt kalitesini alır; siz çok daha az ödersiniz. Hangi araçla başladığınızdan bağımsız olarak, doğru eşik kalibrasyonu ve temel metrik takibi kurulumu ilk haftanın önceliğidir. Ölçekte çalışan her yapay zeka uygulaması bu katmanı değerlendirmelidir.