Blog Modely

DeepSeek zrychlil generování AI až o 85 %. Bez nového modelu a nových čipů

DSpark nepřidává jazykovému modelu inteligenci. Mění způsob, jakým se jeho odpověď skládá a ověřuje. Právě proto je zajímavý: ukazuje, že další velké zrychlení AI nemusí přijít z většího modelu ani z dražšího hardwaru.

Jaroslav Urbánek, zakladatel TECHNOMATONu 26. července 2026 7 min čtení

Paralelní návrh tokenů prochází ověřovací bránou DSparku Původní ilustrace: TECHNOMATON · vytvořeno s podporou OpenAI ImageGen

Nejzajímavější AI novinka posledních týdnů není nový model.

DeepSeek nevydal chytřejší systém, nepřidal další biliony parametrů a neoznámil novou generaci čipů. Místo toho se podíval na část provozu, kterou už všichni používají, a změnil způsob, jakým v ní proudí práce.

Výsledkem je DSpark, framework pro spekulativní dekódování od týmu DeepSeek-AI a výzkumníků z Pekingské univerzity. Veřejný repozitář DeepSpec vznikl 26. června 2026 a výzkumný článek na arXivu následoval 6. července.

Podle měření DeepSeeku z reálného provozu zvyšuje DSpark u modelu DeepSeek-V4-Flash rychlost generování na uživatele o 60 až 85 %. U většího V4-Pro jde o 57 až 78 %. Cílový model přitom zůstává stejný a systém běží na stejné infrastruktuře.

To zní skoro jako bezplatný výkon.

Není. Ale je to velmi dobré systémové inženýrství.

Problém nevzniká jen v modelu

Jazykový model generuje odpověď token po tokenu. Každý nový token závisí na tom, co už bylo napsáno, a vyžaduje další průchod modelem.

Moderní GPU jsou výborná v paralelních výpočtech. Sekvenční generování jim ale nedává vždy dost práce najednou. Zvlášť u interaktivních požadavků a menších dávek bývá dekódování omezené přesuny dat mezi pamětí a výpočetními jednotkami. Část potenciálu drahého hardwaru proto zůstává nevyužitá.

Je to podobné, jako kdyby velmi rychlá tiskárna dostávala každou stránku dokumentu zvlášť a po každé musela čekat, až někdo připraví další.

Čip není pomalý. Pomalý je způsob, jakým k němu práce přichází.

Starší trik: nechte malý model připravit návrh

Známým řešením je spekulativní dekódování.

Vedle velkého cílového modelu běží menší pomocný model, takzvaný drafter. Ten rychle navrhne několik dalších tokenů. Velký model je pak ověří společně v jednom průchodu.

Pokud s návrhem souhlasí, přijme více tokenů najednou. Pokud najde chybu, ponechá správný začátek a od místa neshody pokračuje znovu.

Při správné implementaci se tím nemění výsledná distribuce odpovědi cílového modelu. Zrychluje se cesta k výsledku, ne samotný obsah.

Jenže pomocný model vytváří nový kompromis.

  • Když navrhuje tokeny jeden po druhém, udržuje souvislost, ale je pomalejší.
  • Když je navrhuje paralelně, je rychlý, ale pozdější části návrhu ztrácejí soudržnost a velký model je častěji odmítne.

Právě na tento kompromis DSpark míří.

Co DSpark mění

DSpark skládá několik mechanismů, které se navzájem doplňují:

  1. Paralelní drafter připraví blok kandidátních tokenů najednou.
  2. Lehká sekvenční hlava do návrhu doplní lokální závislosti mezi tokeny. Výchozí varianta používá takzvanou Markovovu hlavu, která při úpravě další pozice zohledňuje bezprostředně předchozí token.
  3. Confidence head odhaduje pravděpodobnost, že cílový model přijme jednotlivé části navrženého prefixu.
  4. Hardwarově orientovaný plánovač podle těchto odhadů a aktuálního zatížení rozhoduje, jak dlouhou část návrhu má smysl ověřovat.
  5. Cílový model ověří vybraný blok a zachová svou původní výstupní distribuci.

