Mennyibe kerülnek valójában az LLM tokenek, és hogyan kell kevesebbért fizetni

Minden API-számla egy nyelvi modellhez egy tokenek számlája, és szinte senkinek nincs megérzése, hogy egy adott szöveg hány tokenből áll. Az eredmény ugyanaz a meglepetés havonta kétszer: a tesztelés során olcsónak tűnő szolgáltatás negyvenszer többe kerül a termelésben, vagy egy kontextusablak, amelynek „illene illeszkednie”, elutasítja a kérést. Mindkettő számtani feladat, és a számtant egyszer érdemes megtanulni.

A token nem szó

A modellek nem olvasnak karaktereket vagy szavakat. Tokeneket olvasnak – egy bájtpáros kódoló által előállított darabokat, amelyek a képzés során megtanulták, hogy mely sorozatok elég gyakran előfordulnak ahhoz, hogy megérdemeljék saját szimbólumukat. A gyakori angol szavak egy jelző. A ritkák szétválnak. Így token egy és tokenization három, míg egy véletlenszerű karakterlánc tetszik x7Qp2 ötbe kerülhet.

A hüvelykujjszabályokat érdemes betartani:

• angol próza: nagyjából négy karakter tokenenként, vagyis körülbelül 0,75 token szónként. Egy ezer szavas cikk körülbelül 1300 token.
• Kód: lényegesen rosszabb. A behúzás, az írásjelek és a camelCase azonosítók mind töredékek. Költségvetése a három karakterhez közelíthető tokenenként, és a minimált kódot a saját katasztrófájaként kezelheti – pont azért tokenizál rosszul, mert szokatlan.
• Nem latin betűk: megint sokkal rosszabb. A kínai, a japán és a koreai általában egy vagy két karakterenként közel egy tokenhez jutnak, így ugyanaz a tartalom japánul többszöröse is kerülhet, mint az angol verzió. A cirill és a görög ül közöttük.
• JSON: az írásjelek valódi pénz. Minden idézőjel, kapcsos zárójel, kettőspont és vessző legalább egy token része, és a mélyen beágyazott, hosszú kulcsnevekkel rendelkező szerkezetek többet költhetnek szintaxisra, mint értékekre.

A hüvelykujjszabályok a becslést szolgálják. Amikor számít, számolj: a LLM token és költségkalkulátor tokenizálja, amit beilleszt, és kinyomtatja a számlálást, és a szöveget is megjelenítheti a megjelölt tokenhatárokkal, ami a leggyorsabb módja annak, hogy megértse, miért váratlanul drága valamelyik prompt. Ha látja, hogy saját azonosítói nevei négy darabra törnek, az sok mindent megmagyaráz.

A kimenet többszöröse többe kerül, mint az input

Az árazási részleteket az emberek hiányolják: a szolgáltatók külön díjat számítanak fel az Ön által elküldött tokenekért és a modell által generált tokenekért, és a kimenet általában négy-nyolcszorosa a beviteli aránynak. A 10 000 kontextusjelzőt és 200 token választ tartalmazó promptot a bemenet uralja. Az 500 jelzőt tartalmazó utasítást, amely egy 4000 jelű esszét készít, a kimenet uralja – erősen –.

Ez sok optimalizálási ösztönt megfordít. A rendszerkérdés 900-ról 600-ra történő levágása nagyon keveset takarít meg, ha a modell minden hívásra hosszú választ ír. Ha azt mondjuk a modellnek, hogy három bekezdés helyett három mondatban válaszoljon, sokat spórolunk. Mielőtt a rossz oldalt optimalizálná, kérdezze meg, hogy a tranzakció melyik oldalán él ténylegesen a munkateher.

A számológép ugyanazt a szöveget árazza a táblázatában szereplő összes modellhez mind a bemeneti, mind a kimeneti arányban, így összehasonlíthatja az olcsó modellt, amely a teljes munkát elvégzi egy drága modellel, amely egy részét végzi el. A referenciaárakat helyben tároljuk, és rendszeres időközönként összevetjük a szolgáltatói oldalakkal – tekintse őket tervezési segédletként, és erősítse meg a szolgáltató saját árképzési oldalán, mielőtt elkötelezi magát a költségvetés mellett, mert az árak változnak.

A chat négyzet alakú, és itt halnak meg a költségvetések

Egy egyszeri API-hívás annyiba kerül, amennyibe kerül. Egy beszélgetés minden körben újraküldi a teljes előzményt, így egy húszfordulós csevegés nem kerül hússzor egy körbe – nagyjából egy növekvő sorozat összegébe kerül. A húsz forduló ismét fizet az elsőtől a tizenkilencedikig.

