Pokud jste někde zaslechli výraz „tokenová ekonomika“ nebo „token economy“ a pohybujete se v oblasti velkých jazykových modelů (LLM), pak hovoříme o hospodaření s jednotkami textu, nad kterými model pracuje ^[1]. Token není slovo v běžném slova smyslu. Jde o menší segment informace (nejčastěji textu), který může odpovídat celému slovu, jeho části, interpunkčnímu znaménku nebo dokonce skupině bajtů ^[2]. Model totiž počítá, ukládá i trénuje nad tokeny, nikoli nad větami či odstavci.

Každý token představuje trojnásobný náklad. Výpočetní náklad spočívá v tom, že více tokenů znamená více operací při tréninku i při inferenci. Finanční náklad plyne z toho, že infrastruktura se dimenzuje a účtuje podle objemu zpracovaných tokenů ^[3]. A kapacitní náklad znamená, že model má omezené kontextové okno, takže každá nadbytečná část textu zabírá místo, které by mohlo nést užitečnou informaci.

Tento článek se zaměřuje na konkrétní důsledek této ekonomiky: jak formát podkladových dat, z nichž se buduje trénovací korpus, ovlivňuje počet tokenů, a tím i cenu, kvalitu a rozsah toho, co se model naučí.

Jak tokenizér vidí text

Úvodem se třeba alespoň základě vysvětlit, jak tokenizace funguje. LLM využívají nejrůznější metody tokenizace, z nichž nejrozšířenější je Byte-Pair Encoding (BPE) ^[4]. Vezměme si ho tedy jako ukázkový. Princip je jednoduchý: algoritmus začíná se slovníkem jednotlivých bajtů a postupně sloučí nejfrekventovanější páry do nových tokenů, dokud nedosáhne cílové velikosti slovníku. GPT, Llama i Mistral používají varianty BPE ^[5].

Důležitý detail je, že slovník tokenizéru je specifický pro každý model. Stejný text zaslaný různým modelům bude téměř jistě převeden na jiný počet a sekvenci tokenů ^[1]. Například slovo „darkness“ se typicky rozloží na dva tokeny: „dark“ a „ness“ ^[2]. Sdílený token „ness“ pomáhá modelu porozumět, že slova mají něco společného.

Pro naše téma je klíčové pochopit, že různé typy textu mají různou tokenovou hustotu. Běžná angličtina se pohybuje kolem 4 znaků na token. Odborný žargon, právnické smlouvy nebo kód v HTML se tokenizují méně efektivně, protože obsahují výrazy, které jsou v obecném textu vzácné a tokenizér je musí rozložit na více částí ^[1].

Tokenizace jazyků jako je například čeština se svými háčky a čárkami je ještě náročnější. Vyzkoušet si to můžete například na webu https://platform.openai.com/tokenizer, kde si mžete vložit slovo v českém jazyce a ve srovnání v angličtině. Způsob zpracování tokenů se mírně liší – novější modely jsou obvykle úspornější – takže třeba slovo kočka ve starších modelech „spotřebovalo“ tri tikeny (ko/č/ka) a novější modely řady GPT 5 již zracovávají stejníé slova pouzte na dva tokeny (ko/čka).

Důvod najdeme v tom, jak se buduje slovník tokenizéru, konkrétně v algoritmu BPE a v trénovacích datech, na kterých se slovník učí. Tokenizér se totiž trénuje odděleně od samotného modelu. Při tréninku BPE algoritmus prochází obrovský textový korpus, počítá frekvence sousedních párů bajtů (nebo znaků) a postupně slučuje ty nejčastější do nových tokenů. Čím větší a rozmanitější korpus, tím více šancí má algoritmus narazit na české texty a vytvořit pro ně efektivní sloučení.

U starších modelů (řada GPT-2 až 4) byl trénovací korpus tokenizéru dominantně anglický. České znaky s diakritikou jako č, ž, ř, ě se v těchto datech vyskytovaly relativně zřídka. Algoritmus BPE proto nikdy nevytvořil dostatečně frekventovaný pár, který by sloučil například „č“ s následujícím „k“ do jednoho tokenu. Slovo „kočka“ se tak rozpadlo na tři nebo i více částí, protože žádná z kombinací obsahujících „č“ nepřekročila práh frekvence pro sloučení.

Datová krize

