API-Metriken für feinabgestimmte Modelle

Ein feinabgestimmtes Modell ist nur dann behaltenswert, wenn es unter Live-API-Traffic schnell genug, stabil genug und günstig genug bleibt.

Wenn ich vom ersten Tag an nur wenige Dinge tracken würde, würde ich Latenz, Durchsatz, Fehlerrate, Timeout-Rate, Erfolgsrate, Fallback-Rate, Token-Nutzung, Kosten pro Anfrage, Queue-Tiefe und Task-Abschlussrate beobachten. Warum? Weil ein Modell 200 OK zurückgeben und die Aufgabe trotzdem verfehlen, zusätzliche Tokens verbrennen oder Nutzer zum Abbruch treiben kann.

Hier die Kurzfassung:

• Latenz: Beobachten Sie TTFT und p95/p99, nicht nur Durchschnittswerte.
• Durchsatz: Testen Sie RPS/TPS unter Produktions-Nebenläufigkeit, nicht eine Anfrage nach der anderen.
• Zuverlässigkeit: Trennen Sie 4xx, 5xx, 429, 503 und 504, damit Fehlermuster leicht zu erkennen sind.
• Timeouts: Längere Ausgaben treiben feinabgestimmte Modelle oft über die Anfrage-Deadlines hinaus.
• Erfolg vs. Fallback: Eine funktionierende API-Antwort ist nicht dasselbe wie eine nutzbare Antwort.
• Tokens: Tracken Sie Input-, Output- und Gesamt-Tokens aus dem API-Feld usage.
• Kosten: Messen Sie Kosten pro Anfrage, Kosten pro 1.000 Tokens und p95-Kosten, nicht nur die monatlichen Ausgaben.
• Kapazität: Queue-Tiefe und KV-Cache-Druck zeigen Probleme oft, bevor GPU-Diagramme es tun.
• Nutzerergebnis: Beobachten Sie Task-Abschlussrate, menschliche Prüfung und Abbrüche.
• Rollback-Risiko: Wenn p99 spitzt, 5xx + Timeouts über 5 % steigen oder die Win-Rate gegenüber dem Basismodell unter 50 %–55 % fällt, würde ich das als ernste Warnung behandeln.

Feinabstimmung mit benutzerdefinierten Compute-Metriken

Schnellvergleich

Fazit: Ich würde ein feinabgestimmtes Modell nicht allein anhand von Offline-Scores beurteilen. Ich würde es in Produktion mit dem Basismodell vergleichen, Rollback-Grenzen vor dem Start festlegen und ein Dashboard führen, das Geschwindigkeit, Fehler, Ausgaben und Ergebnis in einer Ansicht zeigt.

Warum API-Metriken nach der Feinabstimmung noch wichtiger sind

Feinabstimmung verändert, wie sich ein Modell in Produktion verhält. Unter Live-Traffic können sich Latenz, Token-Nutzung und Fehlermuster alle verschieben. In manchen Fällen senkt Feinabstimmung die Input-Tokens, indem lange Prompts ersetzt werden. In anderen treibt sie die Output-Kosten hoch, indem sie Completions länger macht ^[6]. Deshalb bedeuten Offline-Erfolge für sich allein nicht viel. Sie müssen sie an Live-API-Metriken prüfen.

Die Lücke zwischen Offline-Tests und Produktion ist real. Forschung zeigt, dass ein feinabgestimmtes Modell 12 Punkte auf einem aufgabenspezifischen Holdout-Set gewinnen und trotzdem 6 Punkte auf allgemeinen Reasoning-Benchmarks wie GSM8K verlieren kann ^[2]. Das ist kein seltener Sonderfall. Es ist ein bekanntes Fehlermuster namens katastrophales Vergessen, bei dem das Verbessern einer Fähigkeit andere schwächen kann.

Die Lektion hier ist ziemlich einfach: Ein Fine-Tune kann der Aufgabe helfen, die Ihnen wichtig ist, und trotzdem die Leistung anderswo verschlechtern. Und diese Art von Benchmark-Drift zeigt sich nicht klar, wenn Sie nur auf Offline-Scores starren. Sie sehen sie, wenn Produktionssignale neben Eval-Ergebnissen stehen.

Qualitäts-Drift ist nicht das einzige Problem. Domänenspezifische Feinabstimmung kann auch das Ablehnungsverhalten des Basismodells schwächen, was das Modell anfälliger für Jailbreaks und Prompt Injection macht ^[2]. In Produktion zeigt sich so ein Ausrutscher schnell: Die Erfolgsrate fällt, die Fallback-Rate steigt und Fehlerspitzen tauchen auf Weisen auf, die ein statisches Test-Set nicht erfasst. Diese Änderungen zeigen sich in den API-Metriken, die folgen.

1. End-to-End-Latenz

End-to-End-Latenz ist die Gesamtzeit von dem Moment, in dem ein Client eine Anfrage sendet, bis die vollständige Antwort ankommt. Das umfasst Netzwerkzeit, Queueing, Inferenz und Antwortauslieferung ^[7][9]. Für feinabgestimmte Endpunkte ist dies eines der ersten Produktionssignale, die es zu beobachten gilt.

Eine einfache Betrachtungsweise der Latenz ist: total time ≈ TTFT + output_tokens × TPOT ^[9].

