De ce tabloul de bord de utilizare a LLM nu se potrivește cu factura furnizorului

Dacă tabloul de bord de utilizare a LLM, consola furnizorului, exportul de facturare în cloud și factura clientului arată numere diferite, nu începeți prin a presupune că un sistem este greșit. Începeți prin a întreba ce număr este autorizat în ce scop.

Un tablou de bord gateway este de obicei o vizualizare operațională: rapidă, la nivel de solicitare și utilă pentru alerte. O factură de furnizor este o vizualizare de facturare stabilită: mai lentă, agregată și ajustată în conformitate cu regulile de facturare ale furnizorului. Exporturile de facturare în cloud adaugă un alt nivel, în special pentru serviciile de model gestionate, unde datele facturii pot fi grupate după proiect, SKU, regiune, tip de utilizare sau luna de facturare, mai degrabă decât după API solicitare.

Problema practică nu este doar „găsește numărul real”. Este de a clasifica nepotrivirea, de a păstra suficiente dovezi pentru a o explica și de a decide când un număr este suficient de bun pentru tablouri de bord, rapoarte financiare sau facturarea clienților.

Folosiți două registre, nu un număr

Cea mai frecventă greșeală este încercarea de a face ca o estimare de gateway în timp real să se comporte ca o factură finală. Acestea sunt înregistrări diferite cu lucrări diferite.

Registrul de utilizare operațional

Registrul operațional este completat la momentul solicitării de către gateway-ul, SDK wrapper-ul, proxy-ul sau instrumentația aplicației. Ar trebui să fie optimizat pentru viteză și atribuire. Răspunde la întrebări precum:

• Ce chiriaș, echipă, API cheie, proiect sau flux de lucru a creat această solicitare?
• Ce model a fost numit?
• Câte simboluri de intrare, de ieșire, stocate în cache sau de raționament au fost observate sau estimate?
• Solicitarea a fost reîncercată, anulată, transmisă în flux, grupată sau eșuată?
• Ce buget intern sau limită ar trebui să fie taxat imediat?

Acest registru este esențial pentru gestionarea costurilor LLM, dar nu este întotdeauna corect din punct de vedere al facturii. Poate folosi jetoane estimate înainte ca furnizorul să returneze utilizarea finală. Se poate aplica un tabel de preț vechi. Se poate considera o încercare de solicitare pe care furnizorul nu o facturează sau poate rata o reîncercare pe care furnizorul o facturează.

Registrul cu costuri stabilite

Registrul cu costuri decontate este completat din API-urile de cost ale furnizorului, rapoartele de utilizare ale furnizorului sau exporturile de facturare în cloud după ce furnizorul a agregat și clasificat taxele. Ar trebui să fie optimizat pentru raportarea financiară. Răspunde la întrebări precum:

• Ce cost a raportat furnizorul pentru această zi, model, proiect, cheie, element rând sau tip de utilizare?
• Ce monedă și perioada de facturare se aplică?
• Au existat corecții, credite sau ajustări cu întârziere?
• Ce costuri pot fi alocate cu încredere chiriașilor?
• Ce costuri rămân neatribuite deoarece lipseau metadatele?

Recomandări: utilizați registrul operațional pentru alerte, rezervări bugetare, depanare și tablouri de bord aproape în timp real. Utilizați registrul cu costuri decontate pentru închiderea financiară, facturile clienților, analiza marjei și rambursarea finală. Etichetați orice număr de pre-decontare ca fiind estimat sau provizoriu.

Clasificați nepotrivirea înainte de a depana

Majoritatea discrepanțelor de facturare LLM se încadrează în cinci clase. Clasificarea mai întâi a decalajului împiedică echipele să urmărească detaliile tokenizării atunci când problema reală este sincronizarea facturii sau urmărirea exporturilor de facturi în cloud atunci când problema reală este lipsa metadatelor chiriașilor.

1. Derivarea ferestrei de timp

Acest lucru se întâmplă atunci când două sisteme grupează aceeași utilizare în perioade diferite.

