LLM Latency ve Throughput: API Alıcıları Hızı Nasıl Ölçmeli

En son testimizde ilk görünür token'ını en hızlı gösteren model, aynı zamanda tamamlanması en uzun süren model oldu. 2026-10-03 tarihinde bir prompt'u dört model üzerinden stream ettik. claude-sonnet-5-5 ilk görünür token (2.981 ms) konusunda liderken, toplam sürede (12.384 ms) geride kaldı. Bu fark, LLM gecikmesi (latency) ve throughput arasındaki temel farktır: bir sayı kullanıcının metni görmek için ne kadar beklediğini, diğeri ise işin ne kadar hızlı tamamlandığını söyler. Bu makale her bir metriği tanımlıyor, kendi küçük birinci taraf ölçümlerimizi limitleriyle birlikte sunuyor ve TokenLab API'sine karşı çalıştırabileceğiniz bir test aracı sağlıyor.

Önemli Çıkarımlar

• Üç sayı, üç görev. İlk token'a kadar geçen süre, toplam süre ve saniyedeki çıktı token'ı farklı sorulara yanıt verir. Sohbet, ajanlar ve toplu işler (batch) her biri farklı birine dayanır.
• İlk olay ile ilk görünür token'ı ayırın. deepseek-v4.1-flash modelinde iki medyan arasında 2.334 ms ve 3.925 ms fark vardı. Akıl yürütme (reasoning) deltaları, görünür metinden çok önce ulaşabilir.
• Akıl yürütme token'ları max_tokens bütçenizi harcar. max_tokens 400 iken, deepseek-v4.1-flash yaklaşık 0 görünür token, gemini-3.8-flash ise yaklaşık 14 token döndürdü. 2000 değerinde ise her ikisi de tam yanıt verdi.
• Token sayılarını kullanım (usage) bloğundan okuyun. Bunları karakterlerden tahmin etmeyin.
• Model hızı istek limitinizi artırmaz. Hız limitleri (rate limits), token limitleri ve model hızı ayrı kısıtlamalardır.
• Örneklemimiz küçüktür. Model başına beş çalıştırma, bir istemci, bir prompt ve bir günden oluşur. Kimin en hızlı olduğunu değil, nasıl ölçüm yapılacağını gösterir.

Üç hız sayısı: Pratikte LLM gecikmesi ve throughput

"Hız"ı parçalara ayırın, çünkü her parçanın farklı bir sahibi vardır: ağ, model ve kendi kuyruğunuz.

istek gönder
  -> ilk stream olayı          (herhangi bir SSE bloğu; bir akıl yürütme deltası olabilir)
  -> ilk görünür içerik token'ı (boş olmayan ilk delta.content)
  -> son token + nihai kullanım bloğu

İlk token'a kadar geçen süre (TTFT), isteğin gönderilmesinden ilk token'ın ulaşmasına kadar geçen süredir. İki versiyon kaydediyoruz. İlk stream olayı, herhangi bir türdeki ilk SSE bloğudur. İlk görünür içerik token'ı, choices[0].delta.content değeri boş olmayan ilk bloktur. Yanıt vermeden önce akıl yürüten modeller için ilk olay, görünür metinden çok önce gelen bir akıl yürütme deltası (delta.reasoning_content) olabilir. Sadece delta.content değerini izleyen bir test aracı, ilk bayta kadar geçen süreyi değil, ilk görünür token'a kadar geçen süreyi ölçer. Kullanıcılar görünür olanı hisseder.

Toplam süre, isteğin gönderilmesinden stream'in sonuna kadar geçen süredir. Akıl yürütme, ağ süresi ve üzerine eklediğiniz herhangi bir yeniden deneme (retry) beklemesini içerir.

Saniyedeki çıktı token'ı, çıktı token'larının toplam süreye bölünmesidir. Token sayısını, akıl yürütme token'larını da içeren usage.completion_tokens değerinden alın. Toplam süreye bölüyoruz, görünür pencereye değil. Örneklemimizdeki bazı modeller görünür metni birkaç büyük blok halinde sundu, bu nedenle pencere tabanlı bir oran yanıltıcı olurdu.

