Pozorovatelnost LLM ve vícemodelové bráně API: Trasování, účetní knihy tokenů, analýza nájemců a bezpečné protokolování výzev

Souhrnné počty požadavků a měsíční útrata nestačí, když se zákazník zeptá, proč byl jeden pracovní postup včera pomalejší, dražší nebo méně spolehlivý. Brána s více modely API může na tuto otázku odpovědět, pokud zachází s pozorovatelností jako se součástí řídicí roviny: každý požadavek získá trasování, každé volání modelu aktualizuje knihu použití, lze přiřadit každého tenanta a pracovní postup a citlivý obsah je ve výchozím nastavení chráněn.

Tento článek popisuje praktický návrh analytiky využití AI a pozorovatelnosti LLM v bráně, která slouží více poskytovatelům prostřednictvím OpenAIkompatibilního API. Vzor je užitečný, i když nepoužíváte žádného konkrétního dodavatele: nástroj jednou na bráně, normalizaci telemetrie modelu, zachování přiřazení fakturace a zachycování obsahu výzev pouze na základě explicitních zásad.

Problém se čtečkou: „Který tenant, model, výzva nebo cesta načítání způsobily změnu?“

Většina týmů se nakonec potýká se stejnou mezerou v ladění. Protokoly aplikací ukazují, že některá funkce selhala. Panely poskytovatelů ukazují, že využití tokenů vzrostlo. Finance vidí účet. Žádný z těchto pohledů sám o sobě nevysvětluje úplnou cestu od požadavku nájemce přes volání modelu až po kontext načítání a opakování pokusu o fakturované náklady.

Cílem není další panel s celkovým počtem tokenů. Cílem je odpovědět na provozní otázky jako:

• Který tenant nebo klíč API způsobil prudký nárůst útraty?
• Zvýšila se latence po změně aliasu modelu?
• Započítávají se náklady na opakované nebo záložní pokusy dvakrát?
• Která okamžitá verze spálí nejvíce chybového rozpočtu?
• Zdražil pracovní postup RAG, protože načítání přidalo příliš mnoho kontextových tokenů?
• Může podporovat ladění incidentu bez čtení výzev soukromých uživatelů?

Fakta, doporučení a předpovědi

Fakta: OpenTelemetry dokumentuje generativní sémantické konvence a atributy umělé inteligence pro modelové operace, včetně názvů operací, jako je chat, generate_content a text_completion. Stejná dokumentace varuje, že atributy vstupní a výstupní zprávy GenAI mohou obsahovat citlivé informace nebo PII a mohou vyžadovat filtrování nebo zkrácení. Hlavní poskytovatelé modelů také nabízejí panely využití, rozhraní API nebo exporty, které mohou podporovat sladění na straně poskytovatele, ačkoli podrobnosti se u jednotlivých poskytovatelů liší.

Doporučení: Používejte OpenTelemetry pro trasování neutrální vůči poskytovatelům, ale ponechejte si obchodní dimenze vlastněné bránou ve svých vlastních atributech a účetních knihách. Ve výchozím nastavení neukládejte nezpracované výzvy nebo výstupy. Nejprve ukládejte metadata, hashe, počty tokenů, ID šablon výzvy, názvy schémat, třídy chyb a bezpečnostní štítky. Přidejte zachycení obsahu pouze jako volitelnou funkci ladění s řízeným přístupem a krátkou dobou uchování.

Predikce: Pozorovatelnost LLM bude méně o izolovaných řídicích panelech poskytovatelů a více o řídicích rovinách mezi různými poskytovateli. Týmy budou očekávat, že na jednom místě budou zkoumat latenci, náklady, kvalitu, události zásad, chování nájemců a rozdíly ve fakturaci napříč modely.

Referenční architektura: sledujte celou cestu požadavku

Brána může vidět celý životní cyklus požadavku, aniž by musel každý aplikační tým vytvářet vlastní telemetrii. Užitečný model trasování začíná jedním nadřazeným rozsahem pro příchozí požadavek zákazníka a podřízeným rozsahem pro kroky, které ovlivňují cenu, latenci a kvalitu.

Doporučená struktura rozsahu

• Rozsah požadavku brány: požadavek přijat, ověřen, autorizován, omezen sazbou a směrován.
• Rozsah volání modelu: poskytovatel, model, operace, využití tokenu, stav odpovědi a latence.
• Rozsah načítání: dotazovaný index, ID dokumentů nebo hashovaná ID, počet bloků, latence načítání a sdílení kontextového tokenu.
• Rozsah volání nástroje: název nástroje, stav, latence, třída chyb a klasifikace vedlejších účinků.
• Rozpětí opakování: důvod opakování, číslo pokusu, stav poskytovatele a přírůstkové náklady.
• Rozpětí záložních reklam: původní model, záložní model, spouštěč, zásady kompatibility a konečný výsledek.
• Rozpětí ochranného zábradlí nebo moderování: vyvolané zásady, rozhodnutí, štítky a to, zda byl výstup blokován nebo transformován.
• Rozsah následného zpracování: JSON ověření, oprava schématu, kontrola citací nebo konečné formátování.

