Erstellen Sie ein AI API-Kapazitätsbuch, bevor Sie neue Mieter aufnehmen

Warten Sie nicht auf Live-Verkehr, um festzustellen, dass ein neuer Kunde nicht bedient werden kann. Laufzeitdrosseln beantworten eine enge Frage: Soll diese Anfrage jetzt ausgeführt werden? Sie beantworten nicht die kommerzielle Frage, die vor dem Onboarding wichtig ist: Kann dieses Anbieterkonto, dieses Projekt, dieser Arbeitsbereich, diese Region, diese Modellfamilie und dieser Ausgabenrahmen den Mieter unterstützen, den Sie verkaufen möchten?

Ein KI-Kapazitätsbuch API gibt dieser Frage eine konkrete Antwort. Es wandelt Upstream-Grenzwerte in internes Angebot um, subtrahiert Reservierungen, wendet Spielraum an und blockiert die Planerstellung oder Mieteraktivierung, wenn die versprochene Arbeitslast keine glaubwürdige Unterstützungskapazität hat.

Was das Kapazitätsbuch steuert

Ein Kapazitätsbuch ist kein Ersatz für Laufzeitbegrenzung, Abrechnung oder Reaktion auf Vorfälle. Es befindet sich früher im Lebenszyklus: Verkauf, Planentwurf, Mieterbereitstellung, Modellprofilzuweisung und Upgrades.

Das Leserproblem ist spezifisch: KI API Wiederverkäufer und SaaS-Teams können den Zugang schneller verkaufen, als Upstream-Anbieter Quoten genehmigen, offenlegen oder aufrechterhalten können. Ein Kunde kauft möglicherweise einen Plan, der ein Modell, eine Region, eine Latenzstufe oder ein monatliches Volumen verspricht, bevor irgendjemand überprüft hat, ob der entsprechende Upstream-Pool vorhanden ist. Das Ergebnis ist vorhersehbar: 429-Fehler, blockierte Upgrades, Notfallkontingentanfragen, erzwungene Fallback-Modelle und umständliche Kundenkommunikation.

Das Hauptbuch sollte Fragen beantworten wie:

• Können wir diesen Mandanten in dieser Modellfamilie aktivieren, ohne reservierte Unternehmenskapazität zu verbrauchen?
• Kann ein Wiederverkäufer einen Plan erstellen, der 20 Millionen Token pro Monat in einer bestimmten Region verspricht?
• Kann dieser Kunde ein Upgrade von Burst-Zugriff auf zugesicherte Kapazität durchführen?
• Welcher Anbieterpool unterstützt das Versprechen und wann muss diese Annahme überprüft werden?
• Was passiert, wenn das Anbieterlimit kürzlich nicht abgeglichen wurde?

Dies ist besonders wichtig für eine AI API Reseller-Plattform, bei der Downstream-Portale möglicherweise Paketzugriff an viele Kunden verkaufen, während Upstream-Kontingente auf eine kleine Anzahl von Anbieterkonten konzentriert bleiben.

Fakten, auf denen man aufbauen kann

Das Folgende sind sachliche Einschränkungen aus der Anbieterdokumentation und sollten das Design prägen.

• OpenAI dokumentiert API Ratenbeschränkungen auf Organisations- und Projektebene. Die Grenzwerte variieren je nach Modell, können von mehreren Modellfamilien gemeinsam genutzt werden und können über Antwortheader überprüft werden.
• OpenAI dokumentiert die monatlichen Ausgabenkontrollen getrennt von den Ratenlimits. Erzwungene feste Ausgabenlimits können zu 429-Fehlern führen und die Durchsetzung erfolgt möglicherweise nicht sofort.
• OpenAI Admin-APIs unterstützen Organisationsworkflows wie Projektverwaltung, API Schlüsselverwaltung, Ausgabenlimits, Warnungen, Audit-Protokolle und Ratenlimitvorgänge.
• Anthropic dokumentiert einen Admin API Rate Limits API für die Abfrage konfigurierter Organisations- und Arbeitsbereichslimits.
• Anthropic API Antworten enthalten Ratenlimit-Header, die das erzwungene Limit, die aktuelle Nutzung und den Zeitpunkt des Zurücksetzens anzeigen.
• Azure OpenAI-Kontingent wird nach Abonnement, Region, Modell und Bereitstellungstyp in Token-pro-Minute-Einheiten zugewiesen. Bereitstellungen verbrauchen den verfügbaren Kontingentpool.
• In der Azure-Dokumentation wird die Rolle „Cognitive Services Usages Reader“ als minimaler Zugriff zum Anzeigen des verfügbaren Kontingents in einem Abonnement empfohlen.
• Google Cloud-Kontingente beschränken die Menge einer Ressource, die ein Projekt nutzen kann, können häufig angepasst werden und werden über Cloud-Kontingente überwacht. Systemlimits sind behoben.

