Creeu un llibre de facturació de l'API d'IA: cotitzeu, reserveu, liquideu i concilieu cada model de trucada

La facturació de l'API AI orientada al client no pot ser una exportació mensual de l'ús del proveïdor en brut. Si una passarel·la exposa diversos models a llogaters, equips o socis, la facturació ha de respondre a una pregunta més difícil abans que existeixi la factura: s'ha de permetre aquesta sol·licitud ara mateix i com s'explicarà el seu cost més endavant?

El patró pràctic és un llibre de facturació amb quatre etapes: cotitzar, reservar, liquidar i conciliar. Citeu el cost probable abans de la sol·licitud. Reserveu el pressupost de l'inquilí suficient per cobrir el pitjor dels casos permès. Liquideu el cost real després de conèixer-ne l'ús. Reconcilieu el llibre major de la passarel·la amb els registres del proveïdor perquè les factures es puguin defensar.

Aquest article descriu aquest bucle de control per a una passarel·la d'API multimodel. És útil tant si la passarel·la factura als equips interns, als clients de prepagament, als clients de l'agència o als socis posteriors.

El problema de facturació: l'ús del proveïdor no és una factura del client

Fet: els principals proveïdors d'IA no exposen un comptador de fitxes universals ni un preu universal. L'OpenAI publica preus per model amb tarifes de testimoni d'entrada, d'entrada a la memòria cau i de sortida separades. L'emmagatzematge a la memòria cau de les sol·licituds d'OpenAI informa de l'ús de testimonis en memòria cau al camp d'ús de la resposta de l'API. Documents antròpics comptadors separats per a fitxes d'entrada normals, fitxes d'entrada de creació de memòria cau, fitxes d'entrada de lectura de memòria cau i fitxes de sortida. El preu de Gemini distingeix les entrades, les sortides i altres categories de testimonis, inclòs l'ús específic de la modalitat, com ara els testimonis d'àudio.

Això significa que una passarel·la no pot facturar de manera segura multiplicant total_tokens per un preu. Necessita adaptadors específics del proveïdor darrere d'un esquema de facturació neutral per al proveïdor.

El problema es fa més visible en aquestes situacions:

• Crèdits de prepagament: la passarel·la ha de rebutjar les sol·licituds abans que l'inquilí gasti per sota de zero.
• Marcs del partner: el soci necessita la seva pròpia factura orientada al client, no una còpia de la factura del proveïdor.
• Transmissió en temps real: la resposta comença abans que es conegui l'ús final del testimoni.
• Memòria a la memòria cau: l'entrada en memòria cau pot ser més barata que l'entrada sense memòria cau, però només si es mesura per separat.
• Raonament i ús d'eines: alguns models exposen dimensions d'ús addicionals, classes de sortida ocultes o unitats multimèdia.
• Canvis de preu del proveïdor: una factura del mes passat encara s'ha de poder reproduir després de canviar la fitxa de tarifes.

Recomanació: tracteu la facturació com un llibre comptable financer només adjunt, no com una consulta del tauler de control sobre els registres de sol·licituds.

L'arquitectura principal

Una arquitectura de facturació fiable té sis components:

1. Compte d'inquilí: client, espai de treball, client distribuïdor o centre de costos intern.
2. Servei de tarifes: preus versionats per a proveïdor, model, classe de facturació, moneda i regla de marcatge.
3. Estimador: calcula un pressupost previ a partir dels paràmetres de la sol·licitud i la política del model.
4. Llibre de reserves: conté el pressupost abans que comenci la trucada del proveïdor.
5. Normalitzador d'ús: converteix els camps d'ús específics del proveïdor en unitats de facturació internes.
6. Fines de liquidació i conciliació: finalitzeu els càrrecs i compareu-los amb els registres del proveïdor.

El flux de control té aquest aspecte:

sol·licitud del client
  -> autenticar l'arrendatari i la clau
  -> seleccioneu el model i la versió de la targeta de tarifes
  -> estimació del cost d'entrada i sortida màxima
  -> reserva el saldo del llogater
  -> proveïdor de trucades
  -> normalitzar l'ús retornat
  -> liquidar el cost real
  -> allibera la reserva no utilitzada
  -> emet un esdeveniment de registre llest per a la factura

L'opció de disseny important és que la sol·licitud no s'observi simplement. Està controlat financerament abans i després de l'execució.

Pas 1: pressupost abans de la trucada del proveïdor

