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

Service-Tier-Routing ist die Richtlinienebene, die entscheidet, ob eine KI-Anfrage Premium-Kapazität mit geringer Latenz, normale On-Demand-Kapazität, reservierten Durchsatz oder vergünstigte asynchrone Verarbeitung verdient. Ohne diese Ebene kodieren Anwendungsteams normalerweise anbieterspezifische Flags, Bereitstellungsnamen und Batch-Endpunkte direkt im Produktcode. Das macht es schwierig, Latenz, Kosten, Kontingent und Abrechnungsverhalten des Mandanten zu steuern.

Das Gateway sollte die Arbeitslastabsicht offenlegen, nicht die Mechanismen des Anbieters. Ein Produktteam sollte in der Lage sein zu sagen „Dies ist eine interaktive Support-Antwort“ oder „Dies ist eine nächtliche Anreicherungsaufgabe“, während das Gateway diese Absicht der richtigen Upstream-Kapazitätsoption zuordnet und aufzeichnet, was tatsächlich passiert ist.

Das Leserproblem: Kapazitätsklassen werden zur Anwendungslogik

Teams, die mehr als einen Modellanbieter verwenden, beginnen oft mit einer einfachen Modellweiterleitung: Senden Sie diese Modell-ID an diesen Anbieter. Das Routing wird schwieriger, wenn Anbieter unterschiedliche Kapazitätsklassen bereitstellen:

• Premium-Anfrageverarbeitung mit geringer Latenz für benutzerorientierte Pfade.
• Standardgemeinsame Kapazität für normalen synchronen Datenverkehr.
• Dedizierte oder bereitgestellte Kapazität für vorhersehbaren Durchsatz.
• Batch- oder asynchrone APIs für latenztolerante Arbeitslasten.
• Spillover-Verhalten, wenn die reservierte Kapazität erschöpft ist.

Wenn jede Anwendung diese Entscheidungen selbst trifft, verliert das Unternehmen die Kontrolle über vier Dinge: Wer darf die Premium-Kapazität nutzen, wie viel kostet sie, was passiert, wenn die Kapazität nicht verfügbar ist, und ob die gewählte Stufe das Produkt ausreichend verbessert hat, um die Ausgaben zu rechtfertigen.

Das praktische Muster besteht darin, eine anbieterneutrale Quality-of-Service-Schicht innerhalb des KI-Gateways API zu platzieren.

Fakten, auf denen man aufbauen kann

Die Details variieren je nach Anbieter, aber mehrere beobachtbare Fakten sprechen für ein Design auf Gateway-Ebene.

• Fakt: Einige Anbieter bieten eine Servicestufe pro Anfrage für die Premium-Verarbeitung an. OpenAI beschreibt den Schnellmodus als Option pro Anfrage unter Verwendung des Parameters service_tier und gibt an, dass dafür im Vergleich zur Standardverarbeitung ein Aufpreis berechnet wird. OpenAI gibt außerdem an, dass die Prioritätsverarbeitung am 30. Juli 2026 in Schnellmodus umbenannt wurde, während sowohl service_tier=priority als auch service_tier=fast für API Anfragen akzeptiert werden.
• Fakt: Die Bearbeitung von Premium-Anfragen ist möglicherweise kein separates Kontingentuniversum. OpenAI weist darauf hin, dass die Ratenbegrenzungen für den Schnellmodus mit anderen Dienststufen geteilt werden und dass ein schneller Anstieg des Datenverkehrs ein Anstiegsratenverhalten auslösen kann, bei dem ein Teil des Datenverkehrs möglicherweise stattdessen an die Standardverarbeitung gesendet wird.
• Fakt: Die Servicestufe kann eine Berichts- und Abrechnungsdimension sein. OpenAI besagt, dass API Kunden Nutzungs-Dashboard-Daten nach Servicestufe und Werbebuchung gruppieren können. Anthropic dokumentiert standard, priority und batch als Service-Stufenwerte in API Nutzungsberichten.
• Fakt: Batch-APIs können die Kosten für asynchrone Arbeit erheblich senken. In der Preisdokumentation von Anthropic heißt es, dass Batch API die asynchrone Verarbeitung großer Mengen mit einem Rabatt von 50 % auf Eingabe- und Ausgabe-Tokens unterstützt. Googles Gemini Batch API-Dokumentation beschreibt große asynchrone Arbeitslasten zu 50 % der Standardkosten, mit Kompromissen bei der Durchlaufzeit, wie z. B. bis zu 24 Stunden für einige großvolumige Aufträge.
• Fakt: Der bereitgestellte Durchsatz ist ein separates Kapazitätsmodell. Microsoft dokumentiert den von Azure OpenAI bereitgestellten Durchsatz als dedizierte Kapazität, im Gegensatz zu Standardbereitstellungen, bei denen die Kapazität gemeinsam genutzt wird und der Durchsatz je nach Bedarf variieren kann. Microsoft dokumentiert außerdem einen Spillover von bereitgestellten Bereitstellungen zu Standardbereitstellungen in derselben Azure OpenAI-Ressource.

Es wird empfohlen, nicht jeden Anbieterbegriff im Anwendungscode widerzuspiegeln. Die Empfehlung besteht darin, diese Mechanismen in geschäftsorientierte Gateway-Ebenen zu normalisieren.

Anbieterneutrale Gateway-Stufen definieren