Cauzele obișnuite includ datele UTC față de datele locale, zilele de facturare ale furnizorului care nu se potrivesc cu zilele tabloului de bord, datele de finalizare a lucrărilor în lot care diferă de datele de trimitere, solicitările de streaming care depășesc o limită de dată și câmpurile cloud pentru luna de facturare care diferă de marcajele de timp de utilizare. Exporturile de facturare în cloud pot include, de asemenea, corecții sau utilizarea întârziată pentru generarea de bani într-o perioadă ulterioară de facturare.

Pași de depanare:

1. Convertiți fiecare marcaj temporal în UTC înainte de comparare.
2. Comparați separat data de utilizare, ora de începere a solicitării, ora de încheiere a cererii, timpul de procesare a furnizorului, timpul de finalizare a lotului și luna facturii.
3. Reconciliați mai întâi perioadele închise. Evitați să diagnosticați tabloul de bord de astăzi în raport cu un raport al furnizorului care încă este în curs de soluționare.
4. Pentru încărcăturile de lucru în lot, comparați atât data de depunere a cererii, cât și data de finalizare a lotului.

Recomandare: definiți un calendar de raportare care separă „ziua de utilizare”, „ziua decontării” și „luna facturii”. Nu restrângeți aceste câmpuri într-o singură coloană de dată.

2. Deriva de dimensiune

Acest lucru se întâmplă atunci când tabloul de bord și factura grupează lucruri diferite.

Gateway-ul dvs. poate fi grupat după chiriaș, echipă, API cheie, mediu sau flux de lucru. Costul unui furnizor API poate grupa după proiect, utilizator, API cheie, model, element rând sau sursă, în funcție de furnizor și de punctul final. Un export de facturare în cloud poate fi grupat în funcție de proiect, SKU, serviciu, locație, tip de utilizare, etichete sau luna de facturare. Pentru serviciile de model gestionate, este posibil ca atribuirea promptă la cerere să nu existe deloc în exportul facturii.

Pași de depanare:

1. Notați dimensiunile exacte de grupare utilizate de fiecare sistem.
2. Normalizați ID-urile modelului, regiunile, nivelurile de servicii, tipurile de indicative, elementele rând și API sursele înainte de a compara totalurile.
3. Verificați dacă proiectele furnizorilor, spațiile de lucru, API cheile și etichetele proiectelor în cloud sunt corelate cu chiriașii dvs. interni.
4. Identificați în mod explicit cheltuielile neatribuite, în loc să le forțați într-un grup de chiriași.

Recomandare: tratați atribuirea chiriașului ca pe un câmp de facturare de primă clasă, nu ca pe un filtru de tablou de bord. Pentru o atribuire de încredere a costurilor LLM API, capturați identificatorii locatarului la momentul solicitării și păstrați identificatorii de la furnizori necesari pentru a vă înscrie mai târziu.

3. Derivarea prețurilor

Acest lucru se întâmplă atunci când estimarea operațională folosește o logică de preț diferită de factura decontată a furnizorului.

Cauzele obișnuite includ prețul pentru token-ul stocat în cache, taxele de scriere în cache față de accesarea în cache, rate separate de jeton de intrare și de ieșire, aliasuri de model care au trecut la un model cu preț mai nou, niveluri de servicii, geografie de inferență, reduceri pe lot, elemente rând de căutare de fișiere sau de căutare pe web, unități de imagine sau audio și conversie valutară. Un tablou de bord care înmulțește numărul total de jetoane cu un preț combinat va varia de îndată ce factura furnizorului conține mai multe tipuri de jetoane sau elemente rând.

Pași de depanare:

1. Divizați costurile în elemente rând înainte de a compara totalurile.
2. Separați jetoane de intrare, jetoane de ieșire, scrieri în cache, accesări în cache, jetoane de raționament și unități non-token unde furnizorii le raportează.
3. Versionați tabelul de prețuri intern și stocați versiunea de preț folosită pentru fiecare estimare.
4. Verificați dacă furnizorul raportează aliasuri de model, instantanee de model sau elemente rând de produse diferit de gateway-ul dvs.
5. Comparați în moneda de facturare a furnizorului înainte de a aplica propria conversie valutară.