TTFT misst, wie schnell das erste Token erscheint, was für Streaming-Apps sehr wichtig ist ^[9][10]. TPOT ist die durchschnittliche Zeit zwischen generierten Tokens ^[9]. Diese Aufteilung hilft Ihnen zu sehen, was sich nach einem Fine-Tune geändert hat. Ist die Antwortgeschwindigkeit gesunken? Hat das Streaming später begonnen? Ist die Token-Generierung langsamer geworden?

Feinabgestimmte Modelle laufen oft 10 %–20 % langsamer als Basismodelle. Wenn die Latenz um mehr als 50 % springt, deutet das meist auf nicht zusammengeführte LoRA-Gewichte, fehlende Quantisierung oder zu lang gewordene Ausgaben hin ^[7][8]. Der nützliche Vergleich ist der gegen das Basismodell. Der sagt Ihnen, ob das Fine-Tune die Aufgabenqualität genug verbessert hat, um den Geschwindigkeitsverlust zu rechtfertigen.

Tail-Latenz ist das, was Nutzer bei langsamen Durchläufen, Retries und Queue-Spitzen bemerken. Eine p95-TTFT über 3–4 Sekunden erzeugt eine deutliche Verlangsamung für Nutzer ^[3]. Im interaktiven Chat fühlt sich eine p95-TTFT unter 500 ms sofort an. Sobald sie über 3–4 Sekunden hinausgeht, fällt das Erlebnis schnell ab ^[12]. Setzen Sie SLAs also nicht allein auf den Mittelwert. Setzen Sie sie auf die Tail-Latenz.

Hohe Tail-Latenz deutet meist auf Probleme mit der Queue-Tiefe oder Cold-Start-Overhead hin, nicht auf rohe GPU-Geschwindigkeit ^[10]. Deshalb zählt Perzentil-Latenz mehr als die durchschnittliche Antwortzeit für sich allein.

Bevor Sie messen, führen Sie 2–3 Aufwärm-Anfragen durch. Die Latenz des ersten Aufrufs ist oft 30 %–50 % höher ^[8].

2. p50-, p90- und p99-Latenz

Durchschnittliche Latenz kann Dinge besser aussehen lassen, als sie sind. Sie sehen vielleicht eine mittlere Antwortzeit von 1,2 Sekunden und nehmen an, dass der Endpunkt gut läuft, während die p99 bei 9 Sekunden liegt ^[15]. Das bedeutet, 1 % der Nutzer wartet immer noch fast 10 Sekunden, obwohl das Dashboard sagt, alles sehe normal aus. Perzentile helfen Ihnen zu sehen, ob das Fine-Tune den meisten Anfragen geholfen oder die Verlangsamung nur in den Tail geschoben hat.

Hier, was Ihnen jedes Perzentil über Ihren feinabgestimmten Endpunkt sagt:

Nutzen Sie diese Perzentile, um das Basismodell und das feinabgestimmte Modell unter demselben Traffic-Mix zu vergleichen.

Nach der Feinabstimmung können sich p50 und p99 in unterschiedliche Richtungen bewegen. Wenn Ihr Fine-Tune zu kürzeren, strukturierteren Ausgaben führt, kann p50 sinken, weil typische Anfragen schneller fertig werden. Aber p99 kann steigen, wenn das Modell manchmal wortreicher wird ^[7][15]. Diese Aufspaltung ist wichtig. Wenn p99 steigt, während p50 flach bleibt, ist das das Signal, tiefer zu graben – nicht die durchschnittliche Antwortzeit.

p99 ist Ihre Rollback-Risiko-Kennzahl. Setzen Sie Regressionsgates in Ihrer CI/CD-Pipeline rund um p99-Schwellen ^[15]. Wenn ein Modell-Update die Tail-Latenz über Ihr Limit treibt, sollte der Build fehlschlagen, bevor er in Produktion geht.

Latenz sagt Ihnen, wie langsam sich Anfragen anfühlen. Als Nächstes schauen Sie, wie viele Anfragen der Endpunkt bewältigen kann.

3. Durchsatz und Anfragen pro Sekunde (RPS)

Latenz sagt Ihnen, wie eine Anfrage performt. Durchsatz sagt Ihnen, wie viel Arbeit der Endpunkt über die Zeit bewältigen kann.

Die wichtigsten Zahlen zum Tracken sind Anfragen pro Sekunde (RPS), Tokens pro Sekunde (TPS) und Tokens pro Minute (TPM) ^[17][18]. Zusammen zeigen sie, ob Ihr feinabgestimmter Endpunkt mit tatsächlichem Traffic mithalten kann, besonders bei Nutzung einer einheitlichen LLM-API zur Verwaltung mehrerer Anbieter.

Hier der Haken: Ein Modell kann in einem einmaligen Test schnell aussehen und trotzdem auseinanderfallen, sobald sich Traffic staut. Unter Nebenläufigkeit können Sie einen Durchsatzkollaps erleben, bei dem das Hinzufügen weiterer paralleler Anfragen die Ausgabe nicht mehr erhöht und die Latenz hart hochschießt. Dieser Wendepunkt – an dem der Durchsatz aufhört zu skalieren – ist Ihre Kapazitätsobergrenze ^[15].

Einer der größten Faktoren hinter RPS ist die Ausgabelänge. Wenn ein Fine-Tune anfängt, längere Antworten zu geben, sinkt der Durchsatz und die Kosten steigen, selbst wenn die Antworten besser sind ^[6][8].

