Případová studie: AI workstation se 4x RTX 4090

Tento článek dokumentuje kompletní sestavu, kterou si objednal výzkumný zákazník. Potřeboval inferenční LLM workstation do racku, schopný provozu 24/7 a s dostatkem VRAM pro modely třídy 70B bez závislosti na cloudu. Všechny údaje jsou naměřené na skutečném hardwaru. Žádné syntetické odhady, žádná marketingová čísla.

Sestava byla objednána a dodána v dubnu 2026. Uváděcí benchmarky proběhly 2026-04-10.

Proč 4× RTX 4090

Požadavek na workload byl jasný od začátku: provozovat kvantizovaný 70B LLM s použitelnou latencí u jednotlivého požadavku, obsloužit souběžné požadavky v menším výzkumném týmu a držet vše on-premise kvůli kontrole nad daty. Otázkou bylo, kolik GPU a jakých.

Model 70B v INT4 (AWQ nebo GGUF Q4_K_M) zabere v praxi zhruba 38–40 GB VRAM. To zcela vylučuje řešení s jedinou GPU — ani RTX 4090 s 24 GB model sama neunese. Potřebujete minimálně dvě, lépe čtyři, aby tensor-parallel inference pod vLLM měla rezervu na KV cache.

Čtyři karty RTX 4090 dávají dohromady 96 GB VRAM. To stačí na načtení modelu Llama 3.3 70B AWQ INT4 s gpu_memory_utilization=0.80 a stále zbývá smysluplný prostor pro KV cache u dávkovaných požadavků. Přináší to i výpočetní kapacitu (4× 128 SM běžících současně), která rozhoduje o rychlosti zpracování promptu.

Zvažovanou alternativou byla sestava 4× RTX Pro 6000 Blackwell, která by dala 4× 96 GB = 384 GB VRAM. To je úplně jiná liga: víc VRAM, než jakýkoli jediný 70B model potřebuje, vhodné pro souběžný provoz několika velkých modelů nebo pro hostování modelů třídy 200B+ v rozumné kvantizaci. Pro tento workload — jeden hlavní model, malá souběžná dávka, rozpočet jednouživatelského workstationu — by tato kapacita navíc zůstala nevyužitá a cenový rozdíl je značný. Pro uvedené použití byla správnou odpovědí sestava 4× RTX 4090.

V nabídce existuje i varianta 8× L40. L40 nabízí 48 GB VRAM na kartu, podporu ECC a je navržena pro trvalou zátěž v datacentru. Tento zákazník nepotřeboval smluvní spolehlivost na úrovni datacentra, absence spotřebitelských zvláštností ovladačů u L40 byla jen drobnou výhodou a rozpočet tam nedosáhl. Stojí za to o této cestě upgradu vědět.

Jeden architektonický strop je třeba pojmenovat hned: karty RTX 4090 nemají NVLink. Veškerá komunikace mezi GPU probíhá přes PCIe peer-to-peer. To má význam pro tensor-parallel inferenci (rozebráno v sekci s benchmarky) a je dobré tomu rozumět ještě před objednávkou. Viz N03 pro úplné pojednání o tom, kdy na NVLinku záleží a kdy ne.

Specifikace hardwaru

Několik poznámek k volbě komponent:

CPU. EPYC 7542 je 32jádrový čip generace Rome se 128 MB L3 cache napříč 8 CCD. Pro inferenční workstation je předimenzovaný co do počtu jader — čistou inferencí 64 vláken nevytížíte. Kde si své místo zaslouží, je rozpočet PCIe linek: EPYC Rome poskytuje 128 linek PCIe 4.0 přímo z CPU, díky čemuž lze na této platformě osadit čtyři plné x16 GPU bez sdílení linek nebo bifurkace. RTX 4090 je zařízení PCIe 4.0 x16; chcete čtyři plné sloty x16 a EPYC je dá. Viz W02 pro detaily topologie linek.

RAM. Systém byl dodán s 512 GB DDR4 ECC LRDIMM, což překročilo původně specifikovaných 256 GB. Operační paměť navíc je tu skutečně užitečná: načítání modelu z NVMe jde přes systémovou RAM, než se přenese do VRAM, a u větších modelů nebo při přepínání mezi modely znamená 512 GB, že můžete držet několik sad vah modelů v RAM současně a vyhnout se opakovanému čtení z NVMe.

