LLM-Latenz vs. Durchsatz: Wie API-Käufer Geschwindigkeit messen sollten

Das Modell, das in unserem neuesten Test am schnellsten das erste sichtbare Token anzeigte, war gleichzeitig am langsamsten bei der Fertigstellung. Am 03.10.2026 haben wir einen Prompt durch vier Modelle gestreamt. claude-sonnet-5-5 führte beim ersten sichtbaren Token (2.981 ms), lag aber bei der Gesamtzeit (12.384 ms) zurück. Diese Lücke ist der Kern der Debatte um LLM-Latenz vs. Durchsatz: Eine Kennzahl gibt an, wie lange ein Benutzer auf Text warten muss, die andere, wie schnell die Arbeit abgeschlossen wird. Dieser Artikel definiert die einzelnen Metriken, zeigt unsere kleinen internen Messungen mit ihren Grenzen auf und stellt ein Test-Tool bereit, das Sie gegen die TokenLab API ausführen können.

Wichtige Erkenntnisse

• Drei Zahlen, drei Aufgaben. Time to First Token (TTFT), Gesamtzeit und Output-Token pro Sekunde beantworten unterschiedliche Fragen. Chat, Agenten und Batch-Verarbeitung basieren jeweils auf einer anderen Metrik.
• Unterscheiden Sie das erste Ereignis vom ersten sichtbaren Token. Bei deepseek-v4.1-flash lagen die beiden Mediane 2.334 ms und 3.925 ms auseinander. Reasoning-Deltas können lange vor dem sichtbaren Text eintreffen.
• Reasoning-Token verbrauchen Ihr max_tokens-Budget. Bei max_tokens 400 lieferte deepseek-v4.1-flash etwa 0 sichtbare Token und gemini-3.8-flash etwa 14. Bei 2000 antworteten beide vollständig.
• Lesen Sie Token-Anzahlen aus dem Usage-Chunk. Schätzen Sie diese nicht anhand von Zeichen.
• Modellgeschwindigkeit erhöht nicht Ihr Request-Limit. Rate Limits, Token-Limits und Modellgeschwindigkeit sind separate Einschränkungen.
• Unsere Stichprobe ist klein. Sie umfasst fünf Durchläufe pro Modell, einen Client, einen Prompt und einen Tag. Sie zeigt, wie man misst, nicht, wer am schnellsten ist.

Drei Geschwindigkeitskennzahlen: LLM-Latenz vs. Durchsatz in der Praxis

Unterteilen Sie "Geschwindigkeit" in Abschnitte, da jeder Teil einen anderen Verantwortlichen hat: das Netzwerk, das Modell und Ihre eigene Warteschlange.

send request
  -> first stream event          (beliebiger SSE-Chunk; kann ein Reasoning-Delta sein)
  -> first visible content token (erstes nicht-leeres delta.content)
  -> last token + final usage chunk

Time to First Token (TTFT) ist die Zeit vom Absenden der Anfrage bis zum Eintreffen des ersten Tokens. Wir erfassen zwei Versionen. Das erste Stream-Ereignis ist der erste SSE-Chunk jeglicher Art. Das erste sichtbare Inhalts-Token ist der erste Chunk, dessen choices[0].delta.content nicht leer ist. Bei Modellen, die vor der Antwort nachdenken (Reasoning), kann das erste Ereignis ein Reasoning-Delta (delta.reasoning_content) sein, das deutlich vor dem sichtbaren Text eintrifft. Ein Test-Tool, das nur delta.content überwacht, misst die Zeit bis zum ersten sichtbaren Token, nicht die Zeit bis zum ersten Byte. Benutzer nehmen das sichtbare Token wahr.

Gesamtzeit läuft vom Absenden der Anfrage bis zum Ende des Streams. Sie beinhaltet Reasoning, Netzwerkzeit und jede von Ihnen hinzugefügte Wartezeit für Wiederholungsversuche.

