Kako smanjiti troškove API-ja za LLM uz skupnu obradu bez prekidanja operacija

Mnogi timovi preplaćuju za LLM radna opterećenja jer svaki zahtjev prolazi kroz isti sinkroni put. To je pravi obrazac za chat, petlje agenata, radnje okrenute korisniku i odluke koje zahtijevaju trenutačni odgovor. Obično je pogrešan obrazac za evaluacije, obogaćivanje dokumenata, popunjavanje klasifikacije, osvježavanje ugrađivanja, noćne provjere kvalitete, skeniranje sukladnosti i poslove izvješćivanja koji mogu čekati.

Teži dio nije odlučiti jesu li skupni popusti privlačni. Teži dio je premještanje posla u asinkronu obradu bez gubitka operativne kontrole. Skupna obrada mijenja oblik sustava: zahtjevi postaju poslovi, kvarovi stižu kasnije, rezultati mogu biti djelomični, a dodjela troškova ovisi o usklađivanju, a ne o metapodacima o trenutnom odgovoru.

Ovaj vodič razdvaja činjenice, preporuke i predviđanja tako da timovi mogu donijeti praktičnu odluku o implementaciji bez tretiranja skupne obrade kao univerzalne zamjene za sinkrone API-je.

Što je činjenično točno o LLM batchu API-ji

Nekoliko glavnih pružatelja modela sada nudi skupne API-je za asinkroni rad velike količine. Specifični formati i ograničenja razlikuju se, ali komercijalni obrazac je sličan: pošaljite mnogo zahtjeva, pričekajte asinkronu obradu, a zatim dohvatite rezultate kasnije.

• Činjenica: OpenAI dokumentira seriju API za velike asinkrone serije s dovršecima koji se vraćaju u roku od 24 sata i uz popust od 50%. Njegove dokumentirane podržane krajnje točke uključuju odgovore, dovršetke chata, ugradnje, dovršetke i moderacije, s JSONL ulaznim datotekama učitanim za obradu.
• Činjenica: Anthropic dokumentira skupine poruka za velike količine asinkronih zahtjeva za poruke, uz smanjenje troškova od 50% i povećanu propusnost. Njegova dokumentacija kaže da većina serija završi za manje od jednog sata i da je uzorak prikladan kada nisu potrebni trenutni odgovori.
• Činjenica: Anthropic također dokumentira zasebno ponašanje ograničenja brzine za grupe poruka, uključujući ograničenja za krajnje točke paketa i broj skupnih zahtjeva koji mogu biti u redu čekanja za obradu u isto vrijeme vrijeme.
• Činjenica: Google dokumentira Gemini seriju API za velike količine asinkronih zahtjeva po 50% standardne cijene, a dokumentacija o cijenama navodi seriju API kao značajku smanjenja troškova za 50%.
• Činjenica: Amazon Bedrock bilježenje pozivanja modela može prikupljati podatke o zahtjevima, podatke o odgovorima i metapodatke za podržane pozive u vremenu izvođenja, s isporukom u CloudWatch Logs i/ili S3. Zabilježena polja mogu uključivati ID zahtjeva, radnju, ID modela, Metapodatke zahtjeva, broj ulaznih tokena i broj izlaznih tokena, koji su korisni za usklađivanje.

Te činjenice podržavaju jasnu preporuku: koristite skupnu obradu tamo gdje radno opterećenje može tolerirati odgođeno dovršetak i gdje poslovna vrijednost niže jedinične cijene nadmašuje operativnu složenost asinkronog izvršenje.

Nemojte započeti s pružateljem API

Uobičajena pogreška implementacije je vezanje koda aplikacije izravno na format paketne datoteke ili model statusa pružatelja. To funkcionira za prototip, ali stvara troškove migracije koji se mogu izbjeći kada tim doda drugog pružatelja usluga, promijeni modele ili mu je potrebno dosljedno izvješćivanje u sinkronom i asinkronom prometu.

