Reasoning budget v LLM modelech: jak nastavit čas na přemýšlení, aby AI nebyla zbytečně pomalá

Nové reasoning modely jako Claude Opus 5 nebo OpenAI o1 umí přemýšlet déle, než odpovědí. Problém není v tom, že by to neuměly dobře — ale že výchozí nastavení dává stejně dlouhý čas na zodpovězení triviální otázky i na složitou analýzu kódu. Model se nezdržuje schválně. Prostě dostal instrukci přemýšlet stejně dlouho u všeho. A protože thinking tokens stojí peníze a latence roste, začíná být důležité rozlišovat, kdy má AI myslet na plný výkon a kdy má jen rychle odpovědět.

Jak funguje reasoning budget a proč není rozumné nastavit ho jednou pro všechno

Reasoning budget určuje, kolik času model stráví interním přemýšlením, než vrátí výsledek. OpenAI i Anthropic ho nazývají různě — thinking tokens, effort ladder, reasoning steps — ale princip je stejný: model může strávit více výpočetního času prohledáváním možností, kontrolou svých odpovědí a opravou chyb.

Claude Opus 5 má thinking zapnutý standardně. OpenAI nabízí režimy low, medium, high. Anthropic popisuje effort ladder s několika stupni od minimálního po full reasoning. Všechny tyto přístupy sdílejí jeden problém: výchozí hodnota je často nastavená konzervativně vysoko, aby model nevypadal hloupě na složitých otázkách. Jenže developer obvykle neposílá do API jen složité otázky.

Když se model zeptáte na aktuální čas v databázi, nepotřebujete půl minuty přemýšlení. Když řešíte edge case v produkčním kódu, kde může selhat race condition, chcete, aby model skutečně promyslel všechny scénáře. Rozdíl je v tom, že většina vývojářských nástrojů dnes reasoning budget nenastavuje dynamicky podle typu úkolu.

Praktický rozdíl mezi rychlým lookup a skutečným debugováním

Jednoduchý test: zkuste poslat do reasoning modelu dotaz „jaký je hlavní město Francie“ s plným reasoning budgetem. Model stráví desítky thinking tokens tím, že si ověřuje, zda Paříž je stále správná odpověď, prochází varianty, kontroluje si nejistotu. Odpověď dostanete správně, ale o 15 vteřin později než kdybyste použili nulový nebo minimální budget.

Teď zkuste najít chybu v rekurzivní funkci, kde se může stát deadlock při konkrétní kombinaci vstupů. S nízkým budgetem model odpoví rychle, ale často nepřesně nebo povrchně. S vysokým budgetem projde možné stavy, zkontroluje podmínky, porovná s běžnými vzory. Latence stoupne na 40 vteřin, ale odpověď je použitelná.

Problém není akademický. Vývojář, který integruje reasoning model do IDE, chatbota nebo CI pipeline, obvykle nenastavuje různé budgety pro různé typy dotazů. Výsledek je buď pomalý nástroj na všechno, nebo rychlý nástroj, co selhává na složitých otázkách. Oba scénáře vedou k tomu, že lidi model přestanou používat.

Jak Anthropic a OpenAI řeší volbu reasoning režimu

Anthropic v dokumentaci ke Claude Opus 5 popisuje thinking jako výchozí chování. Model sám rozhoduje, jak dlouho bude přemýšlet, ale developer může nastavit maximální limit thinking tokens. To je užitečné pro cost control, ale neřeší problém neefektivního přemýšlení u jednoduchých dotazů.

OpenAI nabízí tři pevné režimy: low, medium, high. Low je pro jednoduché úkoly, high pro analytické nebo rizikové. Developer musí v kódu explicitně specifikovat, který režim chce. Problém je, že většina aplikací posílá do API směs dotazů — a bez logiky, která by je třídila, buď použijete high všude (drahé, pomalé), nebo low všude (rychlé, ale nespolehlivé na složitosti).

Žádný z obou providerů zatím nenabízí automatickou detekci složitosti. To znamená, že odpovědnost za správné nastavení je plně na vývojáři. A protože většina lidí nechce psát routing logiku pro každý typ dotazu, výchozí režim se často stane jediným použitým režimem.

Kde reasoning budget hraje roli ve víceagentních systémech a dlouhých kontextech

Claude Opus 5 podporuje dlouhé kontexty a agentní práci. To znamená, že model může procházet velké dokumenty, volat nástroje a skládat složité odpovědi. V takovém scénáři je reasoning budget ještě důležitější, protože každý krok agenta může vyžadovat jiný stupeň přemýšlení.

Například: agent, co prochází dokumentaci a hledá relevantní sekce, nepotřebuje vysoký reasoning budget. Je to filtrování, ne analýza. Ale když agent najde konfliktní informace ve dvou dokumentech a má rozhodnout, která verze je správná, rozumné je zvýšit reasoning úroveň.

Problém je, že většina agentních frameworků dnes reasoning budget nenastavuje dynamicky podle typu kroku. Výsledek je stejný jako u jednoduchého API volání: buď všechno pomalu, nebo všechno rychle a nespolehlivě. OpenAI i Anthropic ve svých dokumentacích popisují možnost nastavení, ale nenabízejí hotový pattern pro automatické rozhodování.

Proč stávající přístupy vedou k tomu, že reasoning modely končí nepoužité

Reasoning modely jsou užitečné. Ale pokud developer integruje model s thinking zapnutým na maximum a všechny odpovědi trvají 30 vteřin, nástroj přestane být praktický. Naopak když je thinking vypnutý nebo na minimu, model se chová jako starší generace — a pak není důvod platit za reasoning schopnosti.

Chybí middleware nebo helper knihovna, která by dotazy automaticky třídila podle složitosti a nastavovala budget podle typu. Některé týmy si píší vlastní heuristiky — například podle délky dotazu nebo přítomnosti klíčových slov jako „debug“, „analyze“, „compare“. To funguje lépe než fixed budget, ale není to robustní řešení.

Dokud provideři nenabídnou built-in routing nebo aspoň doporučené vzory pro dynamické nastavení, bude reasoning budget zůstávat problémem, který většina vývojářů řeší špatně nebo vůbec. A to znamená, že reasoning modely budou používané méně, než by mohly být — ne kvůli tomu, že by neuměly přemýšlet, ale kvůli tomu, že přemýšlejí i tam, kde to nikdo nečeká ani nepotřebuje.