Output-Token pro Sekunde sind die ausgegebenen Token geteilt durch die Gesamtzeit. Nehmen Sie die Token-Anzahl aus usage.completion_tokens, welche auch Reasoning-Token enthält. Wir teilen durch die Gesamtzeit, nicht durch das sichtbare Fenster. Einige Modelle in unserer Stichprobe lieferten sichtbaren Text in wenigen großen Chunks, daher wäre eine fensterbasierte Rate irreführend.

Workload	Zuerst beachten	Dann	Warum
Chat	Erstes sichtbares Token	Gesamtzeit	Der Benutzer sieht ein leeres Feld, bis sichtbarer Text erscheint.
Agenten	Gesamtzeit	Erstes sichtbares Token	Jeder Schritt wartet meist auf den vorherigen, daher summieren sich die Summen pro Schritt.
Batch-Extraktion oder Zusammenfassungen	Output-Token pro Sekunde und Kosten pro Aufgabe	Request-Limit-Spielraum	Niemand achtet auf das erste Token, und das Request-Limit des Accounts begrenzt, wie schnell Sie Arbeit einreichen können.

Nicht-Streaming-Aufrufe, wie strukturierte JSON-Extraktion, zeigen nur die Gesamtzeit. Streamen Sie diese beim Testen, wenn Sie die Aufschlüsselung wünschen.

Was wir am 03.10.2026 gemessen haben

Methode. Dies ist eine interne TokenLab-Messung, beobachtet am 03.10.2026, gegen POST https://api.tokenlab.sh/v1/chat/completions (Quelle). Jede Anfrage verwendete stream=true und stream_options.include_usage=true. Wir führten 5 sequentielle Durchläufe pro Modell von einem Client in Ostasien aus, unter Verwendung von Node 24 fetch. Der Prompt lautete: "Erklären Sie, wie HTTP keep-alive die Latenz für API-Clients reduziert. Schreiben Sie etwa 200 Wörter." Jedes Modell verwendete Standard-Reasoning-Einstellungen. Die Zeitangaben sind clientseitige Wall-Clock-Zeiten, und alle Durchläufe (5/5) waren für jede Zeile unten erfolgreich.

Modell (max_tokens 2000)	Median erstes Stream-Ereignis	Median erstes sichtbares Token	Median Gesamtzeit	Median Completion-Token (Reasoning)	Geschätzte 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 (nicht gemeldet)	34
gpt-5.6-luna	3.262 ms	3.262 ms	8.183 ms	313 (42)	38

Die Spalte Token/s ist unsere eigene Schätzung: Median der Completion-Token geteilt durch Median der Gesamtsekunden, zum Beispiel 453 ÷ 5,204 ≈ 87. Es ist ein Verhältnis von Medianen, kein Median der Raten pro Durchlauf.

Was die Zahlen zeigen, und nicht mehr:

• Die Sortierung nach dem ersten sichtbaren Token (claude-sonnet-5-5, gpt-5.6-luna, deepseek-v4.1-flash, gemini-3.8-flash) unterscheidet sich von der Sortierung nach der Gesamtzeit (deepseek-v4.1-flash, gpt-5.6-luna, gemini-3.8-flash, claude-sonnet-5-5). Eine Metrik kann die andere nicht ersetzen.
• deepseek-v4.1-flash hatte eine Lücke von 1.591 ms zwischen dem ersten Ereignis und dem ersten sichtbaren Token. Sein medianer sichtbarer Output betrug etwa 228 Token, geliefert in 87 Ereignissen über 1.304 ms.
• Für gemini-3.8-flash teilen sich das erste Ereignis und das erste sichtbare Token einen Median von 6.892 ms. Sein sichtbarer Text kam in einem Median von 11 Ereignissen über 1.734 ms, der Stream war also eher blockweise als Token für Token.
• claude-sonnet-5-5 sandte einen Median von 371 Ereignissen über 9.186 ms, und gpt-5.6-luna sandte 265 Ereignisse über 4.901 ms.

