O čem je řeč

V únoru 2026 tým Samsung Research (Hyochan Chong, Dongkyu Kim, Changdong Kim, Minseop Choi) publikoval paper popisující NanoQuant — metodu post-training kvantizace (PTQ), která dokáže komprimovat váhy velkých jazykových modelů na 1 bit a méně. Ne jako marketingový trik s hvězdičkou a poznámkou pod čarou, ale jako funkční framework s měřitelnými výsledky na standardních benchmarcích.

Proč je to zajímavé: dosavadní PTQ metody (GPTQ, AWQ, QuIP, AQLM) fungují spolehlivě na 3–4 bitech na váhu. Pod touto hranicí se rozpadají. Kdo chtěl jít níže, musel sáhnout po QAT (quantization-aware training) metodách jako LittleBit nebo DBF, které ale vyžadují výrazně víc dat, výpočetního času a často i přístup k trénovacímu pipeline modelu. NanoQuant tuhle mezeru překlenuje — dosahuje komprese srovnatelné s QAT, ale s efektivitou a jednoduchostí PTQ.

NanoQuant jednoduše: 70B model na herní grafice

Co je sub-1-bit kvantizace a proč na tom záleží

Představ si, že máš knihu, která má 138 000 stránek. Je v ní všechno — umí odpovídat na otázky, překládat, psát texty. Problém je, že potřebuješ obrovskou knihovnu, aby se ti tam vešla. Normální člověk si ji domů nedá.

Kvantizace je v podstatě způsob, jak tu knihu přepsat menším písmem. Místo toho, aby každé číslo v modelu (a těch jsou miliardy) zabíralo 16 pozic přesnosti, řeknete — stačí mi 4. Nebo 2. Model je pak menší, ale pořád rozumně funguje. Tohle se dělá běžně a funguje to dobře až do určité hranice.

NanoQuant jde dál. Řekne — stačí mi méně než jedna pozice na číslo. To zní absurdně, protože jedna pozice znamená jen dvě možnosti: plus nebo minus. Méně než jedna pozice by znamenalo, že ani to plus/minus nemáte pro každé číslo zvlášť.

Jak to udělají? Místo toho, aby každé číslo komprimovali samostatně, vezmou celou tabulku čísel a rozloží ji na několik menších tabulek, kde jsou jen jedničky a minus jedničky. Ty menší tabulky se pak vynásobí a dají dohromady přibližně totéž co originál. A protože ty menší tabulky jsou menší než originál, průměrně vychází méně než jeden bit na původní číslo.

Výsledek: model, který normálně zabírá 138 GB a potřebuje dvě profesionální grafické karty za statisíce, se smrskne na 5,35 GB a běží na běžné herní grafice za pár tisíc. A pořád dává rozumné odpovědi.

Háček je v tom, že tohle zatím existuje jen jako vědecký článek. Kód není veřejný, nemůžete si to stáhnout a zkusit. Ale ukazuje to směr — modely, které dnes potřebují serverovnu, by za rok nebo dva mohly běžet na normálním počítači nebo i na telefonu.

Zdroj: NanoQuant — arxiv.org/abs/2602.06694

Problém: proč je sub-1-bit komprese těžká

Standardní kvantizace funguje tak, že se každá váha zaokrouhlí na nejbližší hodnotu z omezeného počtu úrovní. Při 4 bitech máte 16 úrovní, při 2 bitech 4 úrovně. Při 1 bitu máte dvě: +1 a −1. To je brutální ztráta informace.

Existující PTQ metody na tomhle selhávají ze dvou důvodů:

1. Nemají dostatečně sofistikovaný způsob, jak rozhodnout, která váha bude +1 a která −1, aby výsledný model stále dával smysl.
2. Některé metody technicky tvrdí, že komprimují na 1 bit, ale pak si "berou zpět" paměť přes pomocné struktury — škálovací faktory, lookup tabulky, metadata — takže skutečný paměťový otisk je výrazně vyšší.

QAT metody tenhle problém řeší přetrénováním modelu s kvantizačním šumem jako součástí tréninkového procesu. Funguje to, ale vyžaduje to stovky tisíc až miliony kalibračních tokenů, desítky GPU hodin a přístup k tréninkovému pipeline.

Jak NanoQuant funguje

