DSpark utrudnia Nvidii sprzedaż racków LPX: firma liczy na „drugi zakup”

Nvidia ma pewny, duży biznes GPU. Pytanie dotyczy kolejnej warstwy sprzętu, którą spółka chce na nim zbudować i sprzedawać dodatkowo.

Chodzi o wyspecjalizowany rack do decode: Groq 3 LPX. To rozwiązanie wymaga osobnej decyzji zakupowej od klientów, którzy wcześniej zainwestowali w systemy Vera Rubin. Taki „drugi zakup” pojawia się tylko wtedy, gdy przewaga wydajności nad ogólnymi GPU jest na tyle duża, by uzasadnić dodatkowy wydatek.

DeepSeek uruchomił DSpark i sprawił, że ta decyzja może być trudniejsza do przeforsowania.

Nvidia podkreśla też, że ma nowe zadanie: sprzedać wyspecjalizowany sprzęt do decode obok platformy GPU, celując w najbardziej wymagające scenariusze agentic AI.

Największy sygnał z perspektywy inwestorów dotyczy tak zwanego „attach rate”, czyli odsetka klientów, którzy dokupują LPX jako dodatkową jednostkę. Jeśli wskaźnik będzie odpowiednio wysoki, można utrzymać oczekiwania co do przyszłych przychodów segmentu Data Center.

Nvidia opublikowała też bardzo mocne wyniki: przychody w wysokości 81,6 mld USD, z czego 75,2 mld USD pochodzi z Data Center. GAAP gross margin wyniosła 74,9%.

Nvidia stawia „nowy zakład”: LPX jako specjalny rack do decode

Dotychczasowa logika jest prosta: sprzedaż GPU do dużych dostawców usług w chmurze (hyperscalers) to główny, utrwalony biznes.

Nowy cel jest inny. Nvidia chce sprzedawać rack do decode jako niezbędne ulepszenie dla obciążeń, które najbardziej wymagają niskich opóźnień i wysokiej przepustowości.

Tym rackiem jest Groq 3 LPX. Ma być zbudowany wokół 256 akceleratorów Groq LPU. Pojedynczy LPU ma mieć 500 MB pamięci SRAM na chipie, działającej z przepustowością 150 terabajtów na sekundę, czyli około siedem razy większą przepustowością pamięci niż w GPU Vera Rubin.

Nvidia podaje, że w połączeniu z systemem Vera Rubin NVL72 taka konfiguracja może zapewniać nawet 35 razy wyższą przepustowość inferencji na megawat dla modeli „trillion-parameter”, czyli modeli o parametrach rzędu bilionów.

Vera Rubin jest już w pełnej produkcji. LPX ma trafiać do wczesnych klientów w drugiej połowie 2026.

Sedno ryzyka: osobna decyzja zakupowa

Problem nie dotyczy tego, czy Nvidia ma klientom co sprzedawać. Ryzyko jest bardziej „ekonomiczne”: jeśli klient już kupił Rubin, to do LPX musi wrócić drugi raz.

Ten drugi wydatek jest łatwiejszy do obrony wtedy, gdy decode na ogólnych GPU jest wyraźnie za wolne albo zbyt kosztowne, gdy rośnie długość kontekstu i obciążenia użytkowników.

DSpark jest zaprojektowany właśnie tak, by zmniejszać presję na decode, co może osłabiać argument za dodatkowym rackiem.

Dlaczego decode jest tak ważne w modelach językowych

Wnioskowanie w dużych modelach językowych (LLM) dzieli się na dwie fazy.

Najpierw odbywa się prefill — przetwarzanie promptu wejściowego i budowanie wstępnego stanu pamięci.

Potem następuje decode, czyli generowanie tokenów wyjściowych krok po kroku. Ta część pracuje na już przygotowanym stanie pamięci pod stałą presją ze strony aktywnych użytkowników, długich odpowiedzi i bardzo długich okien kontekstu.

Decode bywa wolniejsze i bardziej wymagające pamięciowo, a kluczowym elementem nacisku jest tak zwany KV cache. To struktura pamięci, która rośnie wraz z długością kontekstu i musi być odczytywana przy generowaniu każdego kolejnego tokenu.

W długokontextowych, agentic scenariuszach KV cache może zużywać większość dostępnej pamięci GPU.

To właśnie obszar, który ma monetyzować LPX. Jeśli decode pozostanie dominującym ograniczeniem jakości i kosztów inferencji, LPX może stać się elementem wymaganym w poważnych wdrożeniach agentic.

Rozproszenie (disaggregation) to trend całej branży

Ocena LPX nie może opierać się wyłącznie na planach Nvidii. Rozdzielenie prefill i decode na wyspecjalizowanym sprzęcie nie jest wyłącznie pomysłem Nvidii.