Bolje polazište je interna apstrakcija batch-joba.Ne mora biti razrađeno, ali bi trebalo normalizirati operativna polja koja vaša platforma treba bez obzira na davatelja.

Minimalna polja skupnog posla

• job_id: Vaš interni identifikator za skupni posao.
• provider: Davatelj odabran za izvršenje.
• provider_batch_id: Identifikator vanjske serije jednom poslan.
• workflow: Poslovni tijek rada, kao što je eval_run, embedding_refresh, doc_enrichment ili qa_scan.
• team_id ili customer_id: Odgovorni vlasnik za kvote, izvješćivanje i raspodjelu troškova.
• model: Traženi model ili pravilo modela.
• endpoint: Vrsta krajnje točke pružatelja, kao što su chat, odgovori, ugradnje, moderiranje ili poruke.
• submitted_at i deadline_at: Vremenske oznake potrebne za rukovanje SLA.
• status: Normalizirano stanje, kao što je u redu čekanja, poslano, obrada, dovršeno, completed_with_errors, neuspjelo, poništeno ili istekao.
• input_uri i result_uri: Pokazivači na trajne ulazne i izlazne artefakte.
• item_count, success_count, failure_count: Usklađivanje na razini posla ukupno.
• input_tokens i output_tokens: Ostvarena upotreba nakon obrade.
• estimated_cost i realized_cost: Procjena vremena podnošenja i trošak nakon usklađivanja.
• cost_basis: Cijena korišteno pravilo, uključujući je li primijenjen skupni popust.

Ova apstrakcija daje ostatku organizacije jedan ugovor. Polja specifična za pružatelja usluga i dalje se mogu pohraniti za otklanjanje pogrešaka, ali ne bi trebala postati sučelje koje svaki aplikacijski tim mora naučiti.

Klasificirajte radna opterećenja prema SLA prije usmjeravanja

Skupna obrada trebala bi biti vođena očekivanjima na razini usluge, a ne općom željom da se smanji potrošnja. Jednostavnom politikom usmjeravanja lakše je upravljati nego pametnom.

Interaktivna klasa

Interaktivni zahtjevi okrenuti su korisniku ili su vremenski osjetljivi. Primjeri uključuju UX chata, petlje agenta koje zahtijevaju pozive alata, tijekove rada podrške gdje operater čeka, prijevare ili odluke o plaćanju i bilo koji tijek rada u kojem je odgođeni djelomični izlaz gori od izostanka izlaza. One bi trebale ostati sinkronizirane osim ako proizvod izričito ne promijeni svoje korisničko iskustvo.

Odgođena klasa

Odgođeni tijekovi rada mogu čekati bez štete korisniku ili poslovnom procesu. Primjeri uključuju izvanmrežne procjene, označavanje dokumenata, popunjavanje klasifikacije, osvježavanja ugrađivanja, povijesno moderiranje, noćne provjere kvalitete i generiranje izvješća.Ovo su najbolji kandidati za paketne API-je pružatelja usluga.

Granična klasa

Neka radna opterećenja nisu doista interaktivna, ali ipak imaju rok. Na primjer, dokument koji je kupac uvezao može trebati obogatiti u roku od 20 minuta, a ne odmah. Za njih koristite interni red čekanja s rokom. Ako je posao još uvijek na čekanju blizu roka, može se promaknuti u sinkronu obradu, otkazati ili preusmjeriti u skladu s pravilima.

Ovdje AI API kontrola troškova postaje problem infrastrukture, a ne vježba određivanja cijena. Sustav treba politiku usmjeravanja, svijest o rokovima, računovodstvo i vidljivost na istom mjestu.

Koristite stabilne ID-ove zahtjeva za svaku stavku

Skupni poslovi ne uspijevaju na više različitih načina od sinkronih poziva. Davatelj može odbiti datoteku. Posao se može dovršiti s pogreškama na razini stavke. Ponovni pokušaj može ponovno poslati rad koji je djelomično uspio. Proces unosa može se srušiti nakon pisanja nekih rezultata, ali prije označavanja da je posao dovršen.

