LLM-Latenz Reduzieren: Caching- Und Edge-Strategien

Die Reduzierung der LLM-Latenz ist eine der wichtigsten Herausforderungen für Entwickler, die reaktionsschnelle KI-Anwendungen erstellen. Während große Sprachmodelle (LLMs) immer leistungsfähiger werden, kann ihre tokenweise Generierung frustrierende Engpässe für Endnutzer verursachen, und lange Wartezeiten führen direkt zu geringerem Engagement und Anwendungsabbrüchen. Die Optimierung Ihrer Inferenz-Pipelines auf Geschwindigkeit ist daher eine grundlegende Anforderung an Entwickler. Dieser Leitfaden beschreibt, wie Sie Prompt-Caching konfigurieren, Antwort-Streaming implementieren, Edge-Netzwerk-Routing strukturieren und Serverless-Konfigurationen nutzen, um Verarbeitungsverzögerungen zu reduzieren.

[!TIP] Performance-Tipp: Isolieren Sie bei der Messung von API-Verzögerungen die Time to First Token (TTFT) von der Gesamtgenerierungsgeschwindigkeit. Eine niedrige TTFT lässt eine Anwendung für den Nutzer sofort reagierend wirken, selbst wenn die vollständige Ausgabegenerierung mehrere Sekunden dauert, da der Text unmittelbar gerendert wird.

Wichtige Erkenntnisse:

• Prompt-Caching: Verwenden Sie statische Präfix-Blöcke wieder, um Parsing-Phasen zu überspringen und die TTFT um 80% zu senken.
• Antwort-Streaming: Senden Sie Tokens über Server-Sent Events (SSE), damit Nutzer eine sofortige Textgenerierung sehen.
• Edge Workers: Führen Sie Autorisierung und Anfrage-Routing in regionalen Edge-Rechenzentren nahe am Nutzer aus.
• Modell-Routing: Leiten Sie einfache Nutzeranfragen an ressourcenschonende Modelle weiter, um die Geschwindigkeit zu optimieren.

Die Komponenten der LLM-API-Latenz

Um Antwortzeiten zu verkürzen, müssen Sie zunächst verstehen, welche Elemente die gesamte API-Verzögerung bestimmen. Die Gesamtlatenz ist die kumulierte Summe von drei verschiedenen Variablen.

Erstens misst die Netzwerklaufzeit, wie lange eine Anfrage vom Client zu Ihrem Server und weiter zur API des Modell-Anbieters benötigt. Dadurch wird die Transitdistanz zu einem wesentlichen Engpass.

Zweitens beschreibt die Time to First Token (TTFT) die Dauer zwischen dem Empfang der Anfrage durch das Modell und der Generierung des ersten Ausgabe-Tokens, weshalb Prompt-Caching so wichtig ist.

Schließlich misst die Token-Generierungsgeschwindigkeit die Rate, mit der die Hardware nachfolgende Tokens ausgibt. Hardware-Beschränkungen bestimmen die Generierungsgeschwindigkeit, doch Entwickler behalten die volle Kontrolle über Transitzeit und TTFT, sodass intelligentes Routing und Caching die LLM-Latenz drastisch reduzieren können.

Voraussetzungen

Bevor Sie mit der Implementierung der folgenden Optimierungen beginnen, stellen Sie sicher, dass die nachstehenden Voraussetzungen erfüllt sind. Keine davon ist exotisch, doch das Überspringen einer einzelnen führt später häufig zu verwirrenden Fehlern.

• Eine von Ihnen kontrollierte Middleware- oder Edge-Laufzeit. Die Beispiele nutzen Cloudflare Workers, aber jede Serverless-Plattform, die eine Anfrage weiterleiten kann, ist geeignet. Sie benötigen eine Instanz zwischen dem Browser und dem Modell-Anbieter.
• API-Zugangsdaten eines Anbieters, der Streaming und Caching unterstützt. OpenAI und Anthropic bieten beides. Speichern Sie den Schlüssel als Secret (ein Wrangler-Secret oder eine Umgebungsvariable), niemals im clientseitigen Code.
• Node.js 18 oder neuer, falls Sie Workers lokal mit wrangler dev testen möchten. Die durchgängig verwendeten globalen APIs fetch und ReadableStream sind in dieser Laufzeit und in modernen Browsern verfügbar.
• Eine Ausgangsmessung (Baseline). Erfassen Sie Ihre aktuelle Time to First Token und die Gesamtantwortzeit, bevor Sie etwas ändern, damit Sie den Nutzen jeder Optimierung belegen können. Der folgende Benchmarking-Abschnitt zeigt, wie.
• Vertrautheit mit Server-Sent Events (SSE). Streaming-Antworten treffen als Folge von data:-Zeilen ein, die Sie auf dem Client parsen werden.

