Изградете AI API регистър на капацитета, преди да приемете нови наематели

Не чакайте трафик на живо, за да откриете, че нов клиент не може да бъде обслужен. Дроселите по време на изпълнение отговарят на тесен въпрос: трябва ли тази заявка да се изпълнява точно сега? Те не отговарят на търговския въпрос, който има значение преди включването: може ли този доставчик да поддържа акаунт, проект, работно пространство, регион, моделна фамилия и плик за разходите на наемателя, който ще продадете?

ИИ API регистър на капацитета дава конкретен отговор на този въпрос. Той преобразува лимитите нагоре по веригата във вътрешно снабдяване, изважда резервациите, прилага свободен капацитет и блокира създаването на план или активирането на наемател, когато обещаното работно натоварване няма надежден резервен капацитет.

Какво контролира Capacity Ledger

Книгата за капацитет не е заместител на ограничаване на скоростта на изпълнение, таксуване или реакция при инциденти. Той се намира по-рано в жизнения цикъл: продажби, проектиране на план, осигуряване на наемател, присвояване на профил на модел и надстройки.

Проблемът с четеца е специфичен: AI API дистрибуторите и SaaS екипите могат да продават достъп по-бързо, отколкото доставчиците нагоре по веригата могат да одобрят, изложат или поддържат квота. Клиент може да закупи план, обещаващ модел, регион, ниво на латентност или месечен обем, преди някой да е проверил дали съществува съответният пул нагоре по веригата. Резултатът е предвидим: грешки 429, блокирани надстройки, спешни заявки за квоти, принудителни резервни модели и неудобна комуникация с клиенти.

Главната книга трябва да отговаря на въпроси като:

• Можем ли да активираме този клиент на това семейство модели, без да изразходваме резервиран корпоративен капацитет?
• Може ли дистрибутор да създаде план, който обещава 20 милиона токена на месец в определен регион?
• Може ли този клиент да надстрои от разрушаващ се достъп до ангажиран капацитет?
• Кой пул от доставчици подкрепя обещанието и кога трябва да се прегледа това предположение?
• Какво се случва, ако ограничението на доставчика не е съгласувано наскоро?

Това е особено важно за AI API платформа за дистрибутори, където порталите надолу по веригата могат да продават пакетиран достъп на много клиенти, докато квотата нагоре по веригата остава концентрирана в малък брой акаунти на доставчици.

Факти, около които да се гради

Следните са фактически ограничения от документацията на доставчика и трябва да оформят дизайна.

• OpenAI документи API ограничения на скоростта на ниво организация и проект. Ограниченията варират в зависимост от модела, може да се споделят в семейства модели и могат да се проверяват чрез заглавки на отговора.
• OpenAI документира месечните контроли на разходите отделно от лимитите на ставките. Наложените твърди ограничения на разходите могат да върнат 429 грешки и прилагането може да не е мигновено.
• OpenAI Приложните програмни интерфейси (API) на администратора поддържат организационни работни потоци, като например администриране на проекти, API управление на ключове, лимити на разходите, предупреждения, регистрационни файлове за одит и операции за ограничаване на скоростта.
• Anthropic документира администраторски API ограничения на скоростта API за заявка за конфигурирани ограничения за организация и работно пространство.
• Anthropic API отговорите включват заглавки за ограничение на скоростта, показващи наложеното ограничение, текущо използване и време за нулиране.
• Azure OpenAI квотата се определя по абонамент, регион, модел и тип на внедряване в единици токени на минута. Внедряванията консумират от наличния квотен пул.
• Документацията на Azure препоръчва ролята на Cognitive Services Usages Reader като минимален достъп за преглед на наличната квота в рамките на абонамента.
• Google Облачните квоти ограничават каква част от ресурсите може да използва даден проект, често могат да бъдат коригирани и се наблюдават чрез облачни квоти. Системните ограничения са фиксирани.

Тези факти предполагат изискване за проектиране: счетоводната книга не може да моделира капацитет като едно глобално число. Той трябва да запази специфични за доставчика измерения, като същевременно излага нормализирано решение за допускане до вашия собствен продукт и партньор API.

Препоръчан модел на Ledger

Моделирайте капацитета нагоре по веригата като първокласен обект на контролна равнина. Един полезен запис на пул от капацитет обикновено се нуждае от тези полета:

• доставчик: openai, anthropic, azure_openai, gemini или друг нагоре по веригата.
• provider_account_id: организацията, абонаментът, сметката за таксуване или наемателят, който притежава квотата.
• обхват: организация, проект, работно пространство, облачен проект, регион, внедряване или акаунт за услуга.
• region: се изисква за Azure и работни натоварвания, чувствителни към пребиваването; по избор или глобално за доставчици, където ограниченията не са регионални.
• model_family: нормализираното вътрешно семейство, а не само точния низ на модела на доставчика.
• deployment_type: стандартен, осигурен, партиден, приоритетен, в реално време или друг клас на капацитет.
• rpm_limit: заявки на минута, когато има такива.
• tpm_limit: токени на минута или еквивалентен капацитет на токена.
• batch_queue_limit: поставени на опашка задачи, поставени на опашка токени, размер на файла или специфичен за доставчика асинхронен капацитет.
• monthly_spend_cap: твърдата или конфигурирана граница на бюджета нагоре по веригата.
• sellable_fraction: процентът на измерения капацитет, разрешен за търговски ангажименти.
• effective_from и effective_until: така че временните увеличения на квотите да не се превърнат в постоянни предположения.
• източник: API, доказателство от конзолата, одобрение от мениджъра на акаунта, ръчна отмяна или изведено от заглавки.
• last_reconciled_at: за предупреждения за остарели данни и пропуски за одобрение.

След това добавете записи за резервации, които консумират от тези пулове:

• tenant_id или reseller_customer_id: клиентът или наемателят надолу по веригата.
• reservation_class: ангажиран, разрушаващ се, вътрешен, партиден, free_trial или спешен.
• model_profile_id: продуктовият пакет от модели и резервни варианти.
• required_rpm и required_tpm: прогнозата за прием.
• monthly_volume_commitment: очакван месечен обем или разходи на токени.
• region_policy: задължително, предпочитано или неограничено.
• статус: чакащ, активен, влошен, изтекъл, отхвърлен или awaiting_provider_quota.
• approved_by и approval_reason: за търговски изключения.
• review_at: когато капацитетът трябва да се провери отново.

Въпросът не е да се предвиди перфектно всеки токен. Въпросът е решенията за продажбите и внедряването да бъдат достатъчно ясни, за да могат да бъдат одитирани, оспорвани и актуализирани, преди клиентите да разчитат на тях.

Контролът на достъпа е различен от дроселирането по време на изпълнение

Ограничаването на времето на изпълнение е защита на ниво заявка. Той оценява или измерва натиска за жива заявка и решава дали да изпрати, забави, понижи или отхвърли. Това е необходимо, но е реактивно.

Контролът на допускане е планиране от страната на предлагането. Той решава дали е разрешено съществуването на наемател, план за дистрибутор, профил на модел или надстройка. Силното внедряване свързва проверките на капацитета с Партньор API автоматизация, валидиране на плана, включване на клиенти и одобрения на администратори.

Например, създаването на план трябва да се провали при проверка, ако планът обещава:

• моделно семейство, което няма картографиран набор от доставчици;
• регион, където не съществува квота;
• ниво на забавяне, подкрепено само от капацитет за най-добри усилия;
• обем на ангажиран токен, по-голям от възможността за продажба;
• пакетно ниво, където ограниченията на опашката са неизвестни;
• ангажимент за разходи, който би тласнал акаунта на доставчика близо до твърдата му граница.

Това не е регулиране, обърнато към клиента. Това е целостта на продукта. Ако вашият шлюз позволява на дистрибутор да рекламира план, който не може да бъде подкрепен от квота на доставчика, кодът за изпълнение ще наследи обещание, което не може да спази.

Изчисляване на продаваемия капацитет с височина

Не продавайте 100 процента от броя нагоре по веригата. Ограниченията на доставчиците могат да се променят, семействата на модели могат да споделят пулове, повторните опити изразходват допълнителна квота и клиентският трафик не пристига равномерно. Една практическа политика излага само част от измерения капацитет като продаваем.

Една проста формула е достатъчна, за да започнете:

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

Ако набор от доставчици излага 1 000 000 TPM и вашата политика продава 70 процента, само 700 000 TPM са налични за ангажименти. Ако активните наематели резервират 500 000 TPM, а предстоящите одобрени сделки запазват 100 000 TPM, оставащият наличен TPM е 100 000.

Продаваемата част трябва да варира според типа пул:

• Стабилен пул с голям обем: 70-80 процента може да са разумни, след като съгласуването стане зряло.
• Нов акаунт на доставчик: 50-60 процента е по-безопасно, докато реалният трафик не потвърди поведението.
• Споделен набор от семейство модели: намаляват продаваемия капацитет, тъй като несвързаните псевдоними на моделите могат да се конкурират.
• Ръчни или остарели доказателства: намаляване на продаваемия капацитет или блокиране на нови ангажименти.
• Спешен резервен пул: не го продавайте като нормален капацитет.

