Az OpenRouter Batch API-t ad hozzá az alacsonyabb költségű aszinkron LLM-munkaterhelésekhez

Az OpenRouter elindított egy Batch API-ot az aszinkron LLM-következtetéshez, új költségfelülettel bővítve azokat a csapatokat, amelyek az azonnali szinkron válaszok fizetése helyett várhatnak az eredményekre.

A szeptember 22-i kiadás lehetővé teszi a felhasználók számára, hogy kötegelt munkaterheléseket küldjenek be a /api/v1/batches-ra a csevegés befejezéséhez, a válaszok beágyazásához és az üzenetek beágyazásához. Az OpenRouter szerint a funkció több mint 70 modellen működik. Azt is mondja, hogy a szolgáltatók általában a normál tokenenkénti ár 50%-át vagy kevesebbet számítanak fel, ha 24 órás időtartamon belül el tudják végezni a munkát.

Ez a bejelentés több, mint egy másik végpont. Ez formalizálja azt a felosztást, amelyet sok mesterséges intelligencia-csapat már informálisan kezel: egyes modellhívásoknak a felhasználó várakozása közben kell megtörténnie, míg mások a háttérben futhatnak. Az értékelések, az osztályozási feladatok, a beágyazások, a dokumentumbővítés, a címkézés, a háttérkitöltések, a red-team tesztcsomagok és a nagy összegző várólisták gyakran nem igényelnek alacsony késleltetésű válaszokat. Eddig ezek a munkák gyakran ugyanazokon a szinkron API mintákon haladtak keresztül, mint az interaktív termékfunkciók.

Mi változott

Az OpenRouter Batch API külön útvonalat hoz létre a munka számára, amely aszinkron módon sorba állítható és befejezhető. Ahelyett, hogy egyetlen kérést tennének és nyitva tartanának egy válaszútvonalat, a felhasználók egy köteget küldenek be, nyomon követik annak állapotát, és később lekérik az elkészült kimeneteket.

A gyakorlati változás éppolyan gazdasági, mint technikai jellegű. Az OpenRouter közleménye szerint a szolgáltatók általában a szabványos tokenenkénti díjak felére vagy kevesebbre árazzák ezeket a munkaterheléseket, ha a munkát 24 órás időtartamon belül el tudják végezni. A vállalat arról is beszámolt, hogy bétaverziója több mint 230 000 befejezett tételt kezelt, átlagosan 7 perces befejezési idővel.

Ezek a számok nem értelmezhetők egyetemes szolgáltatási szintű garanciaként. Az elérhető kedvezmény a szolgáltató támogatásától és az útválasztástól függ, a befejezési idő pedig modelltől, sormélységtől, terhelés alakjától és a szolgáltató kapacitásától függően változik. De az irány egyértelmű: API a platformok kezdik a késleltetést szándékos költségszabályozási eszközként felfedni.

Miért fontos ez az AI-csapatok számára

A fejlesztők számára a kötegelt feldolgozás megváltoztatja az LLM-munka megtervezését. A termékcsapat továbbra is használhat szinkron hívásokat a csevegéshez, a kódsegítéshez, az ügynöki eszköz használatához vagy az ügyfelek felé irányuló munkafolyamatokhoz. De ugyanaz a csapat az ismétlődő kiértékeléseket, az éjszakai tudásbázis-feldolgozást, a beágyazások generálását és az offline elemzéseket alacsonyabb költségű sorba helyezheti.

Ez azért számít, mert a token-ráfordítás egyre inkább megoszlik számos rejtett működési feladat között. Előfordulhat, hogy egy vállalat először észreveszi a látható mesterségesintelligencia-szolgáltatások költségeit, de a belső munkák a következtetések nagy részévé válhatnak, miután a csapatok elkezdik futtatni az értékeléseket, a minőségellenőrzéseket, a tartalom moderálását, az adatkészlet-átalakításokat és a visszakeresési karbantartást. A kötegelt API-k megkönnyítik a háttérben felmerülő munkaterhelések elkülönítését, költségkeretét és optimalizálását.

A kiadás az AI API költségszabályozásban is megerősít egy szélesebb mintát: a vállalatoknak többre van szükségük, mint a támogatott modellek listájára. Útválasztásra, megfigyelhetőségre, szabályzatra, használati elemzésre és számlázási logikára van szükségük, amelyek megértik az interaktív és a halasztott következtetés közötti működési különbséget.