Una cotització prèvia al control ha de ser prou pessimista per fer complir els pressupostos, però prou explicable per mostrar-la als clients o als socis.

Les entrades solen incloure:

• Identificador de l'arrendatari i pla de facturació;
• Identificador de clau de l'API o identificador de projecte;
• identificador de proveïdor i model després d'aplicar les regles d'encaminament;
• indicadors d'entrada sense memòria cau estimats;
• idoneïtat coneguda per a l'entrada en memòria cau, si està disponible;
• max_tokens, max_output_tokens o límit de sortida equivalent;
• eina, imatge, àudio o altres paràmetres de modalitat;
• Regla de marcatge, descompte o preu de distribuïdor per a partners;
• política de moneda i arrodoniment.

Una fórmula de cita simple per a la generació de text podria ser:

cost_estimat =
  estimated_uncached_input_tokens * taxa d'entrada
+ estimated_cached_input_tokens * cached_input_rate
+ max_output_tokens * output_rate+ request_fee
+ partner_markup

Recomanació: quan es desconeix la longitud final de la sortida, reserveu-lo contra la sortida màxima configurada. Si l'aplicació deixa el límit de sortida sense límits, la passarel·la hauria d'aplicar un inquilí o un model predeterminat. L'execució del pressupost no pot ser determinista si no hi ha responsabilitat màxima.

Això pot rebutjar algunes sol·licituds que a la pràctica haurien estat barates. Aquesta és la compensació. Per als sistemes de prepagament, el predeterminat més segur és la reserva pessimista amb els fons no utilitzats alliberats després de la liquidació. Per als clients empresarials amb facturació, els equips poden permetre excés suaus i utilitzar el pressupost principalment per a alertes.

Pas 2: reserva el pressupost de l'inquilí

La reserva protegeix el compte de l'arrendatari de gastar més del saldo permès. Hauria de ser atòmic: o bé la reserva té èxit i la trucada del proveïdor pot començar, o la sol·licitud es rebutja abans que s'incorre en cap cost del proveïdor.

Un registre de reserva pot incloure:

{
  "reservation_id": "res_01J...",
  "tenant_id": "arrendatari_123",
  "api_key_id": "key_456",
  "request_id": "req_789",
  "proveïdor": "proveïdor_exemple",
  "model": "model-a",
  "rate_card_version": "2026-08-01",
  "quoted_amount": "0,032100",
  "currency": "USD",
  "status": "reservat",
  "expires_at": "2026-08-11T12:05:00Z"
}

Utilitzeu venciments curts de reserva per a errors de xarxa i desconnexions de clients. Una tasca de neteja hauria d'alliberar les reserves caducades que mai no han arribat a la liquidació. Tanmateix, no allibereu una reserva simplement perquè el client s'ha desconnectat; la trucada del proveïdor encara podria completar-se i suposar un cost. Feu un seguiment de l'estat de la sol·licitud del proveïdor per separat.

Recomanació: feu que la reserva sigui idempotent mitjançant l'identificador de sol·licitud o la clau d'idempotència. Els reintents de clients, passarel·les o treballadors no haurien de crear diverses retencions de pressupost per a la mateixa sol·licitud lògica.

Pas 3: normalitzar l'ús del proveïdor

Les respostes del proveïdor s'han de convertir en un petit esquema intern. Manteniu-lo estable encara que els proveïdors afegeixin camps d'ús nous.

Un esquema pràctic d'ús normalitzat:

{
  "input_uncached_tokens": 1200,
  "input_cached_tokens": 800,
  "cache_write_tokens": 0,
  "output_tokens": 650,
  "reasoning_or_hidden_output_tokens": 0,
  "tool_or_media_units": [],
  "request_fee_units": 1,
  "provider_request_id": "prov_abc",
  "usage_source": "resposta_proveïdor",
  "és_estimat": fals
}

Aquest esquema no és intencionadament idèntic a la resposta de cap proveïdor. Captura les dimensions de facturació que necessiten les factures alhora que conserva les escotilles d'escapament per a les unitats específiques del proveïdor.

Les fitxes en memòria cau necessiten la seva pròpia línia

Fet: l'emmagatzematge en memòria cau d'indicacions pot tenir un preu diferent de l'entrada sense memòria cau. Si els testimonis emmagatzemats en memòria cau es fusionen amb el total de testimonis d'entrada, és possible que el client pagui un sobrecàrrec o la passarel·la pot subestimar el cost del proveïdor. L'entrada a la memòria cau hauria d'aparèixer com a classe de facturació pròpia tant al llibre major com a la factura.

