Jak vybrat jazykový model?

V tomhle článku se pokusím nastínit, podle čeho se rozhodovat, pokud vybíráte otevřený generativní jazykový model. Na co všechno si dávat pozor?

Chápu, že se může lišit jak vaše technická expertýza, tak záměr, se kterým model nasazujete. Půjde proto především o rozcestník, který vás nasměruje na další zdroje.

Projdeme postupně tři úrovně:

• Úroveň 1: Podle intuice, aneb aby to dávalo smysl.
• Úroveň 2: Podle hardwaru, aneb aby to dobře běželo.
• Úroveň 3: Podle využití, aneb aby to fungovalo podle očekávání.

Úroveň 1 – Podle intuice

O čem se mluví

Chcete jen jedno pravidlo, podle kterého se rozhodovat? Sáhněte po modelu, o kterém se v poslední době hodně mluví mezi lidmi.

Na hlasitý release nového modelu stačí mít dobrý marketing. Už bych ani nespočítal, kolikrát jsem viděl bombastický release nějakého modelu, o kterém jsem už od té doby nikdy víc neslyšel. Stejně tak výsledky na benchmarcích nejsou zrovna vypovídající. Ty se dají vždycky nějak “zaonačit” – stačí měřit faktory, které zrovna hrajou do kapsy vašemu modelu.

Pokud ale o modelu slyšíte ze všech stran, tak to znamená, že stojí aspoň za vyzkoušení. Stačí sledovat zmínky – sentiment není tak zásadní (málokterý model budou lidé zmiňovat s tím že “ten ale nestojí za nic”¹ Například model Llama 4 vypustila Meta s velkou slávou, ale od té doby se po něm slehla zem. ).

Je na to dobré sledovat kanály, kde se mluví o otevřených modelech. Já například sleduju Reddit r/LocalLLaMa a různé sociální sítě. Vaši kolegové můžou být samozřejmě také dobrým zdrojem.

Zajímavý benchmark, který vlastně není benchmarkem (o těch si povíme později), je OpenRouter Leaderboard. Ten ukazuje, které modely lidi používají skrz OpenRouter: službu, kde si předplatíte určitý počet tokenů a pak s nimi můžete využívat libovolné komerční i otevřené modely.² Anglicky se tomu říká “voting with your feet”. Tady například vidíme, že v posledním týdnu velké čínské modely jako tencent/Hy3, XiaomiMiMo/MiMo-V2.5 a deepseek-ai/DeepSeek-V4-Flash momentálně vedou. Z dalších stojí za povšimnutí Nemotron 3 Ultra od NVIDIA.

Dobré modely také lidi často používají jako základ pro fine-tunované a další upravené verze. Tady je vhodným příkladem Qwen 3.6: model z dubna 2026, který už je základem pro víc jak 4000 různých verzí. Mezi nimi je momentálně nejoblíbenější bottlecapai/ThinkingCap-Qwen3.6-27B od českých kolegů z BottleCap AI se stručnějším uvažováním, necenzurovaná verze HauhauCS/Qwen3.6-35B-A3B-Uncensored-HauhauCS-Aggressive nebo verze s vylepšenou kvantizací unsloth/Qwen3.6-27B-NVFP4.

Zajímavý zdroj jsou i aktuální výzkumné články. Výzkumníci se totiž většinou snaží využít k experimentům ty nejschopnější otevřené modely, které jsou k dispozici. I u článků z arXivu – tedy pre-printového serveru, kde se články objevují v podstatě bez prodlení – je ale potřeba počítat s tím, že modely budou tak o 3–12 měsíců pozadu kvůli prodlevě mezi samotnými experimenty a publikací článku.

Oblíbenost a počet stažení

Pravdou totiž je, že vybírat otevřený jazykový model je jako vybírat mobilní telefon před 15 lety. To, co vyšlo před rokem, je teď na hranici použitelnosti. To, co vyšlo před dvěma, už v podstatě nestojí za řeč.