Diese Fakten implizieren eine Designanforderung: Das Hauptbuch kann die Kapazität nicht als einzelne globale Zahl modellieren. Es muss anbieterspezifische Dimensionen bewahren und gleichzeitig eine normalisierte Zulassungsentscheidung für Ihr eigenes Produkt und Partner API.

Empfohlenes Ledger-Modell

Modellieren Sie die Upstream-Kapazität als erstklassiges Steuerungsebenenobjekt. Ein nützlicher Kapazitätspooleintrag benötigt normalerweise diese Felder:

• Anbieter: openai, anthropic, azure_openai, gemini oder ein anderer Upstream.
• provider_account_id: die Organisation, das Abonnement, das Rechnungskonto oder der Mandant, der das Kontingent besitzt.
• scope: Organisation, Projekt, Arbeitsbereich, Cloud-Projekt, Region, Bereitstellung oder Dienstkonto.
• region: erforderlich für Azure und standortabhängige Arbeitslasten; optional oder global für Anbieter, bei denen die Beschränkungen nicht regional sind.
• model_family: die normalisierte interne Familie, nicht nur die genaue Anbietermodellzeichenfolge.
• deployment_type: Standard, bereitgestellt, Batch, Priorität, Echtzeit oder eine andere Kapazitätsklasse.
• rpm_limit: Anfragen pro Minute, sofern verfügbar.
• tpm_limit: Token pro Minute oder entsprechende Token-Ratenkapazität.
• batch_queue_limit: Jobs in der Warteschlange, Token in der Warteschlange, Dateigröße oder anbieterspezifische asynchrone Kapazität.
• monthly_spend_cap: die feste oder konfigurierte Upstream-Budgetgrenze.
• sellable_fraction: der Prozentsatz der gemessenen Kapazität, der für kommerzielle Verpflichtungen zulässig ist.
• effective_from und effective_until:, damit vorübergehende Quotenerhöhungen nicht zu dauerhaften Annahmen werden.
• Quelle: API, Konsolenbeweis, Genehmigung des Account-Managers, manuelle Überschreibung oder abgeleitet aus Headern.
• last_reconciled_at: für Warnungen zu veralteten Daten und Genehmigungstore.

Dann fügen Sie Reservierungsdatensätze hinzu, die diese Pools nutzen:

• tenant_id oder reseller_customer_id: der Kunde oder nachgelagerte Mieter.
• reservation_class: festgeschrieben, platzfähig, intern, Batch, free_trial oder Notfall.
• model_profile_id: das produktbezogene Bündel von Modellen und Fallbacks.
• required_rpm und required_tpm: die Eintrittsschätzung.
• monthly_volume_commitment: erwartetes monatliches Token-Volumen oder -Ausgaben.
• region_policy: erforderlich, bevorzugt oder uneingeschränkt.
• status: ausstehend, aktiv, herabgestuft, abgelaufen, abgelehnt oder awaiting_provider_quota.
• approved_by und approval_reason: für kommerzielle Ausnahmen.
• review_at: wenn die Kapazität erneut überprüft werden muss.

Es geht nicht darum, jeden Token perfekt vorherzusagen. Es geht darum, Vertriebs- und Onboarding-Entscheidungen so deutlich zu machen, dass sie geprüft, hinterfragt und aktualisiert werden können, bevor Kunden sich darauf verlassen.

