Smanjite troškove LLM API-ja s batch poslovima i brzim predmemoriranjem: praktična knjiga

Mnogi timovi preplaćuju LLM API-je jer svaki zahtjev šalju istim sinkronim putem. To je prikladno za chat, pomoćnike kodiranja, agente za podršku, tokove plaćanja i sve što čeka korisnika. Rasipan je za evaluacije, označavanje, obogaćivanje, moderiranje, ugrađivanje popunjavanja, noćna izvješća i prethodnu obradu sadržaja.

Praktično pitanje nije "Koji je model najjeftiniji?" To je: Koji posao zapravo treba trenutni odgovor, a koji posao može pričekati? Nakon što odgovorite na to, kontrola troškova AI API-ja postaje inženjerski tijek rada: klasificirajte promet, pošaljite poslove otporne na kašnjenje u skupnu obradu gdje je to podržano, strukturirajte ponovljene upite za predmemoriju i izmjerite stvarne uštede nakon neuspjeha, ponovnih pokušaja i operativnih troškova.

Počnite s revizijom troškova prema opterećenju, a ne prema modelu

Prije promjene arhitekture, izvezite uzorak nedavne upotrebe API-ja i grupirajte ga prema radnom opterećenju. Korisna revizijska tablica trebala bi uključivati:

• Krajnja točka i model: završeci chata, odgovori, ugradnje, moderiranje ili krajnje točke specifične za pružatelja usluga.
• Prosječni ulazni i izlazni tokeni: odvojite dugačke upite od kratkih zadataka klasifikacije.
• Oblik upita: stabilne upute sustava, primjeri za višekratnu upotrebu, sheme, kontekst dohvaćanja i dinamički korisnički podaci.
• Zahtjev za kašnjenjem: sekunde, minute, sati ili sljedeći radni dan.
• Vidljivost korisnika: čeka li osoba rezultat.
• Stopa ponovnih pokušaja i neuspjeha: neispravni zahtjevi, neuspjele provjere valjanosti, isteci vremena pružatelja, istekli poslovi i duplicirana slanja.
• Vlasništvo: projekt, tim, korisnik, API ključ ili račun partnera.
• Poslovni SLA: posljednje vrijeme kada je rezultat još uvijek koristan.

Ova revizija obično otkriva da "LLM promet" nije jedno radno opterećenje. To je mješavina interaktivnih značajki proizvoda, interne automatizacije, izvješćivanja, pripreme podataka i procjene kvalitete. Tretiranje njih kao jednog troškovnog centra skriva najlakše uštede.

Koristite trotračni klasifikator radnog opterećenja

Jednostavan klasifikator sprječava timove da premjeste pogrešan promet u skupinu i potom budu iznenađeni promašenim očekivanjima.

Staza 1: interaktivni zahtjevi u stvarnom vremenu

Održavajte ih sinkronima. Oni uključuju chat UX, kopilote, agente za podršku, ljudski pregled u petlji, tokove pretraživanja ili dohvaćanja uživo i pozive alata s trenutnim nuspojavama. Ako korisnik čeka, vrijednost jeftinijeg odgovora može biti izbrisana latencijom.

Preporuka: optimizirajte ovu stazu odabirom modela, brzim skraćivanjem, upravljanjem ograničenjem brzine, predmemoriranjem gdje je primjenjivo i pažljivim ponovnim pokušajima. Nemojte ga slati u 24-satni skupni red čekanja osim ako ga proizvod izričito ne predstavlja kao pozadinski zadatak.

Traka 2: zahtjevi blizu linije koji mogu čekati nekoliko minuta

Ovi poslovi ne moraju blokirati učitavanje stranice, ali i dalje mogu imati očekivanu istu sesiju ili isti sat. Primjeri uključuju analizu dokumenata nakon učitavanja, obogaćivanje CRM-a nakon podnošenja obrasca ili izvješće koje može obavijestiti korisnika kada je spremno.