Jedním z těch lepších způsobů, jak získat do ekosystému otevřených modelů vhled, je proto přes trending zobrazení na Hugging Face Models. To bere v úvahu, o které modely je v poslední době zájem.

Dvakrát si naopak rozmyslete řazení modelů podle lajků nebo počtu stažení. Pokud si například na Huggingface seřadíte modely podle lajků, jako první uvidíte model deepseek-ai/DeepSeek-R1:

Důvody k jeho oblíbenosti se nabízejí: je to první otevřený reasoning model, který – a obzvlášť jeho doprovodný paper – odstartoval celou éru tohoto typu modelů. Pro nasazení bych ho ale už dnes určitě nevybral. Nebo třetí nejstahovanější model je facebook/opt-125m:

Řada modelů OPT od Mety byla jednou z prvních rodin otevřených modelů, za což jí patří kredit. Brzo ale byla překonána interní konkurencí: rodinou modelů Llama, která se stala symbolem otevřených modelů (viz odkazované Reddit vlákno, případně názvy jako “Ollama” nebo “llama.cpp”).

Lepší je proto skoro vzít tuto nadsázku jednoho Redditora doslova a nesnažit se výběr modelů přeoptimalizovat:

O těch dobrých modelech nejspíš už víte.

Úroveň 2 – Podle hardwaru

I pokud si ale vyberete nějaký model a jeho základní verzi, nemáte ještě zdaleka vyhráno. Většina modelů totiž přichází v tzv. “rodinách”, které zahrnují řadu variant. Například rodina modelů Qwen 3.5 na Hugging Face nabízí následující varianty:

- Qwen/Qwen3.5-397B-A17B
- Qwen/Qwen3.5-397B-A17B-FP8
- Qwen/Qwen3.5-122B-A10B
- Qwen/Qwen3.5-122B-A10B-FP8
- Qwen/Qwen3.5-35B-A3B
- Qwen/Qwen3.5-35B-A3B-FP8
- Qwen/Qwen3.5-35B-A3B-Base
- Qwen/Qwen3.5-27B
- Qwen/Qwen3.5-27B-FP8
- Qwen/Qwen3.5-9B
- Qwen/Qwen3.5-9B-Base
- Qwen/Qwen3.5-4B
- Qwen/Qwen3.5-4B-Base
- Qwen/Qwen3.5-2B
- Qwen/Qwen3.5-2B-Base
- Qwen/Qwen3.5-0.8B
- Qwen/Qwen3.5-0.8B-Base
- Qwen/Qwen3.5-397B-A17B-GPTQ-Int4
- Qwen/Qwen3.5-122B-A10B-GPTQ-Int4
- Qwen/Qwen3.5-35B-A3B-GPTQ-Int4
- Qwen/Qwen3.5-27B-GPTQ-Int4

V tuto chvíli už musíme začít uvažovat techničtěji: jaký hardware můžete pro provoz modelu nabídnout a jaké provozní parametry očekáváte.

Úplně základním předpokladem pro to, abyste model mohli provozovat, je to, že se vám vejde do paměti. To znamená buď přímo do RAM paměti počítače, pokud model provozujete na CPU (nebo na integrovaných GPU jako novějších AMD Radeon nebo Apple Silicon), případně – a to bude častější případ – do VRAM grafických karet.

Dalším parametrem, který budete určitě řešit (alespoň pokud model používáte interaktivně), je rychlost jeho provozu. Základem je metrika Tokens Per Second (TPS), tedy počet tokenů za sekundu. S touto metrikou souvisí další ukazatele, jako například Time To First Token (TTFT), tedy doba do vygenerování prvního tokenu, která vyplývá z rozdílu mezi TPS pro zpracování vstupu a TPS pro generování výstupu.