Najvažnija zaštita je stabilan ključ zahtjeva za svaku stavku. Ovaj ključ bi trebao biti determiniran iz vaših vlastitih podataka, a ne generiran nasumično u vrijeme podnošenja.

Na primjer, ključ zahtjeva za obogaćivanje dokumenta može biti:

doc_enrichment:v3:customer_812:document_9912:section_04:model_policy_standard

Ključ za osvježavanje ugradnje može biti:

embedding_refresh:v2:workspace_44:asset_2107:chunk_18:embedding_model_small

Ključ bi trebao uključivati tijek rada, verziju, granicu zakupca, izvorni zapis, granicu stavke i model ili model politike gdje je relevantno. To omogućuje nizvodno pisanje da bude idempotentno. Ako se isti rezultat primi dva puta, baza podataka se može vratiti na request_key radije nego da stvara dvostruke retke ili dvostruko broji korištenje.

Izričito dizajnirajte stroj stanja

Stanja pružatelja usluga se razlikuju, tako da interni stroj stanja treba biti malen i izdržljiv. Praktična verzija izgleda ovako:

• created: Posao postoji interno, ali nije zapakiran.
• validated: Ulazni zapisi prošli su shemu i provjere prihvatljivosti.
• submitted: Davatelj prihvatio skupnu predaju.
• obrada: Davatelj je započeo ili stavio izvršenje u red čekanja.
• dovršeno: Sve stavke su dosegle uspješno terminalno stanje.
• completed_with_errors: Posao je dovršen, ali neke stavke nisu uspjele i trebaju pregled ili replay.
• failed: Posao nije uspio na pružatelju ili sloju orkestracije.
• cancelled: Sustav ili operater zaustavio je posao prije završetka.
• expired: Posao je propustio svoj rok i ne bi trebao pisati normalne rezultate bez pregled.

Svaki prijelaz treba biti samo za dodavanje u tablicu događaja. To daje operativnim timovima revizijski trag kada posao propusti svoj rok ili kada sustav koji slijedi osporava je li zapis obrađen.

Izgradite usklađivanje kao prvoklasni tijek rada

Podnošenje je samo pola sustava.Skupi operativni bugovi obično se pojavljuju tijekom gutanja rezultata.

Radnik za usklađivanje trebao bi učiniti pet stvari svaki put kada obradi dovršenu seriju:

1. Učitati originalni manifest podnesenih ključeva zahtjeva.
2. Učitati rezultate pružatelja iz izlaznih datoteka, krajnjih točaka rezultata ili zapisnika pružatelja.
3. Mapirati svaki rezultat pružatelja natrag na točno jedan interni zahtjev ključ.
4. Idempotentno zapišite uspješne rezultate u odredišni sustav.
5. Emitirajte terminalske zapise za neuspjehe, stavke koje nedostaju, brojeve tokena i ostvareni trošak.

Proces usklađivanja treba potvrditi da svaka poslana stavka ima terminalno stanje. Rezultati koji nedostaju ne bi trebali tiho nestati. Označite ih kao nedostajuće, neuspjele ili pokušaje ponovno u skladu s odgovorom pružatelja usluga i vašim pravilima.

Ovdje bi se također trebalo dogoditi dodjeljivanje troškova. Procjene vremena podnošenja korisne su za provjere proračuna, ali realizirani trošak trebao bi se izvesti iz stvarnog broja tokena, izlaza pružatelja, izvoza naplate ili zapisnika pozivanja gdje su dostupni. Time se izbjegava problem koji se ponavlja: timovi izvješćuju o procijenjenim uštedama dok financijska knjiga kasnije prikazuje drugačiji broj.

Rješavanje djelomičnih kvarova bez ponavljanja svega

