Защо не разчитате само на ограниченията на разходите на доставчика?

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

Трябва ли оценките преди полет да използват максимални изходни токени или очаквани изходни токени?

За стриктно спазване на бюджета използвайте жетони за максимален изход или друга консервативна горна граница. Очакваният изход е по-добър за прогнозиране, но може да намали бюджета, когато дадена заявка генерира по-дълъг отговор от обикновено.

Какво трябва да се случи, когато бюджет достигне мек лимит?

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

Как трябва да се контролират поточните отговори?

Резервирайте бюджет преди началото на потока, проследете генерираните токени, където е възможно, спрете генерирането, когато резервираният бюджет е изчерпан, и върнете ясна причина за приключване, като например budget_exhausted, така че клиентите да могат да се справят с частичния отговор.

Колко често разходите за шлюз трябва да се съгласуват с данните за фактуриране на доставчика?

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

Как да наложите лимити за разходи за LLM в API Gateway

Ограниченията на разходите на доставчиците са полезни предпазни мерки, но те рядко отговарят на начина, по който една компания действително притежава разходи за LLM. Finance иска ограничения по екип, приложение, среда, клиент, партньор или работен процес. Екипите на платформата трябва да наложат тези ограничения, преди дадена заявка да се разпространи към OpenAI, Anthropic, Gemini, Azure OpenAI или друг доставчик на модели. Правилната контролна точка обикновено е API шлюзът, където всяка заявка може да бъде приписана, оценена, допусната, понижена, блокирана и съгласувана.

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

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

Факт: Големите доставчици предоставят полезни контроли, но работят в граници, определени от доставчика. OpenAI документира месечните API лимити на разходите на ниво организация и проект, заедно с различни грешки за лимити на организация, лимити на проекти, зададени лимити за използване и изчерпани предплатени кредити. Anthropic документира ограниченията за разходите и скоростта на работното пространство и също така предоставя API за извличане на конфигурирани ограничения за организация и работно пространство за вътрешно предупреждение. Google Сигналите за облачен бюджет сами по себе си не ограничават автоматично разходите, докато Google също документира ограничени бюджети за отговарящи на условията услуги, като Gemini API и Платформа на агенти. Квотата на Azure OpenAI се присвоява на абонамент, регион, модел и тип на внедряване в единици токени на минута, а изчисленията на лимита на скоростта могат да включват бърза оценка и максимални токени, не само окончателно таксувани токени.

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

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

Първо дефинирайте модела на бюджетната политика

Започнете с политика, не с код. Един шлюз не може да наложи бюджет, който не е описан точно.

Записът на практическата политика трябва да включва:

Собственик на бюджета: собственик на екип, отдел, клиент, партньор, приложение или работен процес.
Обхват: измеренията, които съответстват на заявки, като team_id, app_id, environment, customer_id и workflow_id.
Интервал за нулиране: дневно, седмично, месечно, период на договора или персонализиран прозорец.
Мек праг: точката, в която шлюзът предупреждава, понижава, намалява дължината на изхода или насочва към по-евтини модели.
Твърд праг: точката, в която некритичният трафик е блокиран.
Разрешени модели: моделите, които този обхват може да използва.
Резервни модели: по-евтини модели или модели с по-нисък капацитет, разрешени след мек праг.
Критичност: дали работното натоварване е критично за производството, насочено към потребителя, вътрешно, партидно или експериментално.
Спешна отмяна: кой може да удължи лимита, за колко време и с каква одитна пътека.
Цели на известията: Slack канал, имейл група, услуга за инциденти, уебкукичка или финансова опашка.

Примерни правила:

{
  "budget_id": "budget_support_prod_monthly",
  "owner_type": "team",
  "owner_id": "customer_support",
  "scope": {
    "team_id": "customer_support",
    "app_id": "support_assistant",
    "environment": "production"
  },
  "currency": "USD",
  "limit": 5000.00,
  "reset_interval": "monthly",
  "soft_threshold_percent": 80,
  "hard_threshold_percent": 100,
  "allowed_models": ["premium-chat", "standard-chat", "economy-chat"],
  "fallback_models": ["standard-chat", "economy-chat"],
  "criticality": "user_facing_production",
  "on_soft_limit": ["notify", "downgrade_model", "reduce_max_output_tokens"],
  "on_hard_limit": ["block_noncritical", "allow_emergency_override"],
  "notification_targets": ["slack:#support-platform", "email:[email protected]"]
}

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