Ограниченията на разходите се нуждаят от подобно третиране. Ограничението на твърдите разходи на доставчика е бюджетен предпазен механизъм, а не план за продуктов капацитет. Ако твърдият таван нагоре по веригата е $50 000 на месец, шлюзът трябва да запази по-нисък вътрешен праг за планирано използване и да предупреди, преди твърдият лимит да може да прекъсне производствения трафик.

Използване на резервационни класове вместо резервации на заявка

Не се опитвайте да резервирате капацитет на доставчика за всяка възможна заявка по време на приема. Това принадлежи на дроселирането по време на изпълнение. Допускането на капацитет работи по-добре с резервационни класове.

Ангажирани клиенти

Ангажираните клиенти получават изрични резервации за капацитет. Техните планове трябва да уточняват необходимите фамилии модели, региони, ниво на услугата, допускания за токени и дати за преглед. Неактивните резервации намаляват използването, но правят обещанията надеждни.

Стабилни клиенти

Burstable клиенти теглят от споделен пул. Те могат да използват капацитет, когато е наличен, но не трябва да блокират извършеното включване. Техният език на плана, статус API и поведение при влошаване трябва да са ясни.

Вътрешни натоварвания

Вътрешните оценки, инструментите за поддръжка, задачите за анализ и административните автоматизации трябва да имат собствен клас за резервация. В противен случай вътрешният трафик може безшумно да погълне капацитет, който според продажбите е наличен.

Пакетни задачи

Пакетният капацитет се нуждае от отделно моделиране, тъй като може да се управлява от размера на опашката, броя на заданията, поставените токени, ограниченията на файловете или ангажиментите за изпълнение, а не само от RPM и TPM.

Безплатни изпробвания

Безплатните пробни версии трябва да използват умишлено ограничени групи. Безплатният пробен период не трябва да изразходва ограничен регионален или приоритетен капацитет, освен ако това не е част от умишлено решение за излизане на пазара.

Съгласуване на капацитета на доставчика по график

Главната книга е полезна само ако се захранва от помирение. Нивата на контрол на доставчиците се променят извън вашия шлюз: администраторите коригират проекти, работни пространства, внедрявания, ограничения на разходите, ключове, региони и наличност на модели. Създайте планирани изтегляния и проверки, управлявани от събития, след известни администраторски промени.

Една практическа верига за съгласуване изглежда така:

1. Извличане на видими от доставчика ограничения, където съществуват API.
2. Нормализиране на измеренията в записи на пул от капацитет.
3. Сравнете новите стойности с предишната моментна снимка на счетоводната книга.
4. Маркиране на резервации като риск, ако капацитетът е намалял или изчезнал.
5. Изтичащи временни увеличения, когато изтече прозорецът им за доказателства.
6. Изпращайте предупреждения, когато остарелите пулове все още поддържат активни ангажименти.
7. Записвайте всяка промяна в журнал за проверка.

Някои доказателства за капацитет ще бъдат несъвършени. Доставчикът може да разкрие ограничения чрез API, конзола за облачна квота, заглавки на отговор или работен процес на представител на акаунт. Подкрепете всички тези като различни видове доказателства. Книгата трябва да показва увереност и свежест, а не да се преструва, че всеки доставчик излъчва едни и същи данни от контролната равнина.

Това се припокрива с по-широкото AI API управление на квотите, но регистърът на капацитета има по-тясна цел: решаване какво може безопасно да се продаде или активира, преди да пристигне трафик.

Проверки за достъп, които да поставите в продукта

Допускането на капацитет трябва да бъде част от работните процеси, където се създават обещания. Най-полезните проверки обикновено са тези.

Проверка за създаване на план

Когато администратор създаде план за дистрибутор, потвърдете рекламираните семейства модели, нива на обслужване, регионални ангажименти, месечен обем, допускания за пакети и резервна политика. Ако нито един набор от доставчици не може да поддържа плана с капацитет, планът трябва да остане чернова или да изисква отмяна.

Проверка за активиране на клиента

Когато даден клиент е предоставен, резервирайте съответния клас капацитет. Отговорът за активиране трябва да показва състояние като активен, чакащ одобрение на квота, понижен до резервен или блокиран.

Проверка за надстройка

Преди да увеличите плана на наемател, извършете същото изчисление за допускане спрямо целевата резервация. Ако капацитетът е недостатъчен, надстройката трябва да стане чакаща заявка, свързана с работен поток от квота на доставчика.

Проверка на профила на модела

Ако псевдонимите на модела или профилите се променят, преизчислете резервациите. Безобидна промоция с псевдоним може да премести наематели от един пул доставчици в друг и да наруши модела на предлагане.

Проверка на регионалната политика