Es hilft auch, den Goodput zu beobachten, nicht nur den rohen Durchsatz. Goodput ist der Anteil der Anfragen, die weiterhin die Latenz-SLOs erfüllen. Wenn der Goodput niedrig ist, kann der Endpunkt zwar beschäftigt sein, aber trotzdem das Ziel verfehlen. Diese Art von Lücke deutet oft auf schwaches Batching oder Serversättigung hin ^[17].

Wenn Sie also RPS und TPS benchmarken, testen Sie bei Produktions-Nebenläufigkeit, nicht mit Einzel-Anfrage-Läufen. Grenzen, die an Rate-Caps, Queue-Tiefe und VRAM gebunden sind, bleiben oft verborgen, bis das System unter Last steht ^[7][9][15]. Wenn der Endpunkt dort die Kapazität halten kann, ist es an der Zeit zu prüfen, ob diese Anfragen erfolgreich sind.

4. Fehlerrate nach HTTP-Statuscode

Sobald die Last unter Kontrolle ist, ist das Nächste, was zu beobachten ist, die Zuverlässigkeit: wie oft der Endpunkt fehlschlägt. Die Fehlerrate sagt Ihnen, ob Anfragen so abschließen, wie sie sollten. In der Praxis teilt sich das in zwei Kategorien auf: clientseitige Fehler und serverseitige Fehler.

Ein Anstieg von 4xx-Fehlern deutet oft auf Prompt- oder Schema-Diskrepanzen oder auf durch das Fine-Tune eingeführte Kontextfenster-Probleme hin. Ein Anstieg von 503- oder 504-Fehlern deutet meist auf Serverbelastung oder Timeout-Druck hin. Wenn 5xx-Fehler ansteigen, behandeln Sie das als ernstes Rollback-Risiko.

Es gibt hier auch einen finanziellen Aspekt. Fehlgeschlagene Anfragen verbrauchen weiterhin Tokens. Um verschwendete Ausgaben zu tracken, addieren Sie die Token-Kosten fehlgeschlagener Anfragen, besonders 4xx-Fehler außer 429 und alle 5xx-Fehler ^[22]. Und wenn die Retry-Logik zu aggressiv ist, können diese fehlerhaften Retries die Inferenzkosten um das 3- bis 5-Fache hochtreiben ^[21].

Hier eine einfache Übersicht der häufigsten Statuscodes, woher sie meist kommen und was als Nächstes zu tun ist:

Verwenden Sie nicht dieselbe Retry-Logik für jeden Fehlercode. Ein 400 erneut zu versuchen verbrennt nur mehr Rechenleistung, weil die Anfrage weiterhin fehlerhaft ist. Exponentielles Backoff gehört zu 429-Fehlern ^[21]. Wenn 503- oder 504-Fehler über drei Prüfungen hinweg immer wieder auftauchen, lösen Sie einen Circuit Breaker aus und leiten den Traffic zum Basismodell um.

Als Nächstes prüfen Sie, ob langsame Antworten in ein Timeout laufen, bevor sie fertig sind.

5. Timeout-Rate

Wenn Fehler steigen und es keinen klaren Sprung bei tatsächlichen Ausfällen gibt, ist die Timeout-Rate das Nächste, was zu prüfen ist. Ein Timeout ist immer noch eine fehlgeschlagene Anfrage: Der Client erhält vor der Deadline keine Antwort. Tracken Sie die Timeout-Rate als Anteil der Anfragen, die diese Deadline überschreiten, was sich oft als serverseitige Timeout-Fehler zeigt.

Feinabgestimmte Modelle laufen eher in Timeouts, weil sie oft längere Ausgaben produzieren. Wenn die Trainingsdaten wortreich waren, kann das Modell mehr Tokens pro Anfrage generieren als das Basismodell. Das ist häufig bei der Nutzung von Alibaba-Qwen-Modellen oder anderen leistungsstarken LLMs, die detaillierte Antworten priorisieren. Mehr Tokens bedeuten mehr Generierungszeit, und diese zusätzliche Zeit ist es, die Anfragen über die Deadline treibt ^[8].

Wenn die Queue-Tiefe über null bleibt, ist das System bereits an der Kapazitätsgrenze. Wenn das passiert, steigen die Timeout-Raten meist bald danach ^[12]. Behandeln Sie die Queue-Tiefe als Frühwarnzeichen, statt zu warten, bis Timeouts auftauchen. Wenn die Queue-Tiefe gleichzeitig mit den Timeouts steigt, haben Sie ein Kapazitätsproblem, und es erfordert sofortiges Handeln. Sobald sich die Timeout-Rate beruhigt hat, trennen Sie echte Erfolge von Fallback-Antworten.

6. Erfolgsrate und Fallback-Rate

Selbst wenn Timeouts verschwinden, können Anfragen die Aufgabe trotzdem verfehlen. Die Erfolgsrate sagt Ihnen, ob das Modell die Aufgabe tatsächlich abgeschlossen hat, nicht nur, ob es HTTP 200 zurückgegeben hat. Das bedeutet, Dinge wie Schema-Konformität, korrekte Tool-Calls und faktische Genauigkeit zu prüfen. Ein feinabgestimmtes Modell kann eine hohe Token-Genauigkeit erzielen und trotzdem 15 %–30 % der Live-Produktionsanfragen wegen Regressionen auf Aufgabenebene verfehlen ^[23].

Die Fallback-Rate sagt Ihnen, wie oft Traffic anderswohin geschickt werden musste, nachdem der feinabgestimmte Endpunkt fehlschlug, in ein Timeout lief oder von Sicherheitsfiltern blockiert wurde ^[4][5]. Deshalb sollte sie direkt neben der Erfolgsrate getrackt werden. Sie messen nicht nur Completions. Sie messen Ausgaben, die Sie nutzen können.

