Zaman aşımları ve yavaş modeller

Zaman aşımı hatalarının büyük çoğunluğu gateway kaynaklı değildir: model yanıtı üretmeye devam ederken istemci kendi okuma bütçesini doldurup bağlantıyı kapatır. Bu sayfa, hangi modelde ne kadar süre beklemeniz gerektiğini ve bağlantının hangi ayarlarla açık kalacağını anlatır.

Neden bir istek zaman aşımına uğrar

Akış kullanmayan (stream: false) bir çağrıda gövdenin ilk baytı ancak yanıt tamamen üretildikten sonra gönderilir. Model 90 saniye üretim yapıyorsa, istemci 90 saniye boyunca soketten tek bir bayt görmez. Çoğu HTTP istemcisinin varsayılan okuma zaman aşımı 30-60 saniyedir; bu süre dolduğunda istek istemci tarafında iptal edilir.

Bu durumda:

• İstek başarısız sayılır ve ücretlendirilmez.
• Sunucu tarafında provider_error veya provider_timeout olarak kayda geçer.
• Aynı isteği tekrar denemek, aynı süreyi tekrar bekleyeceği için genellikle aynı sonucu verir.

İki çözüm

1. Akış kullanın

stream: true verdiğinizde gateway yanıt başlıklarını hemen gönderir ve model düşünürken bağlantıyı canlı tutar. Okuma zaman aşımı, baytlar akmaya devam ettiği için tetiklenmez. Uzun yanıt üreten her modelde önerilen yol budur.

import openai

client = openai.OpenAI(
    base_url="https://llmtr.com/v1",
    api_key="llmtr-your_key",
)

stream = client.chat.completions.create(
    model="llmtr/qwen3-6-35b",
    messages=[{"role": "user", "content": "Bir fonksiyon yaz"}],
    stream=True,
)

for chunk in stream:
    delta = chunk.choices[0].delta.content
    if delta:
        print(delta, end="", flush=True)

Akış biçiminin ayrıntıları için /docs/gateway/streaming sayfasına bakın.

2. Okuma zaman aşımını yükseltin

Akış kullanamıyorsanız istemci zaman aşımını modelin gerçek süresine göre ayarlayın. Türkiye'de barındırılan modellerde 300 saniye güvenli bir başlangıç değeridir.

client = openai.OpenAI(
    base_url="https://llmtr.com/v1",
    api_key="llmtr-your_key",
    timeout=300.0,
)

curl --max-time 300 "https://llmtr.com/v1/chat/completions" \
  -H "Authorization: Bearer llmtr-your_key" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "llmtr/gemma-4",
    "messages": [{"role": "user", "content": "Merhaba"}]
  }'

Beklenen üretim hızları

Aşağıdaki değerler üretim kayıtlarından ölçülmüştür; teorik değer değildir. Süre tahmini için beklenen token sayısı ÷ hız kullanın.

Model	Üretim hızı	Tipik yanıt süresi
llmtr/gemma-4	30-45 token/sn	512 token çıktıda 15-20 sn
llmtr/qwen3-6-35b	~8 token/sn	1000+ token çıktıda 2 dakikanın üzeri
llmtr/medgemma-4b	5-7 token/sn (sıcakken)	İlk istek model yüklemesi nedeniyle dakikalar sürebilir
llmtr/trendyol-asure-12b	4-5 token/sn	512 token çıktıda 2 dakikaya yakın
llmtr/ornith-1-35b	~3,6 token/sn	4000 token çıktıda ~18 dakika

Global sağlayıcılardaki modeller (OpenAI, Anthropic, Google, Qwen ve diğerleri) bu tablonun dışındadır ve tipik olarak saniyeler içinde yanıtlar.

Uzun promptlarda istem işleme süresi

Türkiye'de barındırılan modellerde yalnızca üretim hızı değil, promptun ilk kez işlenmesi de süre alır ve bu süre modelden modele belirgin şekilde değişir. llmtr/gemma-4 uzun promptları hızlı okur; 20.000 tokenlik bir prompt saniyeler içinde işlenir. Diğer TR modellerinde aynı prompt dakikalar sürebilir. Uzun bağlamlarla çalışırken:

• İstemci okuma zaman aşımınızı prompt boyutuna göre ölçekleyin, sabit 60 saniyede bırakmayın.
• Aynı öneki (sistem talimatı, doküman, konuşma geçmişi) tekrar gönderin. Önek önbelleğe alınır: ölçümde 1.603 tokenlik bir prompt ilk çağrıda 3.985 ms, aynı önekle ikinci çağrıda 714 ms sürmüştür ve önbellekten okunan tokenler daha ucuz faturalanır.
• Çok büyük promptlar için ilk isteği ayrı yapıp ardından aynı önek üzerinden devam edin.

Yanıt uzunluğunu sınırlayın

Süre doğrudan üretilen token sayısına bağlı olduğundan, kısa yanıt yeterliyse max_tokens ile tavan koymak en hızlı iyileştirmedir.

{
  "model": "llmtr/qwen3-6-35b",
  "messages": [{"role": "user", "content": "Tek cümleyle özetle"}],
  "max_tokens": 256
}

Toplu işler

Sıralı çok sayıda istek gönderen toplu işlerde:

• Her istek için akış açın; bir isteğin takılması tüm işi durdurmasın.
• Başarısız istekleri geri çekilmeli (backoff) yeniden deneyin, hemen ve sınırsız değil.
• Eşzamanlılık sınırına takılırsanız 429 veya 503 model_busy yanıtındaki Retry-After başlığına uyun.

İlgili sayfalar

• /docs/gateway/streaming — akış biçimi ve olay yapısı
• /docs/gateway/errors — hata tipleri ve HTTP kodları
• /docs/usage — isteklerinizin durum kodlarını ve gecikmelerini görüntüleme