Service-Tier-Routing in einem AI-API-Gateway: Schnell, Standard, bereitgestellt und Batch ohne hartcodierende Anbieter

Diese Rangliste ist bewusst klein. Wenn Sie zwanzig Ebenen erstellen, umgehen Entwickler das System. Das Gateway kann intern weiterhin eine neutrale Ebene mehreren anbieterspezifischen Mechanismen zuordnen.

Angeforderte Stufe von ausgewählter Stufe trennen

Der Anrufer sollte eine angeforderte Stufe senden, aber das Gateway sollte sowohl die angeforderte Stufe als auch die tatsächlich ausgewählte Stufe aufzeichnen. Das ist nicht immer dasselbe.

Beispiel für Anfragemetadaten:

{
  „model“: „support-chat-default“,
  "Nachrichten": [...],
  „Metadaten“: {
    „workflow“: „customer_support_reply“,
    „tenant_id“: „tenant_123“,
    „requested_gateway_tier“: „interactive_fast“,
    „end_user_id“: „u_789“
  }

Beispiel für einen Versanddatensatz:

{
  „request_id“: „req_abc“,
  „tenant_id“: „tenant_123“,
  „api_key_id“: „key_live_456“,
  „workflow“: „customer_support_reply“,
  „model_alias“: „support-chat-default“,
  „requested_gateway_tier“: „interactive_fast“,
  „selected_provider“: „provider_a“,
  „selected_provider_tier“: „schnell“,
  „tier_outcome“: „selected_as_requested“,
  „downgrade_reason“: null,
  „input_tokens“: 1840,
  „output_tokens“: 420,
  „latency_ms“: 1420,
  „estimated_cost_usd“: „0,0312“,
  „settled_cost_usd“: „0,0308“

Wenn eine Premium-Anfrage aufgrund von Rampenlimits oder Mieterbudgetregeln an die Standardverarbeitung gesendet wird, muss dies sichtbar sein:

{
  „requested_gateway_tier“: „interactive_fast“,
  „selected_provider_tier“: „standard“,
  „tier_outcome“: „herabgestuft“,
  „downgrade_reason“: „tenant_premium_budget_exhausted“

Diese Unterscheidung verhindert irreführende Analysen. Wenn in den Dashboards nur angezeigt wird, was der Anrufer angefordert hat, erkennt die Finanzabteilung zwar die Prämienabsicht, aber nicht die Prämienausführung. Wenn Dashboards nur das Upstream-Ergebnis anzeigen, wissen Produktteams nicht, wann ihrem latenzempfindlichen Workflow Premium-Kapazität verweigert wurde.

Erstellen Sie vor dem Routing eine Fähigkeitsmatrix

Ein Service-Tier-Router benötigt eine Fähigkeitsmatrix. Die Matrix sollte die folgende Frage beantworten: Welche Kapazitätsmechanismen stehen für ein bestimmtes Modell, eine bestimmte Region, einen bestimmten Mandanten und einen bestimmten Arbeitsablauf zur Verfügung?

Mindestfelder:

• Anbieter
• model_or_deployment
• Regionen
• supports_sync
• supports_batch
• supports_premium_tier
• supports_provisioned_capacity
• supports_spillover
• provider_tier_values
• billing_line_items
• known_downgrade_behavior
• tenant_allowlist

Ein vereinfachtes Beispiel:

gateway_tier_map:
  interaktiv_schnell:
    bevorzugt:
      - Anbieter: openai
        request_params:
          service_tier: schnell
      - Anbieter: anthropic
        request_params:
          service_tier: Priorität
    Rückfall:
      - Gateway_tier: interaktiver_Standard
        erlaubt_wann: Policy.allows_standard_downgrade
  Hintergrund_Rabatt:
    bevorzugt:
      - Anbieter: anthropic
        Modus: Batch
      - Anbieter: gemini
        Modus: Batch
    Rückfall:
      - Warteschlange: verzögerte_Wiederholung
        erlaubt_wann: wahr
  reservierte_Kapazität:
    bevorzugt:
      - Anbieter: azure_openai
        Bereitstellungsklasse: bereitgestellt
    Rückfall:
      - Anbieter: azure_openai
        Bereitstellungsklasse: Standard
        erlaubt_wann: Policy.allows_spillover

Diese Matrix sollte eine Konfiguration sein, kein verstreuter Code. Änderungen bei der Namensgebung des Anbieters, der regionalen Verfügbarkeit und der Abrechnungsweise werden sich im Laufe der Zeit ändern. Das Aktualisieren einer Gateway-Richtlinie ist sicherer als das erneute Bereitstellen jeder Anwendung, die die API aufruft.

Klassifizieren Sie Arbeitslasten, bevor Sie die Kapazität auswählen

Der schwierigste Teil ist nicht die Anbieterzuordnung. Es wird entschieden, welche Anfragen welche Stufe verdienen.

Gute Kandidaten für interactive_fast

• Sprachassistenten, bei denen eine Verzögerung das Gespräch unterbricht.
• Kundenorientierter Chat über hochwertige Conversion- oder Bindungspfade.
• Human-in-the-Loop-Operationen, bei denen ein Agent aktiv wartet.
• Produktionsvorfälle, bei denen sich die Latenz direkt auf die Schadensbegrenzung auswirkt.

Gute Kandidaten für interactive_standard

• Interne Copiloten.
• Unterstützen Sie Entwürfe, bei denen ein Mensch normale Reaktionszeiten tolerieren kann.
• Produktfunktionen, bei denen die Reaktionszeit wichtig, aber nicht kritisch ist.

Gute Kandidaten für background_discount

• Nächtliche Zusammenfassung.
• Anreicherung großer Dokumente.
• Offline-Bewertungen.
• Masseneinbettungsaktualisierungen.
• Analysekennzeichnung und Berichtserstellung.

Gute Kandidaten für reserved_capacity

• Kontinuierliche Produktionsauslastung mit hohem Volumen.
• Vertragliche Kunden-Workloads mit vorhersehbaren Durchsatzverpflichtungen.
• Verkehr, der keine Schwankungen zwischen lauten Nachbarn toleriert und ausreichend ausgelastet ist, um eine dedizierte Kapazität zu rechtfertigen.

Eine einfache Richtlinienregel lautet: Erlauben Sie Anrufern nicht, Premium-Kapazität zu wählen, nur weil sie Geschwindigkeit bevorzugen. Erfordern einen deklarierten Arbeitsablauf, eine Mieterberechtigung und einen Budgetrahmen.

Mandanten- und API-Schlüsselberechtigungen erzwingen

Für jeden Mandanten und API-Schlüssel sollte eine zulässige Stufe festgelegt sein. Neue Schlüssel sollten standardmäßig auf Standard- und Hintergrundebenen basieren, nicht auf Premiumebenen.

Beispiel für eine Mieterrichtlinie:

{
  „tenant_id“: „tenant_123“,
  „allowed_gateway_tiers“: [
    „interaktiver_standard“,
    „background_discount“
  ],
  „premium_tier“: {
    „aktiviert“: falsch,
    „monthly_budget_usd“: „0,00“,
    „approval_required“: wahr
  },
  „reserved_capacity“: {
    „aktiviert“: wahr,
    „deployment_pool“: „support-prod-ptu“,
    „allow_spillover_to_standard“: true,
    „spillover_monthly_budget_usd“: „500,00“
  }

Beispiel für eine Überschreibung auf Schlüsselebene:

{
  „api_key_id“: „key_voice_prod“,
  „allowed_gateway_tiers“: [„interactive_fast“],
  „workflow_allowlist“: [„voice_control_loop“],
  „premium_daily_budget_usd“: „75,00“,
  „max_premium_traffic_percent“: 15

Die Richtlinie auf Schlüsselebene verhindert eine versehentliche Erweiterung. Ein Entwickler kann einen für den Sprachverkehr vorgesehenen Schlüssel nicht für ein Massenzusammenfassungsskript verwenden, es sei denn, der Workflow ist ebenfalls zulässig.

Entwerfen Sie Downgrade- und Spillover-Verhalten explizit

Downgrade-Verhalten ist eine Produktentscheidung, nicht nur eine Infrastrukturentscheidung. Wenn Premium- oder bereitgestellte Kapazität nicht verfügbar ist, sollte das Gateway einen von vier Pfaden wählen:

• Mit Standard fortfahren: Nützlich, wenn Verfügbarkeit wichtiger ist als Latenzkonsistenz.
• Warteschlange: Nützlich für Hintergrundjobs und Batch-Workloads.
• Schnell fehlschlagen: Nützlich, wenn eine langsame Antwort schlimmer wäre als keine Antwort, z. B. bei engen Echtzeitschleifen.
• Anrufer bitten, es erneut zu versuchen: Nützlich, wenn der Client es sicher mit einem Backoff und einem beibehaltenen Idempotenzschlüssel wiederholen kann.

Beispielrichtlinie:

downgrade_policy:
  voice_control_loop:
    angefragte_Stufe: interaktive_schnell
    if_fast_unavailable: fail_fast
    Fehlercode: tier_capacity_unavailable
  customer_support_reply:
    angefragte_Stufe: interaktive_schnell
    if_fast_unavailable: continue_on_standard
    record_outcome: herabgestuft
  nightly_document_enrichment:
    angeforderte_Stufe: Hintergrundrabatt
    if_batch_unavailable: Warteschlange
    max_queue_delay_hours: 24
  Contracted_api_customer:
    request_tier: reservierte_Kapazität
    if_reserved_exhausted: Spillover_to_standard
    require_spillover_budget: true

Spillover nicht verbergen. Spillover kann die Verfügbarkeit verbessern, verändert jedoch die Kosten und die SLO-Interpretation. Rechnungen und Analysen sollten die Anforderung der reservierten Kapazität, das Spillover-Ereignis, die tatsächlich genutzte Standardkapazität und den Grund enthalten.

Verknüpfen Sie das Service-Tier-Routing mit der Abrechnung

Ein Gateway kann die Prämienausgaben nicht kontrollieren, wenn die Stufenauswahl nicht Teil des Hauptbuchs ist. Speichern Sie diese Felder für jede Anfrage oder jeden Auftrag:

• Angeforderte Gateway-Stufe.
• Ausgewählte Anbieterstufe oder Kapazitätsklasse.
• Stufenergebnis: ausgewählt, herabgestuft, hochgestuft, in die Warteschlange gestellt, Spillover, abgelehnt.
• Grund für das Ergebnis.
• Mandanten-, API-Schlüssel-, Benutzer- und Workflow-IDs.
• Modellalias und Upstream-Modell oder -Bereitstellung.
• Geschätzte Kosten vor dem Versand.
• Abgerechnete Kosten, nachdem die Anbieternutzung bekannt ist.
• Latenz und Wiederholungsanzahl für synchrone Anfragen.
• Batch-Übermittlungszeit, Abschlusszeit und Ergebnisaufnahmestatus für asynchrone Jobs.

Mit diesen Feldern kann das Gateway die Fragen beantworten, die Finanz- und Ingenieurwesen stellen werden:

• Welche Mieter nutzten diese Woche Premium-Kapazität?
• Welche Arbeitsabläufe verursachten die meisten Prämienausgaben?
• Wie oft wurden Premium-Anfragen auf Standard heruntergestuft?
• Hat interactive_fast die p95-Latenz ausreichend verbessert, um den Aufpreis zu rechtfertigen?
• Wie viel hat die Batchverarbeitung im Hintergrund im Vergleich zur synchronen Standardverarbeitung eingespart?
• Wie viel Standard-Spillover wurde durch die bereitgestellte Kapazität generiert?

Die wichtige Empfehlung: Stellen Sie die tatsächlich genutzte Stufe in Rechnung und zeigen Sie gleichzeitig die angeforderte Stufe für den betrieblichen Kontext an. Andernfalls werden die Mieter entweder von den Kosten überrascht oder hinsichtlich der Servicequalität in die Irre geführt.

Fügen Sie Leitplanken hinzu, damit Premium nicht zum Standard wird

Sobald Teams eine schnellere Stufe entdecken, können sie diese überbeanspruchen. Setzen Sie vor der umfassenden Einführung Grenzen im Gateway.

• Prämienbudget pro Mandant: Feste monatliche und tägliche Obergrenzen.
• Workflow-Genehmigung: Premium nur für benannte Workflows zulässig.
• Traffic-Share-Obergrenze: Beispielsweise dürfen nicht mehr als 10 % der synchronen Anfragen eines Mandanten interactive_fast ohne Genehmigung verwenden.
• Warnung von Standard auf Premium: Warnung, wenn ein Workflow, der normalerweise Standard verwendet, aktualisiert wird.
• Premium-Burn-Rate-Benachrichtigung: Warnung, wenn die prognostizierten Ausgaben den genehmigten Rahmen überschreiten.
• Automatischer Ablauf: Vorübergehende Notfallüberschreibungen sollten ohne manuelle Bereinigung ablaufen.
• Batch-Berechtigungsprüfungen: Blockieren Sie Massenaufträge aus synchronen Premium-Stufen, wenn sie Batch-Kriterien erfüllen.

Leitplanken sollten umkehrbar sein. Während eines Vorfalls muss ein autorisierter Betreiber möglicherweise eine vorübergehende Prämienüberschreibung gewähren. Diese Außerkraftsetzung sollte einen Grund, einen Genehmiger, ein Budget, eine Ablaufzeit und einen Prüfdatensatz haben.

Implementierungssequenz

Eine sichere Einführung beginnt nicht damit, dass überall Premium-Routing aktiviert wird. Beginnen Sie mit der Messung.

1. Schattenstufenklassifizierung hinzufügen

Klassifizieren Sie jede Anfrage einer vorgeschlagenen Gateway-Stufe, aber ändern Sie das Routing noch nicht. Notieren Sie die vorgeschlagene Stufe neben den vorhandenen Latenz-, Kosten- und Workflow-Metadaten. Dies zeigt, wie viel Datenverkehr auf Premium-, Batch- oder reservierte Kapazität verlagert würde, wenn die Richtlinie durchgesetzt würde.

2. Erstellen Sie die Fähigkeitsmatrix

Listen Sie Anbietermechanismen, unterstützte Modelle, Regionen, Grenzwerte, Berichtsfelder und bekanntes Downgrade-Verhalten auf. Behandeln Sie unbekanntes Downgrade-Verhalten als Risiko, bis es getestet wird.

3. Erzwingen Sie Mandantenberechtigungen im Probelaufmodus

Protokollieren Sie, ob jede Anfrage zugelassen, herabgestuft, in die Warteschlange gestellt oder abgelehnt wird. Teilen Sie die Ergebnisse vor der Durchsetzung mit den Produktbesitzern.

4. Aktivieren Sie eine Stufe für eine Kohorte

Wählen Sie einen engen Workflow, z. B. einen Live-Support-Antwortpfad oder einen nächtlichen Zusammenfassungsjob. Aktivieren Sie die entsprechende Gateway-Stufe für eine kleine Mandantenkohorte. Messen Sie die p50-Latenz, die p95-Latenz, die Kosten, die Downgrade-Rate, die Fehlerrate und benutzerbezogene Geschäftsmetriken, sofern verfügbar.

5. Erweitern Sie es nur, wenn die Daten dies unterstützen

Wenn die Premium-Stufe die Latenz, aber nicht die Produktergebnisse verbessert, sollten Sie sie begrenzen. Wenn die Stapelverarbeitung die Kosten senkt, ohne das Produktverhalten zu beeinträchtigen, erweitern Sie sie. Wenn die bereitgestellte Kapazität ungenutzt bleibt, überprüfen Sie die Zusage oder leiten Sie vorhersehbareren Datenverkehr dorthin.

Kompromisse, die explizit gemacht werden müssen

• Premium-Stufen mit niedriger Latenz können die Reaktionsfähigkeit verbessern, sie können jedoch Ratenbegrenzungen aufweisen oder Rampeneinschränkungen auslösen. Sie sind kein Ersatz für die Tarifbegrenzungsgestaltung.
• Bereitgestellte Kapazität verbessert die Vorhersagbarkeit, kann aber bei geringer Auslastung Geld verschwenden. Standard- oder Batch-Kapazität ist möglicherweise besser für Spitzen- oder latenztoleranten Datenverkehr.
• Stapelverarbeitung kann die Token-Kosten senken, verändert jedoch das Produktverhalten, da Antworten asynchron sind und möglicherweise viel später eintreffen.
• Anbieterneutrale Ebenennamen vereinfachen den Anwendungscode, aber das Gateway muss eine aktuelle Funktionsmatrix beibehalten, da Anbieter unterschiedliche Namen, Limits, Abrechnungslinien und Downgrade-Verhalten verwenden.
• Automatisches Downgrade verbessert die Verfügbarkeit, kann jedoch zu SLO- und Abrechnungserwartungen führen, es sei denn, das Gateway zeichnet die tatsächlich verwendete Stufe auf.
• Strikte Mandantenkontrollen verhindern Überraschungsausgaben, aber zu strenge Richtlinien können dringende Produktionsabläufe blockieren, es sei denn, es gibt einen kontrollierten Überschreibungspfad.

Vorhersage: Die Serviceebene wird zu einer erstklassigen Routing-Dimension

Vorhersage: Mit zunehmender Reife der Modell-APIs wird die Serviceebene für das KI-Routing genauso wichtig wie Modellauswahl, Region und Kontextfenster. Die Teams werden nicht nur fragen: „Welches Modell soll dies beantworten?“ Sie werden fragen: „Welches Modell, in welcher Kapazitätsklasse, für welches Mieterbudget, mit welcher Downgrade-Richtlinie?“

Empfehlung: Entwerfen Sie jetzt das Gateway-Ledger und das Richtlinienmodell, sodass neue Anbieterkapazitätsklassen hinzugefügt werden können, ohne den Anwendungscode zu ändern. Auch wenn Sie nur mit Standard und Batch beginnen, verwenden Sie von Anfang an Felder wie requested_gateway_tier, selected_provider_tier und tier_outcome.

Umsetzbare Checkliste

• Definieren Sie nicht mehr als fünf anbieterneutrale Gateway-Ebenen.
• Jeder API-Schlüssel muss angeben, welche Ebenen und Workflows er verwenden darf.
• Erstellen Sie eine Anbieterfähigkeitsmatrix für Premium-, Standard-, bereitgestellte, Batch- und Spillover-Verhalten.
• Erfassen Sie die angeforderte Stufe, die ausgewählte Stufe, das Downgrade- oder Spillover-Ergebnis, die Latenz, die Nutzung und die abgerechneten Kosten.
• Standardmäßige neue Schlüssel für Standard- oder Hintergrundebenen.
• Fügen Sie Premium-Budgets, Traffic-Sharing-Obergrenzen und Benachrichtigungen hinzu.
• Machen Sie das Downgrade-Verhalten pro Workflow explizit.
• Beginnen Sie vor der Durchsetzung mit Schattenmetriken.
• Führen Sie Premium- oder bereitgestellte Kapazitäten zunächst für eine kleine Kohorte aus.
• Erweitern Sie es nur, wenn Latenz, Zuverlässigkeit oder Geschäftskennzahlen die Kosten rechtfertigen.

Schlussfolgerung

Service-Tier-Routing gehört zum AI API-Gateway, da es sich um eine übergreifende Richtlinienentscheidung handelt. Es wirkt sich auf Latenz, Kosten, Kontingente, Mieterberechtigungen, Rechnungen und Betriebserwartungen aus. Anwendungsteams sollten keine anbieterspezifischen Tiernamen oder Bereitstellungsklassen fest codieren, nur um die Dringlichkeit der Arbeitslast auszudrücken.

Ein praktischer Gateway stellt neutrale Ebenen wie interactive_fast, interactive_standard, reserved_capacity und background_discount zur Verfügung. Es ordnet diese Ebenen anbieterspezifischen Mechanismen zu, erzwingt Mieterberechtigungen, zeichnet das tatsächliche Ergebnis auf und macht Premium-Kapazität zu einer absichtlichen Ausnahme und nicht zum Standardpfad.

Verwandte Lektüre

• Ratenbegrenzungsgestaltung vor dem Anbieter 429s
• Dauerhaftes Gateway-Muster für asynchrone Batch-Jobs
• Abrechnung Hauptbuch für Angebot, Reservierung, Abrechnung und Abgleich