Nutzen Sie diese beiden Metriken zusammen als Hauptsignal für die Abschlussqualität. Wenn eine von ihnen abrutscht, ist das der Moment zu prüfen, ob das Fine-Tune gegenüber dem Basismodell noch standhält. Wenn die Win-Rate gegenüber dem Basismodell unter 50 %–55 % fällt, ist das eine gängige Rollback-Schwelle ^[2][4].

Wenn der Erfolg hoch bleibt, aber die Kosten anfangen zu steigen, prüfen Sie als Nächstes die Token-Nutzung.

Ein hoher Erfolg bedeutet nicht viel, wenn jede Anfrage zu teuer in der Bereitstellung ist.

7. Token-Nutzung pro Anfrage

Nach der Zuverlässigkeit sagt Ihnen die Token-Nutzung, ob das Modell schlank genug ist, um im großen Maßstab zu laufen. Sie zeigt auch, ob die Feinabstimmung ihre Aufgabe erfüllt, indem sie Prompt-Overhead durch erlerntes Verhalten ersetzt. Geringere Token-Nutzung bedeutet meist niedrigere Kosten und schnellere Antworten.

Tracken Sie Input-, Output- und **Gesamt-**Tokens als getrennte Zahlen. Das macht es leichter, langsames Wachstum zu erkennen, bevor es zu einem Kostenproblem wird. Hohe Input-Tokens deuten oft auf aufgeblähte Prompts oder Kontextüberlauf hin. Hohe Output-Tokens bedeuten meist langatmige Completions, schwache Stop-Regeln oder keine Output-Obergrenze. Und Output-Tokens kosten mehr als Input-Tokens, weshalb Wortreichtum das größte Kostenrisiko ist ^[15].

Ziehen Sie die Token-Zahlen bei jeder Antwort aus dem API-usage-Objekt, nicht aus einer lokalen Tokenizer-Schätzung ^[15][25]. Lokale Schätzungen können von den abgerechneten Zahlen abweichen. Wenn Sie eine 3-fache Token-Spitze sehen, gehen Sie von aufgeblähten Prompts oder Kontextüberlauf aus, bis Sie die Ursache finden ^[3]. Es hilft auch, in CI/CD eine Output-Token-Obergrenze zu setzen, damit Sie Wortreichtum-Regressionen erkennen, bevor sie ausgeliefert werden ^[15].

Token-Zahlen bilden sich direkt in Ausgaben ab, weshalb die nächste Metrik die Kosten pro Anfrage sind.

8. Kosten pro Anfrage und Kosten pro 1.000 Tokens

Tokens werden zu Dollar. Aber eine monatliche Rechnung allein sagt Ihnen nicht, warum die Ausgaben gestiegen sind. Um zu sehen, was sie treibt, tracken Sie Kosten pro Anfrage und Kosten pro 1.000 Tokens. Das gibt Ihnen die nächste Ebene der Produktionsanalyse.

Kosten pro Anfrage zeigen, was eine einzelne Nutzeraktion kostet. Berechnen Sie sie aus den abgerechneten Input-, Output- und Cache-Token-Kosten für diese Anfrage ^[26][28]. Tracken Sie dann die abgerechnete Rate pro 1.000 Tokens für sich. Wenn Sie beide Zahlen zusammen beobachten, können Sie erkennen, ob die Ausgaben steigen, weil Sie mehr Traffic haben oder weil Prompts und Completions länger werden. Dieses Muster wird oft als Token-Kriechen bezeichnet ^[15][26].

Feinabgestimmte Inferenz kann 2- bis 5-mal mehr pro Token kosten, aber sie kann die Kosten pro Anfrage trotzdem senken, wenn sie die Prompt-Länge reduziert ^[29][30]. Warum? Ein feinabgestimmtes Modell backt Rollendefinitionen, Leitplanken und Few-Shot-Beispiele in seine Gewichte ein. So wird jeder Prompt bei jedem Aufruf kürzer. In einem Benchmark benötigte ein feinabgestimmtes Modell nur 42 Completion-Tokens, wo das Basismodell 85 brauchte – eine Reduzierung der Inferenzkosten pro Anfrage um 50,6 % ^[19]. In einfachen Worten: Der höhere Stückpreis kann gegen die niedrigere Token-Zahl verlieren. Das ist der Gewinn, den Sie im Live-API-Traffic messen wollen.

Taggen Sie jeden API-Aufruf mit feature_name und user_tier, damit Sie Ausgaben mit der Produktnutzung verknüpfen können ^[27][28]. Das macht die Daten weit nützlicher, wenn die Kosten anfangen zu driften.

Ein paar Prüfungen zählen am meisten:

• Beobachten Sie Output-Tokens genau. Bei Flaggschiff-Modellpreisen können sie 5-mal mehr kosten als Input-Tokens, sodass das Kürzen einer wortreichen Antwort mehr spart als das Kürzen derselben Zahl an Prompt-Tokens ^[15].
• Setzen Sie eine Obergrenze für die durchschnittlichen Output-Tokens in Ihrer CI/CD-Pipeline. Das hilft, Wortreichtum-Regressionen zu erkennen, bevor sie in Produktion gehen ^[15].
• Überprüfen Sie Kosten nach Feature und Nutzer-Tier, nicht nur aggregiert. Sonst kann sich teure Nutzung in einer gesund aussehenden Summe verstecken.

