Cloudflare промени неприятна, но важна част от AI Gateway: какво се случва, когато доставчик на AI нагоре по веригата отхвърли идентификационни данни на клиент.
Според регистъра на промените на AI Gateway на Cloudflare, POST /ai/run вече връща по-последователни отговори, когато доставчик откаже идентификационни данни. Най-конкретният пример е Google Vertex. Отхвърлени идентификационни данни на Vertex, които преди това произвеждаха отговор HTTP 500, с повторни опити нагоре, сега връщат HTTP 401 с код за грешка на Cloudflare 2009. Cloudflare казва, че приложенията трябва да интерпретират HTTP 401 като невалидни или отхвърлени идентификационни данни на доставчик. За разлика от това, отхвърлянето на доставчик в управляваното от Cloudflare Унифицирано таксуване съответства на HTTP 503.
Това звучи като тясна актуализация на договор за грешка. За екипи, управляващи AI шлюзове, това е повече от това. Лошият ключ на доставчика не трябва да се третира като преходна повреда в инфраструктурата. Когато е така, приложенията се опитват да извършат повторна работа, която не е успешна, резервните системи може да пренасочат трафика по грешна причина и екипите за поддръжка на клиенти трябва да отделят грешките при удостоверяване от нестабилността на доставчика след факта.
Какво се промени в договора за портала
Промяната стандартизира разграничение, което има значение в производството: кой може да поправи грешката.
Ако потребител донесе свой собствен ключ на доставчик и този ключ е невалиден, отменен, с изтекъл срок, липсват правилните разрешения за проекта или е отхвърлен от доставчика, клиентът или администраторът на платформата трябва да поправи идентификационните данни. Връщането на 401 прави това видимо. Той казва на приложението, че удостоверяването е неуспешно на границата на доставчика и че слепите повторни опити е малко вероятно да помогнат.
Преди това, поне за отхвърлени Google идентификационни данни на Vertex, Cloudflare казва, че грешката може да се появи като HTTP 500 и да задейства повторни опити нагоре. Отговор 500 обикновено означава повреда от страната на сървъра или проблем нагоре по веригата, който може да се изчисти сам. Много клиентски библиотеки и обвивки на шлюз третират този клас грешка като възможност за повторен опит. При трафика с изкуствен интелект това може да бъде скъпо, тъй като заявките може да включват дълги подкани, контекст на инструменти или пакетна работа с голям обем.
Новото разделяне също изяснява поведението при унифицирано таксуване. Cloudflare казва, че отхвърлянето на доставчик при Унифицирано таксуване съответства на HTTP 503. Това запазва грешката в семейството наличност на услугата, вместо да я представя като ключов проблем на клиента. За софтуер, който поддържа както донасяне на собствен ключ, така и таксуван трафик чрез шлюз, това разграничение трябва да оформя както правилата за повторен опит, така и съобщенията, насочени към потребителя.
Защо има значение за продуктите на BYOK и дистрибуторите
Актуализацията попада на пазар, където повече платформи с изкуствен интелект смесват таксуван чрез шлюз достъп с предоставени от клиента идентификационни данни. Многомоделен API шлюз за екипи може да насочи една заявка през акаунт на платформа, друга през OpenAI ключ на клиент и трета през Google облачен проект, контролиран от корпоративен купувач. Кодът на състоянието HTTP често е първият сигнал, който контролната равнина вижда, когато нещо се обърка.
За работни потоци BYOK третирането на отхвърлянето на идентификационните данни на доставчика като 401 позволява по-чист оперативен път. Таблото за управление може да маркира идентификационни данни като отхвърлени, да постави на пауза само засегнатия маршрут, да уведоми правилния собственик и да избегне изразходването на бюджет за повторен опит за заявка, която ще бъде неуспешна отново. Освен това помага да се отдели хигиената на ключовете от наличността на модела. Отменените идентификационни данни на Vertex не са същият инцидент като прекъсване на доставчика или събитие за ограничаване на скоростта.
Платформите за дистрибутори и партньори имат подобен проблем, но с по-големи последствия за клиентите. Една AI API платформа за дистрибутори може да управлява ключове, състояние на фактуриране и маршрути на доставчика за много клиенти надолу по веригата. Ако отхвърлените идентификационни данни изглеждат като общи грешки на сървъра, екипите за поддръжка може да докладват за грешна основна причина, да преминат към по-скъп маршрут или да поемат разходи, които трябва да бъдат приписани на неправилно конфигурирани идентификационни данни на клиента.
Следователно практическата промяна не е само в анализирането на грешки. Операторите трябва да преразгледат правилата за повторен опит, етикетите за предупреждение, копието на таблото и класификацията на инциденти. 401 от пътя на шлюза обикновено трябва да спре автоматичните повторни опити на доставчика и да премести проблема в отстраняване на идентификационни данни. 503 при управлявано таксуване все още може да изисква проверки на изправността на доставчика, логика за преодоляване при срив или инцидент на страница за състояние, в зависимост от архитектурата на продукта.
Какво трябва да актуализират разработчиците
Разработчиците, използващи Cloudflare AI Gateway, трябва да проверяват всяка клиентска логика, която обработва грешки на доставчика чрез широки HTTP класове. Ако отговорите 401 в момента се обработват само като проблеми с токена на шлюза, може да се наложи този код да прави разлика между идентификационните данни на Cloudflare на приложението и идентификационните данни на доставчика нагоре по веригата, представени от код за грешка на Cloudflare 2009.
Екипите трябва също да прегледат резервното маршрутизиране. Резервният вариант е полезен, когато доставчикът е недостъпен, претоварен или извън целта за латентност. По-рисковано е, когато първоначалният отказ е проблем с идентификационните данни на клиента. Автоматичното пренасочване на трафика от отхвърлен BYOK маршрут към таксуван от платформата маршрут може да създаде неочаквани такси, нарушения на правилата или промени в обработката на данни. Продуктите с унифициран AI API таксуване трябва да посочват изрично това поведение.
Инструментите за поддръжка също трябва да станат по-прецизни. Полезно състояние на таблото за управление може да каже, че доставчикът е отхвърлил конфигурираните идентификационни данни, да идентифицира засегнатия маршрут на доставчика и да покаже времето на последния отказ. Това е по-възможно за действие от обща грешка нагоре по веригата. За корпоративни клиенти регистрационните файлове за проверка трябва да запазят кода на състоянието, доставчика, препратката към идентификационните данни и решението за маршрутизиране, така че екипите да могат да обяснят дали дадена заявка е неуспешна, дали е направен повторен опит или е преместена към друг път за таксуване.
Какво остава несигурно
Регистърът на промените на Cloudflare идентифицира Google Vertex като конкретен коригиран случай и назовава ElevenLabs в по-широкия контекст на идентификационните данни на доставчика, но публичната бележка не се чете като пълна матрица на всеки доставчик и всяка възможна грешка в идентификационните данни. Операторите на шлюзовете трябва да тестват доставчиците, на които разчитат, вместо да приемат, че всички сценарии с отхвърлен ключ сега се държат идентично.
Има и въпрос относно продуктовия дизайн за платформи, изградени върху AI Gateway: каква част от речника за грешки на Cloudflare трябва да бъде изложен на крайните клиенти? Необработените кодове са полезни за разработчиците, но порталите за дистрибутори често се нуждаят от по-трайна категория, насочена към клиентите, като „отхвърлени идентификационни данни на доставчика“, отделно от „недостъпно таксуване през шлюза“ или „временно недостъпен доставчик“.
По-голямата посока е ясна. Шлюзовете за изкуствен интелект вече не са прости прокси сървъри за моделиране на повиквания. Те са равнини за контрол на политиката и таксуването и малките разлики в семантиката на грешката могат да решат дали системата да направи повторен опит, да се преустанови, да таксува клиент или да поиска от администратор да свърже отново акаунт на доставчик.