Les escriptures de la memòria cau i les lectures de la memòria cau no sempre són iguals

Alguns proveïdors distingeixen entre crear entrades de memòria cau i llegir des de la memòria cau. El normalitzador no hauria de suposar que l'entrada en memòria cau sempre significa una tarifa de facturació. Si un proveïdor té testimonis d'escriptura de memòria cau i testimonis de lectura de memòria cau, assigneu-los per separat o preserveu-los com a subunitats específiques del proveïdor.

El raonament i la sortida oculta necessiten una política

Alguns models exposen l'ús relacionat amb el raonament o els comptadors de sortida ocults. Si el proveïdor factura aquestes unitats, la passarel·la ha de decidir si les mostra directament, si les inclou en una categoria de sortida o si les inclou en una línia de factura independent.

Recomanació: les factures dirigides al client han d'utilitzar un llenguatge senzill. Per exemple: "indicadors de sortida de raonament" és més clar que el nom de camp d'un proveïdor en brut. Manteniu els camps sense processar disponibles per a l'auditoria, però no obligueu tots els clients a comprendre els aspectes interns del proveïdor.

Pas 4: liquideu el cost real

La liquidació converteix l'ús normalitzat en entrades finals del llibre major. Hauria de ser només adjunt i fer referència a la versió de la targeta de tarifes utilitzada per a la sol·licitud.

Un esdeveniment resolt podria semblar així:

{
  "ledger_event_id": "led_01J...",
  "event_type": "assentament",
  "tenant_id": "arrendatari_123",
  "request_id": "req_789",
  "reservation_id": "res_01J...",
  "proveïdor": "proveïdor_exemple",
  "model": "model-a",
  "rate_card_version": "2026-08-01",
  "línies": [
    {
      "billing_class": "input_uncached_tokens",
      "quantitat": 1200,
      "unit": "token",
      "unit_price": "0,00000250",
      "import": "0,003000"
    },
    {
      "billing_class": "input_cached_tokens",
      "quantitat": 800,
      "unit": "token",
      "unit_price": "0,00000125",
      "import": "0,001000"
    },
    {
      "billing_class": "fitxes de sortida",
      "quantitat": 650,
      "unit": "token","unit_price": "0,00001000",
      "quantitat": "0,006500"
    }
  ],
  "total_amount": "0,010500",
  "currency": "USD",
  "status": "assentat"
}

Si la sol·licitud s'ha reservat per a 0,032100 i es va liquidar a 0,010500, el llibre major allibera 0,021600 al saldo disponible.

Recomanació: no torneu a calcular mai les línies de factura antigues de la taula de preus actual. Emmagatzemeu versions immutables de tarifes i adjunteu l'identificador de versió a cada pressupost, reserva i esdeveniment de liquidació. En cas contrari, pot ser que no es pugui reproduir una factura després que un proveïdor actualitzi els preus del model.

Sol·licituds de reproducció en temps real: reserva primer, liquida després

La transmissió en temps real complica la facturació perquè l'usuari comença a rebre la sortida abans que la passarel·la conegui l'ús final. La resposta és no saltar-se els controls previs al vol. La passarel·la s'ha de reservar abans d'obrir el flux.

Utilitzeu aquest flux de treball:

1. Calculeu els testimonis d'entrada i el cost màxim de sortida.
2. Reservi el pressupost de l'inquilí.
3. Obre el tauler d'activitat del proveïdor.
4. Reenvia els fragments al client.
5. Captureu l'ús final quan el proveïdor l'enviï o quan hi hagi un registre d'ús de seguiment disponible.
6. Liquida el cost real i allibera la reserva no utilitzada.

Si l'ús final no està disponible, marqueu la liquidació com a estimada en lloc de fingir que és exacta:

"usage_source": "estimació_gateway",
"és_estimat": cert,
"reconciliation_status": "pendent"

Recomanació: la conciliació diària hauria de prioritzar els esdeveniments de transmissió estimats, les sol·licituds fallides, els temps d'espera i els reintents. Aquestes són les àrees amb més probabilitats de crear variacions entre els registres de la passarel·la i les factures del proveïdor.

Regles de versions i marques de tarifes

