Observabilitate LLM într-un gateway API cu mai multe modele: urme, registre de jetoane, analize de chiriași și înregistrare în siguranță a promptului

Numărările agregate ale solicitărilor și cheltuielile lunare nu sunt suficiente atunci când un client întreabă de ce un flux de lucru a devenit mai lent, mai costisitor sau mai puțin fiabil ieri. Un gateway API cu mai multe modele poate răspunde la această întrebare dacă tratează observabilitatea ca parte a planului de control: fiecare solicitare primește o urmă, fiecare apel de model actualizează un registru de utilizare, fiecare locatar și flux de lucru este atribuibil, iar conținutul sensibil este protejat în mod implicit.

Acest articol descrie un design practic pentru analitica utilizării AI și observabilitatea LLM într-un gateway care înfruntă mai mulți furnizori printr-un API compatibil OpenAI. Modelul este util chiar dacă nu folosiți niciun furnizor anume: instrumentați o dată la gateway, normalizați telemetria modelului, păstrați atribuirea facturării și capturați conținut prompt numai conform politicii explicite.

Problema cititorului: „Care chiriaș, model, prompt sau cale de recuperare a cauzat schimbarea?”

Majoritatea echipelor se confruntă în cele din urmă cu același decalaj de depanare. Jurnalele aplicației arată că o funcție a eșuat. Tablourile de bord ale furnizorilor arată că utilizarea token-ului a crescut. Finanțe vede o factură. Niciuna dintre aceste vizualizări, prin ea însăși, nu explică calea completă de la cererea locatarului la apelul model la contextul de recuperare pentru a reîncerca la costul facturat.

Obiectivul nu este un alt tablou de bord cu un total de jetoane. Scopul este de a răspunde la întrebări operaționale precum:

• Ce chiriaș sau cheie API a cauzat o creștere a cheltuielilor?
• A crescut latența după modificarea unui alias de model?
• Reîncercările sau alternativele costă dubla numărare?
• Care versiune de prompt arde cel mai mult buget de eroare?
• Un flux de lucru RAG a devenit costisitor deoarece recuperarea a adăugat prea multe indicative de context?
• Poate accepta depanarea unui incident fără a citi solicitările private ale utilizatorilor?

Fapte, recomandări și previziuni

Fapte: OpenTelemetry documentează convențiile și atributele semantice generative AI pentru operațiunile model, inclusiv nume de operațiuni precum chat, generate_content și text_completion. Aceeași documentație avertizează că atributele mesajelor de intrare și ieșire GenAI pot conține informații sensibile sau PII și pot necesita filtrare sau trunchiere. Furnizorii majori de modele expun, de asemenea, tablouri de bord de utilizare, API-uri sau exporturi care pot sprijini reconcilierea la nivel de furnizor, deși detaliile diferă în funcție de furnizor.

Recomandări: utilizați OpenTelemetry pentru urme neutre pentru furnizor, dar păstrați dimensiunile companiei deținute de gateway în propriile atribute și registre. Nu stocați prompturi sau rezultate brute în mod implicit. Stocați mai întâi metadatele, hashe-urile, numărul de simboluri, ID-urile șablonelor de solicitare, numele schemelor, clasele de eroare și etichetele de siguranță. Adăugați captură de conținut numai ca o funcție de depanare, cu acces controlat și cu reținere scurtă.

Predicție: observabilitatea LLM va deveni mai puțin despre tablourile de bord izolate ale furnizorilor și mai mult despre planurile de control între furnizori. Echipele se vor aștepta la un singur loc pentru a investiga latența, costul, calitatea, evenimentele legate de politici, comportamentul chiriașilor și deltele de facturare în toate modelele.

Arhitectură de referință: observați întreaga cale de solicitare

Un gateway poate vedea întregul ciclu de viață al cererii fără a fi necesar ca fiecare echipă de aplicații să creeze telemetrie personalizată. Un model de urmărire util începe cu un interval părinte pentru cererea primită de la client și cu un interval secundar pentru pașii care afectează costul, latența și calitatea.

Structură recomandată

• Interval de solicitare Gateway: cerere acceptată, autentificată, autorizată, cu tarif limitat și direcționată.
• Model de durată a apelurilor: furnizor, model, operare, utilizarea simbolului, starea răspunsului și latența.
• Durata de recuperare: indexată, ID-uri de document sau ID-uri hashing, număr de bucăți, latență de recuperare și partajare de simboluri de context.
• Durata apelurilor instrumentului: numele instrumentului, starea, latența, clasa de eroare și clasificarea efectelor secundare.
• Perioada de reîncercare: motivul reîncercării, numărul încercării, starea furnizorului și costul incremental.
• Durata de rezervă: model original, model de rezervă, declanșator, politica de compatibilitate și rezultatul final.
• Perioada de gardă sau moderare: politica invocată, decizie, etichete și dacă ieșirea a fost blocată sau transformată.
• Perioadă de post-procesare: validare JSON, reparare a schemei, verificări de citare sau formatare finală.