Изпълнението на бюджета зависи от приписването. Ако дадена заявка не може да бъде свързана с обхват на бюджета, шлюзът не може да вземе надеждно решение за допускане.

Изискване вътрешните клиенти да изпращат стабилни метаданни за собственост:

{
  "model": "premium-chat",
  "messages": [...],
  "max_tokens": 1200,
  "metadata": {
    "team_id": "customer_support",
    "app_id": "support_assistant",
    "environment": "production",
    "customer_id": "cust_48291",
    "workflow_id": "ticket_reply_draft"
  }
}

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

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

Приблизителна цена преди изпращане

Оценката преди полет е в основата на прилагането в реално време. Шлюзът оценява максималната вероятна цена, преди да изпрати заявката до доставчик.

Оценителят се нуждае от:

Таблици с ценовите модели за вход, изход, кеширан вход, партида, използване на инструменти, изображения, вграждания или други размери, подлежащи на таксуване.
Токенизатор или логика за оценка на токени за семейство модели.
Бърз брой токени или прогноза.
Заявено max_tokens или максимална изходна дължина.
Предположения за кеша, ако бързото кеширане засяга таксуването.
Специфични за доставчика правила за таксуване за повторни опити, извиквания на инструменти, логически токени, генериране на изображения или мултимодално въвеждане.

Примерен резултат от оценителя:

{
  "request_id": "req_7f1b",
  "budget_scope": "team:customer_support/app:support_assistant/env:production",
  "model": "premium-chat",
  "input_tokens_estimated": 1850,
  "max_output_tokens": 1200,
  "estimated_cost": 0.0845,
  "estimate_basis": "prompt_tokens_plus_max_output_tokens",
  "confidence": "conservative"
}

Препоръка: Отнасяйте се към разходите преди полета като към консервативна оценка за допускане, а не към счетоводна истина. Ако потребителят поиска max_tokens: 4000, резервирайте срещу тази горна граница, дори ако отговорът обикновено спира на 700 токена. Това намалява риска от преразход, но може да отхвърли заявки, които биха били изпълнени в рамките на бюджета. Този компромис е за предпочитане за строг финансов контрол и по-малко привлекателен за проучвателни вътрешни инструменти.

Запазване на бюджет преди изпращане на заявката

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

Поредицата за приемане трябва да бъде:

Удостоверяване на обаждащия се.
Потвърдете метаданните за собственост.
Разрешете приложимата бюджетна политика.
Приблизителна цена на заявката.
Автоматично резервирайте тази прогнозна цена от бюджетния магазин.
Изпращане на заявката до доставчика само ако резервацията е успешна.
Освободете неизползваната резервация след завършване.
Записване на крайно прогнозно или отчетено от доставчика използване.

Магазинът за резервации трябва да поддържа атомарни актуализации. Redis с Lua скриптове, PostgreSQL транзакции или специална услуга за счетоводна книга може да работи. Важното свойство е, че две заявки не могат да изразходват един и същ оставащ бюджет.

Примерен запис на резервация:

{
  "reservation_id": "res_9d42",
  "request_id": "req_7f1b",
  "budget_id": "budget_support_prod_monthly",
  "estimated_cost": 0.0845,
  "state": "reserved",
  "expires_at": "2026-09-28T12:45:00Z"
}

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

Разделете меките от твърдите лимити

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

Меко ограничение на поведение

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

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

Примерни метаданни за отговор с мек лимит:

{
  "budget_scope": "team:customer_support/app:support_assistant/env:production",
  "limit_state": "soft_limit_exceeded",
  "estimated_cost": 0.0310,
  "remaining_budget": 912.44,
  "applied_policy": ["downgrade_model", "reduce_max_output_tokens"],
  "selected_model": "standard-chat"
}

Поведение с твърди ограничения

