Reduceți costurile API LLM cu joburi în loturi și memorare în cache promptă: un manual practic

Multe echipe plătesc în exces pentru API-urile LLM, deoarece trimit fiecare solicitare prin aceeași cale sincronă. Acest lucru este potrivit pentru chat, asistenți de codare, agenți de asistență, fluxuri de plată și orice așteaptă pe un utilizator. Este o risipă pentru evaluări, etichetare, îmbogățire, verificări de moderare, încorporare a umplerilor, rapoarte nocturne și preprocesare a conținutului.

Întrebarea practică nu este „Care model este cel mai ieftin?” Este: ce lucrare are de fapt nevoie de un răspuns imediat și care poate aștepta? Odată ce răspundeți la asta, controlul costurilor AI API devine un flux de lucru de inginerie: clasificați traficul, trimiteți lucrări tolerante la latență la procesarea în loturi acolo unde este acceptată, structurați solicitările repetate pentru stocarea în cache și măsurați economiile reale după eșecuri, reîncercări și operațiuni.

Începeți cu un audit al costurilor în funcție de volumul de lucru, nu de model

Înainte de a schimba arhitectura, exportați un eșantion de utilizare recentă a API-ului și grupați-l în funcție de volumul de lucru. Un tabel de audit util ar trebui să includă:

• Punctul final și model: finalizări de chat, răspunsuri, încorporare, moderare sau puncte finale specifice furnizorului.
• Indicative medii de intrare și ieșire: separă solicitările lungi de sarcinile scurte de clasificare.
• Forma promptă: instrucțiuni de sistem stabile, exemple reutilizabile, scheme, context de recuperare și date dinamice ale utilizatorului.
• Cerință de latență: secunde, minute, ore sau următoarea zi lucrătoare.
• Vizibilitatea utilizatorului: dacă o persoană așteaptă rezultatul.
• Reîncercare și rata de eșec: solicitări incorecte, eșecuri de validare, expirări ale furnizorului, joburi expirate și trimiteri duplicate.
• Proprietate: proiect, echipă, client, cheie API sau cont de partener.
• SLA de afaceri: ultima dată când rezultatul este încă util.

Acest audit dezvăluie de obicei că „traficul LLM” nu este un singur volum de lucru. Este o combinație de caracteristici interactive ale produsului, automatizare internă, raportare, pregătire a datelor și evaluarea calității. Tratarea acestora ca un singur centru de cost ascunde cele mai ușoare economii.

Utilizați un clasificator de încărcătură de lucru cu trei benzi

Un simplu clasificator împiedică echipele să mute traficul greșit în lot și apoi să fie surprinse de așteptările ratate.

Banda 1: solicitări interactive în timp real

Păstrați acestea sincrone. Acestea includ UX prin chat, copiloți, agenți de asistență, revizuire uman-in-the-loop, fluxuri de căutare sau recuperare live și apeluri de instrumente cu efecte secundare imediate. Dacă un utilizator așteaptă, valoarea unui răspuns mai ieftin poate fi ștearsă prin latență.

Recomandare: optimizați această bandă cu selecția modelului, tăierea rapidă, gestionarea limitelor de viteză, stocarea în cache acolo unde este cazul și reîncercări atente. Nu-l trimiteți la o coadă de 24 de ore, decât dacă produsul îl prezintă în mod explicit ca sarcină de fundal.

Bandă 2: solicitări aproape de linie care pot aștepta minute

Aceste lucrări nu trebuie să blocheze încărcarea unei pagini, dar pot avea totuși o așteptare la aceeași sesiune sau la aceeași oră. Exemplele includ analiza documentelor după încărcare, îmbogățirea CRM după trimiterea formularului sau un raport care poate notifica utilizatorul când este gata.

Recomandare: plasați munca aproape de linie în spatele unei cozi cu stări explicite de stare. În funcție de asistența furnizorului și de termenul limită, fie rulați-l prin loturi mici, fie lucrători sincroni cu prioritate mai mică. Această bandă beneficiază de ID-uri de job, webhook-uri și progres vizibil de utilizator.

Bandă 3: solicitări de lot offline care pot aștepta până la 24 de ore

Aceasta este principala bandă de optimizare a costurilor. Candidații buni includ:

• evaluări la scară largă;
• etichetarea setului de date;
• catalog sau îmbogățire CRM;
• rezumat nocturn;
• cozile de verificare a conformității;
• încorporarea rambleurilor;
• măturări de moderare;
• generarea de rapoarte periodice;
• preprocesarea conținutului înainte de indexare sau publicare.