Nach den Kosten schauen Sie, ob die Ausgaben zu echter Nachfrage passen oder nur zu ungenutzter Kapazität.

Als Nächstes vergleichen Sie diese Kosten mit der Infrastrukturauslastung und der Queue-Länge.

9. Infrastrukturauslastung und Queue-Länge

Wenn Latenz und Timeouts gestiegen sind, schauen Sie als Nächstes auf die Serving-Schicht: Queues, Speicher und Cache-Druck. Die Queue-Tiefe zählt hier am meisten. Die GPU-Auslastung neigt dazu, der Nachfrage hinterherzuhinken, ist also ein nachlaufendes Signal. Deshalb sollte sich das Autoscaling an der Queue-Tiefe pro Replica orientieren, nicht am Rechenprozentsatz ^[10][32].

Die KV-Cache-Nutzung ist eine weitere Metrik, die Teams oft übersehen. Der KV-Cache speichert Token-Kontext im GPU-Speicher, und wenn dieser Speicher knapp wird, kann die Engine anfangen, neue Anfragen zu queuen, selbst wenn die GPU-Rechenleistung noch frei aussieht ^[31][32]. Eine gute Faustregel: Behandeln Sie 40 %–50 % KV-Cache-Nutzung als Frühwarnung und 90 %+ als Sättigung ^[31][32].

Feinabgestimmte Modelle fügen eine weitere Wendung hinzu. LoRA-Adapter benötigen Speicher zusätzlich zu den Basismodell-Gewichten, und sie bei der ersten Anfrage nach einem Scale-up zu laden erzeugt Cold-Start-Verzögerung. In den meisten Fällen fügt das der TTFT ein paar Hundert Millisekunden hinzu ^[10]. Das Vorladen von Adaptern beim Start vermeidet den größten Teil dieses Verlusts. Es hilft auch, die CPU für sich zu beobachten, da Tokenisierung und Vorverarbeitung Latenz hinzufügen können, die leicht übersehen wird ^[10].

Wenn diese Kapazitätssignale weiterhin gesund aussehen, gehen Sie zur Ausgabequalität über.

10. Nutzerzufriedenheit und Task-Abschlussrate

Nach Latenz, Kosten und Zuverlässigkeit ist die letzte Prüfung einfach: Erledigt das Modell die Aufgabe? Ein feinabgestimmter Endpunkt kann schnell, günstig und stabil sein und trotzdem das Ziel verfehlen.

Die Task-Abschlussrate (TCR) ist der Anteil der Anfragen, die ohne menschliche Hilfe gelöst werden. Die menschliche Prüfungsrate ist der Anteil der Ausgaben, die noch manuelle Korrekturen brauchen. Dieser Unterschied ist wichtig. Ein Modell kann HTTP 200 zurückgeben und trotzdem etwas liefern, das eine Person bereinigen muss, bevor es jemand nutzen kann. TCR trackt also das Geschäftsergebnis, nicht nur, ob die API geantwortet hat.

Bei Arbeit mit strukturierter Ausgabe können 500 hochwertige Beispiele die Format-Konformität von 68 %–74 % auf 97 %–99 % treiben ^[33]. Diese Art von Sprung reduziert, wie oft Personal eingreifen muss. Sobald das Format korrekt ist, vergleichen Sie das feinabgestimmte Modell direkt mit dem Basismodell.

Geschwindigkeit zählt auch hier. Eine p99-Latenz über 5 Sekunden treibt rund 45 % Abbrüche ^[33]. Wenn das Fine-Tune also das Erlebnis verlangsamt, zeigen Nutzer Ihnen das schnell – indem sie gehen.

Für eine direkte Qualitätsprüfung nutzen Sie gepaartes Arena-Testing. Lassen Sie 200–500 Produktionsstichproben durch das Basismodell und das feinabgestimmte Modell laufen, dann bewerten Sie die Ausgaben nebeneinander mit einem LLM-as-a-Judge. Danach fixieren Sie das Judge-Modell und die Bewertungsrichtlinie, damit zukünftige Tests konsistent bleiben. Wenn die Win-Rate gegenüber dem Basismodell unter 50 %–55 % fällt, ist das eine gängige Rollback-Schwelle ^[2][4].

Es hilft auch, diese Signale zusammen zu beobachten:

• TCR
• Arena-Win-Rate
• Eine eingefrorene Benchmark-Suite

Wenn das Modell um mehr als 5 Punkte auf allgemeinen Benchmarks fällt, behandeln Sie das als klaren Fehlschlag, selbst wenn aufgabenspezifische Scores steigen ^[2].

Nutzen Sie diese Qualitätsprüfungen neben den API-Metriken aus früheren Abschnitten, wenn Sie entscheiden, ob das Fine-Tune produktionsreif ist.

Vergleichstabelle für Latenz und Durchsatz

Keine einzelne Metrik erzählt die ganze Geschichte für einen feinabgestimmten Endpunkt. Die durchschnittliche Latenz zum Beispiel kann Schwankungen von Anfrage zu Anfrage glätten, besonders wenn anbieterseitiges Queueing und Batching ins Spiel kommen ^[9].

Deshalb hilft es, Latenz und Durchsatz zuerst getrennt zu messen und sie dann nebeneinander zu vergleichen, bevor Sie SLOs festlegen.