NVMe. Úložiště modelů (2 TB) je na rychlém disku PCIe 4.0 NVMe. Rychlost sekvenčního čtení se projeví při načítání: soubor modelu o velikosti 38 GB se při 4,589 MB/s sekvenčního čtení načte zhruba za 8–10 sekund. Naměřené časy to potvrzují: llama.cpp načetl 70B Q4_K_M GGUF za 10.8 sekundy; vLLM (který při načtení ještě staví CUDA grafy) potřeboval 95 sekund.

Dva zdroje. Šasi používá dva napájecí zdroje ATX. Jde o rozdělené napájení: každý zdroj napájí část systému — typicky dvě GPU a příslušné komponenty desky. Pokud jeden zdroj selže, přijdete o GPU na jeho větvi. Toto není redundance N+1; je to uspořádání napájecí kapacity, nikoli zajištění failoveru. U produkčních systémů, kde je dostupnost smluvní, na tomto rozdílu záleží. Viz W04 pro kompletní rozbor dimenzování zdrojů.

Proudění vzduchu v šasi. Šasi je určeno do racku a má průmyslové řízené proudění vzduchu zepředu dozadu. GPU nejsou v otevřeném prostoru; sedí v řízeném vzduchovém kanálu, kde ventilátory ženou vzduch přes chladiče a vyfukují jej vzadu ven. Díky tomu je systém vhodný pro trvalý provoz 24/7 v rackovém prostředí. Viz W05 pro detaily tepelného návrhu.

Softwarový stack

Python prostředí se nachází v /home/logic/llm-env/, modely na NVMe v /mnt/nvme/models/.

Výsledky uvedení do provozu

Výchozí výpočetní výkon GPU

První test je vždy čistý výpočet: násobení matic v FP16 (cesta přes Tensor Cores) a FP32. Potvrdí, že karty fungují správně, a dá výchozí hodnotu pro srovnání s nominálními specifikacemi.

Pro srovnání: teoretický špičkový výkon RTX 4090 ve FP16 na Tensor Core je ~330 TFLOPS, FP32 ~82.6 TFLOPS. Naměřené hodnoty na úrovni ~52% špičky FP16 jsou očekávané — měření je matmul s trvalou propustností, který nedosahuje teoretického maxima ručně laděného GEMM kernelu. Potvrzují, že všechna čtyři pole Tensor Cores fungují a jsou konzistentní.

GPU 1 má ve FP16 o ~6% nižší výkon než ostatní. To je běžný rozptyl křemíku v rámci stejného binu. Žádná hardwarová závada.

Propustnost paměti GPU

Propustnost VRAM 920 GB/s odpovídá specifikaci RTX 4090 (špička 1,008 GB/s; rozdíl jde na vrub režii benchmarku). Právě toto číslo rozhoduje o propustnosti dekódování: každý vygenerovaný token vyžaduje načtení celé sady KV cache a tenzorů vah z VRAM, takže propustnost přímo určuje strop rychlosti generování.

Hodnota mezi GPU (19–22 GB/s přes PCIe peer-to-peer) je architektonické omezení, které se týká tensor-parallel inference. S NVLinkem běží tato cesta rychlostí 900 GB/s. Jen přes PCIe dostanete zhruba 2% z toho. Pro inferenci to není katastrofa (většina tensor-parallel komunikace u modelu 70B AWQ INT4 na 4 GPU se do možností PCIe vejde), ale u jednotlivého požadavku to oproti systému s NVLinkem snižuje rychlost dekódování. Viz sekce s benchmarky níže a N03 pro širší diskusi.

Jedna anomálie: propustnost Device-to-Host naměřena na 1.4 GB/s, hluboko pod očekávanými ~26 GB/s pro PCIe Gen4 x16. Jde o známé chování CUDA s nepřipnutou pamětí. Pokud vaše aplikace často přenáší data z GPU na hosta (např. sampling z výstupních logitů ve vlastní pipeline), použijte torch.pin_memory() nebo předalokujte připnuté buffery. Standardní servisní pipeline vLLM a llama.cpp tuto cestu v horké smyčce nespouštějí.

Všechny PCIe linky byly pod zátěží potvrzeny jako Gen4 x16 (16 GT/s). V klidu ovladač používá úsporný režim ASPM a linky klesají na Gen1 (2.5 GT/s) — to je normální, nejde o vadu kabeláže ani riseru.

