Csökkentse az LLM API-költségeket a kötegelt munkákkal és az azonnali gyorsítótárazással: gyakorlati útmutató

Sok csapat túlfizet az LLM API-kért, mert minden kérést ugyanazon a szinkron útvonalon küldenek. Ez megfelelő a csevegéshez, a kódolási asszisztensekhez, a támogatási ügynökökhöz, a fizetési folyamatokhoz és bármihez, ami a felhasználóra vár. Pazarló az értékelések, a címkézés, a gazdagítás, a moderálás, a háttérkitöltések beágyazása, az éjszakai jelentések és a tartalom előfeldolgozása miatt.

A gyakorlati kérdés nem az, hogy „Melyik modell a legolcsóbb?” Ez: melyik munkára van szükség azonnali válaszra, és melyik munka várhat még? Ha ezt megválaszolja, az AI API költségszabályozása mérnöki munkafolyamattá válik: osztályozza a forgalmat, küldje el a késleltetéstűrő feladatokat a kötegelt feldolgozáshoz, ahol ez támogatott, strukturálja az ismételt gyorsítótárazási kéréseket, és mérje meg a valós megtakarítást hibák, újrapróbálkozások és működési többletköltségek után.

Kezdje a költségellenőrzéssel munkaterhelés, nem modell szerint

Az architektúra megváltoztatása előtt exportáljon egy mintát a legutóbbi API-használatból, és csoportosítsa azt munkaterhelés szerint. Egy hasznos ellenőrzési táblázatnak tartalmaznia kell:

• Végpont és modell: csevegés befejezése, válaszok, beágyazások, moderálás vagy szolgáltató-specifikus végpontok.
• Átlagos bemeneti és kimeneti tokenek: válassza el a hosszú promptokat a rövid osztályozási feladatoktól.
• Prompt shape: stabil rendszerutasítások, újrafelhasználható példák, sémák, lekérési kontextus és dinamikus felhasználói adatok.
• Késési idő: másodperc, perc, óra vagy a következő munkanap.
• Felhasználói láthatóság: hogy egy személy várja-e az eredményt.
• Újrapróbálkozási és sikertelenségi arány: rosszul formázott kérések, ellenőrzési hibák, szolgáltatói időtúllépések, lejárt feladatok és ismétlődő beküldések.
• Tulajdonjog: projekt, csapat, ügyfél, API-kulcs vagy partnerfiók.
• Üzleti SLA: az utolsó időpont, amikor az eredmény még hasznos.

Ez az ellenőrzés általában felfedi, hogy az „LLM-forgalom” nem egyetlen munkaterhelés. Interaktív termékfunkciók, belső automatizálás, jelentéskészítés, adat-előkészítés és minőségértékelés keveréke. Ha egyetlen költséghelyként kezeli őket, akkor a legkönnyebb megtakarítás érhető el.

Használjon háromsávos munkaterhelés-osztályozót

Egy egyszerű osztályozó megakadályozza, hogy a csapatok rossz forgalmat helyezzenek át a kötegbe, majd meglepjék őket az elmulasztott elvárások miatt.

1. sáv: valós idejű interaktív kérések

Tartsa ezeket szinkronban. Ide tartoznak a chat UX, a másodpilóták, a támogató ügynökök, a human-in-the-loop áttekintés, az élő keresési vagy visszakeresési folyamatok, valamint az azonnali mellékhatásokkal járó eszközhívások. Ha egy felhasználó várakozik, az olcsóbb válasz értéke a késleltetéssel törölhető.

Javaslat: optimalizálja ezt a sávot modellválasztással, azonnali vágással, sebességkorlát kezeléssel, gyorsítótárazással és gondos újrapróbálkozásokkal. Ne küldje 24 órás kötegelt sorba, kivéve, ha a termék kifejezetten háttérfeladatként mutatja be.

2. sáv: olyan közeli kérések, amelyek perceket várhatnak

Ezeknek a munkáknak nem kell blokkolniuk az oldalbetöltést, de előfordulhat, hogy ugyanaz a munkamenet vagy az óra várható. Ilyen például a feltöltés utáni dokumentumelemzés, a CRM-bővítés az űrlap elküldése után, vagy egy jelentés, amely értesíti a felhasználót, ha készen áll.

