# 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/](https://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/](https://redis.io/blog/token-budget-aware-llm-reasoning/) • Jeff Mills, Redis Blog, 2026-07-28 • [Wiki raw](../tanulmanyok/2026-07-28_redis_token_budget_aware_llm_reasoning.md) --- ## 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/](https://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