Reduïu els costos de l'API LLM amb treballs per lots i memòria cau ràpida: un llibre de jocs pràctic

Molts equips paguen de més per les API de LLM perquè envien totes les sol·licituds pel mateix camí sincrònic. Això és adequat per al xat, els assistents de codificació, els agents de suport, els fluxos de pagament i qualsevol cosa que estigui esperant un usuari. És un malbaratament per a les avaluacions, l'etiquetatge, l'enriquiment, les escombrades de moderació, la inserció d'emplenaments, els informes nocturns i el processament previ del contingut.

La pregunta pràctica no és "Quin model és més barat?" És: quina feina realment necessita una resposta immediata i quina pot esperar? Un cop responguis a això, el control de costos de l'API de l'IA es converteix en un flux de treball d'enginyeria: classifiqueu el trànsit, envieu tasques tolerants a la latència al processament per lots on sigui compatible, estructura les sol·licituds repetides per a la memòria cau i mesureu els estalvis reals després d'errors, reintents i operacions

Comenceu amb una auditoria de costos per càrrega de treball, no per model

Abans de canviar l'arquitectura, exporteu una mostra de l'ús recent de l'API i agrupeu-la per càrrega de treball. Una taula d'auditoria útil hauria d'incloure:

• Punt final i model: finalitzacions de xat, respostes, incrustacions, moderació o punts finals específics del proveïdor.
• Fitxa mitjana d'entrada i sortida: separeu les sol·licituds llargues de les tasques de classificació breus.
• Forma ràpida: instruccions del sistema estables, exemples reutilitzables, esquemes, context de recuperació i dades d'usuari dinàmiques.
• Requisit de latència: segons, minuts, hores o el dia laborable següent.
• Visibilitat de l'usuari: si una persona està esperant el resultat.
• Percentatge de reintents i errors: sol·licituds amb format incorrecte, errors de validació, temps d'espera del proveïdor, tasques vençudes i enviaments duplicats.
• Propietat: projecte, equip, client, clau d'API o compte de soci.
• SLA empresarial: la darrera vegada que el resultat encara és útil.

Aquesta auditoria sol revelar que el "trànsit LLM" no és una càrrega de treball. És una combinació de funcions interactives del producte, automatització interna, informes, preparació de dades i avaluació de la qualitat. Tractar-los com un centre de cost amaga els estalvis més fàcils.

Utilitzeu un classificador de càrrega de treball de tres carrils

Un classificador senzill evita que els equips traslladin el trànsit equivocat al lot i que després es sorprenguin per les expectatives perduts.

Carril 1: sol·licituds interactives en temps real

Mantingueu-los sincrònics. Inclouen UX de xat, copilots, agents de suport, revisió human-in-the-loop, fluxos de cerca o recuperació en directe i trucades a eines amb efectes secundaris immediats. Si un usuari està esperant, el valor d'una resposta més barata es pot esborrar per latència.

Recomanació: optimitzeu aquest carril amb la selecció del model, la retallada ràpida, la gestió del límit de velocitat, l'emmagatzematge a la memòria cau si escau i els reintents acudits. No l'envieu a una cua per lots de 24 hores tret que el producte el presenti explícitament com a tasca en segon pla.

Carril 2: sol·licituds properes a la línia que poden esperar minuts

Aquests treballs no necessiten bloquejar la càrrega d'una pàgina, però encara poden tenir una expectativa de la mateixa sessió o la mateixa hora. Alguns exemples inclouen l'anàlisi de documents després de la càrrega, l'enriquiment de CRM després de l'enviament del formulari o un informe que pot notificar a l'usuari quan estigui llest.

Recomanació: col·loqueu el treball de línia propera darrere d'una cua amb estats d'estat explícits. Depenent del suport del proveïdor i de la data límit, executeu-lo a través de petits lots o treballadors síncrons amb una prioritat més baixa. Aquest carril es beneficia dels identificadors de feina, dels webhooks i del progrés visible per l'usuari.

Carril 3: sol·licituds per lots fora de línia que poden esperar fins a 24 hores

Aquest és el carril principal d'optimització de costos. Els bons candidats inclouen:

• avaluacions a gran escala;
• etiquetatge del conjunt de dades;
• enriquiment de catàleg o CRM;
• resum nocturn;
• cues de revisió del compliment;
• incrustar rebliments;
• escombrats de moderació;
• generació d'informes periòdics;
• preprocessament del contingut abans de la indexació o la publicació.

