Лимитът за OpenAI API спира разхода — и може да спре продукцията

За да ограничите месечния разход за OpenAI API, задайте предупреждение преди бюджетния праг и преценете дали да включите принудителен лимит за проект или за цялата организация. Според указанията на OpenAI за разходните лимити предупреждението оставя заявките активни, а при достигнат принудителен праг засегнатите заявки получават HTTP 429.

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

Изберете обхвата на тавана

Организационният лимит обхваща API трафика на всички проекти в организацията. Проектният се прилага само към трафика, чиито разходи се отчитат към съответния проект. Ако експериментална задача и критична услуга са в различни проекти, отделният проектен таван позволява първата да достигне своя праг, без това само по себе си да спре заявките на втората.

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

Поставете предупреждението преди принудителния лимит

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

1. Определете месечната сума и решете дали границата трябва да важи за конкретен проект, или за всички проекти в организацията. Уточнете кои функции ще бъдат засегнати, ако заявките започнат да отказват.
2. Добавете предупреждение под сумата, при която искате употребата да спре. Уговорете кой получава сигнала и кой може да вземе решение за промяна на прага.
3. За организационен таван отворете Organization limits, после Spend и Edit spend limit. За проектен таван отворете Project settings, Limits, Spend и Edit spend limit. Нужни са права за управление на съответните настройки.
4. Въведете Monthly spend limit. Включете Enforce a hard limit само ако искате API заявките да отказват при достигнат отчетен разход, след което запазете настройката.

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

Предвидете малък резерв за отчетения разход

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

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

Разграничете бюджета от скоростта на заявките

Месечният бюджет и ограниченията за натоварване измерват различни неща. Указанията за rate limits описват отделни ограничения за броя заявки и за токените през определен период; достигането на което и да е приложимо ограничение може временно да спре нови заявки. Свободният капацитет по токени не означава, че има свободен капацитет и по брой заявки.

При временен 429 приложението трябва да намали темпото. Ако отговорът съдържа валидна заглавка Retry-After, изчакайте поне посоченото време; ако тя липсва или е невалидна, увеличавайте паузата между опитите и добавете малко случайно отклонение. Ограничете както броя опити, така и общото време за изчакване. Неуспешните опити също се броят към ограниченията за заявки, така че незабавното им повтаряне може да удължи проблема.

Проверете и настройките на използвания SDK, преди да добавите собствен цикъл за повторение. Официалните SDK могат автоматично да повтарят допустими временни грешки, а поведението им при дълъг Retry-After зависи от версията и настройките. Ако приложението повтаря отгоре, включете и тези автоматични опити в общия срок, за да не умножите заявките.

Обработвайте отказа според кода на грешката

Един и същ HTTP статус може да изисква изчакване или намеса в бюджета. Справочникът за грешките на OpenAI разграничава временния rate limit от достигнат проектен или организационен разходен лимит, изчерпан предплатен кредит и отделния одобрен лимит за употреба. Проверявайте error.code, преди да решите дали заявката да бъде повторена.

• Предупреждение за разход: трафикът продължава. Отговорният екип разглежда употребата и решава дали да намали натоварването, или да промени бюджета.
• project_spend_limit_exceeded и organization_spend_limit_exceeded: засегнатите заявки получават 429. Спрете автоматичните повторения, върнете контролирана грешка или отложете задачата и уведомете администратор. Трафикът може да се възстанови след повишаване или премахване на достигнатия лимит и разпространяване на промяната; иначе лимитът се нулира в следващия месечен цикъл.
• Временно ограничение на заявки или токени, включително slow_down: намалете темпото и повторете само в определения срок, като спазите Retry-After, когато присъства. Кодът slow_down може да означава прекалено бързо нарастване на трафика дори преди обичайните прагове за заявки и токени.
• organization_usage_limit_exceeded и credit_balance_exhausted: необходим е съответно по-висок одобрен лимит за употреба или добавяне на кредит. Изчакването и повторението сами няма да възстановят достъпа.

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

Прочетете също:

• DNS през HTTPS във Firefox: максималната защита може да счупи локални адреси
• Shopify или WooCommerce: лесният старт може да излезе по-скъп в България
• Complaion набра €13,5 млн. — автоматизацията спира пред одитора