Podle výzkumu organizace Epoch AI činí celkový efektivní objem kvalitních veřejně dostupných textových dat přibližně 300 bilionů tokenů ^[6]. Pokud současné trendy pokračují, jazykové modely tento fond vyčerpají někdy mezi lety 2026 a 2032 ^[6]. Stanford AI Index 2025 tuto situaci označuje dokonce za závažnou, protože vydavatelé a platformy stále více omezují přístup AI firem k obsahu ^[7].

Situace je ještě dramatickější pro neanglická data. Anglický obsah tvoří přes 56 % webu, zatímco data ze všech ostatních jazyků dohromady pokrývají pouze 44 % ^[8]. Pro český jazyk je podíl ještě podstatně menší, což znamená, že každý kvalitní český text má pro trénink neproporcionálně velkou hodnotu.

V tomto kontextu nabývá na významu myšlenka, která se stává mantrou LLM komunity: lepší data porazí lepší algoritmy ^[9]. Specializované modely jako BioGPT, Med-PaLM nebo SaulLM-7B ukazují, že s kvalitně kurovanými daty stačí desítky miliard tokenů, aby doménový model překonával na specializovaných úkolech model obecný, trénovaný na bilionech ^[9].

Žrouti tokenů

Když webový crawler sbírá data pro trénovací korpus, získává typicky zdrojový kód HTML stránek. Problém spočívá v tom, že typická webová stránka obsahuje obrovské množství značek, atributů, tříd a metadat, které nenesou žádnou sémantickou informaci užitečnou pro model ^[10]. Navigační lišty, patičky, cookie bannery a reklamní bloky zabírají tokeny, aniž by přidávaly hodnotu ^[11].

Uvažme typický fragment HTML z blogu postaveného na moderním frameworku:

<p class=“text-base leading-relaxed text-gray-700 dark:text-gray-300″>Obsah odstavce…</p>

Atributy class, id, data-* a další slouží prohlížeči pro vykreslení CSS stylů, webové analytice nebo JavaScriptu pro interaktivitu. Jazykový model z nich neodvodí nic užitečného. Přesto všechny tyto řetězce spotřebovávají tokeny ^[10].

Problém se násobí v měřítku. Jak uvádí The New Stack, jediný neefektivně serializovaný záznam může ztratit stovky tokenů, a při milionech dotazů se tyto ztráty rychle akumulují ^[3].

Tabulka 1: Příklady tokenového nákladu HTML artefaktů (testováno na GPT-3 až GPT-5.x)

HTML artefakt	Tokeny
class=“article-container main-content“	7-9
data-analytics-section=“blog“	6-9
class=“text-2xl font-semibold mt-8 mb-4″	15-20
<div class=“article-body prose prose-lg max-w-none“>	12-18
id=“post-12847″	7
data-tracking-id=“abc123″	7-9

Markdown

Převod HTML na Markdown představuje jednu z nejefektivnějších strategií pro zvýšení tokenové efektivity trénovacích dat. Markdown zachovává sémantickou strukturu dokumentu — nadpisy zůstanou nadpisy, odkazy zůstanou odkazy, důraz zůstane důrazem — ale bez desítek nadbytečných atributů ^[10]. Oborové benchmarky potvrzují, že konverze HTML do Markdown snižuje tokenovou spotřebu o 20–30 % u běžných stránek ^[10] a až o 95 % u složitých e-commerce stránek ^[11].

Tabulka 2: Porovnání HTML a Markdown při stejném informačním obsahu

Metrika	HTML	Markdown	Úspora
Znaky (úryvek článku)	1 144	400	65 %
Tokeny (e-commerce) [11]	~40 000	~2 000	95 %
Tokeny (blog) [10]	3–4 000	800–1 200	20–50 %

Důležité je, že Markdown není jen úspornější z hlediska počtu tokenů. LLM jsou na Markdown přímo trénovány, protože obrovská část kvalitních trénovacích dat pochází z GitHubu, Stack Overflow a technické dokumentace ^[11]. Markdown navíc poskytuje sémantické kotvy, které model dokáže využít: nadpisy označené symbolem # explicitně definují hierarchii myšlenek, tabulky pomocí pipe znaku | umožňují sloupcové uvažování ^[11].

Další přístupy k tokenové úspoře

JSON a CSV

