Lokální model může odpovídat, i když většinu práce odvádí procesor a grafika se jen veze. Šest měření níže ukáže, jak ověřit offload vrstev, vytížení CPU, spotřebu RAM i diskové I/O.
Po instalaci Ollamy, LM Studia nebo llama.cpp stačí stáhnout model a spustit příkaz. Problém je, že odpověď v terminálu nic neříká o tom, zda výpočet skutečně běží na grafické kartě. Model se totiž může načíst do systémové RAM, část vrstev nechat na CPU a GPU využít jen minimálně. Následujících šest měření oddělí skutečnou akceleraci od zdánlivě funkčního běhu.
První měření není o procentech, ale o tom, komu máte procenta přiřadit. U Ollamy spusťte ollama ps; sloupec PROCESSOR ukáže, zda model běží na GPU, CPU, nebo rozděleně. Pokud se zobrazí kombinace, není model plně na GPU. U llama.cpp čtěte výstup při startu: řádek llm_load_tensors: offloaded ... layers to GPU říká, kolik vrstev se skutečně přesunulo. V LM Studiu zapněte log a zkontrolujte počet offloadovaných vrstev a runtime. Teprve pak má smysl měřit vytížení.
Na Windows i Linuxu sledujte rodičovský a dítě proces. Ollama často běží jako služba ollama serve, ale výpočet dělá potomek ollama runner. Pokud měříte jen službu, uvidíte nízké CPU a nic. V Process Exploreru nebo ve Správci úloh zapněte strom procesů; na Linuxu použijte ps -ef --forest a pgrep -a ollama.
Na NVIDIA použijte nvidia-smi --query-compute-apps=pid,process_name,used_memory --format=csv. Tím zjistíte, který proces má alokovanou paměť na kartě. Průběžné vytížení sledujte přes nvidia-smi dmon -s pucvmet nebo v grafu GPU v Správci úloh. Na AMD je praktický amdgpu_top nebo radeontop, na Intelu intel_gpu_top. Podstatné je měřit během generování, ne během načítání modelu.
U Windows oddělte „Dedicated GPU memory“ od „Shared GPU memory“. Když model přeteče dedikovanou VRAM, začne se část odehrávat v systémové RAM a výkon padá. To je běžná příčina toho, že GPU je „vytížená“, ale tokeny za sekundu jsou nízké. Sledujte také zaplnění VRAM po dlouhém promptu: KV cache roste s délkou kontextu. Pokud se po zvýšení kontextu změní rozdělení vrstev nebo začne swap, není to problém modelu, ale nastavení.
Celkové vytížení CPU klame. Na Linuxu spusťte top -H -p <PID> nebo pidstat -t -p <PID> 1; uvidíte, která vlákna pracují. Na Windows použijte Process Explorer, záložku Threads, nebo Správce úloh přepnutý na logická jádra. Pokud je při generování jedno jádro na maximum a GPU je klidná, model pravděpodobně běží na CPU nebo se čeká na data.
Měřte zvlášť prefill a generování. Zpracování dlouhého promptu může zatížit CPU jinak než samotné vydávání tokenů. U llama.cpp sledujte počet vláken -t; příliš mnoho vláken na malém modelu přináší režii. U Ollamy se počet vláken nastavuje parametrem num_thread. Pokud CPU zůstává vysoké i po dokončení odpovědi, hledejte jiný proces: indexování, antivirus nebo načítání dalšího modelu.
V Resource Monitoru sledujte u procesu modelu „Working Set“ a „Commit“. Na Linuxu čtěte /proc/<PID>/status, konkrétně VmRSS, VmData a VmSwap, nebo použijte pidstat -r -p <PID> 1. Working set ukazuje fyzicky použité stránky, commit může být vyšší. Rozdíl je důležitý: model může mít rezervovanou paměť, ale nemusí ji celou aktivně používat.
Hard faults nebo major page faults během generování znamenají, že se data tahají z disku. Po prvním načtení modelu mohou být stránky v cache a další běh je rychlejší. Proto měřte první a druhé načtení odděleně. Pokud se hard faults objevují opakovaně při každém tokenu, je pravděpodobné, že RAM nestačí a systém swapuje. To se projeví i na disku.
Na Windows otevřete Resource Monitor, záložku Disk, a sledujte „Disk Queue Length“, „Disk Bytes/sec“ a „Hard Faults/sec“ současně s během modelu. Na Linuxu použijte iostat -x 1, pidstat -d -p <PID> 1 a vmstat 1. Zajímá vás, zda disk čte během generování, nebo jen při startu. Čtení stovek MB při každém dotazu znamená, že model není v RAM nebo se část přelévá do swapu.
U Ollamy a llama.cpp se model často mapuje pomocí mmap. To znamená, že první načtení čte soubor z disku, ale systémová cache ho může držet pro další běh. Pokud chcete měřit čistý dopad, poznamenejte si, kolik dat se přečetlo při prvním a druhém spuštění. Na Windows sledujte také pagefile: při nedostatku RAM roste zápis i čtení a latence odpovědí. Zvýšení swapu není řešení, jen přesun problému.
Šesté měření spojuje hardware s výsledkem. U Ollamy spusťte ollama run --verbose <model>; výstup obsahuje dobu načtení, počet prompt tokenů, počet výstupních tokenů a eval rate. U llama.cpp hledejte výpis llama_perf_context_print s časy prompt eval a eval. Zapište si zvlášť čas do prvního tokenu a tokeny za sekundu. První token ovlivňuje prefill a načtení kontextu, další tokeny závisí na paměťové propustnosti a offloadu.
Měření opakujte při stejném promptu a stejné délce kontextu. Pokud se po zvýšení kontextu zhorší tokeny za sekundu a současně roste VRAM nebo swap, našli jste příčinu. Pokud je GPU vytížená, VRAM stabilní a CPU nízké, model pravděpodobně skutečně běží na kartě. Pokud je to opačně, žádný benchmark v chatovacím okně to nespraví. Sledujte i teploty a clocky: NVIDIA je ukáže v nvidia-smi --query-gpu=temperature.gpu,clocks.sm,clocks.mem,power.draw --format=csv, AMD v amdgpu_top. Teplotní throttling může vypadat jako pomalý model, i když je offload správně.
Foto: Matheus Bertelli / Pexels
Stisk spouště ve tmě spustí řetězec expozic, snímání senzoru, skládání a výpočtů v ISP i NPU. Dva telefony se stejným senzorem mohou dopadnout jinak, protože rozhoduje optika, stabilizace, firmware a algoritmy.