Preporuka: posao blizu linije postavite iza reda čekanja s eksplicitnim stanjima statusa. Ovisno o podršci pružatelja usluga i roku, pokrenite ga kroz male serije ili sinkrone radnike s nižim prioritetom. Ova traka koristi ID-ove poslova, web-dojavnike i napredak vidljiv korisnicima.

Staza 3: izvanmrežni grupni zahtjevi koji mogu čekati do 24 sata

Ovo je glavna staza optimizacije troškova. Dobri kandidati uključuju:

• evaluacije velikih razmjera;
• označavanje skupa podataka;
• obogaćivanje kataloga ili CRM-a;
• noćno sažimanje;
• redovi čekanja za pregled sukladnosti;
• ugrađivanje zatrpavanja;
• moderacija;
• generiranje periodičnih izvješća;
• prethodna obrada sadržaja prije indeksiranja ili objavljivanja.

Činjenica: glavni pružatelji usluga sada nude asinkrone batch API-je za odgovarajuća radna opterećenja. OpenAI-jev Batch API čita zahtjeve iz učitane datoteke, zapisuje rezultate u izlaznu datoteku i cilja obradu unutar 24 sata. OpenAI navodi da se podržano Batch API korištenje nudi uz 50% popusta na cijenu u usporedbi sa sinkronim API-jima. Anthropicov Message Batches API dizajniran je za velike količine zahtjeva za poruke, asinkronu obradu, veću propusnost i 50% nižu cijenu. Googleov Gemini Batch API dizajniran je za velike količine asinkronih zahtjeva po 50% standardne cijene, s ciljnim vremenom obrade od 24 sata.

Kompromis: "do 24 sata" izvrsno je za dopune i evaluacije, ali je neprihvatljivo za interaktivne tijekove rada. Batch je strategija raspoređivanja, a ne univerzalna zamjena za sinkroni zaključak.

Dizajnirajte paketni put kao životni ciklus posla

Greška u implementaciji koju treba izbjegavati je tretiranje serije kao jednog API poziva. To je životni ciklus: prihvatite posao, potvrdite ga, ustrajte u njemu, pošaljite ga, ispitajte ga, uskladite ga i izložite rezultate.

Referentna arhitektura

1. Prihvatite normalizirani zahtjev: neka oblik zahtjeva bude blizak vašem postojećem OpenAI-kompatibilnom API formatu gdje je to moguće. Dodajte metapodatke kao što su projekt, tim, kupac, ključ idempotencije, traženi rok i mjesto troška.
2. Klasificirajte radno opterećenje: dodijelite zahtjev grupi u stvarnom vremenu, blizu mreže ili izvan mreže. Ovo bi se trebalo temeljiti na pravilima, a ne skriveno unutar koda aplikacije.
3. Stvorite ID posla: odmah vratite identifikator posla za rad blizu mreže i izvan mreže.
4. Provjerite kompatibilnost: provjerite podržavaju li odabrani pružatelj usluga i model paket za traženu krajnju točku, modalitet, veličinu datoteke, alate, format odgovora i druge značajke.
5. Trajni redovi zahtjeva: pohranjujte normalizirane JSONL retke ili podatke specifične za pružatelja usluga. Uključite stabilan ID retka za usklađivanje.
6. Pošaljite paket: prenesite datoteku zahtjeva ili ugrađeni skupni sadržaj ovisno o ograničenjima pružatelja usluga i veličini posla.
7. Status ankete: pratite stanja pružatelja usluga kao što su provjera valjanosti, u tijeku, dovršeno, neuspješno, isteklo, otkazivanje i otkazano ako je primjenjivo.
8. Pohrani retke izlaza: zapišite uspješne odgovore, pogreške na razini retka, upotrebu tokena, predmemorirane brojeve tokena gdje su dostupni i identifikatore pružatelja usluga.
9. Obavijestite potrošače: izložite krajnju točku preuzimanja, web-dojavnik, obavijest nadzorne ploče ili upozorenje Telegrama.
10. Uskladite naplatu: pripišite trošak izvornom projektu, timu, kupcu, API ključu i ID-u posla.