Intervalul părinte ar trebui să conțină identificatori de corelație stabili. Întinderile de copii ar trebui să aibă atribute tehnice normalizate. Registrul de utilizare ar trebui să aibă înregistrări durabile de facturare și analiză. Evitați forțarea tuturor informațiilor în etichetele de valori; valorile cu cardinalitate ridicată, cum ar fi ID-urile locatarului, hash-urile prompte și ID-urile documentelor sunt mai bine stocate în urme, jurnale sau tabele registru și apoi agregate în tablouri de bord.

Normalizați metadatele capturate la fiecare apel LLM

Fiecare cerere de model ar trebui să producă o înregistrare consecventă, indiferent de furnizor. Schema exactă va varia, dar un minim practic arată astfel:

{
  "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": "nume_furnizor",
  "model": "furnizor-model-id",
  "model_alias": "fast-support-chat",
  "prompt_template_id": "refund_policy_v5",
  "prompt_hash": "sha256:...",
  "response_schema": "support_answer_v2",
  "status": "finalizat",
  „error_class”: nul,
  "latency_ms": 1842,
  „input_tokens”: 2110,
  „output_tokens”: 384,
  „cached_input_tokens”: 1200,
  "estimated_cost_usd": "0,00492",
  „final_billed_cost_usd”: nul,
  "finish_reason": "opriți",
  "retry_count": 0,
  „fallback_used”: fals,
  "content_capture_policy": "metadata_only"
}

Păstrați două idei separate: telemetria explică ce s-a întâmplat, în timp ce registrul de utilizare înregistrează ceea ce ar trebui să fie taxat, reconciliat și raportat. Se referă reciproc cu ID-uri de solicitare și ID-uri de urmărire, dar nu trebuie să locuiască în același sistem de stocare.

Construiți un token și un registru al costurilor, nu doar contoare

Contoarele de jetoane sunt utile pentru diagrame, dar nu sunt suficiente pentru facturare sau investigarea incidentelor. Un registru ar trebui să reprezinte tranzițiile de stare. Creați un rând când gateway-ul acceptă o solicitare, apoi actualizați-l pe măsură ce solicitarea avansează.

Stari utile registrului contabil

• acceptat: autentificarea și verificările politicii au fost trecute.
• redirecționat: solicitarea a fost trimisă unui furnizor.
• streaming: furnizorul a început să returneze jetoane.
• finalizat: răspunsul s-a încheiat cu succes.
• user_aborted: clientul s-a deconectat înainte de finalizare.
• reîncercat: a fost făcută o încercare suplimentară de furnizor.
• fallback_used: a fost selectat un alt model sau furnizor după eșec sau potrivire cu politicile.
• Eșuat: solicitarea s-a încheiat fără un răspuns utilizabil.
• reconciliat: au fost comparate și aplicate datele de utilizare sau de cost la nivelul furnizorului.

Acest model de stare ajută la identificarea erorilor obișnuite de facturare și analiză: răspunsuri transmise în flux în care clientul s-a deconectat, încercări de reîncercare care au fost taxate de furnizor, dar ascunse utilizatorului, căi alternative care au numărat modelul greșit și diferențele de contabilitate în cache între furnizori.

Utilizați convențiile OpenTelemetry GenAI, apoi extindeți cu atenție

Convențiile semantice OpenTelemetry GenAI oferă un vocabular portabil pentru operațiunile cu model. Folosiți aceste convenții pentru atribute comune, cum ar fi numele operațiunii, furnizorul, modelul, parametrii solicitării, motivele finalizării răspunsului, utilizarea simbolului și starea erorii acolo unde se aplică.

Cu toate acestea, convențiile neutre pentru furnizori nu vor acoperi fiecare dimensiune comercială dintr-un gateway. Adăugați atribute deținute de gateway sau coloane registru pentru:

• ID-ul locatarului, ID-ul echipei, ID-ul clientului reseller-ului și ID-ul aplicației;
• ID-ul cheii API și domeniul de aplicare al cheii;
• planul de facturare, limita de cheltuieli și politica bugetară;
• aliasul modelului și versiunea politicii de rutare;
• ID șablonului prompt și versiunea promptului;
• numele fluxului de lucru și pasul fluxului de lucru;
• costul estimat, costul final facturat și starea reconcilierii.

