V pozdějších, interpolovaných měřeních dosáhl systém GB300 NVL72 až 11 474 tokenů za sekundu na GPU, v závislosti na požadované rychlosti odpovědi a míře souběžného zatížení .

Huawei: první ne-Nvidia platforma se srovnatelnou připraveností

Huawei se postarala o jedno z největších překvapení testu. Kombinace akcelerátoru Ascend 950DT a frameworku CANN nabídla plnou podporu celého stacku už v den uvedení modelu — tedy stejně jako Nvidia .

Jde o významný milník: u frontierového modelu této velikosti se ne-Nvidia platformě poprvé podařilo dorovnat Nvidii v připravenosti při uvedení na trh. Neznamená to však, že Huawei překonala Nvidia v absolutním výkonu. Výrobní omezení dál snižují výkonnostní strop čínského hardwaru.

Nezávislá měření čipu Ascend 950PR například uvádějí výkon ve FP4 na úrovni 2,87násobku Nvidia H20 a až 1,96násobku při inferenci MoE modelu v RL rolloutech .

AMD: nefunkční začátek, mimořádně rychlá náprava

Start AMD MI355X byl naopak velmi slabý. V první fázi byl použitelný pouze režim FP8, zatímco nativní checkpoint ve formátu FP4+FP8 nebyl připraven. Na úloze s konfigurací 8K/1K dosahoval čip jen 20,4 tokenu za sekundu na GPU při interaktivitě 2,4 tokenu za sekundu na uživatele .

Problém nebyl nutně v samotném hardwaru, ale především v nedostatečně vyladěném stacku ROCm pro takto rozsáhlý mixture-of-experts model.

AMD a 110,5násobné zrychlení za 26 dní

Následující vývoj patří k nejvýraznějším příkladům softwarové optimalizace v nedávné historii AI infrastruktury. Tým AMD SGLang pod technickým vedením HaiShawa během 26 dní sloučil 31 pull requestů zaměřených na výkon ve vývojové větvi amd/deepseek_v4 .

Každá úprava řešila jinou část stacku ROCm, která předtím s MoE modelem této velikosti prakticky nebyla otestována.

Do 20. května 2026, tedy 26 dní po vydání, se MI355X dostal na 2 256 tokenů za sekundu na GPU při 9,4 tokenu za sekundu na uživatele. Oproti úvodnímu měření šlo o 110,5násobné zvýšení propustnosti. Současně se interaktivita zlepšila 3,85krát .

Jde o neobvyklý výsledek: zvýšila se jak celková propustnost na GPU, tak rychlost odpovědi pro jednotlivého uživatele. V praxi přitom často platí, že optimalizace jedné veličiny zhorší druhou.

Při srovnatelné úrovni interaktivity dosahoval MI355X v InferenceX přibližně 1 411 tokenů za sekundu na GPU, čímž se zařadil do podobné výkonnostní kategorie jako Nvidia B200 při nižší míře interaktivity . Na GB300 NVL72 ale stále výrazně ztrácí — ten za optimálních podmínek dosahuje až 11 474 tokenů za sekundu na GPU .

Přehled výsledků po 43 dnech

Cena za milion tokenů dobře ukazuje ekonomický rozdíl mezi platformami. Při nižší požadované interaktivitě vychází GB300 NVL72 na 0,064 dolaru za milion tokenů, tedy přibližně 4,5krát levněji než MI355X s cenou 0,291 dolaru .

Při vyšší interaktivitě, kdy je méně souběžných uživatelů a důraz je na rychlost odpovědi, se MI355X dostává blíž B200. V příslušných měřených bodech se obě platformy pohybovaly zhruba mezi 1,22 a 1,45 dolaru za milion tokenů při 23 až 24 souběžných uživatelích .

Proč je DeepSeek V4 vůbec možné provozovat v milionovém kontextu

Čísla z benchmarků by sama o sobě nestačila. Ekonomickou proveditelnost provozu V4 Pro umožňuje především změna architektury modelu.

U standardní transformerové pozornosti náklady s délkou kontextu rostou kvadraticky. Při milionu tokenů se výpočetní i paměťové nároky stávají pro běžné nasazení prakticky neúnosnými. DeepSeek V4 proto kombinuje dva mechanismy: Compressed Sparse Attention (CSA) a Heavily Compressed Attention (HCA).

CSA: komprese a výběr relevantních částí

CSA pracuje na jemnější úrovni. Přibližně čtyři tokeny sloučí do jednoho naučeného záznamu KV pomocí vah závislých na obsahu a překrývajících se oken. Následně se použije řídká pozornost: každý dotaz pracuje jen s nejrelevantnějšími komprimovanými záznamy. Výběr zajišťuje komponenta Lightning Indexer .

Paralelně běží posuvné okno pozornosti, které pomáhá zachovat přesnost u lokálních vztahů v textu .

HCA: globální přehled za zlomek paměti