Fapte: suprafețele de raportare ale furnizorilor pot expune costuri grupate și dimensiuni de grupare, cum ar fi proiect, utilizator, cheie API, model, element rând, spațiu de lucru, tip de simbol, geografie, nivel de serviciu sau monedă, în funcție de furnizor și mediu. Exporturile în cloud pot expune etichete, câmpuri de resurse, marcaje temporale de utilizare, luna facturii, credite și corecții.

4. Solicitați deriva ciclului de viață

Acest lucru se întâmplă atunci când sistemele nu sunt de acord cu privire la ceea ce este considerat o operație facturabilă.

Reîncercările sunt vinovatul obișnuit. Dacă o aplicație reîncearcă după expirarea timpului, tabloul de bord al produsului poate trata răspunsul final de succes ca o singură acțiune a utilizatorului, în timp ce furnizorul facturează două sau trei invocări de model. Rutarea de rezervă poate crea aceeași problemă atunci când un apel principal eșuat și un apel de rezervă reușit sunt afișate ca rezultat al unei aplicații.

Transmiterea în flux adaugă o altă sursă de derive. Un utilizator poate anula un flux după ce a primit o ieșire parțială. Furnizorul poate raporta tokenurile generate până la anulare, în timp ce aplicația dvs. înregistrează doar o solicitare eșuată sau abandonată. Lucrările în loturi creează un ciclu de viață diferit: trimiterea, validarea, procesarea, eșecul parțial, recuperarea rezultatelor și facturarea pot să nu aibă aceeași marca temporală.

Pași de depanare:

1. Atribuiți un ID de solicitare intern stabil acțiunii utilizatorului.
2. Atribuiți ID-uri de încercare separate pentru fiecare apel, reîncercare și alternativă de la furnizor.
3. Pastrați ID-urile de răspuns ale furnizorului și ID-urile de solicitare atunci când sunt disponibile.
4. Înregistrați starea fluxului: finalizat, client anulat, server încheiat, expirare sau pierdere a rețelei.
5. Pentru lucrări în lot, stocați ID-ul sarcinii lot, ID-ul fișierului de intrare, acolo unde este cazul, timpul de trimitere, timpul de finalizare și starea per articol, dacă este disponibil.

Recomandare: comparați facturile furnizorului cu încercările furnizorului, nu cu acțiunile utilizatorului la nivel de produs. Apoi, rulați încercările la acțiunile utilizatorului pentru analiza produselor.

5. Derivarea decontării furnizorului

Acest lucru se întâmplă atunci când datele de facturare la nivelul furnizorului se modifică după ce tabloul de bord a afișat deja un număr.

API-urile pentru costul furnizorilor și exporturile de facturare în cloud sunt mai aproape de adevărul facturării, dar pot fi amânate, grupate sau ajustate ulterior. Creditele, corecțiile, utilizarea cu întârziere, modificările pe luna de facturare și reclasificarea produselor pot muta numărul final. Acest lucru este deosebit de important atunci când finanțele compară o captură de ecran din tabloul de bord din prima zi a lunii cu un export de factură generat ulterior.

Pași de depanare:

1. Urmăriți când a fost preluată fiecare grupă de costuri de furnizor.
2. Stocați instantanee imuabile ale importurilor cu costuri stabilite.
3. Detectați modificări între importuri pentru același furnizor, perioadă și parametri de grupare.
4. Păstrați ajustările tardive ca rânduri de ajustare în loc să rescrieți istoricul în tăcere.
5. Definiți un proces de închidere: de exemplu, păstrați o perioadă provizorie până când datele furnizorului s-au stabilizat și verificările variației trec.

Recomandare: facturile clienților ar trebui să utilizeze perioade stabilite sau să aibă o etichetă provizorie explicită. Tablourile de bord pot tolera variații mici în perioadele deschise; facturarea clienților nu trebuie să ascundă incertitudinea.

Schema de dovezi minime

Un proces de reconciliere este la fel de bun decât dovezile reținute înainte de apariția nepotrivirii. Capturați cel puțin metadate care vă permit să treceți între înregistrările operaționale și înregistrările de facturare ale furnizorului fără a stoca conținut sensibil de prompt.

Câmpuri la nivel de solicitare recomandate:

• Identificatori interni: internal_request_id, attempt_id, parent_request_id, tenant_id, team_id, project_id, mediu, workflow_id.
• Identificatori de acces: gateway_api_key_id, provider_api_key_id când este disponibil, cont de serviciu, user_id acolo unde este cazul.
• Identificatori de furnizor: furnizor, provider_project_id, provider_workspace_id, provider_response_id, provider_request_id, cloud_account_id, cloud_project_id.
• Model și rutare: requested_model, resolved_model, model_version, route_policy, fallback_from, fallback_to.
• Utilizare: input_tokens, output_tokens, cached_input_tokens, cache_write_tokens, reasoning_tokens, token_unit, non_token_quantity, quantity_unit.
• Prețul estimat: estimated_cost, monedă, price_table_version, estimate_source, budget_reservation_id.
• Ciclul de viață: stare, error_class, retry_number, stream_started, stream_completed, stream_termination_status, batch_job_id, batch_item_id.
• Timp: request_started_at, request_completed_at, provider_reported_at, batch_submitted_at, batch_completed_at, usage_date_utc.

Nu stocați solicitări sau răspunsuri brute doar pentru a reconcilia facturarea. Solicitați metadatele, numărul de simboluri, ID-urile furnizorilor și dimensiunile normalizate sunt de obicei suficiente. Dacă jurnalele de invocare pot conține conținut sensibil, redactați sau dezactivați capturarea sarcinilor utile de prompt și răspuns, păstrând în același timp câmpurile de utilizare și identitate.

Comparați la cea mai mică cantitate de cereale partajată de încredere

Reconcilierea la nivel de cerere sună atractivă, dar nu este întotdeauna posibilă. Comparația corectă depinde de ceea ce expune furnizorul.

API-uri cu costul furnizorului

Acolo unde punctele finale de cost ale furnizorului expun segmente zilnice și dimensiuni de grupare, cum ar fi proiect, utilizator, API cheie, model, element rând, spațiu de lucru sau tip de simbol, începeți de aici. Comparați segmentele zilnice de costuri decontate cu pachetele zilnice ale gateway-ului dvs. folosind aceleași dimensiuni. Nu comparați un tablou de bord la nivel de chiriaș direct cu totalul unei organizații furnizor, decât dacă acoperirea chiriașilor este completă.

Exemplu de cereale de comparație:

• date_utc
• furnizor
• provider_project_id sau workspace_id
• api_key_id dacă este disponibil
• model sau resolved_model
• line_item sau token_type
• moneda

Servicii model facturate în cloud

Pentru serviciile facturate în cloud, exportul facturii poate să nu includă identificatori per cerere. În acest caz, asociați jurnalele de invocare la exportul de cost și utilizare la un cereale mai grosiere, cum ar fi ziua, modelul, regiunea și tipul de utilizare. Utilizați jurnalele la nivel de solicitare pentru alocarea chiriașilor, dar utilizați exportul de facturare în cloud pentru totalul facturilor.

Exemplu de cereale de comparație:

• usage_date_utc
• cloud_account_id sau billing_account_id
• cloud_project_id
• regiunea
• model_id
• usage_type sau SKU
• invoice_month

Realitate: documentația AWS Bedrock descrie utilizarea câmpurilor Raport de cost și utilizare, cum ar fi modelul, tipul de jeton, nivelul de serviciu și inferența între regiuni în datele tipului de utilizare, în timp ce se utilizează jurnalele de invocare a modelului pentru identitatea cererii, numărul de simboluri, ID-ul modelului, regiunea și ID-ul cererii. Documentația recomandă asocierea jurnalelor de invocare cu CUR la model, tipul de utilizare și cereala zilei pentru totaluri exacte la factură.

Un flux de lucru practic de reconciliere

Utilizați acest flux de lucru atunci când finanțele raportează o nepotrivire a facturii.

Pasul 1: înghețați comparația

Alegeți un furnizor, o perioadă de facturare, o monedă și o comparație. Exportați numărul tabloului de bord, raportul de cost al furnizorului și exportul de facturare în cloud în același timp. Înregistrați marcajele de timp ale exportului. Multe echipe pierd ore în șir comparând ținte în mișcare.