Schlüsseln Sie die Ergebnisse nach Endpunkttyp, Modellversion, Region und Tageszeit auf. Traffic zu Spitzenzeiten bringt oft Latenzprobleme an die Oberfläche, die Tests außerhalb der Spitzenzeiten nicht erfassen.

Diese Aufschlüsselungen machen es viel leichter zu erkennen, wo ein feinabgestimmter Endpunkt unter Live-Traffic zu kämpfen beginnt.

Zuverlässigkeitsmetriken, die Rollback-Risiko signalisieren

Das klarste Zeichen dafür, dass ein Rollback nötig sein könnte, ist die Win-Rate gegenüber dem Basismodell. Führen Sie gepaarte Canaries und Shadow-Routing durch, damit Sie das feinabgestimmte Modell nebeneinander mit dem Basismodell vergleichen können. Wenn die Win-Rate unter 50 % fällt, bringt das Fine-Tune in Produktion keinen Mehrwert mehr. Ihre Routing-Schicht sollte auch automatisch zurückrollen, wenn die Canary-Kohorte einen 2-Punkte-Abfall bei einem beliebigen Qualitäts-Score pro Rubrik über 30–60 Minuten hält ^[2][4]. Sobald diese Vergleiche negativ werden, ist der nächste Schritt einfach: die Prompt-Gruppen finden, die brechen.

Ein paar weitere Signale sollten als Rollback-Auslöser dienen: 5xx + Timeout-Rate, Ablehnungsrate, Rate ungültiger Ausgaben, 429-Spitzen und Fallback-Verhalten. Das sind die Zahlen, die zählen, wenn Sie entscheiden, ob das Fine-Tune live bleiben soll. Tracken Sie 429-Spitzen für sich. Sie deuten oft auf höhere Rechenkosten oder tiefere Queues hin ^[24][5].

Es hilft auch, Ablehnungsrate und Rate ungültiger Ausgaben zu trennen, statt sie zusammenzuwerfen. Ablehnungen über 2 % deuten oft auf eine Sicherheitsregression oder auf Anbieterfilter hin, die mit Ihren benutzerdefinierten Prompts kollidieren ^[5][35]. Die Rate ungültiger Ausgaben deutet meist auf Schema-Drift oder schwächere Anweisungsbefolgung hin ^[2][24].

Schlüsseln Sie jede Metrik nach Prompt-Typ, Workflow-Route und Modellversion auf. Ein Modell kann bei allgemeinen Anfragen gut aussehen und trotzdem bei Pfaden mit strukturierter Ausgabe oder domänenspezifischen Prompts zu kämpfen haben. Diese Aufspaltung macht es viel leichter zu beurteilen, ob das Modell sicher weiterlaufen kann und ob das Kostenprofil noch hält.

Kosten-, Token- und Ressourcenmetriken in Dollar

Nach Latenz, Durchsatz und Zuverlässigkeit ist der nächste Schritt einfach: Ist der Endpunkt das Geld wert? Stetiger Traffic hilft nicht viel, wenn jede Anfrage zu viel kostet. Sobald die Zuverlässigkeit unter Kontrolle ist, müssen Sie die Token-Nutzung in Dollar umwandeln.

Für GPT-4o kommt die Preisgestaltung für feinabgestimmte Inferenz mit einem 1,5-fachen Aufschlag auf die Basisraten. Das ergibt $3,75 pro 1M Input-Tokens und $15 pro 1M Output-Tokens ^[36]. Diese zusätzlichen Kosten ergeben nur Sinn, wenn das Fine-Tune die Kosten senkt, um ein erfolgreiches Ergebnis zu erhalten. Eine gängige Methode, Ausgaben zu senken, ist über Mengenrabatte für KI-APIs und Model Cascading: Senden Sie einfache Anfragen an ein kleineres, günstigeres Modell und sparen Sie das größere Modell für schwierigere Aufgaben auf ^[37].

Es hilft auch, die Ausgaben über Szenarien mit geringer, erwarteter und hoher Last hinweg zu prognostizieren. Rechnen Sie dann Retries, Fallback-Nutzung und Evaluierungsläufe ein ^[26]. Dieser Schritt zählt mehr, als viele Teams erwarten, denn 40 % der Teams überschreiten ihr KI-API-Budget im ersten Quartal der Nutzung ^[37]. Darüber hinaus tracken Sie die p95-Kosten pro Anfrage, nicht nur den Durchschnitt. Sonst können Prompts mit langem Kontext oder wiederholte Retries Ihre Prognose auf Weisen verzerren, die der Mittelwert nicht zeigt ^[24]. Rohe Ausgaben werden erst nützlich, wenn Sie sie mit erfolgreichen Ergebnissen verknüpfen.

Diese Verknüpfung sind die Kosten pro erfolgreichem Ergebnis. In der Praxis könnte das Kosten pro gelöstem Support-Ticket oder Kosten pro akzeptierter Antwort bedeuten. Wenn ein feinabgestimmtes Modell den Anteil erfolgreicher Ergebnisse hebt, können Ihre Kosten pro Lösung sinken, selbst wenn der Preis pro Anfrage steigt ^[26][37].

Bei selbst gehosteten Deployments ist die GPU-Auslastung der Hauptkostentreiber. Fixe GPU-Ausgaben zahlen sich erst aus, sobald die Nutzung eine bestimmte Schwelle überschreitet. Anders gesagt: Hohe Auslastung zählt, wenn sie die Kosteneffizienz verbessert. Sie sollten außerdem die Queue-Länge neben der Auslastung beobachten. Wenn die Queue-Tiefe weiter steigt, ist das meist ein Zeichen für Sättigung, zusätzliche Kosten und mehr Skalierungsdruck ^[11][15].

