API-Umstellung: Antworten

Die neue API (https://llm-server.ai.t-systems.net/v1) führt eine einheitliche Antwortstruktur über verschiedene Modell-Provider hinweg ein. Das verbessert die Konsistenz und erhält die zentralen Felder, die Standardintegrationen für Chat Completions nutzen: choices, message, finish_reason und usage bleiben verfügbar.

{
  "id": "chatcmpl-example",
  "object": "chat.completion",
  "model": "gpt-6.1-sol",
  "choices": [
    {
      "index": 0,
      "message": {
        "role": "assistant",
        "content": "Hello!"
      },
      "finish_reason": "stop"
    }
  ],
  "usage": {
    "prompt_tokens": 10,
    "completion_tokens": 3,
    "total_tokens": 13
  }
}

{
  "id": "chatcmpl-example",
  "object": "chat.completion",
  "model": "gpt-6.1-sol",
  "choices": [
    {
      "index": 0,
      "message": {
        "role": "assistant",
        "content": "Hello!"
      },
      "finish_reason": "stop"
    }
  ],
  "usage": {
    "prompt_tokens": 10,
    "completion_tokens": 3,
    "total_tokens": 13
  },
  "extra_fields": {}
}

Der Wert von response.model kann bei einigen Providern außerdem vom angefragten Modellbezeichner abweichen.

Was ändert sich?

Aspekt	Legacy-API	Neue API
Antwortstruktur	Am Provider orientiertes Antwortformat	Einheitliches Chat-Completion-Format
Standardfelder	`choices`, `message`, `usage` usw.	Dieselben zentralen Felder
Token-Nutzung	Ursprüngliche Nutzungsinformationen des Providers	Details können je nach Provider variieren; optionale Felder mit dem Wert `0` können fehlen
Optionale Felder	Können explizite `null`- oder leere Werte enthalten	Einige optionale Felder können fehlen
`model` in der Antwort	In der Regel der angefragte Modellbezeichner	Kann den vom Provider gemeldeten Modellnamen enthalten, der vom angefragten Bezeichner abweichen kann
Provider-spezifische Metadaten	In der Regel erhalten	Können vereinheitlicht werden oder fehlen
Zusätzliche Informationen	Provider-spezifische Felder	Optionale Diagnose-Metadaten, einschließlich Latenzinformationen

Details zur Token-Nutzung

Die Standardfelder zur Token-Nutzung bleiben verfügbar, weitere Details hängen jedoch vom gewählten Modell und Provider ab. Einige Provider liefern zum Beispiel eine detaillierte Aufschlüsselung der Completion-Tokens, andere liefern andere Nutzungsfelder oder lassen optionale Details ganz weg.

Felder wie completion_tokens_details, reasoning_tokens oder Provider-spezifische Token-Kategorien sollten daher als optional behandelt werden. Details mit dem Wert 0 können außerdem fehlen, statt ausdrücklich als 0 zurückgegeben zu werden.

Anwendungen, die den Token-Verbrauch erfassen, sollten diese Unterschiede bei der Verarbeitung der Nutzungsinformationen berücksichtigen.

Zusätzliche Metadaten der Antwort

Die neue API kann zusätzliche Diagnoseinformationen im Objekt extra_fields liefern. Je nach Anfrage und Modell kann dies Folgendes enthalten:

Latenzinformationen — helfen, die Verarbeitungszeit der Anfrage zu verstehen.
Routing-Informationen — liefern weitere Details dazu, wie die Anfrage verarbeitet wurde.
Metadaten der Provider-Antwort — zusätzliche Informationen, sofern verfügbar.

Diese Felder sind optional und sollten nicht als Teil der erforderlichen Standard-Antwortstruktur behandelt werden.

Was Sie prüfen sollten

Für Standardintegrationen: Anwendungen, die vor allem choices, message, finish_reason und die üblichen Felder zur Token-Nutzung verwenden, benötigen in der Regel nur minimale Änderungen bei der Verarbeitung der Antwort.

Für die Erkennung des Modells: Prüfen Sie Code, der davon ausgeht, dass response.model immer dem angefragten Modellnamen entspricht.

Für strikte Antwortvalidierung: Lassen Sie fehlende optionale Felder zu und unterstützen Sie zusätzliche Metadaten der Antwort.

Für die Abrechnung von Tokens: Prüfen Sie Provider-spezifische Nutzungsfelder und gehen Sie nicht davon aus, dass jeder Provider dieselbe Aufschlüsselung der Tokens liefert.

Für Provider-spezifische Integrationen: Prüfen Sie Code, der von nicht standardisierten Antwortfeldern abhängt.