Pasul 2: separați dolari estimați și decontați

Împpărțiți rândurile în estimated_cost și settled_cost. Costul estimat provine din tabelul de prețuri pentru gateway. Costul decontat provine din datele de facturare ale furnizorului sau din cloud. Nu suprascrie niciodată unul cu celălalt; stocați ambele și urmăriți variația.

Pasul 3: Normalizați dimensiunile

Creați un tabel de mapare pentru furnizor, model, model rezolvat, element rând, tip de indicativ, nivel de serviciu, regiune, proiect, spațiu de lucru, API cheie și chiriaș. Includeți un grup „necunoscut” sau „neatribuit”. O alocare forțată este mai rea decât un decalaj explicit, deoarece ascunde soluția operațională.

Pasul 4: reconciliați totalurile de sus în jos

Începeți cu totalul organizației furnizorului versus totalul facturii furnizorului. Apoi comparați pe zi. Apoi comparați după model și element rând. Numai după trecerea acestora ar trebui să comparați alocarea chiriașilor sau a cheii cu API. Această comandă vă indică dacă problema este prețul global, variația în intervalul de timp sau atribuirea.

Pasul 5: investigați varianța în funcție de clasă

Folosiți cele cinci clase ca listă de verificare:

• Derivarea ferestrei de timp: Nepotrivire UTC, gruparea locală a datei, data finalizării lotului, luna facturii, utilizare cu întârziere.
• Derivarea dimensiunii: nepotrivire proiect/spațiu de lucru, cheia API lipsă, model nemapat, eticheta locatarului lipsă.
• Derivarea prețurilor: indicative de memorie cache, nivel de serviciu, regiune, prețuri pe lot, elemente rând fără simboluri, tabel de prețuri învechite.
• Solicitare deviere ciclului de viață: reîncercări, alternative, anulări în flux, eșecuri parțiale ale loturilor, expirări.
• Derivarea decontării furnizorului: credite, corecții, segmente întârziate, exporturi de costuri modificate.

Pasul 6: aplicați pragurile de varianță

Cazurile de utilizare diferite necesită toleranțe diferite. Un tablou de bord de inginerie poate tolera o mică variație pentru perioadele deschise dacă este marcat în mod clar ca în așteptare. Un sistem de executare a bugetului poate avea nevoie de estimări conservatoare pentru a preveni cheltuirea excesivă. O factură de client ar trebui să utilizeze costuri decontate sau o politică de alocare documentată.

Recomandare: definiți pragurile după caz de utilizare, nu după furnizor. De exemplu:

• Tabloul de bord operațional: permite variații mici în perioada deschisă și arată starea în așteptare.
• Alerte privind bugetul: utilizați estimări conservatoare și reconciliați mai târziu.
• Rambursare internă: necesită segmente de furnizori stabilite plus verificări de acoperire a atribuirii.
• Factura clientului: necesită perioadă închisă, import cu costuri decontate, variație sub prag și nicio cheltuială materială neatribuită.

Model de implementare: tabele de reconciliere

O schemă simplă este adesea suficientă. Aveți nevoie de tabele separate pentru încercările operaționale, grupele de costuri ale furnizorului, cumulări normalizate și rezultatele variațiilor.

operational_attempts
- attempt_id
- internal_request_id
- tenant_id
- provider
- provider_project_id
- provider_workspace_id
- provider_api_key_id
- model_requested
- model_resolved
- region
- input_tokens
- output_tokens
- cached_input_tokens
- cache_write_tokens
- status
- retry_number
- stream_termination_status
- batch_job_id
- estimated_cost
- currency
- price_table_version
- usage_date_utc

provider_cost_buckets
- provider
- bucket_date_utc
- provider_project_id
- provider_workspace_id
- provider_api_key_id
- model
- line_item
- token_type
- service_tier
- region
- quantity
- quantity_unit
- settled_cost
- currency
- invoice_month
- imported_at

reconciliation_results
- period_start
- period_end
- grain_key
- estimated_cost
- settled_cost
- absolute_variance
- percent_variance
- variance_class
- status
- notes
- checked_at

