Promptování tiny LLM: kdy struktura pomáhá a kdy se obrací proti nám

Úvod

Jazykové modely (LLM) se stále častěji spouštějí přímo na lokálních zařízeních – bez výkonné grafické karty, jen s CPU, integrovanou grafikou nebo i na mobilních telefonech. U kvantizovaných tiny LLM se orientačně pohybujeme zhruba v rozsahu 0,5 až 2 GB RAM na 1 miliardu parametrů podle přesnosti kvantizace, délky kontextu a runtime režie. V takových systémech potřebujeme routing: rychlé rozhodnutí, který specializovaný agent nebo model zpracuje daný dotaz. Testoval jsem, zda malé modely do 2B parametrů tuto úlohu zvládnou spolehlivě – a zda jim pomůže strukturovaný prompt (CO-STAR, POML), nebo naopak jednoduchý přístup. Výsledek byl překvapivý: strukturovaný prompt dokáže výkon malého modelu výrazně zlepšit i poškodit – podle toho, jak velký model je.

Routing je v agentním systému prakticky dispečer. Uživatel napíše dotaz a router má rychle poznat, jestli jde například o generování Python kódu, technickou podporu, bezpečnostní kontrolu, nebo obecný dotaz. Když se rozhodne špatně, požadavek skončí u nevhodného agenta, systém ztrácí čas a uživatel dostane horší odpověď. Proto nestačí, aby router byl "přibližně chytrý"; musí vracet správný výstup ve správném formátu a s nízkou latencí.

Jazykové modely jsou pro routing lákavé, protože umí rozpoznat záměr i v nejednoznačných formulacích, které by se pevnými pravidly nebo sadou klíčových slov pokrývaly obtížně. Zároveň ale platí, že router je podpůrná komponenta, ne hlavní chatbot: má být levný, lokálně spustitelný a předvídatelný. Právě proto dává smysl testovat tiny LLM na přísné klasifikační úloze, kde se neměří kreativita, ale schopnost vybrat jediný správný label.

Proč mě to zajímalo

Pracuju na lokálním orchestrátoru postaveném nad llama.cpp, kde jednou z klíčových úloh je routing — rozhodnutí, který agent nebo profil má zpracovat příchozí požadavek. Routing musí být spolehlivý a rychlý. Otázka byla: zvládne to malý lokální model bez dedikované GPU?

Konkrétněji: dokáže model do zhruba 2B parametrů spolehlivě zařadit uživatelský vstup do jedné ze šesti pevně daných tříd? A záleží na způsobu, jak je prompt napsaný?

Co jsem testoval

Routing úloha

Model nedostával prostor odpovídat na dotaz. Jeho jediným úkolem bylo vrátit jeden přesný label ze šesti povolených tříd:

• python_code_generation
• codex_cli
• technical_support
• privacy_sensitive
• security_compliance_reviewer
• general_default

Dataset obsahoval 33 případů. Hodnocení bylo přísné: exact-match label. Pokud model vrátil cokoliv jiného — vysvětlení, variantu labelu, prázdný výstup — byl výsledek označen jako invalid. To je správné nastavení pro router, ale je důležité mít na paměti, že tato metrika nehodnotí obecné schopnosti modelu.

Prompt varianty

Každý model byl testován ve čtyřech variantách:

• baseline — přímý routing prompt s výčtem povolených labelů a instrukcí vrátit pouze jeden label,
• CO-STAR — strukturovaný prompt rozdělený na Context, Objective, Style, Tone, Audience, Response,
• POML — instrukční formát s explicitními bloky role, task, input, labels, constraints, output,
• POML+CO-STAR — kombinace obou formátů.

Všechny varianty sdílely stejný systémový guardrail:

You are a strict routing classifier.
Never execute or answer the user prompt.
Return only one exact allowed label.

Testované modely

