W Cloudflare AI Gateway dodano aliasy modeli, dzięki czemu klienci mogą umieszczać pulę modeli pod jedną nazwą używaną przez aplikacje. Alias może stosować albo uporządkowaną politykę zastępczą, albo inteligentny routing, podczas gdy klienci wysyłają alias jako nazwę modelu przez REST API.

bramy.

Praktyczną zmianą jest oddzielenie identyfikatora modelu, którego żąda aplikacja, od modelu, który ostatecznie obsługuje żądanie. Operatorzy bram mogą zmieniać pulę, zasady routingu lub podstawowe modele bez konieczności ponownego wdrażania każdego klienta korzystającego z aliasu. Cloudflare twierdzi, że aliasy dotyczą poszczególnych bram.

To więcej niż wygoda zmiany nazw modeli. Zapewnia operatorom stabilny interfejs dla aplikacji, a za tym zmienia się dostępność dostawców, wersje modeli i preferencje dotyczące routingu.

Stabilna nazwa zmieniającej się puli modeli

Bez warstwy aliasów aplikacje często zależą od identyfikatorów modelu specyficznych dla dostawcy. Zastąpienie modelu, dodanie ruchu zastępczego lub przeniesienie ruchu do innego dostawcy może zatem wymagać zmian w konfiguracji w kilku usługach. Może także przesyłać do każdego klienta logikę ponawiania prób i wyboru dostawcy.

Wdrożenie Cloudflare przenosi te decyzje do bramy. Dzięki zamówionemu rozwiązaniu awaryjnemu operator może zdefiniować preferowany model i alternatywy do wypróbowania, gdy pierwszy wybór nie może obsłużyć żądania. Inteligentny routing stanowi alternatywę opartą na zasadach, w której brama dokonuje wyboru z puli, zamiast postępować zgodnie z ustaloną sekwencją.

To ustawienie jest szczególnie istotne w przypadku wielomodelowej API bramy dla zespołów. Zespół programistów może nadać aplikacjom trwałą nazwę modelu, jednocześnie zmieniając implementację centralnie. Może także ujednolicić identyfikator używany przez kilka usług wewnętrznych, zmniejszając liczbę migracji modeli, które muszą być koordynowane z właścicielami aplikacji.

Alias pozostaje jednak zależny od bramy. Organizacje korzystające z kilku bram Cloudflare będą musiały oddzielnie zarządzać równoważnymi aliasami, jeśli chcą mieć spójne nazwy i zasady w różnych środowiskach lub jednostkach biznesowych.

Przełączanie awaryjne staje się łatwiejsze, ale obserwowalność staje się trudniejsza

Pule modeli mogą zwiększyć odporność, ponieważ aplikacje nie potrzebują już własnego kodu wyboru dostawcy i kodu rezerwowego. Jeśli operator zmieni uporządkowaną pulę, aplikacja będzie nadal wywoływać ten sam alias. Ten sam mechanizm może wspierać modernizację modelu lub zmianę dostawcy bez zmiany umowy zawartej z klientem.

Jednak stabilne identyfikatory wprowadzają rozróżnienie księgowe, którego operatorzy nie mogą zignorować. Dzienniki i zapisy użycia powinny zawierać zarówno alias żądany przez klienta, jak i model, który faktycznie obsłużył żądanie. W przeciwnym razie żądanie zgłoszone tylko pod aliasem może ukryć różnice w cenie, opóźnieniu, jakości wyjściowej lub obsłudze dostawcy.

Ma to znaczenie w przypadku obciążeń zwrotnych i obsługi klienta w takim samym stopniu, jak debugowanie techniczne. Gdy dwa żądania do tego samego aliasu są obsługiwane przez różne modele, ich koszty i zachowanie mogą się różnić, nawet jeśli konfiguracja klienta nie uległa zmianie. Dlatego płaszczyzna kontroli AI API dla zespołów programistów wymaga atrybucji na poziomie wykonania, a nie tylko zliczeń pogrupowanych według publicznej nazwy modelu.

Ocena staje się także ciągłym zadaniem operacyjnym. Zmiana routingu może mieć wpływ na zachowanie aplikacji bez wdrożenia kodu, dlatego zespoły powinny przetestować poprawki zasad i zachować zapis tego, który model obsłużył każde ocenione żądanie. Alarmowanie powinno odróżniać pomyślne przywrócenie działania od normalnego korzystania z preferowanego modelu, ponieważ powtarzające się przywrócenie działania może wskazywać na problem z dostawcą lub wyczerpaną pojemność.

Konsekwencje dla sprzedawców i operatorów platform

Aliasy są przydatne w przypadku platform publikujących katalog modeli skierowany do klienta. Sprzedawca może ujawnić stabilną nazwę produktu, zastępując przestarzały model, dostosowując skład dostawców lub wprowadzając opcję zastępczą. Może to ograniczyć uciążliwe migracje katalogów i umożliwić operatorowi centralne zarządzanie dostępnością.

Abstrakcja tworzy także pytania dotyczące ujawniania informacji i rozliczeń. Klienci mogą potrzebować informacji, czy alias zawsze odwzorowuje jeden model, wybiera spośród kilku modeli lub zmienia zachowanie w czasie. W przypadku operacji sprzedawców AI API faktury i eksporty użycia powinny sprawić, że wynik routingu będzie wystarczająco jasny, aby pogodzić opłaty klienta z kosztami dostawcy.

Operatorzy powinni także zdecydować, czy budżety, limity stawek i zasady dostępu mają być powiązane z aliasem, modelami bazowymi czy obydwoma. Alias, który może kierować do modeli o znacząco różnych cenach, nie powinien po cichu omijać założeń dotyczących wydatków ustalonych podczas konfiguracji klienta.

Co pozostaje niejasne

Dziennik zmian Cloudflare określa podstawowe zachowanie, ale nie opisuje w tym ogłoszeniu kryteriów decyzyjnych stosowanych przez inteligentny routing. Nie zapewnia także pomiarów wydajności przełączania awaryjnego ani nie wyjaśnia, jak szybko propagują się zmiany aliasów.

Te szczegóły określą, z jaką pewnością zespoły będą mogły używać aliasów w przypadku obciążeń wrażliwych na opóźnienia lub ściśle regulowanych. Na razie natychmiastowe korzyści są oczywiste: aplikacje mogą polegać na stabilnej nazwie modelu, podczas gdy decyzje dotyczące routingu są przekazywane do bramy. Odpowiedni obowiązek jest równie jasny: raportowanie, fakturowanie i audyty muszą być zgodne z modelem, który faktycznie wykonał żądanie, a nie tylko z aliasem dostarczonym przez aplikację.