Kosten stehen neben der Geschwindigkeit. Die Preise unten stammen von der TokenLab Modell-API, beobachtet am 03.10.2026, mit Preisen aktualisiert am 02.10.2026T16:53:30.068Z. Die letzte Spalte ist eine Schätzung: Median der Completion-Token mal Output-Rate, nur Output-Seite. Überprüfen Sie die Nutzungsdatensätze für tatsächliche Gebühren.

Modell	Input pro 1M	Output pro 1M	Max Output-Token	Schätzung Output-Seite, Median-Durchlauf	Quelle
deepseek-v4.1-flash	$0.15 off-peak, $0.30 peak	$0.60 off-peak, $1.20 peak	384.000	453 × $0.60 / 1M ≈ $0.00027 off-peak, ≈ $0.00054 peak	Modell API
gemini-3.8-flash	$0.375	$1.875	65.536	826 × $1.875 / 1M ≈ $0.00155	Modell API
claude-sonnet-5-5	$0.60	$3	128.000	418 × $3 / 1M ≈ $0.00125	Modell API
gpt-5.6-luna	$0.06	$0.36	128.000	313 × $0.36 / 1M ≈ $0.00011	Modell API

Für gpt-5.6-luna gelten diese Raten, wenn der Input maximal 272K Token beträgt. Darüber hinaus verwendet die vollständige Anfrage die 2-fache Input- und 1,5-fache Output-Rate.

Grenzen dieser Stichprobe. Fünf sequentielle Durchläufe von einem Client in Ostasien sind ein kleiner Ausschnitt. Der Prompt war eine kurze Essay-Anfrage, daher ändern sich die Ergebnisse je nach Region, Tageszeit, Prompt und Output-Länge. Wir haben keine Nebenläufigkeit (Concurrency) getestet, daher sagt dies nichts darüber aus, was unter Last passiert. Betrachten Sie die Tabelle als Vorlage für Ihren eigenen Test, ausgeführt aus der Region, in der die Produktion läuft. Wenn Sie einen breiteren Überblick über Modelle wünschen, ist das TokenLab LLM API Leaderboard für Entwickler ein Ausgangspunkt. Überprüfen Sie dessen Methode und Datum, bevor Sie einem Geschwindigkeitswert dort vertrauen. Tauschen Sie Modelle auch nicht stillschweigend aus: Der Leitfaden zur Zuverlässigkeit, beobachtet am 03.10.2026, merkt an, dass ein Ersatz Qualität, Preis, Kontextlänge und Tools ändern kann.

Reasoning-Token und max_tokens: warum 400 fast nichts zurückgaben

Wir haben denselben Prompt auch mit max_tokens auf 400 gesetzt ausgeführt. Gleiche Methode, gleiche fünf Durchläufe, gleiches Datum (Quelle).

Modell (max_tokens 400)	Median Completion-Token	Median Reasoning-Token	Sichtbarer Output (ca.)	Median erstes sichtbares Token	Median Gesamtzeit
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	nicht gemeldet	400 Token	3.088 ms	11.078 ms
gpt-5.6-luna	317	42	275 Token	3.040 ms	8.083 ms

Mediane werden pro Spalte berechnet, daher müssen die Spalten einer Zeile nicht einen einzelnen Durchlauf beschreiben. Deshalb zeigt deepseek-v4.1-flash eine Zeit bis zum ersten sichtbaren Token neben einem Median von null sichtbaren Ereignissen.

Das Ergebnis ist eindeutig. deepseek-v4.1-flash und gemini-3.8-flash verbrauchten fast das gesamte 400-Token-Budget für Reasoning und lieferten fast keinen sichtbaren Text. Das Erhöhen von max_tokens auf 2000 führte zu vollständigen Antworten. Reasoning-Token zählen innerhalb von usage.completion_tokens. Sie werden separat in usage.completion_tokens_details.reasoning_tokens gemeldet.

Als wir das erste 400-Token-Ergebnis sahen, sah der Fehler wie eine leere Antwort aus, nicht wie ein Budgetproblem. Drei Prüfungen machen dies sichtbar:

1. Lesen Sie den finalen Usage-Chunk, aktiviert durch stream_options={"include_usage": True}. Wenn reasoning_tokens nahe an completion_tokens liegt und der Text leer ist, floss das Budget in das Reasoning.
2. Überprüfen Sie finish_reason. Der Streaming-Leitfaden (beobachtet am 03.10.2026) listet length als Wert, wenn ein Token-Limit erreicht wurde.
3. Vergleichen Sie dies mit dem maximalen Output des Modells. Zum Beispiel listet die Modell-API 384.000 für deepseek-v4.1-flash und 65.536 für gemini-3.8-flash, also waren 400 ein winziger Teil dessen, was die Modelle erlauben.

Die Create Chat Completion-Referenz (beobachtet am 03.10.2026) listet auch max_completion_tokens und reasoning_effort. Sie besagt, dass unterstützte Werte vom Modell abhängen, lesen Sie also die Modellseite, bevor Sie beides festlegen. Wir haben diese nicht getestet und jede Zeile mit Standard-Reasoning ausgeführt. Dimensionieren Sie das Limit basierend auf Ihrem eigenen Prompt: In unserem Durchlauf erzeugte eine 200-Wörter-Antwort etwa 228 bis 418 sichtbare Token und zusätzlich bis zu 528 Reasoning-Token.

Ein Mess-Tool für die TokenLab Basis-URL

Dieses Skript verwendet die TokenLab Basis-URL, liest Token-Anzahlen aus dem Usage-Chunk und zeichnet das erste Stream-Ereignis separat vom ersten sichtbaren Inhalts-Token auf. Es behält auch Antwort-Header für späteres Debugging bei. Es folgt den Client-Einstellungen in der Dokumentation (timeout=30.0, max_retries=0), sodass das SDK keine versteckten Wiederholungsversuche zu Ihren Zeitmessungen hinzufügt. Die Modell-ID ist eine, die wir gemessen haben; tauschen Sie jede ID aus, deren akzeptierte Anfrageformate openai_chat_completions beinhalten.

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 = "Erklären Sie, wie HTTP keep-alive die Latenz für API-Clients reduziert. Schreiben Sie etwa 200 Wörter."

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))

Ein paar Hinweise zum Lesen der Ausgabe:

• first_event_s feuert bei jedem Chunk, einschließlich eines reinen Rollen- oder Reasoning-Chunks. first_visible_s feuert nur bei nicht-leerem delta.content. Wenn beide um Sekunden differieren, denkt das Modell nach, bevor es antwortet.
• Token-Anzahlen kommen aus dem finalen Usage-Chunk. Dieser Chunk hat eine leere choices-Liste, weshalb die Schleife chunk.usage prüft, bevor sie ihn überspringt.
• Führen Sie es fünfmal oder öfter aus, notieren Sie die Region und berichten Sie Mediane zusammen mit der Stichprobengröße.
• Für Modelle, die openai_responses auflisten, zeigt der Streaming-Leitfaden Responses, die mit response.output_text.delta und response.completed Ereignissen streamen. Die gleiche Aufteilung gilt: Messen Sie das erste Ereignis, dann das erste Text-Delta.
• Betrachten Sie einen Stream, der vor response.completed oder einem stop-Finish-Reason schließt, als unvollständig, nicht als schnellen Erfolg.

Header und Identifikatoren zum Protokollieren für Latenz-Debugging

Eine langsame Anfrage ist schwer zu debuggen, wenn Sie nur eine Dauer gespeichert haben. Die API-Referenz und der Troubleshooting-Leitfaden, beide beobachtet am 03.10.2026, nennen die Identifikatoren, die es wert sind, behalten zu werden.

Identifikator	Wo er erscheint	Verwendung für
X-Request-ID	Antwort-Header, wenn verfügbar	Support und Debugging für eine Anfrage
request_id	Fehler-Bodies, Dashboard-Logs, Nutzungsdatensätze	Support auf Anfrage-Ebene und Abgleich
X-Routing-Time-MS	Antwort-Header, wenn verfügbar	Zeit für die Auswahl der Zustellung, vor der Generierung
X-Task-ID, task_id, poll_url	Async-Erstellungs- und Status-Antworten	Bild-, Video-, Musik- und 3D-Jobs
X-Billing-Transaction-ID	Header nach finaler Abrechnung, wenn verfügbar	Kostenabgleich
Ihre eigene Job- oder User-ID	Ihre Anwendung	Finden der Anfrage hinter einer Benutzerbeschwerde