Compartimentul este cardinalitatea. Aceste câmpuri sunt valoroase pentru investigare, dar pot face valorile scumpe și zgomotoase dacă sunt folosite ca etichete de metrici peste tot. O regulă practică este: agregatele cu cardinalitate scăzută merg la metrici; identificatorii cu cardinalitate mare merg la urme, jurnale și registre.

Proiectați prompt și înregistrare sigură a ieșirii

Înregistrarea completă promptă face depanarea mai ușoară, dar crește confidențialitatea, conformitatea, stocarea și expunerea la riscuri din interior. Valoarea prestabilită mai sigură este observabilitatea mai întâi a metadatelor.

Implicit: numai metadate

Pentru majoritatea traficului de producție, stocați:

• idul și versiunea șablonului prompt;
• hash-uri de solicitări și ieșiri normalizate;
• numărările de intrare, de ieșire, stocate în cache și de context;
• numele schemei de răspuns și rezultatul validării;
• etichete de siguranță și decizii politice;
• rezumatele erorilor și clasele de erori ale furnizorului;
• metadate de recuperare, nu documente brute.

Înscriere: captură controlată de conținut

Dacă aveți nevoie de conținut brut sau redactat pentru depanare profundă, solicitați o politică explicită. Controalele bune includ listele de mediu permise, consimțământul chiriașului, eșantionarea, lungimea maximă a încărcăturii utile, redactarea automată, ferestre scurte de păstrare, criptarea, accesul bazat pe roluri, jurnalele de audit și o cale de aprobare pentru incidente sensibile.

Nu tratați redactarea ca fiind perfectă. Reduce riscul; nu o elimina. Pentru sarcinile de lucru reglementate sau cu sensibilitate ridicată, luați în considerare stocarea numai hash-urilor și reluarea problemelor într-un cablaj sintetic cu date de testare aprobate.

Adăugați observabilitatea RAG ca strat separat

Generarea îmbunătățită prin recuperare poate modifica atât calitatea, cât și costul. Înregistrarea numai a apelului final al modelului ascunde cauza principală când retriever-ul returnează prea multe bucăți, documente învechite sau context irelevant.

Pentru fiecare pas de recuperare, capturați:

• numele indexului sau al colecției;
• strategia de recuperare și modelul de încorporare;
• ID-urile documentelor sau codurile hashing;
• număr de bucăți și simboluri de context total;
• latența de recuperare;
• distribuirea scorului cel mai bun, dacă este disponibil;
• acoperirea citațiilor;
• dacă contextul preluat a fost folosit în răspunsul final.

Acest lucru vă permite să distingeți „modelul s-a înrăutățit” de „retrieverul a început să trimită context de calitate scăzută sau excesiv”. De asemenea, ajută la identificarea fluxurilor de lucru în care tokenurile de context domină costul total.

Reconciliați utilizarea gateway-ului cu facturarea furnizorului

Estimările pentru gateway sunt disponibile imediat. Datele de facturare la nivelul furnizorului sunt de obicei mai lente, dar mai autoritare. Folosiți ambele.

O lucrare de reconciliere zilnică ar trebui să compare rândurile registrului gateway cu API-urile de utilizare a furnizorilor, API-urile de cost, exporturile de tablouri de bord sau exporturile de facturi. Grupați deltele în funcție de furnizor, model, proiect și fereastră de timp. Urmăriți diferențele separat pentru jetoanele de intrare, jetoanele de ieșire, jetoanele stocate în cache, numărul de solicitări și costul.

Diferențe comune de reconciliere

• Se deconectează fluxul: gateway-ul poate vedea un client avortat în timp ce furnizorul încă facturează jetoanele generate.
• Reîncercări: mai multe încercări pot fi facturate chiar dacă este returnat un singur răspuns final.
• Memorizare promptă în cache: furnizorii pot expune diferit contabilitatea jetonelor în cache.
• Rotunjire: diferențele mici pe solicitare pot deveni vizibile la scară.
• Reduceri de lot sau de nivel: facturile furnizorilor pot aplica prețuri pe care estimarea în timp real nu le cunoștea încă.
• Modificări la nivelul furnizorului: prețurile modelului, comportamentul de tokenizare sau exporturile de facturare se pot modifica în timp.

Când reconcilierea găsește o deltă, evitați să vă suprascrieți în tăcere registrul. Stocați estimarea inițială, valoarea reconciliată cu furnizorul, sursa de reconciliere și codul motiv, dacă este cunoscut.

Tablouri de bord care răspund la întrebări operaționale

Începeți tablourile de bord de la problemele cititorilor, nu de valorile de vanitate. Vizualizările utile includ:

• costul pe chiriaș, echipă, aplicație și flux de lucru;
• costul pe sarcină reușită, nu doar costul pe solicitare;
• latența p50, p95 și p99 în funcție de furnizor, model și alias de model;
• rata de retragere și rata de reîncercare în funcție de rută;
• rata de expirare și tendințele claselor de eroare ale furnizorului;
• raportul de accesări în cache și estimarea economiilor de jeton în cache;
• rata de eșec al validării rezultatelor structurate;
• versiunile cele mai importante de prompt prin eroare de ardere a bugetului;
• Partajarea jetonelor de context RAG în funcție de fluxul de lucru;
• blocuri de protecție și lovituri de clasificare cu injecție rapidă.

Pentru alerte, combinați semnalele tehnice și comerciale. O creștere bruscă a cheltuielilor chiriașilor poate fi mai urgentă decât o mică creștere globală a latenței. O creștere a ratei de rezervă după o modificare a aliasului de model poate indica o problemă de compatibilitate. Răspunsurile repetate 401, 429 sau 5xx pot indica probleme cheie, epuizarea cotelor sau instabilitatea furnizorului.

Flux de implementare minim pentru un proxy compatibil OpenAI

Pentru un proxy /chat/completions, fluxul poate fi simplu:

1. Primiți solicitarea și atribuiți request_id și urmăriți contextul.
2. Autentificați cheia gateway-ului și rezolvați domeniul de aplicare al chiriașului, al echipei, al aplicației și al politicii.
3. Creați intervalul de gateway părinte.
4. Creați un rând registru cu starea acceptat.
5. Rezolvați aliasul de model la modelul furnizorului și versiunea politicii de rutare.
6. Înregistrați metadate: operațiune, ID șablon de solicitare, numele schemei, hash prompt și politica de captare a conținutului.
7. Începeți durata apelului model folosind atribute semantice GenAI, acolo unde este cazul.
8. Redirecționați solicitarea către furnizorul selectat.
9. Pentru streaming, actualizați starea când sosește prima bucată și numărați utilizarea cât de precis permite răspunsul furnizorului.
10. La finalizare, analizați utilizarea furnizorului, motivul finalizării, starea și clasa de eroare.
11. Actualizați registrul cu jetoane, costul estimat, detalii de reîncercare/de rezervă și starea finală a solicitării.
12. Emiteți valori din registru și date span.
13. Efectuați reconcilierea zilnică și stocați costul confirmat de furnizor separat de estimarea inițială.

Lista de verificare a lansării

• Definiți ID-uri de solicitare canonice și ID-uri de urmărire.
• Adoptați atributele OpenTelemetry GenAI pentru telemetria modelului comun.
• Creați un registru de utilizare a gateway-ului cu tranziții de stare a cererii.
• Normalizați parametrii furnizor, model, alias de model, locatar, aplicație și flux de lucru.
• Păstrați datele de investigație cu cardinalitate ridicată în afara etichetelor de valori.
• Dezactivați în mod prestabilit promptul brut și capturarea ieșirii.
• Adăugați politici explicite pentru eșantionare, redactare, păstrare și control al accesului.
• Capturați metadate de recuperare pentru fluxurile de lucru RAG.
• Construiți tablouri de bord pentru cost, latență, fiabilitate, validare și comportamentul chiriașilor.
• Reconciliați estimările gateway-ului cu utilizarea furnizorului și exporturile de costuri.
• Alertă cu privire la vârfurile de cheltuieli, regresiile de latență, salturile de rezervă, eșecurile de validare și evenimentele relevante pentru securitate.

Concluzie

Un gateway cu mai multe modele este locul potrivit pentru a implementa observabilitatea LLM, deoarece vede cererile înainte ca acestea să ajungă la orice furnizor și poate atașa un context de afaceri pe care furnizorii nu îl cunosc. Cel mai puternic design nu este „înregistrați totul”. Este un model stratificat: urme neutre de furnizor pentru execuție, un token durabil și un registru al costurilor pentru facturare, analize ale chiriașilor pentru guvernare, metadate RAG pentru calitatea recuperării și înregistrarea promptă a confidențialității pentru o depanare sigură.

Începeți cu metadate, tranziții de stare și reconciliere. Adăugați captură de conținut numai atunci când politica, reținerea și controalele de acces sunt gata. Această secvență oferă dezvoltatorilor dovezile de care au nevoie pentru a depana latența, calitatea și cheltuirea fără a transforma observabilitatea într-un nou risc de expunere a datelor.

Lectură similară

• prompt cache și modele de control al costurilor lot
• team API managementul cheilor și limitele de cheltuieli