Ovaj uzorak čini aplikaciju jednostavnom. Timovi proizvoda predaju rad i primaju stanja poslova. Pristupnik ili sloj orkestracije rukuje razlikama pružatelja, skupnim datotekama, ponovnim pokušajima i računovodstvom.

Koristite eksplicitna stanja posla

Definirajte interna stanja čak i ako svaki pružatelj koristi različita imena:

• na čekanju: prihvaćeno, ali nije poslano;
• provjera: pružatelj ili pristupnik provjerava datoteku;
• u tijeku: poslano i u obradi;
• dovršeno: prikupljeni svi dostupni rezultati;
• completed_with_errors: neki redovi nisu prošli provjeru valjanosti ili izvršenje;
• istekao: rok je prošao prije nego što su svi redovi dovršeni;
• otkazano: zaustavio korisnik, sustav ili pravilo;
• neuspješno: kvar na razini posla koji zahtijeva intervenciju.

Činjenica: OpenAI dokumentira statuse serija uključujući provjeru valjanosti, neuspjelo, u tijeku, dovršeno, isteklo, otkazivanje i poništeno. Također napominje da se, ako paket istekne, već dovršeni rad vraća i naplaćuje, dok se preostali rad otkazuje.

Preporuka: nikad ne pretpostavljajte da su skupni poslovi sve ili ništa. Izradite rukovanje statusom na razini retka od samog početka.

Izračunajte uštede nakon kvarova i režijskih troškova

Jednostavan model štednje dovoljan je za većinu timova:

osnovni_trošak = sinkroni_ulazni_trošak + sinkroni_izlazni_trošak
batch_cost = sniženi_serijski_ulazni_trošak + sniženi_serijski_izlazni_trošak
prilagođeni_trošak_serije = trošak_serije + trošak_orkestracije + trošak_skladišta + trošak_ponovnog_izvođenja
procijenjena_ušteda = osnovni_trošak - prilagođeni_serijski_trošak

Onda to izračunajte po radnom opterećenju, a ne globalno. Noćni paket za procjenu može znatno uštedjeti. Skoro linearni tijek rada s mnogo pogrešno oblikovanih redaka, hitnim zamjenama ili opetovanim ponovnim izvođenjem može uštedjeti manje od očekivanog.

Pratite barem ove mjerne podatke:

• sinkronizacija u odnosu na skupnu potrošnju tokena;
• ulazni i izlazni tokeni prema modelu;
• broj serijskih poslova i prosječni redovi po poslu;
• stopa neuspjeha na razini retka;
• stopa isteklih poslova;
• trošak ponavljanja;
• trošak povratne sinkronizacije;
• cijena po timu, projektu, ključu, korisniku i partnerskom računu.

Preporuka: automatsku sinkronu zamjenu smatrajte iznimkom, a ne zadanom. Štiti rokove, ali ako se pretjerano koristi može izbrisati očekivane uštede. Dodajte pravilo kao što je "zamjena samo ako je poslovni rok unutar dva sata, a posao nije započeo."

Dodajte predmemoriju upita za duge prefikse koji se ponavljaju

Skupna obrada smanjuje jediničnu cijenu prihvatljivog rada. Predmemoriranje upita smanjuje efektivnu cijenu i kašnjenje ponovljenih dugih upita kada to podržava ponašanje pružatelja usluga.

Činjenica: predmemoriranje OpenAI odzivnika automatski se primjenjuje na upite dulje od 1024 tokena na podržanim modelima, sprema u predmemoriju najdulji prethodno izračunati prefiks i izvješćuje o cached_tokens u detaljima upotrebe API-ja. OpenAI kaže da se promptne predmemorije obično brišu nakon 5 do 10 minuta neaktivnosti i uklanjaju unutar jednog sata od zadnje upotrebe, te da se promptne predmemorije ne dijele između organizacija.

Uzorak implementacije je jednostavan: stavite stabilan sadržaj na prvo mjesto, a nepostojan sadržaj na posljednje mjesto.