NanoQuant reformuluje celý problém kvantizace. Místo zaokrouhlování jednotlivých vah na binární hodnoty rozkládá váhovou matici na součin nízko-rankových binárních matic a škálovacích faktorů. Matematicky: matice vah W se aproximuje jako součin binárních matic (obsahujících pouze +1 a −1) a diagonálních škálovacích vektorů.

Pokud má původní matice rozměr m×n a rank rozkladu je r, potřebujete r×(m+n) binárních hodnot plus škálovací parametry. Při dostatečně nízkém r klesne průměrný počet bitů na váhu pod 1.0.

Tříkrokový pipeline

Komprese probíhá po blocích modelu (transformer block po bloku) ve třech krocích:

Krok 1 — Mitigace propagace chyb. Kvantizační chyba se akumuluje, jak rekonstrukce postupuje sítí. Před kvantizací aktuálního bloku se jeho full-precision váhy doladí tak, aby kompenzovaly chyby zavedené kvantizací předchozích bloků. Tohle není nový nápad — podobný přístup používají i AQLM nebo QuIP — ale NanoQuant ho aplikuje na všechny lineární vrstvy v bloku, ne jen na vybrané.

Krok 2 — Inicializace binární faktorizace (LB-ADMM). Tady je jádro celé metody. NanoQuant používá ADMM (Alternating Direction Method of Multipliers) pro řešení kombinatorického problému: jaká kombinace binárních matic a škálovacích faktorů nejlépe aproximuje původní váhy? ADMM iterativně střídá řešení dvou podproblémů — optimalizaci spojitých škálovacích parametrů (uzavřená forma, least-squares) a projekci na binární omezení (sign operace). Celý postup je "Hessian-aware", tedy bere v úvahu citlivost výstupu na jednotlivé váhy.

Autoři experimentálně ukázali, že LB-ADMM inicializace překonává inicializační schémata z LittleBit i DBF. Jejich hypotéza: vyřešit kombinatorický problém binární faktorizace před fine-tuningem poskytuje stabilnější optimalizační krajinu než přístupy, které inicializaci řeší přibližně a spoléhají na to, že ji gradientová optimalizace dotáhne.

Po ADMM následuje magnitude balancing — vyrovnání škálovacích faktorů, aby binární matice měly vyvážený rozsah.

Krok 3 — Zpřesnění faktorizovaných komponent. Po inicializaci se binární matice a škálovací faktory dolaďují pomocí Straight-Through Estimatorů (STE). STE je standardní trik pro gradientovou optimalizaci přes diskrétní operace — při zpětném průchodu se gradient sign funkce nahradí identitou. Toto zpřesnění probíhá lokálně na úrovni bloku, ne globálně.

Na závěr celého procesu přichází model-level rekonstrukce: lehká kalibrace škálovacích faktorů přes celý model pro lepší globální zarovnání aktivací.

Co znamená "sub-1-bit"

Pojem sub-1-bit může znít jako protimluv — jak můžete mít méně než jeden bit informace na váhu? Odpověď je v tom, že nízko-rankový rozklad sdílí informaci mezi váhami. Binární matice v rozkladu jsou menší než původní váhová matice, takže celkový průměrný počet bitů na váhu (bits per weight, BPW) klesne pod 1.0.

NanoQuant demonstroval výsledky na 0.8 BPW, tedy méně než jeden bit na váhu v průměru. Při tomhle kompresním poměru samozřejmě dochází k degradaci kvality — ale ta je měřitelná a v kontextu 70B modelů stále překvapivě nízká.

Čísla

Tady to přestává být akademické cvičení a začíná to být prakticky relevantní:

• Llama2-70B: komprese ze 138,04 GB na 5,35 GB — kompresní poměr 25,8×
• Inference: kvantizovaný 70B model běží na spotřebitelské 8GB GPU rychlostí až 20,11 tokenů/s
• Kalibrace: 128 vzorků (~0,26M tokenů), 1 GPU
• Čas komprese: ~13 hodin na jednom H100 pro Llama2-70B
• CUDA kernely: autoři implementovali vlastní binární GEMV/GEMM kernely optimalizované pro datacenter, spotřebitelské i edge GPU

Pro srovnání: Llama2-70B v FP16 vyžaduje minimálně 140 GB VRAM, tedy dvě A100 80GB. NanoQuant ho nacpe na jednu RTX 4060 s 8 GB.

Autoři testovali na rodinách modelů Llama2, Llama3, Qwen3 a dalších. Napříč modely NanoQuant vytváří novou Pareto frontu v prostoru komprese vs. kvalita — tedy pro danou úroveň komprese dosahuje lepší kvality než kterákoliv jiná PTQ metoda.