Implementierung von Prompt-Caching

Prompt-Caching ist die effektivste Methode, um die TTFT für Anwendungen zu optimieren, die auf großen System-Prompts basieren. Wenn eine Anfrage einen langen statischen Anweisungsblock enthält (etwa den System-Prompt eines Agenten oder ein RAG-Referenzdokument), muss der Modell-Anbieter diese Tokens bei jeder Ausführung parsen und kodieren. Sowohl Anthropic als auch OpenAI unterstützen Prompt-Caching, das die geparsten Token-Zustände im Speicher ablegt. Nachfolgende Anfragen mit identischem Präfix überspringen dann die Parsing-Phase und verkürzen die TTFT um bis zu 80%.

Die Cache-Lebensdauer variiert je nach Anbieter. Anthropic hält den Cache bei etwa fünf Minuten Inaktivität aufrecht, während OpenAI ein dynamisches Verfallsmodell verwendet. Regelmäßig geplante Hintergrund-Pings können daher kritische Systemanweisungen im Serverspeicher aktiv halten.

Der Mechanismus unterscheidet sich zwischen den beiden Anbietern geringfügig, und die richtige Struktur der Anfrage entscheidet darüber, ob der Cache tatsächlich greift. Bei Anthropic markieren Sie einen Cache-Breakpoint explizit mit cache_control. Alles vor dem Breakpoint wird gespeichert, daher muss der stabile, statische Inhalt zuerst und der veränderliche, anfragespezifische Inhalt zuletzt stehen:

 1import Anthropic from "@anthropic-ai/sdk";
 2
 3const anthropic = new Anthropic();
 4
 5const response = await anthropic.messages.create({
 6  model: "claude-opus-4-8",
 7  max_tokens: 1024,
 8  system: [
 9    {
10      type: "text",
11      text: SYSTEM_INSTRUCTIONS       // small, sent on every request
12    },
13    {
14      type: "text",
15      text: KNOWLEDGE_BASE,           // large, static reference block
16      cache_control: { type: "ephemeral" }
17    }
18  ],
19  messages: [
20    { role: "user", content: userQuestion }   // volatile — after the breakpoint
21  ]
22});
23
24// Confirm the cache is working
25console.log(response.usage.cache_read_input_tokens);

Der mit Abstand häufigste Fehler besteht darin, einen Zeitstempel, eine Request-ID oder eine andere anfragespezifische Zeichenkette vor dem gecachten Block zu platzieren. Da Caching auf einem Präfix-Abgleich beruht, macht ein einziges geändertes Byte an beliebiger Stelle vor dem Breakpoint alles danach ungültig, und der Cache greift stillschweigend nie. Überprüfen Sie die Funktion, indem Sie usage.cache_read_input_tokens aus der Antwort auslesen: Bleibt dieser Wert über identische Anfragen hinweg bei null, hat sich etwas Dynamisches in das Präfix eingeschlichen. Beachten Sie außerdem, dass das gecachte Präfix eine Mindestlänge (je nach Modell im Bereich von 1.024 bis 4.096 Tokens) überschreiten muss, bevor Caching überhaupt greift.

OpenAI verfolgt einen einfacheren Ansatz: Caching erfolgt automatisch für Prompts ab etwa 1.024 Tokens, ohne dass ein cache_control-Flag gesetzt werden muss. Dieselbe Disziplin gilt jedoch weiterhin. Halten Sie den statischen Anweisungsblock ganz am Anfang Ihres messages-Arrays und hängen Sie die wechselnde Nutzereingabe am Ende an, damit das wiederverwendbare Präfix zwischen den Anfragen Byte für Byte identisch bleibt.

Die Preis- und Parameterstrukturen des Prompt-Cachings finden Sie im Anthropic Prompt Caching Guide .

Edge Compute und Serverless Routing

Die Verarbeitung von LLM-Anfragen auf einem einzelnen zentralen Server verursacht für globale Nutzer massive Netzwerk-Hops. Die Bereitstellung Ihrer API-Middleware auf Serverless-Edge-Netzwerken (wie Cloudflare Workers) verkürzt diese Wege drastisch.

