Kosten, Kapazität & Lasttests
Ein Dashboard zählt Requests, aber ein einziger langer Auftrag kostet mehr als hundert kurze. Beim Launch sind die Providerquote und die Queue erschöpft, obwohl der Durchschnitt unauffällig bleibt. Erst arbeitsbezogene Maße machen Kosten und Kapazität gemeinsam steuerbar.
Lehrtext · 11 Abschnitte · zuletzt geprüft: 2026-09-04
Drei Grenzen, ein System
Ein LLM-Dienst kann an Geld, Provider-Durchsatz oder eigener Ausführungskapazität scheitern. Diese Grenzen wirken zusammen: Ungebremste Retries verbrauchen Budget und Quota; lange Queues erhöhen die Latenz; Autoscaling kann Last verteilen, aber keine Anbieterquote erzeugen.
Betriebsprobe: COST-ATTRIBUTION
Szenario
Die monatlichen Modellkosten stiegen um 38 Prozent. Traffic stieg nur um 4 Prozent. Das Dashboard zeigt eine Gesamtsumme, aber keine Modell-, Prompt-, Mandanten- oder Ergebnisdimension.
Anforderungen
- Was ist der erste belastbare Schritt?
- Bewerte Ursache, wirksame Grenze und den Preis der tragfähigen Maßnahme getrennt.
Schritte
- Plausibler Fehlweg: Sofort überall auf das kleinste Modell wechseln. Das senkt möglicherweise Qualität und erklärt nicht, welcher Pfad den Anstieg verursacht. Es ist eine irreversible globale Reaktion auf unzureichende Messung.
- Tragfähiger Ansatz: Kosten und Nutzungsvolumen pro Request mit Modell, Version, Mandant und Ergebnisstatus korrelieren. Richtig. Erst die Attribution trennt etwa längere Ausgaben, neue Prompts, Retries oder einzelne Mandanten als Ursachen.
- Plausibler Fehlweg: Die Kosten auf alle Teams gleichmäßig umlegen. Umlage schafft kein operatives Signal und kann den verursachenden Pfad sogar unsichtbar machen.
- Plausibler Fehlweg: Nur die Provider-Rechnung mit dem Vormonat vergleichen. Die Rechnung bestätigt den Anstieg, verbindet ihn aber nicht mit Ausführung, Produktfunktion oder Qualität.
Merksatz: Kosten werden erst steuerbar, wenn sie der Ausführung und ihrem Wertkontext zugeordnet sind. Aggregierte Summen taugen für Buchhaltung, nicht für Ursachenentscheidungen. + Optimierungen treffen den verursachenden Pfad. − Zusatztelemetrie braucht Datenschutz- und Kardinalitätsdisziplin.
Vor der Optimierung: Attribution
Kostensteuerung beginnt mit belastbarer Attribution. Erfasse mindestens Modell- und Prompt-Version, Ein- und Ausgabevolumen, Anfrageklasse, Mandant und Ergebnis. Ohne diese Dimensionen ist eine Gesamtrechnung kein Steuerinstrument, sondern nur eine Rechnung.
- Signal
- Entscheidung
- Kosten pro erfolgreicher Aufgabe
- Budget und Routing
- Queue-Alter
- Warten, priorisieren oder ablehnen
- Quota-Fehler und Retry-Rate
- Backoff und Admission Control
- Ausgabevolumen
- Antwortvertrag oder Modellwahl
Betriebsprobe: LOAD-PROFILE
Szenario
Nach einer Produktänderung dürfen Nutzer Dokumente anhängen. Die Anfragerate bleibt stabil bei 200 pro Minute, die Fehlerrate ebenfalls. Trotzdem steigen Latenz und Kosten deutlich, und der Dienst erreicht abends erstmals seine Nebenläufigkeitsgrenze. Das Kapazitätsmodell des Teams rechnet ausschließlich in Anfragen pro Minute.
Anforderungen
- Welche Anpassung am Kapazitätsmodell ist nötig?
- Bewerte Ursache, wirksame Grenze und den Preis der tragfähigen Maßnahme getrennt.
Schritte
- Tragfähiger Ansatz: Die Planungsgröße auf verarbeitete Arbeit umstellen — Ein- und Ausgabemenge sowie Belegungsdauer pro Anfrage — und die Anfragerate nur noch als Nachfragegröße führen. Richtig. Die Zahl der Anfragen ist gleich geblieben, ihr Gewicht nicht. Ein Modell, das nur zählt, kann diese Verschiebung strukturell nicht abbilden.
- Plausibler Fehlweg: Das Modell beibehalten und den Grenzwert für Anfragen pro Minute nach unten korrigieren — als globales Kapazitätslimit für alle Arbeitsklassen und Mandanten festgeschrieben. Das kalibriert auf den aktuellen Anhangs-Anteil. Ändert sich dieser Anteil — und er wird sich ändern —, ist der neue Grenzwert genauso falsch wie der alte.
- Plausibler Fehlweg: Anhänge auf eine maximale Größe begrenzen, dann bleibt die Anfrage wieder vergleichbar. Eine Obergrenze ist sinnvoll, macht Anfragen aber nicht gleich schwer: Zwischen null und der Obergrenze bleibt eine große Spanne, und das Modell bliebe blind für sie.
- Plausibler Fehlweg: Anfragen mit Anhang als eigene Arbeitsklasse zählen und dafür ein zweites Kontingent führen. Ein sinnvoller Zwischenschritt, aber er löst das Grundproblem nur einmal: Die nächste Funktion, die das Gewicht pro Anfrage verändert, erzwingt wieder eine neue Klasse — die Planungsgröße bleibt die falsche.
Merksatz: Miss Kapazität in der Einheit, die die Ressource tatsächlich verbraucht. Sobald der Aufwand pro Anfrage variabel ist, ist die Anfragezahl eine Nachfragemetrik und keine Kapazitätsmetrik. + Das Modell bleibt gültig, wenn sich das Produkt ändert, und erklärt Kosten- wie Latenzverschiebungen. − Es braucht Telemetrie über Ein- und Ausgabemengen pro Anfrage und ist schwerer zu kommunizieren als eine einzelne, anschauliche Anfragerate.
Admission Control schützt die nützliche Arbeit
Wenn Nachfrage über der sicheren Kapazität liegt, ist kontrolliertes Ablehnen oder Verzögern besser als alle Anfragen gleichzeitig scheitern zu lassen. Prioritäten müssen eine Produktentscheidung abbilden: etwa interaktive, zahlende oder sicherheitskritische Arbeit vor asynchronen Komfortaufgaben.
Betriebsprobe: LOADTEST-FIDELITY
Szenario
Ein Lasttest bescheinigt eurem Dienst 900 Anfragen pro Minute ohne Latenzanstieg. Am ersten Produktionstag bricht er bei 300 ein. Der Test schickte denselben kurzen Prompt aus einer Datei, mit fester Ausgabelänge von 64 Tokens und ohne den Retrieval-Schritt, der in Produktion vorgeschaltet ist.
Anforderungen
- Welche Korrektur am Testaufbau ist die wichtigste?
- Bewerte Ursache, wirksame Grenze und den Preis der tragfähigen Maßnahme getrennt.
Schritte
- Tragfähiger Ansatz: Eingaben und Ausgabelängen aus der realen Produktionsverteilung ziehen — inklusive des langen Schwanzes — und die vollständige Kette mit Retrieval und Nachverarbeitung testen. Richtig. Der gemessene Wert galt für eine Arbeitseinheit, die es in Produktion nicht gibt: kurz, gleichförmig, ohne vorgelagerte Stufen. Erst die reale Verteilung und die vollständige Kette machen die Zahl übertragbar.
- Plausibler Fehlweg: Den Test mit höherer Zielrate wiederholen, um mehr Sicherheitsabstand zu gewinnen — als globales Kapazitätslimit für alle Arbeitsklassen und Mandanten festgeschrieben und unabhängig von Tokenmenge, Priorität und beobachteter Sättigung in jedes Lastprofil übernommen. Ein falsches Lastprofil wird durch mehr Last nicht richtiger. Du bekämst eine noch höhere, ebenso unbrauchbare Zahl.
- Plausibler Fehlweg: Den Test in der Produktionsumgebung statt in der Testumgebung fahren. Die Umgebungstreue ist ein realer Faktor, aber nicht die Hauptursache: Auch in Produktion würde ein gleichförmiger 64-Token-Prompt den Speicherbedarf und den Tail massiv unterschätzen.
- Plausibler Fehlweg: Statt eines Lasttests die Produktionsmetriken über mehrere Wochen beobachten und daraus die Grenze ableiten. Beobachtung zeigt nur den Bereich, in dem der Dienst bisher lief. Wo das Knie liegt und wie der Dienst versagt, erfährst du so erst im Vorfall.
Merksatz: Ein Lasttest misst die Kapazität für genau die Arbeitseinheit, die er erzeugt. Weicht deren Verteilung von der Produktion ab, ist das Ergebnis keine konservative Schätzung, sondern eine falsche. + Die Zahl wird auf Produktion übertragbar, und der Tail wird sichtbar. − Realistische Profile brauchen aufbereitete, datenschutzkonforme Produktionsdaten und machen Tests langsamer, teurer und schlechter reproduzierbar.
Budget ist eine Policy, kein Dashboard
Caching, kleinere Modelle und knappe Antwortformate sind mögliche Hebel. Sie sind keine universelle Antwort: Jeder Hebel braucht ein Qualitäts- und Fairness-Gate.
Betriebsprobe: SATURATION-SIGNAL
Szenario
Ihr sucht ein Signal, das eine drohende Überlast des Inferenz-Dienstes früh genug meldet, um zu reagieren. Zur Auswahl stehen mehrere Metriken. Die Beschleuniger-Auslastung liegt im Normalbetrieb ohnehin dauerhaft über 90 %, weil der Server batcht.
Anforderungen
- Welches Signal wählst du als primären Frühindikator?
- Bewerte Ursache, wirksame Grenze und den Preis der tragfähigen Maßnahme getrennt.
Schritte
- Tragfähiger Ansatz: Das Alter der wartenden Anfragen in der Queue und den Anteil, der die Frist bereits überschritten hat. Richtig. Wartezeit entsteht, sobald die Nachfrage die Bedienrate übersteigt — also bevor Fehler auftreten. Das Signal ist unabhängig davon, wie die Auslastung zustande kommt, und direkt an der Nutzerwirkung.
- Plausibler Fehlweg: Die Beschleuniger-Auslastung mit einem Schwellwert bei 95 %. Bei einem batchenden Server ist hohe Auslastung der Normalzustand und sagt nichts über Sättigung. Der Schwellwert würde entweder dauernd oder nie auslösen.
- Plausibler Fehlweg: Die Fehlerrate der Anfragen. Fehler sind ein spätes Signal: Wenn sie steigen, ist die Sättigung längst da und Nutzer sind bereits betroffen. Als Bestätigung nützlich, als Frühindikator zu spät.
- Plausibler Fehlweg: Die durchschnittliche Antwortzeit über alle Anfragen. Der Mittelwert reagiert träge und mischt kurze mit langen Generierungen. Eine Verschiebung im Schwanz — genau das Erste, was passiert — verschwindet darin fast vollständig.
Merksatz: Sättigung zeigt sich zuerst als Warten, nicht als Auslastung oder Fehler. Metriken über die Nachfrage, die noch nicht bedient wurde, laufen der Wirkung voraus — Ergebnismetriken laufen ihr hinterher. + Frühe, eindeutige Warnung mit direktem Bezug zur Nutzerwirkung. − Das Signal setzt eine explizite Queue mit Zeitstempeln und Fristen voraus; ohne diese Struktur ist es gar nicht messbar und muss erst gebaut werden.
Was die Checks prüfen
- Welche Telemetrie eine Kostenanomalie erklärbar macht
- Wann eine Queue besser ist als sofortige Retries
- Wie Priorisierung und Load Shedding den Dienst stabilisieren
ai-foundations. Dieses Modul behandelt die laufende Durchsetzung unter realer Nachfrage.Betriebsprobe: CAPACITY-HEADROOM
Szenario
Ihr betreibt eine feste Beschleuniger-Flotte in zwei Ausfalldomänen. Die gemessene Betriebsgrenze liegt bei 100 Einheiten Arbeit, die Tagesspitze bei 70. Nachschub an Hardware hat eine Vorlaufzeit von mehreren Wochen. Das Wachstum liegt bei rund 8 % pro Monat. Ein Vorschlag lautet, die Flotte zu verkleinern, weil im Mittel nur 45 Einheiten anfallen.
Anforderungen
- Wie argumentierst du zur Dimensionierung?
- Bewerte Ursache, wirksame Grenze und den Preis der tragfähigen Maßnahme getrennt.
Schritte
- Tragfähiger Ansatz: Die Reserve aus den konkreten Fällen ableiten — Tagesspitze, Ausfall einer Ausfalldomäne und Wachstum über die Beschaffungsvorlaufzeit — statt aus dem Mittelwert. Richtig. Kapazität muss den schlechtesten planbaren Moment tragen, nicht den durchschnittlichen. Bei wochenlanger Vorlaufzeit muss die Reserve zusätzlich das Wachstum bis zur nächsten Lieferung überbrücken.
- Plausibler Fehlweg: Auf die Tagesspitze von 70 dimensionieren, das ist der real gemessene Bedarf — als globales Kapazitätslimit für alle Arbeitsklassen und Mandanten festgeschrieben und unabhängig von Tokenmenge, Priorität und beobachteter Sättigung in jedes Lastprofil übernommen. Damit fehlt jede Reserve für den Ausfall einer Ausfalldomäne und für Wachstum. Der erste Domänenausfall zur Spitzenzeit wird zum Nutzerausfall.
- Plausibler Fehlweg: Auf den Mittelwert dimensionieren und Spitzen über Autoscaling abfangen. Autoscaling setzt voraus, dass Kapazität kurzfristig verfügbar ist. Bei wochenlanger Hardware-Vorlaufzeit gibt es nichts, worauf skaliert werden könnte — die Annahme trägt hier nicht.
- Plausibler Fehlweg: Auf die Spitze plus pauschal 50 % dimensionieren, das ist die übliche Faustregel. Ein pauschaler Aufschlag kann zufällig passen, ist aber nicht begründet: Er hängt weder an der Ausfalldomänen-Struktur noch an der Vorlaufzeit und ist damit weder verteidigbar noch anpassbar, wenn sich einer dieser Faktoren ändert.
Merksatz: Reserve ist die Antwort auf benannte Risiken mal der Zeit, die du zum Nachlegen brauchst. Wer sie als Prozentsatz auf einen Durchschnitt setzt, kann nicht sagen, welchen Fall er damit abdeckt. + Die Dimensionierung ist gegenüber Finanzverantwortlichen begründbar und überlebt einen Domänenausfall zur Spitzenzeit. − Sie kostet dauerhaft ungenutzte Kapazität, die im Normalbetrieb wie Verschwendung aussieht und regelmäßig verteidigt werden muss.
Warum „Anfragen pro Sekunde“ hier zu wenig ist
Bei einem klassischen Dienst kostet jede Anfrage ungefähr gleich viel. Bei einem generativen Dienst schwankt der Aufwand pro Anfrage um Größenordnungen: Eingabelänge, Ausgabelänge und die Zahl der Zwischenschritte bestimmen, wie lange ein Platz belegt wird. Zwei Dienste mit derselben Anfragerate können völlig unterschiedliche Kapazität brauchen.
Die tragfähigere Größe ist deshalb die belegte Arbeit: gleichzeitig laufende Sequenzen mal ihrer Dauer, beziehungsweise verarbeitete Ein- und Ausgabemenge pro Zeit. Anfragerate bleibt als Nachfragegröße nützlich, ist aber allein keine Kapazitätsaussage.
Betriebsprobe: ADMISSION-CONTROL
Szenario
Ein Provider drosselt euch bei 1.000 Requests pro Minute. Um 09:00 treffen 1.400 Anfragen ein: interaktive Incident-Zusammenfassungen und nicht dringliche Nachtberichte. Wiederholte Sofort-Retries verlängern die Queue auf 14 Minuten.
Anforderungen
- Welche Laufzeitpolicy schützt den Dienst am besten?
- Bewerte Ursache, wirksame Grenze und den Preis der tragfähigen Maßnahme getrennt.
Schritte
- Plausibler Fehlweg: Alle Anfragen unbegrenzt retrien, bis der Provider wieder annimmt — als globales Kapazitätslimit für alle Arbeitsklassen und Mandanten festgeschrieben. Retries unter Sättigung erzeugen zusätzliche Last und binden Ressourcen. Sie priorisieren nicht und verlängern die Nutzerwartezeit.
- Tragfähiger Ansatz: Interaktive Arbeit begrenzt bevorzugen, asynchrone Arbeit queueen und Überlast mit Backoff sowie klarer Degradation behandeln. Richtig. Admission Control macht den Konflikt sichtbar, schützt die wichtigere Arbeit und verhindert eine Retry-Kaskade.
- Plausibler Fehlweg: Nachtberichte löschen, sobald die Quote erreicht ist. Das schützt zwar Kapazität, verliert aber unnötig Arbeit. Eine haltbare Queue ist für nicht dringliche Aufgaben meist die angemessene Degradation.
- Plausibler Fehlweg: Die Quote durch parallele API-Schlüssel umgehen. Das umgeht keine echte Kapazitätsgrenze und verschlechtert Governance sowie Provider-Risiko.
Merksatz: Bei Überlast stabilisiert ein System zuerst die zugelassene Arbeit. Priorisierung, Fristen, Backoff und kontrolliertes Shedding sind gemeinsame Teile einer Kapazitätspolitik. + Kritische Interaktion bleibt nutzbar und die Queue begrenzt. − Niedrig priorisierte Arbeit wird verzögert und braucht transparente Produktsemantik.
Das Lastprofil kommt aus der Produktion
Ein brauchbares Lastprofil beschreibt nicht den Durchschnitt, sondern die Verteilung: wie lang sind Eingaben und Ausgaben typischerweise, wie schwer ist der Schwanz, wie mischen sich Arbeitsklassen, wie sieht die Tagesform aus. Genau diese Verteilung entscheidet über Speicherbedarf, Nebenläufigkeit und Tail-Latenz.
- Eingabelängen-Verteilung
- Treibt Vorlaufzeit und Speicher pro Sequenz.
- Ausgabelängen-Verteilung
- Treibt Belegungsdauer, Kosten und Tail.
- Klassenmischung
- Bestimmt, welche Konfiguration überhaupt passt.
- Zeitliches Muster
- Bestimmt Spitzenfaktor und Vorwärmbedarf.
Sättigung erkennen: die Knie-Kurve
Auslastungsprozente sind bei Beschleunigern trügerisch: Ein Wert nahe hundert kann heißen, dass produktiv gearbeitet wird, oder dass auf Speicher gewartet wird. Verlässlicher ist der Blick auf das Verhalten unter steigender Last: Bis zu einem Punkt steigt der Durchsatz und die Latenz bleibt nahezu flach; danach steigt die Latenz steil, während der Durchsatz kaum noch zulegt. Dieses Knie ist die praktische Kapazitätsgrenze.
Ergänzend sind Warteschlangen-Signale die ehrlichsten Frühindikatoren: wachsendes Queue-Alter und steigender Anteil abgelaufener Einträge zeigen Sättigung, bevor die Fehlerrate es tut.
Reserve: wofür genau
Reserve ist kein pauschaler Aufschlag, sondern die Summe konkreter Fälle: die übliche Tagesspitze, der Ausfall einer Ausfalldomäne, die Zeit bis neue Kapazität bereitsteht, und das erwartete Wachstum bis zur nächsten Beschaffung. Bei Beschleunigern ist der letzte Punkt besonders wichtig, weil Nachschub selten sofort verfügbar ist.
Bei einer fremden API tritt an die Stelle der Hardware die Quote. Sie ist eine harte Grenze, die du nicht kurzfristig erhöhen kannst — Reserve heißt hier: Abstand zur Quote halten, Erhöhungen frühzeitig beantragen und einen Degradationspfad haben, wenn die Nachfrage sie doch erreicht.
Lasttests, die etwas beweisen
Ein Lasttest ist nur so gut wie seine Treue zur Wirklichkeit. Drei Fehler entwerten LLM-Lasttests regelmäßig:
- Gleichförmige Eingaben: identische kurze Prompts erzeugen unrealistisch niedrigen Speicherbedarf und im Zweifel Cache-Treffer, die es in Produktion nicht gäbe.
- Feste Ausgabelängen: sie glätten genau den Schwanz, der in Produktion die Tail-Latenz erzeugt.
- Nur der Modellaufruf: Retrieval, Guardrails und Nachverarbeitung fehlen, obwohl sie Kapazität binden und mitsättigen.
Ebenso wichtig ist die Abbruchbedingung: Ein Lasttest, der bis zum Zusammenbruch fährt, liefert die interessantere Information — nämlich wie der Dienst versagt: ob er sauber ablehnt oder alle Anfragen gemeinsam verlangsamt.
Was die Checks prüfen
- Ob dein Lastprofil die reale Verteilung abbildet
- Woran du Sättigung erkennst, bevor Fehler auftreten
- Wie du Reserve gegen Beschaffungszeit bemisst
- Welche Testfehler ein beruhigendes, aber falsches Ergebnis erzeugen
Jetzt anwenden
Diesen Stoff gibt es als Modul mit bewerteten Entscheidungs-Checks — dieselbe Einführung, danach die Übungen.
Zum Modul →