Kihagyás

Token-Budget-Aware LLM Reasoning: Cut Costs in 2026 — Redis Blog (2026-07-28)

Szerző: Jeff Mills, Redis Publikálás dátuma: 2026-07-28 Vendor: Redis blog (redis.io/blog/token-budget-aware-llm-reasoning/) Olvasási idő: 10 perc (a cikk jelzése szerint) Címkék: LLM, token-budget, TALE, semantic caching, complexity routing, agent memory, OpenTelemetry GenAI, Redis Iris, költség-optimalizálás Paywall: public, nincs fizetős tartalom

Forrás: redis.io/blog/token-budget-aware-llm-reasoning/ • Jeff Mills, Redis Blog, 2026-07-28 • Wiki raw

A lényeg

A reasoning modellek (OpenAI o1/o3, Anthropic Claude extended thinking, Google Gemini thinking) drága tokeneket generálnak: az output tokenek ára hatszorosa az input tokenekének, és egy-egy reasoning modell 900 tokent is elkölt egy „2+3=?” kérdésre. A Redis cikke a token-budget-aware reasoning paradigmát mutatja be: mérettesd a token-budgetet a probléma komplexitásához, és ne fizess felesleges reasoning-ért. A cikk három szinten tárgyalja a megoldást: (1) prompt-szintű technikák (TALE, Chain-of-Draft, Concise CoT) akár 67%-os output csökkentést hoznak <3%-os accuracy veszteséggel; (2) architektúra-szintű megoldások (semantic caching, complexity-based routing, agent memory) akár 98%-os költségcsökkentést hoznak a „fizess a reasoning-ért” modellről a „fizesd meg egyszer, cache-eld örökre” modellre való áttéréssel; (3) mérési keretrendszer (OpenTelemetry GenAI semantic conventions, gen_ai.usage.reasoning.output_tokens attribútum, output token ratio, cache hit rate), amellyel a token waste pontosan azonosítható. A Redis saját terméke, a Redis Iris (LangCache + Agent Memory + SemanticRouter) egyetlen platformon egyesíti ezeket a megoldásokat, és a Redis belső benchmarkjai szerint 73%-kal alacsonyabb LLM inference költséget és 15x gyorsabb cache-hit válaszidőt biztosít.

Mi a token-budget-aware reasoning?

A token-budget-aware reasoning alapelve: a modell minden egyes lekéréshez kapjon egy explicit token-budgetet, amely a probléma komplexitásához igazodik. Egy egyszerű lookup-rövid válasz, egy összetett matematikai feladat hosszabb gondolkodási idő. A módszer a TALE (Token-budget-Aware LLM Reasoning) névre hallgat, és a Redis cikke részletesen ismerteti:

"Token-budget-aware reasoning means giving an LLM a token budget sized to each problem's complexity. A simple lookup gets a short answer. A genuinely hard problem gets room to think. Reasoning traces from current LLMs are often unnecessarily long, and you can compress them by baking a reasonable budget into the prompt, an approach called token-budget-aware LLM reasoning (TALE)."

Miért drága a reasoning token?

A reasoning modellek költségproblémája a token-árazásban rejlik. Az output tokenek hatszor drágábbak az input tokeneknél az OpenAI standard-context modelljein, és a Gemini thinking tokenjei is output rate-en vannak árazva. Ez azért probléma, mert a reasoning modellek sokkal több output tokent generálnak, mint a hagyományos modellek, és a költség-túllépés könnyű problémákon koncentrálódik:

"Reasoning models can spend many times more tokens than conventional ones to reach the same answer, and the overspend concentrates on easy problems. On one think-evaluation benchmark, some reasoning models burned over 900 tokens answering '2+3=?'."

Ez a fajta pazarlás a CoT (Chain-of-Thought) prompting inherent tulajdonsága: a modelltől elvárjuk, hogy „mutassa meg a munkáját”, de a mutatott munka nem mindig valódi gondolkodás — gyakran filler, ami tökéletesen elhagyható.

Chain-of-Draft — 5 szavas reasoning lépések

A Chain-of-Draft (CoD) technika a CoT egy radikális tömörítési változata: minden reasoning lépést maximum 5 szóra korlátoz. Ahol az accuracy túléli ezt a szorítást, a szavak nem csináltak érdemi munkát:

"The technique caps each reasoning step at five words or fewer, so wherever accuracy survives the squeeze, the words it removed weren't doing much work."