Realitate: furnizorii importanți oferă acum API-uri batch asincrone pentru sarcini de lucru adecvate. API-ul OpenAI Batch citește solicitările dintr-un fișier încărcat, scrie rezultate într-un fișier de ieșire și țintește procesarea în 24 de ore. OpenAI afirmă că utilizarea API-ului Batch acceptată este oferită la o reducere de cost de 50% în comparație cu API-urile sincrone. API-ul Message Batches de la Anthropic este conceput pentru volume mari de solicitări de mesaje, procesare asincronă, debit mai mare și costuri cu 50% mai mici. API-ul Google Gemini Batch este conceput pentru solicitări asincrone de volum mare la 50% din costul standard, cu un timp de realizare țintă de 24 de ore.

Compartiment: „până la 24 de ore” este excelent pentru completări și evaluări, dar inacceptabil pentru fluxurile de lucru interactive. Lotul este o strategie de planificare, nu un înlocuitor universal pentru inferența sincronă.

Concepeți calea lotului ca ciclu de viață al sarcinii

Eroarea de implementare care trebuie evitată este tratarea lotului ca un singur apel API. Este un ciclu de viață: acceptați munca, validați-o, persistați-o, trimiteți-o, interogați-o, reconciliați-o și expuneți rezultatele.

Arhitectură de referință

1. Acceptați o solicitare normalizată: păstrați forma solicitării aproape de formatul dvs. API compatibil cu OpenAI, acolo unde este posibil. Adăugați metadate cum ar fi proiect, echipă, client, cheie de idempotence, termenul limită solicitat și centrul de cost.
2. Clasificați volumul de lucru: atribuiți solicitarea unui lot în timp real, aproape sau offline. Acest lucru ar trebui să se bazeze pe politici, nu să fie ascuns în codul aplicației.
3. Creați un ID de job: returnați imediat un identificator de job pentru munca aproape și offline.
4. Validați compatibilitatea: verificați dacă furnizorul și modelul selectat acceptă lotul pentru punctul final solicitat, modalitatea, dimensiunea fișierului, instrumentele, formatul de răspuns și alte caracteristici.
5. Persistați rândurile de solicitare: stochează rânduri JSONL normalizate sau sarcini utile specifice furnizorului. Includeți un ID de rând stabil pentru reconciliere.
6. Trimiteți lotul: încărcați fișierul de solicitare sau încărcarea utilă a lotului inline, în funcție de limitele furnizorului și de dimensiunea jobului.
7. Starea sondajului: urmăriți stările furnizorului, cum ar fi validarea, în curs, finalizat, eșuat, expirat, anulare și anulat, acolo unde este cazul.
8. Stochează rândurile de ieșire: scrieți răspunsuri reușite, erori la nivel de rând, utilizarea simbolurilor, numărul de simboluri stocate în cache, acolo unde este disponibil, și identificatorii furnizorului.
9. Anunțați consumatorii: expuneți un punct final de recuperare, un webhook, o notificare de tablou de bord sau o alertă Telegram.
10. Reconciliați facturarea: atribuiți costul proiectului inițial, echipei, clientului, cheii API și ID-ului jobului.

Acest model menține aplicația simplă. Echipele de produse trimit lucrări și primesc stări de lucru. Poarta de acces sau stratul de orchestrare gestionează diferențele de furnizori, fișierele batch, reîncercări și contabilitate.

Utilizați stări explicite ale jobului

Definiți stările interne chiar dacă fiecare furnizor folosește nume diferite:

• în coadă: acceptat, dar nu trimis;
• validare: furnizorul sau gateway-ul verifică fișierul;
• în rulare: trimis și în curs de procesare;
• finalizat: toate rezultatele disponibile colectate;
• completed_with_errors: validarea sau executarea unor rânduri nu au reușit;
• expirat: termenul limită a trecut înainte ca toate rândurile să fie finalizate;
• anulat: oprit de utilizator, sistem sau politică;
• eșuat: eșec la nivel de job care necesită intervenție.

Fapt: OpenAI documentează stările loturilor, inclusiv validarea, eșuarea, în curs, finalizarea, expirarea, anularea și anularea. De asemenea, menționează că, dacă un lot expiră, munca deja finalizată este returnată și taxată, în timp ce munca rămasă este anulată.

Recomandare: nu presupuneți niciodată că sarcinile în lot sunt totul sau nimic. Creați gestionarea stării la nivel de rând de la început.

Calculați economiile după defecțiuni și cheltuieli generale

Un model simplu de economii este suficient pentru majoritatea echipelor:

baseline_cost = synchronous_input_cost + synchronous_output_cost
batch_cost = discounted_batch_input_cost + discounted_batch_output_cost
ajustat_batch_cost = batch_cost + orchestration_cost + storage_cost + rerun_cost
estimated_savings = cost_baseline - cost_batch_ajusted