Beginn Sie mit der Benennung der Ebenen für das Arbeitslastverhalten und nicht für die Terminologie des Anbieters. Eine nützliche erste Taxonomie ist:

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",
  "messages": [...],
  "metadata": {
    "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": "fast",
  "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 Ramp-Limits oder Mieterbudgetregeln an die Standardverarbeitung gesendet wird, muss dies sichtbar sein:

{
  "requested_gateway_tier": "interactive_fast",
  "selected_provider_tier": "standard",
  "tier_outcome": "downgraded",
  "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 die 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 folgende Antwort geben: Welche Kapazitätsmechanismen stehen für ein bestimmtes Modell, eine bestimmte Region, einen bestimmten Mandanten und einen bestimmten Arbeitsablauf zur Verfügung?

Mindestfelder:

• provider
• model_or_deployment
• regions
• 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:
  interactive_fast:
    preferred:
      - provider: openai
        request_params:
          service_tier: fast
      - provider: anthropic
        request_params:
          service_tier: priority
    fallback:
      - gateway_tier: interactive_standard
        allowed_when: policy.allows_standard_downgrade

  background_discount:
    preferred:
      - provider: anthropic
        mode: batch
      - provider: gemini
        mode: batch
    fallback:
      - queue: delayed_retry
        allowed_when: true

  reserved_capacity:
    preferred:
      - provider: azure_openai
        deployment_class: provisioned
    fallback:
      - provider: azure_openai
        deployment_class: standard
        allowed_when: 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 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 Retention-Pfade.
• 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 eine normale Reaktionszeit 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.
• Analytics-Labeling und Berichtserstellung.

Gute Kandidaten für reserved_capacity

• Kontinuierliche Produktionsarbeitslasten mit hohem Volumen.
• Vertraglich vereinbarte Arbeitslasten von Kunden mit vorhersehbaren Durchsatzverpflichtungen.
• Verkehr, der keine Schwankungen zwischen lauten Nachbarn toleriert und ausreichend ausgelastet ist, um 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 Workflow, 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": [
    "interactive_standard",
    "background_discount"
  ],
  "premium_tier": {
    "enabled": false,
    "monthly_budget_usd": "0.00",
    "approval_required": true
  },
  "reserved_capacity": {
    "enabled": true,
    "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.

Downgrade- und Spillover-Verhalten explizit gestalten

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-Arbeitslasten.
• Schnell fehlschlagen: Nützlich, wenn eine langsame Antwort schlimmer wäre als keine Antwort, z. B. bei engen Echtzeitschleifen.
• Aufrufer bitten, es erneut zu versuchen: Nützlich, wenn der Client es mit einem Backoff und einem beibehaltenen Idempotenzschlüssel sicher erneut versuchen kann.

Beispielrichtlinie:

downgrade_policy:
  voice_control_loop:
    requested_tier: interactive_fast
    if_fast_unavailable: fail_fast
    error_code: tier_capacity_unavailable

  customer_support_reply:
    requested_tier: interactive_fast
    if_fast_unavailable: proceed_on_standard
    record_outcome: downgraded

  nightly_document_enrichment:
    requested_tier: background_discount
    if_batch_unavailable: queue
    max_queue_delay_hours: 24

  contracted_api_customer:
    requested_tier: reserved_capacity
    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.

Service-Tier-Routing mit der Abrechnung verbinden

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 Job:

• 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.
• Mandant, 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 Workflows 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 hat die bereitgestellte Kapazität generiert?

Die wichtige Empfehlung: Stellen Sie die tatsächlich verwendete 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 Beschränkungen 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.
• Benachrichtigung von Standard auf Premium: Benachrichtigung, wenn ein Workflow, der normalerweise Standard verwendet, aktualisiert wird.
• Premium-Burn-Rate-Benachrichtigung: Benachrichtigung, 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

Ein sicherer Rollout beginnt nicht damit, dass überall Premium-Routing aktiviert wird. Beginnen Sie mit der Messung.

1. Schattenstufenklassifizierung hinzufügen

Klassifizieren Sie jede Anfrage in eine vorgeschlagene 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. Mandantenberechtigungen im Probelaufmodus erzwingen

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. Eine Stufe für eine Kohorte aktivieren

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 p50-Latenz, p95-Latenz, Kosten, Downgrade-Rate, Fehlerrate und benutzerbezogene Geschäftsmetriken, sofern verfügbar.

5. Nur erweitern, 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, prüfen Sie die Zusage erneut 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 Ratenbegrenzungsgestaltung.
• Die bereitgestellte Kapazität verbessert die Vorhersagbarkeit,aber sie kann 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, aber sie verändert 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,aber es kann SLO- und Abrechnungserwartungen verschwimmen lassen, 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 Servicestufe wird zu einer erstklassigen Routing-Dimension

Vorhersage: Mit zunehmender Reife der Modell-APIs wird die Servicestufe 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, unter 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.
• Erfordern, dass jeder API-Schlüssel angibt, 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.
• Neue Standardschlü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 zuerst Premium- oder bereitgestellte Kapazitäten für eine kleine Kohorte aus.
• Nur erweitern, 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 bereichsü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 praktisches Gateway stellt neutrale Ebenen wie interactive_fast, interactive_standard, reserved_capacity und background_discount bereit. Es ordnet diese Ebenen anbieterspezifischen Mechanismen zu, erzwingt Mandantenberechtigungen, zeichnet das tatsächliche Ergebnis auf und macht Premium-Kapazität zu einer absichtlichen Ausnahme und nicht zum Standardpfad.

Verwandte Lektüre

• Ratenbegrenzungsgestaltung vor Anbieter 429s
• Dauerhaftes Gateway-Muster für asynchrone Stapelverarbeitung jobs
• Abrechnungsbuch für Angebot, Reservierung, Abrechnung und Abgleich