Bolja struktura upita za predmemoriju

Upute sustava
Stabilan tekst pravila
Stabilna izlazna shema
Stabilni primjeri
Ponovno upotrebljivi referentni kontekst
---
Dinamički unos specifičan za zapis
Dinamički metapodaci korisnika ili retka

Na primjer, posao obogaćivanja kataloga može ponovno upotrijebiti istu taksonomiju, izlaznu shemu, pravila marke i primjere za 50.000 proizvoda. Svaki redak mijenja samo naslov proizvoda, opis i atribute. Postavljanje višekratno upotrebljivog prefiksa na prvo pružatelju pruža bolju priliku da ponovno upotrijebi predmemorirano računanje tamo gdje je to podržano.

Kompromis: predmemorija nije trajna pohrana i ne treba je tretirati kao zajamčenu. Prozori predmemorije, izolacija, minimalna duljina upita i izvješćivanje razlikuju se ovisno o pružatelju usluga. Mjerite predmemorirane tokene radije nego pretpostavljajte uštede.

Provjerite podršku pružatelja usluga prije slanja

Batch API-ji se razlikuju. Gateway bi trebao potvrditi podobnost prije nego što pošalje posao.

Činjenice: OpenAI Batch API ne podržava streaming i ima zasebna ograničenja batch ratea. Ograničenja paketa dokumenata Anthropic uključujući ograničenje veličine paketa od 100 000 zahtjeva ili 256 MB, istek od 24 sata, dostupnost rezultata od 29 dana, ograničenja stope i mogućnost da serije mogu neznatno premašiti konfigurirana ograničenja potrošnje radnog prostora. Google podržava ugrađene skupne zahtjeve za manje poslove ispod 20 MB i JSONL ulazne datoteke za veće skupne zahtjeve.

Upotrijebite popis za provjeru kompatibilnosti:

• Je li traženi model dostupan putem paketnog API-ja tog pružatelja?
• Je li krajnja točka podržana?
• Zahtijeva li zahtjev streaming? Ako da, odbacite seriju.
• Upotrebljava li alate ili nuspojave koje se moraju dogoditi odmah?
• Prelazi li paketna datoteka ograničenja pružatelja?
• Je li očekivani rezultat još uvijek koristan unutar davateljevog prozora za dovršetak?
• Jesu li izlazi dostupni dovoljno dugo da ih nizvodni sustavi dohvate?
• Može li radno opterećenje tolerirati djelomično dovršenje?

Preporuka: neuspješna provjera valjanosti rano s jasnim razlogom. Odbijeni paketni kandidat jeftiniji je od isteklog ili neispravnog posla koji se kasnije mora preraditi.

Zaštitne mjere za timove, agencije i partnere

Skupni sustavi mogu tiho potrošiti mnogo novca jer obrađuju velike datoteke u pozadini. Dodajte kontrole prije širokog predstavljanja:

• Skupni proračuni po timovima: odvojena ograničenja potrošnje na mreži i izvan nje.
• Maksimalna veličina datoteke i broj redaka: nametnite ograničenja pružatelja usluga i vlastita operativna ograničenja.
• Ček čekanja mrtvih pisama: sačuvajte nevažeće retke s pogreškama provjere za pregled.
• Ključevi idempotencije: sprječavaju duple naplate od slučajnog ponovnog podnošenja.
• Pregled PII: skupne datoteke mogu stvoriti nove obveze zadržavanja podataka i privatnosti.
• Pravila zadržavanja: definirajte koliko dugo se pohranjuju datoteke zahtjeva, izlazne datoteke i zapisnici.
• Pravila obavijesti: upozorite vlasnike kada poslovi ne uspiju, isteknu ili premaše proračun.
• Atribucija: zabilježite projekt, tim, kupca, API ključ, model, pružatelja usluga, ID posla i ID retka.