Zugangskontrolle unterscheidet sich von Laufzeitdrosselung

Laufzeitdrosselung ist ein Schutz auf Anfrageebene. Es schätzt oder misst den Druck für eine Live-Anfrage und entscheidet, ob diese weitergeleitet, verzögert, herabgestuft oder abgelehnt wird. Das ist notwendig, aber es ist reaktiv.

Zutrittskontrolle ist angebotsseitige Planung. Es entscheidet, ob ein Mandant, ein Reseller-Plan, ein Modellprofil oder ein Upgrade existieren darf. Eine starke Implementierung verbindet Kapazitätsprüfungen mit Partner API Automatisierung, Planvalidierung, Kunden-Onboarding und Administratorgenehmigungen.

Zum Beispiel sollte die Planerstellung bei der Validierung fehlschlagen, wenn der Plan Folgendes verspricht:

• eine Modellfamilie, die keinen zugeordneten Anbieterpool hat;
• eine Region, in der kein Kontingent vorhanden ist;
• eine Latenzstufe, die nur durch Best-Effort-Kapazität unterstützt wird;
• ein zugesagtes Token-Volumen, das größer ist als der verkaufbare Spielraum;
• eine Batch-Stufe, bei der die Warteschlangenlimits unbekannt sind;
• eine Ausgabenverpflichtung, die das Anbieterkonto an seine harte Obergrenze bringen würde.

Dies ist keine kundenseitige Drosselung. Es ist Produktintegrität. Wenn Ihr Gateway es einem Wiederverkäufer ermöglicht, einen Plan zu bewerben, der nicht durch die Anbieterquote abgesichert werden kann, erbt der Laufzeitcode ein Versprechen, das er nicht einhalten kann.

Verkaufbare Kapazität mit Spielraum berechnen

Verkaufen Sie nicht 100 Prozent der Upstream-Nummer. Anbieterlimits können abweichen, Modellfamilien können sich Pools teilen, Wiederholungsversuche verbrauchen zusätzliche Kontingente und der Kundenverkehr kommt nicht gleichmäßig an. Eine praktische Richtlinie stellt nur einen Bruchteil der gemessenen Kapazität als verkaufbar dar.

Eine einfache Formel reicht für den Anfang:

sellable_tpm = provider_tpm_limit * sellable_fraction
available_tpm = sellable_tpm - active_reserved_tpm - pending_reserved_tpm

Wenn ein Anbieterpool 1.000.000 TPM verfügbar macht und Ihre Police 70 Prozent verkauft, stehen nur 700.000 TPM für Zusagen zur Verfügung. Wenn aktive Mandanten 500.000 TPM reservieren und ausstehende genehmigte Deals 100.000 TPM reservieren, beträgt die verbleibende verfügbare TPM 100.000.

Der verkaufbare Anteil sollte je nach Pooltyp variieren:

• Stabiler Pool mit hohem Volumen: 70–80 Prozent können angemessen sein, nachdem die Abstimmung ausgereift ist.
• Neues Anbieterkonto: 50–60 Prozent sind sicherer, bis echter Traffic das Verhalten bestätigt.
• Gemeinsamer Modellfamilienpool: Reduzieren Sie die verkaufbare Kapazität, da nicht verwandte Modellaliase konkurrieren können.
• Manuelle oder veraltete Beweise: Reduzieren Sie die verkaufbare Kapazität oder blockieren Sie neue Verpflichtungen.
• Notfall-Fallback-Pool: Verkaufen Sie ihn nicht als normale Kapazität.

Ausgabenobergrenzen müssen ähnlich behandelt werden. Bei einem festen Ausgabenlimit eines Anbieters handelt es sich um eine Budgetsicherung und nicht um einen Produktkapazitätsplan. Wenn die Upstream-Hard-Obergrenze 50.000 $ pro Monat beträgt, sollte das Gateway einen niedrigeren internen Schwellenwert für die geplante Nutzung reservieren und eine Warnung ausgeben, bevor die Hard-Obergrenze den Produktionsverkehr unterbrechen kann.

Verwenden Sie Reservierungsklassen anstelle von Reservierungen pro Anfrage

