DGX Spark doma: deník prvních dní s Gigabyte AI TOP Atom

Dnes přišel můj první DGX Spark — konkrétně Gigabyte AI TOP Atom, malá krabička s NVIDIA čipem GB10 a 128 GB sdílené paměti. Sním o něm už dlouho a dnes se mi to konečně vyplnilo. Jelikož ale nemám žádné zkušenosti s Linuxem a mám obavy, jestli to zvládnu vůbec rozchodit, jsem s nadšením opatrná. Nastavení celého stroje jsem svěřila AI agentovi (Fable, model od Anthropicu), tak na něj odevzdaně spoléhám.

Tenhle článek je deník. Najdete v něm, jak vypadají první dny s "AI superpočítačem na stole", když nejste programátor — a dole pak reálná čísla z testů, která by vám mohla pomoct v rozhodování, jestli má takový stroj smysl i pro vás.

Den první: zapojit a nezhasnout byt

Úplně první obava je, co se stane, až to zapojím do zásuvky. Pár měsíců zpátky, když jsem připojovala druhé Mac Studio, v celém bytě nastala tma.

Zapojila jsem ho a na pokyn agenta zmáčkla power button. Cítím se jak blbec a říkám si, zda by spíš nestálo za to naučit se to od základu sama. Stejně na tom nic nebude — to jenom ta obava, že co když udělám nějakou zbytečnou chybu.

Agent mi řekl, že na letáčku v krabici najdu přístupy k dočasné wifi. Dávám mu je a on se tam snaží připojit. A zde dělám hned první chybu — připojuji Spark k brýlím, které mi slouží jako přenosný monitor, abych se podívala, jak mu to jde. Jenže kvůli tomu Spark přestal vysílat svou dočasnou wifi a agent ho neviděl. Poučí mě, vypnu, zapnu a jdeme na to znovu.

Úskalí číhá v tom, že když se počítač připojí k wifi Sparku, odpojí se od naší domácí. Prý to vyřeší skriptem. Trpělivě čekám, ale jsem skeptická. A co očekáváš, to také přijde:

Nakonec si to jdu nastavit sama. A vlastně je to easy — NVIDIA to připravila dokonale. Přihlásím se na adresu, která svítí na obrazovce, vytvořím účet a heslo, připojím ho k domácí wifi a on si sám začne stahovat aktualizace. Trvá to asi 20 minut.

Hotovo. Update dokončen a přesměrovalo mě to na stránku NVIDIE s návody. A že jich dává požehnaně — build.nvidia.com/spark je skvělá práce. Připravené postupy pro první spuštění modelu, agenty i monitoring.

Pak předávám štafetu zpátky agentovi. Jedna ostuda se ještě stihla stát: místo ke Sparku se chvíli snažil přihlašovat k úplně jinému počítači v naší domácnosti. Přišli jsme na to až ve chvíli, kdy se mě ptal, jestli jsem si nespletla heslo. Nakonec vidím na pozadí v jeho příkazech, že přes SSH stahuje první model. Dobrá zpráva!

Počítač začíná hučet. A hřát. A to ještě nic nedělá — což je celkem nezvyk oproti Mac Studiu, které neslyším vůbec. No, myslím, že jdu do Jysku pro nějakou poličku a ze stolu ho přestěhuju.

Test první: Qwen3.6-35B přes llama.cpp

S agentem jsme se dohodli, že prvně otestujeme model Qwen3.6-35B-A3B v kvantizaci Q8 (přesněji UD-Q8_K_XL, GGUF soubor ~37 GB) přes llama.cpp, s kontextem 262 tisíc tokenů a 4 paralelními sloty. llama.cpp jsem zvolila z prostého důvodu: stejný model mi na něm běhal na Mac Studiu s dobrou kvalitou češtiny.

Výsledek pod plnou zátěží:

• 25,9 tokenů/s generování
• prefill (načtení promptu) 132 tokenů/s

Bez zátěže zhruba 33 tokenů/s.

Používám ho na první verze interních textů a podkladů — všechno pak stejně prochází ještě revizí větším modelem, takže svůj účel to plní. Kvalita češtiny je na Q8 v pohodě. Ale je to pomalé. Takže mám chuť zkusit to jinak.

Test druhý: stejný model ve 4 bitech přes vLLM

Druhý pokus: stejný Qwen3.6-35B, ale v kvantizaci NVFP4 (~4 bity, soubor jen 22 GB) přes inferenční server vLLM. NVFP4 je formát, který má čip GB10 zadrátovaný přímo v hardwaru — proto se od něj čekala rychlost.

