Com crear un registre de costos de LLM per equip a través de diverses API d'IA

Els taulers de control dels proveïdors us poden indicar què ha gastat una organització. Poques vegades responen a la pregunta que realment necessiten respondre els equips financers i de plataformes: quin equip, producte, entorn, càrrega de treball o segment de clients ha causat la despesa i si s'esperava aquesta despesa.

El patró durador no és un altre tauler. Es tracta d'un registre de costos intern: un sistema de registre que combina metadades de sol·licitud de l'aplicació, claus de l'API amb àmbit, dades d'ús del proveïdor i totals de facturació a nivell de factura. El llibre major ofereix als equips d'enginyeria una visibilitat operativa gairebé en temps real, alhora que ofereix a les finances una visió conciliada que pot donar suport als pressupostos, l'assignació i la devolució de càrrecs.

Aquest article exposa una arquitectura pràctica per als equips que utilitzen més d'una API d'IA, inclòs el contracte d'etiquetatge, el flux de sol·licituds, les taules, el procés de conciliació, els controls i les compensacions.

El problema: la facturació del proveïdor és precisa però no sempre es pot assignar

La majoria de proveïdors d'IA exposen alguna combinació de taulers d'ús, API d'ús, exportacions de facturació, projectes, espais de treball, comptes de servei o API de costos. Aquestes eines són útils, però no totes funcionen amb el mateix nivell de detall.

Fets

• Alguns punts finals de costos del proveïdor estan dissenyats per a informes financers i poden desglossar la despesa per línies de facturació, projectes o períodes de facturació.
• Les API d'ús sovint proporcionen detalls operatius, però és possible que els registres d'ús i els registres de costos finals no es conciliin perfectament a causa de descomptes, crèdits, facturació retardada, preus de compromís, tarifes per lots, preus de memòria cau o ajustos de les factures.
• Els límits administratius natius, com ara projectes, espais de treball, comptes de servei, claus d'API o directors d'IAM poden ajudar a atribuir la despesa, però les capacitats exactes difereixen segons el proveïdor.
• En algunes plataformes, les metadades per sol·licitud apareixen als registres d'invocació en lloc dels informes d'assignació de costos. Els equips han d'agregar els registres i aplicar tarifes per estimar el cost a nivell de sol·licitud.

Recomanació

Traiteu les dades del proveïdor com una entrada, no com a tot el sistema. Creeu un llibre major intern que pugui respondre a qüestions operatives i financeres i, a continuació, concilieu-lo amb les fonts de costos del proveïdor cada dia.

The Ledger Architecture

Un registre de costos té cinc components principals:

1. Un esquema de dimensions de cost estable.
2. Credencials d'abast i regles d'encaminament.
3. Captura de metadades a nivell de sol·licitud.
4. Ús del proveïdor i ingesta de costos.
5. Reconciliació diària i aplicació de polítiques.

L'objectiu és produir dues vistes relacionades: un llibre major estimat per sol·licitud per a les operacions i un llibre diari conciliat per a les finances.

Aquest és un element bàsic comú en el control de costos de l'API AI més ampli perquè connecta la telemetria d'enginyeria amb la responsabilitat financera sense dependre del model d'informes d'un sol proveïdor.

Pas 1: definiu les dimensions del cost abans de crear taulers

Comenceu amb les dimensions que els equips de finances, enginyeria, producte i seguretat utilitzaran de manera coherent. Feu-ho abans de seleccionar gràfics o escriure tasques d'ingestió.

Un esquema pràctic normalment inclou:

• team_id: l'equip d'enginyeria o empresa propietari.
• product_id: el producte, l'àrea de funcions o la plataforma interna que utilitza l'API.
• entorn: producció, posada en escena, desenvolupament, sandbox, demostració o prova.
• càrrega de treball: xat, resum, extracció, classificació, generació de codi, avaluació, incrustació, reclassificació o processament per lots.
• segment_client: segments empresarials, de mercat mitjà, de prova gratuïta, interns, de socis o d'altres segments aprovats.
• budget_owner: la persona, l'equip o el centre de costos responsable de la despesa.
• proveïdor: el proveïdor de l'API d'IA utilitzat per a la sol·licitud.
• model: el model exacte o l'identificador de desplegament.
• request_class: interactiu, en segon pla, per lots, reintentar, alternativa, avaluació o administrador.

