Znížte náklady na LLM API pomocou dávkových úloh a rýchleho ukladania do vyrovnávacej pamäte: Praktická príručka

Mnoho tímov prepláca za rozhrania LLM API, pretože každú požiadavku posielajú cez rovnakú synchrónnu cestu. To je vhodné pre chat, asistentov kódovania, podporných agentov, platobné toky a čokoľvek, čo čaká na používateľa. Je to zbytočné na hodnotenia, označovanie, obohacovanie, moderovanie, vkladanie záložných reklám, nočné správy a predbežné spracovanie obsahu.

Praktická otázka nie je „Ktorý model je najlacnejší?“ Je to: ktorá práca skutočne potrebuje okamžitú reakciu a ktorá môže počkať? Keď na to odpoviete, riadenie nákladov AI API sa stane inžinierskym pracovným postupom: klasifikujte prevádzku, odosielajte úlohy s toleranciou latencie na dávkové spracovanie, ak je to podporované, štruktúrujte opakované výzvy na ukladanie do vyrovnávacej pamäte a merajte skutočné úspory po zlyhaniach, opakovaných pokusoch a prevádzkovej réžii.

Začnite auditom nákladov podľa pracovného zaťaženia, nie podľa modelu

Pred zmenou architektúry exportujte vzorku nedávneho používania rozhrania API a zoskupte ju podľa pracovného zaťaženia. Užitočná tabuľka auditu by mala obsahovať:

• Koncový bod a model: dokončenia četu, odpovede, vloženia, moderovanie alebo koncové body špecifické pre poskytovateľa.
• Priemerné vstupné a výstupné tokeny: oddeľte dlhé výzvy od krátkych klasifikačných úloh.
• Tvar výzvy: stabilné systémové pokyny, opakovane použiteľné príklady, schémy, kontext načítania a dynamické údaje používateľa.
• Požiadavka latencie: sekundy, minúty, hodiny alebo nasledujúci pracovný deň.
• Viditeľnosť používateľa: či osoba čaká na výsledok.
• Počet opakovaných pokusov a zlyhaní: chybné požiadavky, zlyhania overenia, uplynutie časového limitu poskytovateľa, úlohy s vypršanou platnosťou a duplicitné odoslania.
• Vlastníctvo: projekt, tím, zákazník, kľúč API alebo partnerský účet.
• Business SLA: posledný čas, kedy je výsledok stále užitočný.

Tento audit zvyčajne odhalí, že „prevádzka LLM“ nie je jedno pracovné zaťaženie. Ide o kombináciu interaktívnych funkcií produktu, internej automatizácie, reportingu, prípravy dát a hodnotenia kvality. Považovať ich za jedno nákladové stredisko skrýva najjednoduchšie úspory.

Použite trojprúdový klasifikátor pracovného zaťaženia

Jednoduchý klasifikátor zabraňuje tímom presunúť nesprávnu návštevnosť do dávky a potom ich prekvapiť zmeškanými očakávaniami.

Ruha 1: interaktívne požiadavky v reálnom čase

Zachovajte ich synchrónne. Zahŕňajú chat UX, kopilotov, podporných agentov, kontrolu človekom v slučke, živé vyhľadávanie alebo získavanie a volania nástrojov s okamžitými vedľajšími účinkami. Ak používateľ čaká, hodnota lacnejšej odpovede môže byť vymazaná latenciou.

Odporúčanie: optimalizujte tento jazdný pruh výberom modelu, rýchlym orezaním, správou rýchlostného limitu, ukladaním do vyrovnávacej pamäte tam, kde je to možné, a opatrnými pokusmi. Neposielajte ho do 24-hodinového dávkového frontu, pokiaľ to produkt výslovne neprezentuje ako úlohu na pozadí.

Druh 2: Nepriame požiadavky, ktoré môžu čakať niekoľko minút

Tieto úlohy nemusia blokovať načítanie stránky, ale stále môžu očakávať rovnakú reláciu alebo rovnakú hodinu. Príklady zahŕňajú analýzu dokumentov po nahraní, obohatenie CRM po odoslaní formulára alebo správu, ktorá môže používateľa upozorniť, keď bude pripravený.