A rychlost opravdu přišla:

• 71 tokenů/s namísto 33 — tedy 2,15× rychleji
• při 4–5 souběžných požadavcích 170–230 tokenů/s dohromady
• prefill až 4 000 tokenů/s

Jenže jak už 4bitová kvantizace napovídá, čeština šla kouřit. Model začal komolit slova (vymýšlel si tvary, které v češtině neexistují) a hůř dodržoval pokyny. V našem interním hodnocení proti vzorovým výstupům spadl z 11 bodů z 12 na zhruba 7 — a to je rozdíl, který žádná rychlost nezachrání.

Takže jsem to vrátila na llama.cpp s Q8. Pomalejší, ale česky.

Co si z toho odnést, pokud o podobném stroji uvažujete

Tohle jsou poznatky z prvních čtyř dnů testování. Nejsou to laboratorní benchmarky — jsou to čísla z reálné práce na českých textech.

1. Kvantizace pod 8 bitů komolí češtinu. Na anglických benchmarcích to neuvidíte, tam 4bitové modely vychází skvěle. Čeština je ale menšinový jazyk a při agresivní kompresi modelu trpí jako první. Pokud model potřebujete na české texty, počítejte s 8 bity — a tedy s většími nároky na paměť, než uvádí optimistické tabulky.

2. Rychlost není všechno. Server 2× rychlejší je k ničemu, když výstupy potřebují víc oprav. Vždycky měřte kvalitu na vlastních úlohách, ideálně bodovacím systémem proti vzorovým výstupům — ne dojmem "vypadá to dobře".

3. Nevěřte tomu, že přechod mezi servery je "jen výměna". vLLM a llama.cpp mají stejné API jen na papíře. V praxi jsme narazili na drobnosti, které umí rozbít celé automatizované zpracování: vLLM vyžaduje v požadavku pole s názvem modelu (llama.cpp ho ignoruje) a některé kombinace parametrů vzorkování s rychlostními optimalizacemi prostě odmítne.

4. Síla těchhle strojů je v souběhu. Jeden požadavek jede na GB10 pomaleji než na výkonné grafice. Ale při více souběžných požadavcích celková propustnost pěkně roste — a přesně tak se dávková práce s texty dělá.

5. Počítejte s hlukem a teplem. Proti Mac Studiu je to jiná liga. Na stůl vedle sebe bych ho nedávala.

Testy pokračují — co zkusíme dál

Tenhle deník bude mít pokračování, protože jsme zdaleka neskončili:

• FP8 kvantizace přes vLLM — kompromis mezi oběma testy: 8 bitů (čeština by měla přežít) a zároveň rychlost a souběh vLLM. Existuje oficiální FP8 verze přímo od autorů Qwenu.
• Novější verze vLLM (0.25) — přinesla vylepšené spekulativní dekódování, které slibuje další zrychlení. Uvidíme, co z toho zbyde na českých textech.

Průběžné výsledky sem budu přidávat. Pokud vás zajímá něco konkrétního, co bych na tom stroji měla změřit, napište mi.

Časté otázky

Zvládne DGX Spark provozovat velký jazykový model doma?

Zvládne. Model o 35 miliardách parametrů v 8bitové kvantizaci běží pohodlně (zabere ~37 GB ze 128 GB paměti) a zbývá dost místa na dlouhý kontext. Není to rychlost placených API, ale na dávkovou práci to stačí.

Jakou kvantizaci zvolit pro české texty?

Z našich testů: 8 bitů (Q8, případně FP8). Čtyřbitová kvantizace byla 2× rychlejší, ale komolila slova a hůř držela pokyny. Pro angličtinu můžou být 4 bity v pořádku — pro češtinu zatím ne.

Je vLLM rychlejší než llama.cpp?

V našem testu ano, zhruba 2× na jednom požadavku a ještě výrazněji při souběhu. Ale pozor: rozdíl dělala hlavně kvantizace (4 bity vs. 8 bitů), ne jen server samotný. Férové srovnání obou serverů na stejné 8bitové kvantizaci teprve chystáme.

Potřebuji umět Linux, abych něco takového rozchodila?

Upřímně: já ho neumím. Prvotní nastavení zvládne podle mě každý (NVIDIA to má připravené opravdu hezky), instalaci modelů a serverů za mě dělá AI agent. Bez něj bych se ale neobešla — takže úplně bez pomoci bych do toho nešla.

Zdroje