První dvě části řeší kvalitu návrhu. Další dvě řeší, zda ověřování nezabere víc kapacity, než kolik ušetří.

To je důležité hlavně při vysokém počtu souběžných požadavků. Dlouhý návrh může jednomu uživateli pomoci, ale pokud jeho konec pravděpodobně neprojde, zbytečně spotřebuje kapacitu, která mohla obsloužit někoho dalšího.

DSpark proto neověřuje pokaždé stejně dlouhý blok. Když si je drafter jistý a server má rezervu, může ověřit více tokenů. Při nižší jistotě nebo vyšší zátěži návrh zkrátí.

Malá sériová část, velký efekt

Mohlo by se zdát, že sekvenční korekce vrací do systému úzké hrdlo, kterého se chtěl zbavit.

Podle paperu je ale tato část velmi malá. Při zvětšení navrhovaného bloku ze 4 na 16 tokenů přidala proti čistě paralelnímu baseline jen 0,2 až 1,3 % času na jeden celý cyklus. Přijatá délka návrhu přitom vzrostla až o 30 %.

Confidence head zase pomáhá odříznout části, které by s vysokou pravděpodobností neprošly. V diagnostickém testu na Qwen3-4B zvýšilo postupné zpřísňování prahu akceptační poměr:

  • u otevřeného chatu z 45,7 na 95,7 %,
  • u matematiky ze 76,9 na 92,5 %,
  • u kódu ze 67,6 na 92,0 %.

Vyšší akceptační poměr ale neznamená, že systém zázračně pozná správnou odpověď. Znamená, že předem vyřadí více rizikových tokenů a cílovému modelu pošle kratší, kvalitnější prefix.

Co přesně znamená „až o 85 %“

Titulní číslo potřebuje kontext. Paper porovnává DSpark s předchozím produkčním nastavením DeepSeeku označeným jako MTP-1 a pracuje s telemetrií z živého provozu modelů V4-Flash a V4-Pro.

Při srovnatelné celkové propustnosti naměřil DeepSeek tyto změny:

ModelRychlost generování na uživatelePropustnost při mírném SLAPropustnost při přísném SLA
DeepSeek-V4-Flash+60 až +85 %+51 % při 80 tokenech/snominálně +661 % při 120 tokenech/s
DeepSeek-V4-Pro+57 až +78 %+52 % při 35 tokenech/snominálně +406 % při 50 tokenech/s

Čísla 661 a 406 % vypadají nejlépe, ale nejsou nejvhodnějším titulkem. Při přísném SLA se původní MTP-1 dostává k hranici, kde už zvládá jen velmi malý počet souběžných požadavků. Poměr pak prudce roste kvůli slabému výchozímu bodu.

Autoři paperu na to sami upozorňují. Za stabilnější srovnání považují právě 60 až 85 % vyšší rychlost na uživatele při odpovídající propustnosti.

A ještě jeden častý omyl: o 85 % vyšší rychlost neznamená o 85 % kratší čekání. Pokud by se rychlost zvýšila z 100 na 185 tokenů za sekundu, stejná odpověď by se v ideálním případě vygenerovala přibližně za 54 % původního času. Čekání by tedy kleslo zhruba o 46 %.

Pořád je to velký rozdíl. Jen jiný, než naznačuje nejdramatičtější výklad titulku.

Co znamená „bez zásahu do modelu“

Oficiální modelová karta to popisuje přesně: varianta DeepSeek-V4-Pro-DSpark používá stejný checkpoint cílového modelu a připojuje k němu modul pro spekulativní dekódování.

To má dvě důležité výhody.

Za prvé není nutné znovu trénovat obrovský cílový model ani měnit jeho váhy. Za druhé lze při korektním ověřování zachovat jeho původní výstupní distribuci.

Neznamená to ale, že se netrénuje nic.

Pomocný draft model se trénovat musí. DeepSeek zveřejnil hotové checkpointy pro své modely i pro rodiny Qwen3 a Gemma4 a v repozitáři DeepSpec poskytuje nástroje pro přípravu dat, trénink a evaluaci. Kód je pod licencí MIT.