За Azure и работни натоварвания, чувствителни към пребиваване, валидирайте региона изрично. Еквивалентни модели в друг регион не отговарят на обещанието за пребиваване, освен ако клиентската политика не позволява резервен вариант.

Подробности за внедряване: Форма за решение за приемане

Поддържайте резултата от приема машинно четим. Партньор API, портал за дистрибутори или вътрешен администраторски потребителски интерфейс не трябва да анализира човешки бележки.

{
  "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"
}

За отхвърляне върнете причина, по която работният поток на продукта може да действа:

{
  "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"
  ]
}

Избягвайте да връщате само „без капацитет“. Обаждащият се трябва да знае дали проблемът е регионална квота, наличност на модела, остарели доказателства, излагане на ограничение на разходите, липсващо внедряване или конфликт на правила.

Одит на търговското решение

Всяко решение за капацитет трябва да подлежи на проверка. Запис:

• който е поискал наемателя, плана или надстройката;
• кой е одобрил или отменил решението;
• кой пул от доставчици подкрепи обещанието;
• коя политика за запас е приложена;
• кой източник на доказателства е използван;
• когато резервацията изтече или трябва да бъде прегледана;
• какво се променя, ако даден наемател бъде понижен или преместен в друг пул.

Това има значение по време на инциденти. Ако пулът изчерпи квотата, екипът трябва да знае дали проблемът идва от неочакван трафик, остаряло доказателство за доставчик, отмяна, миграция на профил на модел или план за продажби, който не е трябвало да бъде активиран.

Компромиси

Книгата за капацитет добавя оперативни разходи. Може също така да отхвърли приходите, докато не бъде потвърдена квотата нагоре по веригата. Това е разочароващо, но е за предпочитане пред продажбата на планове, които се провалят при натоварване.

Твърдите резервации подобряват предвидимостта за наемателите с висока стойност, но намаляват използването, когато клиентите не работят. Меките резервации подобряват използването, но изискват по-силен контрол по време на изпълнение и по-ясни правила за влошаване, насочени към клиента.

Регионалното моделиране е необходимо за Azure и работни натоварвания, чувствителни към пребиваването, но усложнява резервното маршрутизиране. Модел, наличен в един регион, може да не задоволи наемател, чиито данни трябва да останат в друг регион.

Ръчните доказателства понякога са неизбежни. Рискът не е, че съществуват ръчни доказателства; рискът е да го третираме като свежа истина, получена от API. Използвайте предупреждения за остарели данни, дати на изтичане и изисквания за одобрение.

Ограниченията на твърдите разходи на доставчика са полезни предпазни мерки, но те могат да прекъснат производствения трафик с 429s. Шлюзът трябва да предупреждава и резервира вътрешно, преди твърдите ограничения нагоре по веригата да се превърнат в механизъм за прилагане.

Какво е препоръка и какво е прогноза?

Препоръки: моделиране на капацитета като обекти на счетоводна книга, съгласуване на лимитите на доставчиците, прилагане на свободен капацитет, резервиране по клас на наемател, свързване на проверките за допускане към планиране и работни потоци на наемател и проверка на всяко решение.

Прогнози: допускането на капацитет ще стане по-важно, тъй като порталите за дистрибутори, офертите на агенциите и включването на SaaS наематели стават по-автоматизирани. Клиентите ще очакват незабавно активиране, докато одобренията на квотите на доставчика и регионалния капацитет ще останат неравномерни. Екипите, които правят доставката изрично в контролната равнина, ще имат по-малко спешни ескалации, отколкото екипите, които разчитат само на дросели по време на изпълнение.

Факти: специфичните за доставчика твърдения по-горе трябва да се третират като факти от текущата публична документация, но API на доставчика и семантиката на квотите могат да се променят. Преглеждайте кода за съгласуване и връзките към документацията.

Приложимо заключение

Започнете с един работен процес с висока стойност: блокирайте ангажираното активиране на наемател, освен ако нов пул от доставчици не може да поддържа исканото семейство модели, регион, тарифа и обхвата на разходите след запас. След това добавете валидиране на плана, проверки за надграждане, предупреждения за остарели доказателства и полета за статус на партньор API.

Минималната полезна версия е малка: маса за билярд с капацитет, маса за резервации, задача за съгласуване, политика за капацитет и решение за допускане API. Това е достатъчно, за да премести капацитета от племенните знания в равнината за контрол на продуктите, където продажбите, поддръжката, операциите и порталите за дистрибутори надолу по веригата могат да видят дали дадено обещание действително е подкрепено от доставка.

Свързано четене

• оформяне на ограничение на скоростта на изпълнение за жив AI API трафик