{"author":{"@type":"Person","name":"Alexander Bock","url":"https://abxk.ai/de/autor/alexander-bock/"},"categories":["AI Development"],"content":{"markdown":"Im Prototyp schaut niemand auf die Rechnung oder die Uhr. Im großen Maßstab entscheiden beide darüber, ob eine Funktion bleibt: Kleine Kosten je Anfrage werden zu einem großen Monatsposten, und eine langsame Antwort lässt jede Nutzerin warten. Die meisten LLM-Apps verschwenden Tokens und Zeit an denselben wenigen Stellen — deshalb helfen fast überall dieselben wenigen Hebel.\n\nDies ist Teil 5 von Level 4 (Experte), der letzte Teil unseres Lernpfads AI Development. Sie erfahren, woher Kosten und Latenz kommen, wie Sie die Kosten je erfolgreicher Aufgabe messen, welche Hebel Tokens und Wartezeit sparen und wie eine Routing-Kaskade einfache Anfragen an kleine Modelle schickt. Unser Artikel darüber, [wie wir KI-Entwicklungskosten senken](/de/ai-development/reduce-ai-development-costs-without-compromising-results/), behandelt die Phase des Bauens; dieser Teil behandelt die laufenden Kosten jeder Anfrage.\n\n## Wohin Kosten und Zeit in einer Anfrage gehen\n\nAPIs rechnen nach Tokens ab, mit einem Satz für die Eingabe und meist einem höheren für die Ausgabe. Viele Reasoning-Modelle erzeugen zusätzlich verborgene **Reasoning-Tokens**, die in der Regel als Ausgabe abgerechnet werden. Die Zeit folgt einer anderen Logik. Bevor das erste Wort erscheint, liest das Modell die gesamte Eingabe; diese Phase heißt **Prefill** und bestimmt die **Zeit bis zum ersten Token** (Time to First Token, TTFT). Danach schreibt es die Antwort Token für Token. Die **Zeit je Ausgabetoken** (Time per Output Token, TPOT) mal die Zahl der Ausgabetokens macht meist den größten Teil der Gesamtzeit aus.\n\n![Balken für die Teile einer Beispielanfrage — Anweisungen, Tool-Definitionen, Chatverlauf, Dokumente und Frage als Eingabe, Reasoning und Antwort als Ausgabe —, jeweils mit dem Hebel, der sie verkleinert; darunter eine Zeitleiste aus Warten, Prefill und Ausgabe mit der Zeit bis zum ersten Token und der Gesamtzeit](/images/learn/de/optimize-llm-cost-and-latency-anatomy.webp \"Wohin Kosten und Zeit in einer Anfrage gehen und welcher Hebel wo wirkt. Beispiel mit erfundenen Werten.\")\n\nDaraus folgt eine Faustregel: Eingabetokens machen oft den größten Teil der Menge aus, Ausgabetokens den größten Teil der Wartezeit. Der Support-Bot aus Level 0 zeigt die erste Hälfte: Er liest neunmal so viele Tokens, wie er schreibt, meist dieselben Anweisungen und Hilfetexte in jeder Anfrage (siehe [APIs, Tokens und Kontextfenster](/de/ai-development/learn/apis-tokens-and-context-windows/)).\n\n## Die Kosten je erfolgreicher Aufgabe messen\n\nBevor Sie etwas ändern, messen Sie eine Basislinie. Der Preis je Token oder je Anfrage ist die falsche Einheit, denn er verbirgt Wiederholungen, Agenten-Schleifen und misslungene Antworten. Die nützliche Einheit sind die **Kosten je erfolgreicher Aufgabe**: alle Ausgaben für eine Funktion — Modellaufrufe, Wiederholungen, Tool-Aufrufe, Aufrufe eines Bewerters — geteilt durch die Zahl der Aufgaben, die Ihre Qualitätskriterien erfüllt haben. Verfolgen Sie diese Zahl zusammen mit der Erfolgsquote und der p95-Latenz, je Funktion und je Modellversion, und legen Sie eine Mindest-Erfolgsquote fest, die jede Variante erreichen muss.\n\n![Drei Varianten mit Beispielwerten im Vergleich: nur ein großes Modell, nur ein kleines Modell und eine Kaskade; Balken zeigen die Erfolgsquote gegenüber einem Minimum von 90 Prozent und die daraus folgenden Kosten je erfolgreicher Aufgabe](/images/learn/de/optimize-llm-cost-and-latency-per-success.webp \"Günstig je Aufruf heißt nicht günstig je Erfolg. Beispiel mit erfundenen Werten.\")\n\nDas Beispiel zeigt zwei Fallen. Das große Modell allein erreicht die Mindest-Erfolgsquote, kostet aber je Erfolg am meisten. Das kleine Modell allein wirkt am günstigsten, verfehlt aber das Minimum — seine niedrige Zahl zählt also nicht. Die Kaskade erreicht das Minimum für deutlich weniger Geld. Solche Ergebnisse finden Sie nur mit Evals und Traces: Level 2 zeigt, wie Sie [KI-Funktionen mit Evals testen](/de/ai-development/learn/test-ai-features-with-evals/), und die Traces aus Level 3 liefern die Token-Zahlen.\n\n## Weniger Tokens: Budgets, Kompression, kürzere Antworten\n\n**Token-Budgets** setzen harte Grenzen dort, wo Kosten davonlaufen können: eine Höchstzahl an Ausgabetokens je Anfrage, ein Tagesbudget je Nutzer und eine Höchstzahl an Schritten je Agenten-Aufgabe. Ein Agent in einer Endlosschleife gehört zu den teuersten Fehlern einer LLM-App.\n\n**Prompt-Kompression** entfernt, was das Modell nicht braucht. Beginnen Sie von Hand: Streichen Sie doppelte Anweisungen, kürzen Sie Beispiele, senden Sie nur die Tool-Definitionen des aktuellen Wegs, fassen Sie lange Chatverläufe zusammen, und holen Sie weniger, aber bessere Dokumentabschnitte. Werkzeuge aus der Forschung gehen weiter: LLMLingua lässt ein kleines Modell unwichtige Tokens streichen und erreichte auf den getesteten Aufgaben bis zu zwanzigfache Kompression bei geringem Qualitätsverlust (Quelle: Jiang et al., „LLMLingua“, EMNLP 2023). Jede Kompression kann genau den einen Satz entfernen, auf den es ankam — prüfen Sie sie deshalb mit Ihrem Eval-Satz.\n\n**Kürzere Antworten** sparen Kosten und Zeit zugleich. Verlangen Sie ein festes Format, etwa JSON mit festgelegten Feldern oder drei Stichpunkte, und setzen Sie die Ausgabegrenze passend. Bei Reasoning-Modellen wählen Sie die niedrigste Denkstufe, die in Ihren Evals noch besteht.\n\n## Arbeit wiederverwenden und warten lassen: Caching und Batching\n\n[Teil 1 dieses Levels](/de/ai-development/learn/production-llm-architecture/) hat die drei Caches vorgestellt. Auf die Rechnung wirken sie unterschiedlich. Ein **Prompt-Cache** beim Anbieter rechnet ein wiederholtes Präfix günstiger ab und verkürzt die Zeit bis zum ersten Token. Er lohnt sich, wenn langer, gleichbleibender Inhalt am Anfang steht: Anweisungen, Tool-Definitionen, Beispiele, Dokumente. Ein exakter oder semantischer Cache spart den Modellaufruf ganz, aber nur bei wiederholten Fragen und mit den Risiken aus Teil 1.\n\n**Batching** tauscht Zeit gegen Geld. Viele Aufgaben brauchen keine Antwort in Sekunden: die nächtliche Klassifizierung, Zusammenfassungen der Tickets von gestern, Embeddings, Eval-Läufe. Mehrere Anbieter, darunter OpenAI, Anthropic und Google, bieten Batch-Schnittstellen: Sie reichen viele Anfragen auf einmal ein, erhalten die Ergebnisse innerhalb eines Zeitfensters von bis zu 24 Stunden und zahlen je Token weniger als bei Live-Anfragen. Auf eigenen GPUs erhöhen größere Batches den Durchsatz, aber jede Anfrage wartet länger. Das DistServe-Paper nennt die nützliche Kennzahl **Goodput**: die höchste Anfragerate, die ein System bedienen kann, während es seine Latenzziele noch einhält (Quelle: Zhong et al., „DistServe“, OSDI 2024).\n\n## Einfache Anfragen an kleine Modelle leiten\n\nDie meisten Anbieter verkaufen ihre Modelle in Größenstufen. Eine kleinere Stufe antwortet schneller, kostet je Token weniger und reicht für viele Anfragen aus. Zwei Familien aus unserer LLM-Datenbank mit je drei Stufen und dem Gesamtindex der Fähigkeiten (ECI):\n\n{{\u003c llm-models \"claude-opus-5-5 claude-sonnet-5-5 claude-haiku-5-5 gpt-5-4 gpt-5-4-mini gpt-5-4-nano\" \u003e}}\n\n**Modell-Routing** entscheidet für jede Anfrage, welches Modell antwortet. Die verbreitetste Form ist eine **Kaskade**: Das kleine Modell beginnt, eine Prüfung entscheidet, ob seine Antwort gut genug ist, und nur der Rest geht weiter an ein größeres Modell.\n\n![Routing-Kaskade: Jede Anfrage geht zuerst an ein kleines Modell; eine Prüfung nimmt die Antwort an oder eskaliert an ein großes Modell, dessen Antwort eine weitere Prüfung durchläuft; was wieder scheitert, geht an einen Menschen; Beispielanteile von 70, 25 und 5 Prozent der Antworten](/images/learn/de/optimize-llm-cost-and-latency-cascade.webp \"Eine Routing-Kaskade: erst das kleine Modell, eskaliert wird nur, was die Prüfung nicht besteht. Beispielanteile, keine Messung.\")\n\nDie Forschung stützt die Idee. In den Experimenten zu FrugalGPT erreichte eine gelernte Kaskade die Leistung des damals besten Einzelmodells bei bis zu 98 Prozent geringeren Kosten auf den getesteten Aufgaben (Quelle: Chen, Zaharia und Zou, „FrugalGPT“, 2023, arxiv.org). RouteLLM trainierte Router mit Präferenzdaten von Menschen; in einigen Tests senkten sie die Kosten um mehr als die Hälfte, ohne die Qualität der Antworten zu verschlechtern (Quelle: Ong et al., „RouteLLM“, ICLR 2025).\n\nRouting spart mehr als Geld. Weniger Tokens auf großen Modellen bedeuten auch weniger Strom und, über Stromerzeugung und Kühlung, weniger Wasser. Dieser Fußabdruck ist nicht mehr klein: Eine Studie schätzt, dass KI-Systeme 2025 zwischen 32,6 und 79,7 Millionen Tonnen CO₂ verursachten (Quelle: de Vries-Gao, Patterns, Dezember 2025), und laut der Internationalen Energieagentur steigt der Strombedarf von Rechenzentren viermal so schnell wie der aller anderen Sektoren (Quelle: berichtet vom Guardian, März 2026).\n\nDie Prüfung ist die Schwachstelle. Das kann eine Schema-Validierung sein, eine Regel, ein Konfidenzwert oder ein kleines Bewertungsmodell. Nimmt sie falsche Antworten an, spart die Kaskade Geld und verliert unbemerkt Qualität. Eskalierte Anfragen dauern außerdem länger, weil sie zwei Modelle durchlaufen. Bewerten Sie deshalb jeden Weg einzeln, und beobachten Sie die Eskalationsquote: Steigt sie, haben sich Ihr Verkehr oder ein Modell verändert. Für eine enge Aufgabe mit hohem Volumen ist der nächste Schritt die **Destillation**: Sie trainieren ein kleines Modell mit den Antworten eines großen. Level 3 vergleicht das mit [Fine-Tuning, RAG und Prompting](/de/ai-development/learn/fine-tuning-vs-rag-vs-prompting/); prüfen Sie die Bedingungen des Anbieters, bevor Sie mit seinen Ausgaben trainieren.\n\n## Kürzere Wartezeit für Nutzer\n\nFür die Latenz gibt es eigene Hebel. **Streaming** zeigt die ersten Wörter nach der Zeit bis zum ersten Token, sodass sich das Warten kürzer anfühlt — Gesamtzeit und Kosten bleiben aber gleich. Unabhängige Schritte, etwa mehrere Tool-Aufrufe oder Dokumentabfragen, können parallel statt nacheinander laufen. Arbeit, die nicht von der Frage der Nutzerin abhängt, etwa Zusammenfassungen bekannter Dokumente, lässt sich im Voraus berechnen. Und ein selbst betriebenes Modell kann spekulatives Decoding nutzen, beschrieben in [Teil 2 dieses Levels](/de/ai-development/learn/self-host-open-weight-models/).\n\nDie Tabelle zeigt, was jeder Hebel verändert. Jeder Hebel birgt ein Qualitätsrisiko, deshalb läuft jede Änderung zuerst durch Ihre Evals:\n\n| Hebel | Senkt Kosten | Senkt Latenz | Qualitätsrisiko | Am besten für |\n|---|---|---|---|---|\n| Token-Budgets, Ausgabegrenzen | Ja | Ja, kürzere Ausgaben | Abgeschnittene Antworten | Jede Funktion, Agenten-Schleifen |\n| Prompt-Kompression | Ja, Eingabe | Ja, Zeit bis zum ersten Token | Verlorener Kontext | Lange Prompts, RAG, lange Chats |\n| Prompt-Caching | Ja, wiederholte Eingabe | Ja, Zeit bis zum ersten Token | Gering | Lange, gleichbleibende Präfixe |\n| Exakter oder semantischer Cache | Ja | Ja, kein Modellaufruf | Veraltete oder falsche Treffer | Wiederholte Fragen |\n| Batching | Ja | Nein, Ergebnisse kommen später | Gering | Offline-Aufgaben und Evals |\n| Routing und Kaskaden | Ja | Meist; Eskalationen dauern länger | Falsche Antworten werden angenommen | Viele einfache, wenige schwere Anfragen |\n| Streaming | Nein | Nur die gefühlte Wartezeit | Gering | Chats und lange Antworten |\n| Destillation oder Eigenbetrieb | Ja, bei hohem Volumen | Oft | Engere Fähigkeiten, mehr Betrieb | Enge, häufige Aufgaben |\n\n## Die Hebel der Reihe nach angehen\n\nBeginnen Sie mit den Hebeln, die sich günstig ausprobieren und leicht zurücknehmen lassen, und gehen Sie erst zu den schweren über, wenn die Zahlen es verlangen:\n\n![Treppe mit fünf Stufen von unten links nach oben rechts: Basislinie messen, Tokens begrenzen und kürzen, cachen und bündeln, an kleinere Modelle leiten, destillieren oder selbst betreiben](/images/learn/de/optimize-llm-cost-and-latency-ladder.webp \"Fünf Stufen von leicht bis schwer: jede Stufe erst, wenn sich die vorige gelohnt hat.\")\n\nÄndern Sie jeweils nur einen Hebel, und vergleichen Sie die Kosten je erfolgreicher Aufgabe, die Erfolgsquote und die p95-Latenz mit der Basislinie, am besten in einem Canary-Release. Die Infrastruktur für die schwereren Stufen finden Sie in unserem Vergleich. Nach Angaben der Anbieter vermietet Runpod GPUs nach Verbrauch für selbst betriebene oder destillierte Modelle, Pinecone ist eine Vektordatenbank für Retrieval und semantische Caches, und Netlify hostet die Web-App und ihre Serverless-Funktionen:\n\n{{\u003c tools \"runpod pinecone netlify\" \u003e}}\n\n{{\u003c callout type=\"try\" title=\"Finden Sie Ihre drei größten Token-Verbraucher\" \u003e}}\nExportieren Sie die Traces einer Woche für eine einzelne Funktion. Addieren Sie die Eingabe- und Ausgabetokens je Teil des Prompts: Anweisungen, Tools, Verlauf, Dokumente, Reasoning und Antwort. Berechnen Sie dann mit Ihren Eval-Ergebnissen die Kosten je erfolgreicher Aufgabe. Die drei größten Blöcke zeigen Ihnen, welche Hebel Sie zuerst ausprobieren, und die Basislinie sagt Ihnen später, ob sie gewirkt haben.\n{{\u003c /callout \u003e}}","text":"Im Prototyp schaut niemand auf die Rechnung oder die Uhr. Im großen Maßstab entscheiden beide darüber, ob eine Funktion bleibt: Kleine Kosten je Anfrage werden zu einem großen Monatsposten, und eine langsame Antwort lässt jede Nutzerin warten. Die meisten LLM-Apps verschwenden Tokens und Zeit an denselben wenigen Stellen — deshalb helfen fast überall dieselben wenigen Hebel.\nDies ist Teil 5 von Level 4 (Experte), der letzte Teil unseres Lernpfads AI Development. Sie erfahren, woher Kosten und Latenz kommen, wie Sie die Kosten je erfolgreicher Aufgabe messen, welche Hebel Tokens und Wartezeit sparen und wie eine Routing-Kaskade einfache Anfragen an kleine Modelle schickt. Unser Artikel darüber, wie wir KI-Entwicklungskosten senken, behandelt die Phase des Bauens; dieser Teil behandelt die laufenden Kosten jeder Anfrage.\nWohin Kosten und Zeit in einer Anfrage gehen APIs rechnen nach Tokens ab, mit einem Satz für die Eingabe und meist einem höheren für die Ausgabe. Viele Reasoning-Modelle erzeugen zusätzlich verborgene Reasoning-Tokens, die in der Regel als Ausgabe abgerechnet werden. Die Zeit folgt einer anderen Logik. Bevor das erste Wort erscheint, liest das Modell die gesamte Eingabe; diese Phase heißt Prefill und bestimmt die Zeit bis zum ersten Token (Time to First Token, TTFT). Danach schreibt es die Antwort Token für Token. Die Zeit je Ausgabetoken (Time per Output Token, TPOT) mal die Zahl der Ausgabetokens macht meist den größten Teil der Gesamtzeit aus.\nWohin Kosten und Zeit in einer Anfrage gehen und welcher Hebel wo wirkt. Beispiel mit erfundenen Werten. Daraus folgt eine Faustregel: Eingabetokens machen oft den größten Teil der Menge aus, Ausgabetokens den größten Teil der Wartezeit. Der Support-Bot aus Level 0 zeigt die erste Hälfte: Er liest neunmal so viele Tokens, wie er schreibt, meist dieselben Anweisungen und Hilfetexte in jeder Anfrage (siehe APIs, Tokens und Kontextfenster).\nDie Kosten je erfolgreicher Aufgabe messen Bevor Sie etwas ändern, messen Sie eine Basislinie. Der Preis je Token oder je Anfrage ist die falsche Einheit, denn er verbirgt Wiederholungen, Agenten-Schleifen und misslungene Antworten. Die nützliche Einheit sind die Kosten je erfolgreicher Aufgabe: alle Ausgaben für eine Funktion — Modellaufrufe, Wiederholungen, Tool-Aufrufe, Aufrufe eines Bewerters — geteilt durch die Zahl der Aufgaben, die Ihre Qualitätskriterien erfüllt haben. Verfolgen Sie diese Zahl zusammen mit der Erfolgsquote und der p95-Latenz, je Funktion und je Modellversion, und legen Sie eine Mindest-Erfolgsquote fest, die jede Variante erreichen muss.\nGünstig je Aufruf heißt nicht günstig je Erfolg. Beispiel mit erfundenen Werten. Das Beispiel zeigt zwei Fallen. Das große Modell allein erreicht die Mindest-Erfolgsquote, kostet aber je Erfolg am meisten. Das kleine Modell allein wirkt am günstigsten, verfehlt aber das Minimum — seine niedrige Zahl zählt also nicht. Die Kaskade erreicht das Minimum für deutlich weniger Geld. Solche Ergebnisse finden Sie nur mit Evals und Traces: Level 2 zeigt, wie Sie KI-Funktionen mit Evals testen, und die Traces aus Level 3 liefern die Token-Zahlen.\nWeniger Tokens: Budgets, Kompression, kürzere Antworten Token-Budgets setzen harte Grenzen dort, wo Kosten davonlaufen können: eine Höchstzahl an Ausgabetokens je Anfrage, ein Tagesbudget je Nutzer und eine Höchstzahl an Schritten je Agenten-Aufgabe. Ein Agent in einer Endlosschleife gehört zu den teuersten Fehlern einer LLM-App.\nPrompt-Kompression entfernt, was das Modell nicht braucht. Beginnen Sie von Hand: Streichen Sie doppelte Anweisungen, kürzen Sie Beispiele, senden Sie nur die Tool-Definitionen des aktuellen Wegs, fassen Sie lange Chatverläufe zusammen, und holen Sie weniger, aber bessere Dokumentabschnitte. Werkzeuge aus der Forschung gehen weiter: LLMLingua lässt ein kleines Modell unwichtige Tokens streichen und erreichte auf den getesteten Aufgaben bis zu zwanzigfache Kompression bei geringem Qualitätsverlust (Quelle: Jiang et al., „LLMLingua“, EMNLP 2023). Jede Kompression kann genau den einen Satz entfernen, auf den es ankam — prüfen Sie sie deshalb mit Ihrem Eval-Satz.\nKürzere Antworten sparen Kosten und Zeit zugleich. Verlangen Sie ein festes Format, etwa JSON mit festgelegten Feldern oder drei Stichpunkte, und setzen Sie die Ausgabegrenze passend. Bei Reasoning-Modellen wählen Sie die niedrigste Denkstufe, die in Ihren Evals noch besteht.\nArbeit wiederverwenden und warten lassen: Caching und Batching Teil 1 dieses Levels hat die drei Caches vorgestellt. Auf die Rechnung wirken sie unterschiedlich. Ein Prompt-Cache beim Anbieter rechnet ein wiederholtes Präfix günstiger ab und verkürzt die Zeit bis zum ersten Token. Er lohnt sich, wenn langer, gleichbleibender Inhalt am Anfang steht: Anweisungen, Tool-Definitionen, Beispiele, Dokumente. Ein exakter oder semantischer Cache spart den Modellaufruf ganz, aber nur bei wiederholten Fragen und mit den Risiken aus Teil 1.\nBatching tauscht Zeit gegen Geld. Viele Aufgaben brauchen keine Antwort in Sekunden: die nächtliche Klassifizierung, Zusammenfassungen der Tickets von gestern, Embeddings, Eval-Läufe. Mehrere Anbieter, darunter OpenAI, Anthropic und Google, bieten Batch-Schnittstellen: Sie reichen viele Anfragen auf einmal ein, erhalten die Ergebnisse innerhalb eines Zeitfensters von bis zu 24 Stunden und zahlen je Token weniger als bei Live-Anfragen. Auf eigenen GPUs erhöhen größere Batches den Durchsatz, aber jede Anfrage wartet länger. Das DistServe-Paper nennt die nützliche Kennzahl Goodput: die höchste Anfragerate, die ein System bedienen kann, während es seine Latenzziele noch einhält (Quelle: Zhong et al., „DistServe“, OSDI 2024).\nEinfache Anfragen an kleine Modelle leiten Die meisten Anbieter verkaufen ihre Modelle in Größenstufen. Eine kleinere Stufe antwortet schneller, kostet je Token weniger und reicht für viele Anfragen aus. Zwei Familien aus unserer LLM-Datenbank mit je drei Stufen und dem Gesamtindex der Fähigkeiten (ECI):\nModelle aus unserer LLM-Datenbank ModellErschienenGewichteECIRang Claude Opus 5.5 Anthropic22.09.2026geschlossen166,81 Claude Sonnet 5.5 Anthropic28.09.2026geschlossen164,46 Claude Haiku 5.5 Anthropic07.10.2026geschlossen159,014 GPT-5.4 OpenAI05.03.2026geschlossen156,723 GPT-5.4 Mini OpenAI17.03.2026geschlossen148,864 GPT-5.4 Nano OpenAI17.03.2026geschlossen146,179 ECI = Epoch Capabilities Index, ein Gesamtwert über viele Benchmarks; Rang unter allen Modellen mit ECI. Daten: Epoch AI, abgerufen am 17.10.2026, Lizenz CC BY 4.0. Alle Modelle: LLM-Datenbank.\nModell-Routing entscheidet für jede Anfrage, welches Modell antwortet. Die verbreitetste Form ist eine Kaskade: Das kleine Modell beginnt, eine Prüfung entscheidet, ob seine Antwort gut genug ist, und nur der Rest geht weiter an ein größeres Modell.\nEine Routing-Kaskade: erst das kleine Modell, eskaliert wird nur, was die Prüfung nicht besteht. Beispielanteile, keine Messung. Die Forschung stützt die Idee. In den Experimenten zu FrugalGPT erreichte eine gelernte Kaskade die Leistung des damals besten Einzelmodells bei bis zu 98 Prozent geringeren Kosten auf den getesteten Aufgaben (Quelle: Chen, Zaharia und Zou, „FrugalGPT“, 2023, arxiv.org). RouteLLM trainierte Router mit Präferenzdaten von Menschen; in einigen Tests senkten sie die Kosten um mehr als die Hälfte, ohne die Qualität der Antworten zu verschlechtern (Quelle: Ong et al., „RouteLLM“, ICLR 2025).\nRouting spart mehr als Geld. Weniger Tokens auf großen Modellen bedeuten auch weniger Strom und, über Stromerzeugung und Kühlung, weniger Wasser. Dieser Fußabdruck ist nicht mehr klein: Eine Studie schätzt, dass KI-Systeme 2025 zwischen 32,6 und 79,7 Millionen Tonnen CO₂ verursachten (Quelle: de Vries-Gao, Patterns, Dezember 2025), und laut der Internationalen Energieagentur steigt der Strombedarf von Rechenzentren viermal so schnell wie der aller anderen Sektoren (Quelle: berichtet vom Guardian, März 2026).\nDie Prüfung ist die Schwachstelle. Das kann eine Schema-Validierung sein, eine Regel, ein Konfidenzwert oder ein kleines Bewertungsmodell. Nimmt sie falsche Antworten an, spart die Kaskade Geld und verliert unbemerkt Qualität. Eskalierte Anfragen dauern außerdem länger, weil sie zwei Modelle durchlaufen. Bewerten Sie deshalb jeden Weg einzeln, und beobachten Sie die Eskalationsquote: Steigt sie, haben sich Ihr Verkehr oder ein Modell verändert. Für eine enge Aufgabe mit hohem Volumen ist der nächste Schritt die Destillation: Sie trainieren ein kleines Modell mit den Antworten eines großen. Level 3 vergleicht das mit Fine-Tuning, RAG und Prompting; prüfen Sie die Bedingungen des Anbieters, bevor Sie mit seinen Ausgaben trainieren.\nKürzere Wartezeit für Nutzer Für die Latenz gibt es eigene Hebel. Streaming zeigt die ersten Wörter nach der Zeit bis zum ersten Token, sodass sich das Warten kürzer anfühlt — Gesamtzeit und Kosten bleiben aber gleich. Unabhängige Schritte, etwa mehrere Tool-Aufrufe oder Dokumentabfragen, können parallel statt nacheinander laufen. Arbeit, die nicht von der Frage der Nutzerin abhängt, etwa Zusammenfassungen bekannter Dokumente, lässt sich im Voraus berechnen. Und ein selbst betriebenes Modell kann spekulatives Decoding nutzen, beschrieben in Teil 2 dieses Levels.\nDie Tabelle zeigt, was jeder Hebel verändert. Jeder Hebel birgt ein Qualitätsrisiko, deshalb läuft jede Änderung zuerst durch Ihre Evals:\nKosten und Latenz von LLMs im großen Maßstab optimieren Hebel Senkt Kosten Senkt Latenz Qualitätsrisiko Am besten für Token-Budgets, Ausgabegrenzen Ja Ja, kürzere Ausgaben Abgeschnittene Antworten Jede Funktion, Agenten-Schleifen Prompt-Kompression Ja, Eingabe Ja, Zeit bis zum ersten Token Verlorener Kontext Lange Prompts, RAG, lange Chats Prompt-Caching Ja, wiederholte Eingabe Ja, Zeit bis zum ersten Token Gering Lange, gleichbleibende Präfixe Exakter oder semantischer Cache Ja Ja, kein Modellaufruf Veraltete oder falsche Treffer Wiederholte Fragen Batching Ja Nein, Ergebnisse kommen später Gering Offline-Aufgaben und Evals Routing und Kaskaden Ja Meist; Eskalationen dauern länger Falsche Antworten werden angenommen Viele einfache, wenige schwere Anfragen Streaming Nein Nur die gefühlte Wartezeit Gering Chats und lange Antworten Destillation oder Eigenbetrieb Ja, bei hohem Volumen Oft Engere Fähigkeiten, mehr Betrieb Enge, häufige Aufgaben Die Hebel der Reihe nach angehen Beginnen Sie mit den Hebeln, die sich günstig ausprobieren und leicht zurücknehmen lassen, und gehen Sie erst zu den schweren über, wenn die Zahlen es verlangen:\nFünf Stufen von leicht bis schwer: jede Stufe erst, wenn sich die vorige gelohnt hat. Ändern Sie jeweils nur einen Hebel, und vergleichen Sie die Kosten je erfolgreicher Aufgabe, die Erfolgsquote und die p95-Latenz mit der Basislinie, am besten in einem Canary-Release. Die Infrastruktur für die schwereren Stufen finden Sie in unserem Vergleich. Nach Angaben der Anbieter vermietet Runpod GPUs nach Verbrauch für selbst betriebene oder destillierte Modelle, Pinecone ist eine Vektordatenbank für Retrieval und semantische Caches, und Netlify hostet die Web-App und ihre Serverless-Funktionen:\nRunpodInfrastruktur \u0026amp; Hosting · KI ist der KernGPU-Cloud zum Trainieren und Betreiben von KI-Modellen, abgerechnet nach Nutzung. PineconeInfrastruktur \u0026amp; Hosting · KI ist der KernVektordatenbank für KI-Anwendungen, etwa für Suche und Retrieval. NetlifyInfrastruktur \u0026amp; Hosting · Software mit KI-FunktionenPlattform zum Bauen, Ausliefern und Hosten von Websites und Web-Apps. Kurzbeschreibungen aus unserem Tool-Vergleich, nach Angaben der Anbieter — nicht von ABXK getestet.\n▸Finden Sie Ihre drei größten Token-Verbraucher\nExportieren Sie die Traces einer Woche für eine einzelne Funktion. Addieren Sie die Eingabe- und Ausgabetokens je Teil des Prompts: Anweisungen, Tools, Verlauf, Dokumente, Reasoning und Antwort. Berechnen Sie dann mit Ihren Eval-Ergebnissen die Kosten je erfolgreicher Aufgabe. Die drei größten Blöcke zeigen Ihnen, welche Hebel Sie zuerst ausprobieren, und die Basislinie sagt Ihnen später, ob sie gewirkt haben.\n","words":1690},"date":"2026-10-14","description":"Kosten und Antwortzeit einer LLM-App senken, ohne Qualität zu verlieren: Token-Budgets, Caching, Batching, Modell-Routing, Streaming, Kosten je Erfolg.","image":"https://abxk.ai/images/cover/optimize-llm-cost-and-latency.webp","json":"https://abxk.ai/de/ai-development/learn/optimize-llm-cost-and-latency/index.json","kind":"page","language":"de","learning_path":{"category":"ai-development","level":4,"level_name":"Experte"},"modified":"2026-10-14","related_tools":["Runpod","Pinecone","Netlify"],"section":"ai-development","seo_title":"LLM-Kosten und Latenz im großen Maßstab optimieren","tags":["llm-kosten","latenz","modell-routing","caching","experte"],"title":"Kosten und Latenz von LLMs im großen Maßstab optimieren","translations":[{"json":"https://abxk.ai/en/ai-development/learn/optimize-llm-cost-and-latency/index.json","language":"en","url":"https://abxk.ai/en/ai-development/learn/optimize-llm-cost-and-latency/"}],"url":"https://abxk.ai/de/ai-development/learn/optimize-llm-cost-and-latency/"}