Versuchen Sie nicht, während der Zulassung Anbieterkapazität für jede mögliche Anfrage zu reservieren. Das gehört in die Laufzeitdrosselung. Der Kapazitätszugang funktioniert besser mit Reservierungsklassen.

Engagierte Kunden

Engagierte Kunden erhalten explizite Kapazitätsreservierungen. Ihre Pläne sollten erforderliche Modellfamilien, Regionen, Serviceebene, Annahmen zur Token-Rate und Überprüfungstermine angeben. Leerlaufreservierungen reduzieren die Auslastung, machen Versprechen aber glaubwürdig.

Burstable-Kunden

Burstable-Kunden schöpfen aus einem gemeinsamen Pool. Sie können die Kapazität nutzen, wenn sie verfügbar ist, sollten jedoch das verbindliche Onboarding nicht blockieren. Ihre Plansprache, ihr API Status und ihr Abbauverhalten müssen klar sein.

Interne Arbeitslasten

Interne Auswertungen, Support-Tools, Analysejobs und Verwaltungsautomatisierungen sollten eine eigene Reservierungsklasse haben. Andernfalls kann der interne Datenverkehr stillschweigend Kapazität verbrauchen, von der der Vertrieb glaubt, dass sie verfügbar ist.

Batch-Jobs

Die Batch-Kapazität erfordert eine separate Modellierung, da sie möglicherweise durch die Warteschlangengröße, die Jobanzahl, in die Warteschlange gestellte Token, Dateilimits oder Turnaround-Verpflichtungen und nicht nur durch RPM und TPM gesteuert wird.

Kostenlose Testversionen

Kostenlose Testversionen sollten absichtlich eingeschränkte Pools verwenden. Eine kostenlose Testversion sollte keine knappe regionale oder vorrangige Kapazität verbrauchen, es sei denn, dies ist Teil einer bewussten Markteinführungsentscheidung.

Anbieterkapazität nach Zeitplan abgleichen

Das Hauptbuch ist nur dann nützlich, wenn es durch einen Abgleich gespeist wird. Die Steuerungsebenen der Anbieter ändern sich außerhalb Ihres Gateways: Administratoren passen Projekte, Arbeitsbereiche, Bereitstellungen, Ausgabenobergrenzen, Schlüssel, Regionen und Modellverfügbarkeit an. Erstellen Sie geplante Pulls und ereignisgesteuerte Prüfungen nach bekannten Administratoränderungen.

Eine praktische Abgleichsschleife sieht so aus:

1. Für Anbieter sichtbare Limits abrufen, sofern APIs vorhanden sind.
2. Dimensionen in Kapazitätspooldatensätze normalisieren.
3. Vergleichen Sie neue Werte mit dem vorherigen Ledger-Snapshot.
4. Markieren Sie Reservierungen als gefährdet, wenn die Kapazität abnimmt oder verschwindet.
5. Vorübergehende Erhöhungen laufen ab, wenn ihr Beweisfenster endet.
6. Benachrichtigungen auslösen, wenn veraltete Pools immer noch aktive Zusagen unterstützen.
7. Erfassen Sie jede Änderung in einem Audit-Log.

Einige Kapazitätsnachweise werden unvollständig sein. Ein Anbieter kann Grenzwerte über ein API, eine Cloud-Quota-Konsole, Antwortheader oder einen Account-Representative-Workflow offenlegen. Unterstützen Sie all dies als unterschiedliche Beweistypen. Das Hauptbuch sollte Vertrauen und Aktualität zeigen und nicht so tun, als würde jeder Anbieter die gleichen Daten auf der Steuerungsebene ausgeben.

Dies überschneidet sich mit der umfassenderen KI APIKontingentverwaltung, aber das Kapazitätsbuch hat einen engeren Zweck: zu entscheiden, was sicher verkauft oder aktiviert werden kann, bevor der Datenverkehr eintrifft.

Zulassungsschecks zur Einreichung des Produkts

Die Kapazitätszulassung sollte Teil der Arbeitsabläufe sein, in denen Zusagen erstellt werden. Die nützlichsten Prüfungen sind normalerweise diese.