Protokollieren Sie für jeden Aufruf den Endpunkt, die Methode, das Modell, den Statuscode, den Zeitstempel und die Latenz. Fügen Sie die Feldnamen hinzu, die Sie gesendet haben (nicht den Prompt), Ihre Anzahl an Wiederholungsversuchen und ob ein Wiederholungsversuch eine neue Aufgabe erstellt oder eine bestehende fortgesetzt hat. Unser Test-Tool fügt die aufgeteilten Zeitmessungen und Token-Anzahlen aus dem Usage-Chunk hinzu.

Zwei Vorsichtsmaßnahmen. Streaming-Antworten können sich nach Ende des Streams stabilisieren, daher kann ein Abrechnungs-Header fehlen, selbst wenn die Nutzung später aufgezeichnet wird. Verwenden Sie für abgerechnete Beträge die Nutzungsdatensätze der Management-API anstelle der Token-Anzahlen aus der Antwort allein. Protokollieren Sie auch den Wert X-TokenLab-Delivery-Policy, falls Sie einen festlegen. Die Referenz besagt, dass sie auto, verified oder official akzeptiert, dass ein ungültiger Wert 400 zurückgibt und eine nicht verfügbare Option 503 mit code: delivery_tier_unavailable und retryable: true zurückgibt. Protokollieren Sie niemals Authorization, API-Keys, signierte URLs, vollständige Prompts oder persönliche Daten.

Konsolen-Anfragedetails werden 30 Tage ab Erfassung aufbewahrt, kopieren Sie also die IDs, die Sie benötigen, in Ihre eigenen Logs. In unserer Pipeline gleichen wir diese IDs mit der Anfragen-Ansicht ab; der Beitrag zur TokenLab Request Console deckt diese Ansicht ab.

Rate Limits, Retries und LLM-Latenz vs. Durchsatz

Geschwindigkeit pro Stream und Durchsatz des Accounts sind unterschiedliche Obergrenzen. Der Rate-Limits-Leitfaden, beobachtet am 03.10.2026, listet die Standard-Tier-Werte unten auf. Er merkt an, dass sie sich mit der aktiven Konfiguration ändern können und pro API-Key durchgesetzt werden.

Tier	Anfragen pro Minute
User	1.000
Partner	10.000
VIP	10.000

Wenn Sie das Limit überschreiten, gibt die API 429 rate_limit_exceeded mit einem Retry-After-Header zurück. Der Body im Beispiel des Leitfadens enthält "retryable": true und "retry_after": 8. Der Leitfaden empfiehlt, den zurückgegebenen X-RateLimit-Limit- und Retry-After-Werten mehr zu vertrauen als jeder kopierten Tabelle. Er besagt auch, dass ein schnelleres Modell das Request-Limit Ihres Accounts nicht erhöht.

Hier ist die Arithmetik für Batch-Arbeit. Dies ist unsere Schätzung basierend auf den Medianen oben, kein Lasttest. Nebenläufige Streams sind grob Anfragen pro Sekunde mal Sekunden pro Anfrage. Bei 1.000 Anfragen pro Minute (etwa 16,7 pro Sekunde):

• Mit deepseek-v4.1-flash bei einem Median von 5,204 s Gesamtzeit laufen etwa 87 Streams gleichzeitig.
• Mit claude-sonnet-5-5 bei einem Median von 12,384 s laufen etwa 206 Streams gleichzeitig.

Ein langsamerer Stream bedeutet mehr Nebenläufigkeit, um die gleiche Anfragerate zu erreichen. Das Erreichen des Limits fügt dann Wartezeit zur Generierungszeit hinzu. Token-Limits werden auf den von uns verwendeten Seiten nicht behandelt, prüfen Sie also Ihren Account und die Modellseite darauf.