W marcu 2026 roku AWS i Cerebras ogłosiły wieloletnią współpracę, w której silniki Cerebras CS-3 trafiają do centrów danych AWS. Mają być połączone z Trainium 3 do prefill oraz Cerebras CS-3 do decode. Komponenty ma łączyć Amazon Elastic Fabric Adapter (EFA).

Ten układ ma być logicznie podobny do koncepcji Nvidii: prefill i decode wymagają różnych układów, a trzymanie ich na tym samym sprzęcie ogranicza wydajność.

AWS opisał rezultat jako możliwość inferencji nawet o rząd wielkości szybszej niż obecne rozwiązania oparte wyłącznie na GPU.

Usługa ma być uruchamiana przez Amazon Bedrock w drugiej połowie 2026 roku — w tym samym horyzoncie co LPX.

W tle rośnie scenariusz „rywala wewnątrz chmury”

Jeśli duzi dostawcy usług w chmurze dojdą do tego samego wniosku architektonicznego i zbudują własne odpowiedniki, to LPX Nvidii przestaje być oczywistym uzupełnieniem.

Wtedy attach rate LPX sprowadza się do pytania, czy klienci, którzy kupili Rubin, dokupią jeszcze LPX jako dodatkowy rack. Alternatywa to kierowanie najbardziej wrażliwych na opóźnienia obciążeń decode do rozwiązań oferowanych natywnie przez hyperscalers.

DSpark jako najnowszy krok w dłuższym schemacie

DeepSeek wypuścił DSpark 27 czerwca 2026 roku. Nie jest to osobny model. To moduł speculative decoding dołączany do DeepSeek-V4-Flash i V4-Pro, który działa już w produkcji.

Mechanizm jest następujący: mniejszy model „draft” proponuje naraz kilka tokenów, a większy model „target” weryfikuje je równolegle. Gdy propozycje draftu trafiają, wiele tokenów można zaakceptować w pojedynczym kroku.

Oznacza to, że na jedno wyjście potrzeba mniej pełnych przebiegów decode. Spada też obciążenie pamięci i obliczeń na token.

DeepSeek podaje, że szybkość generowania na jednego użytkownika poprawia się o 60% do 85% na V4-Flash oraz o 57% do 78% na V4-Pro w porównaniu z wcześniejszym punktem odniesienia. Do tego przepustowość przy stałym poziomie usługi ma być wyższa o 51%.

DeepSeek wskazuje też, że DSpark jest dostępny w open source na licencji MIT i działa już w produkcji. Towarzyszące narzędzie treningowe DeepSpec ma już rozszerzenia na rodziny modeli Qwen i Gemma.

Ważna uwaga: DSpark i LPX nie muszą działać wprost „przeciwko sobie”

Nvidia dopuszcza speculative decoding również w swojej architekturze LPX. Dynamo ma orkiestrację przepływów draft-and-verify między GPU i LPU.

Najbardziej krytyczny wariant scenariusza „niedźwiedzi” brzmi jednak tak: jeśli DSpark uruchamiany na samych, ogólnych GPU Vera Rubin daje wystarczająco wysoką efektywność inferencji, to drugi rack może być zbędny w większości wdrożeń.

DeepSeek ogranicza problem pamięciowy jeszcze zanim sprzęt zaczyna być potrzebny

DSpark nie jest pierwszym krokiem w tym kierunku. DeepSeek wcześniej zmniejszał problem z pamięcią, który zwykle uzasadnia tego typu wyspecjalizowany sprzęt.

Chodzi o architekturę MLA wdrażaną od V2 w kolejnych wersjach modeli. Zamiast trzymać pełny stan pamięci dla przeszłego kontekstu, DeepSeek zapisuje skompresowaną reprezentację tego kontekstu.

Praktyczny efekt jest taki, że DeepSeek-V4-Pro ma wymagać około 10% pamięci, jakiej potrzebował V3.2 do rozmów o długości miliona tokenów. Mniejsza presja pamięci oznacza mniejszą pilność dla sprzętu, którego głównym zadaniem jest obsługiwanie tej presji.

Co to znaczy dla inwestorów: to ten sam problem, ale inne rozwiązanie

Jasny łańcuch zależności jest taki.

Decode jest problemem pamięci i opóźnień.

LPX jest sprzętowym rozwiązaniem tego problemu.

DSpark i MLA to rozwiązania programowe atakujące tę samą przeszkodę.

Ponieważ są otwarte, darmowe i działają w produkcji, konkurencja dla hardware’owego „wąskiego gardła” rośnie.

Dlaczego rynek może nie wyceniać całego ryzyka

To nie jest historia o tym, że Nvidia przegrywa rynek infrastruktury AI. Hyperscalers już zabezpieczyli przydziały na Vera Rubin.