Javaslat: helyezze a közeli munkát explicit állapotállapotú várólista mögé. A szolgáltatói támogatástól és a határidőtől függően vagy kis kötegeken keresztül futtassa, vagy alacsonyabb prioritású szinkron dolgozókon keresztül. Ez a sáv a munkaazonosítók, a webhookok és a felhasználó által látható előrehaladás előnyeit élvezi.

3. sáv: offline kötegelt kérések, amelyek akár 24 órát is várhatnak

Ez a fő költségoptimalizálási sáv. A jó jelöltek a következők:

• nagyszabású értékelések;
• adatkészlet-címkézés;
• katalógus- vagy CRM-bővítés;
• éjszakai összefoglaló;
• megfelelőségi ellenőrzési sorok;
• háttérkitöltések beágyazása;
• moderálási söprés;
• időszakos jelentéskészítés;
• tartalom előfeldolgozása az indexelés vagy közzététel előtt.

Tény: a nagyobb szolgáltatók ma már aszinkron kötegelt API-kat kínálnak a megfelelő munkaterheléshez. Az OpenAI Batch API-ja beolvassa a kéréseket a feltöltött fájlból, az eredményeket kimeneti fájlba írja, és 24 órán belül megcélozza a feldolgozást. Az OpenAI kijelenti, hogy a támogatott Batch API-használatot 50%-os költségkedvezménnyel kínálják a szinkron API-khoz képest. Az Anthropic Message Batches API-ját nagy mennyiségű üzenetkérésre, aszinkron feldolgozásra, nagyobb átviteli sebességre és 50%-kal alacsonyabb költségre tervezték. A Google Gemini Batch API-ját nagy volumenű aszinkron kérésekre tervezték, a normál költség 50%-áért, 24 órás átfutási idővel.

Kiváltás: a „legfeljebb 24 óra” kiváló a háttérkitöltésekhez és kiértékelésekhez, de elfogadhatatlan az interaktív munkafolyamatoknál. A kötegelt ütemezési stratégia egy ütemezési stratégia, nem pedig a szinkron következtetések univerzális helyettesítője.

A kötegelt útvonal megtervezése feladat-életciklusként

Az elkerülendő megvalósítási hiba, hogy a köteget egyetlen API-hívásként kezeli. Ez egy életciklus: fogadd el a munkát, érvényesítsd, tartsd fenn, küldd be, szavazd meg, egyeztetd össze, és tedd közzé az eredményeket.

Referenciaarchitektúra

1. Normalizált kérés elfogadása: lehetőség szerint tartsa a kérés alakját közel a meglévő OpenAI-kompatibilis API-formátumhoz. Adjon hozzá metaadatokat, például projektet, csapatot, ügyfelet, idempotenciakulcsot, kért határidőt és költséghelyet.
2. A munkaterhelés osztályozása: rendelje hozzá a kérést valós idejű, közeli vagy offline köteghez. Ennek házirend-alapúnak kell lennie, nem pedig az alkalmazás kódjában.
3. Munkaazonosító létrehozása: azonnal küldjön vissza egy állásazonosítót a közeli és offline munkához.
4. Kompatibilitás ellenőrzése: ellenőrizze, hogy a kiválasztott szolgáltató és modell támogatja-e a köteget a kért végponthoz, modalitáshoz, fájlmérethez, eszközökhöz, válaszformátumhoz és egyéb szolgáltatásokhoz.
5. Kérelmessorok megőrzése: normalizált JSONL-sorok vagy szolgáltató-specifikus rakományok tárolása. Adjon meg egy stabil sorazonosítót az egyeztetéshez.
6. Köteg beküldése: töltse fel a kérésfájlt vagy a soron belüli kötegelt rakományt a szolgáltatói korlátoktól és a munka méretétől függően.
7. Szavazás állapota: nyomon követheti a szolgáltató állapotait, például érvényesítés, folyamatban, befejezett, sikertelen, lejárt, törölt és törölt, ahol lehetséges.
8. Kimeneti sorok tárolása: írja be a sikeres válaszokat, a sorszintű hibákat, a tokenhasználatot, a gyorsítótárazott tokenszámokat, ahol elérhető, és a szolgáltató azonosítóit.
9. A fogyasztók értesítése: lekérési végpont, webhook, irányítópult-értesítés vagy távirati figyelmeztetés megjelenítése.
10. Számlázás egyeztetése: rendeljen költséget az eredeti projekthez, csapathoz, ügyfélhez, API-kulcshoz és munkaazonosítóhoz.