Odporúčanie: prácu nablízku umiestnite do poradia s explicitnými stavmi. V závislosti od podpory poskytovateľa a termínu ho spustite buď prostredníctvom malých dávok alebo synchrónnych pracovníkov s nižšou prioritou. Tento pruh využíva ID úloh, webhooky a pokrok viditeľný pre používateľov.

Plán 3: offline dávkové požiadavky, ktoré môžu čakať až 24 hodín

Toto je hlavný pruh optimalizácie nákladov. Medzi dobrých kandidátov patria:

• rozsiahle hodnotenia;
• označenie množiny údajov;
• obohatenie katalógu alebo CRM;
• nočný súhrn;
• fronty na kontrolu súladu;
• vkladanie záložných reklám;
• moderovanie záťahov;
• pravidelné generovanie prehľadov;
• predbežné spracovanie obsahu pred indexovaním alebo publikovaním.

Fakt: hlavní poskytovatelia teraz ponúkajú asynchrónne dávkové rozhrania API pre vhodné pracovné zaťaženia. Batch API OpenAI číta požiadavky z nahraného súboru, zapisuje výsledky do výstupného súboru a zacieľuje spracovanie do 24 hodín. OpenAI uvádza, že podporované používanie Batch API je ponúkané s 50% zľavou v porovnaní so synchrónnymi API. Rozhranie API Anthropic Message Batches je navrhnuté pre veľké objemy žiadostí o správy, asynchrónne spracovanie, vyššiu priepustnosť a o 50 % nižšie náklady. Rozhranie API Gemini Batch od spoločnosti Google je navrhnuté pre veľké objemy asynchrónnych žiadostí za 50 % štandardných nákladov s cieľovým časom spracovania 24 hodín.

Výmena: „až 24 hodín“ je vynikajúce pre záložné reklamy a hodnotenia, ale je neprijateľné pre interaktívne pracovné postupy. Dávka je stratégia plánovania, nie univerzálna náhrada za synchrónnu inferenciu.

Navrhnite cestu dávky ako životný cyklus úlohy

Chybou implementácie, ktorej sa treba vyhnúť, je zaobchádzanie s dávkou ako s jedným volaním rozhrania API. Je to životný cyklus: prijmite prácu, overte ju, zotrvajte v nej, odošlite ju, odošlite prieskum, zosúlaďte ju a vystavte výsledky.

Referenčná architektúra

1. Prijmite normalizovanú požiadavku: ak je to možné, ponechajte tvar žiadosti blízko k vášmu existujúcemu formátu API kompatibilnému s OpenAI. Pridajte metadáta, ako je projekt, tím, zákazník, kľúč idempotencie, požadovaný termín a nákladové stredisko.
2. Klasifikácia pracovného zaťaženia: priraďte požiadavku k dávke v reálnom čase, na blízko alebo offline. Toto by malo byť založené na zásadách, nie skryté v kóde aplikácie.
3. Vytvorte ID úlohy: okamžite vráťte identifikátor úlohy pre prácu nablízku a offline.
4. Overenie kompatibility: skontrolujte, či vybraný poskytovateľ a model podporujú dávku pre požadovaný koncový bod, modalitu, veľkosť súboru, nástroje, formát odpovede a ďalšie funkcie.
5. Pretrvávať riadky žiadostí: ukladať normalizované riadky JSONL alebo dátové zaťaženie špecifické pre poskytovateľa. Zahrňte stabilné ID riadka na vyrovnanie.
6. Odoslanie dávky: odovzdanie súboru požiadavky alebo vloženej dávky v závislosti od limitov poskytovateľa a veľkosti úlohy.
7. Stav ankety: sledujte stavy poskytovateľa, ako je overovanie, prebieha, dokončené, zlyhalo, platnosť vypršala, ruší sa a ak je to možné, zrušené.
8. Ukladanie výstupných riadkov: zapisovanie úspešných odpovedí, chýb na úrovni riadkov, použitia tokenov, počtu tokenov uložených vo vyrovnávacej pamäti, ak sú k dispozícii, a identifikátorov poskytovateľa.
9. Upozorniť spotrebiteľov: zobraziť koncový bod získavania, webhook, upozornenie na informačnom paneli alebo telegramové upozornenie.
10. Zosúladenie fakturácie: priraďte náklady pôvodnému projektu, tímu, zákazníkovi, kľúču API a ID úlohy.