İş Yükü	Önce İzle	Sonra	Neden
Sohbet	İlk görünür token	Toplam süre	Kullanıcı görünür metin belirene kadar boş bir kutuya bakar.
Ajanlar	Toplam süre	İlk görünür token	Her adım genellikle bir öncekini bekler, bu yüzden adım başına toplamlar birikir.
Toplu çıkarım veya özetler	Saniyedeki çıktı token'ı ve görev başına maliyet	İstek limiti payı	Kimse ilk token'ı izlemez ve hesabın istek limiti işi ne kadar hızlı gönderebileceğinizi sınırlar.

Yapılandırılmış JSON çıkarımı gibi stream edilmeyen çağrılar sadece toplam süreyi gösterir. Ayrımı görmek istiyorsanız test sırasında bunları stream edin.

2026-10-03 tarihinde ölçtüklerimiz

Yöntem. Bu, 2026-10-03 tarihinde POST https://api.tokenlab.sh/v1/chat/completions (kaynak) adresine karşı gözlemlenen birinci taraf bir TokenLab ölçümüdür. Her istekte stream=true ve stream_options.include_usage=true kullanıldı. Doğu Asya'daki tek bir istemciden, Node 24 fetch kullanarak model başına 5 sıralı çalıştırma yaptık. Prompt: "HTTP keep-alive'ın API istemcileri için gecikmeyi nasıl azalttığını açıklayın. Yaklaşık 200 kelime yazın." şeklindeydi. Her model varsayılan akıl yürütme ayarlarını kullandı. Zamanlamalar istemci tarafı duvar saati süresidir ve aşağıdaki her satır için tüm çalıştırmalar (5/5) başarılı olmuştur.

Model (max_tokens 2000)	Medyan ilk stream olayı	Medyan ilk görünür token	Medyan toplam süre	Medyan tamamlanma token'ları (akıl yürütme)	Tahmini token/s
deepseek-v4.1-flash	2.334 ms	3.925 ms	5.204 ms	453 (225)	87
gemini-3.8-flash	6.892 ms	6.892 ms	8.626 ms	826 (528)	96
claude-sonnet-5-5	2.981 ms	2.981 ms	12.384 ms	418 (bildirilmedi)	34
gpt-5.6-luna	3.262 ms	3.262 ms	8.183 ms	313 (42)	38

Token/s sütunu kendi tahminimizdir: medyan tamamlanma token'ları, medyan toplam saniyeye bölünmüştür, örneğin 453 ÷ 5,204 ≈ 87. Bu, çalıştırma başına oranların medyanı değil, medyanların oranıdır.

Sayıların gösterdikleri ve fazlası değil:

• İlk görünür token'a göre sıralama (claude-sonnet-5-5, gpt-5.6-luna, deepseek-v4.1-flash, gemini-3.8-flash), toplam süreye göre sıralamadan (deepseek-v4.1-flash, gpt-5.6-luna, gemini-3.8-flash, claude-sonnet-5-5) farklıdır. Bir metrik diğerinin yerini tutamaz.
• deepseek-v4.1-flash, ilk olay ile ilk görünür token arasında 1.591 ms'lik bir boşluğa sahipti. Medyan görünür çıktısı yaklaşık 228 token idi ve 1.304 ms boyunca 87 olayda iletildi.
• gemini-3.8-flash için ilk olay ve ilk görünür token 6.892 ms'lik bir medyanı paylaşır. Görünür metni 1.734 ms boyunca 11 olaylık bir medyanda geldi, bu nedenle stream token token değil, bloklar halindeydi.
• claude-sonnet-5-5 9.186 ms boyunca 371 olaylık bir medyan, gpt-5.6-luna ise 4.901 ms boyunca 265 olay gönderdi.

Maliyet, hızın yanındadır. Aşağıdaki fiyatlar 2026-10-03 tarihinde gözlemlenen ve 2026-10-02T16:53:30.068Z tarihinde güncellenen TokenLab model API'sinden alınmıştır. Son sütun bir tahmindir: medyan tamamlanma token'ları çarpı çıktı oranı, sadece çıktı tarafı. Gerçek ücretler için kullanım kayıtlarını kontrol edin.

Model	1M başına giriş	1M başına çıktı	Maks çıktı token'ı	Çıktı tarafı tahmini, medyan çalıştırma	Kaynak
deepseek-v4.1-flash	$0.15 yoğun olmayan, $0.30 yoğun	$0.60 yoğun olmayan, $1.20 yoğun	384.000	453 × $0.60 / 1M ≈ $0.00027 yoğun olmayan, ≈ $0.00054 yoğun	model API
gemini-3.8-flash	$0.375	$1.875	65.536	826 × $1.875 / 1M ≈ $0.00155	model API
claude-sonnet-5-5	$0.60	$3	128.000	418 × $3 / 1M ≈ $0.00125	model API
gpt-5.6-luna	$0.06	$0.36	128.000	313 × $0.36 / 1M ≈ $0.00011	model API

