Cloudflare zmieniło sposób, w jaki wykorzystanie AI Gateway pojawia się na miesięcznych fakturach, a korekta ma większe znaczenie operacyjne, niż mogłoby się wydawać na pierwszy rzut oka. We wpisie do dziennika zmian z 1 września firma podała, że ​​miesięczne faktury za użytkowanie pokazują teraz jedną pozycję całkowitego kosztu na model, a nie oddzielne pozycje dla tokenów wejściowych i wyjściowych. Cloudflare poinformowało również, że ujednoliciło nazwy modeli na fakturach i dziennikach przy użyciu spójnego identyfikatora dostawcy/modelu.

Zmiana nie dotyczy faktur za zakupy kredytów AI Gateway. Dotyczy to miesięcznych faktur za użytkowanie: rejestry wykorzystywane przez zespoły finansowe, zespoły ds. platform i sprzedawców do uzgadniania zużycia po przejściu ruchu przez bramę.

Dla klientów, którzy potrzebują jedynie rachunku wysokiego poziomu, nowy format może być łatwiejszy do odczytania. W przypadku zespołów, które obliczają marże, przydzielają koszty sztucznej inteligencji dzierżawcom lub przeprowadzają audyt zestawu tokenów według obciążenia, zmienia się miejsce, w którym musi znajdować się księga szczegółowa. Faktura przestaje być artefaktem księgowym opartym na tokenach, a bardziej podsumowaniem kosztów na poziomie modelu.

Co zmieniło się w rozliczeniach w Cloudflare AI Gateway

Do tej aktualizacji miesięczne faktury za użytkowanie mogły oddzielać opłaty za token wejściowy i token wyjściowy. To rozróżnienie ma znaczenie, ponieważ wielu dostawców modeli wycenia te klasy tokenów w różny sposób. Obciążenie, które wysyła duże podpowiedzi i otrzymuje krótkie odpowiedzi, ma inny profil kosztów niż obciążenie, które wysyła małe podpowiedzi i generuje długie odpowiedzi, nawet jeśli oba są powiązane z tym samym modelem.

Nowa struktura faktur Cloudflare łączy te oddzielne pozycje typu token w jedną linię całkowitego kosztu dla każdego modelu. Praktycznym efektem jest czystsze rozliczenie na poziomie modelu, ale mniej szczegółów na poziomie faktury dotyczących sposobu wygenerowania tego kosztu.

Jednocześnie standaryzacja identyfikatorów modeli w fakturach i dziennikach rozwiązuje inny, ale powiązany problem: dryf aliasów. W systemach wielomodelowych ten sam model może pojawiać się pod nieco innymi nazwami w dziennikach, eksportach rozliczeń, pulpitach nawigacyjnych, raportach klientów i regułach wewnętrznego routingu. Spójny format nazewnictwa dostawców/modeli zmniejsza ryzyko, że zespoły finansowe i inżynieryjne dopasują jeden ciąg w dziennikach użytkowania do nieco innego ciągu na fakturach.

Ta część zmiany jest wyraźnie użyteczna dla każdego, kto korzysta z ujednoliconego rozliczania interfejsu API AI. Jeśli projekt ustawy mówi jedno, a strumień dziennika mówi co innego, uzgadnianie staje się ręcznym mapowaniem. Dzięki standardowym identyfikatorom łatwiej zaufać automatycznym połączeniom, pulpitom nawigacyjnym i oświadczeniom klientów.

Dlaczego szczegółowość faktury ma znaczenie

Trudniejszym kompromisem jest szczegółowość tokenów. Zespoły zajmujące się infrastrukturą AI często potrzebują więcej niż całkowita kwota naliczona za model. Muszą wiedzieć, czy wzrost kosztów wynika z dłuższych monitów, bardziej szczegółowych wyników, zmiany routingu, wzorca braków w pamięci podręcznej, nowej pętli agenta czy integracji z klientem, która zaczęła wysyłać duże pliki jako kontekst.

Wiersz faktury na poziomie modelu może potwierdzić należną kwotę. Samo w sobie nie jest w stanie wyjaśnić zachowania, które spowodowało powstanie ładunku. Wyjaśnienie to musi pochodzić z dzienników, eksportu, danych telemetrycznych bramy lub oddzielnej księgi użytkowania.

Ma to największe znaczenie dla firm, które znajdują się pomiędzy dostawcą modelu a klientem końcowym. Sprzedawcy, wewnętrzne zespoły ds. platform, produkty SaaS z wbudowanymi funkcjami sztucznej inteligencji oraz agencje zarządzające obciążeniami klientów – wszyscy potrzebują możliwej do uzasadnienia alokacji kosztów. Jeśli faktura na ich wyższym szczeblu nie przedstawia już kosztów tokenów wejściowych i wyjściowych w oddzielnych wierszach, muszą zachować to rozróżnienie przed terminem wystawienia faktury.