Tento vzor umožňuje jednoduchú aplikáciu. Produktové tímy odosielajú prácu a prijímajú stavy úloh. Vrstva brány alebo orchestrácie spracováva rozdiely medzi poskytovateľmi, dávkové súbory, opakované pokusy a účtovanie.

Používajte explicitné stavy úloh

Definujte interné stavy, aj keď každý poskytovateľ používa iné názvy:

• v rade: prijaté, ale neodoslané;
• overuje sa: poskytovateľ alebo brána kontroluje súbor;
• beží: odosiela sa a spracováva sa;
• dokončené: zhromaždili sa všetky dostupné výsledky;
• completed_with_errors: overenie alebo vykonanie niektorých riadkov zlyhalo;
• vypršala: termín uplynul pred dokončením všetkých riadkov;
• zrušené: zastavené používateľom, systémom alebo zásadou;
• zlyhalo: zlyhanie na úrovni úlohy, ktoré si vyžaduje zásah.

Fakt: OpenAI dokumentuje stavy dávok vrátane overovania, zlyhania, prebiehajúceho procesu, dokončenia, vypršania platnosti, zrušenia a zrušenia. Poznamenáva tiež, že ak vyprší platnosť dávky, už dokončená práca sa vráti a zaúčtuje, zatiaľ čo zostávajúca práca sa zruší.

Odporúčanie: nikdy nepredpokladajte, že dávkové úlohy sú všetko alebo nič. Vytvorte spracovanie stavu na úrovni riadkov od začiatku.

Vypočítajte úspory po zlyhaniach a režijných nákladoch

Väčšine tímov stačí jednoduchý model sporenia:

baseline_cost = synchronous_input_cost + synchronous_output_cost
batch_cost = diskontované_dávkové_vstupné_náklady + diskontované_výstupné_náklady_dávky
adjust_batch_cost = batch_cost + orchestration_cost + storage_cost + rerun_cost
odhadované_úspory = základné_náklady – upravené_náklady_dávky

Potom to vypočítajte podľa pracovného zaťaženia, nie globálne. Súprava na nočné hodnotenie môže výrazne ušetriť. Takmer riadkový pracovný postup s mnohými chybnými riadkami, naliehavými záložnými reklamami alebo opakovanými opakovaniami môže ušetriť menej, než sa očakávalo.

Sledujte aspoň tieto metriky:

• synchronizácia versus dávkové výdavky na tokeny;
• vstupné a výstupné tokeny podľa modelu;
• počet hromadných úloh a priemerný počet riadkov na úlohu;
• miera zlyhania na úrovni riadkov;
• miera uplynutej úlohy;
• náklady na opätovné spustenie;
• náklady na záložnú synchronizáciu;
• náklady podľa tímu, projektu, kľúča, zákazníka a partnerského účtu.

Odporúčanie: automatické synchrónne záložné riešenie považovať za výnimku, nie za predvolené nastavenie. Chráni termíny, ale pri nadmernom používaní môže vymazať očakávané úspory. Pridajte pravidlo, ako napríklad „záložné riešenie iba v prípade, že pracovný termín uplynie do dvoch hodín a úloha sa ešte nezačala.“

Pridať ukladanie výziev do vyrovnávacej pamäte pre opakované dlhé predpony

Dávkové spracovanie znižuje jednotkovú cenu oprávnenej práce. Ukladanie výziev do vyrovnávacej pamäte znižuje efektívne náklady a latenciu opakovaných dlhých výziev, keď to správanie poskytovateľa podporuje.

Fakt: Ukladanie výziev OpenAI do vyrovnávacej pamäte sa automaticky vzťahuje na výzvy dlhšie ako 1 024 tokenov na podporovaných modeloch, do vyrovnávacej pamäte ukladá najdlhšiu predtým vypočítanú predponu a uvádza cached_tokens v podrobnostiach o používaní rozhrania API. OpenAI hovorí, že vyrovnávacie pamäte výziev sa zvyčajne vymažú po 5 až 10 minútach nečinnosti a odstránia sa do jednej hodiny od posledného použitia a že vyrovnávacie pamäte výziev sa medzi organizáciami nezdieľajú.

Vzor implementácie je jednoduchý: stabilný obsah dajte na prvé miesto a nestály obsah až na koniec.