Úložiště NVMe

Na spotřebitelský/prosumer disk PCIe 4.0 NVMe jsou to silná čísla. Pro servírování modelů je podstatné sekvenční čtení: 4,589 MB/s znamená, že se model o velikosti 38 GB načte do RAM přibližně za 8–9 sekund ještě před přenosem do VRAM. 568K náhodných IOPS je relevantnější, pokud provozujete retrieval pipeline (RAG, vektorová databáze), kde zátěž tvoří mnoho malých náhodných čtení — tento disk to zvládne, aniž by se stal úzkým hrdlem.

Inference ve vLLM — Llama 3.3 70B AWQ INT4

Toto je stěžejní benchmark. Model: casperhansen/llama-3.3-70b-instruct-awq. Servírování: vLLM 0.19.0 s tensor_parallel_size=4, max_model_len=2048, gpu_memory_utilization=0.80.

Rychlost dekódování 8.0 tok/s u jednotlivého požadavku vyžaduje kontext. vLLM 0.19.0 spustil AWQ model s kernelem awq, nikoli s awq_marlin. Kernel awq_marlin je pro AWQ na Ada Lovelace (RTX 4090) a Blackwell rychlejší cestou — z poznámek k benchmarku plyne, že při tomto uváděcím běhu vybrán nebyl, a očekávané zlepšení je 2–3× u rychlosti dekódování jednotlivého požadavku. S awq_marlin by stejný model na stejném hardwaru měl dosáhnout zhruba 16–24 tok/s v jednom proudu.

Souhrnných 179.3 tok/s při 32 souběžných požadavcích je číslo relevantnější pro produkci. Právě to uvidí jako kombinovaný výstup systému menší tým, který na endpoint přistupuje současně. Kontinuální dávkování ve vLLM znamená, že souběžné požadavky sdílejí náklady na KV cache a výpočet pozornosti napříč dávkou — proto 32× více uživatelů neznamená 32× vyšší latenci.

Latence 2,043 ms u požadavku na 16 tokenů je spodní hranicí TTFT (time-to-first-token) pro vLLM v této konfiguraci. Pro interaktivní scénáře (chat, asistence při psaní kódu) je to spíše pomalejší. Hlavní příčinou je režie tensor-parallel scatter/gather mezi čtyřmi GPU přes PCIe — každý krok prefillu vyžaduje AllReduce napříč všemi čtyřmi kartami po PCIe. S NVLinkem by TTFT byl zhruba 50–100 ms; s PCIe P2P při 20 GB/s se protáhne ještě víc. To je přímá daň architektury bez NVLinku u jednotlivých požadavků citlivých na latenci (viz N03).

llama.cpp — Llama 3.3 70B Q4_K_M GGUF

Model: Llama-3.3-70B-Instruct-Q4_K_M.gguf. Backend: llama-cpp-python 0.3.20 s CUDA/cuBLAS, všechny vrstvy přeneseny na GPU.

llama.cpp dodává zhruba 20 tok/s při dekódování v jednom proudu — lépe než současné číslo vLLM s AWQ, což lze přičíst tomu, že cuBLAS kernel v llama.cpp si s kvantizací Q4_K_M dobře rozumí. llama.cpp nepodporuje souběžné dávkování více požadavků tak jako vLLM, takže 20 tok/s je strop na jednu relaci, ne souhrnná kapacita. Pro interaktivní práci jednoho uživatele je 20 tok/s pohodlná rychlost čtení u anglického výstupu.

Rychlost zpracování promptu 1,568 tok/s je vysoká. Měří, jak rychle model pojme prompt (fáze prefill). Rychlý prefill se hodí, když model pracuje s dlouhými systémovými prompty nebo kontextem dokumentů. Při 1,568 tok/s se kontext dokumentu o 4,000 tokenech zpracuje za méně než 3 sekundy, než začne generování.

Ekonomiku a srovnání s cloudovými alternativami najdete v T01 (tok/s na euro) a T02 (náklady na milion tokenů on-premise vs. cloud).

K čemu slouží každý z obou enginů

Zátěžový test — trvalá zátěž

Proběhly tři 60sekundové zátěžové testy, které měly ověřit tepelnou a elektrickou stabilitu při maximální zátěži: zátěž jen na GPU, jen na CPU a kombinovaná GPU+CPU.