Při výběru modelu je to tedy o balancování: z hlediska schopností modelu chcete ten největší model, který jste schopni provozovat na vašem hardwaru, zatímco z hlediska rychlosti chcete naopak ten nejmenší.³ S velikostí to platí pouze pokud se omezíme na konkrétní rodinu modelů – menší, ale novější modely mohou ve všech ohledech překonat větší, ale starší modely. Různé speciální techniky (jako například Mixture-of-experts, viz níže) pak můžou zahýbat s přímočarým vztahem mezi velikostí modelu a jeho rychlostí. Hierarchie pamětí je totiž neúprosná a na offloading (tedy odložení částí modelu do pomalejší paměti) se až na pár speciálních případů nechcete spoléhat.

Velikost modelu

Schopnosti modelu bývají zpravidla tím důležitějším faktorem. Hodí se proto získat intuitivní odhad, jaký největší model zvládnete na svém hardwaru provozovat.

Získat tento odhad je překvapivě jednoduché, i když musíme lehce zabrousit do technických detailů.

Pojďme pro začátek předpokládat, že pracujeme se standardním Transformer modelem. Jak už jsme si vysvětlili v předchozím článku, naprostou většinu tohoto modelu tvoří jeho parametry reprezentované pomocí desetinných čísel.

Desetinná čísla v paměti počítače ukládáme pomocí reprezentace s pohyblivou řádovou čárkou (floating point number). Jinak řečeno, vyhradíme si konkrétní počet bitů a v nich zapíšeme číslo tzv. vědeckou notací: část bitů vyhradíme na samotný “obsah čísla”, tedy platné číslice (česky jinak také mantisu, anglicky “fraction”), část bitů na to “o kolik se má posunout desetinná čárka”, tedy exponent, a jeden bit na znaménko (+/-).

V 32 bitech (tedy fp32) může být tedy desetinné číslo zapsáno například takto:

Všech 32 bitů (nebo dokonce 64 bitů, jak je standardem pro desetinná čísla v Pythonu) ale pro většinu parametrů v neuronových sítích a konkrétně jazykových modelech nepotřebujeme – viz např. Gupta et al. (2015) a Ott et al. (2018). V podstatě bez ztráty kvality můžeme parametry reprezentovat i 16 bity, tedy fp16.

V současnosti je zlatým standardem pro reprezentaci parametrů jazykových modelů formát bf16. Tento formát pochází z dílen Google Brain (odtud to “b” v názvu) a oproti standardnímu fp16 se liší pouze jiným rozložením exponentu a mantisy, které o něco víc upřednostňuje rozsah čísel nad přesností:

Od tohoto formátu se můžeme odrazit při výpočtech paměťové náročnosti modelu. Pokud ID modelu vypadá jako Qwen/Qwen3.6-27B, znamená to, že tento model obsahuje 27B = 27 billion = 27 miliard parametrů.

Každý tento parametr v přesnosti fp16 nebo bf16 zabírá 16 bitů, tedy 2 bajty. A 27 miliard × 2 bajty odpovídá zhruba 54 gigabajtům.⁴ Samozřejmě záleží, jestli počítáme s dvojkovým nebo desítkovým základem, ale bavíme se o hrubých odhadech. Také pozor, že skutečný počet parametrů bývá o něco vyšší, než kolik říká zaokrouhlené číslo v názvu modelu. Něco přes 54 GB je tedy naprosté minimum RAM / VRAM, které musíte mít pro provoz modelu k dispozici.

Proč minimum? Když nepočítám lehký overhead na různá metadata, další místo v paměti zaberou především hodnoty spočítané během provozu modelu. Konkrétně se bavíme o velikosti KV-cache (tedy spočítaných klíčů a hodnot z attention mechanismu) pro konkrétní délku kontextu.

Pro lepší představu, jak tyto dvě hodnoty interagují, jsem vytvořil následující kalkulačku, kterou nově najdete i přímo zde na webu. Dokáže podle ID modelu z Hugging Face spočítat paměťovou náročnost modelu.

Zkusit si to můžete rovnou tady:

Následující tabulka je spočítaná pro Qwen3.6-27B, jehož váhy bf16 zaberou podle kalkulačky 55,6 GB (tedy o trochu více, než náš původní odhad), k tomu připočítáváme KV-cache v přesnosti fp16 a zhruba 1 GB režie navíc:

Je vidět, že délka kontextu může být u paměťových nároků dost zásadní faktor. Zatímco ještě před pár lety byl kontext o 8192 tokenech nadstandardní, s agentními modely s definicemi MCP nástrojů a skillů musíme uvažovat spíš v řádech statisíců.

Tato čísla vás zároveň nejspíš nepotěšila. Standardní grafické karty pro konzumenty (NVIDIA RTX 4090 a podobné) mají VRAM kolem 16–32 GB. Pro provoz 27B modelu nám tedy jedna takováto karta stačit nebude. Model by se vešel až na high-end grafické karty jako je NVIDIA H100 s 80 GB paměti, ale to jen pokud bychom délku kontextu omezili někde mezi 32–64 tisíci tokenů.

Naštěstí existují i způsoby, jak toto místo zásadně uspořit.

Lehký úvod do kvantizace

Asi vás hned napadne, proč by zrovna 16 bitů mělo být tím magickým číslem, které pro uložení parametrů modelu funguje. Nedá se jít ještě dál – třeba na 8, 4, 2, 1 bit? Degraduje kvalita nějak zásadně?

Na tuto otázku dává odpověď kvantizace parametrů: tedy sada metod, jak váhy modelu (a aktivace, tedy vypočítané hodnoty) reprezentovat v nižší přesnosti. Je to tak velké téma, že si určitě zaslouží ještě samostatný článek, teď se zkusíme především podívat, jak chápat kvantizaci při výběru modelů.

TL;DR: Ano, přesnost vah můžeme snižovat až na naprosté minimum. Dokonce můžeme mít i model, kde každá váha je pouze -1 nebo 1, tedy 1-bit, viz prism-ml/Bonsai-27B-gguf.⁵ To už je ale hodně specifický extrém a vyžaduje, aby model byl tímto způsobem natrénovaný. Obecně platí, že čím výraznější je kvantizace, tím víc schopnosti modelu degradují. Kvantizace na 8-bit nebo 4-bit je každopádně běžně využívaná pro provoz větších modelů na hardwaru, který by tento model v původní kvalitě neutáhl.

Stručný přehled dává následující tabulka, při jejíž tvorbě jsem se inspiroval zde:

Jak tuto tabulku chápat?

První “zastávkou”, kam dává smysl jít z 16 bitů, je polovina této přesnosti, tedy 8 bitů. Zde už máme v počítačích standardní datový formát pro reprezentaci čísel: int8. Ten ale reprezentuje celá čísla, a proto funguje principiálně jinak než reprezentace desetinných čísel. Zatímco při převodu fp32 → fp16 stačilo jen snížit přesnost čísel, při převodu z desetinných na celá čísla jde už o skutečnou kvantizaci.⁶ Původem “kvantizace” naznačuje přechod od kontinuálního (tedy idealizovaného formátu desetinných čísel) k diskrétnímu (tedy celým číslům). Tento pojem je obecně používán pro všechen převod na formát nižší přesnosti – zvlášť proto, že reprezentace všech čísel v počítači je z podstaty diskrétní. Musíme proto řešit, že přesnost najednou není dynamická (tedy vyšší u nižších hodnot), ale konstantní:

To není pro parametry v neuronových sítích příliš výhodné, protože outliery (velice nízké / vysoké hodnoty) mohou být náročné správně přeškálovat, abychom tím nepoškodili ostatní parametry.

Proto je pro tuto úroveň přesnosti lepší používat formát fp8, tedy desetinné číslo o 8 bitech:

Tento formát zachovává kvalitu natolik výrazně, že například model DeepSeek-V3 byl v tomto formátu i přímo natrénovaný. Je to i v dnešní době poměrně standardní formát pro provoz středních a větších modelů – viz např. výše zmíněný Qwen/Qwen3.5-27B-FP8. Problém ale je, že nejde o standardní datový typ a je podporovaný teprv až na novějším hardwaru.