A többmodelles átjárót használó csapatok számára a kötegelt következtetés azonnali irányítási kérdéseket vet fel. Mely szolgáltatók jogosultak kötegelt munkákra? Egyes modellek csak szinkron, felhasználó általi használatra engedélyezettek, míg az olcsóbb modelleket előnyben részesítik az offline értékeléshez? Hogyan lehet újrapróbálni a sikertelen kötegelemeket? A pénzügyi vagy platformcsapatok hozzárendelhetik-e az aszinkron tokenhasználatot a megfelelő termékhez, ügyfélhez, környezethez vagy belső csapathoz?

Kik érintett

A legnyilvánvalóbb haszonélvezők azok a csapatok, amelyek nagy mennyiségű késleltetéstűrő LLM-munkát végeznek. Az AI-értékelő csapatok szélesebb tesztcsomagokat futtathatnak anélkül, hogy minden kérést valós idejű tranzakcióként kezelnének. Az adatcsoportok alacsonyabb költséggel dolgozhatják fel a támogatási jegyek, dokumentumok, átiratok vagy termékkatalógusok elmaradását. A visszakereső csapatok beágyazásokat és metaadatokat hozhatnak létre a háttérben.A biztonsági és irányítási csapatok az irányelvek ellenőrzését vagy a munkaterhelések auditálását végezhetik anélkül, hogy versenyeznének a termelési késleltetési költségkeretekkel.

Az induló vállalkozások és a kisebb csapatok is előnyösek lehetnek, mert a kötegelt árazás olcsóbbá teheti a kísérletezést. A több modellt összefoglaló vagy osztályozás céljából összehasonlító csapat nagyobb offline teszteket futtathat, mielőtt elkötelezi magát egy gyártási útvonal mellett. Ennek ellenére a költségmegtakarítás nem automatikus. Ha egy munkafolyamat továbbra is blokkolja a felhasználót, vagy ha a későbbi rendszerek nem úgy vannak kialakítva, hogy lekérdezzék a befejezést és kezeljék a részleges hibákat, akkor a kötegelt modellbe kényszerítés több bonyolultságot eredményezhet, mint az érték.

A platform- és infrastruktúra-csapatok esetében a közlemény olyan termékkövetelményre mutat rá, amely valószínűleg elterjed. A kötegelt árképzés általánossá válásával a belső AI-platformoknak külön vezérlőkre lesz szükségük az aszinkron feladatokhoz: kvóták, jóváhagyási folyamatok, megőrzési szabályok, törlési viselkedés, állapotfigyelés és költség-hozzárendelés. Egyetlen összesített tokenszámláló nem lesz elég.

Ami továbbra is bizonytalan

A fő bizonytalanság az, hogy a megtakarítások mennyire következetesek a modellek és szolgáltatók között. Az OpenRouter az 50%-os szintet általános szolgáltatói mintaként írja le, nem pedig annak ígéretét, hogy minden modell vagy útvonal mindig elérhető lesz az adott kedvezménnyel. A vevőknek ellenőrizniük kell, hogy mely modellek támogatják a kötegelt módot, hogyan jelennek meg az árak a naplókban és a számlákban, és hogy az útválasztási változások megváltoztatják-e a várható gazdaságosságot.

Van egy működési kérdés is a befejezési időszakokkal kapcsolatban. A 24 órás időintervallum sok offline munkaterhelés esetén ésszerű, de a vállalkozásoknak továbbra is tudniuk kell, hogy a legtöbb munka percek, órák alatt vagy közel a határidőhöz fejeződik-e be. Az OpenRouter által közölt 7 perces medián béta-befejezési idő biztató, de a medián teljesítmény nem ad választ a késleltetéssel kapcsolatos kérdésekre a nagy gyártási tételek esetében.

A nagyobb jelentősége az, hogy az LLM-infrastruktúra egyre kevésbé monolitikus. A régi modell egyszerű volt: küldjön egy felszólítást, kapjon választ, fizesse ki a feltüntetett jelképes árat. A kialakulóban lévő modell inkább a felhőalapú infrastruktúra árképzéséhez hasonlít, ahol az időzítés, az útválasztás, a terhelési osztály, a szolgáltatóválasztás és a házirend egyaránt befolyásolja a költségeket. Az OpenRouter's Batch API új módot kínál a fejlesztőknek a különbség kiaknázására, feltéve, hogy rendszereiket úgy tervezték, hogy a késleltetett következtetéseket első osztályú munkafolyamatként kezeljék.