Wie man Wiederholungsversuche durchführt, ohne die Zahlen zu ruinieren:

• Respektieren Sie Retry-After, wenn vorhanden. Verwenden Sie ansonsten exponentielles Backoff mit zufälligem Jitter und einem harten Limit für Versuche.
• Stellen Sie das SDK auf max_retries=0 und führen Sie Wiederholungen an einer Stelle durch. Andernfalls wiederholen zwei Ebenen denselben Aufruf und Ihre Zeitmessungen zählen doppelt.
• Wiederholen Sie niemals Validierungs-, Authentifizierungs-, Guthaben- oder Berechtigungsfehler. Wiederholen Sie transiente 5xx-Antworten mit kurzem Backoff.
• Nachdem das erste Ereignis eingetroffen ist, ist ein unterbrochener Stream unvollständig und wird nicht automatisch neu gestartet. Das Wiederholen der Anfrage kann zu einem anderen Output und einer weiteren Gebühr führen.
• Protokollieren Sie die Anzahl der Wiederholungsversuche und die Wartezeit separat von der Modellzeit, damit ein gedrosselter Durchlauf nicht wie ein langsames Modell aussieht.

Dies ist das begrenzte Retry-Muster des Leitfadens:

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)

Begrenzen Sie auch die Nebenläufigkeit, nicht nur die durchschnittlichen Anfragen pro Minute, und reihen Sie Bursts ein. Verfolgen Sie wiederholte 429-Antworten pro API-Key, damit ein Client nicht den Rest Ihrer Anwendung verdrängt.

FAQ

Ist eine höhere Anzahl an Token pro Sekunde immer eine schnellere Benutzererfahrung?

Nein. In unserer Stichprobe vom 03.10.2026 zeigte claude-sonnet-5-5 das früheste erste sichtbare Token (2.981 ms), aber die längste Gesamtzeit (12.384 ms). deepseek-v4.1-flash begann später mit sichtbarem Text (3.925 ms) und war als Erster fertig (5.204 ms). Was sich schneller anfühlt, hängt davon ab, ob der Benutzer den Stream beobachtet oder auf die vollständige Antwort wartet. Fünf Durchläufe von einem Client können das für Ihren Workload nicht entscheiden.

Warum kam meine gestreamte Antwort mit fast keinem Text zurück?

Sie haben wahrscheinlich das Budget für Reasoning verbraucht. Bei max_tokens 400 verbrauchte deepseek-v4.1-flash 400 Reasoning-Token und lieferte etwa 0 sichtbare Token. Überprüfen Sie usage.completion_tokens_details.reasoning_tokens im finalen Usage-Chunk und den finish_reason. Erhöhen Sie dann das Limit; bei 2000 antworteten beide Reasoning-Modelle in unserem Test vollständig.

Erhöht ein schnelleres Modell mein Rate Limit?

Nein. Der Leitfaden zu Rate Limits besagt, dass Modellgeschwindigkeit, Token-Limits und Account-Rate-Limits separate Einschränkungen sind. Ein schnellerer Stream endet früher und gibt einen Nebenläufigkeits-Slot frei, aber Ihr Request-Limit pro Key bleibt gleich. Fragen Sie den Support nach einem anderen Limit, falls Sie eines benötigen.

Welche IDs sollte ich dem Support senden, wenn ein Stream langsam ist?

Senden Sie die request_id (oder X-Request-ID), den Endpunkt, die Methode, das Modell, den Zeitstempel und den Statuscode. Fügen Sie task_id und poll_url für Async-Arbeit hinzu und billing_transaction_id, falls vorhanden. Fügen Sie Ihre aufgeteilten Zeitmessungen und den sicheren Fehler-Body bei und schwärzen Sie zuerst Keys, Prompts und private Medien.

Führen Sie das obige Test-Tool mit Ihrem eigenen Prompt aus und vergleichen Sie dann, was Sie messen, mit den TokenLab Modell-Rankings.