Zátěž GPU (násobení matic FP16 na 100%, 60 s)

Napříč všemi čtyřmi GPU nula výpočetních chyb. Teploty stouply z výchozích ~28°C na stabilní úroveň do 40. sekundy. Nejtepleji běžela GPU 2 na 72°C — na této pozici je v proudu vzduchu šasi nejteplejší kartou. Práh tepelného omezení u RTX 4090 je 83°C; nejvyšší naměřená teplota (72°C) nechává rezervu 11°C. Systém v žádném okamžiku takty neomezoval.

Limity příkonu byly na čtyřech kartách nastaveny různě (480 W, 450 W, 500 W, 480 W). Jde o drobnou nekonzistenci, kterou je vhodné sjednotit: nvidia-smi -pl 480 -i 0,1,2,3 (nebo jakýkoli vhodný limit) nastaví jednotné hodnoty ještě před produkčním nasazením.

Kombinovaná zátěž GPU + CPU (všechny 4 GPU + 64 vláken CPU současně, 60 s)

Přidání 64 vláken CPU při 100% zátěži snížilo souhrnný výkon GPU v TFLOPS jen o 0.6%. EPYC 7542 odebírá při plné zátěži zhruba 200 W TDP; celý systém běžel přibližně na 2.1–2.2 kW. Všechny teploty zůstaly v rezervě: GPU 2 dosáhla při kombinované zátěži 73°C, stále 10°C pod prahem omezování.

Load average během fáze zátěže CPU vystoupal nad 55 (což se u 64 vláken očekává). Systém byl po celou dobu plně stabilní; žádné tepelné události, žádné výpočetní chyby, žádné pády jádra.

To potvrzuje, že systém je vhodný pro trvalé inferenční workloady v režimu 24/7, kde je vytížené i CPU (předzpracování, tokenizace, režie servírovací infrastruktury).

Co fungovalo dobře

Platforma EPYC. Rozpočet PCIe linek je skutečně vyřešen. Všechny čtyři karty RTX 4090 běží pod zátěží na plných Gen4 x16 (potvrzeno v kontrole stavu PCIe 04d). Žádná bifurkace, žádné degradované sloty. Některé sestavy na AMD Ryzen se čtyřmi GPU provozují dva a více slotů na x8; na EPYC Rome to neplatí.

RAM. 512 GB je komfortní. Při načítání modelu v llama.cpp se soubor GGUF o velikosti 38 GB mapuje do paměti; díky 512 GB můžete vedle LLM serveru provozovat další procesy, aniž byste soupeřili o paměť.

Sekvenční rychlost NVMe. Sekvenční čtení 4,589 MB/s drží doby načítání krátké. Při práci s iteracemi modelů — načíst, otestovat, přepnout — se to během dne nasčítá.

Teploty. Nejhorší trvalá teplota 73°C (GPU 2, kombinovaná zátěž) s rezervou 10°C. Při běžném inferenčním workloadu GPU neběží trvale na 100% vytížení (dekódování je limitováno propustností VRAM, ne výpočtem), takže reálné provozní teploty budou nižší než špičky ze zátěžového testu.

llama.cpp a 1,568 tok/s při vyhodnocení promptu. Toto číslo nás příjemně překvapilo. Prefill přes cuBLAS na čtyřech 4090 je rychlý. Aplikace s dlouhým kontextem z toho těží.

Co nás překvapilo

Minutý AWQ kernel ve vLLM. Benchmark běžel s kernelem awq místo awq_marlin. Uváděcí sada to tehdy vybrala automaticky podle konfigurace modelu. S awq_marlin se očekává skok propustnosti u jednotlivého požadavku z 8 tok/s na 16–24 tok/s. Jde o opravu softwarové konfigurace, ne o omezení hardwaru — při nastavování produkčního servírování si ověřte řetězec kvantizační metody ve vLLM.

Propustnost D2H. Device-to-host na 1.4 GB/s nás při prvotní analýze zaskočilo. Je to chování CUDA s nepřipnutou pamětí, ne vada PCIe. Pro standardní servírovací stacky (vLLM, llama.cpp) to nehraje roli. Pro vlastní inferenční kód, který přenáší tenzory na CPU k dalšímu zpracování, použijte alokace připnuté paměti.