Alegerea importantă de proiectare este păstrarea costului estimat și a costului stabilit. Odată ce sosesc datele furnizorului, puteți calcula variația fără a distruge înregistrarea operațională inițială care explica alertele și deciziile bugetare la momentul respectiv.

Remedieri comune după prima reconciliere

Prima reconciliere dezvăluie de obicei lacune operaționale. Remedierile sunt simple, dar au nevoie de proprietate pe platformă și finanțe.

• Lipsesc metadatele locatarului: necesită tenant_id, team_id sau customer_id la limita gateway-ului. Respingeți sau puneți în carantină solicitările de producție fără metadate de atribuire.
• Tabelele de prețuri învechite: prețuri ale versiunii, urmărește datele de intrare în vigoare și alertează când se modifică cataloagele modelelor furnizorilor sau paginile de prețuri.
• Reîncercați supranumărarea sau subnumărarea: ID-uri de solicitare de produs separate de ID-urile încercărilor furnizorului.
• Lacunele de anulare a fluxului: înregistrează utilizarea parțială atunci când furnizorul o returnează și înregistrează starea de terminare chiar și atunci când clientul se deconectează.
• Echivocitatea lotului: stocați ID-urile lucrărilor și comparați după data finalizării, precum și data trimiterii.
• Nepotrivirea facturilor în cloud: alăturați jurnalele de invocare la exporturile de facturare la zi, model, regiune și tipul de utilizare, în loc să vă așteptați la rânduri de factură la cerere.
• Mișcare cu întârziere inexplicabilă: importurile de costuri ale furnizorului de instantanee și rândurile de ajustări înregistrate pentru credite cu întârziere sau corecții.

Fapte, recomandări și previziuni

Fapte: Sistemele de facturare ale furnizorilor și din cloud expun diferite dimensiuni de facturare și niveluri de detaliu. Unele API-uri ale furnizorilor expun segmente zilnice de costuri și dimensiuni de grupare, cum ar fi proiect, utilizator, cheie API, model, element rând, spațiu de lucru, tip de simbol, nivelul de serviciu, zona geografică și moneda, în funcție de punctul final și de mediu. Exporturile de facturare în cloud includ de obicei etichete de proiecte sau resurse, marcaje de timp, luna de facturare, credite, corecții, SKU-uri, locații și tipuri de utilizare. Serviciile model facturate în cloud pot necesita jurnalele de invocare pentru atribuirea la nivel de solicitare.

Recomandări: Păstrați un registru de utilizare operațional și un registru cu costuri decontate. Comparați la cel mai mic cereale partajate de încredere. Păstrați dovezile la nivel de cerere fără a stoca încărcături utile sensibile. Normalizați dimensiunile înainte de a compara. Folosiți datele de facturare stabilite ale furnizorului sau cloud pentru facturi. Tratează cheltuielile neatribuite ca pe o problemă de calitate a datelor, nu ca pe ceva de ascuns cu o alocare combinată.

Predicții: Reconcilierea facturării LLM va deveni mai importantă pe măsură ce echipele folosesc mai multe solicitări stocate în cache, joburi în loturi, niveluri de servicii, rute alternative și servicii model găzduite în cloud. API-urile de facturare a furnizorilor se vor îmbunătăți probabil, dar nu vor elimina necesitatea metadatelor interne ale chiriașilor, deoarece furnizorii nu pot deduce clientul, echipa sau ierarhia fluxului de lucru.

Concluzie

Când un tablou de bord LLM nu se potrivește cu factura furnizorului, răspunsul este rareori o eroare. De obicei, este o nepotrivire între estimările operaționale, costurile decontate de furnizor, dimensiunile de facturare în cloud și regulile interne de atribuire.

Remedierea durabilă este un manual de reconciliere: păstrați registre operaționale și decontate separate, clasificați variația în fereastră de timp, dimensiune, preț, ciclu de viață sau decontare, păstrați dovezile la nivel de cerere și facturați numai din perioadele stabilite după verificări ale variațiilor. Acest lucru oferă echipelor de inginerie control rapid, fără a cere finanțelor să aibă încredere în cifrele provizorii ca dolari finali.

Lectură asociată

• reconcilierea zilnică pentru registrele de costuri LLM per echipă