Mantingueu l'esquema prou petit perquè els enginyers l'omplin. Afegiu govern per evitar la deriva del text lliure. Per exemple, team_id hauria de provenir d'un registre d'equip intern, no de capçaleres de sol·licituds arbitràries.

Detall de la implementació

Representeu les dimensions com un contracte versionat. Una sol·licitud que no té les etiquetes de producció necessàries hauria de fallar en tancar-se a la passarel·la o dirigir-se a un cub de quarantena amb un nom clar que es revisa diàriament.

{
  "schema_version": "2025-01",
  "team_id": "plataforma-ai",
  "product_id": "assistent de suport",
  "environment": "producció",
  "workload": "resum",
  "customer_segment": "empresa",
  "budget_owner": "centre de costos-4812","request_class": "interactiu"
}

Pas 2: emet claus d'abast per equip i entorn

Les claus d'API monolítices compartides fan que l'assignació de costos sigui fràgil. Si tots els serveis utilitzen la mateixa credencial, les finances no poden atribuir la despesa amb confiança i els equips de la plataforma no poden desactivar una càrrega de treball sense afectar els sistemes no relacionats.

Utilitzeu les credencials amb àmbit sempre que sigui possible:

• Una clau o compte de servei per equip i entorn.
• Credencials separades per a les càrregues de treball de producció i no de producció.
• Credencials separades per a experiments, avaluacions i treballs per lots d'alt risc.
• Projectes o espais de treball natius del proveïdor quan s'assignen clarament a la propietat interna.

Això no vol dir que cada microservei necessiti un compte de proveïdor únic. Massa límits creen una sobrecàrrega operativa. La unitat útil és el límit on la propietat, el pressupost i la resposta operativa difereixen.

Nota de seguretat

Les claus de l'API i els testimonis de seguretat no s'han d'enviar als URL perquè els URL es capturen habitualment als registres, servidors intermediaris, eines d'anàlisi i historials del navegador. Col·loqueu les credencials a les capçaleres o als magatzems secrets gestionats, gireu-les a través d'un procés automatitzat i registreu els esdeveniments clau del cicle de vida per respondre a incidents.

Pas 3: captura les metadades de la sol·licitud a la passarel·la o la capa d'aplicació

El llibre major necessita més que un recompte de fitxes. Necessita prou context per explicar per què s'ha produït la despesa i si ha estat útil.

Per a cada trucada de LLM, captura:

• Identificador de sol·licitud interna i identificador de traça distribuïda.
• Identificador de sol·licitud del proveïdor quan es retorna.
• Proveïdor, model, regió i punt final.
• Equip, producte, entorn, càrrega de treball, segment de clients i propietari del pressupost.
• Fitxas d'entrada, fitxes de sortida, fitxes de memòria cau, fitxes de raonament, unitats d'inserció, unitats d'imatge o altres unitats facturables quan estiguin disponibles.
• Latència, recompte de reintents, ruta alternativa, estat de temps d'espera i codi d'error.
• La memòria cau en error o error.
• Classe de sol·licitud: producció, avaluació, reintent, lots o experiment.

Una passarel·la central facilita això perquè cada trucada del proveïdor passa per un punt d'aplicació. Si una passarel·la central no és factible, utilitzeu una biblioteca de client compartida i requereixi que els serveis emetin el mateix format d'esdeveniment.

No registreu-ho tot per defecte

El contingut de sol·licitud i sortida pot ajudar amb la depuració i l'auditabilitat, però també crea obligacions de privadesa, retenció i control d'accés. Per a molts equips, el valor predeterminat hauria de ser metadades, recomptes de testimonis, identificadors de models i identificadors de traça. Emmagatzema el contingut de sol·licitud i sortida només sota una política explícita amb límits de retenció i controls d'accés.

Pas 4: manteniu dues taules de costos

Intentar que una taula serveixi per a tots els propòsits sol generar confusió. Construeix dos llibres de llibres amb feines diferents.

Llibre estimat per sol·licitud

Aquesta taula admet operacions gairebé en temps real. És granular, ràpid i aproximat.

Les columnes útils inclouen:

• request_id
• provider_request_id
• marca de temps
• equip_id
• product_id
• entorn
• càrrega de treball
• proveïdor
• model
• unitats_facturables
• versió_targeta_de_tarifes
• cost_estimat_usd
• latency_ms
• codi_estat
• retry_count
• s'ha utilitzat de manera alternativa
• estat_cache

El cost estimat s'ha de calcular a partir de les millors dades d'unitats facturables disponibles i d'una targeta de tarifes interna versionada. Manteniu la versió de la fitxa de tarifes a cada fila perquè les estimacions històriques es puguin explicar més endavant.

Llibre diari conciliat amb factures

Aquesta taula admet informes financers. És menys granular, més lent i més proper a la realitat de la facturació final.

Les columnes útils inclouen:

• data_facturació
• proveïdor
• compte_factura
• projecte_o_espai de treball
• equip_id
• product_id
• entorn
• cost_estimat_usd
• provider_reported_cost_usd
• allocated_adjustment_usd
• reconcilied_cost_usd
• variance_reason

La taula conciliada hauria de conservar la variància en lloc d'amagar-la. Si el cost informat pel proveïdor és inferior a causa dels crèdits o superior a causa del rendiment subministrat, registreu aquesta diferència explícitament.

Pas 5: concilieu diàriament, no manualment al final del mes

La reconciliació diària fa que les sorpreses siguin petites. El procés pot ser senzill al principi:

1. Ingerir esdeveniments del llibre major a nivell de sol·licitud contínuament.
2. Ingereix els registres de costos i d'ús del proveïdor de forma programada.
3. Agrupeu les estimacions internes per proveïdor, projecte o espai de treball, model, data i dimensions d'assignació conegudes.
4. Compareu les estimacions internes amb els totals de costos informats pel proveïdor.
5. Assigna les diferències mitjançant una política documentada.
6. Escriu els motius de la variació i l'estat de conciliació.

Les categories de variació habituals inclouen descomptes negociats, crèdits del proveïdor, registres d'ús retardat, preus de testimonis en memòria cau, preus per lots, rendiment provisionat, conversió de moneda, càrrecs mínims i metadades que falten.

Exemple de política de conciliació

Si un projecte de proveïdor s'assigna a exactament un equip i un entorn, assigneu el cost diari complet informat pel proveïdor a aquest equip i registreu l'estimació interna com a detall de suport. Si un projecte de proveïdor conté diversos equips, assigneu el total informat pel proveïdor proporcionalment pel cost estimat intern i, a continuació, registreu l'ajust a cada fila d'equip.

Aquesta política no és perfecta, però és explicable. L'explicació importa més que la falsa precisió.

Pas 6: adjunteu pressupostos i controls a les dimensions del llibre major

Un cop s'atribueix la despesa, els controls es tornen més útils. Un límit únic per a tota l'organització és massa contundent per a la majoria dels equips.

Utilitza diferents controls per a diferents càrregues de treball:

• Sandbox: límits diaris o setmanals estrictes, tancament automàtic, llindar d'aprovació baix.
• Desenvolupament: alertes suaus i limitacions dures modestes.
• Avaluació: finestres per lots, propietari explícit del pressupost, data de caducitat.
• Producció: alertes suaus, flux de treball d'escalada, camí d'augment del límit d'emergència.
• Ús de l'API orientada als socis o al client: assignació a nivell de client, aplicació de quotes i supervisió d'abús.

Els límits estrictes impedeixen les factures descontrolades, però poden interrompre els fluxos de treball de producció. Utilitzeu-los amb cura a la producció i emparelleu-los amb regles d'escalada. Per a les càrregues de treball que no són de producció, els límits estrictes solen ser més fàcils de justificar.

Pas 7: detecteu anomalies més enllà de la despesa total

La despesa diària total és un senyal de retard. Les alertes millors utilitzen els camps operatius del llibre major.

Les comprovacions d'anomalies útils inclouen:

• Cost per sol·licitud satisfactòria per càrrega de treball.
• Proporció de testimonis de sortida en comparació amb la línia de base històrica.
• Percentatge de reintents per proveïdor, model i servei.
• Freqüència de retrocés de models més barats a més cars.
• Gasa la velocitat dins de l'hora actual.
• Caiguda de la taxa d'accés a la memòria cau per a les càrregues de treball que s'espera que es beneficiïn de la memòria cau.
• Despeses que no siguin de producció fora de l'horari comercial.
• Sol·licituds que falten dimensions de cost obligatòries.