При твърдия праг шлюзът трябва да блокира некритичен трафик с предвидим договор за грешка.

{
  "error": {
    "type": "budget_limit_exceeded",
    "code": "llm_budget_hard_limit",
    "message": "The budget for this scope has been exhausted.",
    "budget_scope": "team:customer_support/app:support_assistant/env:production",
    "retry_after": "2026-10-01T00:00:00Z",
    "override_required": true
  }
}

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

Изрично обработване на заявките за поточно предаване

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

Работим модел е:

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

Примерно събитие за прекъсване на поток:

{
  "type": "response.completed",
  "finish_reason": "budget_exhausted",
  "budget_scope": "customer:cust_48291/workflow:ticket_reply_draft",
  "estimated_cost": 0.0845,
  "remaining_budget": 0.00
}

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

Излагане на състоянието на бюджета на клиентите

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

Полезните полета включват:

budget_scope
limit_state: нормално, soft_limit_near, soft_limit_exceeded, hard_limit_exceeded
estimated_cost
reserved_cost
final_cost_when_available
remaining_budget
applied_policy
selected_model

За приложни програмни интерфейси (API) на обществени партньори избягвайте изтичане на имена на вътрешни екипи или база на разходите, ако това е чувствително от търговска гледна точка. Вместо това изложете състояние на квота, безопасно за клиента, като remaining_quota, limit_state и retry_after.

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

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

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

Задачата за съгласуване трябва:

Импортиране на данни за използването и разходите на доставчика.
Нормализирайте го в схемата за използване на шлюза.
Съпоставете записите на доставчика с идентификационните номера на заявки за шлюз, когато има такива.
Разпределете несравнимите разходи на доставчика към най-специфичния известен обхват.
Коригирайте бюджетните книги за свръх- или недостатъчно резервиране.
Изпращане на отчети за отклонения по доставчик, модел, екип, приложение и среда.

Използване на нормализирани телеметрични полета за входни токени, изходни токени, модел, доставчик, ID на заявка и статус. Семантичните конвенции на OpenTelemetry GenAI дефинират атрибути за използване на токени, които могат да помогнат за стандартизиране на телеметрията за използване между доставчиците.

Изберете умишлено поведение при отказ при отваряне или отказ при затваряне

Бюджетният магазин става част от пътя на заявката. Това е основната архитектурна цена на прилагането в реално време.

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

Неуспешно отваряне: разрешава заявки и ги маркира за по-късно съгласуване. Това предпазва наличността, но може да преразходи.
Неуспешно затваряне: блокиране на заявки, докато състоянието на бюджета е налично. Това предпазва разходите, но може да наруши производствените работни процеси.
Fail constrained: разрешава само критичен производствен трафик, използва по-евтини модели, прилага ниски ограничения за всяка заявка и блокира експерименти или групови натоварвания.

Препоръка: Използвайте fail constrained за повечето бизнес системи. Критичните производствени работни процеси продължават с намалена експозиция на разходите, докато дискреционните работни натоварвания спират, докато контролната равнина се възстанови.

Контролен списък за внедряване

Дефинирайте бюджетни обхвати и метаданни за собственост.
Свържете API ключове или акаунти за услуги с разрешени обхвати.
Създаване на записи на правила с меки ограничения, твърди ограничения, разрешени модели, резервни варианти, замени и цели за уведомяване.
Изградете ориентиран към доставчика оценител на разходите.
Използване на атомарни бюджетни резервации преди изпращане на доставчика.
Освободете неизползваните резервации след приключване.
Внедрете твърдо ограничени грешки със стабилен договор.
Добавете проследяване на токен за поточно предаване и причини за завършване, съобразени с бюджета.
Изложете състоянието на бюджета чрез вътрешни заглавки или метаданни на отговора.
Поддържайте ограниченията на разходите на доставчика активирани като предпазни мерки.
Съгласувайте оценките на шлюза с ежедневните отчети за използването и разходите на доставчика.
Сигнал за отклонение, неприписан трафик, изчерпани бюджети и използване на замяна.

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

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

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

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

дневник на разходите за LLM на екип