A CoD a commonsense és symbolic problémákon hatékony, ahol a modell könnyen tömöríthető formában is el tudja végezni a gondolkodást. Összetett matematikai feladatokon kevésbé működik, mert ott a teljes 5 szavas lépés néha nem elegendő.

Prompt-szintű technikák: TALE-EP és Concise CoT

A TALE két fő változata létezik: a fix-budget TALE és a TALE-EP (Estimation + Prompting). Előbbi egyetlen fix értéket ad meg minden lekérésre, utóbbi a modellre bízza a budget meghatározását.

TALE-EP: két fázisú budget estimation

A TALE-EP két fázisban működik:

  1. Estimate: egy zero-shot prompt arra kéri a modellt, hogy becsülje meg a minimum token-számot, amire szüksége van a probléma megoldásához.
  2. Constrain: ez a becslés a reasoning promptba explicit budget-ként kerül beépítésre.

A TALE-EP hét adathalmazon (GPT-4o-mini) mért teljesítménye:

  • 67%-os átlagos output csökkentés <3%-os accuracy drop-pal
  • GSM8K benchmarkon az accuracy 81.35%-ról 84.46%-ra nőtt, miközben az átlagos output 318 tokenről 77-re esett

Ez az eredmény azért figyelemre méltó, mert nem csak költséget takarít meg, de accuracy-t is javít. A magyarázat a „less overthinking” — ugyanaz a hatás, amit a Vanilla CoT GSM8K-Zero tesztje is mutat, ahol a hosszú reasoning éppen hogy rontja az egyszerű problémákon az accuracy-t.

Concise CoT — „just be shorter”

A Concise CoT a legegyszerűbb technika: a standard CoT promptra ráteszünk egy „be concise” utasítást. GPT-3.5 és GPT-4 esetén 49%-os átlagos válaszhossz-csökkentés érhető el, a legtöbb feladaton az accuracy megmarad. De van egy fontos kivétel: matematikai problémákon a GPT-3.5 28%-os performance penalty-t szenved:

"But on math problems, GPT-3.5 took a 28% performance penalty, a reminder that 'just be shorter' isn't free when the task actually needs the reasoning."

A tanulság: a token-budget-aware technikák nem univerzálisak. Ahol a feladat valóban igényli a hosszabb reasoning-et (matematika, logika, többlépéses tervezés), ott a túl szűk budget csökkenti a minőséget.

Miért nem elég a prompting? — A 50 → 10 token paradoxon

A prompt-szintű költségcsökkentés korlátja, hogy a modell gyakran ignorálja a túl szűk budgetet. Egy TALE kiértékelésben:

  • 50-token budget esetén a modell 258 → 86 tokenre csökkentette a kimenetet (sikeres)
  • 10-token budget esetén ugyanaz a modell 157 tokent produkált — közel kétszer annyit, mint az 50-es budget mellett

Ez az „ignore-the-budget” viselkedés különösen a kisebb modelleknél jellemző, míg a nagyobb modellek (GPT-4o, Claude Opus) általában jobban tiszteletben tartják a constraintet:

"When a model can't meet the constraint, it tends to shrug it off and revert to longer reasoning. Smaller models tend to be worse at respecting budgets that larger models handle fine."

Provider API paraméterek — a prompting megbízhatóbb alternatívája

A pontatlanság miatt egyes providerek mostantól API paraméterként teszik elérhetővé a budgetet, nem a prompt szövegére bízzák:

  • Gemini thinking budget paraméter: 0 = kikapcsolja a thinkinget, -1 = a modell maga állítja be a budgetet a kérés komplexitása alapján.
  • Claude: az újabb modellek (Opus 4.7+) nyugdíjazták a manuális thinking budgetet (a budget_tokens paraméter 400-as hibát ad), és helyette egy effort paraméter vezérli a thinking depth-et, valamint egy advisory task budget a teljes agent loop spend-jére.
  • OpenAI: kifejezetten javasolja, hogy a fejlesztők ne használjanak CoT promptokat a reasoning modelljeinél, mert azok belsőleg reasoning-elnek, és a prompt-CoT csak duplikálja a munkát.

A tanulság: a provider-szintű budget kontroll megbízhatóbb, mint a prompt-szintű, és a modern reasoning modellek default viselkedése egyre inkább az, hogy maguk döntik el, mennyit gondolkodnak.

Architektúra-szintű megoldások: caching, routing, memory

