Cloudflare добави малък, но важен контрол към AI Gateway: екипите вече могат да изискват идентификационни данни на доставчик на трета страна, преди заявката да бъде разрешена за изпълнение. Ако шлюзът не намери приложими идентификационни данни, заявката е неуспешна с HTTP 400 вместо връщане към управлявано от Cloudflare Унифицирано таксуване.

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

Какво се промени

Актуализацията на Cloudflare от 14 септември добавя два начина за налагане на новото поведение. На ниво шлюз администраторите могат да активират настройка byok_only. По време на заявка обаждащите се могат да изпратят заглавката cf-aig-no-wholesale, за да предотвратят резервно таксуване на едро за тази заявка.

Когато контролът се прилага и идентификационните данни на доставчика не са налични, AI Gateway връща HTTP 400. Cloudflare казва, че заявките на Workers AI остават разрешени, така че политиката се отнася специално за заявки на доставчици от трети страни, които иначе биха могли да преминат през управляван от Cloudflare идентификационни данни.

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

Защо резервното таксуване е рисковано

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

Доставчик на SaaS, агенция или вътрешен екип на платформа може да обещае, че трафикът на даден наемател се движи само срещу OpenAI, Anthropic, Google или акаунт на друг доставчик на този наемател. Ако вместо това шлюзът тихо използва идентификационни данни на едро, заявката все още може да успее, но търговският смисъл се е променил. Операторът на платформата може да поеме разходите, да ги предаде неправилно или да загуби способността да съпостави потреблението със сметката на доставчика на клиента.

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

Новият контрол на Cloudflare дава на екипите начин да направят този договор изпълним на границата на шлюза. Неуспешната заявка е оперативно досадна, но е по-лесна за отстраняване на грешки, отколкото успешна заявка, която по-късно се появява в грешен разходен център.

Кой е засегнат

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

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

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

Model Gate потребителите се сблъскват със същия основен проблем, когато управляват екипи, API ключове, анализи на използването и достъп, насочен към партньори. Ключът с обхват на клиента не е просто токен за удостоверяване; може да включва режим на таксуване, лимит на разходите, акаунт на доставчик и набор от очаквания за одит. Ако тези значения не се прилагат последователно, таблата за управление на анализите и фактурите могат да се отдалечат от това, което клиентите смятат, че са купили.

Практически последствия

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

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

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

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

Това, което остава неясно

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

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