Za agencije i preprodavače atribucija je posebno važna. Ako jedan partner vodi poslove obogaćivanja ili evaluacije za mnoge klijente, sustav bi trebao prijaviti trošak po klijentu i po poslu, a ne samo po fakturi dobavljača.

Kako se ovo preslikava na AI API pristupnik

Pristupnik AI API-ja prirodno je mjesto za implementaciju toga jer se već nalazi između aplikacija i pružatelja modela. Gateway može sačuvati OpenAI-kompatibilnu API površinu za razvojne programere dok iza sebe dodaje zakazivanje svjesno troškova.

Korisne mogućnosti pristupnika uključuju:

• Objedinjena naplata: usporedite sinkronu, skupnu, predmemoriranu i zamjensku potrošnju na jednom mjestu.
• Analitika upotrebe umjetne inteligencije: raščlanite upotrebu prema modelu, pružatelju usluga, krajnjoj točki, timu, projektu i API ključu.
• Timske kontrole: postavite zasebne proračune za interaktivna i izvanmrežna radna opterećenja.
• Atribucija ključa API-ja: identificirajte koja je usluga ili korisnik kreirao svaki posao.
• Obavijesti o statusu: šaljite upozorenja kada se skupni poslovi dovrše, ne uspiju, isteknu ili se približi rok.
• Partner API tijek rada: neka agencije ili preprodavači stvaraju poslove i dohvaćaju rezultate u ime klijenata uz očuvanje računovodstva na razini klijenta.

Predviđanje: više će timova upravljati troškovima LLM-a s pravilima zakazivanja, a ne samo zamjenama modela. Kako paketna podrška sazrijeva među pružateljima usluga, pobjednička arhitektura usmjeravat će se prema hitnosti, kompatibilnosti značajki i računovodstvenim zahtjevima prije nego što usmjeri prema cijeni modela.

Popis za provjeru implementacije

• Izvezite 30 dana LLM API korištenja.
• Klasificirajte svako radno opterećenje kao u stvarnom vremenu, blizu mreže ili izvan mreže.
• Odaberite jedno izvanmrežno radno opterećenje s jasnim vlasništvom i rokom opraštanja.
• Potvrdite paketnu podršku pružatelja za potrebnu krajnju točku i model.
• Definirajte interna stanja poslova i statuse na razini retka.
• Dodajte ključeve idempotencije, ID-ove poslova i ID-ove po retku.
• Pohranjujte normalizirane zapise zahtjeva i odgovora s kontrolama zadržavanja.
• Pošaljite prvu seriju iza oznake značajke.
• Izmjerite sinkroni osnovni trošak u odnosu na prilagođeni skupni trošak.
• Restrukturirajte ponovljene duge upite da biste prvo stavili stabilne prefikse.
• Pratite predmemorirane tokene, neuspjele retke, istekle poslove i rezervnu potrošnju.
• Proširite samo nakon što uštede i operativno ponašanje budu vidljivi u analitici.

Zaključak koji se može poduzeti

Ne započinjite kontrolu troškova AI API-ja tražeći od svakog tima da koristi jeftiniji model. Započnite s odvajanjem hitnog posla od onoga koji može čekati. Održavajte interaktivne zahtjeve sinkronima. Premjestite evaluacije, obogaćivanje, označavanje, popunjavanje, moderiranje i izvješća u paket kada podrška pružatelja usluga i poslovni rokovi odgovaraju. Struktura ponovljenih dugih upita za predmemoriju. Zatim izmjerite stvarne uštede nakon kvarova, ponovnih pokretanja, pohrane i rezervnih troškova.

Najbolja implementacija je namjerno dosadna: ID-ovi poslova, provjera valjanosti, statusi na razini redaka, proračuni, analitika korištenja i jasno vlasništvo. Taj operativni sloj je ono što popuste pružatelja pretvara u pouzdanu uštedu.

Povezana literatura

• Atribucija ključeva API-ja i kontrole timske potrošnje
• pravila usmjeravanja, ponovnih pokušaja i zamjenskih pravila za LLM API-je
• povezana implementacija Model Gate bilješke