Nyereség:
- Magyarázza el a token fogalmát, a bemeneti/kimeneti token megkülönböztetést és a tokenizációt!
- A tokenek számából és az egységárból ki tudja számítani egy kérés költségét és a havi munkaterhelést
- Összehasonlítja a modellválasztás és az azonnali hossz hatását a költségekre
Nem építhet nagyszabású megoldást az LLM API-k gazdaságosságának ismerete nélkül. Egy demó egyszer lefut; A lényeg az, hogy megjósolható legyen a számla, ha havonta több ezer hívás érkezik. Ebben az egységben felállítjuk a dolgok pénzes oldalát: mi az a token, miért különbözik az input és output ára, hogyan számítsuk ki egy kérés költségét, és hogyan tervezzük meg a havi munkaterhet. Ez az információ lehetővé teszi az optimalizálási technikák (gyorsítótár, modellválasztás, köteg) megtérülésének mérését a következő egységekben.
Mi az a Token?
A token a legkisebb egység, amelyben a modell szöveget dolgoz fel. Egy szó nem mindig jelző; token általában egy szó része. Nagyjából, angolul 1 token ≈ 4 karakter ≈ 0,75 szó. A törökben és a kódban az arány változó: a török szavakat utótagos szerkezete és ábécéje miatt gyakran több tokenre osztják, mint az angolban. Ezért a tokenek számát a szolgáltató tokenszámláló eszközével kell mérni, nem pedig szemből való találgatást.
A tokenizálás (a szöveg tokenekre bontásának folyamata) modellenként eltérő lehet. Ennek két gyakorlati következménye van: (1) Ugyanaz a szöveg különböző modellekben eltérő számú tokent eredményezhet; (2) A más szolgáltatók tokenizátoraival (pl. az OpenAI tiktoken könyvtára) készített előrejelzések pontatlanok lesznek Claude esetében – használja a használt modellhez tartozó tokenszámláló tippet.
Tipp: "Körülbelül hány token?" Ne válaszolj vakon a kérdésre. Adjon át egy reprezentatív szöveget a tokenszámláló API-n keresztül; A költségvetési döntéseket a mérésre alapozza.
Bemeneti és kimeneti tokenek
A számla két tételből áll:
- Beviteli tokenek: Bármi, amit a modellnek küld – rendszerparancs, korábbi körutazások, felhasználói üzenet, dokumentáció, ha van ilyen. Ezeket egyszerre dolgozzák fel.
- Kimeneti tokenek: A modell által generált válasz. A modell minden kimeneti token esetében lépésről lépésre elvégzi a számítást.
A legtöbb szolgáltatónál a kimenet többszöröse drágább, mint a bemenet. Az ok egyszerű: a bemeneti adatok egyszerre történő kiolvasása olcsóbb, mint a kimeneti tokenenkénti előállítása. Ennek az aszimmetriának az ismerete megmagyarázza, hogy miért olyan hatékonyak az olyan optimalizálások, mint a „tömör válaszokat igényel”.
Mintaárak (1 millió tokenenként, USD)
Az alábbi táblázat referencia; Az árak idővel változhatnak, kérjük, ellenőrizze saját szolgáltatója aktuális listáját.
modell osztály
minta modell
Bemenet ($/1M)
Kimenet ($/1M)
Tipikus használat
gyors/olcsó
Haiku 4.5
1.00
5.00
Osztályozás, címkézés, egyszerű összefoglaló
kiegyensúlyozott
szonett 5
3.00
15.00
Általános célú, kódolás, ügynöki munka
erős
Opus 4.8
5.00
25.00
Összetett érvelés, hosszú távú feladatok
Minden osztályban a kimenet a bemenet 5-szöröse; Sőt, még az erős modell bemenete is ötszöröse az olcsó modell bemenetének. Ez a két tengely (input↔output és modellosztály) alkotja a költségdöntések keretét.
Hogyan számítsuk ki a költséget?
A képlet egyszerű:
költség = (bemeneti_token / 1 000 000) × bemeneti_ár + (kimeneti_token / 1 000 000) × kimeneti_ár
Mintaszámla. Egy kérés a Sonnet 5-tel: 1500 bemeneti token, 400 kimeneti token.
bemenet = 1 500 / 1 000 000 × 3,00 = 0,0045 USD kimenet = 400 / 1 000 000 × 15,00 = 0,0060 USD összesen = 0,0105 USD (körülbelül 1 cent)
Egy hívás olcsónak tűnik. De szorozd meg a hangerővel: napi 20 000 hívás → napi 210 dollár, havonta ~6 300 dollár. Itt jön képbe a skála.
Havi költségvetési sablon
A munkaterhelés havi költségének kivonásához használja ezt a sablont:
1) Átlagos bemeneti token kérésenként: ......2) Átlagos kimeneti token kérésenként: ......3) Kérelmek száma naponta: ......4) Havi munkanapok száma: ......5) Kérelemenkénti költség = (1)/1M×bemeneti_ár + (2)/1M×kimeneti_ár6) Havi költség = (5) × (3) × (4)
Ha ezt a mintát egy táblázatba tölti, és megnézi, hogyan alakul az összeg a modell megváltoztatásakor, az megtestesíti a modellválasztás (5. egység) és a gyorsítótár (6. egység) döntéseit.
A prompt lerövidítése másolható sablonokkal
A költségek nagy része a szükségtelenül hosszú felszólításokból és az elpazarolt kimenetekből származik. Az alábbi sablonok közvetlen megtakarítást biztosítanak.
# Korlátozza a kimeneti hosszt. Maximum 3 elemmel válaszoljon. Adjon hozzá egy indoklást vagy bevezető mondatot.
# Csak a kért mezőt adja vissza Csak a következő JSON-t adja vissza, ne adjon hozzá semmilyen más szöveget:{"category": "...", "urgency": "low|medium|high"}
# A szükségtelen környezet eltávolítása Csak a dátumot és az összeget távolítsa el a következő szövegből. Ne ismételje meg a teljes szöveget.Szöveg: """{{text}}"""
# A hosszú beszéd összefoglalása (bevitel mentése) Foglalja össze ezt a beszédet 5 tételben. A következő körökben ezt az összefoglalót használom a teljes múlt helyett. Beszéd: """{{múlt}}"""
Gyenge felszólítás / Erős felszólítás (a költség szempontjából)
# GYENGE (kimenetet bocsát ki, drága) Elemezze ezt a támogatási kérelmet, és írjon nekem egy átfogó értékelést.
# ERŐS (korlátozza a kimenetet, olcsó és kiszámítható) Osztályozza ezt a támogatási kérelmet. Csak adja vissza a következő JSON-t:{"kategória":"számla|műszaki|visszatérítés|egyéb","sürgősségi":"alacsony|közepes|magas"}Ne írjon leírást.
A gyenge verzió talán 500 kimeneti tokent állít elő; erős verzió ~15. Mivel a kimenet drága, ez jelentős különbség hívásonként, és megsokszorozódik a hangerővel.
Három mini tok
1. eset – A hosszú prompt rejtett költsége. Mivel egy könyvelési automatizálás minden számlát rendezett, minden kéréshez egy 40 oldalas „szabálykönyvet” adott hozzá: kérésenként ~12 000 beviteli token. Sonnet 5-tel 12 000/1M×3 = 0,036 dollár, amit most beírt. 5000 számla naponta → 180 dollár naponta. A szabálykönyv gyorsítótárazásával (6. egység) a beviteli költség ~90%-kal csökkent.
2. eset – A modell leépítésének megtérülése. Az egyik csapat egyszerű „pozitív/negatív” hangulatcímkézést végzett az Opus 4.8-mal: 300 bemenet + 10 kimeneti token. Az Opus ára 300/1M×5 + 10/1M×25 = 0,00175 USD. Haikura váltva, 300/1M×1 + 10/1M×5 = 0,00035 dollár – 5x olcsóbb, a pontosságbeli különbség mérhetetlen volt. Havi 3 millió hívás esetén a különbség 5250 → 1050 dollár.
3. eset – A kimenet elengedése. Amikor egy marketingcsapat készített egy termékleírást, nem szab határt a kibocsátásra; a modell néha 1500 tokent mondott. Amikor hozzáadtam a "maximum 60 szó" utasítást, az átlagos kimenet 900-ról 90 tokenre csökkent. Mivel a nyomtatás drága volt, a havi számla harmadával csökkent, a szövegek pedig hasznosabbak lettek.
Gyakori hibák
- Szemből kitalálni a zsetont: Főleg törökben és kódban lehet tévedni. Intézkedés.
- Feltételezve, hogy a bemenet és a kimenet azonos: A kimenet általában sokkal drágább; Az optimalizálás nagy része a kimenet lerövidítéséből származik.
- Ne tévesszen meg egyetlen hívás olcsósága sem: A döntést a mennyiség határozza meg. 0,01 × millió dollár = 10 000 dollár.
- Előrejelzés egy másik szolgáltató tokenizátorával: Helytelen eredményeket ad; Használja a modell tokenszámláló eszközét.
- A beszélgetés előzményeinek korlátlan bővítése: Minden kör hozzáadódik a bejegyzéshez; hosszú beszélgetésekben összefoglalni.
- A `max_tokens` szükségtelenül magasan tartása: Elrejti a költségvetési tervet és a levágás kockázatát; Adjon reális értéket.
Mélyebb: Kontextus ablak és hosszú beviteli költség
Nagyon fontos, hogy lássuk, hogyan halmozódik fel az ár „a beszélgetés során”, és nem csak „kérésenként”. A modell által feldolgozható szöveg teljes mennyiségét környezeti ablaknak nevezzük; A bemenet és a kimenet összegének bele kell férnie ebbe az ablakba. A modern modellek nagyon nagy ablakokat kínálnak (több százezer, sőt millió token), de ez nem jelenti azt, hogy „végtelenül megtöltheti” – bármit is teszünk az ablakba, az bemenetként kerül számlázásra.
A hosszú beszélgetések csapdája a következő: minden új körrel újra elküldöd a teljes történelmet (hontalanság az 1. egységben). Egy 20 fordulós beszélgetésnél a 20. kérés a teljes első 19 kört tartalmazza bemenetként. Így, ahogy a beszélgetés hosszabbodik, a kérésenkénti költség halmozottan, nem pedig lineárisan növekszik. Egy ügynökasszisztenssel folytatott 50 körös beszélgetés több tucatszoros beviteli költséget eredményezhet az első körben.
Kétféleképpen lehet ezt kezelni. Az első az összefoglaló: a régebbi körök egyetlen összefoglaló blokkba tömörítése, csak az utolsó néhány kört hagyva nyersen. A második a gyorsítótárazás (6. egység): a rögzített kontextus beolvasása az ár tizedéért, ahelyett, hogy ismételten teljes áron feldolgozná. Ezek együttesen jelentősen csökkentik a hosszú, kontextusigényes munkaterhelések számláját. Tehát a token-gazdaságtan az egész munkamenet tervezéséről szól, nem egyetlen kérésről.
Összefoglalva
A token a legkisebb egység, amelyben a szöveget feldolgozzák; Az input és a kibocsátás külön árazódik, és a kibocsátás gyakran sokkal drágább. A költség a tokenek számának szorzata az egységárral, és a valódi döntés a mennyiség alapján történik. A prompt lerövidítése, a teljesítmény korlátozása és a feladatot teljesítő legkönnyebb modell kiválasztása a legközvetlenebb karok, amelyek sokszorosára csökkentik a költségeket.
Pályázati feladat
Válasszon egy saját feladatot. (1) Határozza meg a bemeneti és becsült kimeneti tokenek számát egy reprezentatív prompthoz (lehetőség szerint tokenszámláló eszközzel mérje meg). (2) Számítsa ki a kérésenkénti költséget a három modellosztályra. (3) Becsülje meg a kérelmek napi számát, és számítsa ki a három modell havi költségvetését. (4) Adjon hozzá egy utasítást a kimenet lerövidítésére, és jegyezze fel a várható megtakarításokat.
ellenőrző lista
- [ ] Meg tudom magyarázni a tokenek fogalmát, és azt, hogy a tokenizáció a modelltől függően változik.
- [ ] Tudom, hogy a bemeneti és kimeneti tokenek ára miért eltérő.
- [ ] A képlettel ki tudom számítani egy kérés költségét.
- [ ] Havi költségkeretet tudok létrehozni egy munkaterheléshez sablon segítségével.
- [ ] Egy példával be tudom mutatni a kimenet rövidítésének és a modellcsökkentésnek az előnyeit.