Pro tabulková data může být výhodné použít JSON namísto HTML tabulek. Zplostění vnořených JSON struktur a extrakce pouze relevantních polí dokáže snížit tokenovou spotřebu až o 69 % ^[3]. CSV překonává JSON o 40 až 50 % pokud jde o tokenovou efektivitu tabulkových dat ^[3].

Preciznost čísel

Malý, ale účinný trik spočívá v optimalizaci přesnosti číselných hodnot. Zaokrouhlení čísel na potřebnou přesnost dokáže snížit tokenovou spotřebu číselných hodnot o 30 až 40 % ^[3].

Co to znamená pro trénink

Vyšší informační hustota

Pokud je význam totžny, kratší reprezentace přináší vyšší informační hustotu. To znamená, že při stejném rozpočtu tokenů lze do datasetu zahrnout více různých příkladů. Výzkum Lagasse et al. potvrzuje, že kompozice dat — počet příkladů a jejich průměrná délka v tokenech — významně ovlivňuje tokenovou efektivitu ^[12].

Lepší poměr signálu k šumu

Delší text často obsahuje redundanci, stylistickou výplň nebo odbočky. Tyto části nenesou nový význam, ale model je musí zpracovat a naučit se jejich vzorce. Stručná formulace redukuje balast a zvyšuje poměr signálu k šumu ^[9].

Snížení nákladů

Ekonomický dopad se projevuje okamžitě. Jednou z ilustrací je případ firmy, která finetunováním modelu Mistral-7B jako náhrady GPT-3.5 dosáhla 85% snížení nákladů ^[1]. Finetunovaný model vyžadoval kratší prompty a produkoval stručnější výstupy, čímž se snížila tokenová spotřeba na obou stranách ^[1].

Nástroje pro konverzi HTML na Markdown

Specializovaný model ReaderLM-v2 od Jina AI je kompaktní model s 1,5 miliardou parametrů, který dokáže zpracovat dokumenty až o délce 512 tisíc tokenů a transformovat je z HTML do Markdown nebo JSON ^[13]. Podle benchmarků překonává starší model GPT-4o o 15 až 20 %^[13].

V ekosystému Pythonu jsou k dispozici knihovny jako html2text, markdownify a trafilatura ^[14]. Posledně jmenovaná je obzvláště vhodná pro přípravu trénovacích dat, protože dokáže inteligentně extrahovat hlavní obsah stránky a odstranit navigaci, reklamy a periferní elementy. Platformy jako Apify Website Content Crawler nabízejí konverzi do Markdown na úrovni infrastruktury a uvádějí úsporu 30–50 % tokenů oproti surovému HTML ^[15].

Od mobile-first k AI-first

Vzpomínáte na na období, kdy weby začaly nabízet dedikované verze pro mobilní zařízení? Nejprve šlo o samostatné instance na subdoménách, které nahradil responzivní design, a v posledních letech se dominantním paradigmatem stal přístup mobile-first. Důvod byl prostý: změnil se způsob konzumace obsahu.

Srovnatelná transformace probíhá právě teď. Místo mobilních prohlížečů jsou novými primárními konzumenty AI agenti a velké jazykové modely. Web, jak jej před více než třiceti lety navrhl Tim Berners-Lee, byl koncipován pro lidské čtenáře interagující přes grafické prohlížeče. HTML tuto orientaci odráží: obsahuje vizuální elementy, strukturální wrappery, navigační komponenty a vložené skripty. Pro jazykové modely představují tyto prvky z velké části zbytečný materiál, který musí být odfiltrován, než může začít smysluplné zpracování.

Většina současných AI pipeline proto zavádí mezikrok, v němž se HTML převádí na Markdown. Tato konverze odstraňuje prezentační vrstvu a zachovává kompaktní, sémanticky strukturovanou textovou reprezentaci vhodnou pro strojové zpracování [10][11]. Otázka ale zní: proč Markdown generovat až „po cestě“, když jej server může vrátit přímo?

Cloudflare Markdown for Agents

Cloudflare v únoru 2026 představil mechanismus nazvaný Markdown for Agents, který umožňuje serverům vracet Markdown přímo prostřednictvím standardní HTTP content negotiation [16]. Když klient zahrne do požadavku hlavičku Accept: text/markdown, síť Cloudflare automaticky převede HTML stránku na Markdown a doručí ji místo HTML. Aktivace vyžaduje pouze konfigurační změnu v dashboardu — žádné přepisování šablon, žádné další endpointy, žádné úpravy aplikačního kódu [16].