gpt-5.6-luna için bu oranlar giriş en fazla 272K token olduğunda geçerlidir. Bunun üzerinde, tam istek 2x giriş ve 1.5x çıktı oranlarını kullanır.

Bu örneklemin limitleri. Doğu Asya'daki bir istemciden beş sıralı çalıştırma ince bir dilimdir. Prompt kısa bir makale isteğiydi, bu nedenle sonuçlar bölgeye, günün saatine, prompt'a ve çıktı uzunluğuna göre değişecektir. Eşzamanlılığı test etmedik, bu yüzden bunların hiçbiri yük altında ne olacağını söylemez. Tabloyu, üretim çalıştırmalarının yapıldığı bölgeden çalıştırılan kendi testiniz için bir şablon olarak değerlendirin. Modellerin daha geniş bir görünümünü istiyorsanız, geliştiriciler için TokenLab LLM API liderlik tablosu bir başlangıç noktasıdır. Oradaki herhangi bir hız rakamına güvenmeden önce yöntemini ve tarihini kontrol edin. Modelleri sessizce değiştirmeyin: güvenilirlik kılavuzu (2026-10-03 tarihinde gözlemlenmiştir), bir değişimin kaliteyi, fiyatı, bağlam uzunluğunu ve araçları değiştirebileceğini belirtir.

Akıl yürütme token'ları ve max_tokens: neden 400 neredeyse hiçbir şey döndürmedi

Aynı prompt'u max_tokens 400 olarak ayarlanmış şekilde de çalıştırdık. Aynı yöntem, aynı beş çalıştırma, aynı tarih (kaynak).

Model (max_tokens 400)	Medyan tamamlanma token'ları	Medyan akıl yürütme token'ları	Görünür çıktı (yaklaşık)	Medyan ilk görünür token	Medyan toplam süre
deepseek-v4.1-flash	400	400	0 token	3.795 ms	4.693 ms
gemini-3.8-flash	396	382	14 token	4.199 ms	4.240 ms
claude-sonnet-5-5	400	bildirilmedi	400 token	3.088 ms	11.078 ms
gpt-5.6-luna	317	42	275 token	3.040 ms	8.083 ms

Medyanlar sütun başına hesaplanır, bu nedenle bir satırın sütunları tek bir çalıştırmayı tanımlamak zorunda değildir. deepseek-v4.1-flash modelinin sıfır görünür olay medyanının yanında bir ilk görünür zaman göstermesinin nedeni budur.

Bulgu açıktır. deepseek-v4.1-flash ve gemini-3.8-flash, 400 token'lık bütçenin neredeyse tamamını akıl yürütmeye harcadı ve neredeyse hiç görünür metin döndürmedi. max_tokens değerini 2000'e yükseltmek tam yanıtlar üretti. Akıl yürütme token'ları usage.completion_tokens içinde sayılır. Bunlar usage.completion_tokens_details.reasoning_tokens içinde ayrı olarak bildirilir.

İlk 400 token'lık sonucu gördüğümüzde, hata bir bütçe sorunu gibi değil, boş bir yanıt gibi görünüyordu. Üç kontrol bunu görünür kılar:

1. stream_options={"include_usage": True} ile etkinleştirilen nihai kullanım bloğunu okuyun. Eğer reasoning_tokens değeri completion_tokens değerine yakınsa ve metin boşsa, bütçe akıl yürütmeye gitmiştir.
2. finish_reason değerini kontrol edin. streaming kılavuzu (2026-10-03 tarihinde gözlemlenmiştir), bir token limitine ulaşıldığında değer olarak length listeler.
3. Modelin maksimum çıktısıyla karşılaştırın. Örneğin, model API'si deepseek-v4.1-flash için 384.000 ve gemini-3.8-flash için 65.536 listeler, bu nedenle 400, modellerin izin verdiğinin küçük bir dilimiydi.

Create Chat Completion referansı (2026-10-03 tarihinde gözlemlenmiştir) ayrıca max_completion_tokens ve reasoning_effort listeler. Desteklenen değerlerin modele bağlı olduğunu söyler, bu nedenle herhangi birini ayarlamadan önce model sayfasını okuyun. Bunları test etmedik ve her satırı varsayılan akıl yürütme ile çalıştırdık. Sınırı kendi prompt'unuzdan belirleyin: çalışmamızda, 200 kelimelik bir yanıt yaklaşık 228 ila 418 görünür token ve üzerine 528'e kadar akıl yürütme token'ı üretti.