Planerstellungsprüfung

Wenn ein Administrator einen Reseller-Plan erstellt, validieren Sie die beworbenen Modellfamilien, Servicestufen, regionalen Verpflichtungen, das monatliche Volumen, Burst-Annahmen und die Fallback-Richtlinie. Wenn kein Anbieterpool den Plan mit Spielraum unterstützen kann, sollte der Plan Entwurf bleiben oder eine Überschreibung erfordern.

Mandantenaktivierungsprüfung

Wenn ein Kunde bereitgestellt wird, reservieren Sie die entsprechende Kapazitätsklasse. Die Aktivierungsantwort sollte einen Status wie „Aktiv“, „Kontingentgenehmigung ausstehend“, „Zu Fallback herabgestuft“ oder „Blockiert“ offenlegen.

Upgrade-Check

Bevor Sie den Plan eines Mieters erhöhen, führen Sie dieselbe Eintrittsberechnung für die Zielreservierung durch. Wenn die Kapazität nicht ausreicht, sollte das Upgrade zu einer ausstehenden Anfrage werden, die an einen Anbieterkontingent-Workflow gebunden ist.

Modellprofilprüfung

Wenn sich Modellaliase oder Profile ändern, berechnen Sie die Reservierungen neu. Eine harmlos aussehende Alias-Werbung kann Mieter von einem Anbieterpool zu einem anderen verschieben und das Angebotsmodell zerstören.

Regionale Richtlinienprüfung

Validieren Sie für Azure- und standortabhängige Arbeitslasten die Region explizit. Äquivalente Modelle in einer anderen Region erfüllen kein Wohnsitzversprechen, es sei denn, die Kundenrichtlinie erlaubt einen Fallback.

Implementierungsdetails: Zulassungsentscheidungsform

Halten Sie das Zulassungsergebnis maschinenlesbar. Ein Partner API, ein Reseller-Portal oder eine interne Admin-Benutzeroberfläche sollte keine menschlichen Notizen analysieren müssen.

{
  "decision": "approved",
  "tenant_id": "tenant_123",
  "model_profile_id": "profile_support_fast",
  "reservation_class": "committed",
  "backing_pool_id": "pool_azure_eastus_gpt4_standard",
  "required_tpm": 120000,
  "required_rpm": 600,
  "sellable_tpm_before": 700000,
  "reserved_tpm_before": 520000,
  "available_tpm_after": 60000,
  "headroom_policy": "standard_70_percent",
  "evidence_freshness": "fresh",
  "review_at": "2026-11-01T00:00:00Z"
}

Für eine Ablehnung geben Sie einen Grund zurück, auf den ein Produkt-Workflow reagieren kann:

{
  "decision": "blocked",
  "reason_code": "insufficient_regional_tpm",
  "required_region": "eastus",
  "required_tpm": 300000,
  "available_tpm": 90000,
  "recommended_action": "request_provider_quota_increase",
  "fallback_options": [
    "standard_global_pool",
    "lower_volume_plan",
    "pending_activation"
  ]
}

Vermeiden Sie, nur „keine Kapazität“ zurückzugeben. Der Anrufer muss wissen, ob es sich um ein regionales Kontingent, eine Modellverfügbarkeit, veraltete Beweise, eine Gefährdung durch Ausgabenobergrenzen, eine fehlende Bereitstellung oder einen Richtlinienkonflikt handelt.

Prüfen Sie die kommerzielle Entscheidung

Jede Kapazitätsentscheidung sollte überprüfbar sein. Datensatz:

• Wer hat den Mandanten, den Plan oder das Upgrade angefordert?
• Wer hat die Entscheidung genehmigt oder außer Kraft gesetzt?
• Welcher Anbieterpool hat das Versprechen unterstützt;
• welche Headroom-Richtlinie angewendet wurde;
• welche Beweisquelle wurde verwendet;
• wenn die Reservierung abläuft oder überprüft werden muss;
• was sich änderte, wenn ein Mandant herabgestuft oder in einen anderen Pool verschoben wurde.

