Chybějící metrika mezi tokeny a výdaji na cloud

Problém není v tom, že týmům AI chybí údaje o nákladech. Je v tom, že tokenový přehled a cloudová faktura popisují různé systémy, patřící různým týmům, a neexistuje spolehlivý způsob, jak je propojit.

Podpůrný agent může vyřešit jeden tiket po pěti voláních modelu, kroku načítání, dvou voláních nástroje a opakování. Podnik zaznamená jeden dokončený případ. Infrastruktura zaznamená rozptýlenou řadu požadavků, podů, paměti, času akcelerátorů a sdílených služeb. Dokud se tyto záznamy nespojí, optimalizace nákladů je částečně odhad.

Proč tokenové metriky a cloudové faktury vyprávějí odlišné příběhy?

Počty tokenů jsou užitečné. Ukazují, kolik textu model obdržel a vrátil, a pomáhají týmům porovnávat výzvy, modely nebo rozhodování o směrování. Ale neříkají, co se stalo kolem volání modelu, kolik výpočetního výkonu podpořilo načítání a použití nástrojů, kolik neúspěšných pokusů přišlo dříve, ani zda konečný výsledek byl užitečný.

Zpráva State of FinOps 2026 ukazuje, jak rychle AI pronikla do běžné práce FinOps: 98 % respondentů nyní spravuje výdaje na AI, oproti 63 % v roce 2025. Přesto větší rozpočetová položka neřekne, který pracovní postup peníze spotřeboval a proč. 

Dvě úlohy zpracování dokumentů mohou použít přibližně stejný počet tokenů. Jedna může skončit jedním požadavkem na model. Druhá může načíst kontext z několika úložišť, zavolat externí službu, přejít na jiný model a spustit dokument znovu po neúspěšné kontrole validace, kterou uživatel nikdy nevidí. Součty tokenů vypadají podobně, zatímco cesty provedení jsou odlišné.

Unite.ai již zkoumala, proč token counts don’t automatically represent business value. Dalším krokem je propojit tyto počty s pracovními zatíženími, která je vytvořila. Jinak může tým zlepšit náklad na token, zatímco zhorší náklad na dokončený úkol.

Jak vypadá kompletní řetězec nákladů?

Užitečný řetězec nákladů začíná výsledkem, na kterém podnik záleží. Může se jednat o vyřešený podpůrný případ, zpracovaný dokument, přijatou změnu kódu nebo dokončený pracovní postup agenta. Všechno pod tímto potřebuje identitu, kterou lze sledovat napříč systémem.

Aplikační vrstva poskytuje první spojení. ID požadavku, ID sledování, název pracovního postupu nebo ID konverzace mohou propojit několik operací modelu a nástroje s jedním úkolem. Bez tohoto vlákna vypadají deset souvisejících událostí jako deset nesouvisejících poplatků.

Standardy OpenTelemetry conventions for GenAI agents nabízejí vznikající slovník pro tuto vrstvu. Pokrývají operace, poskytovatele, požadované modely, agenty, konverzace, využití tokenů, provádění nástrojů, chyby a pracovní postupy. Standardy jsou stále označeny jako ve vývoji, takže týmy by je neměly považovat za dokončený univerzální standard. Jsou užitečné, protože konkrétně řeší problém korelace.

Pak přichází infrastruktura. AWS nabízí split cost allocation data for EKS data o rozděleném přidělování nákladů pro EKS, která mohou přiřadit sdílené výpočty a paměťové náklady na Kubernetes pody a zobrazit podrobnosti jako cluster, jmenný prostor, nasazení, uzel, název pracovní zátěže a typ pracovní zátěže. Pro podporované akcelerované instance data také zahrnují rezervace GPU, Trainium a Inferentia.

To je druhá polovina řetězce. Sledování může vysvětlit, co se aplikace pokoušela udělat; alokace v Kubernetes může ukázat, které zdroje práci nesly. Průvodce Unite.ai k deploying and monitoring LLMs on Kubernetes poskytuje širší kontext výroby, včetně přidělování zdrojů, škálování a pozorovatelnosti.

Spojení se nestane náhodou. Týmy potřebují stabilní identifikátor, který vydrží dostatečně dlouho, aby spojil telemetrii aplikace s popisky pracovních zátěží, záznamy alokací nebo jinou mapovací vrstvu. Zákaznická data nepatří do značek Kubernetes. Týmy by měly rozhodnout, které identifikátory s nízkou kardinalitou mohou bezpečně propojit kategorii pracovního postupu, službu nebo funkci se spotřebovanými zdroji.