Skupni sustavi moraju pretpostaviti djelomični kvar. Promptna shema možda neće uspjeti za 2% zapisa. Podskup zahtjeva može dosegnuti ograničenja duljine. Neki unosi mogu kršiti pravila o moderiranju ili sadržaju. Datoteka rezultata može sadržavati važeći izlaz za većinu stavki i strukturirane pogreške za ostale.

Ispravan odgovor obično nije ponovno reproduciranje cijele serije. Ponovno reproducirajte samo neuspjele ili ključeve zahtjeva koji nedostaju u novom poslu, s parent_job_id i retry_attempt. Ovo ograničava trošak, smanjuje dvostruka pisanja i zadržava revizijski trag izvornog posla netaknutim.

Koristan zapis ponovnog pokušaja uključuje:

• request_key
• parent_job_id
• retry_attempt
• original_error_code
• retry_reason
• new_job_id
• final_status

Uradi ne pokušavajte automatski ponoviti sve pogreške. Privremeni kvarovi pružatelja usluga, istek vremena čekanja i popravljivi problemi s prijenosom mogu se pokušati ponovno. Neuspješne provjere valjanosti, neusklađenosti shema i pogreške nepodržane veličine unosa obično zahtijevaju ispravak prije ponovne reprodukcije.

Kontrolirajte radijus eksplozije veličinom serije i verzijama

Velike serije mogu poboljšati propusnost i smanjiti troškove orkestracije, ali također povećavaju troškove lošeg upita, pogrešne sheme ili netočnog odabira modela. Manje serije daju brže povratne informacije i manji radijus eksplozije, ali stvaraju više poslova za praćenje.

Praktični pristup je progresivno uvođenje:

1. Pokrenite malu seriju provjere valjanosti s reprezentativnim ulazima.
2. Potvrdite valjanost sheme, kvalitetu izlaza, raspon tokena i usklađivanje ponašanje.
3. Povećajte veličinu serije po tijeku rada nakon prvog uspješnog pokretanja.
4. Zadržite verziju upita, verziju sheme i pravila modela u ključu zahtjeva ili manifestu.
5. Zaustavite se automatski ako stopa neuspjeha, upotreba tokena ili provjera valjanosti izlaza prijeđu prag.

Ovo je posebno važno za zatrpavanja.Zatrpavanje može brzo stvoriti veliki račun čak i s popustom ako obrađuje milijune zapisa s neočekivano opširnim upitom ili izlaznim formatom.

Izložite uštede kao procijenjene i ostvarene

Grupni popusti su privlačni, ali izvješćivanje ne bi trebalo zamagliti procjene sa stvarnim.

U vrijeme podnošenja, platforma može prikazati procijenjeni trošak koristeći očekivani token brojevi, odabrani model, broj artikala i poznata pravila popusta na seriju. Nakon usklađivanja, platforma bi trebala prikazati realizirani trošak na temelju stvarne upotrebe tokena i podataka o naplati ili korištenju pružatelja usluga.

Korisna nadzorna ploča uključuje:

• starost čekanja prema tijeku rada i pružatelju
• najstariji posao na čekanju
• postotak dovršetka
• neuspjela stavka stopa
• broj ponovnih pokušaja
• procijenjeni trošak dostavljen
• realizirani trošak usklađen
• efektivni popust uhvaćen
• sinkroni rezervni volumen
• poslovi koji se približavaju roku

Ova razlika također pomaže financijama i inženjerstvu da govore istim jezikom. Inženjering može optimizirati usmjeravanje i ponovne pokušaje; financije mogu uskladiti ostvarenu potrošnju; timovi proizvoda mogu vidjeti koji tijek rada zapravo ima koristi od odgođene obrade.

Preporuke za implementaciju

Upotrijebite sljedeći popis za provjeru prije premještanja radnog opterećenja na skupnu obradu.

Kontrolni popis prihvatljivosti