Ez a minta egyszerűvé teszi az alkalmazást. A termékcsapatok beküldik a munkát, és megkapják a munkaállapotokat. Az átjáró vagy a hangszerelési réteg kezeli a szolgáltatók közötti különbségeket, a kötegfájlokat, az újrapróbálkozásokat és a könyvelést.

Használjon kifejezett feladatállapotokat

Határozzon meg belső állapotokat még akkor is, ha az egyes szolgáltatók különböző neveket használnak:

• queued: elfogadva, de nem küldték el;
• ellenőrzés: a szolgáltató vagy az átjáró ellenőrzi a fájlt;
• fut: elküldve és feldolgozás alatt;
• befejezve: az összes elérhető eredmény összegyűjtve;
• completed_with_errors: egyes sorok ellenőrzése vagy végrehajtása sikertelen;
• lejárt: a határidő lejárt az összes sor kitöltése előtt;
• megszakítva: felhasználó, rendszer vagy szabályzat leállította;
• sikertelen: feladat szintű hiba, amely beavatkozást igényel.

Tény: Az OpenAI a kötegelt állapotokat dokumentálja, beleértve az érvényesítést, a sikertelent, a folyamatban lévőt, a befejezett, a lejárt, a törlést és a törölt állapotot. Azt is megjegyzi, hogy ha egy köteg lejár, a már befejezett munkát visszaküldik, és felszámítják, míg a fennmaradó munkát törlik.

Javaslat: soha ne feltételezze, hogy a kötegelt feladatok „mindent vagy semmit” típusúak. Készítsen sorszintű állapotkezelést a kezdetektől.

A hibák és az általános költségek utáni megtakarítások kiszámítása

A legtöbb csapat számára elegendő egy egyszerű megtakarítási modell:

baseline_cost = szinkron_bemeneti_költség + szinkron_kimeneti_költség
batch_cost = kedvezményes_kötegelt_bemeneti_költség + kedvezményes_kötegelt_kimeneti_költség
korrigált_kötegköltség = kötegköltség + rendezési_költség + tárolási_költség + újrafutási_költség
becsült_megtakarítás = kiindulási_költség – korrigált_kötegköltség

Ezután ezt munkaterhelésenként számítsa ki, ne globálisan. Egy éjszakai kiértékelő csomag jelentősen megtakaríthat. A sok helytelenül formázott sort, sürgős tartalékolást vagy ismételt újrafutást tartalmazó, közeli munkafolyamat a vártnál kevesebbet takaríthat meg.

Kövesse nyomon legalább ezeket a mutatókat:

• szinkronizálás és kötegelt tokenköltés;
• bemeneti és kimeneti tokenek modellenként;
• kötegelt feladatok száma és átlagos sorok munkánként;
• sorszintű hibaarány;
• lejárt állások aránya;
• újrafuttatás költsége;
• tartalék szinkronizálási költség;
• csapat, projekt, kulcs, ügyfél és partnerfiók költsége.

Javaslat: az automatikus szinkron tartalékot kezelje kivételként, ne alapértelmezettként. Megvédi a határidőket, de túlzott használat esetén törölheti a várható megtakarításokat. Adjon hozzá egy szabályzatot, például „csak akkor, ha az üzleti határidő két órán belül van, és a munka még nem kezdődött el.”

Adjon hozzá azonnali gyorsítótárat az ismétlődő hosszú előtagokhoz

A kötegelt feldolgozás csökkenti a támogatható munka egységárát. Az azonnali gyorsítótárazás csökkenti az ismétlődő hosszú felszólítások tényleges költségét és késleltetését, ha a szolgáltatói viselkedés ezt támogatja.

Tény: Az OpenAI prompt gyorsítótárazása automatikusan vonatkozik az 1024 tokennél hosszabb promptokra a támogatott modelleken, gyorsítótárazza a korábban kiszámított leghosszabb előtagot, és a cached_tokens jelentést tartalmazza az API használati részleteiben. Az OpenAI szerint az azonnali gyorsítótárak általában 5-10 perc inaktivitás után törlődnek, és az utolsó használat után egy órán belül törlődnek, és a gyorsítótárak nincsenek megosztva a szervezetek között.

A megvalósítási minta egyszerű: a stabil tartalom legyen az első, az ingadozó tartalom pedig az utolsó.

Jobb prompt-struktúra a gyorsítótárazáshoz