A prompt-szintű budget csak az egyes válaszokat zsugorítja. Nem akadályozza meg, hogy ugyanazért a válaszért újra és újra fizessünk. A Redis cikke három architektúra-szintű megoldást mutat be, amelyek együttesen akár 98%-os költségcsökkentést hoznak.

1. Semantic caching — „fizesd meg egyszer, cache-eld örökre”

A semantic caching vektor embeddingekkel és cosine similarity-vel azonosítja a hasonló promptokat. Ha egy új prompt embeddingje átlép egy hasonlósági küszöböt (tipikusan 0.85-0.92), a rendszer a cache-elt választ adja vissza, inference hívás nélkül:

"On a hit, there's no inference call and no reasoning tokens to pay for. In one semantic cache implementation, hit rates ranged from 61.6% to 68.8% across query categories, with positive hit accuracy between 92.5% and 97.3%."

Ez a két szám együtt kritikus: nem elég, hogy a cache sokat talál (61-69% hit rate), az is kell, hogy a talált válasz valóban helyes legyen (92-97% positive accuracy). A Redis saját terméke, a Redis LangCache (a Redis Iris egyik szolgáltatása) egy managed semantic cache, amely a vektor embedding generálást és a cosine similarity keresést is elvégzi. Belső benchmarkjaik szerint:

  • 73%-kal alacsonyabb LLM inference költség
  • 15x gyorsabb válaszidő cache hit esetén

2. Complexity-based routing — a megfelelő modell a megfelelő feladathoz

A complexity-based routing minden lekérést a legolcsóbb modellhez irányít, amely az adott feladatot megbízhatóan megoldja — nem a default legerősebb és legdrágább modellhez. Két fő tervezési minta:

  • Pre-inference router: egyetlen döntést hoz a modell hívása előtt, pusztán a prompt alapján.
  • Cascades: először a cheap modellt próbálja, és csak akkor lépteti a nagyobb modellhez, ha a konfidencia-szint egy küszöb alá esik.

A kutatási eredmények:

  • Pre-inference router preference-adatokkal tanítva: akár 85%-os költségcsökkentés a GPT-4 MT Bench teljesítményének 95%-ának megtartásával.
  • Cascade router: akár 98%-os megtakarítás a legjobb egyedi modell API-költségéből, azonos teljesítménnyel a tesztelt feladatokon.

A Redis saját megoldása a RedisVL SemanticRouter, amely KNN-alapú klasszifikációval irányítja a lekéréseket a megfelelő modellhez.

3. Persistent agent memory — ne deriváld újra

A routing a modell-választást oldja meg, a memory pedig azt akadályozza meg, hogy a modell újra- és újra levezesse ugyanazt a gondolatmenetet. Két konkrét problémát old:

  • Turn-by-turn bloat: a multi-turn agent-ek minden API híváskor újraküldik a teljes conversation history-t, és a token költség közelítőleg kvadratikusan nő a fordulók számával.
  • Session-to-session amnesia: a session-ön kívüli memória nélkül az agent újra-deriválja a korábbi session-ökben levont következtetéseket.

A Reflexion agents egy megoldási minta: a reflection-öket episodic memory bufferben tárolják, és később ezek vezérlik a további trial-okat.

A Redis Agent Memory megoldása két szinten működik:

  • Session memory: az aktuális session scratchpad-je és a friss fordulók.
  • Long-term memory: vektor search a teljes conversation history-n, ahol tények, preferenciák és epizodikus események JSON dokumentumokként, vektor embeddingekkel tárolódnak.

Az eredmény: az agent a memóriából visszakeresi a korábbi kontextust, ahelyett, hogy a reasoning token-ekből újraépítené.

Hogyan mérjük a token-hatékonyságot élesben?

Egyik megoldás sem ér semmit, ha nem látjuk, hol mennek el a tokenek. A OpenTelemetry GenAI semantic conventions (még fejlesztés alatt) szabványos attribútumokat definiál:

  • gen_ai.usage.input_tokens — a prompt tokenjei
  • gen_ai.usage.output_tokens — a válasz tokenjei
  • gen_ai.usage.reasoning.output_tokens — a reasoning tokenek külön, amely megmutatja, ha egy reasoning modell elszalad a költségvetéssel

A két legfontosabb származtatott metrika:

  • Output token ratio (output / total) — emelkedik, ha a prompt vagy a reasoning túl bőbeszédű.
  • Cache hit rate (hits / queries) — a legközvetlenebb mérőszáma annak, hogy mennyi inference-t kerülünk el.