Apoi calculați acest lucru pe volum de lucru, nu global. O suită de evaluare pe noapte poate economisi substanțial. Un flux de lucru aproape de linie cu multe rânduri malformate, alternative urgente sau reluări repetate poate economisi mai puțin decât se aștepta.

Urmăriți cel puțin aceste valori:

• Sincronizare versus cheltuiala batch token;
• jetoane de intrare și de ieșire în funcție de model;
• numărul lotului de joburi și rândurile medii pe job;
• rata de eșec la nivel de rând;
• rata de locuri de muncă expirate;
• cost de reluare;
• costul alternativ la sincronizare;
• cost în funcție de echipă, proiect, cheie, client și cont de partener.

Recomandare: tratați alternativă automată sincronă ca o excepție, nu ca implicită. Protejează termenele limită, dar dacă este folosit în exces, poate șterge economiile așteptate. Adăugați o politică precum „retur numai dacă termenul limită al afacerii este în două ore și munca nu a început.”

Adăugați cache de prompt pentru prefixele lungi repetate

Procesarea în serie reduce prețul unitar al lucrării eligibile. Memorarea promptă în cache reduce costul efectiv și latența solicitărilor lungi repetate atunci când comportamentul furnizorului o acceptă.

Realitate: Memorarea în cache a promptelor OpenAI se aplică automat solicitărilor cu mai mult de 1.024 de jetoane pe modelele acceptate, memorează în cache cel mai lung prefix calculat anterior și raportează cached_tokens în detaliile de utilizare a API. OpenAI spune că cache-urile prompte sunt de obicei șterse după 5 până la 10 minute de inactivitate și eliminate în decurs de o oră de la ultima utilizare, iar cache-urile prompte nu sunt partajate între organizații.

Modelul de implementare este simplu: puneți pe primul loc conținutul stabil și ultimul conținut volatil.

Structură promptă mai bună pentru stocarea în cache

Instrucțiuni de sistem
Text de politică stabil
Schemă de ieșire stabilă
Exemple stabile
Context de referință reutilizabil
---
Intrare dinamică specifică înregistrării
Metadate dinamice pentru utilizator sau rând

De exemplu, o sarcină de îmbogățire a catalogului poate reutiliza aceeași taxonomie, schemă de ieșire, reguli de marcă și exemple pentru 50.000 de produse. Fiecare rând modifică numai titlul produsului, descrierea și atributele. Plasarea mai întâi a prefixului reutilizabil oferă furnizorului o șansă mai bună de a reutiliza calculele din cache acolo unde este acceptat.

Compartiment: stocarea în cache nu este stocare permanentă și nu trebuie tratată ca garantată. Ferestrele de cache, izolarea, lungimea minimă a promptului și raportarea diferă în funcție de furnizor. Măsurați jetoanele stocate în cache în loc să presupuneți economii.

Validați asistența furnizorului înainte de trimitere

API-urile batch diferă. Gateway-ul ar trebui să valideze eligibilitatea înainte de a trimite un job.

Fapte: OpenAI Batch API nu acceptă streaming și are limite separate ale ratei lotului. Anthropic documentează limitări ale loturilor, inclusiv o limită de 100.000 de solicitări sau 256 MB de dimensiune a lotului, o expirare de 24 de ore, disponibilitatea rezultatelor în 29 de zile, limitele ratei și posibilitatea ca loturile să depășească puțin limitele de cheltuieli configurate pentru spațiul de lucru. Google acceptă solicitări de loturi inline pentru lucrări mai mici sub 20 MB și fișiere de intrare JSONL pentru solicitări de loturi mai mari.

Utilizați o listă de verificare pentru compatibilitate:

• Modelul solicitat este disponibil prin API-ul batch al furnizorului respectiv?
• Este acceptat punctul final?
• Solicitarea necesită streaming? Dacă da, respingeți lotul.
• Folosește instrumente sau efecte secundare care trebuie să apară imediat?
• Fișierul batch depășește limitele furnizorului?
• Rezultatul așteptat este încă util în fereastra de finalizare a furnizorului?
• Sunt ieșirile disponibile suficient de mult timp pentru ca sistemele din aval să le recupereze?
• Poate volumul de lucru să tolereze finalizarea parțială?

Recomandare: eșuează validarea din timp cu un motiv clar. Un lot de candidat respins este mai ieftin decât un job expirat sau malformat, care trebuie reluat ulterior.

Măsuri de siguranță pentru echipe, agenții și parteneri

Sistemele batch pot cheltui în liniște o mulțime de bani, deoarece procesează fișiere mari în fundal. Adăugați comenzi înainte de lansarea amplă:

• Bugetele lot pe echipă: limitele separate ale cheltuielilor online și offline.
• Dimensiunea maximă a fișierelor și numărul de rânduri: aplicați limitele furnizorului și propriile limite operaționale.
• Coada de mesaje neînregistrate: păstrați rândurile nevalide cu erori de validare pentru examinare.
• Cheile de idempotenta: previne retrimiterea accidentală a taxelor duplicate.
• Examinare IPI: fișierele batch pot crea noi obligații de păstrare a datelor și de confidențialitate.
• Politica de păstrare: definiți cât timp sunt stocate fișierele de solicitare, fișierele de ieșire și jurnalele.
• Politica de notificări: alertează proprietarii când lucrările eșuează, expiră sau depășesc bugetul.
• Atribuire: înregistrați proiectul, echipa, clientul, cheia API, modelul, furnizorul, ID-ul jobului și ID-ul rândului.

Pentru agenții și revânzători, atribuirea este deosebit de importantă. Dacă un partener execută lucrări de îmbogățire sau de evaluare pentru mulți clienți, sistemul ar trebui să raporteze costul pe client și pe sarcină, nu numai pe factura de la furnizor.

Cum se mapează aceasta la un gateway API AI

Un gateway AI API este un loc natural pentru a implementa acest lucru, deoarece se află deja între aplicații și furnizorii de modele. Gateway-ul poate păstra o suprafață API compatibilă cu OpenAI pentru dezvoltatori, adăugând, în același timp, o programare conștientă de costuri.

Capacitățile utile ale gateway-ului includ:

• Facturare unificată: comparați cheltuielile sincrone, în lot, în cache și de rezervă într-un singur loc.
• Analitica utilizării AI: defalcați utilizarea în funcție de model, furnizor, punct final, echipă, proiect și cheie API.
• Controalele echipei: setați bugete separate pentru sarcinile de lucru interactive și offline.
• Atribuirea cheii API: identificați serviciul sau clientul care a creat fiecare job.
• Notificări de stare: trimiteți alerte atunci când lucrările în lot se termină, eșuează, expiră sau se apropie de un termen limită.
• Fluxuri de lucru API pentru parteneri: permiteți agențiilor sau revânzătorilor să creeze locuri de muncă și să recupereze rezultate în numele clienților, păstrând în același timp contabilitatea la nivel de client.

Predicție: mai multe echipe vor gestiona costurile LLM cu politici de programare, nu doar înlocuiri de model. Pe măsură ce suportul de lot se maturizează între furnizori, arhitectura câștigătoare va fi direcționată în funcție de urgență, compatibilitate cu caracteristicile și cerințe de contabilitate înainte de a fi direcționată în funcție de prețul modelului.

Lista de verificare a implementării

• Exportați 30 de zile de utilizare a API-ului LLM.
• Clasificați fiecare sarcină de lucru ca în timp real, aproape sau offline.
• Alegeți o singură sarcină de lucru offline, cu o proprietate clară și un termen limită iertator.
• Validați suportul lot al furnizorului pentru punctul final și modelul necesar.
• Definiți stările interne ale jobului și stările la nivel de rând.
• Adăugați chei de idempotence, ID-uri de job și ID-uri pe rând.
• Stochează înregistrările normalizate de solicitări și răspunsuri cu controale de păstrare.
• Trimiteți primul lot în spatele unui semnalizator de caracteristică.
• Măsurați costul de referință sincron față de costul lotului ajustat.
• Restructurați solicitările lungi repetate pentru a pune pe primul loc prefixele stabile.
• Urmăriți indicatoarele stocate în cache, rândurile eșuate, lucrările expirate și cheltuielile de rezervă.
• Extindeți numai după ce economiile și comportamentul operațional sunt vizibile în analiză.

Concluzie acționabilă

Nu începeți controlul costurilor AI API solicitând fiecărei echipe să folosească un model mai ieftin. Începeți prin a separa munca urgentă de cea care poate aștepta. Păstrați cererile interactive sincrone. Mutați evaluările, îmbogățirea, etichetarea, completarile, verificările de moderare și rapoartele în loturi atunci când asistența furnizorului și termenele limită de afaceri se potrivesc. Structurați solicitări lungi repetate pentru stocarea în cache. Apoi măsurați economiile reale după eșecuri, reexecuții, stocare și costuri de rezervă.

Cea mai bună implementare este plictisitoare intenționată: ID-uri de job, validare, stări la nivel de rând, bugete, analize de utilizare și proprietate clară. Acest nivel operațional este cel care transformă reducerile oferite de furnizori în economii de încredere.

Lectură similară

• Atribuirea cheilor API și controlul cheltuielilor echipei
• href="https://model-gate.com/en/blog/reliable-llm-api-routing-timeouts-retries-model-fallbacks-3/">politici de rutare, reîncercări și alternative pentru API-urile LLM
• Note de implementare a modelului Gateli