TokenLab temel URL'si için bir ölçüm aracı

Bu betik TokenLab temel URL'sini kullanır, kullanım bloğundan token sayılarını okur ve ilk stream olayını ilk görünür içerik token'ından ayrı olarak kaydeder. Ayrıca daha sonra hata ayıklama için yanıt başlıklarını tutar. Dokümanlardaki istemci ayarlarını (timeout=30.0, max_retries=0) izler, böylece SDK zamanlamalarınıza gizli yeniden denemeler eklemez. Model kimliği ölçtüğümüz bir kimliktir; kabul edilen istek formatları openai_chat_completions içeren herhangi bir kimlikle değiştirin.

import json
import os
import statistics
import time

from openai import OpenAI

client = OpenAI(
    api_key=os.environ["TOKENLAB_API_KEY"],
    base_url="https://api.tokenlab.sh/v1",
    timeout=30.0,
    max_retries=0,
)

PROMPT = "Explain how HTTP keep-alive reduces latency for API clients. Write about 200 words."

def measure(model: str, max_tokens: int = 2000) -> dict:
    start = time.perf_counter()
    raw = client.chat.completions.with_raw_response.create(
        model=model,
        messages=[{"role": "user", "content": PROMPT}],
        max_tokens=max_tokens,
        stream=True,
        stream_options={"include_usage": True},
    )
    headers = raw.headers
    first_event = first_visible = None
    visible_events = 0
    usage = None
    finish_reason = None

    for chunk in raw.parse():
        now = time.perf_counter() - start
        if first_event is None:
            first_event = now
        if chunk.usage is not None:
            usage = chunk.usage
        if not chunk.choices:
            continue
        choice = chunk.choices[0]
        if choice.delta.content:
            visible_events += 1
            if first_visible is None:
                first_visible = now
        if choice.finish_reason:
            finish_reason = choice.finish_reason

    total = time.perf_counter() - start
    details = getattr(usage, "completion_tokens_details", None)
    completion = usage.completion_tokens if usage else None
    return {
        "model": model,
        "request_id": headers.get("x-request-id"),
        "routing_time_ms": headers.get("x-routing-time-ms"),
        "first_event_s": first_event,
        "first_visible_s": first_visible,
        "total_s": total,
        "completion_tokens": completion,
        "reasoning_tokens": getattr(details, "reasoning_tokens", None),
        "visible_events": visible_events,
        "finish_reason": finish_reason,
        "tokens_per_s": completion / total if completion else None,
    }

if __name__ == "__main__":
    runs = [measure("gemini-3.8-flash") for _ in range(5)]
    print(json.dumps(runs[0], indent=2))
    print("median total_s:", statistics.median(r["total_s"] for r in runs))

Çıktıyı okumakla ilgili birkaç not:

• first_event_s, sadece rol veya akıl yürütme bloğu dahil olmak üzere herhangi bir blokta tetiklenir. first_visible_s sadece boş olmayan delta.content üzerinde tetiklenir. İkisi arasında saniyeler fark varsa, model yanıt vermeden önce akıl yürütüyordur.
• Token sayıları nihai kullanım bloğundan gelir. Bu bloğun boş bir choices listesi vardır, bu yüzden döngü atlamadan önce chunk.usage değerini kontrol eder.
• Beş kez veya daha fazla çalıştırın, bölgeyi kaydedin ve örneklem boyutuyla birlikte medyanları bildirin.
• openai_responses listeleyen modeller için streaming kılavuzu, response.output_text.delta ve response.completed olaylarıyla stream edilen yanıtları gösterir. Aynı ayrım geçerlidir: ilk olayı, ardından ilk metin deltasını zamanlayın.
• response.completed veya bir stop bitiş nedeninden önce kapanan bir stream'i hızlı bir başarı olarak değil, eksik olarak değerlendirin.

Gecikme hata ayıklaması için kaydedilecek başlıklar ve tanımlayıcılar

Yavaş bir istekte sadece süreyi tuttuysanız hata ayıklamak zordur. API referansı ve sorun giderme kılavuzu (her ikisi de 2026-10-03 tarihinde gözlemlenmiştir), tutulmaya değer tanımlayıcıları adlandırır.