Opravené chyby PCIe AER na GPU 3. Během benchmarku vLLM zalogovala GPU 3 (sběrnice c1:00.0) opravené chyby PCIe (RxErr + BadTLP). Byly automaticky opraveny hardwarem a výpočet neovlivnily. Pravděpodobná příčina: usazení PCIe riseru nebo renegociace linku na rychlosti Gen4. Doporučujeme systém sledovat při trvalé produkční zátěži; pokud počet chyb poroste, přesaďte riser kabel GPU 3. Při samotných zátěžových testech nula chyb.

Krátký výpadek linky NIC. Síťové rozhraní během zátěže při benchmarku GPU krátce vypadlo a vrátilo se (13:38 UTC). Pravděpodobně napěťový přechodový jev při současném náběhu GPU. V produkci s běžícím nvidia-persistenced (který udržuje kontexty GPU inicializované) jsou přechodové jevy při startu zátěže menší. Zapněte nvidia-persistenced jako službu systemd ještě před produkčním nasazením.

Co bychom u v2 udělali jinak

Zapnout awq_marlin od začátku. Cestu kvantizačního kernelu ve vLLM ověřit už při uvádění do provozu, ne až potom. Do uváděcího skriptu přidat kontrolu identity kernelu.

Sjednotit limity příkonu GPU před benchmarkem. Čtyři karty dorazily s různě nastavenými limity (480 W, 450 W, 500 W, 480 W). Nastavení jednotného limitu (nvidia-smi -pl) před prvním během benchmarku dá čistší a lépe porovnatelná čísla a odstraní nekonzistentní odběr při kombinované zátěži.

Nasadit monitoring už při předání. Prometheus s DCGM exportérem a Grafana se nastaví za pár hodin a zpřístupní v reálném čase teploty GPU, využití VRAM i četnost chyb PCIe. Dodávat to jako součást standardního uvedení do provozu, ne to nechávat jako úkol po předání. Viz L05 pro návod na nastavení tohoto stacku.

Zapsat nvidia-persistenced do unit souboru systemd už při instalaci OS. Je to jeden řádek, ale pravidelně se na něj zapomíná. Bez něj trvá první zátěž GPU po období klidu o pár sekund déle a vyvolá napěťový přechodový jev, který způsobil výpadek NIC.

Rozšíření LVM. Systémový disk (512 GB SATA) má pro LVM oddíl alokováno jen 100 GB. Zbývajících 374 GB je nevyužitých. Není důvod to tak nechávat: lvextend a resize2fs zaberou 30 sekund a vrátí vám ten prostor pro režii OS, logy a vrstvy Dockeru.

Zvážit druhé NVMe pro úložiště modelů. Jediný disk NVMe o kapacitě 2 TB teď drží všechny modely a s růstem knihovny modelů se zaplní. Druhé NVMe o kapacitě 4 TB v RAID 0 nebo jednoduše jako samostatný přípojný bod /mnt/nvme2 by přidalo flexibilitu a udrželo vysoký výkon sekvenčního čtení i u větší celkové knihovny.

Srovnání: alternativy k této sestavě

Zákazníkův workload šlo řešit i jiným hardwarem. Zde je upřímné srovnání:

Sestava 4× RTX 4090 s 96 GB je minimální použitelná konfigurace pro provoz Llama 3.3 70B AWQ INT4 pod vLLM se smysluplnou dávkovou propustností. Není to strop; sestava s 8 GPU přidává kapacitu úměrně. Pro výzkumného zákazníka, který chce jeden dedikovaný workstation (ne servírovací cluster), bývají čtyři karty tím správným místem, kde začít.

Ani konfigurace se 4, ani s 8 GPU nemá mezi GPU NVLink, takže tensor-parallel inference probíhá přes PCIe. Praktickým důsledkem je latence TTFT u jednotlivých požadavků, nikoli souhrnná dávková propustnost. Pro zátěž velikosti týmu (desítky požadavků za hodinu, ne tisíce) to není omezující faktor. Pokud potřebujete TTFT pod 100 ms, viz N03 a zdůvodnění, proč celá řada cílí na multi-GPU propojené přes PCIe místo systémů s NVSwitch.

Celkový příkon a elektrické plánování

Při trvalé zátěži GPU byl celkový příkon systému přibližně 1,900–2,200 W měřeno na větvích GPU (1,914 W při zátěži jen GPU; ~2,100 W odhadem v kombinaci s CPU, disky a deskou). Počítejte se ztrátami účinnosti zdrojů (uvažujte 90%) a plánujte minimálně okruh 16 A/230 V, lépe 20 A pro rezervu.