Výsledky jsou přesvědčivé: u vlastního blogu Cloudflare klesla tokenová spotřeba z 16 180 tokenů v HTML na 3 150 v Markdown, tedy úspora 80 % [17]. Odpověď navíc obsahuje hlavičku x-markdown-tokens s odhadovaným počtem tokenů, takže agent může dopředu plánovat strategii chunkování a využití kontextového okna [16]. Populární kódovací agenti jako Claude Code a OpenCode již hlavičku Accept: text/markdown aktivně odesílají [16].

Řešení pro organizace bez Cloudflare

Pro organizace, které Cloudflare nepoužívají, nabízí tento vývoj širší designový princip: aplikace budou stále častěji potřebovat vystavit alternativní, LLM-orientovanou reprezentaci svého obsahu, optimalizovanou pro strukturovanou strojovou konzumaci namísto vizuálního vykreslování.

Jedním z řešení je open-source projekt php-markdown-mirror [18]. Řeší jednoduchý problém: jeden zdroj pravdy, dvě reprezentace, žádná duplicita. Aplikace dál generuje HTML jako vždy. Middleware zachytí výstup, a pokud klient pošle Accept: text/markdown (nebo přidá parametr ?v=md), provede jednorázový DOM parsing, extrahuje hlavní obsah a vrátí jeho Markdown reprezentaci. Běžný návštěvník dostane plné HTML, AI agent dostane čistý Markdown s korektními hlavičkami Content-Type a Vary. Projekt navíc automaticky extrahuje Schema.org JSON-LD a převádí ho do YAML frontmatter, takže model dostane strukturovaná metadata bez nutnosti parsovat HTML [18].

Doplemenantárně lze zmínit přístup Joosta de Valka, tvůrce Yoast SEO, jehož WordPress plugin přidává na stránky tag <link rel="alternate" type="text/markdown"> a vytváří dedikované .md URL pro každý příspěvek [19]. Zatímco Cloudflare řeší konverzi na úrovni infrastruktury, tento přístup řeší objevitelnost — agent navštěvující HTML verzi programaticky zjistí, že Markdown verze existuje. Oba přístupy se vzájemně doplňují.

Doporučení pro praxi

Za prvé, při sběru dat z webu vždy konvertujte HTML na Markdown ještě před uložením do korpusu. Markdown zachovává sémantickou strukturu a minimalizuje tokenový šum ^[10][11].

Za druhé, pro tabulková data preferujte CSV před JSON a JSON před HTML. Volba formátu může znamenat rozdíl 40–50 % v tokenové spotřebě ^[3].

Za třetí, sledujte tokenovou efektivitu jako first-class metriku vedle přesnosti a latence ^[3].

Za čtvrté, testujte přesnost číselných dat. Nezbytečně přesná čísla zvětšují tokenový otisk bez přínosu ^[3].

A za páté, udržujte různé kompresní profily pro různé případy použití. Agentické workflow vyžaduje jinou optimalizaci než RAG pipeline ^[3].

Token economy není abstraktní koncept. Je to reálný ekonomický parametr, který rozhoduje o tom, kolik znalostí se vejde do daného rozpočtu, jak kvalitní budou trénovací data a kolik bude stát provoz modelu. Volba formátu podkladových dat má přímý dopad na všechny tři nákladové dimenze: výpočet, finance i kapacitu.

Jednoduché pravidlo zní: když máte pevný rozpočet na počet tokenů, vyplatí se zapisovat fakta co nejúsporněji, pokud se neztratí význam. Méně tokenů za stejný obsah znamená více prostoru pro jiné znalosti, nižší náklady a čistší trénovací data.

Seznam použité literatury

[1] The Data Lead. The New Tokenomics: A Comprehensive Guide to the Economics of Large Language Models [online]. 2025 [cit. 2026-02-16]. Dostupné z: https://thedatalead.com/the-new-tokenomics-a-comprehensive-guide-to-the-economics-of-large-language-models/

[2] NVIDIA. Explaining Tokens — the Language and Currency of AI [online]. NVIDIA Blog, 2025-05-01 [cit. 2026-02-16]. Dostupné z: https://blogs.nvidia.com/blog/ai-tokens-explained/

