Cloudflare zmieniło mało efektowną, ale ważną część AI Gateway: co się stanie, gdy zewnętrzny dostawca sztucznej inteligencji odrzuci dane uwierzytelniające klienta.

Według dziennika zmian AI Gateway Cloudflare, POST /ai/run zwraca teraz bardziej spójne odpowiedzi, gdy dostawca odmówi uwierzytelnienia. Najbardziej konkretnym przykładem jest Google Vertex. Odrzucone dane uwierzytelniające Vertex, które wcześniej generowały odpowiedź HTTP 500 przy ponownych próbach, teraz zwracają HTTP 401 z kodem błędu Cloudflare 2009. Cloudflare twierdzi, że aplikacje powinny interpretować HTTP 401 jako nieprawidłowe lub odrzucone dane uwierzytelniające dostawcy. Z kolei odrzucenie dostawcy w zarządzanym przez Cloudflare rozwiązaniu Unified Billing jest mapowane na HTTP 503.

To brzmi jak niewielka aktualizacja umowy o błędzie. Dla zespołów obsługujących bramy AI to coś więcej. Złego klucza dostawcy nie należy traktować jak przejściowej usterki infrastruktury. W takim przypadku aplikacje ponawiają próby działania, które kończą się niepowodzeniem, systemy rezerwowe mogą przesunąć ruch z niewłaściwego powodu, a zespoły obsługi klienta muszą po fakcie oddzielić błędy uwierzytelnienia od niestabilności dostawcy.

Co zmieniło się w umowie bramy

Zmiana ujednolica rozróżnienie, które ma znaczenie w produkcji: kto może naprawić awarię.

Jeśli użytkownik przyniesie własny klucz dostawcy, ale klucz ten jest nieprawidłowy, unieważniony, wygasł, brakuje mu odpowiednich uprawnień do projektu lub został odrzucony przez dostawcę, klient lub administrator platformy musi naprawić dane uwierzytelniające. Zwrócenie 401 sprawia, że ​​jest to widoczne. Informuje aplikację, że uwierzytelnianie nie powiodło się na granicy dostawcy i że ślepe ponowne próby raczej nie pomogą.

Wcześniej, przynajmniej w przypadku odrzuconych Google poświadczeń Vertex, Cloudflare twierdziło, że awaria mogła pojawić się jako HTTP 500 i spowodować ponowne podjęcie prób. Odpowiedź 500 zwykle oznacza awarię po stronie serwera lub problem z serwerem nadrzędnym, który może zniknąć sam. Wiele bibliotek klienckich i opakowań bramek traktuje tę klasę błędów jako możliwą do ponowienia. W ruchu AI może to być kosztowne, ponieważ żądania mogą zawierać długie monity, kontekst narzędzia lub dużą liczbę prac wsadowych.

Nowy podział wyjaśnia również zachowanie ujednoliconych płatności. Cloudflare podaje, że odrzucenie dostawcy w ramach map Unified Billing wynosi HTTP 503. To utrzymuje błąd w rodzinie dostępności usług, zamiast przedstawiać go jako kluczowy problem klienta. W przypadku oprogramowania obsługującego zarówno ruch z własnym kluczem, jak i ruch rozliczany przez bramę, to rozróżnienie powinno mieć wpływ zarówno na reguły ponawiania prób, jak i komunikaty kierowane do użytkownika.

Dlaczego jest to ważne dla BYOK i produktów sprzedawców

Aktualizacja trafia na rynek, na którym coraz więcej platform AI łączy dostęp rozliczany przez bramę z danymi uwierzytelniającymi dostarczanymi przez klienta. Wielomodelowa API bramka dla zespołów może kierować jedno żądanie przez konto platformy, drugie przez klucz OpenAI klienta, a trzecie przez projekt Google w chmurze kontrolowany przez nabywcę korporacyjnego. Kod stanu HTTP jest często pierwszym sygnałem, jaki widzi płaszczyzna sterująca, gdy coś pójdzie nie tak.

W przypadku przepływów pracy BYOK traktowanie odrzucenia danych uwierzytelniających dostawcy jako 401 zapewnia czystszą ścieżkę operacyjną. Panel może oznaczyć dane uwierzytelniające jako odrzucone, wstrzymać tylko trasę, której to dotyczy, powiadomić odpowiedniego właściciela i uniknąć wydawania budżetu na ponowne próby na żądanie, które ponownie zakończy się niepowodzeniem. Pomaga także oddzielić kluczową higienę od dostępności modelu. Unieważnienie danych uwierzytelniających Vertex to nie to samo, co awaria dostawcy lub zdarzenie związane z ograniczeniem szybkości.