Fet: els principals proveïdors ara ofereixen API de lots asíncrones per a càrregues de treball adequades. L'API Batch d'OpenAI llegeix les sol·licituds d'un fitxer penjat, escriu resultats en un fitxer de sortida i s'orienta al processament en 24 hores. OpenAI afirma que l'ús de l'API Batch compatible s'ofereix amb un descompte del 50% en comparació amb les API síncrones. L'API de lots de missatges d'Anthropic està dissenyada per a grans volums de sol·licituds de missatges, processament asíncron, rendiment més alt i cost un 50% més baix. L'API Gemini Batch de Google està dissenyada per a sol·licituds asíncrones de gran volum al 50% del cost estàndard, amb un temps de resposta objectiu de 24 hores.

Compartiment: "fins a 24 hores" és excel·lent per a ompliments i avaluacions, però inacceptable per a fluxos de treball interactius. El lot és una estratègia de programació, no un substitut universal de la inferència síncrona.

Dissenyeu la ruta per lots com un cicle de vida laboral

L'error d'implementació que cal evitar és tractar el lot com una única trucada d'API. És un cicle de vida: acceptar el treball, validar-lo, conservar-lo, enviar-lo, enquestar-lo, conciliar-lo i exposar els resultats.

Arquitectura de referència

1. Accepteu una sol·licitud normalitzada: manteniu la forma de sol·licitud a prop del vostre format d'API compatible amb OpenAI, sempre que sigui possible. Afegiu metadades com ara projecte, equip, client, clau d'idempotència, data límit sol·licitada i centre de costos.
2. Classifica la càrrega de treball: assigna la sol·licitud a un lot en temps real, gairebé en línia o fora de línia. Això hauria d'estar basat en polítiques, no amagat dins del codi de l'aplicació.
3. Creeu un identificador de feina: retorneu un identificador de feina immediatament per a treballs en línia i fora de línia.
4. Valida la compatibilitat: comproveu si el proveïdor i el model seleccionats admeten el lot per al punt final sol·licitat, la modalitat, la mida del fitxer, les eines, el format de resposta i altres funcions.
5. Persisteix les files de sol·licitud: emmagatzema les files JSONL normalitzades o les càrregues útils específiques del proveïdor. Incloeu un identificador de fila estable per a la conciliació.
6. Envia el lot: pengeu el fitxer de sol·licitud o la càrrega útil del lot en línia en funció dels límits del proveïdor i de la mida de la feina.
7. Estat de l'enquesta: fes un seguiment dels estats del proveïdor, com ara la validació, en curs, completat, fallat, caducat, cancel·lant i cancel·lat, si escau.
8. Escriu les files de sortida: escriviu respostes correctes, errors a nivell de fila, ús de testimonis, recomptes de testimonis a la memòria cau quan estiguin disponibles i identificadors de proveïdors.
9. Notificar als consumidors: exposa un punt final de recuperació, un webhook, una notificació del tauler de control o una alerta de Telegram.
10. Concilia la facturació: atribueix el cost al projecte, l'equip, el client, la clau API i l'identificador de feina originals.

Aquest patró fa que l'aplicació sigui senzilla. Els equips de producte envien treballs i reben estats de treball. La passarel·la o la capa d'orquestració gestiona les diferències de proveïdors, els fitxers per lots, els reintents i la comptabilitat.

Utilitza estats de treball explícits

Definiu estats interns encara que cada proveïdor faci servir noms diferents:

• en cua: acceptat però no enviat;
• validant: el proveïdor o la passarel·la està comprovant el fitxer;
• en execució: enviat i processant;
• completat: es recullen tots els resultats disponibles;
• completed_with_errors: algunes files no han pogut validar o executar;
• caducat: la data límit ha passat abans que s'hagin completat totes les files;
• cancel·lat: aturat per l'usuari, el sistema o la política;
• fallida: fallada a nivell de treball que requereix intervenció.

Fet: l'OpenAI documenta els estats dels lots, com ara la validació, l'error, en_progrés, completat, caducat, cancel·lat i cancel·lat. També assenyala que si un lot caduca, el treball ja acabat es retorna i es cobra mentre que el treball restant es cancel·la.

Recomanació: mai assumiu que les tasques per lots són tot o res. Creeu la gestió de l'estat a nivell de fila des del principi.

Calculeu l'estalvi després d'errors i despeses generals

Un model d'estalvi senzill és suficient per a la majoria dels equips:

baseline_cost = cost_d'entrada_sincrònic + cost_de_sortida_síncrona
batch_cost = cost_d'entrada_de_lot_descomptat + cost_de_sortida_descomptat
ajustat_batch_cost = batch_cost + orquestration_cost + storage_cost + rerun_cost
estimated_savings = baseline_cost - ajustat_batch_cost