HCA volí ještě agresivnější kompresi. Až 128 tokenů shrne do jediného KV záznamu a nad tímto komprimovaným proudem provádí hustou pozornost .

Tento přístup obětuje část přesnosti při vyhledávání konkrétní informace výměnou za levný globální přehled celého kontextu. HCA se používá v počátečních vrstvách, zatímco poslední vrstva si zachovává plnou pozornost pro přesnější zpracování .

Výsledek při kontextu o délce jednoho milionu tokenů v porovnání s DeepSeek V3.2:

• Výpočetní náročnost inference na token: 27 % původní hodnoty, tedy o 73 % méně
• Paměť pro KV cache: přibližně 10 % původní hodnoty, tedy zhruba o 90 % méně
• Ve srovnání s běžnou baseline GQA v bfloat16: přibližně 2 % velikosti cache

U menšího modelu V4 Flash jsou úspory ještě výraznější: náročnost inference klesá na 10 % a KV cache na 7 % hodnot DeepSeek V3.2 .

Bez CSA a HCA by byl 1,6bilionový model V4 Pro s milionovým kontextem spíše technickou demonstrací. Díky této architektuře se z něj může stát prakticky nasaditelný produkt.

Co test skutečně ukázal

Čtyřicet tři dní měření přineslo tři odlišné závěry.

Za prvé, náskok Nvidie není pouze otázkou hardwaru. Ekosystém CUDA nabízí připravenou podporu vLLM a SGLang hned při uvedení nového modelu, což je pro provozovatele datacenter zásadní výhoda.

Za druhé, Huawei dokázala u Ascendu 950DT a CANN tuto softwarovou připravenost napodobit. Přestože její absolutní výkon zůstává omezený výrobními podmínkami, podpora v den vydání představuje významný posun pro celý čínský AI ekosystém .

A za třetí, AMD ukázalo, že jeho hardware má podstatně větší potenciál, než naznačovaly výsledky z prvního dne. Zároveň je ale problematické, že k proměně nefunkčního nasazení ve smysluplnou inferenční platformu bylo zapotřebí 31 cílených softwarových zásahů během jediného měsíce .

Nejdůležitější příběh se však odehrává přímo v architektuře DeepSeek V4. Kombinace CSA a HCA snižuje nároky na výpočty i paměť natolik, že milionový kontext u 1,6bilionového modelu přestává být pouze laboratorním experimentem. Otázka se tak posouvá od „lze to vůbec provozovat?“ k mnohem praktičtějšímu „co s tím dokážeme postavit?“

V pozdějších, interpolovaných měřeních dosáhl systém GB300 NVL72 až 11 474 tokenů za sekundu na GPU, v závislosti na požadované rychlosti odpovědi a míře souběžného zatížení .

Huawei: první ne-Nvidia platforma se srovnatelnou připraveností

Huawei se postarala o jedno z největších překvapení testu. Kombinace akcelerátoru Ascend 950DT a frameworku CANN nabídla plnou podporu celého stacku už v den uvedení modelu — tedy stejně jako Nvidia .

Jde o významný milník: u frontierového modelu této velikosti se ne-Nvidia platformě poprvé podařilo dorovnat Nvidii v připravenosti při uvedení na trh. Neznamená to však, že Huawei překonala Nvidia v absolutním výkonu. Výrobní omezení dál snižují výkonnostní strop čínského hardwaru.

Nezávislá měření čipu Ascend 950PR například uvádějí výkon ve FP4 na úrovni 2,87násobku Nvidia H20 a až 1,96násobku při inferenci MoE modelu v RL rolloutech .

AMD: nefunkční začátek, mimořádně rychlá náprava

Start AMD MI355X byl naopak velmi slabý. V první fázi byl použitelný pouze režim FP8, zatímco nativní checkpoint ve formátu FP4+FP8 nebyl připraven. Na úloze s konfigurací 8K/1K dosahoval čip jen 20,4 tokenu za sekundu na GPU při interaktivitě 2,4 tokenu za sekundu na uživatele .

Problém nebyl nutně v samotném hardwaru, ale především v nedostatečně vyladěném stacku ROCm pro takto rozsáhlý mixture-of-experts model.

AMD a 110,5násobné zrychlení za 26 dní

Následující vývoj patří k nejvýraznějším příkladům softwarové optimalizace v nedávné historii AI infrastruktury. Tým AMD SGLang pod technickým vedením HaiShawa během 26 dní sloučil 31 pull requestů zaměřených na výkon ve vývojové větvi amd/deepseek_v4 .

Každá úprava řešila jinou část stacku ROCm, která předtím s MoE modelem této velikosti prakticky nebyla otestována.

Do 20. května 2026, tedy 26 dní po vydání, se MI355X dostal na 2 256 tokenů za sekundu na GPU při 9,4 tokenu za sekundu na uživatele. Oproti úvodnímu měření šlo o 110,5násobné zvýšení propustnosti. Současně se interaktivita zlepšila 3,85krát .