Nutzen Sie diese Metriken zusammen, um den Unterschied zwischen gesunder Last und teurer Verschwendung zu erkennen.

Qualitätssignale, die Sie über die API beobachten können

Sobald Latenz, Durchsatz und Kosten in gutem Zustand sind, ist der nächste Schritt einfach: prüfen, ob das Modell den Nutzern tatsächlich hilft, Dinge zu erledigen. Geschwindigkeit zählt, sicher. Aber eine schnelle Antwort, die das Problem nicht löst, ist trotzdem ein Fehlschlag.

Konzentrieren Sie sich zuerst auf Task-Abschlussrate, Eskalationsrate und Human-Handoff-Rate. Das sind Ihre wichtigsten Ergebnissignale. Sie sagen Ihnen, ob das feinabgestimmte Modell die Anfrage selbst bewältigt hat oder ob jemand eingreifen musste. Und das zählt mehr als Benchmark-Scores, weil diese Metriken aus tatsächlichen Anfrage- und Sitzungslogs stammen.

Sie können auch Daumen-hoch/runter-Bewertungen und die Abbruchrate als unterstützende Signale auf Sitzungsebene tracken, die an den API-Traffic gebunden sind. Selbst wenn das Feedback spärlich ist, kann es wiederkehrende Schmerzpunkte zeigen. Der Abbruch ist besonders nützlich, weil er zeigt, wo das Modell zu driften beginnt, den Kontext verliert oder mitten in einem Gespräch aufhört, hilfreich zu sein.

Es hilft auch, Live-Traffic mit einem LLM-as-Judge zu sampeln, um Halluzinations- und Sicherheitsprobleme zu schätzen. Eine 5-%-Stichprobe reicht oft aus, um Anomalien zu erkennen, ohne die Evaluierungsausgaben zu stark hochzutreiben ^[39]. Behalten Sie auch die Auslösehäufigkeit von Leitplanken im Auge. Wenn mehr als 20 % der Anfragen blockiert werden, kann das auf einen Sprung bei unsicheren Ausgaben oder eine Diskrepanz zwischen dem, was Nutzer wollen, und dem, was das System erwartet, hindeuten ^{[38] [1] [2]}. Ein starker Anstieg der Ablehnungsrate bedeutet oft, dass Filter zu sensibel geworden sind oder dass eine Prompt-Vorlage irgendwo im Stack gebrochen ist ^{[39] [2]}.

Jeder Live-Fehler sollte als dauerhafter Fall zurück in das Offline-Test-Set fließen. So verhindern Sie, dass sich dasselbe Problem später wieder einschleicht.

Nutzen Sie die Tabelle unten, um primäre Qualitätssignale von unterstützenden zu trennen.

Nutzen Sie diese Signale neben Latenz und Kosten im Observability-Dashboard.

Observability-Dashboards für feinabgestimmte Endpunkte

Einzelne Metriken zu tracken hilft. Aber der Nutzen kommt, wenn Sie alles an einem Ort sehen.

Ein solides Observability-Setup für feinabgestimmte Endpunkte ruht auf vier Säulen: Metriken für aggregierte Signale wie Latenz und Fehlerraten, Traces für den gesamten Pfad einer Anfrage, Logs für strukturierte Aufzeichnungen dessen, was passiert ist, und Evaluierungen für asynchrone Qualitätsprüfungen ^[40][42].

Das zählt bei feinabgestimmten Modellen sogar noch mehr. Eine Anfrage kann auf Systemebene erfolgreich sein und trotzdem auf Bedeutungsebene fehlschlagen, selbst bei Nutzung einer KI-Chat-Oberfläche. Das Dashboard muss also semantische Fehler zeigen, nicht nur Transporterfolg. Altmodisches APM kann zeigen, dass eine Antwort gesund war. Es kann Ihnen nicht sagen, ob die Antwort falsch war. Ein 200 OK kann trotzdem ein schlechtes Ergebnis verbergen.

Bauen Sie das Dashboard um fünf Ansichten herum auf: Latenz, Zuverlässigkeit, Kosten, Qualität und Kapazität. Nutzen Sie OpenTelemetry mit GenAI-Semantikkonventionen und Tail-Sample-Traces, damit Sie alle langsamen und fehlgeschlagenen Anfragen behalten, während Sie einen kleinen Ausschnitt des normalen Traffics sampeln ^[40][41]. Dieses Setup zahlt sich auch bei Vorfällen aus: Tracing kann die mittlere Wiederherstellungszeit um das 3-Fache verkürzen ^[42].

Nutzen Sie diese Signale, um ein Dashboard mit fünf Kernpanels zu erstellen: Latenz, Zuverlässigkeit, Kosten, Qualität und Kapazität.

Eine gute Betrachtungsweise: Latenz sagt Ihnen, wie schnell sich das System bewegt hat, Zuverlässigkeit zeigt, ob es verfügbar blieb, Kosten zeigen, was jede Antwort Sie kostet, Qualität zeigt, ob die Antwort gut war, und Kapazität sagt Ihnen, wann das System anfängt, heiß zu laufen.

Tabelle für das Dashboard-Design

Diese Tabelle verknüpft jedes Dashboard-Widget mit dem Diagrammtyp, der am besten funktioniert, und den Filtern, die es bei Vorfällen und Kostenüberprüfungen nützlich machen.