Ten sam problem dotyczy obciążeń zwrotnych w większych firmach. Zespół finansowy może być zadowolony, że „model X kosztuje tyle”. Menedżer ds. inżynierii może potrzebować informacji, że określony asystent repozytorium, bot wsparcia lub przepływ dokumentów wygenerował niezwykłą liczbę tokenów wyjściowych. To są różne pytania księgowe.

Kogo dotyczy

Bezpośrednimi użytkownikami Cloudflare AI Gateway są bezpośredni odbiorcy. Każdy zespół, dla którego głównym źródłem informacji o rozliczeniach są miesięczne faktury, powinien sprawdzić, czy nowy format nadal obsługuje jego wewnętrzne potrzeby w zakresie raportowania.

Dotkliwość ta jest głębsza dla operatorów bram i sprzedawców interfejsów AI API. Jeśli odsprzedają dostęp do wielu modeli, wystawiają faktury dla klientów lub stosują niestandardowe znaczniki, potrzebują własnych rekordów na żądanie: identyfikator modelu, dostawca, tokeny wejściowe, tokeny wyjściowe, tokeny w pamięci podręcznej, w stosownych przypadkach, cena jednostkowa, zastosowana zniżka, klucz klienta, projekt, najemca i sygnatura czasowa. Bez tej księgi uproszczona faktura wstępna może utrudnić weryfikację rozliczeń na późniejszym etapie.

Programiści tworzący pulpity nawigacyjne stoją w obliczu podobnych dostosowań. Standaryzacja nazw modeli powinna zmniejszyć błędy mapowania, ale tylko wtedy, gdy systemy wewnętrzne przyjmują te same identyfikatory kanoniczne lub utrzymują celową tabelę aliasów.W tym miejscu pulpit nawigacyjny analizy wykorzystania interfejsu API AI staje się czymś więcej niż tylko wygodą raportowania. Staje się miejscem, w którym zapisywane, sprawdzane i wyjaśniane są szczegóły usunięte z faktury.

Dla użytkowników Model Gate i podobnych klientów korzystających z bramki wielu dostawców lekcja jest prosta: nie traktuj faktury od dostawcy jako jedynego źródła prawdy. Ujednolicone fakturowanie jest przydatne właśnie dlatego, że dostawcy w różny sposób formatują, ustalają ceny i eksponują wykorzystanie. Księga na poziomie bramy umożliwia zespołom normalizację tych informacji przed skompresowaniem ich do dowolnego formatu faktury wybranego przez dostawcę.

Zmiana nazwy modelu może być silniejszym sygnałem długoterminowym

Aktualizacja standardowego identyfikatora może przetrwać debatę na temat formatu faktury. Nazewnictwo modeli staje się problemem operacyjnym w stosach AI. Dostawcy weryfikują identyfikatory modeli, platformy chmurowe otaczają ten sam model nazwami specyficznymi dla kanału, bramy wprowadzają aliasy w celu zapewnienia zgodności, a nazwy pinów aplikacji w plikach konfiguracyjnych.

Podczas nadawania nazw dryfom kilka rzeczy zostaje pominiętych. Raporty kosztów dzielą jeden model na wiele wierszy. Kontrole wycofania nie uwzględniają ruchu, który nadal korzysta ze starszego aliasu. Zasady routingu dotyczą jednej nazwy, ale nie innej. Na fakturach klientów znajduje się etykieta, która nie pasuje do dzienników programisty.

Droga Cloudflare w kierunku spójnych identyfikatorów dostawców/modeli odzwierciedla szersze zapotrzebowanie na systemy wyboru modelu AI, które można kontrolować, a nie tylko są wygodne. Przyjazny dla człowieka alias może być nadal przydatny w warstwie aplikacji, ale rozliczenia i logi wymagają stabilnych nazw kanonicznych.

Pozostała niepewność dotyczy tego, ile szczegółowych danych o użytkowaniu klienci Cloudflare zachowają poza fakturą i jak łatwo będą mogli je wyeksportować w celu długoterminowego rozliczenia. Dziennik zmian potwierdza zmiany w fakturze i nazewnictwie, ale nie zawiera odpowiedzi na wszystkie dalsze pytania księgowe sprzedawców lub przedsiębiorstw korzystających z niestandardowych modeli obciążeń zwrotnych.

Praktyczna odpowiedź nie jest skomplikowana, ale jest pilna: przechwytywanie wykorzystania na poziomie tokena przed otrzymaniem faktury miesięcznej, normalizowanie identyfikatorów modeli przy przetwarzaniu i uczynienie księgi wewnętrznej organem odpowiedzialnym za rozliczenia klientów i analizę kosztów. Faktura Cloudflare może być teraz prostsza. Firmy zajmujące się sztuczną inteligencją nie powinny pozwolić, aby ich księgowość stała się mniej precyzyjna.