Der Edge-Worker empfängt die Client-Anfrage, autorisiert die Sitzung und leitet sie an das nächstgelegene Rechenzentrum des Modell-Anbieters weiter. Diese Serverless-Struktur liefert Tokens in dem Moment auf den Bildschirm des Nutzers, in dem sie berechnet werden, sodass sich die Oberfläche äußerst reaktionsschnell anfühlt. Die folgende JavaScript-Middleware zeigt, wie Sie Streaming-Antworten direkt aus einer Edge-Laufzeit konfigurieren:

 1export default {
 2  async fetch(request, env) {
 3    const payload = await request.json();
 4
 5    // Call the streaming LLM endpoint
 6    const response = await fetch("https://api.openai.com/v1/chat/completions", {
 7      method: "POST",
 8      headers: {
 9        "Authorization": `Bearer ${env.OPENAI_API_KEY}`,
10        "Content-Type": "application/json"
11      },
12      body: JSON.stringify({
13        model: "gpt-4o-mini",
14        messages: payload.messages,
15        stream: true
16      })
17    });
18
19    // Forward the stream directly to the client browser
20    return new Response(response.body, {
21      headers: { "Content-Type": "text/event-stream" }
22    });
23  }
24};

Diese Serverless-Struktur liefert Tokens sofort auf den Bildschirm des Nutzers, sobald sie berechnet werden. Wie Sie edge-optimierte Backends erstellen, erfahren Sie in unserem Leitfaden zum Erstellen einer serverlosen API mit Cloudflare Workers .

Stream-Parsing auf der Client-Seite

Die Weiterleitung des Streams vom Edge-Server ist nur die halbe Arbeit. Der Browser muss die eintreffenden Chunks weiterhin beim Eintreffen lesen und jedes Token rendern, andernfalls sammelt sich die Antwort in einem Puffer und erscheint auf einen Schlag, was den Zweck zunichtemacht. Dies ist der Schritt, den die meisten Tutorials überspringen, und genau hier wird die wahrgenommene Performance tatsächlich gewonnen oder verloren.

Der Antwortkörper ist ein ReadableStream aus Rohbytes. SSE-Frames treffen als data:-Zeilen ein, doch ein einzelner Netzwerk-Chunk kann mehrere Frames enthalten oder einen Frame auf zwei Chunks aufteilen. Daher müssen Sie unvollständige Zeilen puffern, statt anzunehmen, dass jeder Chunk eine vollständige Nachricht ist:

 1async function streamCompletion(messages, onToken) {
 2  const response = await fetch("/api/chat", {
 3    method: "POST",
 4    headers: { "Content-Type": "application/json" },
 5    body: JSON.stringify({ messages })
 6  });
 7
 8  const reader = response.body.getReader();
 9  const decoder = new TextDecoder();
10  let buffer = "";
11
12  while (true) {
13    const { value, done } = await reader.read();
14    if (done) break;
15
16    buffer += decoder.decode(value, { stream: true });
17    const lines = buffer.split("\n");
18    buffer = lines.pop();              // keep the trailing partial line
19
20    for (const line of lines) {
21      if (!line.startsWith("data: ")) continue;
22      const payload = line.slice(6).trim();
23      if (payload === "[DONE]") return;
24
25      try {
26        const json = JSON.parse(payload);
27        const token = json.choices?.[0]?.delta?.content;
28        if (token) onToken(token);
29      } catch {
30        // ignore keep-alive comments and malformed partial frames
31      }
32    }
33  }
34}

Das buffer.split("\n") gefolgt von lines.pop() ist das entscheidende Detail: Es bewahrt jede unvollständige Zeile auf, bis der nächste Chunk sie vervollständigt. Das Umschließen von JSON.parse mit einem try/catch hält die Schleife am Laufen, wenn ein Keep-Alive-Kommentar oder ein halb empfangener Frame eintrifft. Der onToken-Callback hängt anschließend jedes Fragment an das DOM an, sodass der Text in dem Moment erscheint, in dem das Modell ihn erzeugt.

Latenz messen und benchmarken

Sie können nicht optimieren, was Sie nicht gemessen haben. Erfassen Sie vor und nach jeder Änderung die Time to First Token und die Gesamtgenerierungszeit, damit Sie eine Verbesserung der richtigen Ursache zuordnen können. Am schnellsten ermitteln Sie die TTFT mit curl, wobei time_starttransfer als guter Näherungswert dafür dient, wann das erste Byte den Client erreicht:

1curl -w "TTFT: %{time_starttransfer}s\nTotal: %{time_total}s\n" \
2  -X POST https://your-worker.example.com/chat \
3  -H "Content-Type: application/json" \
4  -d '{"messages":[{"role":"user","content":"Hello"}]}' \
5  -o /dev/null -s

Für Werte auf Anwendungsebene instrumentieren Sie den Client-Parser direkt. Setzen Sie einen Zeitstempel, wenn die Anfrage abgeht, und erneut, wenn das erste Token eintrifft:

1const start = performance.now();
2let firstTokenAt = null;
3
4await streamCompletion(messages, (token) => {
5  if (firstTokenAt === null) firstTokenAt = performance.now();
6  render(token);
7});
8
9console.log(`TTFT: ${Math.round(firstTokenAt - start)}ms`);

Führen Sie jede Messung mehrfach durch und nehmen Sie den Median statt einer Einzelmessung, da Netzwerkschwankungen und Kaltstarts einzelne Werte verfälschen können. Die folgende Tabelle zeigt beispielhafte Bereiche dafür, wohin die Zeit bei einer gut funktionierenden globalen Anfrage typischerweise fließt; betrachten Sie sie als Vergleichsmuster, nicht als feste Werte, da Ihre eigenen Zahlen von Region, Modell und Prompt-Größe abhängen.

Die beiden Zeilen, die genaueres Hinsehen verdienen, sind die TTFT-Werte mit und ohne Cache. Diese Differenz ist der mit Abstand größte Gewinn, der für die meisten Anwendungen erzielbar ist, weshalb Prompt-Caching ganz oben auf der Optimierungsliste steht. Die Generierungsgeschwindigkeit hingegen ist durch den Anbieter festgelegt, sodass hier das Weiterleiten einfacherer Anfragen an ein kleineres Modell der einzige Hebel ist.

Schritt-für-Schritt-Optimierungs-Workflow

Um die Geschwindigkeit Ihrer Softwareanwendung zu optimieren, trennen Sie zunächst statische Systemanweisungen von dynamischen Nutzereingaben. Diese Aufteilung ermöglicht es Ihnen, Cache-Einstiegspunkte sauber zu adressieren.

Aktivieren Sie als Nächstes die Prompt-Caching-Flags in Ihren API-Payloads, damit der Modell-Anbieter Ihre Text-Tokens im Speicher ablegt.

Konfigurieren Sie stets Antwort-Streaming über standardmäßige SSE-Endpunkte. Indem Sie schlanke Frontend-Parser schreiben, die Chunks beim Eintreffen verarbeiten, verbessern Sie die vom Nutzer wahrgenommene Performance. Richten Sie anschließend Modell-Fallback-Pfade ein: Leiten Sie einfache Kundeneingaben an kleinere Modelle weiter und reservieren Sie größere Reasoning-Modelle für anspruchsvolle Aufgaben. Analysieren Sie schließlich die Netzwerk-Hops, um zu bestätigen, dass Serverless-Worker die Transitverzögerungen reduzieren. Details zur Datenbankoptimierung finden Sie in unserem Leitfaden zu WordPress versus individueller Webentwicklung .

Häufige Fehler und Fehlerbehebung

Eine Handvoll Fehler tritt immer wieder auf, wenn Teams Streaming und Caching erstmals einführen. Das Erkennen des Symptoms erspart Ihnen Stunden des Rätselratens.

Eine subtilere Falle ist das Puffern am Edge selbst. Wenn Sie im Worker await response.text() aufrufen, bevor Sie zurückkehren, haben Sie eine Streaming-Antwort unbemerkt wieder in eine blockierende verwandelt. Leiten Sie den Stream-Body stets direkt weiter. Achten Sie ebenso auf die CPU-Limits des Workers: Aufwändige Arbeit pro Anfrage in der Middleware erhöht die TTFT direkt, halten Sie daher die Autorisierungs- und Routing-Logik minimal und verschieben Sie alles Aufwändige.

Produktionsüberlegungen

Ein Demo-Streaming im Browser zum Laufen zu bringen ist unkompliziert; es unter realem Datenverkehr zuverlässig zu betreiben erfordert einige zusätzliche Absicherungen.

Legen Sie ein sinnvolles Anfrage-Timeout für den Upstream-Aufruf fest, damit eine hängende Anbieterverbindung einen Worker nicht unbegrenzt offen halten kann, und kombinieren Sie es mit einem Retry, der bei einem Timeout des primären Anbieters auf einen zweiten Anbieter oder ein kleineres Modell zurückgreift. Da Prompt-Caching einen kleinen Aufschlag auf Cache-Schreibvorgänge und einen großen Rabatt auf Lesevorgänge berechnet, lohnt es sich nur, wenn ein Präfix wiederverwendet wird; ein Hintergrund-Ping alle paar Minuten hält einen aktiven System-Prompt im Speicher, ohne dass er bei jeder Nutzeranfrage neu geschrieben werden muss.