[3] The New Stack. A Guide to Token-Efficient Data Prep for LLM Workloads [online]. 2025-12-06 [cit. 2026-02-16]. Dostupné z: https://thenewstack.io/a-guide-to-token-efficient-data-prep-for-llm-workloads/

[4] SENNRICH, Rico, Barry HADDOW a Alexandra BIRCH. Neural Machine Translation of Rare Words with Subword Units. In: Proceedings of the 54th Annual Meeting of the Association for Computational Linguistics. 2016, s. 1715–1725. DOI: 10.18653/v1/P16-1162.

[5] KARPATHY, Andrej. minbpe: Minimal, clean code for the Byte Pair Encoding (BPE) algorithm commonly used in LLM tokenization [online]. GitHub, 2024 [cit. 2026-02-16]. Dostupné z: https://github.com/karpathy/minbpe

[6] VILLALOBOS, Pablo, Anson HO, Jaime SEVILLA, Tamay BESIROGLU, Lennart HEIM a Marius HOBBHAHN. Will we run out of data? Limits of LLM scaling based on human-generated data. In: Proceedings of the 41st International Conference on Machine Learning (ICML 2024). 2024, s. 49523–49544. ArXiv: 2211.04325.

[7] Stanford University. AI Index Report 2025 [online]. Stanford HAI, 2025 [cit. 2026-02-16]. Dostupné z: https://aiindex.stanford.edu/report/

[8] FUENTES, René, Haoming JIANG a Yejin CHOI. To Repeat or Not To Repeat: Insights from Scaling LLM under Token-Crisis. In: Advances in Neural Information Processing Systems. 2023. ArXiv: 2305.13230.

[9] PAUL, Rohan. Selecting and Preparing Training Data for LLMs (2024–2025) [online]. 2025-06-14 [cit. 2026-02-16]. Dostupné z: https://www.rohan-paul.com/p/selecting-and-preparing-training

[10] SearchCans. Markdown vs. HTML for LLM Context: Optimizing Performance & Cost [online]. 2026-01-16 [cit. 2026-02-16]. Dostupné z: https://www.searchcans.com/blog/markdown-vs-html-llm-context-optimization-2026/

[11] Maxun. Why Markdown is the Secret to Better AI [online]. 2026 [cit. 2026-02-16]. Dostupné z: https://www.maxun.dev/blog/markdown

[12] LAGASSE, Ryan et al. A Scaling Law for Token Efficiency in LLM Fine-Tuning Under Fixed Compute Budgets. ArXiv [online]. 2025. ArXiv: 2505.06150. Dostupné z: https://arxiv.org/abs/2505.06150

[13] WANG, Feng, Zesheng SHI, Bo WANG, Nan WANG a Han XIAO. ReaderLM-v2: Small Language Model for HTML to Markdown and JSON. In: Proceedings of ACL 2025. Jina AI, 2025. ArXiv: 2503.01151. Dostupné z: https://arxiv.org/abs/2503.01151

[14] GLUKHOV, Rost. Converting HTML to Markdown with Python: A Comprehensive Guide [online]. 2025 [cit. 2026-02-16]. Dostupné z: https://www.glukhov.org/post/2025/10/convert-html-to-markdown-in-python/

[15] Apify. Web Scraping for AI Training Data: The 2026 RAG Guide [online]. 2026 [cit. 2026-02-16]. Dostupné z: https://use-apify.com/blog/ai-training-data-web-scraping

[16] MARTINHO, Celso a Will ALLEN. Introducing Markdown for Agents [online]. Cloudflare Blog, 2026-02-12 [cit. 2026-02-16]. Dostupné z: https://blog.cloudflare.com/markdown-for-agents/

[17] The Register. Cloudflare turns websites into faster food for AI agents [online]. 2026-02-13 [cit. 2026-02-16]. Dostupné z: https://www.theregister.com/2026/02/13/cloudflare_markdown_for_ai_crawlers

[18] KUBÍČEK, Michal. php-markdown-mirror: Middleware pro servírování Markdown reprezentace PHP aplikací [online]. GitHub, 2026 [cit. 2026-02-16]. Dostupné z: https://github.com/kubicek-ai/php-markdown-mirror

[19] DE VALK, Joost. Great minds think alike? My WordPress take on Markdown for Agents [online]. 2026-02-12 [cit. 2026-02-16]. Dostupné z: https://joost.blog/markdown-alternate/