Jensen Huang potwierdził, że do 2027 roku łączne zamówienia na Blackwell i Rubin przekraczają 1 bln USD. Ta kwota obejmuje systemy GPU i powiązaną sieć. Nie obejmuje jednak racków LPX, systemów CPU Vera ani pamięci masowych — czyli rzeczy, które są dodatkami.

Spór jest węższy: LPX musi zapewniać wystarczające, mierzalne korzyści w opóźnieniach i przepustowości w porównaniu z samymi GPU Rubin uruchamiającymi rozwiązania podobne do DSpark. Musi to też zrobić, konkurując z decode oferowanym natywnie przez hyperscalera, bez dodatkowych „tarć” integracyjnych.

To wyzwanie rośnie w dwóch obszarach naraz: oprogramowanie staje się coraz bardziej wydajne, a konkurencja dla wyspecjalizowanego sprzętu do decode poszerza się.

Jednocześnie może rosnąć liczba tokenów generowanych w usługach, ale spadać intensywność sprzętowa na token. Tego efektu rynek może nie uwzględniać w pełnej skali.

Jak wygląda możliwe „narażenie” finansowe

Kluczowe jest jedno pytanie o liczby na przyszłość.

Konsensus dla przychodów Data Center w roku fiskalnym 2027 wynosi blisko 343 mld USD — według S&P Global Visible Alpha. Oznacza to dalszy wzrost kwartał do kwartału w trakcie wdrażania rampy Vera Rubin.

Konsensus dla marży brutto w Data Center na rok fiskalny 2027 wynosi 76,3%, czyli jest nieco poniżej poziomów z 2024 i 2025.

Scenariusz „niedźwiedzi” dla LPX nie zagraża popytowi na GPU. Ma zagrażać dodatkowej części przychodów: rackom LPX, rozproszonemu środowisku do serwowania oraz premiowym konfiguracjom sieci i pamięci masowej uzasadnianym najgorszymi obciążeniami decode.

Jeśli LPX trafi głównie do najbardziej wymagających wdrożeń pod kątem współbieżności i długości kontekstu, a nie szeroko do wszystkich scenariuszy agentic, wtedy trudniej będzie uzasadnić dodatkową warstwę przy obecnych wielokrotnościach.

Co musiałoby się wydarzyć, żeby scenariusz „niedźwiedzi” nie sprawdził się

Warunek, który mógłby go obalić, jest prosty: LPX staje się elementem koniecznym w wdrożeniach agentic, a nie tylko opcją premium.

Jeśli dostawcy chmur raportują poprawę poziomu usług, którą można osiągnąć wyłącznie wtedy, gdy LPX jest podłączony do Rubin, i ujawniają to publicznie, argument po stronie Nvidii rośnie.

Nvidia ma też raportować zapotrzebowanie na racki LPX osobno od ogólnego popytu na GPU Rubin w kolejnych rozmowach o wynikach, a liczby mają być na tyle duże, by miały znaczenie.

Stack rozproszenia AWS–Cerebras ma pokazać się jako trudny do skalowania lub napotykać ograniczenia związane z opóźnieniami przez EFA między Trainium i CS-3, co kierowałoby klientów do ściślejszego współprojektowania GPU–LPU, jakie daje LPX.

Speculative decoding w stylu DSpark ma też wykazywać słabe wskaźniki akceptacji w produkcyjnych scenariuszach wnioskowania i w złożonych przepływach agentic, gdzie wynik jest mniej przewidywalny.

Architektury kompresji KV mają sprawiać trudności w skalowaniu poza rodzinę modeli DeepSeek.

Wreszcie, luka kompatybilności z CUDA ma domykać się już wraz z generacją LP35, usuwając istotną barierę wdrożeń.

Co z kolei musiałoby potwierdzić scenariusz „niedźwiedzi”

Scenariusz „niedźwiedzi” byłby bardziej wiarygodny, gdyby Nvidia mówiła szeroko o popycie na Vera Rubin w rozmowach o wynikach, ale bez dowodów na poziom attach rate LPX.

Dodatkowe potwierdzenie to sytuacja, w której hyperscalers na masową skalę wdrażają speculative decoding w stylu DSpark oraz rozwiązania oparte o MLA, a infrastruktura raportuje niższą intensywność sprzętową na token.

Warto też obserwować tempo wdrożeń w uruchomieniu przez Bedrock: jeśli szybko okaże się, że klienci kierują decode wrażliwe na opóźnienia do rozwiązań natywnie dostarczanych przez hyperscalers zamiast do LPX.

Sygnałem byłby też szybszy spadek cen tokenów niż spadek kosztów sprzętu Nvidii, co skracałoby okres zwrotu z inwestycji w LPX.

Na koniec, mocny sygnał to pojawienie się podobnych zysków efektywności w rodzinach otwartych modeli — w Qwen, Gemma i innych — dzięki czemu problem staje się „architektoniczny” i rozprzestrzenia się poza jednego dostawcę.