Rozložení se dvěma zdroji rozděluje zátěž mezi dvě zásuvky. Obě zásuvky musí být na okruzích, které zátěž unesou nezávisle na sobě: pokud zdroj A napájí dvě GPU po 500 W plus 200 W desky a CPU, je to na jeho okruhu 1,200 W. Dimenzujte podle toho.

Rozpočet na chlazení místnosti: počítejte s tímto systémem jako s 2.5 kW trvale (konzervativně, včetně ztrát účinnosti a rezervy). U serverovny nebo rackového rozvaděče s více systémy se souhrnné číslo rychle nasčítá.

Viz P01 k úvahám o jednofázovém vs. třífázovém napájení a P04 k dimenzování jističů.

Cenové pásmo

Sestava v této specifikaci — platforma EPYC 7542, 512 GB ECC RAM, 4× RTX 4090, 2 TB NVMe, rackové šasi se dvěma zdroji — se při aktuálních cenách komponent pohybuje v pásmu €18,000–€24,000 bez DPH podle volby šasi, načasování nákupu RAM a dostupnosti GPU. Dodací lhůta je 10–28 dní podle dostupnosti komponent a potvrzuje se při objednávce.

Toto rozpětí nezahrnuje instalaci, rackové PDU, síť (10 GbE switch, kabeláž) ani softwarové licence. Systém se dodává s předinstalovaným Ubuntu 24.04 LTS a připraveným Python venv; váhy modelů si dodáte sami.

Pro co je tato sestava vhodná

• Výzkum a LLM inference pro malý tým. Provoz modelu 70B pro tým 5–15 uživatelů. Souhrnných 179 tok/s pod vLLM zvládne souběžné relace s rezervou.
• Vyhodnocování a iterace modelů. Rychlé načítání z NVMe znamená svižné přepínání mezi kandidátními modely. Díky rozpočtu PCIe linek platformy EPYC jsou všechny čtyři GPU vždy na plné propustnosti.
• Nasazení s plnou kontrolou nad daty. Veškerá inference probíhá lokálně. Žádné tokeny neopouštějí budovu. To je hlavní neekonomický důvod pro provoz on-premise ve výzkumném prostředí.
• Cenově dostupný vstup do třídy 70B. RTX 4090 je spotřebitelská GPU s nejvyšší VRAM na trhu. Při 24 GB na kartu a čtyřech kartách se díky 96 GB dostanete do třídy 70B, aniž byste museli na ceny profesionálních GPU.

Pro co tato sestava vhodná není

• TTFT pod 100 ms u jednotlivého požadavku. Topologie tensor-parallel přes PCIe P2P stanovuje spodní hranici TTFT u velkých modelů. Pokud potřebujete rychlou interaktivní latenci na modelech 70B+, je tato architektura špatná volba. Chcete GPU propojené NVLinkem, což znamená úplně jinou třídu hardwaru (viz N03).
• Souběžný provoz několika velkých modelů. Při celkových 96 GB VRAM a gpu_memory_utilization=0.80 máte k dispozici zhruba 77 GB. Druhý model 70B INT4 by se už nevešel. Pokud potřebujete hostovat dva modely současně, přejděte na platformu s více VRAM na GPU nebo s více GPU.
• Rozsáhlé produkční servírování. Pro stovky souběžných uživatelů nebo dostupnost krytou SLA není tato architektura (bez přídavných síťových karet v šasi pro 4 GPU, jediný uzel, spotřebitelské GPU bez ECC) správným základem. Tím je 8GPU server Kentino AI s L40 nebo RTX Pro 6000 Blackwell, pořádným monitoringem a dvěma síťovými kartami.
• Trénink velkých modelů. Při celkových 96 GB VRAM můžete modely 70B doladit (LoRA, QLoRA), ale nemůžete je trénovat v plném počtu parametrů. Pro trénink je rozpočet VRAM omezenější než pro inferenci. Pokud je trénink součástí plánu workloadu, počítejte s tím.

---

Toto je součást Kentino Wiki, řada C (případové studie). Data sestavy naměřena 2026-04-10. Článek publikován 2026-05-15. Opravy a doplňující měření uvítáme na info@kentino.com.