Rodičovský rozsah by měl nést identifikátory stabilní korelace. Podřízené rozpětí by mělo nést normalizované technické atributy. Kniha použití by měla obsahovat trvalé fakturační a analytické záznamy. Vyhněte se vynucení všech informací do štítků metrik; hodnoty s vysokou kardinalitou, jako jsou ID tenantů, hash výzev a ID dokumentů, se lépe ukládají do trasování, protokolů nebo tabulek hlavní knihy a poté agregují do řídicích panelů.

Normalizovat metadata zachycená při každém volání LLM

Každý požadavek modelu by měl vytvářet konzistentní záznam bez ohledu na poskytovatele. Přesné schéma se bude lišit, ale praktické minimum vypadá takto:

{
  "request_id": "req_01J...",
  "trace_id": "4bf92f3577b34da6a3ce929d0e0e4736",
  "tenant_id": "tenant_123",
  "team_id": "team_456",
  "app_id": "support_bot",
  "gateway_key_id": "key_789",
  "operation": "chat",
  "provider": "provider_name",
  "model": "provider-model-id",
  "model_alias": "fast-support-chat",
  "prompt_template_id": "refund_policy_v5",
  "prompt_hash": "sha256:...",
  "response_schema": "support_answer_v2",
  "status": "completed",
  "error_class": null,
  "latency_ms": 1842,
  "input_tokens": 2110,
  "output_tokens": 384,
  "cached_input_tokens": 1200,
  "estimated_cost_usd": "0.00492",
  "final_billed_cost_usd": null,
  "finish_reason": "stop",
  "retry_count": 0,
  "fallback_used": false,
  "content_capture_policy": "metadata_only"
}

Držte dva nápady odděleně: telemetry vysvětluje, co se stalo, zatímco kniha použití zaznamenává, co by mělo být účtováno, odsouhlaseno a hlášeno. Odkazují se navzájem pomocí ID požadavků a ID sledování, ale nemusí žít ve stejném úložném systému.

Sestavte si token a knihu nákladů, nejen počítadla

Počítadla tokenů jsou užitečná pro grafy, ale nestačí k účtování nebo vyšetřování incidentů. Hlavní kniha by měla představovat přechody stavů. Vytvořte řádek, když brána přijme požadavek, a poté jej aktualizujte, jak požadavek postupuje.

Užitečné stavy účetní knihy

• accepted: ověření a kontrola zásad prošla.
• forwarded: požadavek byl odeslán poskytovateli.
• streaming: poskytovatel začal vracet tokeny.
• completed: odpověď úspěšně dokončena.
• user_aborted: klient se před dokončením odpojil.
• opakováno: byl proveden další pokus o poskytovatele.
• fallback_used: po selhání nebo shodě zásad byl vybrán jiný model nebo poskytovatel.
• failed: požadavek skončil bez použitelné odpovědi.
• reconciled: Údaje o využití nebo nákladech na straně poskytovatele byly porovnány a použity.

Tento stavový model pomáhá zachytit běžné chyby fakturace a analýzy: streamované odpovědi, kdy se klient odpojil, opakování pokusů, které byly účtovány poskytovatelem, ale skryté před uživatelem, záložní cesty, které počítaly nesprávný model, a rozdíly v účtování mezi poskytovateli mezipaměti.

Používejte konvence GenAI OpenTelemetry a poté opatrně rozšiřujte

Sémantické konvence OpenTelemetry GenAI poskytují přenosný slovník pro modelové operace. Tyto konvence použijte pro běžné atributy, jako je název operace, poskytovatel, model, parametry požadavku, důvody dokončení odpovědi, použití tokenu a chybový stav tam, kde se vztahují.

Konvence neutrální vůči poskytovatelům však nebudou pokrývat všechny obchodní dimenze brány. Přidejte atributy nebo sloupce hlavní knihy ve vlastnictví brány pro:

• ID tenanta, ID týmu, ID zákazníka distributora a ID aplikace;
• brána API ID klíče a rozsah klíče;
• plán fakturace, limit útraty a zásady rozpočtu;
• verze aliasu modelu a směrování;
• ID šablony výzvy a verze výzvy;
• název pracovního postupu a krok pracovního postupu;
• odhadované náklady, konečné fakturované náklady a stav odsouhlasení.