Tanımlayıcı	Nerede görünür	Şunun için kullan
X-Request-ID	Yanıt başlığı, mevcut olduğunda	Bir istek için destek ve hata ayıklama
request_id	Hata gövdeleri, kontrol paneli günlükleri, kullanım kayıtları	İstek düzeyinde destek ve mutabakat
X-Routing-Time-MS	Yanıt başlığı, mevcut olduğunda	Üretim öncesi, teslimat seçiminde harcanan süre
X-Task-ID, task_id, poll_url	Async oluşturma ve durum yanıtları	Görüntü, video, müzik ve 3D işleri
X-Billing-Transaction-ID	Nihai faturalandırmadan sonra başlık, mevcut olduğunda	Maliyet mutabakatı
Kendi iş veya kullanıcı kimliğiniz	Uygulamanız	Kullanıcı şikayetinin arkasındaki isteği bulma

Her çağrı için uç noktayı, yöntemi, modeli, durum kodunu, zaman damgasını ve gecikmeyi kaydedin. Gönderdiğiniz alan adlarını (prompt'u değil), yeniden deneme sayınızı ve bir yeniden denemenin yeni bir görev mi oluşturduğunu yoksa bir görev mi devam ettirdiğini ekleyin. Test aracımız, kullanım bloğundan ayrık zamanlamaları ve token sayılarını ekler.

İki uyarı. Stream yanıtları stream bittikten sonra sonuçlanabilir, bu nedenle kullanım daha sonra kaydedilse bile bir faturalandırma başlığı eksik olabilir. Faturalandırılan tutarlar için sadece yanıt token sayıları yerine Yönetim API'si kullanım kayıtlarını kullanın. Ayrıca, ayarladıysanız X-TokenLab-Delivery-Policy değerini kaydedin. Referans, auto, verified veya official değerlerini kabul ettiğini, geçersiz bir değerin 400 döndürdüğünü ve kullanılamayan bir seçeneğin code: delivery_tier_unavailable ve retryable: true ile 503 döndürdüğünü söyler. Asla Authorization, API anahtarları, imzalı URL'ler, tam prompt'lar veya kişisel verileri kaydetmeyin.

Konsol istek detayları yakalamadan itibaren 30 gün boyunca tutulur, bu nedenle ihtiyacınız olan kimlikleri kendi günlüklerinize kopyalayın. İş hattımızda bu kimlikleri istekler görünümüyle hizalıyoruz; TokenLab istek konsolu gönderisi bu görünümü kapsar.

Hız limitleri, yeniden denemeler ve LLM gecikmesi ile throughput

Stream başına hız ve hesap throughput'u farklı tavanlardır. Hız limitleri kılavuzu (2026-10-03 tarihinde gözlemlenmiştir), aşağıdaki standart katman değerlerini listeler. Bunların aktif yapılandırmayla değişebileceğini ve API anahtarı başına uygulandığını belirtir.

Katman	Dakikadaki istek sayısı
Kullanıcı	1.000
Ortak	10.000
VIP	10.000

Limiti aştığınızda, API Retry-After başlığı ile 429 rate_limit_exceeded döndürür. Kılavuzun örnek gövdesi "retryable": true ve "retry_after": 8 taşır. Kılavuz, döndürülen X-RateLimit-Limit ve Retry-After değerlerine kopyalanmış herhangi bir tablodan daha fazla güvenmenizi söyler. Ayrıca daha hızlı bir modelin hesabınızın istek limitini artırmadığını söyler.

Toplu işler için aritmetik şöyledir. Bu, yukarıdaki medyanlardan kendi tahminimizdir, bir yük testi değildir. Eşzamanlı stream'ler kabaca saniyedeki istek sayısı çarpı istek başına saniyedir. Dakikada 1.000 istekte (saniyede yaklaşık 16,7):

• deepseek-v4.1-flash ile 5,204 saniyelik medyan toplamda, aynı anda yaklaşık 87 stream çalışır.
• claude-sonnet-5-5 ile 12,384 saniyelik medyanda, aynı anda yaklaşık 206 stream çalışır.

Daha yavaş bir stream, aynı istek hızına ulaşmak için daha fazla eşzamanlılık anlamına gelir. Limite çarpmak, üretim süresinin üzerine bekleme süresi ekler. Token limitleri kullandığımız sayfalarda kapsanmamıştır, bu nedenle hesabınızı ve model sayfasını kontrol edin.

Sayılarınızı bozmadan nasıl yeniden deneme yapılır:

• Mevcut olduğunda Retry-After değerine uyun. Aksi takdirde rastgele jitter ve sert bir deneme sınırı ile üstel geri çekilme (exponential backoff) kullanın.
• SDK'yı max_retries=0 olarak ayarlayın ve yeniden denemeyi tek bir yerde yapın. Aksi takdirde iki katman aynı çağrıyı yeniden dener ve zamanlamalarınız iki kez sayılır.
• Doğrulama, kimlik doğrulama, bakiye veya izin hatalarını asla yeniden denemeyin. Geçici 5xx yanıtlarını kısa bir geri çekilme ile yeniden deneyin.
• İlk olay ulaştıktan sonra, kesintiye uğrayan bir stream eksiktir ve otomatik olarak yeniden başlatılmaz. İsteği tekrarlamak farklı bir çıktı ve başka bir ücret üretebilir.
• Yeniden deneme sayısını ve bekleme süresini model süresinden ayrı olarak kaydedin, böylece kısıtlanmış bir çalıştırma yavaş bir model gibi görünmez.

Bu, kılavuzun sınırlı yeniden deneme desenidir:

import random
import time
from openai import RateLimitError

def chat_with_rate_limit_retry(client, model, messages, attempts=4):
    for attempt in range(attempts):
        try:
            return client.with_options(max_retries=0).chat.completions.create(
                model=model,
                messages=messages,
            )
        except RateLimitError as exc:
            if attempt == attempts - 1:
                raise
            header = exc.response.headers.get("Retry-After")
            wait = float(header) if header else min(30, 2 ** attempt + random.random())
            time.sleep(wait)

Ayrıca sadece dakikadaki ortalama istek sayısını değil, eşzamanlılığı da sınırlayın ve patlamaları (burst) kuyruğa alın. API anahtarı başına tekrarlanan 429 yanıtlarını izleyin, böylece bir istemci uygulamanızın geri kalanını kalabalıklaştıramaz.

SSS

Saniyedeki daha yüksek token sayısı her zaman daha hızlı bir kullanıcı deneyimi midir?

Hayır. 2026-10-03 örneklemimizde, claude-sonnet-5-5 en erken ilk görünür token'ı (2.981 ms) gösterdi ancak en uzun toplam süreye (12.384 ms) sahipti. deepseek-v4.1-flash görünür metne daha geç başladı (3.925 ms) ve ilk bitiren oldu (5.204 ms). Hangisinin daha hızlı hissedildiği, kullanıcının stream'i izleyip izlemediğine veya tam yanıtı bekleyip beklemediğine bağlıdır. Bir istemciden beş çalıştırma, iş yükünüz için bunu belirleyemez.

Stream edilen yanıtım neden neredeyse hiç metin olmadan geri geldi?

Bütçeyi muhtemelen akıl yürütmeye harcadınız. max_tokens 400 iken, deepseek-v4.1-flash 400 akıl yürütme token'ı kullandı ve yaklaşık 0 görünür token döndürdü. Nihai kullanım bloğundaki usage.completion_tokens_details.reasoning_tokens değerini ve finish_reason değerini kontrol edin. Ardından sınırı yükseltin; 2000'de testimizdeki her iki akıl yürütme modeli de tam yanıt verdi.

Daha hızlı bir model hız limitimi artırır mı?

Hayır. Hız limitleri kılavuzu, model hızı, token limitleri ve hesap hız limitlerinin ayrı kısıtlamalar olduğunu söyler. Daha hızlı bir stream daha çabuk biter ve bir eşzamanlılık yuvasını boşaltır, ancak anahtar başına istek limitiniz aynı kalır. Bir tane gerekiyorsa destekten farklı bir limit isteyin.

Bir stream yavaş olduğunda desteğe hangi kimlikleri göndermeliyim?

request_id (veya X-Request-ID), uç nokta, yöntem, model, zaman damgası ve durum kodunu gönderin. Async işler için task_id ve poll_url, mevcut olduğunda billing_transaction_id ekleyin. Ayrık zamanlamalarınızı ve güvenli hata gövdesini ekleyin ve anahtarları, prompt'ları ve özel medyayı önce sansürleyin.

Yukarıdaki aracı kendi prompt'unuzda çalıştırın, ardından ölçtüklerinizi TokenLab model sıralamaları ile karşılaştırın.