Damit diese Filter vom ersten Tag an funktionieren, taggen Sie Traces während der Instrumentierung mit Modell-ID, Prompt-Version und Umgebung. OpenTelemetry-GenAI-Semantikkonventionen umfassen Attribute wie gen_ai.request.model und gen_ai.usage.input_tokens ^[40].

Wählen Sie das Diagramm, das das Fehlermuster auf einen Blick leicht erkennbar macht.

Die Kostenzuordnung zeigt, welche Modellversion die Ausgaben treibt. Der Trace-Explorer zählt am meisten für RAG- und Agenten-Workflows, weil er Latenz und Fehler über Retrieval, Tool-Calls und Inferenz hinweg zeigt ^[43][40].

Nachdem Sie jedes Widget definiert haben, legen Sie Aufbewahrungs- und Sampling-Regeln fest. Speichern Sie alle Anfragen mit hoher Latenz, Fehlern und niedrigem Qualitäts-Score im Trace-Explorer. Sampeln Sie dann routinemäßig erfolgreiche Anfragen mit 5 %–20 %, um die Speicherkosten unter Kontrolle zu halten ^[40].

Fazit

Die Fine-Tune-Evaluierung muss Verbesserung beweisen, nicht nur Veränderung. Deshalb muss die finale Scorecard Geschwindigkeits-, Zuverlässigkeits-, Kosten- und Ergebnismetriken zusammen betrachten.

Wenn Sie eine Metrik isoliert optimieren, können sich Produktionsprobleme schnell einschleichen. Ein Modell könnte schneller, aber weniger stabil werden. Oder es könnte die Prüfzeit senken und dabei die Fehler hochtreiben. Der Punkt ist, das ganze Bild zu tracken, nicht einen Ausschnitt davon.

Beginnen Sie mit dem Basismodell. Ohne diese Baseline können Sie nicht zeigen, dass das Fine-Tune irgendetwas besser gemacht hat. Führen Sie einen 5-%–10-%-Canary durch und vergleichen Sie diese Ergebnisse über Shadow-Routing mit dem Basismodell. Setzen Sie Alerts, wenn die Latenz über das 2-Fache der Baseline steigt oder wenn die Fehlerrate 5 % über 5 Minuten überschreitet. Sobald diese Leitplanken gesetzt sind, verknüpfen Sie die Zahlen mit Betriebseinsparungen.

Jede Metrik sollte sich auf ein Geschäftsergebnis abbilden. Die menschliche Prüfungsrate ist ein direkter Stellvertreter für Betriebseinsparungen. Wenn sich diese Zahl nicht bewegt, schafft das Fine-Tune keinen Produktionswert.

Dashboards und Alerts sind nicht optional. Bauen Sie Observability vor dem Start auf, damit Regressionen sichtbar werden, bevor Nutzer sie bemerken.

FAQs

Welche API-Metriken sollte ich zuerst überwachen?

Beginnen Sie mit Infrastruktur- und Zuverlässigkeitsmetriken, um zu prüfen, dass das System stabil ist. Konzentrieren Sie sich auf TTFT im 95. Perzentil, End-to-End-Latenz, harte Fehlerraten, Ablehnungsrate und Kosten pro Anfrage.

Sobald Sie diese Baselines haben, beobachten Sie die Ausgabequalität mit LLM-as-Judge-Scores und Fähigkeits-Drift. Das hilft Ihnen zu erkennen, ob das Modell begonnen hat, bei Kernfähigkeiten abzurutschen.

Wie vergleiche ich ein feinabgestimmtes Modell mit dem Basismodell?

Lassen Sie beide Modelle auf demselben Holdout-Test-Set laufen – Daten, die nie im Training verwendet wurden – damit Sie die Lücke sauber messen können. Beginnen Sie zuerst mit einer starken Prompting-Baseline auf dem Basismodell. Das gibt Ihnen einen fairen Vergleichspunkt, statt das Ergebnis zu verzerren.

Vergleichen Sie die Modelle über Qualität, Latenz und Kosten hinweg.

Für die Qualität nutzen Sie Metriken, die zur Aufgabe passen, wie:

• F1 für Klassifizierungs- oder Extraktionsaufgaben
• Exact Match für Aufgaben mit einer richtigen Antwort
• JSON-Parse-Rate für strukturierte Ausgaben

Für die Latenz messen Sie die End-to-End-Antwortzeit, nicht nur die reine Modelllaufzeit. Das bedeutet, den gesamten Anfragepfad von der Prompt-Übermittlung bis zur finalen Ausgabe zu messen.

Für die Kosten nutzen Sie die Preise pro 1M Tokens jedes Modells und berechnen, was Sie auf Basis der tatsächlichen Input- und Output-Token-Nutzung im Test-Set zahlen würden.

Wann sollte ich ein feinabgestimmtes Modell zurückrollen?

Rollen Sie zurück, wenn das Produktionsmonitoring zeigt, dass die Qualität klar gesunken ist. Das kann auf Modell-Drift oder ein Versagen bei Live-Eingaben hindeuten.

Sie sollten auch zurückrollen, wenn das Modell bei Ihrem Ablehnungs-Set abrutscht, neue Prompt-Injection-Schwächen öffnet oder während des Produktions-Canary-Tests schlechter abschneidet als die aktuelle Version.

Behalten Sie die p95-Latenz und von Nutzern gemeldete Qualitätsprobleme genau im Auge, damit Sie Probleme früh erkennen können.