Jakmile je aplikační kontext nastaven, týmy mohou začít tracking Kubernetes costs by workload sledovat náklady Kubernetes podle pracovních zátěží a propojit jmenný prostor, CPU, paměť a využití GPU zpět k prováděné práci. To stále neříká, zda pracovní postup vytvořil obchodní hodnotu, ale dává infrastrukturní straně výpočtu něco konkrétního, na co se lze odkazovat. 

Kterou jednotkovou metriku by měl podnik důvěřovat?

Neexistuje jediná metrika nákladů na AI, kterou by měl používat každý tým. Náklad na token odpovídá na otázku spotřeby modelu. Náklad na pod odpovídá na otázku alokace infrastruktury. Žádná z nich neřekne produktovému vlastníku, zda funkce stojí za to.

Nejlepší jmenovatel je obvykle nejmenší výsledek, který podnik může jasně definovat a který může produktový tým ovlivnit. Podpůrná operace může sledovat náklad na vyřešený případ. Dokumentový systém může používat náklad na úspěšně zpracovaný soubor, zatímco asistent pro programování může zkoumat náklad na přijatou změnu místo nákladu na návrh.

Úspěch mění výpočet.

Pracovní postup s nízkým nákladem na pokus může být drahý, pokud často selže, spouští opakovanou validaci nebo posílá příliš mnoho případů k lidské revizi. Proto by týmy měly oddělit náklad na pokus od nákladu na dokončení a kde je to možné, náklad na přijatý výsledek. Poslední číslo je často nejužitečnější, protože zahrnuje práci, kterou systém vytvořil, ale podnik nemohl využít.

Systémy agentů to ztěžují, protože jejich cesty se mohou měnit z jednoho běhu na druhý. Analýza Unite.ai o the economics of scaling agentic AI workloads pokrývá směrování, volání nástrojů, opakování a přiřazení na úrovni pracovního postupu. Tyto chování patří do jednotkové metriky, když spotřebovávají zdroje, i když konečný uživatel vidí jen jednu odpověď.

Metrika stále nebude dokonalá. Sdílené služby, kešované výsledky, dávkové úlohy a zpožděné zpracování mohou rozmazat přiřazení. Odhad užitečný pro rozhodování je lepší než falešná přesnost, zejména když ukazuje inženýrům, která vrstva si zaslouží vyšetření.

Kdo vlastní číslo?

Nejtěžší část může být organizační. Týmy ML rozumí voláním modelu a hodnocení. Platformové týmy rozumí pracovním zátěžím a chování clusteru. FinOps rozumí fakturačním údajům a pravidlům alokace. Produktové týmy vědí, který výsledek je důležitý.

Žádný tým nevlastní celý řetězec.

To vytváří předvídatelný spor o tom, čí přehled je správný. Tým ML může ukazovat na nižší využití tokenů, zatímco platformový tým vidí rostoucí hodiny GPU a produktový tým vidí méně dokončených úkolů než předtím. Všechny tři pozorování mohou být současně pravdivá. Sdílená metrika musí vysvětlit vztah mezi nimi.

Funkční výchozí bod je jeden výrobní pracovní postup s jasnou událostí dokončení. Dej mu stabilní identifikátor. Přenášej tento kontext skrze sledování modelu a nástroje, mapuj ho na službu nebo pracovní zátěž běžící v Kubernetes a vyber jeden obchodní jmenovatel. Pak spojte týmy, když se číslo neočekávaně změní.

Tato revize je důležitější než vyleštěný přehled. Náhlý nárůst může pocházet z delších výzev, nové cesty záložního řešení, nevyužité kapacity GPU, změněné politiky automatického škálování nebo produktového rozhodnutí, které posílá více práce skrze AI funkci. Každá příčina patří jinému vlastníku.

Automatizace by měla přijít později. Doporučovací engine může jednat jen na základě štítků a prahových hodnot, které obdrží, a špatný jmenovatel může učinit efektivní systém zbytečným nebo odměnit levný pracovní postup, který uživatelé odmítají. Týmy potřebují dostatečnou sdílenou viditelnost, aby rozlišily chování modelu od návrhu aplikace a alokace infrastruktury, než nechají systém jednat na základě výsledku. Jinak může automatizovaná úprava nákladů snížit kapacitu, zvýšit latenci a přesunout výdaje na méně viditelné místo.

Řetězec nákladů musí být sdílen

Řízení nákladů na AI zůstane roztříštěné, dokud každý tým optimalizuje jen tu vrstvu, kterou vidí. Tokeny, sledování, pody, akcelerátory a faktury nejsou konkurenční měření. Jsou to části stejného řetězce nákladů.

Společnosti, které je propojí, nedostanou dokonalé číslo hned první den. Důležité je, zda tým dokáže sledovat vysokou fakturu zpět k pracovnímu postupu, který ji způsobil, zjistit, co se změnilo, a rozhodnout, zda výsledek ospravedlňoval náklady.