Výhodou je mohutnost. Tato pole jsou cenná pro zkoumání, ale mohou způsobit, že metriky budou drahé a hlučné, pokud se všude používají jako štítky metrik. Praktickým pravidlem je: agregáty s nízkou mohutností jdou do metrik; identifikátory s vysokou kardinalitou jdou do tras, protokolů a účetních knih.

Navrhněte bezpečnou výzvu a protokolování výstupu

Úplné rychlé protokolování usnadňuje ladění, ale zvyšuje soukromí, dodržování předpisů, úložiště a vystavení vnitřnímu riziku. Bezpečnější výchozí nastavení je pozorovatelnost na prvním místě metadat.

Výchozí: pouze metadata

Pro většinu produkčního provozu uložte:

• ID šablony výzvy a verze;
• haše normalizovaných výzev a výstupů;
• počet vstupů, výstupů, mezipaměti a kontextových tokenů;
• název schématu odpovědí a výsledek ověření;
• bezpečnostní štítky a rozhodnutí o zásadách;
• souhrny chyb a třídy chyb poskytovatele;
• načítání metadat, nikoli nezpracovaných dokumentů.

Přihlášení: kontrolované zachycování obsahu

Pokud potřebujete nezpracovaný nebo upravený obsah pro hluboké ladění, vyžadujte explicitní zásady. Mezi dobré ovládací prvky patří seznamy povolených prostředí, souhlas nájemce, vzorkování, maximální délka užitečného zatížení, automatická redakce, krátká okna uchování, šifrování, přístup na základě rolí, protokoly auditu a cesta schvalování pro citlivé incidenty.

Nepovažujte redakci za dokonalou. Snižuje riziko; nevylučuje to. U regulovaných nebo vysoce citlivých úloh zvažte ukládání pouze hashů a přehrávání problémů v syntetickém svazku se schválenými testovacími daty.

Přidat pozorovatelnost RAG jako samostatnou vrstvu

Generování s rozšířeným získáváním může změnit kvalitu i cenu. Protokolování pouze posledního volání modelu skryje hlavní příčinu, když retriever vrátí příliš mnoho kusů, zastaralé dokumenty nebo irelevantní kontext.

Pro každý krok načítání zaznamenejte:

• název indexu nebo kolekce;
• strategie načítání a model vkládání;
• ID dokumentů nebo hashovaná ID;
• počet kusů a celkový kontext tokenů;
• latence načítání;
• nejvyšší rozdělení skóre, je-li k dispozici;
• pokrytí citací;
• zda byl v konečné odpovědi použit načtený kontext.

Umožní vám to rozlišit „model se zhoršil“ od „retriever začal odesílat nekvalitní nebo nadměrný kontext.“ Pomáhá také identifikovat pracovní postupy, kde kontextové tokeny dominují celkovým nákladům.

Sladění používání brány s fakturací poskytovatele

Odhady brány jsou k dispozici okamžitě. Fakturační údaje na straně poskytovatele jsou obvykle pomalejší, ale směrodatnější. Použijte obojí.

Úloha denního odsouhlasení by měla porovnávat řádky hlavní knihy brány s rozhraními API pro využití poskytovatele, rozhraními API pro náklady, exporty řídicího panelu nebo exporty faktur. Seskupte delty podle poskytovatele, modelu, projektu a časového okna. Odděleně sledujte rozdíly pro vstupní tokeny, výstupní tokeny, tokeny uložené v mezipaměti, počty požadavků a náklady.

Běžné rozdíly v odsouhlasení

• Streamování se odpojí: brána může vidět přerušeného klienta, zatímco poskytovatel stále účtuje vygenerované tokeny.
• Opakování: může být účtováno několik pokusů, i když je vrácena pouze jedna konečná odpověď.
• Výzva ukládání do mezipaměti: Poskytovatelé mohou vystavovat účetnictví tokenů uložených v mezipaměti odlišně.
• Zaokrouhlení: malé rozdíly u jednotlivých požadavků se mohou projevit v měřítku.
• Dávkové nebo víceúrovňové slevy: Na fakturách poskytovatelů se mohou vztahovat ceny, které odhad v reálném čase ještě neznal.
• Změny na straně poskytovatele: ceny modelu, chování tokenizace nebo exporty fakturace se mohou časem měnit.

Když usmíření najde deltu, vyhněte se tichému přepisování své účetní knihy. Uložte původní odhad, hodnotu odsouhlasenou poskytovatelem, zdroj odsouhlasení a kód důvodu, pokud je znám.

Panely, které odpovídají na provozní otázky

Spouštějte řídicí panely z problémů se čtenáři, nikoli z marných metrik. Mezi užitečné pohledy patří:

• cena za tenanta, tým, aplikaci a pracovní postup;
• cena za úspěšný úkol, nejen cena za požadavek;
• latence p50, p95 a p99 podle poskytovatele, modelu a aliasu modelu;
• počet záložních reklam a počet opakování podle trasy;
• rychlost vypršení časového limitu a trendy třídy chyb poskytovatele;
• poměr požadavků na přístup do mezipaměti a odhad úspory tokenů v mezipaměti;
• četnost selhání ověření strukturovaného výstupu;
• nejlépe rychlé verze podle chyby spálení rozpočtu;
• Sdílení kontextového tokenu RAG podle pracovního postupu;
• zábradlí a nárazy klasifikátoru prompt-injection.

Pro upozornění kombinujte technické a obchodní signály. Náhlý nárůst výdajů nájemců může být naléhavější než malé globální zvýšení latence. Skok v nouzových rychlostech po změně aliasu modelu může znamenat problém s kompatibilitou. Opakované odpovědi 401, 429 nebo 5xx mohou poukazovat na klíčové problémy, vyčerpání kvóty nebo nestabilitu poskytovatele.

Minimální tok implementace pro OpenAI-kompatibilní proxy

Pro proxy /chat/completions může být postup jednoduchý:

1. Přijměte požadavek a přiřaďte request_id a sledujte kontext.
2. Ověřte klíč brány a vyřešte rozsah tenanta, týmu, aplikace a zásad.
3. Vytvořte nadřazený rozsah brány.
4. Vytvořte řádek hlavní knihy se stavem accepted.
5. Vyřešte alias modelu na model poskytovatele a verzi zásad směrování.
6. Metadata záznamu: operace, ID šablony výzvy, název schématu, hash výzvy a zásady zachycení obsahu.
7. V případě potřeby zahajte rozsah volání modelu pomocí sémantických atributů GenAI.
8. Předejte požadavek vybranému poskytovateli.
9. U streamování aktualizujte stav, když dorazí první blok, a počítejte využití tak přesně, jak to dovolí odpověď poskytovatele.
10. Po dokončení analyzujte využití poskytovatele, důvod dokončení, stav a třídu chyb.
11. Aktualizujte účetní knihu o tokeny, odhadovanou cenu, podrobnosti o opakování/záložním postupu a konečný stav požadavku.
12. Vysílat metriky z účetní knihy a dat rozsahu.
13. Provádějte denní odsouhlasení a ukládejte náklady potvrzené poskytovatelem odděleně od původního odhadu.

Kontrolní seznam k zavedení

• Definujte kanonická ID požadavků a ID trasování.
• Přijměte atributy OpenTelemetry GenAI pro běžný model telemetrie.
• Vytvořte knihu použití brány s přechody stavu požadavku.
• Normalizujte dimenze poskytovatele, modelu, aliasu modelu, tenanta, aplikace a pracovního postupu.
• Uchovejte údaje z vyšetřování s vysokou kardinalitou mimo štítky metrik.
• Ve výchozím nastavení deaktivovat nezpracované výzvy a zachycení výstupu.
• Přidat explicitní zásady pro vzorkování, redigování, uchovávání a řízení přístupu.
• Zachyťte metadata vyhledávání pro pracovní postupy RAG.
• Vytvářejte řídicí panely pro náklady, latenci, spolehlivost, ověřování a chování nájemců.
• Sladění odhadů brány s využitím poskytovatele a exportem nákladů.
• Upozornění na špičky útraty, regrese latence, záložní skoky, selhání ověření a události související se zabezpečením.

Závěr

Multimodelová brána je tím správným místem pro implementaci pozorovatelnosti LLM, protože vidí požadavky dříve, než se dostanou k jakémukoli poskytovateli, a může připojit obchodní kontext, který poskytovatelé neznají. Nejsilnější design není „zaznamenat všechno“. Jedná se o vrstvený model: trasování neutrální vůči poskytovateli pro provádění, trvanlivý token a účetní kniha nákladů pro fakturaci, analytika nájemců pro správu, metadata RAG pro kvalitu načítání a protokolování rychlého přístupu na ochranu soukromí pro bezpečné ladění.

Začněte metadaty, přechody stavů a ​​odsouhlasením. Zachycení obsahu přidejte pouze tehdy, když jsou připraveny zásady, uchovávání a řízení přístupu. Tato sekvence poskytuje vývojářům důkazy, které potřebují k ladění latence, kvality a výdajů, aniž by se z pozorovatelnosti stalo nové riziko vystavení dat.

Související čtení

• opakování a nouzové chování v LLM API routing
• rychlé ukládání do mezipaměti a dávkové vzory
• tým API správa klíčů a limity útraty