Výběr hardwaru pro AI inference už dávno není jen o „co je nejrychlejší“. V praxi rozhoduje kombinace výkonu, ceny, spotřeby energie, latence, dostupnosti ekosystému a bezpečnosti dat. Tento rozsáhlý, SEO-optimalizovaný průvodce porovnává GPU (univerzální akcelerace s masivním ekosystémem), TPU (specializované čipy s XLA kompilací a vysokou propustností v cloudu) a NPU (on-device inference v noteboocích a telefonech), vysvětluje hlavní trade-offy a dává praktickou metodiku, jak si pro konkrétní use-case spočítat nejlepší poměr cena/výkon/energetika.
Proč výběr inference stacku rozhoduje o úspěchu AI
Stejný model může běžet o řád levněji a rychleji, pokud se dobře spojí hardware + kompilace + kvantizace + servisní architektura. Zatímco vývojáři často řeší architekturu modelu a prompt, v produkci rozhoduje i jak rychle přidáte další kapacitu, zda splníte latenci (například do 200 ms u konverzace), kolik wattů vás stojí jeden výstup a jak snadno zvládnete audit. Špatně zvolený stack přináší spirálu nákladů: dlouhé fronty → vyšší latence → další repliky → vyšší účet za GPU/TPU → tlak omezit traffic → nespokojení uživatelé. Naopak dobrá volba umí omezit tokeny (context budgeting), běžet v INT8/INT4, zapnout batching a zlevnit inference o desítky procent.
Základní pojmy: latence, propustnost, kvantizace, paměť, interconnect
Latence je doba od požadavku k prvnímu užitečnému výstupu (u LLM často „time-to-first-token“). Propustnost je počet požadavků za sekundu (QPS) nebo počet tokenů/s. V praxi se ladí kompromis mezi latencí a propustností pomocí batchingu (více požadavků současně), prefillu (rychlejší příprava KV cache), speculative decodingu a kvantizace (např. FP8/INT8/INT4). Paměť (kapacita i propustnost) limituje, jak velký model a jak dlouhý kontext zvládnete. Interconnect (NVLink, PCIe, Ethernet, InfiniBand) určuje, jak dobře škálujete přes více akcelerátorů (tensor/pipeline parallelism).
Pro výběr stacku si vždy ujasněte: 1) cílovou latenci a SLA (p95), 2) očekávaný QPS, 3) délky promptů/odpovědí, 4) zda musíte běžet on-prem/on-device, 5) zda data smí ven (compliance), 6) cílovou cenu za 1000 požadavků.
Třídy workloadů: LLM, vizuální inference, generativní obrazy, ASR/TTS, doporučování
- LLM (chat, RAG, shrnutí) — náročné na paměť (KV cache), citlivé na latenci; parametry: velikost modelu, délka kontextu, tok/token/s, počet paralelních vláken.
- Computer vision — klasifikace/detekce/segementace; dobře škáluje batchingem; latence často do 50–100 ms u real-time.
- Generativní obraz (difúze) — peak compute, méně citlivé na latenci u batchů; vhodné pro GPU/TPU s dobrým FP16/FP8 výkonem.
- ASR/TTS — streamování, nízká latence, stabilní throughput; často kombinace NPU (lokální efekty) + GPU/TPU (cloudová přesnost).
- Doporučování (recsys) — velké embedding tabulky, mix CPU/GPU, vysoká propustnost; často vyžaduje specializovaný cache tier a feature store.
GPU pro inference: univerzálnost, knihovny a škálování
GPU jsou hlavním „pracovním koněm“ AI inference. Nabízí širokou podporu frameworků (PyTorch, TensorFlow, JAX), bohaté knihovny (TensorRT, cuBLAS, cuDNN, Triton Inference Server) a flexibilitu pro smíšené pracovní zátěže. Díky rozšířenosti se snadno škáluje horizontálně (více instancí) i vertikálně (více GPU v serveru).
Kdy volit GPU
- Potřebujete univerzální akceleraci pro různé modely (LLM, CV, difúze) a rychlou iteraci.
- Vyžadujete nízkou latenci u generativních UI (chat, voice), ale zároveň vysoké QPS při špičkách.
- Chcete těžit z nejvyspělejších optimalizací (kernel fusion, FP8/INT8, kvantizace, KV cache).
Praktické tipy pro GPU
- Engine kompilace: export modelu do ONNX a kompilace do TensorRT; zajistí fúze, kernelové optimalizace a nižší latenci.
- Kvantizace: post-training INT8/INT4 s kalibrací; u LLM zvažte AWQ/GPTQ-like přístupy a 8bit/4bit weight-only inference.
- Batching a schedulery: dynamický batching v Tritonu a priority front; oddělte prefill od decode fáze.
- KV cache: pinování do HBM, sdílení napříč požadavky; u dlouhých kontextů šetří desítky procent výpočtu.
- Škálování: pro velké modely využijte tensor parallel (víc GPU v jednom serveru) a pipeline parallel (víc vrstev na různé GPU).
GPU mají velkou výhodu v dostupnosti a nástrojích, nevýhodou může být cena při non-stop provozu bez optimalizací (zejména bez batchingu a kvantizace). Pro spiky trafficu je ideální autoscaling s rychlým warm-upem a cache politikami.
TPU v cloudu: kdy se vyplatí XLA a vysoká propustnost
TPU jsou specializované čipy optimalizované pro maticové operace, s úzkou integrací do XLA kompilace a cloudové sítě. Vynikají u velkých modelů a batch-heavy workloadů, kde je cenná extrémní propustnost a dobrá efektivita na watt.
Kdy volit TPU
- Inference ve velkém měřítku s předvídatelným zatížením (např. stovky QPS stabilně).
- Modely, které dobře kompilují přes XLA (transformery, konvoluce) a těží z layout optimalizací.
- Scénáře, kde je důležitá cena za token v masivním měřítku a není nutná on-prem instalace.
Co zvážit
- Portace grafu a stabilita kompilace: některé modelové nuance vyžadují drobné úpravy ops nebo graph fúzí.
- Ekosystém nástrojů je užší než u GPU, ale rychle se zlepšuje; pro RAG služby je nutné dobře propojit síť/úložiště.
- Billing a rezervace: nejlépe vycházejí dlouhodobější závazky nebo dedikované pooly.
U velkých LLM a batchových generativních úloh mohou TPU nabídnout vynikající poměr ceny a propustnosti, zvláště pokud vaše pipeline dobře kompiluje a drží se standardních grafových vzorů.
NPU on-device: soukromí, offline funkce a extrémně nízká latence
NPU (Neural Processing Unit) v telefonech a noteboocích umožňují inference na zařízení bez cloudu. Vynikají tam, kde je klíčová latence < 100 ms, ochrana soukromí a offline dostupnost. Typické jsou úlohy: diktování a přepis, korekce fotek, lokální asistenti, překlady, rozpoznání scén, detekce klíčových událostí ve videu u kamer.
Kdy volit NPU
- Soukromí a regulace vyžadují, aby data neopouštěla zařízení (např. HR asistent s interními texty, zdravotní poznámky).
- Potřebujete okamžitou odezvu bez závislosti na připojení (asistent psaní, offline překlad, selektivní šifrování fotek).
- Chcete snížit cloudové náklady posunem části inference k uživateli.
Co zvážit
- Modely musí být kompaktní (kvantizace INT8/INT4, distilace, lo-rank adapters), obvykle do jednotek/stovek MB.
- Ekosystémy: Core ML (Apple), NNAPI (Android), Windows/ONNX Runtime s NPU akcelerací; každá platforma má svá omezení ops.
- Distribuce modelů: verze, bezpečné podepisování, ochrana proti extrakci, řízení aktualizací.
NPU posouvají část AI z cloudu do kapsy. Největší přínos je v UX (pocit „okamžitosti“) a v nákladech na provoz, pokud objem uživatelů roste rychleji než cloudový rozpočet.
Srovnání GPU vs. TPU vs. NPU podle cílů
Porovnávací tabulka (vysoká úroveň)
| Kriterium | GPU | TPU (cloud) | NPU (on-device) |
|---|---|---|---|
| Univerzálnost modelů | Velmi vysoká | Vysoká (nejlépe standardní grafy) | Střední (závisí na ops platformy) |
| Latence interaktivní AI | Velmi dobrá | Dobrá až výborná (při batch) | Excelentní (lokálně, <100 ms) |
| Propustnost ve velkém měřítku | Vysoká | Velmi vysoká | Nevztahuje se (per-device) |
| Cena za jednotku (stabilní zatížení) | Střední (závisí na optimalizaci) | Často nízká při vysokém využití | Velmi nízká cloudová cena (běží lokálně) |
| Soukromí a data residency | On-prem možný, cloud vyžaduje režim | Cloud-first (řešit compliance) | Výborné (data neopouští zařízení) |
| Ekosystém a nástroje | Nejbohatší | Silný, ale užší než GPU | Různorodý, platformně závislý |
| Snadnost portace modelu | Vysoká (ONNX/TensorRT) | Střední (XLA/kompilace) | Střední až nižší (Core ML/NNAPI) |
| Energetická účinnost | Dobrá (s kvantizací výborná) | Velmi dobrá | Výborná (nízký TDP) |
Rozhodovací matice podle use-case
| Use-case | Latence | Objem | Data citlivost | Doporučený stack |
|---|---|---|---|---|
| Chatový asistent (RAG) v aplikaci | <300 ms TTFT | Střední–vysoký | Střední | GPU s TensorRT, dynamický batching, KV cache |
| Hromadná sumarizace dokumentů přes noc | Minuty nevadí | Vysoký | Nízká–střední | TPU nebo GPU cluster s batch schedulingem |
| On-device asistent psaní | <100 ms | Vysoký (per-user) | Vysoká | NPU (Core ML/NNAPI), kvantizovaný menší model |
| Moderace obrázků ve streamu | <50–100 ms | Vysoký | Střední | GPU s vysokým batchingem + lehké CV modely |
| Call-center přepis a shrnutí | <300 ms | Vysoký, kontinuální | Vysoká | GPU/TPU pro ASR+LLM v cloudu + lokální NPU pro efekty |
TCO a kapacitní plánování: jak počítat náklady, energii a SLA
Celkové náklady vlastnictví (TCO) zahrnují compute (pronájem/odpisy), energii (včetně PUE datacentra), síť/úložiště, software (licence, podpora), personál (MLOps, SRE) a rezervní kapacitu pro špičky. Rozumný postup:
- Spočítejte profil dotazů (p95 latence, průměrný kontext a odpověď, poměr prefill/decode, re-rank/embeddingy).
- Odhadněte tokeny/sekundu a QPS v reálném provozu (počet souběžných sezení × průměrná rychlost).
- V mikro-benchmarcích změřte tokens/s v požadované přesnosti (FP16/FP8/INT8/INT4) pro daný model a engine.
- Zvolte replikaci, batching a KV cache tak, aby p95 latence splnila SLA i při píkách.
- Přepočítejte na cenu za 1000 požadavků (compute + energie) a porovnejte varianty GPU vs. TPU vs. NPU offload.
Tipy: 1) Context budgeting (omezte zbytečné pasáže RAG, zapněte MMR, kompresi kontextu), 2) Kvantizace (8bit/4bit) dramaticky zvyšuje tokens/s, 3) Speculative decoding s menším „draft“ modelem snižuje latenci, 4) Autoscaling s teplými replikami minimalizuje studené starty.
Softwarový stack: formáty, optimalizace a akcelerační knihovny
- Modelové formáty: ONNX pro přenositelnost, formáty pro TensorRT, případně XLA grafy; na mobilu Core ML/NNAPI.
- Kompilace: PyTorch 2+ (torch.compile) pro fúzi kernelů, TensorRT pro GPU, XLA pro TPU, ONNX Runtime s EP (Execution Provider) pro různé akcelerátory.
- Kvantizace: post-training (PTQ) vs. quantization-aware training (QAT); u LLM funguje weight-only INT4/INT8 a aktivační dequant jen v kritických vrstvách.
- Serving: Triton Inference Server (dynamický batching, multi-model), v cloudových prostředích managed endpointy; sledujte concurrency, queue delay a GPU util.
- Observabilita: metriky latence po fázích (prefill/decode), cache hit-rate, OOM události, využití interconnectu, procento INT8/FP8 cest.
Energetika a udržitelnost: watty na token, PUE a carbon-aware inference
U velkých nasazení se vyplatí sledovat W/token a kWh/1000 požadavků. Na zlepšení mají největší vliv: kvantizace (nižší paměť a přesuny), better batching (méně overheadu), context budgeting (méně tokenů v promptu) a provoz v datacentrech s nízkým PUE. V mobilním světě zase rozhoduje energy per inference a dopad na výdrž baterie; NPU má výrazně lepší efektivitu než CPU/GPU v úloze, na kterou je navrženo.
Carbon-aware plánování (spouštění batchových úloh v časech s nižší uhlíkovou intenzitou sítě) a offload na NPU (část požadavků běží u uživatele) snižují jak účet, tak uhlíkovou stopu.
Bezpečnost a governance: data residency, audit, PII
Volba stacku má bezpečnostní důsledky. Pokud data nesmí opustit perimetr, preferujte on-prem GPU nebo NPU on-device. V cloudu zohledněte region, šifrování, izolaci tenantů a audit logy. U on-device řešení řešte bezpečnou distribuci modelů (podepisování, ochrana proti extrakci) a možnost jejich vzdálené deaktivace. Vždy logujte evidence pack: verze modelu, přesnost/latence v čase, incidenty, verze knihoven a konfigurace akcelerátoru.
Praktické scénáře a volba stacku krok za krokem
1) Interní chat s RAG nad firemní dokumentací
Cíl: p95 TTFT do 300 ms, citace zdrojů, náklady pod kontrolou. Volba: GPU s TensorRT a Tritonem, 8bit kvantizace, KV cache. Retrieval: hybrid (BM25 + vektor), re-ranking, context compression. Výsledek: nízká latence, dobrá kvalita a jednoduché škálování podle trafficu. Pokud je zátěž extrémně stabilní a vysoká, zvažte TPU pro snížení ceny za token.
2) Noční sumarizace PDF a e-mailů (miliony stran)
Cíl: dokončit do rána, cena co nejnižší. Volba: TPU nebo GPU clustery s agresivním batchingem, menší přesnost (FP8/INT8) pokud to kvalita umožní. Plánování: carbon-aware okna a pre-fetch dat. Výsledek: nejlepší cena za 1000 dokumentů, latence nevadí.
3) On-device asistent psaní v mobilu
Cíl: okamžitá odezva, žádná data do cloudu. Volba: NPU, kvantizovaný menší LLM (například 1,5–3B parametrů), distilace a LoRA pro požadované chování. Ekosystém: Core ML/NNAPI, aktualizace modelu přes store, ochrana binárky. Výsledek: skvělý UX a nulové cloudové náklady za inference.
4) Moderace obrázků ve streamu na marketplace
Cíl: <100 ms na snímek, vysoká přesnost. Volba: GPU s vysokým batchingem, lehčí CV modely (detektory + klasifikátory), bezstavová škálovatelnost. Optimalizace: předzpracování na CPU, pipeline s minimálním kopírováním dat, event-driven autoscaling. Výsledek: nízké náklady na jednotku a stabilní SLA.
5) Přepis a shrnutí hovorů v call-centru
Cíl: realtime přepis a krátké shrnutí, ochrana PII. Volba: GPU/TPU pro ASR+LLM, PII redakce před uložením, RBAC k nahrávkám; klientská aplikace může používat NPU pro lokální odhlučnění a VAD (voice activity detection). Výsledek: dobrá latence i přesnost, auditovatelné zpracování PII.
Roadmapa zavedení: benchmark → pilot → škálování
- Benchmark: vyberte 2–3 modely a 2–3 hardware varianty (GPU/TPU/NPU offload) a změřte tokens/s, TTFT, p95 latenci a náklady při realistických dávkách a kontextech.
- Pilot: nasaďte na omezený traffic, měřte online metriky (TTFT, re-prompt rate, cache hit-rate, GPU util), logujte chybové případy.
- Škálování: přidejte autoscaling, canary releasy, observabilitu (tracing po fázích), optimalizujte kvantizaci a batching, zvažte TPU pro části, kde dominuje propustnost.
- NPU strategie: pro funkce vhodné na klienta navrhněte on-device variantu (asistent, překlad), sledujte distribuci a bezpečnost modelů.
Nejčastější omyly při volbě inference hardwaru
- „Vezmeme největší model a největší GPU a je to.“ Bez kvantizace, batchingu, KV cache a context budgetingu zaplatíte víc a dostanete horší latenci.
- Ignorování variability trafficu. Špičky bez autoscalingu znamenají timeouts; přeprovisionování mimo špičky pálí rozpočet.
- Podcenění ekosystému. Portace modelu na platformu bez zralých nástrojů může zdržet týdny.
- Neřešení PII a governance. Volba cloudu bez auditní stopy a regionální kontroly je reputační riziko.
- Slepé porovnávání benchmarků. Vaše data, vaše prompty, vaše latence; cizí čísla jsou orientační.
Závěr: jak si zvolit správně hned napoprvé
Neexistuje „nejlepší“ akcelerátor pro všechny. GPU vyhrají univerzalitou, ekosystémem a rychlou iterací; jsou ideální pro interaktivní aplikace a smíšené workloady. TPU dávají smysl u stabilně vysoké zátěže, kde XLA a cloudová síť dodají špičkovou propustnost a dobrou cenu za token. NPU jsou jasná volba tam, kde rozhoduje soukromí, offline dostupnost a pocit „okamžité“ odezvy – a navíc snižují cloudové účty. V praxi se vyplatí kombinovat: on-device NPU pro lokální asistenty, GPU pro interaktivní RAG a případně TPU pro batch generace a masivní inference. Držte se metrik, testujte na svých datech, kvantizujte a plánujte kapacitu s ohledem na špičky. Tak postavíte inference stack, který je rychlý, úsporný, škálovatelný a udržitelný – a který doručí AI hodnotu bez nepříjemných překvapení na faktuře.