Lepšia štruktúra výziev pre ukladanie do vyrovnávacej pamäte

Systémové pokyny
Text stabilnej politiky
Stabilná výstupná schéma
Stabilné príklady
Opakovane použiteľný referenčný kontext
---
Dynamický vstup špecifický pre záznam
Dynamické metadáta používateľa alebo riadka

Napríklad úloha obohatenia katalógu môže opätovne použiť rovnakú taxonómiu, výstupnú schému, pravidlá značky a príklady pre 50 000 produktov. Každý riadok mení iba názov produktu, popis a atribúty. Umiestnenie opätovne použiteľnej predpony na prvé miesto poskytuje poskytovateľovi väčšiu šancu opätovne použiť výpočty uložené vo vyrovnávacej pamäti, ak sú podporované.

Výmena: ukladanie do vyrovnávacej pamäte nie je trvalé úložisko a nemalo by sa považovať za zaručené. Okná vyrovnávacej pamäte, izolácia, minimálna dĺžka výzvy a hlásenie sa líšia podľa poskytovateľa. Radšej merajte tokeny uložené vo vyrovnávacej pamäti než predpokladajte úspory.

Pred odoslaním overte podporu poskytovateľa

Rozhrania API dávky sa líšia. Brána by mala overiť oprávnenosť pred odoslaním úlohy.

Fakty: OpenAI Batch API nepodporuje streamovanie a má samostatné limity dávkovej rýchlosti. Obmedzenia dávok antropických dokumentov vrátane limitu 100 000 žiadostí alebo 256 MB veľkosti dávky, 24-hodinového uplynutia platnosti, 29-dňovej dostupnosti výsledkov, limitov rýchlosti a možnosti, že dávky môžu mierne presiahnuť limity výdavkov nakonfigurovaných v pracovnom priestore. Google podporuje vložené dávkové požiadavky pre menšie úlohy do 20 MB a vstupné súbory JSONL pre väčšie dávkové požiadavky.

Použite kontrolný zoznam kompatibility:

• Je požadovaný model dostupný prostredníctvom dávkového rozhrania API daného poskytovateľa?
• Je koncový bod podporovaný?
• Vyžaduje si žiadosť streamovanie? Ak áno, odmietnite dávku.
• Používa nástroje alebo vedľajšie účinky, ktoré musia nastať okamžite?
• Prekračuje dávkový súbor limity poskytovateľa?
• Je očakávaný výsledok stále užitočný v rámci okna dokončenia poskytovateľa?
• Sú výstupy dostupné dostatočne dlho na to, aby ich následné systémy mohli získať?
• Môže pracovné zaťaženie tolerovať čiastočné dokončenie?

Odporúčanie: zlyhá overenie skôr s jasným dôvodom. Odmietnutý kandidát na dávku je lacnejší ako úloha s vypršanou platnosťou alebo chybnou formou, ktorú je potrebné neskôr prepracovať.

Záruky pre tímy, agentúry a partnerov

Dávkové systémy môžu pokojne minúť veľa peňazí, pretože spracúvajú veľké súbory na pozadí. Pridanie ovládacích prvkov pred širokým zavedením:

• Dávkové rozpočty na tím: samostatné limity výdavkov online a offline.
• Maximálna veľkosť súboru a počet riadkov: presadzujte limity poskytovateľa a svoje vlastné prevádzkové limity.
• Poradie nedoručených listov: zachovajte neplatné riadky s chybami overenia na kontrolu.
• Kľúče identity: zabraňujú náhodnému opätovnému odoslaniu duplicitných poplatkov.
• Kontrola PII: dávkové súbory môžu vytvárať nové povinnosti týkajúce sa uchovávania údajov a ochrany osobných údajov.
• Pravidlá uchovávania: definujú, ako dlho sa budú uchovávať súbory požiadaviek, výstupné súbory a protokoly.
• Zásady upozornení: upozorní vlastníkov, keď úlohy zlyhajú, vypršia alebo prekročia rozpočet.
• Priradenie: záznam projektu, tímu, zákazníka, kľúča API, modelu, poskytovateľa, ID úlohy a ID riadku.