Platformy sprzedawców i partnerów mają podobny problem, ale jego konsekwencje są bardziej widoczne dla klientów. Platforma resellerska AI API może zarządzać kluczami, stanem rozliczeń i trasami dostawców dla wielu klientów niższego szczebla. Jeśli odrzucone dane uwierzytelniające wyglądają jak ogólne błędy serwera, zespoły pomocy technicznej mogą zgłosić niewłaściwą przyczynę główną, przejść awaryjnie na droższą trasę lub ponieść koszty, które powinny zostać przypisane źle skonfigurowanym poświadczeniom klienta.

Praktyczna zmiana nie polega zatem tylko na analizie błędów. Operatorzy powinni ponownie przyjrzeć się zasadom ponawiania prób, etykietom alertów, kopii pulpitu nawigacyjnego i klasyfikacji incydentów. Komunikat 401 ze ścieżki bramy powinien zasadniczo zatrzymać automatyczne ponowne próby dostawcy i przenieść problem do rozwiązania problemu dotyczącego poświadczeń. Błąd 503 w przypadku niedostatecznie zarządzanych rozliczeń może nadal wymagać kontroli stanu dostawcy, logiki przełączania awaryjnego lub zdarzenia związanego ze stroną stanu, w zależności od architektury produktu.

Co programiści powinni zaktualizować

Programiści korzystający z Cloudflare AI Gateway powinni sprawdzić dowolną logikę klienta, która obsługuje awarie dostawców, za pomocą ogólnych klas HTTP. Jeśli odpowiedzi 401 są obecnie obsługiwane tylko jako problemy z tokenem bramy, konieczne może być rozróżnienie w kodzie danych uwierzytelniających Cloudflare aplikacji od danych uwierzytelniających dostawcy nadrzędnego reprezentowanych przez kod błędu Cloudflare 2009.

Zespoły powinny także sprawdzić routing zastępczy. Rozwiązanie awaryjne jest przydatne, gdy dostawca jest niedostępny, przeciążony lub przekracza docelowy poziom opóźnienia. Jest to bardziej ryzykowne, gdy pierwotną awarią jest problem z uwierzytelnianiem klienta. Automatyczne przenoszenie ruchu z odrzuconej trasy BYOK na trasę rozliczaną przez platformę może spowodować nieoczekiwane opłaty, naruszenia zasad lub zmiany w obsłudze danych. Produkty z ujednoliconą sztuczną inteligencją API rozliczenia muszą wyraźnie podkreślać to zachowanie.

Narzędzia pomocnicze również powinny stać się bardziej precyzyjne. Przydatny stan pulpitu nawigacyjnego może informować, że dostawca odrzucił skonfigurowane poświadczenia, identyfikować trasę dostawcy, którego dotyczy problem i pokazywać czas ostatniej awarii. Jest to bardziej wykonalne niż ogólny błąd nadrzędny. W przypadku klientów korporacyjnych dzienniki kontrolne powinny zawierać kod stanu, dostawcę, dane uwierzytelniające i decyzję o routingu, aby zespoły mogły wyjaśnić, czy żądanie nie powiodło się, zostało ponowione lub zostało przeniesione do innej ścieżki rozliczeniowej.

Co pozostaje niepewne

Dziennik zmian Cloudflare identyfikuje Google Vertex jako konkretny, poprawiony przypadek i nazywa ElevenLabs w szerszym kontekście poświadczeń dostawcy, ale notatka publiczna nie brzmi jak pełna macierz każdego dostawcy i każdego możliwego niepowodzenia poświadczeń. Operatorzy bram powinni testować dostawców, na których polegają, zamiast zakładać, że wszystkie scenariusze odrzuconych kluczy zachowują się teraz identycznie.

Istnieje również pytanie dotyczące projektowania produktu w przypadku platform zbudowanych na bazie AI Gateway: jaka część słownika błędów Cloudflare powinna być udostępniana klientom końcowym? Surowe kody są przydatne dla programistów, ale portale sprzedawców często wymagają bardziej trwałej kategorii skierowanej do klienta, takiej jak „odrzucone dane uwierzytelniające dostawcy”, oddzielnej od „niedostępne rozliczenia za bramkę” lub „dostawca tymczasowo niedostępny”.

Większy kierunek jest jasny. Bramy AI nie są już prostymi serwerami proxy przekazującymi dla wywołań modeli. Są to płaszczyzny kontroli zasad i rozliczeń, a niewielkie różnice w semantyce błędów mogą zdecydować, czy system podejmie ponowną próbę, przełączy się w tryb awaryjny, obciąży klienta opłatą, czy też poprosi administratora o ponowne połączenie konta dostawcy.