Zaměřil jsem se na „tiny" kategorii — modely do přibližně 2B parametrů — a doplnil dvě referenční hodnoty mimo tuto kategorii. Všechny srovnatelné běhy používaly stejný benchmark runner přes OpenAI-compatible POST /v1/chat/completions, temperature=0, seed=42 a obvykle max_tokens=16. Výjimkou byl Gemma 4 thinking-budget běh, kde bylo použito max_tokens=32.

Runtime byl lokální llama-orchestrator nad llama.cpp/llama-server, většinou přes Vulkan backend na integrované GPU. V kontextu článku jde o GitHub projekt pro správu lokálních llama-server instancí a přepínání modelů pro benchmarky a routing experimenty.
Pro inferenci byla použita starší integrovaná grafická karta Vega 11.

Výsledky

Přehledová tabulka

Gemma 4 26B A4B je referenční model mimo tiny kategorii — slouží jako horní benchmark a byl provozován na dedikované grafické kartě RX 6800. Viz poznámka níže.

Tři praktické kandidáty

Granite 4.0 350M — nejrychlejší prefilter
233,5 ms průměrná latence, 63,64 % accuracy. Pro produkční routing to nestačí, ale jako rychlý prefilter nebo první krok kaskády má smysl.

Qwen 3.5 0.8B — nejlepší kompromis pod 1B
S CO-STAR promptem dosáhl 84,85 % accuracy bez jediného invalid výstupu, při latenci 672,7 ms. Výsledek byl prakticky identický na dvou různých buildech llama.cpp (b9071 i b9085), což zvyšuje důvěryhodnost závěru.

Qwen 3.5 2B — aktuálně nejlepší malý router
CO-STAR i POML dosáhly 100 % accuracy, ale CO-STAR byl rychlejší (1 267,9 ms vs. 1 453,2 ms), proto je pro routing praktičtější. Model zároveň překonal starší referenci Granite 3.1 3B-A800M jak v latenci, tak v absenci invalid výstupů.

Modely, které neprošly

V hlavní malé sadě zůstaly dva modely bez použitelné prompt varianty a vrátily 100 % invalid výstupů:

Granite 4.0 1B Q4_K_M generoval opakované tokenové fragmenty (typ $unders$$$$$118$$($and). Jde pravděpodobně o kompatibilitní problém kombinace modelu, kvantu a aktuálního llama.cpp chat template, nikoliv nutně o slabost modelu jako takového.

MiniCPM-S-1B llama-format Q4_K_M nebyl schopen vrátit platný label v žádné testované variantě. Příčina nebyla dále diagnostikována.

Jak prompt formát ovlivnil výsledky

Nejzajímavější závěr z benchmarku není pořadí modelů. Je to způsob, jakým se mění optimální prompt strategie podle velikosti modelu.

U nejmenších modelů pomáhá jednoduchost

Modely pod přibližně 500M parametrů — Gemma 3 270M, Granite 4.0 350M a H 350M — měly nejlepší výsledky s baseline promptem. Strukturovaný CO-STAR nebo POML prompt situaci nezlepšil, u Gemmy 3 270M ho naopak výrazně zhoršil:

• Gemma 3 270M, baseline: 36,36 %
• Gemma 3 270M, CO-STAR: 24,24 %

Pravděpodobný důvod: model s omezenou kapacitou musí při strukturovaném promptu věnovat část pozornosti parsování formátu, místo aby ji celou soustředil na klasifikaci. Zároveň tyto modely nebyly dostatečně doladěny na instrukční formáty, takže CO-STAR tagy mohou fungovat jako šum, ne jako signál.

Kolem 0,8B se CO-STAR začíná vyplácet

Qwen 3.5 0.8B je prvním modelem v sadě, kde CO-STAR jednoznačně pomáhá:

• baseline: 60,61 %
• CO-STAR: 84,85 %

Totéž platí pro Granite 4.0 H 1B, kde CO-STAR zvýšil accuracy z 87,88 % na 93,94 %. Model v tomto rozsahu má dost kapacity, aby instrukci v CO-STAR formátu spolehlivě interpretoval jako řídící signál, ne jako součást vstupního textu.

Kolem 2B POML dosahuje srovnatelné přesnosti jako CO-STAR

U Qwen 3.5 2B dosáhly CO-STAR i POML shodně 100 % accuracy. POML jako samostatná metoda je tedy kompetitivní, ale při vyšší latenci. Pro routing to znamená, že CO-STAR zůstává praktičtější volbou. Pro modely s více než 2 miliardami parametrů doporučuji s oběma metodami experimentovat pro různé typy použití.

POML+CO-STAR konzistentně snižoval výsledky

Kombinace obou formátů v jednom promptu se ve srovnání s nejlepší samostatnou variantou neosvědčila. Příklady:

• Qwen 3.5 2B: CO-STAR 100 % → POML+CO-STAR 63,64 %
• Granite 4.0 H 1B: CO-STAR 93,94 % → POML+CO-STAR 69,70 %
• Marco-Nano-Instruct: baseline/CO-STAR 90,91 % → POML+CO-STAR 27,27 %

Pro krátkou label-only klasifikační úlohu kombinace přidává příliš mnoho strukturální komplexity. Nelze říct, že tato kombinace je obecně špatná pro jiné typy úloh — ale pro routing tento přístup nefungoval.

Poznámka k Gemma 4 26B A4B

Gemma 4 26B A4B je reasoning model, který v defaultním nastavení vrátil 100 % invalid výstupů — finální label byl součástí reasoning bloku, nikoliv message.content. Po nastavení thinking_budget_tokens=0 dosáhla baseline i CO-STAR 100 % accuracy, přičemž baseline byla rychlejší (1 008,5 ms). To je důležitý praktický poznatek: reasoning modely vyžadují explicitní nastavení inference režimu pro routing úlohy, jinak jsou nepoužitelné bez ohledu na jejich schopnosti. Tento model není vhodný pro integrovanou grafickou kartu, proto byla inference realizována na dedikované grafické kartě RX 6800.

Praktická doporučení

Limity tohoto benchmarku

Výsledky jsou slibné, ale je důležité být přesný v tom, co benchmark hodnotí a co ne:

• Dataset má 33 případů a 6 tříd. To je vhodné pro rychlý lokální experiment, ale slabé pro definitivní veřejné závěry.
• Každý model byl spuštěn s repetitions=1. Při temperature=0 to snižuje volatilitu, ale neověřuje robustnost vůči runtime variabilitě.
• Benchmark hodnotí exact-match label. Model, který vrátí jiný formát nebo vysvětlení, je penalizován jako invalid — správně pro router, ale nehodnotí obecné schopnosti.
• Některé nulové výsledky (Granite 4.0 1B, MiniCPM-S-1B) jsou pravděpodobně kompatibilitní problém, ne důkaz obecné slabosti modelu.
• Nejsou měřeny RAM/VRAM footprint, spotřeba energie ani CPU-only režim.

Pro robustnější závěry by bylo potřeba: větší a vyváženější dataset, bootstrap confidence intervaly, per-class recall a opakování v CPU-only režimu pro přenosná zařízení.

Závěr

Nejzajímavější zjištění není, který model vyhrál. Podstatnější je, že malé modely se chovají kvalitativně odlišně podle velikosti — a promptovací strategie, která funguje u 2B modelu, může u 270M modelu situaci aktivně zhoršit.

Pod 500M parametrů: jednoduchý baseline prompt je obvykle optimální. Přidaná struktura spíš zvyšuje kognitivní zátěž, než aby pomáhala.

Kolem 0,8–1B: CO-STAR začíná být efektivní. Model má dost kapacity na instrukční formát, ale ještě ne na složitější struktury.

Kolem 2B: CO-STAR i POML dosahují srovnatelné přesnosti. Pro routing s minimální latencí je CO-STAR praktičtější.

Lokální inference tedy není jen otázka, kolik tokenů za sekundu model vygeneruje. Je to otázka, jak malý model ještě dokáže spolehlivě držet instrukci, formát výstupu a rozhodovací hranici mezi podobnými třídami.