Kolik stojí jedno „ano“
- Generování
- 13,1 tok/s
- I triviální odpověď
- ~20 s
- Tokenů na „ano“
- 257
- Prefill 22,5k
- ~200 s
Teze: Lokální 27B model na Macu odpoví „ano“ za dvacet sekund a na běžný dotaz potřebuje dvě až tři minuty. Není to tím, že by byl pomalý — je to tím, kde je hrdlo.
Naměřeno (M4 Pro, 64 GB, LM Studio)
| Veličina | Hodnota | Co z toho plyne |
|---|---|---|
| Generování 27B (Q4, 17,7 GB) | 13,1 tok/s | strop propustnosti paměti, ne výpočtu |
| Tokenů na triviální dotaz | 257 (s reasoningem) | i „ano“ stojí ~20 s |
| Tokenů v agentní smyčce | 2 000+ | odtud ty 2–3 minuty |
| Prefill 22,5k tokenů | 237 s | viz křivka níž |
ref-search (BM25/FTS5) |
0,05 s | zdarma, používat agresivně |
hindsight_recall |
~45 s | 99,6 % z toho cross-encoder na 2 vCPU |
| gemma-4-31b (Q4, 19,9 GB) | 11,3 tok/s | o 18 % pomalejší na token |
Prefill: kolik stojí, než model napíše první znak
Změřeno 2. 8. 2026, každý dotaz s jedinečným náhodným textem a max_tokens=1,
takže naměřený čas je téměř celý zpracování vstupu.
| tokenů na vstupu | čas | tok/s |
|---|---|---|
| 9 251 | 96 s | 96 |
| 18 209 | 173 s | 106 |
| 29 092 | 287 s | 101 |
| 43 841 | 506 s | 87 |
| 58 572 | 729 s | 80 |
Zhruba 13 sekund na tisíc tokenů — a průchodnost s délkou klesá z 96 na 80 tok/s, protože pozornost roste rychleji než lineárně.
Prakticky: dnešní základní prompt agenta má 16 500 tokenů, takže než model napíše první znak, uplyne skoro tři minuty. Plné okno 65 536 tokenů by stálo přes třináct minut.
To zpětně vysvětluje jedno noční selhání do posledního čísla. Úloha měla kontext 46 817 tokenů, tedy 554 s prefillu, a k tomu 5 128 tokenů přemýšlení při 13 tok/s, tedy 394 s — dohromady 948 sekund v jednom volání. Hlídač měl limit 600.
Dvě pasti, na které jsem při tom měření naletěl
KV cache dělá z měření prefillu nesmysl. První pokus stavěl prompty z jedné opakované věty, takže delší dotaz recykloval cache kratšího. Vyšlo z toho, že 31 313 tokenů se zpracuje za 6,2 s — pětkrát rychleji než 6 533 tokenů. Poznávací znamení je nemonotónnost: prefill nemůže s délkou klesat.
Braní minima z opakování je jednou obrana a podruhé chyba. Když prompty sdílejí prefix, minimum vybírá cache hit. Když je každý dotaz jedinečný, zbývá jako šum jen čekání ve frontě — a to čas pouze přidává, takže minimum je správně. Táž technika, opačný účinek, podle toho, co je zdroj rozptylu.
Kontrola byla součástí měření: týž rozměr s jiným textem dal 301 s (97 tok/s), tedy shodně se studeným během. Týž text dvakrát za sebou dal 298 s a pak 6,8 s.
Tři závěry, které jsem si musel vzít zpátky
Tohle je jádro článku — všechna tři doporučení vyslovil Claude Code a pak je vlastním měřením vyvrátil.
- „Přesuneme Hermese na Mac, bude to rychlejší.“ Ne — inference tam už běží. Přesunula by se jen orchestrace, což je zlomek času, a ztratila by se izolace kontejneru.
- „Dáme vyšší kvantizaci, Q8.“ Ne — zdvojnásobila by odezvu. Hrdlo je propustnost paměti, takže větší soubor = méně tokenů za sekundu, lineárně.
- „Přesuneme embeddingy na Mac.“ Nesmysl — trvají 0,07 s.
Poznámka k publikaci
Údaj „profil od té doby narostl“, který tu dřív stál jako důvod k přeměření, byl mylný — základní prompt má dnes 16 500 tokenů, tedy méně než oněch 22,5k. Polovinu z něj přitom netvoří profil ani skilly, ale definice nástrojů a paměťový kontext.