Kontext: co existuje kolem

NanoQuant není v izolaci. Celá oblast sub-1-bit kvantizace LLM se v posledním roce výrazně zahustila:

LittleBit (Samsung Research / NeurIPS 2025) — QAT metoda, která jde až na 0.1 BPW. Používá SVD-inspirovanou latentní faktorizaci s multi-scale kompenzací. Dosahuje skvělých výsledků, ale vyžaduje přetrénování.

DBF / Double Binary Factorization (Boža & Macko, 2025) — Rozkládá váhové matice na součin dvou binárních matic s diagonálním škálováním. Inference je efektivní (jen sčítání místo násobení), ale škálovací parametry jsou příliš omezené — všechny rankové komponenty sdílejí stejný magnitudový profil.

MDBF / Multi-Envelope DBF (prosinec 2025) — Rozšíření DBF, které nahrazuje jednoduché škálování rank-l obálkou. Zlepšuje perplexitu i zero-shot přesnost oproti DBF při stejném BPW.

BTC-LLM (květen 2025) — Používá naučitelné transformace a binární codebooky místo přímé binarizace.

HBLLM — Waveletová dekompozice pro vylepšenou 1-bit kvantizaci s frekvence-aware seskupováním.

NanoQuant se od těchto metod odlišuje tím, že je čistě PTQ — nepotřebuje přetrénování — a přesto dosahuje konkurenceschopné kvality. To je prakticky zásadní rozdíl, protože PTQ můžete aplikovat na libovolný model bez přístupu k trénovacím datům nebo pipeline.

Současný stav projektu

Na rovinu: k dnešnímu dni (duben 2026) je NanoQuant čerstvý research paper bez veřejně dostupného kódu.

• Paper: publikován 6. února 2026 na arXiv, necelé dva měsíce starý
• Kód: zatím nevydaný. Autor na Hugging Face napsal: "We are working on open-sourcing the code, so please stay tuned!"
• Kvantizované modely / checkpointy: nejsou k dispozici. Na otázku po checkpointech autor zatím neodpověděl.
• Vlastní CUDA kernely: zmíněny v paperu, ale rovněž nejsou veřejné

Jde o výzkum Samsung Research, takže open-source release může trvat déle kvůli interním schvalovacím procesům. Autor Hyochan Chong se v únoru 2025 vrátil do Samsung Research po dokončení studia a NanoQuant je jeden ze dvou paperů, které publikoval v únoru 2026 (druhý je RaBiT — 2-bit QAT metoda).

Co to znamená pro praxi

Než se kód uvolní, NanoQuant zůstává akademický výsledek. Ale i jako takový naznačuje směr:

Pro edge nasazení: Pokud se sub-1-bit formáty dostanou do mainstreamových inference frameworků (llama.cpp, vLLM, TensorRT-LLM), otevírá se možnost provozovat modely třídy 70B na hardware, kde dnes sotva běží 7B. To je relevantní pro kohokoliv, kdo provozuje lokální LLM inference na omezeném hardware — Raspberry Pi, jednočipové GPU, mobilní zařízení.

Pro GGUF ekosystém: Zatím žádná podpora. NanoQuant vyžaduje vlastní binární CUDA kernely, takže integrace do llama.cpp by znamenala portovat tyhle kernely na CPU/Metal/Vulkan backendy. To není triviální, ale komunita kolem llama.cpp už v minulosti portovala i složitější formáty.

Pro kvalitu vs. komprese trade-off: NanoQuant ukazuje, že Pareto fronta se posouvá. Před rokem byl sub-1-bit režim terra incognita pro PTQ. Teď máme měřitelné výsledky, které říkají, že 70B model komprimovaný na 5,35 GB stále dává rozumné výstupy. To mění kalkulaci pro deployment.

Stojí za to sledovat autorův profil a Samsung Research na Hugging Face. Jakmile se kód uvolní, bude to jeden z nejzajímavějších frameworků k otestování.

Reference a zdroje

