OpenRouter přidal ovládací panel aktivity a rozhraní Analytics API pro zákazníky, kteří potřebují pochopit, odkud pocházejí využití modelu a náklady. Vydání, které bylo oznámeno 17. srpna, poskytuje týmům rozdělení podle dimenzí, jako je agent, aplikace, člen týmu, klíč API, model, poskytovatel a pracovní prostor.
To může znít jako funkce vytváření přehledů. V praxi je to známka toho, že analytika využití AI se stává základní součástí infrastruktury AI spíše než administrativním doplňkem. Vzhledem k tomu, že společnosti přecházejí od experimentů s jedním chatbotem k více agentům, kódovacím nástrojům, interním aplikacím a automatizacím orientovaným na zákazníky, jedna celková útrata již nestačí. Týmy potřebují vědět, který pracovní postup vygeneroval účet, který model byl použit, jak moc pomohlo ukládání do mezipaměti a zda se po rozhodnutí o směrování změnila latence nebo propustnost.
OpenRouter říká, že nový produkt zahrnuje metriky, jako je útrata, počet požadavků, objem tokenů, míra přístupu do mezipaměti, smíšená cena za milion tokenů, percentily latence a percentily propustnosti. Také říká, že rozhraní Analytics API obsahuje metadata a koncové body dotazů a vyžaduje klíč pro správu.
Co se změnilo
Nejdůležitější změnou není jen to, že OpenRouter přidal grafy. Jde o to, že společnost odhaluje využití a analýzu nákladů na úrovni blíže tomu, jak jsou moderní systémy umělé inteligence ve skutečnosti stavěny.
V mnoha organizacích již není jednotkou práce umělé inteligence uživatel, který píše do okna chatu. Může to být agent, který zasílá žádosti o stažení, úloha sumarizace na pozadí, asistent prodeje začleněný do CRM, pracovní postup podpory, proces čištění dat nebo partnerská aplikace postavená na bráně. Každý může volat různé modely, prostřednictvím různých poskytovatelů, pod různými klíči API, s různým chováním v mezipaměti a požadavky na latenci.
Podporou atribuce napříč agenty, aplikacemi, členy týmu, klíči API, modely, poskytovateli a pracovními prostory OpenRouter uznává, že řízení nákladů na AI závisí na kontextu. Vysoký účet z jednoho modelu může být přijatelný, pokud patří do pracovního postupu zákazníka, který generuje příjmy. Stejný účet z interního experimentu může vyžadovat omezení rozpočtu. U živého produktu může být špička latence důležitá, ale pro noční dávkový proces je irelevantní. Nízká kombinovaná cena za milion tokenů může skrývat slabé využití mezipaměti nebo záložní cestu, která tiše přesunula požadavky na dražší model.
Proč je to důležité pro brány a týmy platforem
Pro bránu AI API je směrování jen polovinou práce. Jakmile může brána odesílat požadavky více modelům a poskytovatelům, zákazníci potřebují důkaz, že rozhodnutí o směrování fungují. Důkazem je pozorovatelnost: požadavky, tokeny, výdaje, latence, chování mezipaměti a vzorce selhání svázané s týmy a aplikacemi, které je generovaly.
Nové uvedení OpenRouteru zvyšuje konkurenceschopnost infrastruktury pro více modelů. Vývojáři a finanční týmy pravděpodobně očekávají rozbory podle klíče API a modelu. Platformové týmy budou chtít pohledy na úrovni pracovního prostoru a na úrovni členů týmu. Tvůrci agentů budou chtít přiřazení pro jednotlivé agenty, protože jinak se z autonomních pracovních postupů mohou stát nevlastněná nákladová střediska. Partneři a prodejci budou chtít přístup k analýze pomocí rozhraní API, aby mohli vkládat hlášení o využití do svých vlastních panelů.
To je zvláště důležité pro platformy, jako je Model Gate, kde jsou součástí povrchu produktu sjednocená fakturace, správa klíčů API, týmové kontroly, analýzy využití a rozhraní API pro partnery. Pokud zákazníci provozují mnoho navazujících služeb prostřednictvím jednoho rozhraní kompatibilního s OpenAI, brána musí odpovědět více než „kolik jsme utratili?“ Musí odpovědět „kdo to utratil, prostřednictvím kterého klíče, na kterém modelu, pro kterou aplikaci, s jakou latencí a s jakou účinností mezipaměti?“
Toto očekávání také mění způsob, jakým produktové týmy navrhují klíče API. Klíče nejsou jen přihlašovací údaje; jsou to atribuční hranice. Pokud každý pracovní postup sdílí jeden klíč, analytika bude méně užitečná. Pokud se klíče mapují na prostředí, týmy, agenty nebo zákazníky, řídicí panely a rozhraní API se mohou stát praktickým nástrojem pro správu a fakturaci.
Praktické důsledky pro vývojáře a firmy
Vývojáři by to měli považovat za výzvu k přehodnocení značkování, struktury klíčů a postupů protokolování. Analýza pro jednotlivé agenty funguje pouze v případě, že lze požadavky přidružit ke správnému agentovi nebo aplikaci. Týmy vytvářející interní platformy AI mohou potřebovat konvence pro metadata, oddělení pracovního prostoru a klíče specifické pro prostředí. Bez těchto konvencí může i silný analytický produkt vytvářet nejednoznačné zprávy.
Finanční a provozní týmy by také měly věnovat pozornost metrikám mezipaměti a kombinovaným nákladům na milion tokenů. Vzhledem k tomu, že poskytovatelé zavádějí složitější cenové modely, včetně slev uložených v mezipaměti a sazeb specifických pro daný model, hrubý objem tokenů nestačí k vysvětlení účtu.Pracovní postup, který odesílá mnoho tokenů, může být efektivní, pokud jsou četnosti přístupů do mezipaměti vysoké. Jiný s nižším objemem může být drahý, pokud opakovaně vynechává mezipaměť, zbytečně používá prémiové modely nebo spouští nouzová řešení.
Procentily latence a propustnosti jsou stejně důležité. Průměrná latence může skrýt chování ocasu, které poškozuje produkty orientované na uživatele. Percentilové pohledy pomáhají týmům pochopit, zda je model většinu času rychlý, ale nespolehlivý při zatížení, nebo zda je poskytovatel vhodný pro interaktivní použití oproti dávkovému zpracování. U směrovacích systémů mohou tato data sloužit k rozhodování o zásadách: ponechat si levný model pro úlohy na pozadí, rezervovat rychlejší nebo dražší možnosti pro cesty k zákazníkům a upozornit, když se výkon sníží.
Pro agentury, tvůrce SaaS a další společnosti využívající model partnera nebo prodejce může být rozhraní Analytics API důležitější než řídicí panel. Hlášení přístupné pomocí API umožňuje vytvářet uživatelské stránky pro zákazníky, upozornění na rozpočet, interní zpětné zúčtování, analýzu marže a automatizované prosazování zásad. Vrstva automatizace Partner API se stává důvěryhodnější, když může odhalit údaje o nákladech a výkonu, nejen poskytovat přístup.
Co zůstává nejisté
Oznámení OpenRouter popisuje dostupné dimenze a metriky, ale dlouhodobější účinek bude záviset na tom, jak týmy budou data používat a jak bude rozhraní API kompletní pro provozní pracovní postupy. Například analytika je nejvýkonnější, když je spárována s kontrolami rozpočtu, zásadami směrování, výstrahami, exporty a oprávněními. Požadavek na klíč pro správu je smysluplný pro citlivá fakturační data, ale také to znamená, že zákazníci budou muset s tímto klíčem zacházet jako s vysoce privilegovaným pověřením.
Existuje také širší otázka trhu. S tím, jak si brány umělé inteligence, modelová tržiště a cloudové platformy konkurují, se analytika může stát odlišovatelem méně kvůli samotným grafům a více kvůli tomu, jak dobře se propojují s řízením. Vítězný model bude pravděpodobně kombinovat atribuci využití, správu klíčů API, týmová oprávnění, limity rozpočtu, zásady pro výběr modelů a auditní záznamy.
Prozatím je krok OpenRouter jasným signálem: výdaje na umělou inteligenci jsou příliš distribuované, než aby je bylo možné spravovat pouze z faktur. Další fáze řízení nákladů AI API bude měřena na úrovni agentů, klíčů, pracovních prostorů a voleb směrování.