Existují i kvantizace na 6 a 5 bitů, ale jsou spíš exotičtější a prozatím je přeskočíme.

Zajímavá je ovšem 4-bitová kvantizace. Ta sníží velikost původního modelu zhruba na čtvrtinu: pro 27B model tedy najednou nepotřebujeme minimálně ~55 GB paměti, ale pouze ~14 GB, což už má šanci se vejít na více low-end grafickou kartu.

Stejně jako u 8 bitů i tady záleží na tom, jaký formát se pro uložení vah použije. Ve světě 4-bitové kvantizace narazíte hlavně na tři:

• int4 – celočíselná reprezentace, obdoba int8 o patro níž. Trpí stejnými neduhy: konstantní přesnost a citlivost na outliery. V praxi se proto skoro nikdy nepoužívá tento formát “jen tak”: váhy se musí dělit do malých bloků, z nichž každý má vlastní škálovací faktor. Na tomto principu stojí většina běžných kvantizací, které dnes potkáte: GPTQ-Int4 z variant Qwen 3.5 výše nebo formáty GGUF označené jako Q4_K_M nebo Q4_K_S.
• fp4 (resp. jeho hardwarové varianty MXFP4 a NVFP4) – 4-bitové desetinné číslo, tedy stejný princip jako fp8, jen v ještě úspornějším balení. Díky dynamické přesnosti si vede lépe než int4 a novější hardware (NVIDIA Blackwell) ho zvládá nativně. Výše zmíněný unsloth/Qwen3.6-27B-NVFP4 je právě příklad tohoto formátu.
• nf4 (NormalFloat4) – 4-bitový formát, který je navržený přímo na míru vahám s (přibližně) normálním rozdělením. Jinak řečeno: reprezentace je hustší tam, kde je nejvíc hodnot. Proslavil se jako součást metody QLoRA pro efektivní fine-tuning.

Co mít dál obecně na paměti:

• Pokud optimalizujete na kvalitu výstupu a můžete si vybrat 30B model v 8-bit přesnosti vs. 60B model v 4-bit přesnosti, měli byste si vybrat spíš ten druhý – tedy větší model s extrémnější kvantizací (viz např. Dettmers & Zettlemoyer, 2023, Ouyang et al., 2025, Kumar et al., 2025). Platí to ale pouze do určité míry a vždy je lepší otestovat model na váš konkrétní případ: je dost pravděpodobné, že schopnosti modelu degradují nerovnoměrně.
• Silnější kvantizace nezaručuje automaticky vyšší rychlost modelu – často to může být i naopak! Záleží na tom, jestli váš model podporuje operace v nižší přesnosti nativně, nebo jestli je před použitím “dekvantizuje”: tedy rozbalí před prováděním výpočtů do formátu ve vyšší přesnosti. Zároveň nemusíte uspořit nic kvůli tomu, že úzké hrdlo je jinde než ve výpočetní kapacitě – například v přesunech mezi pamětí.
• Zásadní je nemyslet jen na kvantizaci vah modelu, ale i na kvantizaci KV cache, kterou jsme si popsali výše. Tam se můžeme o kvantizaci rozhodnout separátně od kvantizace modelu. Opět platí, že 16 bitů je referenční kvalita, s 8 bity neztratíme téměř žádnou kvalitu a standardně se pro kvantizaci používá.

Dense modely vs. Mixture-of-experts

Mixture-of-experts (MoE) je poměrně novou technikou, která je ale už velmi rozšířená a může zásadně změnit matematiku “jak rychle poběží konkrétní model” k lepšímu.

Stručně řečeno, MoE modely jsou natrénované tak, aby potřebovaly – narozdíl od standardních dense⁷ Česky “husté” modely, ale za mě jsou “husté” (alespoň metaforicky) spíš MoE modely, tak se radši překladu vyhneme. modelů – při dekódování výstupu jen část svých parametrů. Funguje to díky tomu, že donutíme během trénování model, aby své parametry po skupinách specializoval. Kvalita výstupů může lehce utrpět, ale když se to udělá správně, tak za to potenciální zrychlení stojí. Protože méně aktivních parametrů = méně výpočetních operací = rychlejší model.