Instrumentieren Sie kontinuierlich, nicht nur beim Start. Protokollieren Sie TTFT und Tokens pro Sekunde je Anfrage und lösen Sie eine Warnung aus, wenn der Median abdriftet, da sich eine anbieterseitige Verschlechterung oder eine Änderung der Prompt-Größe zuerst dort zeigt. Respektieren Sie schließlich die Rate-Limits des Anbieters: Eine Welle gleichzeitiger Streams kann diese auslösen, verteilen Sie die Last daher elegant über eine Warteschlange oder werfen Sie sie kontrolliert ab, statt Anfragen stillschweigend scheitern zu lassen. Diese Maßnahmen verwandeln einen schnellen Prototyp in eine Anwendung, die schnell bleibt, wenn es darauf ankommt.

Wichtige Erkenntnisse

• Adressieren Sie die Time to First Token (TTFT) und die Transitzeit, um die LLM-Latenz zu reduzieren.
• Nutzen Sie Prompt-Caching in Modell-APIs, um den systematischen Overhead beim Parsen von Anweisungen zu umgehen.
• Verwenden Sie Antwort-Streaming, um Tokens in Echtzeit zu liefern und die wahrgenommene Geschwindigkeit zu verbessern.
• Stellen Sie API-Middleware auf Serverless-Edge-Laufzeiten bereit, um globale Netzwerkwege zu verkürzen.
• Leiten Sie einfachere Nutzeranfragen an ressourcenschonende Modelle weiter, um die Ausführungsgeschwindigkeit zu optimieren.
• Richten Sie Performance-Monitoring-Tools ein, um die Latenz unter realen Nutzerbedingungen kontinuierlich zu analysieren und zu reduzieren.

Häufig gestellte Fragen (FAQ)

Wie reduziere ich die LLM-Latenz in der Produktion? Um die LLM-Latenz in der Produktion zu reduzieren, sollten Sie Prompt-Caching für statische Anweisungen implementieren, Token-Streaming aktivieren und Edge-Worker bereitstellen, um das Anfrage-Routing zu optimieren. Durch die Bereitstellung von Serverless-Orchestrierungslaufzeiten näher an globalen Clients umgehen Entwickler mehrere Netzwerk-Routing-Hops und liefern das erste Antwort-Token in Echtzeit.

Was ist Prompt-Caching? Prompt-Caching ist eine API-Funktion, die geparste Textzustände im Serverspeicher ablegt, sodass nachfolgende Anfragen mit demselben Präfix deutlich schneller ausgeführt werden. Indem der systematische Parsing-Zyklus für große Anweisungsdatensätze umgangen wird, reduziert diese Optimierung die Time to First Token (TTFT) um bis zu achtzig Prozent.

Beeinflusst die Modellgröße die Latenz? Ja, kleinere Modelle haben eine deutlich höhere Token-Generierungsgeschwindigkeit, was sie ideal für einfache Aufgaben macht, bei denen die Latenz im Vordergrund steht. Das Weiterleiten einfacher Klassifizierungs- oder Extraktionsanfragen an spezialisierte Edge-Modelle sorgt für schnelle Bearbeitungszeiten, während dichte Modelle für Reasoning-Aufgaben reserviert bleiben.

Wie hilft Server-Sent-Events-(SSE)-Streaming, die wahrgenommene Latenz zu reduzieren? SSE-Streaming sendet Text-Ausgabe-Tokens vom Modell-Host in Echtzeit an den Client-Bildschirm, sobald sie erstellt werden. Obwohl dies die Gesamtausführungsdauer nicht verkürzt, minimiert es die Time to First Token (TTFT) und bietet dem Nutzer eine reaktionsschnelle, aktive Anwendungsoberfläche.

Wie cache ich dynamische LLM-Antworten am Edge? Sie können dynamische Antworten am Edge mit KV-Datenbanken oder Redis-Instanzen mit kurzen TTL-Werten (Time to Live) cachen. Das Caching dynamischer Antworten ist bei wiederkehrenden Nutzeranfragen oder häufigen Kundenservice-Anliegen wirksam und verhindert Netzwerkaufrufe zum Modell-Anbieter vollständig.