Rendszerutasítások
Stabil politikai szöveg
Stabil kimeneti séma
Stabil példák
Újrafelhasználható hivatkozási kontextus
---
Dinamikus rekord-specifikus bemenet
Dinamikus felhasználói vagy sor metaadatok

Például egy katalógusbővítési feladat ugyanazt a taxonómiát, kimeneti sémát, márkaszabályokat és példákat használhatja újra 50 000 terméken. Minden sor csak a termék címét, leírását és attribútumait módosítja. Az újrafelhasználható előtag első elhelyezése nagyobb esélyt ad a szolgáltatónak a gyorsítótárazott számítások újrafelhasználására, ahol ez támogatott.

Kiváltás: a gyorsítótárazás nem állandó tárolás, és nem kezelendő garantáltként. A gyorsítótár ablakai, az elkülönítés, a minimális prompt hossza és a jelentések szolgáltatónként eltérőek. Mérje meg a gyorsítótárazott tokeneket, ahelyett, hogy megtakarítást feltételezne.

Elküldés előtt ellenőrizze a szolgáltatói támogatást

A kötegelt API-k eltérőek. Az átjárónak ellenőriznie kell a jogosultságot, mielőtt elküld egy munkát.

Tények: Az OpenAI Batch API nem támogatja a streamelést, és külön kötegelt sebességkorlátokkal rendelkezik. Az antropikus dokumentumok kötegkorlátozása, beleértve a 100 000 kérésre vagy 256 MB-os kötegméret-korlátozást, a 24 órás lejárati időt, az eredmények 29 napos elérhetőségét, a sebességkorlátokat és annak lehetőségét, hogy a kötegek kissé meghaladják a konfigurált munkaterület-költési korlátokat. A Google támogatja a soron belüli kötegelt kéréseket a kisebb, 20 MB-nál kisebb feladatokhoz, illetve a JSONL beviteli fájlokat a nagyobb kötegelt kérésekhez.

Használjon kompatibilitási ellenőrzőlistát:

• Elérhető a kért modell a szolgáltató kötegelt API-ján keresztül?
• Támogatott a végpont?
• A kérelemhez streamelés szükséges? Ha igen, utasítsa el a köteget.
• Használ olyan eszközöket vagy mellékhatásokat, amelyeknek azonnal meg kell történniük?
• A kötegfájl túllépi a szolgáltatói korlátokat?
• A várt eredmény továbbra is hasznos a szolgáltató befejezési időszakában?
• Elég hosszú ideig elérhetők a kimenetek ahhoz, hogy a későbbi rendszerek le tudják kérni őket?
• Elbírja-e a munkaterhelés a részleges befejezést?

Javaslat: egyértelmű ok miatt sikertelen a korai érvényesítés. Az elutasított kötegelt jelölt olcsóbb, mint egy lejárt vagy rosszul formált munka, amelyet később át kell dolgozni.

Biztonsági intézkedések a csapatok, ügynökségek és partnerek számára

A kötegelt rendszerek csendesen sok pénzt költhetnek, mivel nagy fájlokat dolgoznak fel a háttérben. Vezérlők hozzáadása az általános közzététel előtt:

• Csapatonkénti kötegelt költségkeretek: külön online és offline költési korlátok.
• Maximális fájlméret és sorszám: érvényesítse a szolgáltatói korlátokat és a saját működési korlátait.
• Holt betűs sor: az érvényesítési hibákat tartalmazó érvénytelen sorok megőrzése ellenőrzés céljából.
• Idempotency kulcsok: megakadályozzák a többszörös terhelések véletlen újraküldését.
• PII-ellenőrzés: a kötegelt fájlok új adatmegőrzési és adatvédelmi kötelezettségeket eredményezhetnek.
• Megőrzési szabályzat: határozza meg, hogy mennyi ideig legyenek tárolva a kérésfájlok, kimeneti fájlok és naplók.
• Értesítési szabályzat: figyelmezteti a tulajdonosokat, ha a megbízások meghiúsulnak, lejárnak vagy túllépik a költségkeretet.
• Hozzárendelés: rögzítse a projektet, csapatot, ügyfelet, API-kulcsot, modellt, szolgáltatót, munkaazonosítót és sorazonosítót.

Az ügynökségek és a viszonteladók számára a forrásmegjelölés különösen fontos. Ha az egyik partner sok ügyfélnél végez dúsítási vagy értékelési feladatokat, akkor a rendszernek kliensenként és munkánként kell jelentenie a költségeket, nem csak szolgáltatói számlánként.