Jde o neobvyklý výsledek: zvýšila se jak celková propustnost na GPU, tak rychlost odpovědi pro jednotlivého uživatele. V praxi přitom často platí, že optimalizace jedné veličiny zhorší druhou.

Při srovnatelné úrovni interaktivity dosahoval MI355X v InferenceX přibližně 1 411 tokenů za sekundu na GPU, čímž se zařadil do podobné výkonnostní kategorie jako Nvidia B200 při nižší míře interaktivity . Na GB300 NVL72 ale stále výrazně ztrácí — ten za optimálních podmínek dosahuje až 11 474 tokenů za sekundu na GPU .

Přehled výsledků po 43 dnech

Cena za milion tokenů dobře ukazuje ekonomický rozdíl mezi platformami. Při nižší požadované interaktivitě vychází GB300 NVL72 na 0,064 dolaru za milion tokenů, tedy přibližně 4,5krát levněji než MI355X s cenou 0,291 dolaru .

Při vyšší interaktivitě, kdy je méně souběžných uživatelů a důraz je na rychlost odpovědi, se MI355X dostává blíž B200. V příslušných měřených bodech se obě platformy pohybovaly zhruba mezi 1,22 a 1,45 dolaru za milion tokenů při 23 až 24 souběžných uživatelích .

Proč je DeepSeek V4 vůbec možné provozovat v milionovém kontextu

Čísla z benchmarků by sama o sobě nestačila. Ekonomickou proveditelnost provozu V4 Pro umožňuje především změna architektury modelu.

U standardní transformerové pozornosti náklady s délkou kontextu rostou kvadraticky. Při milionu tokenů se výpočetní i paměťové nároky stávají pro běžné nasazení prakticky neúnosnými. DeepSeek V4 proto kombinuje dva mechanismy: Compressed Sparse Attention (CSA) a Heavily Compressed Attention (HCA).

CSA: komprese a výběr relevantních částí

CSA pracuje na jemnější úrovni. Přibližně čtyři tokeny sloučí do jednoho naučeného záznamu KV pomocí vah závislých na obsahu a překrývajících se oken. Následně se použije řídká pozornost: každý dotaz pracuje jen s nejrelevantnějšími komprimovanými záznamy. Výběr zajišťuje komponenta Lightning Indexer .

Paralelně běží posuvné okno pozornosti, které pomáhá zachovat přesnost u lokálních vztahů v textu .

HCA: globální přehled za zlomek paměti

HCA volí ještě agresivnější kompresi. Až 128 tokenů shrne do jediného KV záznamu a nad tímto komprimovaným proudem provádí hustou pozornost .

Tento přístup obětuje část přesnosti při vyhledávání konkrétní informace výměnou za levný globální přehled celého kontextu. HCA se používá v počátečních vrstvách, zatímco poslední vrstva si zachovává plnou pozornost pro přesnější zpracování .

Výsledek při kontextu o délce jednoho milionu tokenů v porovnání s DeepSeek V3.2:

• Výpočetní náročnost inference na token: 27 % původní hodnoty, tedy o 73 % méně
• Paměť pro KV cache: přibližně 10 % původní hodnoty, tedy zhruba o 90 % méně
• Ve srovnání s běžnou baseline GQA v bfloat16: přibližně 2 % velikosti cache

U menšího modelu V4 Flash jsou úspory ještě výraznější: náročnost inference klesá na 10 % a KV cache na 7 % hodnot DeepSeek V3.2 .

Bez CSA a HCA by byl 1,6bilionový model V4 Pro s milionovým kontextem spíše technickou demonstrací. Díky této architektuře se z něj může stát prakticky nasaditelný produkt.

Co test skutečně ukázal

Čtyřicet tři dní měření přineslo tři odlišné závěry.

Za prvé, náskok Nvidie není pouze otázkou hardwaru. Ekosystém CUDA nabízí připravenou podporu vLLM a SGLang hned při uvedení nového modelu, což je pro provozovatele datacenter zásadní výhoda.

Za druhé, Huawei dokázala u Ascendu 950DT a CANN tuto softwarovou připravenost napodobit. Přestože její absolutní výkon zůstává omezený výrobními podmínkami, podpora v den vydání představuje významný posun pro celý čínský AI ekosystém .

A za třetí, AMD ukázalo, že jeho hardware má podstatně větší potenciál, než naznačovaly výsledky z prvního dne. Zároveň je ale problematické, že k proměně nefunkčního nasazení ve smysluplnou inferenční platformu bylo zapotřebí 31 cílených softwarových zásahů během jediného měsíce .

Nejdůležitější příběh se však odehrává přímo v architektuře DeepSeek V4. Kombinace CSA a HCA snižuje nároky na výpočty i paměť natolik, že milionový kontext u 1,6bilionového modelu přestává být pouze laboratorním experimentem. Otázka se tak posouvá od „lze to vůbec provozovat?“ k mnohem praktičtějšímu „co s tím dokážeme postavit?“