• NanoQuant paper (arXiv): arxiv.org/abs/2602.06694
• Hugging Face paper page: huggingface.co/papers/2602.06694
• Samsung Research na Hugging Face: huggingface.co/SamsungResearch
• Profil autora (Hyochan Chong): d7chong.github.io
• Blog-style summary (alphaXiv): alphaxiv.org/overview/2602.06694v1
• LittleBit (Samsung Research): research.samsung.com/blog/LittleBit-Ultra-Low-Bit-Quantization-via-Latent-Factorization
• DBF — Double Binary Factorization: arxiv.org/abs/2505.11076
• MDBF — Multi-Envelope DBF: arxiv.org/abs/2512.24545
• BTC-LLM: arxiv.org/abs/2506.12040
• RaBiT (další paper od stejného autora): huggingface.co/papers — RaBiT: Residual-Aware Binarization Training

Dokument vytvořen: Duben 2026

The post NanoQuant: Post-training kvantizace LLM pod hranici jednoho bitu first appeared on Hard Wired.

Průvodce modely Claude od Anthropic

Úvod

Anthropic je americká firma, která se zabývá vývojem bezpečné AI - jejich hlavní produkt je rodina jazykových modelů Claude, v současnosti jedny z nejpokročilejších AI asistentů na trhu, které mají tři hlavní úrovně: Opus, Sonnet a Haiku. Když jsem poprvé začal s těmito modely pracovat, upřímně jsem nevěděl který kdy použít - všechny vypadaly podobně, ale rozdíly v kvalitě výstupu a ceně byly obrovské. V tomhle článku si projdeme co který model umí, kdy ho použít a proč, a sdílím zkušenosti z reálných projektů kde jsem každý z nich testoval.

Architektura rodiny Claude

Anthropic postavil třístupňovou hierarchii modelů, kde každá úroveň má svoje místo:

Všechny modely používají Constitutional AI framework pro bezpečnost a mají kontextové okno 200 000 tokenů (zhruba 150 000 slov), což v praxi znamená že můžeš nahrát celou kódovou bázi menšího projektu nebo technickou knihu a model si pamatuje všechno. Novější verze Opus a Sonnet nabízejí experimentální podporu až 1 milion tokenů - zkoušel jsem to s kompletní dokumentací ESP-IDF frameworku a fungovalo to překvapivě dobře, i když latence byla znatelně vyšší.

Claude Opus — hluboký myslitel

Co je Opus?

Opus je top tier model od Anthropic - navržený pro úlohy kde potřebuješ hluboké analytické uvažování, komplexní vícekrokové plánování, pokročilé programování a refaktoring, nebo práci s rozsáhlými kontexty jako jsou celé knihy nebo velké kódové báze. Když jsem poprvé testoval Opus na code review komplexní Flask aplikace s asynchronními tasky a Celery workers, byl jsem fascinovaný tím, jak model dokázal propojit souvislosti mezi moduly které byly od sebe vzdálené stovky řádků kódu a identifikovat potenciální race condition, kterou jsem já sám přehlédl.

Kdy použít Opus?

Ideální scénáře:

1. Code review před nasazením — Opus zachytí subtilní chyby jako memory leaky, async bugy nebo chybějící dispose volání, které ostatní modely přehlédnou
2. Architektonická rozhodnutí — Při návrhu systémové architektury nebo rozsáhlém refaktoringu
3. Výzkum a analýza — Sumarizace celých knih, analýza právních dokumentů, finanční modelování
4. Agentické workflow — Dlouhodobé autonomní úlohy vyžadující vícekrokové uvažování

Praktický příklad

Scénář: Máš komplexní Flask aplikaci s 50+ soubory a potřebuješ identifikovat 
bezpečnostní zranitelnosti.

Proč Opus: Model dokáže udržet kontext celé aplikace, propojit souvislosti mezi 
moduly a identifikovat zranitelnosti typu race condition nebo injection attacks, 
které vyžadují pochopení toku dat napříč celým systémem.

Cena

Opus 4.5 přinesl výrazné zlevnění oproti předchozím verzím (Opus 4/4.1 stál $15/$75), což zpřístupnilo prémiovou inteligenci širšímu spektru uživatelů - upřímně, při těch starých cenách jsem Opus používal jen na kritické review před nasazením do produkce, protože každý delší prompt stál dost peněz. Teď s novými cenami je to mnohem dostupnější, i když pořád ne na každodenní použití pokud máš omezený budget.

Claude Sonnet — spolehlivý kolega

Co je Sonnet?

Sonnet je vyvážený model - kombinuje vysokou inteligenci s rozumnou rychlostí a cenou, což z něj dělá ideální volbu pro většinu každodenní práce. Většina vývojářů tráví s tímhle modelem nejvíc času, a já nejsem výjimka - odhadem 80 % mých promptů jde na Sonnet, protože pro běžné programování, refaktoring nebo psaní dokumentace je naprosto dostačující a odpovídá rychle.

