Brakująca metryka pomiędzy tokenami a wydatkami w chmurze

Problem nie polega na tym, że zespoły AI nie mają danych o kosztach. Chodzi o to, że pulpit tokenów i rachunek za chmurę opisują różne systemy, zarządzane przez różne zespoły, bez niezawodnego sposobu ich połączenia.

Agent wsparcia może rozwiązać jedno zgłoszenie po pięciu wywołaniach modelu, kroku pobierania, dwóch wywołaniach narzędzi i ponownej próbie. Biznes rejestruje jedną zakończoną sprawę. Infrastruktura rejestruje rozproszone żądania, podsy, pamięć, czas przyspieszaczy i usługi współdzielone. Dopóki te zapisy nie zostaną połączone, optymalizacja kosztów jest częściowo zgadywanką.

Dlaczego metryki tokenów i rachunki za chmurę opowiadają różne historie?

Liczby tokenów są przydatne. Pokazują, ile tekstu model otrzymał i zwrócił, oraz pomagają zespołom porównywać zapytania, modele czy wybory routingu. Jednak nie mówią, co wydarzyło się wokół wywołania modelu, ile mocy obliczeniowej wspierało pobieranie i użycie narzędzi, ile nieudanych prób nastąpiło najpierw, ani czy ostateczny wynik był użyteczny.

Raport State of FinOps 2026 pokazuje, jak szybko AI weszło w codzienną pracę FinOps: 98 % respondentów obecnie zarządza wydatkami na AI, w porównaniu z 63 % w 2025 roku. Jednak większa pozycja budżetowa wciąż nie mówi, który przepływ pracy spalił pieniądze i dlaczego. 

Dwa zadania przetwarzania dokumentów mogą używać mniej więcej takiej samej liczby tokenów. Jedno może zakończyć się pojedynczym wywołaniem modelu. Drugie może pobrać kontekst z kilku magazynów, wywołać usługę zewnętrzną, przejść do innego modelu i ponownie uruchomić dokument po nieudanej weryfikacji, której użytkownik nigdy nie widzi. Sumy tokenów wyglądają podobnie, podczas gdy ścieżki wykonania są różne.

Unite.ai już zbadało, dlaczego token counts don’t automatically represent business value. Następnym krokiem jest powiązanie tych liczb z obciążeniami, które je wygenerowały. W przeciwnym razie zespół może poprawić koszt na token, jednocześnie pogarszając koszt na zakończone zadanie.

Jak wygląda pełny łańcuch kosztowy?

Użyteczny łańcuch kosztowy zaczyna się od wyniku, na którym zależy biznesowi. Może to być rozwiązane zgłoszenie wsparcia, przetworzony dokument, zaakceptowana zmiana kodu lub zakończony przepływ pracy agenta. Wszystko poniżej wymaga tożsamości, którą można śledzić w systemie.

Warstwa aplikacji zapewnia pierwsze połączenie. Identyfikator żądania, identyfikator śladu, nazwa przepływu pracy lub identyfikator konwersacji mogą powiązać kilka operacji modelu i narzędzi z jedną jednostką pracy. Bez tego wątku dziesięć powiązanych zdarzeń wygląda jak dziesięć niepowiązanych opłat.

Konwencje OpenTelemetry conventions for GenAI agents oferują rozwijające się słownictwo dla tej warstwy. Obejmują operacje, dostawców, żądane modele, agentów, konwersacje, użycie tokenów, wykonanie narzędzi, błędy i przepływy pracy. Konwencje są nadal oznaczone jako będące w fazie rozwoju, więc zespoły nie powinny traktować ich jako gotowego uniwersalnego standardu. Są przydatne, ponieważ konkretyzują problem korelacji.

Następnie pojawia się infrastruktura. Dane o podziale kosztów dla EKS udostępniane przez split cost allocation data for EKS mogą przypisywać wspólne koszty obliczeniowe i pamięci do podów Kubernetes oraz udostępniać szczegóły takie jak klaster, przestrzeń nazw, wdrożenie, węzeł, nazwa obciążenia i typ obciążenia. Dla obsługiwanych przyspieszonych instancji dane obejmują również rezerwacje GPU, Trainium i Inferentia.

To druga połowa łańcucha. Ślad może wyjaśnić, co aplikacja próbowała zrobić; przydział w Kubernetes może pokazać, które zasoby wykonały pracę. Przewodnik Unite.ai dotyczący deploying and monitoring LLMs on Kubernetes dostarcza szerszy kontekst produkcyjny, w tym przydział zasobów, skalowanie i obserwowalność.

Połączenie nie nastąpi przypadkowo. Zespoły potrzebują stabilnego identyfikatora, który przetrwa wystarczająco długo, aby połączyć telemetrykę aplikacji z etykietami obciążeń, rekordami przydziału lub inną warstwą mapowania. Dane klientów nie powinny znajdować się w tagach Kubernetes. Zespoły powinny zdecydować, które identyfikatory o niskiej kardynalności mogą bezpiecznie łączyć kategorię przepływu pracy, usługę lub funkcję z wykorzystanymi zasobami.

Gdy kontekst aplikacji zostanie ustalony, zespoły mogą rozpocząć tracking Kubernetes costs by workload i połączyć użycie przestrzeni nazw, CPU, pamięci i GPU z wykonywaną pracą. To nadal nie mówi, czy przepływ pracy stworzył wartość biznesową, ale daje stronie infrastruktury obliczeń coś konkretnego, do czego można się odnieść. 