MoE modely poznáme podle toho, že ve svém ID specifikují počet aktivních parametrů. Například Qwen/Qwen3.6-35B-A3B má z celkového počtu 35B parametrů v každou chvíli jen 3B aktivních a může být tedy odhadem až 10× rychlejší při inferenci (záleží ale i na řadě dalších faktorů).

Skupina parametrů, která je v danou chvíli aktivní, se může lišit jak vrstva od vrstvy:

tak token od tokenu:

Z toho je tedy jasné, že co díky MoE modelům neuspoříme, je paměť, kterou potřebujeme pro provoz modelu. Model průběžně “experty” (tedy skupiny parametrů) střídá a musíme je mít tedy po ruce všechny. Teoreticky tedy můžeme jednotlivé experty offloadovat do pomalejší paměti, ale jde spíš o nouzové řešení. Matematika “kolik potřebuju na model VRAM” je tedy u MoE modelů v zásadě stejná.

Úroveň 3 – Podle využití

Dejme tomu, že jste si předvybrali sadu modelů, které na vašem hardwaru s jistotou rozběhnete v rozumné rychlosti. Co teď, který nasadit primárně?

Benchmarky? Ano, ale vlastní!

Je vždy skvělé, když můžeme na něčí výkon nalepit číslo (ideálně jen jedno), protože se nám pak podle výkonu dobře řadí.

Bohužel na řazení jazykových modelů podle schopností to takhle notoricky nefunguje. Nefungovalo to dobře už v době, kdy modely měly dobře řešit jen jeden problém, jako například překládat mezi dvěma jazyky. (Protože: co je lepší překlad? Ten, co je přesnější? Gramaticky správnější? Přirozenější?)

Ve chvíli, kdy jazykový model musí zvládat řadu zcela odlišných úkolů, koncept řazení modelů na jedné ose se rozpadne úplně.

Tedy až na to, že jeden z nejpoužívanějších indexů dneška, Artificial Analysis, se přesně o tohle snaží:

A jejich snaha je chvályhodná. Jednak je většinou lepší mít alespoň nějakou představu, než žádnou, jednak to dělají v zásadě dobře: toto skóre je agregované z řady různých velkých benchmarků. Přesto toto číslo může navádět k předčasným závěrům.

Artificial Analysis ale těch leaderboardů má ve skutečnosti celou řadu, což je cesta správným směrem. Například schopnost psát kód nebo fungovat jako agent může být něčím, co jeden model zásadně odlišuje od druhého, ale v agregovaném skóre se ztratí.

Každopádně pokud plánujete nasadit model v konkrétní doméně, která není tak úplně standardní, potřebujete vlastní benchmark.

Pracujete s českými právními dokumenty? Je váš model finetunovaný na výstup v JSON formátu pro vaši specifickou knowledge base? Potřebujete kódovacího asistenta na neobvyklý dialekt assembleru?

Pak vám nejspíš existující srovnání modelů nepomůžou. Může se dost dobře stát, že malý specializovaný model bude tím nejlepším, co na váš případ existuje. A nebo to bude naopak – nejnovější obecný velký model překoná všechny modely, které papírově “řeší” váš problém.

Téma bechmarků zase vystačí na další článek samo o sobě, zatím si ale vystačíme s touto drobnou radou: postavte si vlastní benchmark a na něm si předvybrané modely otestujte.

Trénovací data: co od modelu čekat?

Instruction tuning: nezbytný základ?

Řadu aspektů chování modelu nezjistíte na první, druhý, ani třetí pohled. Můžou uniknout i vašemu specializovanému test setu, nebo se jednoduše ztratí v agregovaných skóre.

U každého modelu je dobré mít povědomí o tom, na jakých datech byl natrénovaný – jak při předtrénování, tak při dotrénování.

