AI API Gateway bewerten: Checkliste für Production
Reproduzierbare Bewertung von Protocol, Failure Drills, Latenz, Usage und Kosten, Security, Control Plane und Exit Risk.
Bewerten Sie ein AI API Gateway, indem Sie Ihren echten Protocol Contract ausführen, relevante Failure Modes erzwingen und die Request-level Evidence prüfen. Eine Feature-Liste oder ein erfolgreicher „Hello World“-Request beweist weder korrektes Streaming noch Tool Compatibility, sicheren Fallback, korrekte Kosten, Security Boundaries oder einen nutzbaren Exit Path.
Ein belastbarer Prozess trennt nicht verhandelbare Gates, an denen ein Kandidat scheitert, von bewertbaren Betriebsqualitäten, die erst nach bestandenen Gates verglichen werden.
Zuerst den Workload Contract definieren
Beginnen Sie nicht mit einer Vendor-Vergleichstabelle, sondern mit einem repräsentativen Workload und seinen Invarianten:
- exakter Endpoint: Responses, Chat Completions, Embeddings, Images oder eine andere API;
- exakte Model IDs und erlaubte Aliases;
- verwendete Streaming- und Non-streaming-Modi;
- benötigte Structured Outputs, Function Calling, Hosted Tools, Reasoning oder Felder;
- typische und hochperzentile Input-/Output-Längen;
- Concurrency, Request Rate, Region und User-facing Deadline;
- notwendige Usage-, Cache-, Cost- und Correlation-Felder;
- erlaubte Fallback Routes und Verbot einer Model Substitution;
- Data Retention, Access, Residency und Deletion;
- Application Operations mit möglichen Side Effects.
Ein Gateway kann für einen textbasierten internen Assistenten bestehen und für einen Streaming Coding Agent scheitern. „OpenAI-compatible“ ist keine ausreichende Definition, da Compatibility je Endpoint, Event Type, Tool, Schema Keyword und Provider Route variiert.
Falls noch unklar ist, ob ein Proxy oder eine modellbewusste Control Plane benötigt wird, beginnen Sie mit LLM Proxy vs. AI Gateway. Diese Checkliste setzt die Gateway-Kategorie voraus und prüft eine konkrete Implementierung.
Schnelle Ausschlusskriterien vor einem langen Trial
Die erste Prüfung sollte Kandidaten entfernen, die eine Pflichtgrenze nicht erfüllen. Fordern Sie reproduzierbares Verhalten statt Roadmap-Aussagen.
| Gate | Sofortiges Ausschlusskriterium | Anzufordernde Evidenz |
|---|---|---|
| Protocol | Pflichtfeld, Output Item oder Stream Event wird verworfen oder falsch umgeschrieben | Redacted Request/Response und Parser Result |
| Model Identity | Requested Model wird still ersetzt | Attempt Record mit angefordertem und tatsächlichem Modell |
| Streaming | Vollständiges Buffering, verlorene Cancellation oder beschädigte Tool Argument Fragments | Timestamped Event Sequence und Cancel Trace |
| Authentication | Browser oder Workload Client erhält Provider Credentials | Credential Flow und echte Key Rotation |
| Tenant Isolation | Ein Project kann Keys, Usage oder Logs eines anderen verwenden/einsehen | Authorization Check mit wirklich isolierten Accounts |
| Cost Evidence | Final Charge lässt sich nicht mit Model, Route, Price Basis und Usage verbinden | Reconciled Ledger eines Requests |
| Failure Safety | Partial Stream wird transparent wiederholt oder Cancel startet neuen Attempt | Erzwungene Partial-Stream- und Cancel-Traces |
| Export and Exit | Configuration und Contract sind nur durch Application Rewrite wiederherstellbar | Export Sample und Provider-native Rollback Drill |
Ein Pflicht-Gate darf nicht durch einen hohen Gesamtscore kompensiert werden. Ein gutes Dashboard gleicht mangelhafte Tenant Isolation nicht aus; ein niedriger Preis keinen falschen Tool Contract.
Kleinen Protocol Conformance Corpus aufbauen
Nutzen Sie deterministische, nicht sensible Inputs und versionieren Sie das erwartete Wire Behavior. Der Corpus ruft den echten Gateway Endpoint auf; Provider Mocking oder eine Kopie der Conversion Logic als Test Oracle sind ungeeignet.
| Case | Request | Erforderliche Beobachtung |
|---|---|---|
| Basic Non-streaming Text | Pinned Model und fester Prompt | Status, Model Identity, Text Location, Usage, Request ID korrekt |
| Streaming Text | Gleicher Prompt mit Streaming | Geordnete Events, First Effective Output, Final Event, Cancellation |
| Structured Output | Strict Schema mit Required Fields und additionalProperties: false |
Valider Output oder expliziter Unsupported Error, kein Silent Downgrade |
| Function Calling | Eine Read-only Function und zurückgegebenes Result | Function Name, JSON Arguments, Call ID Correlation, Final Answer |
| No-tool Path | Tools deklariert, aber nicht erforderlich | Normaler Text ohne erfundenen Tool Call |
| Invalid Field | Absichtlich unsupported oder malformed | Stabiler Client Error; Fallback verdeckt Fehler nicht |
| Long Input Boundary | Direkt unter und über dem Limit | Dokumentierte Annahme oder explizite Ablehnung, keine stille Truncation |
| Usage Detail | Request mit Cache- oder Reasoning Usage | Felder überstehen Route und stimmen mit Billing Record überein |
| Cancellation | Cancel nach Verbindung und nach First Output | Upstream Work stoppt, kein neuer Fallback Attempt |
| Partial Stream | Verbindungsfehler nach Effective Output | Ein expliziter Partial Failure, keine unsichtbare zweite Antwort |
Jeder Case muss auf jeder Route laufen, die den Workload bedienen kann. Ein bestandener Primary Route qualifiziert keinen Fallback. Der Structured-Outputs-Guide und der Function-Calling-Vergleich liefern Field-level Cases.
Notieren Sie Gateway Version, Route Configuration Version, Model ID, Provider, Region, Timestamp und Sanitized Result Hash. Prüfen Sie vor Rollout und nach materiellen Route-Änderungen erneut.
Routing und Fehlerverhalten statt nur Erfolg testen
Reliability Claims sind nur mit sichtbarer Failure Policy wertvoll. Erzwingen Sie vor Production:
- Primary Route vor Headers nicht verfügbar;
- Provider Rate Limit mit und ohne
Retry-After; - Upstream Authentication oder Account Failure;
- Slow Headers und Slow First Effective Output;
- Malformed Provider Response;
- Caller Cancellation bei pending Upstream;
- Connection Loss nach sichtbarem Output;
- Erschöpfung aller geeigneten Routen.
Erfassen Sie Attempt Order, Selected Route, Status, Timing, Output-Beginn, Terminal Reason, Usage und Cost. Requested Model und Protocol müssen erhalten bleiben, sofern keine separate Model-substitution Policy aktiv ist.
Messen Sie Attempt Amplification über SDK, Application, Gateway und Provider. Eine Ebene besitzt den unmittelbaren Same-contract Fallback; die Application entscheidet über die Wiederholung der vollständigen User Action. AI API Fallback Strategy beschreibt Failure Matrix und Retry Budget.
Latenz braucht präzise Definitionen. Vergleichen Sie Upstream Headers, First SSE Event, First Effective Output, First Visible Text, Completion und Visible Output Speed bei realistischer Concurrency. Ein unerklärter Mittelwert „Latency“ reicht nicht. Siehe AI API Latency Metrics.
Usage und Kosten je Request abgleichen
Verfolgen Sie mehrere abgeschlossene Requests durch die vollständige Kette:
application request ID
→ gateway attempt sequence
→ selected model and route
→ provider or normalized usage
→ applicable price basis
→ final recorded charge
Die Evaluation muss beantworten:
- Sind Input, Output, Cached, Reasoning und Tool-related Units vertreten?
- Welche Werte stammen vom Provider, welche sind Estimated?
- Wann wird der Model Price ausgewählt und für den Request fixiert?
- Wie verändern Group, Service Tier, Discount oder Surcharge den User Charge?
- Welche Failed Attempts erzeugen Provider Cost und wie werden sie erfasst?
- Verbirgt ein erfolgreicher Fallback frühere Billable Attempts?
- Sind Currency Conversion und Rounding Rules explizit?
- Kann Finance den Daily Total aus Immutable Request Records reproduzieren?
Testen Sie Normal Completion, Same-contract Fallback, Cancelled Request und Upstream Error. Ein Dashboard Total genügt nicht; erforderlich ist ein belastbarer Per-request Record. AI API Cost Tracking trennt Provider Usage, Platform Pricing, Customer Charge und Supplier Cost.
Vergleichen Sie keine Savings, ohne Model, Workload, Cache Behavior, Output Length, Failure Rate und Provider Price Basis konstant zu halten. Niedrigere scheinbare Kosten können aus Missing Usage oder Silent Model Substitution entstehen.
Security und Data Boundary prüfen
Zeichnen Sie den tatsächlichen Data Flow vom Client über das Gateway zu jedem Provider. Identifizieren Sie für jeden Hop den Zugriff auf Credentials, Request/Response Content, Metadata und Administrative Configuration.
Prüfen Sie mindestens:
- Provider Credentials bleiben Server-side, sind At-rest Encrypted und gehen nie an normale Clients;
- Application Keys lassen sich je Project/Workload scopen und unabhängig widerrufen;
- Authorization wird auf jedem Management- und Log-Endpoint Server-side erzwungen;
- Logs vermeiden vollständige API Keys und haben explizite Prompt/Response Retention Controls;
- Support Access ist attributierbar und begrenzt;
- Configuration Changes enthalten Actor, Time, Before/After und Rollback Evidence;
- Exports entfernen Secrets, Personal und Proprietary Content;
- Deletion und Retention sind demonstrierbar;
- Region und Subprocessor Claims stimmen mit der genutzten Route überein;
- Abuse Limits greifen möglichst vor teurer Upstream Work.
Fragen Sie nach Key Rotation, Operator Departure, kompromittiertem Application Key und Provider-key Leak. Führen Sie Rotation und Revocation mit echten isolierten Test Credentials durch, ohne Production Secrets zu kopieren.
Ein Gateway macht unsichere Application Tools nicht sicher. Tool Authorization, Transactionality, Approval und Idempotency bleiben Application Responsibilities. AI API Key Security and Cost Controls trennt Credentials und Workload Limits.
Operational Control Plane bewerten
Ein funktionierender Data Plane kann von einer riskanten Control Plane begleitet werden.
| Bereich | Zu beantwortende Fragen |
|---|---|
| Versioning | Ist jede Route-, Price-, Policy- und Key-Änderung versioniert oder attributierbar? |
| Validation | Werden Invalid Route oder Incompatible Model vor Aktivierung abgelehnt? |
| Rollout | Kann eine Änderung zuerst einen kleinen Workload/Prozentsatz betreffen? |
| Rollback | Lässt sich Last-known-good Configuration schnell wiederherstellen? |
| Availability | Was geschieht mit Existing/New Requests bei Ausfall der Control Plane? |
| Health | Nutzt Channel Health aktuelle Evidenz und ist Auto-disable nachvollziehbar? |
| Incidents | Ist ein Request ohne mehrere unverbundene Systeme rekonstruierbar? |
| Limits | Bleiben Rate/Quota Decisions unter Concurrency korrekt? |
| Change Ownership | Sind Emergency Edits von Product Configuration getrennt? |
Führen Sie einen Configuration Rollback und eine Unhealthy-route Removal wirklich aus. Zählen Sie Operator Steps und verifizieren Sie Data-plane Behavior. Ein Screenshot des Buttons ist kein Drill.
Exit Path vor Vertragsabschluss testen
Gateway-Nutzung kann Abhängigkeiten von Model Aliases, Custom Headers, proprietären Route Names, Log APIs, Normalized Error Shapes oder Hosted Prompt/Tool Configuration erzeugen. Klassifizieren Sie jede als beabsichtigten Nutzen oder unbeabsichtigten Lock-in.
Ein praktischer Exit Drill sollte:
- Route-, Key-policy-, Price- und Audit Configuration dokumentiert exportieren;
- einen Workload auf einen Provider-native Test Endpoint umstellen;
- Gateway-only Headers/Aliases durch explizite Application Configuration ersetzen;
- Request Correlation und Usage Reconciliation erhalten;
- nicht ohne Redesign migrierbare Funktionen dokumentieren;
- Exit Engineering anhand realer Arbeit statt Sales Claim schätzen.
Ein Exit Path verlangt keine Austauschbarkeit mit jedem Provider. Das Team muss wissen, was es selbst besitzt, was das Gateway besitzt und wie der zugrunde liegende Protocol Contract wiederhergestellt wird.
Erst nach bestandenen Gates bewerten
Nutzen Sie pass/fail für Hard Boundaries und einen kleinen Evidence Score für Operations:
| Score | Bedeutung |
|---|---|
| 0 | Unsupported oder durch Test widerlegt |
| 1 | Behauptet oder einmal manuell gezeigt, schwache Evidenz |
| 2 | Wiederholbar mit Request-level Evidence demonstriert |
| 3 | Wiederholbar, überwacht und mit geprüftem Control recoverable |
Bewerten Sie Protocol Coverage, Route Reliability, Attempt Evidence, Latency Diagnostics, Usage Accuracy, Cost Reconciliation, Key Isolation, Auditability, Configuration Rollback, Supportability und Exit Effort. Gewichten Sie nach Workload, aber halten Sie Raw Evidence neben jedem Score.
Vermeiden Sie falsche Präzision wie 87.4/100. Dokumentieren Sie Mandatory Gates, Evidence Links, Accepted Gaps mit Owner und Remediation Deadline, Cost/Contract Assumptions, ausgewählte und verworfene Kandidaten sowie ein Review Date nach dem ersten Production-Monat.
Build versus Buy nach Ownership vergleichen
Die Frage ist nicht, ob ein internes Gateway keine Lizenz kostet, sondern welche Verantwortung das Team dauerhaft tragen kann.
| Verantwortung | Intern gebaut | Purchased oder Managed |
|---|---|---|
| Protocol Updates | Provider Schemas und Regressions verfolgen | Vendor Updates und Route Compatibility prüfen |
| Routing and Retry | State Machine und Failure Evidence entwerfen | Policy konfigurieren und echte Attempts auditieren |
| Usage and Billing | Usage normalisieren und Pricing Logic pflegen | Vendor Records mit Finance Truth abgleichen |
| Security | Secrets speichern, Tenancy durchsetzen, Access auditieren | Vendor Boundary prüfen und Least Privilege konfigurieren |
| Reliability | Data Plane, Control Plane und On-call betreiben | Vendor plus Integration überwachen und Exit Path erhalten |
| Product Support | Jede Application/Provider-Interaktion diagnostizieren | Gateway-, Provider- und Application-Fault triagieren |
Verwenden Sie keine generischen Gehalts- oder „Zeitersparnis“-Zahlen. Schätzen Sie anhand eigener On-call Load, Protocol-change History, Incident Frequency, Finance Requirements und Compliance Work. Auch ein Managed Product braucht einen Accountable Internal Owner.
Checkliste korrekt auf Modelflare anwenden
Der aktuelle Evaluationsumfang von Modelflare muss explizit sein. Die Plattform bietet Workload API Keys, Requested-model Routing über geeignete Groups und Channels, Ordered Group Fallback für normale Keys, Strategy-based Group Selection für Smart API Keys, Pre-upstream Group RPM Admission sowie Request-level Usage-, Cost-, Status- und Timing-Records.
GPT-, Codex- und OpenAI-Traffic ist das vollständig adaptierte Compatibility Target. Andere OpenAI-compatible Model Families sollten bis zur Einzelprüfung als Raw Chat Completions Pass-through bewertet werden. Eine gemeinsame Base URL beweist keine identische Unterstützung von Responses, Hosted Tools, Structured Outputs oder Function Calling auf jeder Route.
Modelflare Fallback soll einen geeigneten Pfad für das Requested Model suchen, statt still ein anderes Modell zu wählen. Channel Failover stoppt nach Beginn des Downstream Output. Prüfen Sie diese Claims mit Corpus und Failure Drills statt Marketing-Aussagen.
Models & Pricing zeigt die aktuelle Model/Group Surface; über Modelflare Docs richten Sie einen isolierten Test Key ein. Verwenden Sie nicht sensible Requests, pinnen Sie das exakte Modell und bewahren Sie Request IDs für die Attempt-Analyse auf.
Die Entscheidung muss reproduzierbar sein: Ein anderer Engineer kann denselben Corpus ausführen, dieselben Evidence Categories prüfen und verstehen, weshalb ein Kandidat bestanden hat. Das dauert länger als eine Vergleichsseite, ist aber schneller als ein inkompatibler Tool Contract, eine nicht nachvollziehbare Rechnung oder unsicherer Fallback im Production Traffic.