Jaką jednostkową metrykę powinien zaufać biznes?

Nie istnieje jedna metryka kosztowa AI, której powinien używać każdy zespół. Koszt na token odpowiada na pytanie o zużycie modelu. Koszt na pod odpowiada na pytanie o przydział infrastruktury. Żadna z nich nie mówi właścicielowi produktu, czy funkcja się opłaca.

Najlepszy mianownik to zazwyczaj najmniejszy wynik, który biznes może jasno określić i który zespół produktowy może wpływać. Operacja wsparcia może śledzić koszt na rozwiązane zgłoszenie. System dokumentów może używać kosztu na pomyślnie przetworzony plik, podczas gdy asystent programistyczny może analizować koszt na zaakceptowaną zmianę zamiast kosztu na sugestię.

Sukces zmienia rachunek.

Przepływ pracy o niskim koszcie na próbę może być kosztowny, jeśli często się nie udaje, wywołuje powtarzane weryfikacje lub wysyła zbyt wiele zgłoszeń do przeglądu przez człowieka. Dlatego zespoły powinny rozdzielać koszt na próbę od kosztu na ukończenie i, gdzie to możliwe, koszt na zaakceptowany wynik. Ostatnia liczba jest często najbardziej przydatna, ponieważ obejmuje pracę wygenerowaną przez system, której biznes nie mógł wykorzystać.

Systemy agentowe utrudniają to, ponieważ ich ścieżki mogą się zmieniać z jednego uruchomienia na drugi. Analiza Unite.ai dotycząca the economics of scaling agentic AI workloads obejmuje routing, wywołania narzędzi, ponowne próby i przypisywanie na poziomie przepływu pracy. Te zachowania należą do jednostkowej metryki, gdy zużywają zasoby, nawet gdy końcowy użytkownik widzi tylko jedną odpowiedź.

Metryka nadal nie będzie doskonała. Usługi współdzielone, buforowane wyniki, zadania wsadowe i opóźnione przetwarzanie mogą zamazać przypisanie kosztów. Szacowanie przydatne do podejmowania decyzji jest lepsze niż fałszywa precyzja, szczególnie gdy informuje inżynierów, która warstwa wymaga analizy.

Kto jest właścicielem liczby?

Najtrudniejszą częścią może być organizacyjna. Zespoły ML rozumieją wywołania modeli i ich ocenę. Zespoły platformowe rozumieją obciążenia i zachowanie klastra. FinOps rozumie dane rozliczeniowe i zasady przydziału. Zespoły produktowe wiedzą, który wynik ma znaczenie.

Żaden zespół nie posiada pełnego łańcucha.

To tworzy przewidywalny spór o to, czyj pulpit jest prawidłowy. Zespół ML może wskazywać na niższe użycie tokenów, podczas gdy zespół platformowy widzi rosnącą liczbę godzin GPU, a zespół produktowy zauważa mniej zakończonych zadań niż wcześniej. Wszystkie trzy obserwacje mogą być jednocześnie prawdziwe. Wspólna metryka musi wyjaśniać zależność między nimi.

Praktycznym punktem wyjścia jest jeden przepływ produkcyjny z wyraźnym zdarzeniem zakończenia. Nadaj mu stabilny identyfikator. Przenieś ten kontekst przez ślady modelu i narzędzi, zmapuj go na usługę lub obciążenie działające w Kubernetes i wybierz jeden biznesowy mianownik. Następnie zjednocz zespoły, gdy liczba zmieni się nieoczekiwanie.

Ta ocena ma większe znaczenie niż dopracowany pulpit. Nagły wzrost może wynikać z dłuższych zapytań, nowej ścieżki awaryjnej, niewykorzystanej pojemności GPU, zmienionej polityki autoskalowania lub decyzji produktowej, która kieruje więcej pracy przez funkcję AI. Każda przyczyna należy do innego właściciela.

Automatyzacja powinna przyjść później. Silnik rekomendacji może działać jedynie na podstawie otrzymanych etykiet i progów, a nieodpowiedni mianownik może sprawić, że wydajny system wyda się marnotrawny lub nagrodzić tani przepływ pracy odrzucony przez użytkowników. Zespoły potrzebują wystarczającej wspólnej widoczności, aby odróżnić zachowanie modelu od projektowania aplikacji i przydziału infrastruktury, zanim pozwolą systemowi działać na podstawie wyniku. W przeciwnym razie automatyczna korekta kosztów może zmniejszyć pojemność, podnieść opóźnienia i przenieść wydatki w mniej widoczne miejsce.

Łańcuch kosztowy musi być współdzielony

Kontrola kosztów AI pozostanie fragmentaryczna, dopóki każdy zespół optymalizuje wyłącznie warstwę, którą widzi. Tokeny, ślady, podsy, przyspieszacze i faktury nie są rywalizującymi miarami. Są elementami tego samego łańcucha kosztowego.

Firmy, które je połączą, nie uzyskają idealnej liczby od pierwszego dnia. Liczy się to, czy zespół potrafi prześledzić wysoką fakturę do przepływu pracy, który ją spowodował, ustalić, co się zmieniło, i zdecydować, czy wynik uzasadnia koszt.