Pre agentúry a predajcov je pripisovanie obzvlášť dôležité. Ak jeden partner vykonáva úlohy obohatenia alebo hodnotenia pre mnohých klientov, systém by mal vykazovať náklady na klienta a na úlohu, nielen na faktúru poskytovateľa.

Ako sa to mapuje na bránu AI API

Prirodzeným miestom na implementáciu je brána AI API, pretože už sedí medzi aplikáciami a poskytovateľmi modelov. Brána môže pre vývojárov zachovať povrch API kompatibilný s OpenAI a zároveň pridať plánovanie s ohľadom na náklady.

Užitočné možnosti brány zahŕňajú:

• Jednotná fakturácia: porovnajte synchrónne, dávkové, uložené a záložné výdavky na jednom mieste.
• Analýza používania AI: rozdelenie používania podľa modelu, poskytovateľa, koncového bodu, tímu, projektu a kľúča API.
• Tímové kontroly: nastavte samostatné rozpočty pre interaktívne a offline pracovné zaťaženie.
• Priradenie kľúča API: identifikujte, ktorá služba alebo zákazník vytvoril jednotlivé úlohy.
• Upozornenia o stave: odosielať upozornenia, keď sa dávkové úlohy dokončia, zlyhajú, uplynie alebo sa blíži konečný termín.
• Pracovné postupy rozhrania API partnera: umožňujú agentúram alebo predajcom vytvárať pracovné miesta a získavať výsledky v mene klientov pri zachovaní účtovníctva na úrovni klienta.

Predpoveď: Viac tímov bude riadiť náklady LLM pomocou plánovacích pravidiel, nielen modelových suplovaní. Ako sa dávková podpora u jednotlivých poskytovateľov rozvíja, víťazná architektúra sa bude smerovať podľa naliehavosti, kompatibility funkcií a účtovných požiadaviek predtým, ako bude smerovaná podľa ceny modelu.

Kontrolný zoznam implementácie

• Exportujte 30 dní používania LLM API.
• Klasifikujte každú pracovnú záťaž ako real-time, nearline alebo offline.
• Vyberte si jedno offline pracovné zaťaženie s jasným vlastníctvom a zhovievavým termínom.
• Overte dávkovú podporu poskytovateľa pre požadovaný koncový bod a model.
• Definujte interné stavy úloh a stavy na úrovni riadkov.
• Pridajte kľúče idempotencie, ID úloh a ID riadkov.
• Uchovávajte normalizované záznamy žiadostí a odpovedí s ovládacími prvkami uchovávania.
• Odošlite prvú dávku za príznakom objektu.
• Merajte synchrónne základné náklady v porovnaní s upravenými nákladmi v dávkach.
• Zmeniť štruktúru opakovaných dlhých výziev tak, aby boli na prvé miesto stabilné predpony.
• Sledujte tokeny uložené vo vyrovnávacej pamäti, neúspešné riadky, úlohy s vypršanou platnosťou a záložné výdavky.
• Rozbaliť až po tom, ako sa úspory a prevádzkové správanie zobrazia v analytike.

Uplatniteľný záver

Nezačínajte riadenie nákladov AI API tým, že požiadate každý tím, aby použil lacnejší model. Začnite oddelením urgentnej práce od práce, ktorá môže počkať. Udržujte interaktívne požiadavky synchrónne. Presuňte hodnotenia, obohatenie, označovanie, spätné výplne, kontroly moderovania a zostavy do dávok, keď budú vyhovovať termínom podpory poskytovateľa a obchodu. Štruktúra opakujúcich sa dlhých výziev na ukladanie do vyrovnávacej pamäte. Potom zmerajte skutočné úspory po zlyhaniach, opakovaných spusteniach, skladovaní a náhradných nákladoch.

Najlepšia implementácia je zámerne nudná: ID úloh, overenie, stavy na úrovni riadkov, rozpočty, analýzy používania a jasné vlastníctvo. Táto operačná vrstva je to, čo premieňa zľavy poskytovateľa na spoľahlivé úspory.

Súvisiace čítanie

• Pripisovanie kľúčov API>
• href="https://model-gate.com/en/blog/reliable-llm-api-routing-timeouts-retries-model-fallbacks-3/">pravidlá smerovania, opakovania a záložných pravidiel pre LLM API
• ul súvisiace poznámky k implementácii brány modelu