A költségmetrika (cost per request) nincs benne az OpenTelemetry spec-ben, ezt saját magunknak kell trackelni.

A GitHub esettanulmánya jól mutatja a mérés erejét: API proxy instrumentation és egy „Effective Tokens” metrika (amely az output tokeneket a cached read felett árazza) segítségével 62%-kal csökkentették az agent workflow token költségét. A mérhetőség teszi lehetővé, hogy a csapat prompt-változtatásokat, cache viselkedést és routing döntéseket tényleges költéssel mérjen össze, ne találgatással.

Összegzés és a Redis pozicionálása

A cikk konklúziója: a token-budget-aware reasoning három szinten működik:

  1. Prompt-szintű technikák (TALE, Chain-of-Draft, Concise CoT) az egyes válaszokat zsugorítják — érdemes adoptálni, de a provider API paraméterek megbízhatóbbak.
  2. Architektúra-szintű megoldások (semantic caching, complexity routing, agent memory) a teljes alkalmazás költségét csökkentik — ezek hozzák a legnagyobb megtakarítást (akár 98%-os cascade router esetén).
  3. Mérési keretrendszer (OpenTelemetry GenAI) nélkül nem tudjuk, hol megy el a pénz — a gen_ai.usage.reasoning.output_tokens attribútum és az output token ratio a két legfontosabb metrika.

A Redis saját pozicionálása: a Redis Iris egyesíti ezeket a megoldásokat egy real-time context engine-ben, amely négy managed service-ből áll (LangCache a semantic caching-hez, Agent Memory a session és long-term memóriához, SemanticRouter a routing-hoz, és a Redis Search a gyors vektor-kereséshez). Akit a Redis-szel már caching vagy session tárolásra használ, nem kell új infrastruktúrát bevezetnie — ugyanaz a platform szolgálja ki a semantic cache-t és az agent memory-t is.

A cikk legfontosabb üzenete: A reasoning modellek bevezetésével járó költség-ugrás nem elkerülhetetlen — a TALE paradigmával és a semantic caching + routing + memory architektúrával a teljes költség akár 98%-kal is csökkenthető. A kulcs a token-budget probléma komplexitás-arányos méretezése, és nem egy fix budget erőltetése minden feladatra.

Forrás

  • Cikk: redis.io/blog/token-budget-aware-llm-reasoning/ — Jeff Mills, 2026-07-28 (10 perces olvasás)
  • Cikk típusa: Műszaki blog poszt (engineering guide)
  • Kulcsszavak: TALE, Token-budget-aware reasoning, Chain-of-Draft, Chain-of-Thought, Concise CoT, GSM8K, GPT-4o-mini, GPT-3.5, GPT-4, Claude Opus 4.7, Gemini thinking budget, OpenAI reasoning models, semantic caching, cosine similarity, vector embedding, LangCache, complexity-based routing, cascade router, pre-inference router, RedisVL SemanticRouter, Agent Memory, session memory, long-term memory, episodic memory, Reflexion agent, OpenTelemetry GenAI, gen_ai.usage.reasoning.output_tokens, Effective Tokens, Redis Iris, k-nearest neighbor (KNN), MT Bench
  • Kapcsolódó termékek (Redis saját): Redis LangCache (managed semantic caching, public preview), Redis Agent Memory (dual-tier memory architecture), RedisVL SemanticRouter (KNN-alapú routing), Redis Iris (real-time context engine), Redis Search (fast vector retrieval layer)
  • Kutatási hivatkozások a cikkben: TALE (token-budget-aware LLM reasoning), Chain-of-Draft (CoD, 5-word reasoning steps), TALE-EP (Estimation + Prompting, 67% output reduction, <3% accuracy drop on GPT-4o-mini), Concise CoT (49% reduction, 28% math penalty on GPT-3.5), pre-inference router (85% cost reduction, 95% GPT-4 MT Bench performance), cascade router (98% API cost reduction), GitHub 62% Effective Tokens reduction, semantic cache (61.6-68.8% hit rate, 92.5-97.3% positive accuracy)
  • Topic mapping: primary = ai-automation.md (LLM költség-optimalizálás, AI infrastruktúra); a cikk a cost-optimization, inference-cost, caching, agent-memory, observability szálakat erősíti
Vissza a tetejére