Hogyan illeszkedik ez egy AI API-átjáróhoz

A mesterséges intelligencia API átjárója természetes hely ennek megvalósítására, mivel már az alkalmazások és a modellszolgáltatók között helyezkedik el. Az átjáró megőrizheti az OpenAI-kompatibilis API felületet a fejlesztők számára, miközben költségtudatos ütemezést ad hozzá.

A hasznos átjáró képességek közé tartoznak a következők:

• Egységes számlázás: egy helyen hasonlítsa össze a szinkron, kötegelt, gyorsítótárazott és tartalék kiadásokat.
• AI-használati elemzés: a használat lebontása modell, szolgáltató, végpont, csapat, projekt és API-kulcs szerint.
• Csapatvezérlők: külön költségkeret beállítása az interaktív és offline munkaterhelésekhez.
• API-kulcs hozzárendelése: azonosítsa, melyik szolgáltatás vagy ügyfél hozta létre az egyes feladatokat.
• Állapotértesítések: értesítést küld, ha a kötegelt feladatok befejeződnek, meghiúsulnak, lejárnak vagy közeledik a határidő.
• Partner API munkafolyamatok: lehetővé teszi az ügynökségek vagy viszonteladók számára, hogy munkahelyeket hozzanak létre, és lekérjék az eredményeket az ügyfelek nevében, az ügyfélszintű könyvelés megőrzése mellett.

Előrejelzés: több csapat fogja kezelni az LLM-költségeket ütemezési szabályokkal, nem csak a modellcseréket. A szolgáltatók kötegelt támogatásának előrehaladtával a nyertes architektúra a sürgősségi, a funkciók kompatibilitása és a számviteli követelmények szerint továbbítja az útvonalat, mielőtt a modellár alapján.

Megvalósítási ellenőrzőlista

• 30 napos LLM API-használat exportálása.
• Minden munkateher besorolása valós idejű, közeli vagy offline módba.
• Válasszon egy offline munkaterhelést egyértelmű tulajdonjoggal és elnéző határidővel.
• Érvényesítse a szolgáltató kötegelt támogatását a szükséges végponthoz és modellhez.
• Határozza meg a belső feladatállapotokat és a sorszintű állapotokat.
• Adjon hozzá idempotenciakulcsokat, munkaazonosítókat és soronkénti azonosítókat.
• Tároljon normalizált kéréseket és válaszrekordokat megőrzési vezérlőkkel.
• Küldje be az első köteget egy jellemzőjelző mögé.
• Mérje meg a szinkron alapköltséget a korrigált kötegelt költségekhez képest.
• Újrastrukturálja az ismétlődő hosszú felszólításokat, hogy a stabil előtagokat helyezze előtérbe.
• Nyomon követheti a gyorsítótárazott tokeneket, a sikertelen sorokat, a lejárt munkákat és a tartalék kiadásokat.
• Csak azután bontsa ki, hogy a megtakarítások és a működési viselkedés látható az elemzésben.

Intézhető következtetés

Ne indítsa el az AI API költségszabályozását úgy, hogy minden csapatot megkér egy olcsóbb modell használatára. Kezdje azzal, hogy különválasztja a sürgős munkát a várakozó munkától. Tartsa szinkronban az interaktív kéréseket. A kiértékeléseket, a gazdagítást, a címkézést, a háttérkitöltéseket, a moderálási sweepeket és a jelentéseket kötegbe helyezheti, amikor a szolgáltatói támogatás és az üzleti határidők megfelelnek. Strukturálja az ismétlődő hosszú promptokat a gyorsítótárazáshoz. Ezután mérje meg a tényleges megtakarításokat a hibák, az újrafutások, a tárolási és a tartalékköltségek után.

A legjobb megvalósítás szándékosan unalmas: munkaazonosítók, érvényesítés, sorszintű állapotok, költségvetések, használati elemzés és egyértelmű tulajdonjog. Ez a működési réteg az, ami a szolgáltatói kedvezményeket megbízható megtakarításokká változtatja.

Kapcsolódó olvasmány

• >>> költési kulcs attribútum

  és/API-kulcs attribution href="https://model-gate.com/en/blog/reliable-llm-api-routing-timeouts-retries-model-fallbacks-3/">útválasztási, újrapróbálkozási és tartalék házirendek LLM API-khoz