Das ist bei Vorfällen wichtig. Wenn ein Pool das Kontingent erschöpft, muss das Team wissen, ob das Problem auf unerwarteten Datenverkehr, veraltete Anbieternachweise, eine Überschreibung, eine Modellprofilmigration oder einen Verkaufsplan zurückzuführen ist, der nicht hätte aktiviert werden sollen.

Kompromisse

Ein Kapazitätsbuch erhöht den Betriebsaufwand. Es kann auch Einnahmen ablehnen, bis die Upstream-Quote bestätigt ist. Das ist frustrierend, aber es ist besser, als Pläne zu verkaufen, die unter Last scheitern.

Harte Reservierungen verbessern die Vorhersehbarkeit für hochwertige Mieter, verringern jedoch die Auslastung, wenn Kunden inaktiv sind. Soft-Reservierungen verbessern die Auslastung, erfordern jedoch stärkere Laufzeitkontrollen und klarere kundenorientierte Verschlechterungsregeln.

Regionale Modellierung ist für Azure und standortabhängige Arbeitslasten erforderlich, erschwert jedoch das Fallback-Routing. Ein in einer Region verfügbares Modell erfüllt möglicherweise nicht die Anforderungen eines Mandanten, dessen Daten in einer anderen Region bleiben müssen.

Manuelle Beweise sind manchmal unvermeidlich. Das Risiko besteht nicht darin, dass manuelle Beweise vorhanden sind; Das Risiko besteht darin, es wie eine frische API-abgeleitete Wahrheit zu behandeln. Verwenden Sie Warnungen zu veralteten Daten, Ablaufdaten und Genehmigungsanforderungen.

Hard-Spend-Limits von Anbietern sind nützliche Backstops, können aber den Produktionsverkehr mit 429s unterbrechen. Das Gateway sollte intern alarmieren und reservieren, bevor Upstream-Hardcaps zum Durchsetzungsmechanismus werden.

Was ist eine Empfehlung und was ist eine Vorhersage?

Empfehlungen: Kapazität als Ledger-Objekte modellieren, Anbietergrenzen abgleichen, Headroom anwenden, nach Mandantenklasse reservieren, Zulassungsprüfungen mit Plan- und Mandanten-Workflows verbinden und jede Entscheidung prüfen.

Vorhersagen: Der Kapazitätszugang wird immer wichtiger, da Reseller-Portale, Agenturangebote und SaaS-Mieter-Onboarding zunehmend automatisiert werden. Kunden erwarten eine sofortige Aktivierung, während die Genehmigung von Anbieterkontingenten und die regionale Kapazität uneinheitlich bleiben. Bei Teams, die das Angebot in der Steuerungsebene explizit angeben, kommt es zu weniger Notfalleskalationen als bei Teams, die sich nur auf Laufzeitdrosseln verlassen.

Fakten: Die obigen anbieterspezifischen Aussagen sollten als Fakten aus der aktuellen öffentlichen Dokumentation behandelt werden, aber Anbieter-APIs und Quotensemantik können sich ändern. Überprüfen Sie den Abgleichscode und die Dokumentationslinks regelmäßig.

Umsetzbare Schlussfolgerung

Beginnen Sie mit einem hochwertigen Workflow: Blockieren Sie die Aktivierung fester Mandanten, es sei denn, ein neuer Anbieterpool kann die angeforderte Modellfamilie, Region, Rate und Ausgabenspanne nach Spielraum unterstützen. Fügen Sie dann Planvalidierung, Upgrade-Prüfungen, Warnungen bei veralteten Beweisen und Partner-API-Statusfelder hinzu.

Die minimale nützliche Version ist klein: eine Kapazitätspooltabelle, eine Reservierungstabelle, ein Abstimmungsjob, eine Headroom-Richtlinie und eine Zulassungsentscheidung API. Das reicht aus, um Kapazitäten vom Stammwissen auf die Produktkontrollebene zu verlagern, wo Vertrieb, Support, Betrieb und nachgelagerte Wiederverkäuferportale sehen können, ob ein Versprechen tatsächlich durch das Angebot abgesichert ist.

Verwandte Lektüre

• Laufzeitratenbegrenzungsgestaltung für Live-KI API Datenverkehr