• Tijek rada ne zahtijeva neposredan kontakt s korisnikom odgovor.
• Poduzeće može definirati prihvatljivi prozor završetka.
• Svaka stavka ima stabilan ključ zahtjeva.
• Odredišno pisanje može biti idempotentno.
• Djelomični rezultati su prihvatljivi i pomirljivi.
• Neuspjesi se mogu pokušati ponovo selektivno.
• Verzije upita i sheme se bilježe.
• Korištenje se može pripisati timu, kupcu, proizvodu ili okruženju.
• Zapisivanje osjetljivog sadržaja pregledano je zbog obaveza privatnosti i zadržavanja.

Operativno popis za provjeru

• Normalizirajte status pružatelja u interni stroj stanja.
• Trajno pohranjujte originalne manifeste unosa.
• Provjerite ili primajte događaje završetka pružatelja prema rasporedu.
• Validirajte svaki rezultat prema očekivanoj shemi.
• Usporedite poslane ključeve zahtjeva s primljenim terminalom stanja.
• Emitiraj zapise o korištenju samo nakon usklađivanja.
• Odvoji procijenjeni trošak od realiziranog troška.
• Upozorenje o starosti čekanja, stopi neuspjelih stavki, rezultatima koji nedostaju i riziku roka.
• Dokumentiraj koja radna opterećenja moraju ostati sinkrono.

Kompromisi za eksplicitnost

Preporuka: Tretirajte skupnu obradu kao zasebnu izvršnu klasu, a ne skrivenu optimizaciju iza sinkrone API staze.Timovi bi trebali znati kada tijek rada kasni, koji se rok primjenjuje i što se događa kada se rok propusti.

Razvoj: Skupni API-ji mogu značajno smanjiti troškove tokena, ali zamjenjuju jednostavno ponašanje zahtjeva-odgovora s čekanjem, anketiranjem, unosom rezultata, odgođenim pogreškama i složenijom podrškom tijekovi rada.

Razvoj: Skupni API-ji pružatelja nisu identični. Normalizirani interni model smanjuje složenost aplikacije, ali platforma i dalje mora sačuvati identifikatore i pogreške specifične za pružatelja usluga za otklanjanje pogrešaka.

Različje: Bilježenje potpunih upita i izlaza može poboljšati mogućnost revizije i usklađivanja, ali također može stvoriti obveze privatnosti, sigurnosti i zadržavanja podataka. Osjetljivi sadržaj treba klasificirati, redigirati ili isključiti gdje je to potrebno.

Predviđanje: Više LLM infrastrukturnih timova tretirat će skupno izvršavanje kao standardnu ​​klasu usmjeravanja uz sinkrone pozive, strujanje poziva i rezervne rute. Timovi koji će imati najviše koristi bit će oni koji rano izgrade usklađivanje i troškovno računovodstvo, umjesto da ih dodaju nakon što financije ili operacije postave pitanje zašto se brojke ne podudaraju.

Primjen zaključak

Skupna obrada je jedan od najjasnijih načina za smanjenje jediničnih troškova LLM-a za odgođena radna opterećenja, ali treba je implementirati kao operativni sustav, a ne samo kao jeftiniju krajnju točku. Započnite s ispunjavanjem uvjeta za radno opterećenje, stabilnim ključevima zahtjeva, normaliziranim modelom posla i tijek rada usklađivanja koji dokazuje da je svaka poslana stavka dosegla terminalno stanje.

Održavajte interaktivne zahtjeve sinkronima. Premjestite odgođene tijekove rada u paketne API-je pružatelja usluga gdje prozor cijene i završetka ima smisla. Koristite interni red čekanja za granična radna opterećenja s izričitim rokovima. Prijavite procijenjene uštede u vrijeme podnošenja, ali uskladite ostvareni trošak sa stvarnim korištenjem. To je obrazac koji bilježi skupne popuste bez rušenja nizvodnih zapisa, timskih knjiga ili očekivanja SLA.

Povezano čitanje

• pridjeljivanje i usklađivanje troškova po timu