Kdy použít Sonnet?

Ideální scénáře:

1. Každodenní programování — Vývoj funkcí, práce s více soubory, správa stavu, připojení k API
2. Analýza a reporting — Strukturované analýzy, Q&A s dokumenty, vytváření reportů
3. Kreativní úlohy — Psaní obsahu, copywriting, technická dokumentace
4. Orchestrace agentů — Sonnet vytvoří plán a rozdělí úkoly pro Haiku instance

Praktický příklad

Scénář: Vyvíjíš React aplikaci s Tailwind CSS a potřebuješ implementovat
autentizaci s Firebase.

Proč Sonnet: Model zvládne multi-file logiku, správu stavu (Riverpod, Redux),
připojení k Firebase a generuje čistý, použitelný kód. Má vynikající výkon
v oblasti frontend/UI vývoje a generuje „pixel-perfect layouts".

Osobní zkušenost: Když jsem dělal redesign jednoho projektu s Flutter a Material 3,
Sonnet mi vygeneroval kompletní theme configuration včetně custom color schemes
a typography - kód fungoval na první pokus, což mě docela překvapilo protože
Material 3 API je dost komplexní a čekal jsem že budu muset něco ladit.

Cena

Sonnet nabízí výkon blížící se Opusu za zlomek ceny, což z něj dělá optimální volbu pro 90 % produkčních úloh - a tady je důležité si uvědomit že rozdíl mezi Sonnetem a Opusem není vždycky tak velký jak by se podle ceny mohlo zdát, takže pokud nejdeš do opravdu komplexních analýz nebo kritického code review, Sonnet ti bude stačit.

Claude Haiku — rychlý sprinter

Co je Haiku?

Haiku je nejrychlejší a nejlevnější model v rodině Claude - optimalizovaný pro minimální latenci (odpovědi pod sekundu), vysoký objem dotazů a nákladovou efektivitu. Upřímně, nejdřív jsem Haiku podceňoval a myslel si že je to jen "levná verze" pro lidi co chtějí ušetřit, ale když jsem ho začal používat na rychlé prototypování UI komponent, zjistil jsem že pro tento konkrétní use case je vlastně lepší než Sonnet - odpovídá skoro okamžitě a pro jednoduchý layout kód je kvalita naprosto dostačující.

Kdy použít Haiku?

Ideální scénáře:

1. Chatboti a zákaznická podpora — Real-time odpovědi bez čekání
2. UI prototypování — Rychlé generování layoutů a komponent
3. Klasifikace a moderace obsahu — Vysokoobjemové úlohy
4. Paralelní provádění subtasků — V orchestrovaném workflow s Sonnetem

Praktický příklad

Scénář: Potřebuješ rychle vytvořit Flutter screen s Material 3 designem.

Proč Haiku: Model vygeneruje layout téměř okamžitě. Pro brainstorming a rychlé
prototypy je ideální volbou. Ale pozor — v delších sessions „ztrácí nit"
a není vhodný pro komplexní logické stavby.

Osobní zkušenost: Zkoušel jsem s Haiku dělat složitější state management
s Riverpod providers a po třech čtyřech iteracích začal generovat kód který
nedával smysl - zapomínal na kontext z předchozích promptů a navrhoval řešení
která byla v rozporu s tím co jsme dělali předtím. Pro jednoduché úlohy super,
ale na komplexní logiku radši Sonnet.

Cena

Haiku je 5× levnější než Opus na vstupních tokenech, což z něj dělá ekonomickou volbu pro vysokoobjemové scénáře - pokud děláš chatbota nebo zákaznickou podporu kde potřebuješ zpracovat tisíce dotazů denně, rozdíl v ceně mezi Haiku a Sonnetem se rychle nasčítá na stovky dolarů měsíčně.

Srovnávací tabulka modelů

Orchestrační workflow — jak modely kombinovat

Když pracuješ na větším projektu, dává smysl kombinovat modely podle jejich silných stránek - tohle je něco co jsem se naučil až po pár měsících práce s Claude, protože na začátku jsem používal jen Sonnet na všechno a nevěděl jsem že můžu ušetřit čas i peníze tím že rozdělím úlohy mezi modely strategicky.

Fáze 1: Plánování (Sonnet)

Sonnet analyzuje požadavky, navrhuje architekturu a rozděluje úkoly na paralelizovatelné podúlohy.