Két következmény. Először is, a hosszú távú ügynökhurkok az LLM-használat legdrágább formája, és a legvalószínűbb, hogy mérés nélkül prototípust készítenek. Másodszor, az azonnali gyorsítótárazás többet jelent, mint bármilyen szövegmódosítás: a szolgáltatók leengedik azokat a tokeneket, amelyek egy már látott előtagot ismételnek, ami azt jelenti, hogy a stabil tartalmat – a rendszerpromptot, a sémát, a példákat – a legelejére, a változó részét pedig a végére helyezik. Rendelje újra ugyanazt a promptot, hogy a változó időbélyeg felül legyen, és minden hívásnál érvénytelenítette a gyorsítótárat, miközben semmi mást nem változtatott.

A felszólítás kicsinyítése, mielőtt elküldi

A legtöbb túlméretezett prompt unalmas okokból túlméretezett: valaki egy egész fájlt beillesztett, amikor három függvény volt releváns, és a fájl fél megjegyzések és üres sorok. A LLM kontextustömörítő pontosan ezt célozza meg – megfosztja a kód megjegyzéseit, összecsukja az üres sorokat, a kihagyásokat, és eltávolítja a töltelékszavakat a prózából, majd jelenti, hogy a trimmelés hány tokent mentett el. Valódi forrásfájlon, amely rutinszerűen 20–40%-ban fut anélkül, hogy bármihez hozzányúlna, amire a modellnek szüksége van.

A kézi vágások, amelyeket érdemes előtte elvégezni:

1. Küldj kivonatokat, ne fájlokat. A modellfigyelem sem ingyenes; az irreleváns kontextus mérhetően lerontja a válaszokat, valamint pénzbe kerül.
2. Csupaszítsa a naplókat a hibás régióba. A sikeres indítási kimenet tízezer sora nem járul hozzá a diagnózishoz.
3. Dobd le az ismételt kazánlemezt. Licencfejlécek, generált importok, ugyanaz a felelősség kizárása minden rekordon.
4. Újraküldés helyett összegezzen. Egy hosszú beszélgetés során az egytől a tizenötödikig terjedő körök állapotfeljegyzéssel történő helyettesítése jelenti a legnagyobb megtakarítást.

Amikor a bemenet valóban nem illik

A kontextusablakok ma már nagyok, de a "nagy" még mindig véges, és egy könyv, egy évnyi napló vagy egy teljes átirat meghaladja az egyet. A felosztás a szokásos válasz, és a felosztás az számít: a mondat közepének vagy a funkcióközépnek a felvágása olyan darabokat eredményez, amelyeket a modellnek ki kell találnia. A prompt elosztó a szöveget az Ön által választott méretű darabokra osztja, miközben tiszteletben tartja a határokat, és számozza a részeket, így sorban betáplálhatja őket egy következetes utasítással.

Megjegyzés az egységekhez: a tokenek nem bájtok. A UTF-8 bájt számláló egy másik kérdésre ad választ – mennyi helyet foglal el a szöveg a vezetéken vagy az adatbázis oszlopában –, és a két szám élesen eltér a nem latin nyelvű szövegeknél, ahol a karakterenkénti bájtok emelkednek, miközben a tokenenkénti karakterek száma csökken. Használjon bájtokat a tárolási korlátokhoz és tokeneket a modellkorlátokhoz, és soha ne cserélje le egyiket a másikkal.

Működő példa

Tegyük fel, hogy húsz kérdésre válaszol egy harminc oldalas dokumentumhoz képest. A harminc oldal körülbelül 15 000 szót jelent, tehát nagyjából 20 000 token. Naiv módon minden kérdéssel elküldöd a dokumentumot: 20 × 20 000 = 400 000 bemeneti token, plusz talán 20 × 300 kimeneti token.

Tegye az első helyre a dokumentumot, és tartsa bájtonosan a hívások során, és a legtöbb szolgáltató a gyorsítótárból szolgálja ki az ismétlődő előtagot a sebesség töredékével. Először vágja le a kazánlemez dokumentumát, és az alap is zsugorodik. Hívásonként öt kérdést töltsön fel egy helyett, és húsz helyett négyszer küldje el a dokumentumot. Ugyanaz a feladat, ugyanaz a modell, és egy nagyságrend az óvatlan és a gondos változat között – ez a lényeg, hogy számolj, mielőtt elküldöd.

A számláló és a kompresszor is teljes egészében az Ön böngészőjében fut: az Ön által árazott prompt nincs feltöltve sehova, hogy mérni lehessen.