Úplně základním aspektem je fakt, jestli model prošel instruction tuningem. Nějaké dva tři roky zpátky bylo standardem, že nově vydaný model byl tzv. base, tedy pouze základní předtrénovaný model bez jakéhokoliv dalšího tuningu. To znamenalo, že model se nebude konzistentně chovat jako asistent, protože jen čistě předpovídá následující text v textech, na kterých byl natrénovaný.

Ironicky – a proto to může uniknout vaší evaluaci – se i base model občas jako asistent chovat může, obzvlášť pokud ho do toho navedete formátem otázky (“Odpověz na následující otázku: Jaké je hlavní město Francie? Odpověď: ”)⁸ Trénování na takovémto formátu vstupu je ostatně podstatou samotného instruction tuningu. Pokud ho ale napromptujete pouze “Jaké je hlavní město Francie?”, může se stát, že vám model odpoví například: “Paříž. Jaké je hlavní město Německa? Berlín. Jaké je hlavní město Itálie?” atd., což pravděpodobně nebyl váš záměr.

Base modely chcete jen v případě, že děláte velmi specifické experimenty, případně model chcete dotrénovat na vašich datech a nevyžadujete, aby se následně choval jako asistent.

V dnešní době už je naštěstí (alespoň pro lidi, co při stahování modelu nedávají moc pozor) instruction tuning téměř standard. Proto se modely chovající se jako asistent nerozlišují žádnou příponou, zatímco nedotrénované modely se rozlišují příponou -base. Tak je tomu například u modelu Qwen: viz Qwen3.5-9B vs. Qwen3.5-9B-Base.

Ale pozor: u Gemmy 4 (také velmi aktuálního modelu) je tomu přesně naopak! Base model je bez dalšího rozlišení: gemma-4-12B, zatímco dotrénovaný model má příponu -it: gemma-4-12B-it.

U instruction tuningu se skrývají i další záludnosti v podobě chat templatů, ale tady vás prozatím odkážu na tutorial od Hugging Face.

Domény a zdroje

Dále je tu velké téma domén a zdrojů trénovacích dat. Smutnou pravdou je, že ani u většiny otevřených modelů se nemáme šanci příliš dozvědět, protože tato informace narozdíl od samotných modelů veřejná není.

Čest výjimkám – modelům, kde jejich vývojáři publikují jejich trénovací data v plném rozsahu. Z těch známějších a novějších stojí za povšimnutí Olmo 3, sada modelů o velikostech 7B a 32B, jejíž trénovací data ze všech fází si můžete prohlížet přímo na Hugging Face:

Stejně otevřené jsou i menší modely SmolLM přímo od Hugging Face. Ty jsou navíc doprovázené neuvěřitelně podrobnými “playbooky”: aneb kuchařskými recepty, jak podobné modely natrénovat. Podobně jsou na tom i modely Nemotron od NVIDIA nebo švýcarský Apertus.

U většiny dalších modelů (obzvlášť těch čínských) se musíme spokojit s tím, co nám jejich vývojáři napíšou do doprovodného technického reportu, případně do tzv. “model card” – tedy popisu modelu přímo na Hugging Face. Technický report může být občas cenným zdrojem informací, jako je tomu u modelu DeepSeek-R1, který sice nemá otevřená trénovací data, ale má podrobně sepsaný recept na jejich vytvoření.

Ale také může být podobně nicneříkající jako technický report k modelu Gemma 4, jehož sekce Training data zní takto:

Training data. Our pre-training dataset is a largescale, diverse collection of data from a wide range of domains and modalities, including web documents, code, images, and audio (for E2B, E4B and 12B), with a cutoff date of January 2025.

Co se dá přece jen většinou zjistit?

U explicitně multilinguálních modelů většinou bývají explicitně zmíněné jazyky, které model podporuje. Například u modelu Aya-Expanse-32B se dočteme:

Languages covered: The model is particularly optimized for multilinguality and supports the following languages: Arabic, Chinese (simplified & traditional), Czech, Dutch, English, French, German, Greek, Hebrew, Hindi, Indonesian, Italian, Japanese, Korean, Persian, Polish, Portuguese, Romanian, Russian, Spanish, Turkish, Ukrainian, and Vietnamese

Takový seznam ale není ani úplný, ani závazný. Model může umět i jazyky, které v něm nejsou, a modely bez podobného výčtu na tom klidně můžou být stejně dobře. Jestli model umí česky, bývá spíš funkcí jeho velikosti. Tedy jediné, co ze seznamu bezpečně víme, je to, že se čeština v trénovacích datech vyskytla.

Dál se většinou můžeme dočíst, jestli byl model trénovaný na reasoning datech, agentních datech (obzvlášť používání nástrojů) nebo dlouhých kontextech. Často je to rozlišeno přímo i v ID modelu (např. přípona -thinking pro modely, které za všech okolností generují thinking trace), většinou se tím ale výrobce modelu chlubí i v popisu modelu, protože je to pro jeho následné použití zásadní faktor.

Co se spíš nedočteme, je to, jaký má model postoj k politice, ke svému vlastnímu vývojáři, a ke spoustě dalších společenských otázek. Odpovědi modelu na otázky, na které není jednoznačná odpověď, do velké míry závisí na jeho trénovacích datech. Zde se buď musíme začíst do výzkumných článků (ochutnávka třeba zde nebo zde), podívat se na související benchmarky (třeba tento) nebo si opět model otestovat ručně.

Překvapivě v těchto ohledech občas odvádějí lepší práci komerční dodavatelé. Například Anthropic chování Claude důkladně vyhodnocuje, vhledy do chování modelu dává i technický report Gemini 2.5.

Licence

Poslední zastávkou před nasazením modelů do produkce – nebo naopak první, pokud chcete mít rychlý filtr – by měla být jeho licence. Stejně jako u open-source kódu, i u otevřených modelů se podmínky jeho použití mohou lišit.

Většina otevřených modelů je k dispozici pod standardní otevřenou licencí jako je Apache 2.0, MIT nebo BSD. Například všechny zmíněné modely jako Olmo, Apertus nebo SmolLM jsou dostupné pod Apache 2.0 licencí (zde i včetně trénovacích dat), stejně tak Qwen, otevřené modely od Mistralu nebo GPT-OSS od OpenAI (zde už bez trénovacích dat), DeepSeek-R1 je pak dostupný pod MIT licencí. Tyto licence umožňují i komerční použití.

Modely od velkých korporací mívají většinou otevřenou licenci nějak specificky upravenou. Například Meta Llama 3 licence vyžadovala specifické povolení, pokud vaše firma měla přes 700 milionů aktivních uživatelů, a požadovala, aby všechny odvozené modely obsahovaly na začátku jméno “Llama 3”:

 If you use the Llama Materials to create, train, fine tune, or otherwise improve an AI model, which is distributed or made available, you shall also include “Llama 3” at the beginning of any such AI model name.

Dalšími příklady modelů se specifickými licencemi jsou pak modely Nemotron pod NVIDIA Open Model License nebo dřívější modely Gemma od Googlu (nově Gemma 4 už je také pod Apache 2.0 licencí).

Existují i otevřené modely, které explicitně zakazují komerční použití, jako například většina z rodiny modelů Aya od Cohere, které jsou dostupné pouze pod CC-BY-NC licencí. Takovýchto modelů je ale minimum. Licence proto většinou nebude zásadním rozhodovacím faktorem, o těch několika specifických případech je ale dobré vědět.

Závěrem

Doufám, že je v tuhle chvíli jasnější, jaký jazykový model může být pravý právě pro váš konkrétní případ. Tento článek měl být jen rychlým rozcestníkem, ale nakonec poměrně nabobtnal – a to i přes to, že většinu témat jsme vzali spíše “letem světem”. Jestli vás některé z témat zaujalo a chtěli byste se o něm dozvědět víc, dejte vědět na Discordu!