Datadog sagt, 5 Prozent der KI-Anfragen scheitern. Die, die mir Sorgen machten, kamen mit 200 zurück.

Datadogs State-of-AI-Engineering-Report legt eine Zahl auf etwas, das die meisten Teams nur spüren: rund 5 Prozent aller Modellanfragen scheitern in Produktion, und knapp 60 Prozent dieser Fehler kommen aus Kapazitätsgrenzen. Der Schluss lautet, nicht die Intelligenz der Modelle sei die Hürde, sondern die betriebliche Komplexität.

Ich hatte kurz davor einen Nachmittag damit verbracht, einen kostenlosen Inferenz-Endpunkt zu vermessen, und bin zu meinen eigenen Zahlen zurück, um den Befund zu bestätigen.

Gescheitert war nichts. Keine einzige Anfrage.

Null Fehler, und größtenteils unbrauchbare Antworten

Der Endpunkt war Hetzners experimentelle Inferenz-API, vier offene Modelle, kostenlos, ohne SLA. Über den gesamten Durchlauf habe ich 17.920 Ausgabe-Token gegen ein Limit von 200.000 pro Minute verbraucht. Nichts kam als 429 zurück. Nichts lief in einen Fehler. Gemessen an der Kennzahl des Reports war das ein makelloser Lauf.

Er war auch fast wertlos, und zwar so. Bei einem Budget von 512 Token erzeugten drei der vier Modelle exakt 512 Completion-Token und null sichtbare Wörter:

Qwen 3.6       512 Token    0 Wörter
DeepSeek V4    512 Token    0 Wörter
GLM 5.2        512 Token    0 Wörter
Kimi K2.7      512 Token    eine Antwort

Sie haben das gesamte Budget mit Nachdenken verbraucht und wurden abgeschnitten, bevor die Antwort begann. Status 200. Token abgerechnet. Latenz aufgezeichnet. Für den Nutzer nichts.

Eine Fehlerquote kann das nicht sehen. Die Anfrage war auf jeder Achse erfolgreich, die eine Überwachung beobachtet, und das Einzige, was an ihr falsch war, trägt kein Statuscode.

Was die Quote sonst übersieht

Wer die eigenen Messungen gegen die Kategorien des Reports liest, findet drei weitere Muster, die eine Prozentzahl gescheiterter Anfragen nicht sichtbar macht.

• Latenz, die keine Zahl ist, sondern eine Spanne. Die Zeit bis zum ersten Token lag bei GLM 5.2 über fünf Läufe zwischen 11 und 173 Sekunden. Ein Median von 26,8 Sekunden ist formal richtig und betrieblich bedeutungslos: der p50 sagt nichts über den Lauf, wegen dem jemand den Tab geschlossen hat.
• Generierungen, die von selbst aufhören. Auf 4.096 Token angehoben, hörte jedes Modell irgendwo zwischen 1.046 und 2.680 Token von allein auf. Das größere Budget kaufte eine langsamere Anfrage und sonst nichts. Beide Budgets sind erfolgreich, aber nur eines gibt sinnvoll aus.
• Parallelität, die einem Modell hilft und dem anderen schadet. Acht gleichzeitige 256-Token-Anfragen ließen Qwen 3.6 bei rund 36 Token pro Sekunde je Anfrage, gegenüber 34 bei einer einzelnen. Dieselbe Behandlung drückte DeepSeek V4 auf 15. Gleiche Infrastruktur, gleiche Last, gegenteiliges Verhalten, und in keiner Spalte ein Fehler.

Wo der Report recht hat, aus zehn Anfragen

Das Kapazitätsmuster, das der Report beschreibt, gibt es, und ich bin ihm an anderer Stelle frontal begegnet.

Ein Vorschaumodell lief etwa eine Woche lang unter Tarnnamen auf OpenRouter, kostenlos solange es dauerte, und während ich damit etwas gebaut habe, liefen 4 von 10 Anfragen in einen Timeout.

Das ist genau der Fehler, den Datadog zählt, und es ist zugleich eine Zahl, mit der ich vorsichtig sein will. Zehn Anfragen sind eine winzige Stichprobe, und ich habe kein Experiment gefahren, ich habe gearbeitet. Das 95-Prozent-Intervall um 4 von 10 reicht von 17 bis 69 Prozent. Anders gesagt: es belegt, dass das Phänomen da war, und fast nichts über seine Größe. Für einen Vergleich mit den 5 Prozent des Reports trägt es nicht.

Der Mechanismus steht trotzdem nicht in Frage, und er ist der gewöhnliche: eine kostenlose Vorschau unter plötzlicher Aufmerksamkeit hat keine Kapazitätsreserve, und was zuerst nachgibt, ist der Rand der Latenzverteilung.

Was ich stattdessen messen würde

Eine Fehlerquote ist eine gute Überschrift und eine schlechte Arbeitsgrundlage. Vier Größen, die ich danebenstellen würde, und die ich alle nur habe, weil ich gemessen und nicht überwacht habe:

• Leerantwort-Quote. Welcher Anteil der erfolgreichen Antworten enthält nichts Brauchbares. An jenem Endpunkt waren es beim Standardbudget drei von vier Modellen, was weit mehr sagt als die null Prozent Fehlerquote daneben.
• Budget-Effizienz. Verbrauchte Completion-Token gegen erzeugte sichtbare Wörter. Das ist die Zahl, die verrät, dass ein Reasoning-Modell auf deine Rechnung nachdenkt.
• Randlatenz, als Spanne angegeben. Kein Median. Der Abstand zwischen 11 und 173 Sekunden ist die Produktentscheidung, und der Median verdeckt ihn.
• Verhalten unter Parallelität, je Modell. Je Modell, nicht je Anbieter, denn zwei Modelle auf derselben Infrastruktur verhielten sich gegenteilig.

Next

Nichts davon widerspricht dem Report. Betriebliche Komplexität ist tatsächlich die Hürde, und ich vermute, die 5 Prozent sind für die Grundgesamtheit, aus der sie stammen, gut belegt. Mein Einwand ist enger: die Kennzahl stammt aus der Schicht, in der Anfragen entweder durchgehen oder nicht, und ein wachsender Teil dessen, was bei Inferenz schiefgeht, geht durch.

Zwei der vier gemessenen Modelle wurden inzwischen von diesem Endpunkt genommen, was stillschweigend das Gegenbeispiel und die volatilste Zahl des Textes entfernt. Auch das ist eine Lehre über das Vermessen kostenloser Kapazität.

Die Messung darunter ist der Hetzner-Lauf, bei dem die Modelle ihre freie Kapazität mit Nachdenken verbraucht haben. Drei der vier wurden inzwischen von diesem Endpunkt genommen, die Zahlen sind also eine Momentaufnahme, und niemand kann sie reproduzieren, ich eingeschlossen.

Wenn du Inferenz in Produktion betreibst, ist die Zahl, um die ich dich bitten würde, nicht deine Fehlerquote. Es ist der Anteil deiner erfolgreichen Antworten, den ein Nutzer eine Antwort genannt hätte. Wer diese beiden nie getrennt hat, weiß noch nicht, welche von beiden sein Problem ist.