Pro nový cílový model tedy nejde o přepínač bez přípravy. README DeepSpecu například u výchozího nastavení Qwen3-4B počítá s osmi GPU a upozorňuje, že příprava cílové cache může zabrat přibližně 38 TB.

Podobně „bez nového hardwaru“ znamená, že DeepSeek dosáhl zlepšení na stejné infrastruktuře. Neznamená to kompatibilitu s libovolným starším serverem ani nulovou integrační práci. Inference engine musí DSpark podporovat a produkční nasazení vyžaduje správné profilování, plánování i měření.

Open source snižuje vstupní bariéru. Neruší náklady na implementaci.

Máme nezávislé potvrzení?

Hlavní produkční čísla stále pocházejí od samotného DeepSeeku. Veřejnost nemá stejný provoz, stejné rozložení požadavků ani interní infrastrukturu, takže plnohodnotná nezávislá reprodukce tvrzení „až 85 %“ zatím chybí.

Existují ale první užitečné signály.

Vývojář Rafael Caricio ve veřejném integračním pull requestu naměřil na komunitním portu DeepSeek-V4-Flash průměrně 60,31 tokenu za sekundu, tedy 1,51násobek MTP-1 v testu jednoho souběžného streamu při generování kódu. Zároveň ukázal, že přínos klesá s delším a náročnějším kontextem, protože drafterovi postupně klesá míra akceptace.

Je to důležitá praktická validace mechanismu, ne potvrzení celé produkční křivky DeepSeeku.

Proč na tom záleží právě teď

U chatbotu znamená pomalejší generování několik sekund čekání.

U AI agenta se zpoždění násobí. Agent může během jednoho úkolu přečíst soubory, zavolat nástroje, napsat kód, spustit testy, vyhodnotit chybu a celý cyklus několikrát zopakovat. Pokud jsou tyto kroky závislé jeden na druhém, každé zrychlení inference zkracuje celou kritickou cestu.

Stejná změna ovlivňuje i ekonomiku provozu.

Když server při zachování odezvy zvládne více souběžných požadavků, může poskytovatel snížit jednotkové náklady nebo obsloužit více uživatelů bez okamžitého rozšíření clusteru. To neznamená, že poptávka po GPU zmizí. Efektivnější a levnější inference může naopak otevřít nové scénáře a zvýšit celkovou spotřebu.

DSpark proto není příběh „software porazil hardware“. Je to připomínka, že hodnotu AI neurčuje jen model a počet čipů.

Určuje ji celý systém:

  • jak model dostává práci,
  • jak se požadavky dávkují,
  • co se počítá paralelně,
  • co se ověřuje,
  • jak se kapacita přiděluje pod zátěží,
  • a kolik z výpočtu se nakonec zahodí.

Skutečná pointa

DeepSeek neobešel potřebu výpočetního výkonu. Získal více užitku z výkonu, který už měl.

To je méně dramatické než nový „nejchytřejší model na světě“, ale pro provoz AI možná důležitější. Modelové schopnosti se rychle sbližují a cena samotné inteligence klesá. Rozdíl se proto stále častěji přesouvá do vrstvy kolem modelu: orchestrace, inference, cache, směrování, pozorovatelnost a řízení kapacity.

Další konkurenční výhoda nemusí být ukrytá v nových vahách.

Může vzniknout v tom, jak chytře organizujete práci kolem nich.

Zdroje

Stav ověření k 26. 7. 2026. Produkční benchmarky 60 až 85 % a 57 až 78 % vykázal DeepSeek na vlastním provozu. Nezávislý komunitní test ověřuje směr a dílčí zrychlení, nikoli celou produkční křivku.

Newsletter na LinkedInu

Odebírejte Za hranice inovací

Newsletter Jaroslava Urbánka: rozbory dění v AI a toho, co z něj plyne pro firmy.

Odebírat na LinkedInu

Další krok

Test připravenosti na AI

Osm otázek bez registrace. Z odpovědí vybereme téma, kterým můžete s AI začít. Výsledek je orientační.

Spustit test připravenosti

Další čtení

3 články