A continuació, calculeu-ho per càrrega de treball, no globalment. Una suite d'avaluació nocturna pot estalviar substancialment. Un flux de treball proper a la línia amb moltes files malformades, alternatives urgents o repeticions repetides pot estalviar menys del que s'esperava.

Feu un seguiment d'almenys aquestes mètriques:

• Despesa de testimoni de sincronització versus lot;
• Fitxas d'entrada i sortida per model;
• nombre de treballs per lots i files mitjanes per feina;
• taxa d'errors a nivell de fila;
• taxa de feina caducada;
• cost de repetició;
• cost de recuperació a sincronització;
• cost per equip, projecte, clau, client i compte de soci.

Recomanació: tracteu la alternativa sincrònica automàtica com una excepció, no com a predeterminada. Protegeix els terminis, però si s'utilitza en excés pot esborrar els estalvis esperats. Afegiu una política com ara "refugi només si la data límit de l'empresa és de dues hores i la feina no ha començat".

Afegiu una memòria cau d'indicadors per a prefixos llargs repetits

El processament per lots redueix el preu unitari del treball apte. La memòria cau ràpida redueix el cost efectiu i la latència de les sol·licituds llargues repetides quan el comportament del proveïdor ho admet.

Fet: l'emmagatzematge a la memòria cau d'indicacions d'OpenAI s'aplica automàticament a les sol·licituds de més de 1.024 fitxes als models compatibles, emmagatzema a la memòria cau el prefix més llarg calculat prèviament i informa de cached_tokens als detalls d'ús de l'API. L'OpenAI diu que les memòries cau d'indicacions s'esborren normalment després de 5 a 10 minuts d'inactivitat i s'eliminen dins d'una hora després de l'últim ús, i que les memòries cau d'indicacions no es comparteixen entre organitzacions.

El patró d'implementació és senzill: primer el contingut estable i l'últim el contingut volàtil.

Millor estructura d'indicadors per a la memòria cau

Instruccions del sistema
Text de política estable
Esquema de sortida estable
Exemples estables
Context de referència reutilitzable
---
Entrada dinàmica específica del registre
Metadades dinàmiques d'usuari o fila

Per exemple, una tasca d'enriquiment de catàleg pot reutilitzar la mateixa taxonomia, esquema de sortida, regles de marca i exemples en 50.000 productes. Cada fila només canvia el títol, la descripció i els atributs del producte. Si col·loqueu primer el prefix reutilitzable, el proveïdor té més possibilitats de reutilitzar els càlculs en memòria cau quan sigui compatible.

Compartiment: la memòria cau no és un emmagatzematge permanent i no s'ha de tractar com a garantida. Les finestres de la memòria cau, l'aïllament, la longitud mínima de sol·licitud i els informes difereixen segons el proveïdor. Mesureu els testimonis emmagatzemats a la memòria cau en lloc d'assumir estalvis.

Valideu l'assistència del proveïdor abans de l'enviament

Les API per lots són diferents. La passarel·la hauria de validar l'elegibilitat abans d'enviar una feina.

Fets: l'API d'OpenAI Batch no admet la reproducció en temps real i té límits de velocitat per lots separats. Les limitacions dels lots de documents antròpics inclouen un límit de mida de lot de 100.000 sol·licituds o 256 MB, caducitat de 24 hores, disponibilitat de resultats de 29 dies, límits de tarifa i la possibilitat que els lots superin lleugerament els límits de despesa de l'espai de treball configurats. Google admet sol·licituds per lots en línia per a feines més petites de menys de 20 MB i fitxers d'entrada JSONL per a sol·licituds per lots més grans.

Utilitzeu una llista de verificació de compatibilitat:

• El model sol·licitat està disponible a través de l'API per lots d'aquest proveïdor?
• El punt final és compatible?
• La sol·licitud requereix streaming? En cas afirmatiu, rebutgeu el lot.
• Utilitza eines o efectes secundaris que s'han de produir immediatament?
• El fitxer per lots supera els límits del proveïdor?
• El resultat esperat segueix sent útil dins de la finestra de finalització del proveïdor?
• Les sortides estan disponibles el temps suficient perquè els sistemes posteriors les recuperin?
• La càrrega de treball pot tolerar la finalització parcial?

Recomanació: falla la validació aviat amb un motiu clar. Un candidat de lot rebutjat és més barat que un treball caducat o mal format que s'ha de tornar a treballar més tard.

Proteccions per a equips, agències i socis

Els sistemes per lots poden gastar molts diners en silenci perquè processen fitxers grans en segon pla. Afegiu controls abans del llançament ampli:

• Pressuposts per lots per equip: separen els límits de despesa en línia i fora de línia.
• Mida màxima de fitxers i nombre de files: apliqueu els límits del proveïdor i els vostres propis límits operatius.
• Cua de missatges no vàlids: conserva les files no vàlides amb errors de validació per revisar-les.
• Tecles d'idempotència: evita que els càrrecs duplicats es tornin a enviar accidentalment.
• Revisió d'IPI: els fitxers per lots poden crear noves obligacions de privadesa i de retenció de dades.
• Política de retenció: defineix quant de temps s'emmagatzemen els fitxers de sol·licitud, els fitxers de sortida i els registres.
• Política de notificacions: alerta els propietaris quan les feines fallen, caduquen o superin el pressupost.
• Atribució: enregistra el projecte, l'equip, el client, la clau API, el model, el proveïdor, l'identificador de feina i l'identificador de fila.

Per a les agències i els distribuïdors, l'atribució és especialment important. Si un soci executa tasques d'enriquiment o d'avaluació per a molts clients, el sistema hauria d'informar el cost per client i per feina, no només per factura del proveïdor.

Com s'assigna això a una passarel·la d'API AI

Una passarel·la d'API d'IA és un lloc natural per implementar-ho perquè ja es troba entre les aplicacions i els proveïdors de models. La passarel·la pot conservar una superfície d'API compatible amb OpenAI per als desenvolupadors, alhora que hi afegeix una programació conscient dels costos.

Les capacitats útils de passarel·la inclouen:

• Facturació unificada: compareu la despesa sincrònica, per lots, en memòria cau i alternativa en un sol lloc.
• Analítica de l'ús de l'IA: desglosseu l'ús per model, proveïdor, punt final, equip, projecte i clau d'API.
• Controls de l'equip: establiu pressupostos separats per a càrregues de treball interactives i fora de línia.
• Atribució de claus API: identifiqueu quin servei o client ha creat cada feina.
• Notificacions d'estat: envieu alertes quan les tasques per lots finalitzin, fallin, caduquin o s'acostin a una data límit.
• Fluxos de treball de l'API de partners: permet que les agències o els distribuïdors creïn llocs de treball i recuperin resultats en nom dels clients alhora que es preserva la comptabilitat a nivell de client.

Predicció: més equips gestionaran els costos de LLM amb polítiques de programació, no només amb substitucions de models. A mesura que el suport per lots madura entre els proveïdors, l'arquitectura guanyadora s'enviarà per urgència, compatibilitat de funcions i requisits de comptabilitat abans que s'orienti pel preu del model.

Llista de verificació d'implementació

• Exporta 30 dies d'ús de l'API LLM.
• Classifica cada càrrega de treball com a temps real, gairebé en línia o fora de línia.
• Trieu una càrrega de treball fora de línia amb una propietat clara i un termini indulgent.
• Validar el suport per lots del proveïdor per al punt final i el model necessaris.
• Definiu estats de treball interns i estats a nivell de fila.
• Afegiu claus d'idempotència, identificadors de feina i identificadors per fila.
• Emmagatzema els registres de sol·licituds i respostes normalitzats amb controls de retenció.
• Envia el primer lot darrere d'una marca de funció.
• Mesureu el cost de referència sincrònic en comparació amb el cost del lot ajustat.
• Reestructura les sol·licituds llargues repetides per posar primer els prefixos estables.
• Fes un seguiment dels testimonis emmagatzemats a la memòria cau, de les files fallides, de les tasques caducades i de la despesa alternativa.
• Amplieu només quan els estalvis i el comportament operatiu siguin visibles a l'anàlisi.

Conclusió accionable

No inicieu el control de costos de l'API de l'IA demanant a cada equip que utilitzi un model més barat. Comenceu separant el treball urgent del que pot esperar. Mantenir les sol·licituds interactives sincròniques. Moveu les avaluacions, l'enriquiment, l'etiquetatge, l'emplenament, les barres de moderació i els informes per lots quan s'adaptin els terminis comercials i l'assistència del proveïdor. Estructura de preguntes llargues repetides per a la memòria cau. A continuació, mesura els estalvis reals després d'errors, reexecucions, emmagatzematge i costos de reserva.

La millor implementació és avorrida a propòsit: identificadors de feina, validació, estats a nivell de fila, pressupostos, anàlisis d'ús i propietat clara. Aquesta capa operativa és la que converteix els descomptes dels proveïdors en estalvis fiables.

Lectura relacionada

• Atribució de claus de l'API i control de la despesa de l'equip
• href="https://model-gate.com/en/blog/reliable-llm-api-routing-timeouts-retries-model-fallbacks-3/">polítiques d'encaminament, reintents i alternatives per a les API de LLM
• Notes d'implementació de Model Gateli">