Una fitxa de tarifes ha de ser un objecte versionat, no un full de càlcul mutable.

Camps mínims:

• proveïdor;
• ID del model;
• classe de facturació;
• unitat, com ara testimoni, sol·licitud, imatge, segon d'àudio o unitat d'eina;
• preu per unitat;
• moneda;
• marques de temps efectives d'inici i final;
• política d'arrodoniment;
• pla d'inquilí o regla de marcatge del soci;
• referència de la font i metadades d'aprovació.

Les regles de marcatge han de ser explícites. Per exemple:

• Cost més: cost del proveïdor més un 20%.
• Comerç al detall fix: l'arrendatari paga un preu de testimoni fix independentment del preu del proveïdor.
• Grans: primer 10 milions de fitxes a una tarifa, després una tarifa més baixa.
• Crèdits inclosos: l'ús consumeix un subsidi mensual abans que comenci la facturació per excés.

Compartiment: la versió de la targeta de preus afegeix treball operatiu, però evita que les disputes de factures es converteixin en arqueologia. Un agent d'atenció al client hauria de poder explicar per què una sol·licitud del 3 d'agost es va facturar a una tarifa específica sense comprovar el preu del proveïdor d'avui.

Separeu el llibre de facturació de les analítiques

L'anàlisi i la facturació tenen toleràncies diferents. Les analítiques es poden agregar, retardar, mostrejar o corregir. La facturació ha de ser completa, idempotent, auditable i explicable.

Utilitza l'anàlisi per a preguntes com ara:

• Quins equips fan servir més fitxes?
• Quins models creixen més ràpidament?
• On pot reduir el cost l'emmagatzematge en memòria cau d'indicacions?
• Quines claus produeixen sol·licituds inusualment cares?

Utilitzeu el llibre de facturació per a preguntes com ara:

• S'ha autoritzat aquesta sol·licitud amb el saldo de l'arrendatari?
• Quina versió de la targeta de preus ha generat aquest càrrec?
• S'ha alliberat la reserva no utilitzada?
• La factura del client coincideix amb l'ús establert?
• L'ús de la passarel·la coincideix amb l'ús del proveïdor?

Fet: les convencions semàntiques d'OpenTelemetry GenAI inclouen atributs d'ús de testimonis, com ara testimonis d'entrada i sortida. Això és útil per a l'observabilitat i unir traces als esdeveniments de costos. Però els atributs de telemetria no substitueixen les tarifes, les reserves, la liquidació, l'arrodoniment i l'estat de la factura.

Flux de treball de conciliació diària

La conciliació compara el registre liquidat de la passarel·la amb l'ús del proveïdor. L'objectiu no és un acord perfecte en tots els camps intermedis. L'objectiu és detectar la variació del material amb prou antelació per corregir les factures, les tarifes o els adaptadors.

Una feina pràctica diària:

1. Agrupa els esdeveniments del registre de passarel·la per proveïdor, model, inquilí o clau d'API, classe de facturació i dia UTC.
2. Obtén l'ús del proveïdor agrupat per dimensions disponibles, com ara l'identificador de la clau de l'API, el model i el dia.
3. Normalitzeu les exportacions del proveïdor mitjançant el mateix codi d'adaptador que s'utilitza per a les respostes de sol·licitud, sempre que sigui possible.
4. Compara quantitats i costos per classe de facturació.
5. Marqueu la variació per sobre dels llindars, com ara una diferència de quantitat del 0,5% o qualsevol diferència de cost absoluta gran.
6. Classifica les causes de la variació: estimacions en temps real, reintents, sol·licituds fallides, comptabilitat de memòria cau, canvis d'àlies de model, registres de proveïdors retardats o identificadors de sol·licituds que falten.
7. Creeu esdeveniments d'ajustament en lloc d'editar esdeveniments de liquidació antics.

Recomanació: utilitzeu les claus de l'API del proveïdor per inquilí quan sigui operativament viable perquè simplifica la conciliació. Si això crea massa sobrecàrrega de gestió de claus, assigneu els identificadors interns d'inquilí a les metadades del proveïdor on sigui compatible i manteniu un pont d'identificació de sol·licitud fiable.

Línies de facturació que els clients poden entendre

Una factura orientada al client no hauria de reflectir el JSON del proveïdor. Hauria d'explicar la factura en termes comercials estables.

Columnes de factura útils:

• interval de dates;
• etiqueta de clau d'inquilí, projecte o API;
• model o perfil del model;
• recompte de sol·licituds;
• indicadors d'entrada sense memòria cau;
• indicadors d'entrada en memòria cau;
• indicadors de sortida;
• unitats de suport o eina, si escau;
• descomptes, crèdits o majors;
• import total i moneda.

Per als socis, inclou tant el cost a l'engròs com el preu al detall només si el model de negoci ho requereix. Moltes factures de distribuïdors només haurien de mostrar l'ús de la venda al detall, mentre que els taulers de control dels socis poden mostrar el marge per separat.

Compartiment: un esquema de factura unificat millora la llegibilitat, però els detalls de facturació específics del proveïdor encara necessiten escotilles d'escapament. Manteniu les línies de factura senzilles de manera predeterminada i proporcioneu una exportació per als clients avançats que necessiten camps d'auditoria detallats.

Llista de verificació d'implementació

Abans del llançament

• Definiu classes de facturació normalitzades per a tots els proveïdors admesos.
• Creeu versions de tarifes immutables amb dates efectives.
• Requereix majúscules de sortida o aplica els valors predeterminats de la passarel·la.
• Implementeu reserves atòmiques amb claus d'idempotència.
• Estableix regles d'arrodoniment per a cada moneda.
• Decidiu com facturar els testimonis de la memòria cau, els testimonis de raonament, les unitats multimèdia i les tarifes de sol·licitud.
• Reintents de prova, temps d'espera, desconnexions de clients i errors del proveïdor.
• Crea un mecanisme d'ajust d'esdeveniments en lloc d'editar esdeveniments resolts.

Durant la gestió de sol·licituds

• Autentiqueu l'arrendatari i la clau.
• Resol el model final després de la política d'encaminament i alternativa.
• Seleccioneu la versió de tarifa correcta.
• Cotitzeu el cost del pitjor cas.
• Reserva el saldo o rebutja la sol·licitud.
• Registreu l'identificador de sol·licitud del proveïdor quan estigui disponible.
• Normalitzeu l'ús a partir de la resposta.
• Liquida, allibera la reserva no utilitzada i emet esdeveniments preparats per a facturar.

Després de la gestió de la sol·licitud

• Executeu la conciliació diària per proveïdor, clau, model, classe de facturació i dia.
• Reviseu les liquidacions de transmissió estimades.
• Marca l'ús del model amb les entrades de tarifes que falten.
• Supervisa la variació causada per la comptabilitat dels testimonis en memòria cau.
• Genereu visualitzacions prèvies de les factures dels clients abans de la facturació final.

Prediccions per planificar

Predicció: la facturació de l'API de l'IA serà més multidimensional, no menys. És probable que les classes de testimonis, les classes de memòria cau, les unitats multimèdia, l'execució d'eines i els comptadors relacionats amb el raonament es continuïn expandint a mesura que canvien les capacitats del model.

Predicció: els clients esperaran explicacions d'ús a nivell de sol·licitud, clau, projecte i factura. Un total mensual sense línies de comanda traçables serà insuficient per als equips que venen accés a l'API o que facin complir pressupostos de prepagament.

Predicció: les passarel·les que ja separen la cotització, la reserva, la liquidació i la conciliació s'adaptaran més ràpidament als nous models de preus perquè poden afegir classes de facturació sense reescriure tot el sistema de facturació.

Conclusió accionable

Si exposeu diversos proveïdors d'IA mitjançant una passarel·la, creeu el llibre de facturació abans que les disputes de facturació obliguin el problema. Comenceu amb quatre garanties:

1. Cada sol·licitud facturable rep un pressupost previ al vol.
2. Tots els inquilins de prepagament o amb límits tenen un pressupost reservat abans que comenci la trucada del proveïdor.
3. Cada resposta del proveïdor es normalitza en classes de facturació estables.
4. Cada factura es pot conciliar amb l'ús del proveïdor i la versió exacta de la targeta de tarifes utilitzada en aquell moment.

Aquest bucle de control fa que la facturació unificada de l'API de l'IA sigui comprensible per als clients, s'aplica als crèdits de prepagament, flexible per a les marques de socis i auditable quan canvien els preus dels proveïdors o els formats d'ús.

Lectura relacionada

• unir traces LLM amb registres d'ús i costos
• creació de portals de distribuïdors amb mesura de l'ús de l'inquilí
• ús de la memòria cau d'indicadors alhora que la facturació és comprensible