A Cloudflare hozzáadta a gyorsítótár olvasási és gyorsítótárba írási token díját az AI Gateway egyéni költségelszámolásához, amely egy kis változásnapló elem, amely jelentős számlázási következményekkel jár azon csapatok számára, amelyek viszonteladók, irányítják vagy egyeztetik a modellhasználatot a szolgáltatók között.
A szeptember 9-i frissítés azt jelenti, hogy a fejlesztők mostantól átadhatják a per_tokenper_cache_write_token értékek a cf-aig-custom-cost fejlécben. Ha bármelyik gyorsítótár-specifikus arány van, a Cloudflare szerint az AI Gateway aktiválja a gyorsítótár-token árazást, és figyelembe veszi a szolgáltatók közötti különbségeket, így ugyanazt a gyorsítótárhasználatot nem számolja kétszer a rendszer.
Ez szűken hangzik. Nem az. A gyorsítótár-árazás az egyesített AI API számlázás egyik legnehezebb részévé vált, különösen mivel a szolgáltatók különböző neveket, mértékegységeket és számlázási szabályokat használnak az újrafelhasznált kontextushoz. Minden gyorsítótárazott token normál beviteli tokenként való kezelése egyszerű lehet, de elég helytelen lehet a viszonteladói árrés törléséhez, vagy félrevezetni az ügyfeleket azzal kapcsolatban, hogy valójában mely munkaterhelések drágák.
Mi változott?
Az AI Gateway már lehetővé tette az egyéni költségadatok csatolását a kérésekhez, így a csapatok a nyilvános szolgáltatók helyett a kialkudott árakat vagy belső árkönyveket ábrázolhatják. Az új változás kiterjeszti ezt a mechanizmust a gyorsítótár-specifikus jogkivonat-kategóriákra.
A gyakorlatban az átjáró-üzemeltető mostantól nemcsak azt tudja megmondani a Cloudflare-nek, hogy egy bemeneti vagy kimeneti token mennyibe kerül, hanem azt is, hogy mennyibe kerül a gyorsítótár olvasása vagy írása. Ez a különbségtétel azért fontos, mert a szolgáltatók egyre inkább árazzák a gyorsítótárazást, mint saját gazdasági réteget. A gyorsítótár írása többe kerülhet, mint a gyorsítótár olvasása. A gyorsítótár olvasása drámaian olcsóbb lehet, mint a friss bevitel. Egyes szolgáltatók eltérő módon teszik közzé a gyorsítótár létrehozását és a gyorsítótár-lekérést a használati rekordokban.
A Cloudflare megjegyzése, hogy kezeli a szolgáltatói különbségeket a kettős számlálás elkerülése érdekében, szintén fontos. A gyorsítótár mezőket nem mindig választják el egyértelműen a bemeneti token összegeitől. Ha egy számlázási rendszer naivan gyorsítótár-tokeneket ad hozzá a szolgáltató által jelentett bemeneti használathoz, az túlterhelheti az ügyfeleket, vagy megnövelheti a belső költségeket. Ha figyelmen kívül hagyja a gyorsítótár mezőket, akkor alulbecsülheti a hosszú környezetű alkalmazások költségeit, amelyek gyakran hoznak létre gyorsítótár-bejegyzéseket.
Miért számít most a gyorsítótár-elszámolás?
Az azonnali gyorsítótárazás korábban optimalizálási részlet volt. Sok termelési munkaterhelésnél ez már az árarchitektúra része.
A hosszú rendszerüzenetek, a visszakereséssel bővített kontextus, a kódolóügynök-tárak, a jogi dokumentumcsomagok és a támogatási tudásbázisok mind profitálnak a kontextus újrafelhasználásából. Minél több kontextust küld egy rendszer, annál nagyobb mértékben változtatja meg a gyorsítótár árazása a valós egységgazdaságot. Két, hasonló tokenszámú kérésnek nagyon eltérő költségei lehetnek, ha az egyik gyorsítótárbejegyzést ír, a másik pedig abból olvas.
Ez a gyorsítótár láthatóságát pénzügyi, nem csak mérnöki problémává teszi. Egy belső ügynököket futtató csapatnak tudnia kell, hogy egy új munkafolyamat költséges-e, mert túl sok friss promptot generál, kihagyja a gyorsítótárat, vagy túl gyakran ír nagy gyorsítótárblokkokat. Előfordulhat, hogy a viszonteladónak meg kell mutatnia az ügyfeleknek, hogy az egyik alkalmazás számlázott használata miért alacsonyabb a vártnál, még akkor is, ha a látszólagos prompt mérete nagy. Előfordulhat, hogy az átjáró szállítójának meg kell őriznie a gyorsítótár mezőit a naplókban, az elemzésekben és a főkönyvi rekordokban, hogy a hónap végi egyeztetés megfeleljen a szolgáltató számláinak.
Ez az a hely is, ahol az az AI API költségelemzése egyre igényesebbé válik. Az összesített igénylési költség már nem elegendő. A csapatoknak külön kell látniuk a bemeneti, kimeneti, gyorsítótárazási és -olvasási viselkedést, majd összekapcsolniuk kell ezeket a kategóriákat API-kulcsokkal, ügyfelekkel, modellekkel és útvonalakkal.
Kit érint?
A közvetlen közönség a Cloudflare AI Gateway felhasználói, akik az alapértelmezett nyilvános árazás helyett egyéni költségekre támaszkodnak. Ebbe beletartoznak a kialkudott modelldíjakkal rendelkező vállalatok, az ügyfelek számára a szolgáltatóhasználatot megjelölő platformok, valamint azok a csapatok, amelyek a Cloudflare-t több modellszolgáltató megosztott vezérlési síkjaként használják.
A viszonteladók különösen ki vannak téve a veszélynek. Ha egy viszonteladó egyszerűsített token-modell használatával számít fel díjat az ügyfeleknek, miközben gyorsítótár-tudatos árazás mellett fizet a szolgáltatóknak, a különbség csendben felhalmozódhat. Előfordulhat, hogy az alulterhelt gyorsítótár-írások vagy a túlterheléses gyorsítótár-olvasások nem jelennek meg egyetlen kérésben, de ez az ügynöki munkamenetek, a kötegelt feldolgozás vagy a nagy volumenű visszakeresési munkaterhelések között is számíthat.
Az OpenAI-kompatibilis átjárórétegeket építő fejlesztőket akkor is érinti, ha nem használják közvetlenül a Cloudflare-t. A változás a piac tágabb irányát tükrözi: a szolgáltatói számlázási felületek egyre szemcsésebbek, miközben az ügyfelek továbbra is tiszta számlát és kiszámítható használati jelentéseket várnak el.Az olyan termékeknek, mint a Model Gate, első osztályú főkönyvi adatokként kell kezelniük a gyorsítótár-token mezőket, ha pontos, ügyfélre kiterjedő jelentéseket, használati korlátokat és árréselemzést szeretnének több szolgáltatón keresztül.
Gyakorlati következmények
Az átjárócsapatoknak át kell tekinteniük, hogy kérésnaplóik, költségkalkulátoraik és számláik hogyan képviselik a gyorsítótári tevékenységet. Ha a gyorsítótár olvasása és írása közönséges prompt tokenekbe kerül, az elemzés egyszerűbbnek tűnhet, mint a mögöttes számla. Ha a szolgáltató használati rekordjai olyan gyorsítótármezőket tartalmaznak, amelyeket a feldolgozás során eldobnak, a későbbi egyeztetés nehéz lesz.
Az árképzési motoroknak irányonként egynél több díjat is támogatniuk kell. A régi input-output felosztás már nem elég a fejlett modellelszámoláshoz. A hiteles modellkönyvnek most helyre van szüksége a friss bemeneti tokenek, a kimeneti tokenek, a gyorsítótár-írások, a gyorsítótár-olvasások és e kategóriák esetleg szolgáltató-specifikus változatai számára.
Az ügyfelek felé néző irányítópultok gondosan feltárják ezeket a különbségeket. A legtöbb felhasználó nem akarja olvasni a nyers szolgáltatói telemetriát, de meg kell értenie, hogy miért változnak a költségek, amikor egy alkalmazás hatékonyabban kezdi újra felhasználni a környezetet. A legjobb felület egy költségbontás lehet, amely megmutatja a gyorsítótár-megtakarítást és a gyorsítótár létrehozásának költségeit anélkül, hogy az ügyfeleket arra kényszerítené, hogy megtanulják az összes szolgáltató terminológiáját.
Működési következményei is vannak a figyelmeztetéseknek és a korlátozásoknak. Előfordulhat, hogy a csak az összes tokenen alapuló ügyfél-költségkeret-korlát nem képes elkapni a költséges gyorsítótárbejegyzéseket író munkaterhelést. A kizárólag a kérelmek számán alapuló árrés-figyelmeztetésből hiányozhat a szolgáltatói árképzési eltérés. Azon csapatok esetében, amelyek ügyfélenkénti kulcsokon keresztül értékesítenek hozzáférést, a gyorsítótár-tudatos elszámolást ugyanahhoz az ügyfél-, projekt- vagy alkalmazásazonosítóhoz kell kötni, amelyet a költésszabályozáshoz használnak.
Ami nyitva marad
A változásnapló támogatja az egyéni gyorsítótár-olvasási és gyorsítótárazási díjakat, de nem oldja meg a kapu minden megvalósítási kérdését. A csapatoknak továbbra is tesztelniük kell, hogy konkrét szolgáltatóik hogyan jelentik a gyorsítótár-használatot, hogyan jelennek meg a Cloudflare számított költségei a naplókban és az exportálásokban, és hogyan kell összehasonlítani a meglévő számlákat az új egyéni költségmezőkkel.
A nagyobb irány azonban egyértelmű. Az AI-átjáró számlázása az egyszerű token-mérőről a részletes használati főkönyv felé halad. A gyorsítótár árazása most ennek a főkönyvnek a része. A részleteket megőrző csapatok tisztább egyeztetést és jobb ügyfélelemzést biztosítanak. Azok a csapatok, amelyek összecsukják, előfordulhat, hogy addig nem veszik észre a problémát, amíg a szolgáltatói számlájuk és az ügyfélszámlájuk nem meséli el ugyanazt a történetet.