Fáze 2: Implementace (Haiku)

Více instancí Haiku provádí subtasky paralelně — scaffolding, komponenty, API integrace.

Fáze 3: Review (Opus)

Před mergem provede Opus hlubokou revizi — zachytí async bugy, memory leaky a subtilní logické chyby.

Příklad z praxe:

Developer pracuje na mobilní aplikaci:
1. Používá Haiku pro rychlé UI prototypy
2. Přepne na Sonnet pro implementaci business logiky
3. Před releasem nechá Opus udělat finální code review

Výsledek: Opus odhalil rebuild issues a chybějící disposes,
které Haiku i Sonnet přehlédly.

Moje zkušenost: Přesně tenhle workflow jsem použil na jednom Flutter projektu
kde jsem dělal aplikaci pro správu IoT zařízení. Haiku mi vygeneroval asi 15
různých screen layoutů za pár minut, Sonnet implementoval komunikaci s MQTT
brokerem a state management, a Opus pak při finálním review našel memory leak
v subscription handleru který by v produkci způsobil problémy - model si všiml
že StreamSubscription není správně disposed při dispose() widgetu, což by
vedlo k postupnému nárůstu paměti. Tohle by Sonnet pravděpodobně přehlédl.

Rozhodovací strom: Který model zvolit?

START
  │
  ├── Je úloha časově kritická (real-time)?
  │     └── ANO → HAIKU
  │
  ├── Je to rutinní práce (coding, analýza, psaní)?
  │     └── ANO → SONNET
  │
  ├── Vyžaduje hluboké uvažování nebo rozsáhlý kontext?
  │     └── ANO → OPUS
  │
  ├── Je to finální review před nasazením?
  │     └── ANO → OPUS
  │
  └── Nejste si jistí?
        └── Začněte se SONNET, eskalujte na OPUS při potřebě

Cenové předplatné pro běžné uživatele

Pro ty, kteří nepoužívají API, nabízí Anthropic předplatné:

Praktické tipy pro optimalizaci nákladů

1. Začni s Haiku, eskaluj nahoru

Pro většinu dotazů postačí Haiku - na Sonnet nebo Opus přepni pouze pro složitější úlohy, což ti ušetří peníze a zároveň nezpomalí workflow, protože Haiku odpovídá tak rychle že rozdíl v latenci je znatelný.

2. Využij Prompt Caching

Při opakovaném dotazování na stejný kontext (např. velký dokument) snížíš náklady až o 90 % - tohle je obrovská úspora pokud pracuješ s rozsáhlou kódovou bází nebo dokumentací, protože model si cachuje kontext a při dalších dotazech ho nemusí znovu zpracovávat. Zkoušel jsem to s dokumentací k ESP-IDF a rozdíl v ceně byl dramatický - první prompt stál normálně, ale následující dotazy byly skoro zadarmo.

3. Batch API pro neurgentní úlohy

Asynchronní zpracování přes Batch API poskytuje 50% slevu na tokeny.

4. Optimalizuj prompty

Každý token stojí peníze. Odstraň zbytečný kontext a buď konkrétní.

Závěr

Každý model v rodině Claude má svoje místo:

• Opus je senior architekt — pomalejší, ale nejspolehlivější pro kritické rozhodnutí a hluboké analýzy
• Sonnet je spolehlivý kolega — zvládne 90 % každodenní práce kvalitně a efektivně, což z něj dělá můj go-to model
• Haiku je rychlý junior — ideální pro opakované úlohy a prototypování, překvapivě schopný pokud víš jak ho použít

Nejde o to používat jeden model na všechno. Jde o to strategicky kombinovat jejich silné stránky podle toho, co zrovna potřebuješ - a tohle pochopení přišlo až s praxí, protože na začátku jsem dělal chybu že jsem používal Sonnet i na úlohy kde by Haiku stačil, nebo naopak jsem se snažil ušetřit a používal Sonnet na code review kde by Opus odvedl mnohem lepší práci. Teď po několika měsících práce s těmito modely mám docela dobrý cit kdy který použít, a doufám že tento článek ti pomůže zkrátit tu learning curve.

Zdroje a další čtení

• Anthropic dokumentace
• Claude.ai
• API cenový přehled

Pro opravu diakritiky a překlepů byl použit model Claude Sonnet 4.5.

Článek aktualizován: březen 2026

The post Průvodce modely Claude od Anthropic first appeared on Hard Wired.