Una alerta que digui que la despesa és alta és menys útil que una alerta que diu que les sol·licituds de resum de producció d'un servei generen tres vegades els testimonis de sortida normals després d'un desplegament.

Seqüència d'implementació recomanada

No intenteu crear l'arquitectura completa en una versió. Una seqüència pràctica és:

1. Definiu l'esquema de dimensions de cost i el registre de propietat.
2. Dividiu les credencials del proveïdor per equip i entorn per a les càrregues de treball amb més despesa.
3. Afegiu passarel·la o captura de metadades de la biblioteca client.
4. Creeu el llibre comptable estimat per sol·licitud.
5. Afegiu una targeta de tarifes versionada per als proveïdors i models que s'utilitzen.
6. Ingereix les dades de costos del proveïdor en una taula d'informes diaris.
7. Implementeu la conciliació diària i el seguiment de la variació.
8. Afegiu polítiques pressupostàries, alertes i fluxos de treball d'aprovació.
9. Reviseu les metadades que falten i la despesa no assignada cada setmana.

La primera fita útil no és la devolució perfecta. És la capacitat de respondre, en un dia laborable, quin equip i càrrega de treball han provocat un canvi de despesa material.

Compartiments per decidir explícitament

Taulers de control de proveïdors versus registre intern: els taulers de control de proveïdors són més ràpids d'adoptar, però poques vegades coincideixen amb les dimensions dels costos interns entre equips, productes, entorns i clients.

Granularitat versus sobrecàrrega operativa: més claus, projectes, espais de treball i etiquetes milloren l'atribució, però augmenten el treball de govern. Utilitzeu límits que coincideixin amb la propietat real.

Cost estimat versus cost de factura: les estimacions a nivell de sol·licitud són oportunes i útils per a les operacions, però no reflecteixen automàticament els crèdits, els preus negociats o els ajustos de facturació.

Porta d'enllaç central versus instrumentació distribuïda: una passarel·la ofereix una aplicació coherent entre els proveïdors, però es converteix en una infraestructura crítica. Una biblioteca de client compartida és més fàcil d'adoptar en alguns entorns, però més difícil d'aplicar.

Audibilitat versus privadesa: el registre de contingut pot ajudar amb les investigacions, però el registre només de metadades sovint és el més segur per defecte.

Predicció: els registres de costos passaran a formar part del govern de la plataforma AI

La direcció probable és que els informes natius del proveïdor millorin, però l'assignació entre proveïdors encara requerirà un context intern. Els proveïdors no poden conèixer l'estructura d'equip de cada empresa, la taxonomia del producte, la segmentació de clients, el flux de treball d'aprovació o la política de retrocàrrec.

A mesura que l'ús d'IA s'estén des dels projectes pilot als fluxos de treball de producció, els registres de costos passaran a formar part de la governança normal de la plataforma juntament amb el control d'accés, la rotació de claus, el registre d'auditoria, els límits de tarifa i l'anàlisi d'ús. Els equips que defineixin la seva taxonomia de costos aviat tindran més facilitat per afegir pressupostos, assignació a nivell de client i controls automatitzats més endavant.

Conclusió accionable

Creeu el llibre major al voltant de la responsabilitat, no dels gràfics. Comenceu amb dimensions estables, credencials amb abast i metadades de sol·licitud. Mantingueu una estimació ràpida per sol·licitud per a les operacions d'enginyeria i un registre diari conciliat per a les finances. Reconcilieu en lloc de forçar que les estimacions semblin exactes i preserveu la variació perquè els descomptes, els compromisos, els crèdits i els retards de facturació siguin visibles.

Una primera versió útil pot ser limitada: un proveïdor, les tres càrregues de treball principals, claus d'abast per equip i entorn, captura de metadades, costos estimats i una comparació diària amb els totals informats pel proveïdor. Un cop funcioni, amplieu el mateix contracte entre proveïdors i adjunteu polítiques pressupostàries a les dimensions que importen.