Offloading DeepSeek Engram przenosi pamięć AI poza HBM

Offloading DeepSeek Engram przeniósł 189 GiB pamięci modelu poza GPU HBM, a testy z DRAM czasami przewyższały konfigurację opartą wyłącznie na HBM. Wynik ten podważa podstawowe założenie stojące za infrastrukturą dużych modeli. Najszybsza pamięć nie jest automatycznie najlepszym miejscem dla każdego parametru.

SemiAnalysis opublikował nowe eksperymenty 18 września, wykorzystując DeepSeek-V4.1-Flash i jego framework obsługi InferenceX. W testach tablice Engram umieszczono w pamięci DRAM hosta lub w plikach mapowanych w pamięci na lokalnych dyskach NVMe. Ścieżka DRAM poprawiła jedną konfigurację B300 dzięki ograniczeniu równoległości tensorowej, podczas gdy pierwsza implementacja SSD pozostawała wolniejsza i mniej ekonomiczna.

To rozróżnienie ma znaczenie. Engram nie eliminuje popytu na GPU Nvidia ani pamięć o wysokiej przepustowości. Zmienia to, które parametry modelu zasługują na tę ograniczoną pojemność. W najbliższej perspektywie rywalizacja nie dotyczy więc HBM kontra SSD. Chodzi o model wdrożenia wyłącznie z HBM kontra system warstwowy, który przydziela różne obciążenia do HBM, DRAM i pamięci masowej.

Offloading DeepSeek Engram zmienia rozmieszczenie parametrów

Kluczowa zmiana ma charakter architektoniczny: duży blok wyuczonej pamięci może opuścić HBM bez zmuszania całego modelu do działania jak odciążona sieć neuronowa.

DeepSeek wprowadził Engram jako moduł pamięci warunkowej dla modeli językowych. Rozszerza on zwykłe osadzenia tokenów o wyuczone odwołania dla powtarzających się wzorców wielotokenowych. Wzorce te mogą obejmować nazwy, fragmenty kodu, tekst standardowy i często występujące zwroty relacyjne.

Zwykły Transformer często odtwarza takie lokalne wzorce za pomocą warstw uwagi i feed-forward. Engram daje modelowi osobną ścieżkę odwołań. Haszuje sekwencje tokenów, pobiera niewielki zbiór wierszy osadzeń i łączy je z ukrytym stanem modelu.

Oryginalna praca o pamięci warunkowej opisuje to podejście jako drugą formę rzadkości. Mixture-of-Experts, czyli MoE, aktywuje dla każdego tokenu tylko część obliczeń modelu. Engram aktywuje jedynie niewielką część znacznie większej tablicy pamięci.

To rozróżnienie określa, jak sprzęt może obsługiwać model. Ekspert MoE zawiera macierze wag używane do istotnych obliczeń. Przeniesienie go między warstwami pamięci może wymagać dużych transferów dokładnie w niewłaściwym momencie.

Adresy Engram są inne. Zależą od identyfikatorów tokenów i ich lokalnej sekwencji, a nie od pośredniego ukrytego stanu. Środowisko wykonawcze może wiedzieć, których wierszy potrzebuje, zanim późniejsze warstwy modelu zakończą obliczenia.

Ta przewidywalność tworzy okno prefetchingu. Serwer może pobrać wiersze z pamięci hosta, gdy GPU obsługuje wcześniejsze operacje. Jeśli pobieranie zakończy się w tym oknie, model unika znacznej części opóźnień zwykle związanych z offloadingiem.

Opublikowane badania DeepSeek przeskalowały eksperymentalną tablicę Engram do 27 miliardów parametrów. W kontrolowanych porównaniach autorzy zgłosili przewagę nad bazą MoE o równoważnej liczbie parametrów i nakładzie obliczeniowym. Raportowane ulepszenia obejmowały wiedzę faktograficzną, rozumowanie, kod, matematykę i odzyskiwanie informacji z długiego kontekstu.

Dane te pochodziły z modeli badawczych, a nie z dokładnego systemu produkcyjnego testowanego przez SemiAnalysis. Mimo to wyjaśniają, dlaczego Engram nie może być traktowany jako opcjonalne metadane. Staje się częścią ścieżki rozumowania wytrenowanego modelu.

SemiAnalysis wzmocnił ten argument, usuwając Engram podczas inferencji. Według jego analizy w ablacjach z wcześniejszej pracy benchmarki faktograficzne zachowały jedynie 29–44 procent pierwotnej wydajności. Rozumienie tekstu zachowało 81–93 procent.

Ta strata nie dowodzi, że Engram przewyższa każdy model konwencjonalny. Sieć została wytrenowana tak, by zależeć od swojego modułu pamięci. Usunięcie tego modułu powoduje niedopasowanie między treningiem a inferencją.

Eksperyment pokazuje jednak, że operatorzy nie mogą po prostu usunąć tablicy, gdy pamięci zaczyna brakować. Muszą ją wydajnie obsługiwać, skompresować albo umieścić gdzie indziej.

DeepSeek-V4.1-Flash konkretyzuje problem rozmieszczenia. DeepSeek podaje, że model ma szkielet MoE o 552 miliardach parametrów, z 8 miliardami parametrów aktywnych podczas przetwarzania wejścia i 16 miliardami podczas generowania wyjścia. Engram dodaje kolejną dużą pulę pamięci warunkowej.

Wydanie V4.1-Flash deklaruje również pamięć podręczną KV wymagającą jednej czwartej HBM i jednej ósmej miejsca na SSD w porównaniu z poprzednikiem. Pamięć KV przechowuje ponownie używalny stan uwagi z wcześniejszych tokenów. Jest oddzielna od Engram, lecz obie funkcje zmieniają wymagania wobec pamięci serwera.

SemiAnalysis użył około 189 GiB dla tablicy Engram modelu. Mimo to każda przetworzona pozycja tokenu żądała tylko 24 wierszy w dwóch warstwach Engram. Odpowiadało to około 12,4 KiB w całym modelu, czyli 3,1 KiB na GPU w konfiguracji czterech GPU.

Tablica jest ogromna, lecz aktywny odczyt jest niewielki. Ta asymetria jest powodem, dla którego offloading DeepSeek Engram w ogóle działa.

Offloading do DRAM wywiera presję na projekt oparty wyłącznie na HBM

Engram osłabia związek między całkowitą liczbą parametrów a wymaganą pojemnością HBM, nawet gdy przepustowość GPU pozostaje kluczowa.

HBM ma dwie cenne właściwości dla inferencji AI. Zapewnia wysoką przepustowość i znajduje się blisko zasobów obliczeniowych GPU. Te zalety czynią ją naturalnym miejscem dla często używanych wag i rosnącej pamięci podręcznej KV.

Pojemność pozostaje jednak kosztowna z perspektywy systemu. Operator często dodaje GPU, ponieważ model się nie mieści, nawet gdy obciążenie nie potrzebuje ich pełnej mocy obliczeniowej. Dodatkowe akceleratory zwiększają następnie koszty komunikacji i złożoność operacyjną.

Engram oferuje sposób na oddzielenie pojemności od obliczeń. Serwer może utrzymywać gęste warstwy, aktywnych ekspertów i stan wrażliwy na opóźnienia w HBM. Rzadką tablicę pamięci może umieścić w DRAM hosta.

SemiAnalysis przetestował taki układ za pomocą Unified Virtual Addressing, czyli UVA. UVA pozwala GPU adresować przypiętą pamięć hosta w jednej wspólnej przestrzeni adresowej. To samo jądro GPU wybierało i dekwantyzowało wiersze Engram z HBM lub DRAM.

Nie był to zwykły offloading zarządzany przez CPU. GPU uzyskiwało bezpośredni dostęp do przypiętej alokacji hosta. Wykonywanie asynchroniczne pozwalało nakładać pobieranie na inną pracę modelu.

Zaskakujący wynik pojawił się na Nvidia B300. SemiAnalysis podał, że przeniesienie Engram do DRAM pozwoliło jego konfiguracji przejść z czterokierunkowej równoległości tensorowej na dwukierunkową.

Równoległość tensorowa dzieli operacje modelu między wiele GPU. Może umożliwić zmieszczenie dużego modelu, lecz każdy podział dodaje synchronizację i komunikację. Ograniczenie podziału może więc zrekompensować wolniejszą warstwę pamięci.

Według testu wynikowa granica przepustowości i interaktywności B300 poprawiła się nawet 1,6 raza. Przeniesienie tablicy z powrotem do HBM nie dało mierzalnej poprawy wykraczającej poza zmienność między uruchomieniami w tym wczesnym stosie programowym.

To ustalenie odwraca najprostszy argument dotyczący hierarchii pamięci. HBM przyspieszała pojedyncze odwołanie, lecz odwołania stanowiły tylko część kompletnej ścieżki obsługi. Engram zajmował pojemność, która mogłaby wspierać pamięć podręczną KV, batchowanie lub mniejszą replikę.

DRAM poprawił cały system, zmieniając jego topologię. Korzyść nie wynikała z przewagi DRAM nad HBM pod względem surowej szybkości dostępu.

To główna presja wywierana na projektowanie systemów GPU. Operatorzy tradycyjnie oceniali dopasowanie modelu, sumując rozmiar checkpointu, stan środowiska wykonawczego i margines bezpieczeństwa. Engram wymaga klasyfikowania pamięci według wzorca dostępu.

Gorące, gęste wagi wymagające dużej przepustowości nadal preferują HBM. Przewidywalne rzadkie wiersze mogą tolerować DRAM, gdy obliczenia ukrywają transfer. Wiersze z długiego ogona mogą z czasem trafić na NVMe, pod warunkiem że cache'owanie i narzut programowy pozostaną pod kontrolą.

Zmiana ma konsekwencje dla dostawców pamięci. Engram nie kończy popytu na HBM. Eksperymenty SemiAnalysis sugerują natomiast, że dla części konfiguracji inferencyjnych przepustowość może mieć większe znaczenie niż maksymalna pojemność HBM.

Jednocześnie DRAM serwera staje się częścią obwiedni wydajności obsługi modelu. Planowanie pojemności musi uwzględniać przypięte alokacje, kanały pamięci, zachowanie PCIe i rywalizację między replikami.

NVMe również zyskuje potencjalną rolę wykraczającą poza przechowywanie checkpointów i pamięci podręcznej KV. Jego rynek adresowalny rośnie, jeśli parametry modelu są aktywnie obsługiwane z lokalnej pamięci masowej. Ta możliwość zależy jednak od oprogramowania, które uczyni odczyty z pamięci masowej ekonomicznie użytecznymi.

Natychmiastowymi zwycięzcami nie muszą być dostawcy sprzedający największe pule pamięci. Są nimi systemy koordynujące kilka warstw bez zatrzymywania drogich akceleratorów.

Dla nabywców infrastruktury AI całkowity rozmiar modelu staje się słabszym sygnałem zakupowym. Aktywne parametry, bajty pobierane na token, odległość prefetchingu i topologia replik oferują bardziej użyteczne wskazówki.

System o 748 miliardach parametrów może stawiać bardzo inne wymagania sprzętowe niż gęsty model o podobnym rozmiarze. DeepSeek-V4.1-Flash łączy rzadki szkielet z pamięcią warunkową i zmniejszoną pamięcią podręczną KV. Każdy element obciąża inny zasób.

Ta złożoność utrudnia również porównania. Benchmark mierzący jedynie tokeny na sekundę może ukrywać opóźnienia na poszczególnych poziomach współbieżności. Wynik kosztowy może się zmienić, gdy konfiguracja dodaje GPU wyłącznie dla pojemności pamięci.

Najbardziej użyteczne porównanie zestawia przepustowość z interaktywnością widoczną dla użytkownika. Następnie pyta, ile użytecznej pracy wykonuje każdy kompletny serwer, a nie jak szybko działa pojedyncze odizolowane jądro.

Dlaczego Engram działa poza pamięcią GPU

Deterministyczne adresowanie daje środowisku wykonawczemu czas na pobranie pamięci, a rzadki dostęp utrzymuje każdy transfer na tyle małym, by mógł nakładać się na obliczenia.

Engram zaczyna od N-gramów, czyli krótkich sekwencji sąsiadujących tokenów. Architektura kompresuje słownictwo tokenizera, haszuje lokalne sekwencje za pomocą wielu głów i mapuje te hasze na wyuczone wiersze.

Kompresja słownictwa ma znaczenie, ponieważ tokenizery często przypisują różne identyfikatory tekstowi podobnemu wizualnie. Wielkie litery, odstępy i formy Unicode mogą fragmentować powtarzające się wzorce. W pracy zgłoszono 23-procentowe zmniejszenie efektywnego słownictwa dla słownictwa liczącego 128 000 tokenów.

Pobrane osadzenia nie trafiają do modelu w niezmienionej postaci. Bramka uwzględniająca kontekst kontroluje, w jakim stopniu każde odwołanie wpływa na bieżący ukryty stan. Lekka konwolucja dodaje pobliski kontekst, zanim wkład pamięci trafi do późniejszych warstw.

Ten projekt pomaga wyjaśnić zarówno wartość Engram, jak i jego ograniczenia. Tablica przechowuje ponownie używalne wzorce statystyczne, lecz model nadal decyduje, w jakim stopniu z nich korzystać. Nie jest to konwencjonalna baza danych zawierająca uporządkowane rekordy faktograficzne.

SemiAnalysis przeskanował wzorce z wysoką wartością bramki w DeepSeek-V4.1-Flash. Znalazł nazwy, fragmenty kodu, sformułowania relacyjne, licencje, fragmenty bibliografii i tekst standardowy stron internetowych. Jeden nietypowy przykład odnosił się do serii gier Ace Attorney.

Wyniki te sugerują, że tablica optymalizuje przewidywanie następnego tokenu, a nie ludzkie oceny wartościowej wiedzy. Powtarzalne formatowanie może stać się użyteczne, jeśli stanowi skrót predykcyjny.

To ustalenie komplikuje cache'owanie. Silna bramka nie musi wskazywać często używanego wiersza. Wiersz może mieć dużą wartość po pobraniu, ale rzadko pojawiać się w ruchu produkcyjnym.

Środowisko wykonawcze nie może też uniknąć każdego słabego odwołania po zobaczeniu jego bramki. Obliczenie bramki wymaga odpowiedniego klucza, który już wywołał pobranie. Pominięcie tego odczytu wymagałoby oddzielnego predyktora działającego przed dostępem do pamięci.

Częstotliwość dostępu nadal powinna podlegać rozkładowi długiego ogona. Częste słowa, wzorce programistyczne i rutynowa składnia powinny występować częściej niż rzadkie encje. Dzięki temu wielopoziomowa pamięć podręczna staje się wiarygodnym założeniem.

Najczęściej żądane wiersze mogłyby pozostać w HBM. Większy zestaw roboczy mógłby znajdować się w pamięci DRAM hosta. Rzadkie wiersze mogłyby być przechowywane na NVMe i trafiać do szybszych warstw, gdy ruch czyni je użytecznymi.

Badanie CXL memory research rozszerza tę samą ideę poza bezpośrednio podłączoną pamięć DRAM pojedynczego serwera. Jego autorzy proponują współdzielenie pamięci Engram przez Compute Express Link, który obsługuje precyzyjny dostęp do współdzielonych urządzeń pamięciowych.

Propozycja pozostaje badaniem, a nie dowodem opłacalności w środowisku produkcyjnym. CXL wprowadza własne kwestie związane z opóźnieniami, topologią i oprogramowaniem. Mimo to pokazuje, jak pamięć warunkowa zmienia granice systemu.

Operator mógłby skalować pulę wyszukiwania niezależnie od mocy obliczeniowej GPU. Kilka akceleratorów mogłoby współdzielić pojemność zamiast duplikować całą tabelę w każdej replice GPU.

Prefetching jest centralnym mechanizmem we wszystkich tych projektach. Warstwy Engram nie mogą znajdować się dowolnie wcześnie, jeśli opóźnienie pamięci masowej ma zostać ukryte. Więcej poprzedzających obliczeń tworzy dłuższe okno na pobranie danych.

Jakość modelu może jednak pociągać w przeciwnym kierunku. Wczesna interwencja pamięci pomaga sieci uniknąć poświęcania pierwszych warstw na odtwarzanie typowych lokalnych wzorców. Zbyt późne umieszczenie Engram może osłabić tę korzyść.

Tworzy to rzeczywisty problem współprojektowania. Badacze modeli wybierają warstwy wstawienia, wymiary tabel, zachowanie haszowania i bramki. Inżynierowie środowiska wykonawczego projektują wokół tych wyborów kolejki prefetchingu, pamięć podręczną, kernele i ścieżki transferu.

Zespoły sprzętowe decydują następnie, jaką przepustowość i pojemność powinna zapewniać każda warstwa. Żadnej z tych decyzji nie da się zoptymalizować niezależnie.

Artykuł DeepSeek wskazywał na zależność w kształcie litery U między parametrami przeznaczonymi na obliczenia MoE a parametrami przeznaczonymi na pamięć Engram. Zbyt mało pamięci pozostawiało powtarzalne wzorce neuralnemu rdzeniowi. Zbyt dużo pamięci zmniejszało zasoby obliczeniowe dostępne dla innych zadań.

Wynik ten przemawia przeciwko traktowaniu Engram jako nieograniczonej, taniej pojemności. Więcej wierszy tabeli może poprawiać stratę walidacyjną, ale tylko w zrównoważonym systemie. Jakość danych treningowych również determinuje, czego uczą się te wiersze.

Szersza implikacja architektoniczna jest istotna. Skalowanie nie oznacza już umieszczania każdego nowego parametru obok arytmetyki GPU. Model może zwiększać pojemność poprzez przewidywalne rzadkie wyszukiwanie, rezerwując kosztowną przepustowość dla dynamicznych obliczeń.

Offloading SSD Nie Jest Jeszcze Tanią Odpowiedzią

Pierwszy eksperyment z NVMe zmniejszył zarezerwowaną pojemność DRAM, lecz jego nieoptymalna ścieżka danych przegrała z przypiętą pamięcią DRAM zarówno pod względem szybkości, jak i efektywności.

SemiAnalysis zastąpiło alokację Engram o wielkości 189 GiB plikami mapowanymi w pamięci na lokalnych dyskach SSD. Plik mapowany w pamięci pozwala systemowi operacyjnemu udostępniać pamięć masową za pośrednictwem stron pamięci wirtualnej. Niedawno używane strony mogą pozostać w pamięci podręcznej systemu plików.

Takie podejście oferuje elastyczność operacyjną. System operacyjny może odzyskiwać strony z pamięci podręcznej, gdy inne aplikacje potrzebują pamięci. Operatorzy unikają trwałego przypinania całej tabeli Engram w DRAM.

Jednak rozgrzana pamięć podręczna stron nie czyni ścieżki SSD równoważną natywnemu offloadingowi DRAM. Prototyp nadal przenosił identyfikatory wierszy do CPU, usuwał duplikaty, zbierał wiersze do przypiętych buforów i kopiował je z powrotem.

Następnie dekwantyzował wybrane wiersze na GPU. Kroki te były wykonywane między segmentami pracy GPU, a nie przez bezpośredni kernel UVA używany dla przypiętej pamięci hosta.

Każdy etap zwiększa konieczność koordynacji. Planowanie CPU, transfery identyfikatorów, zbieranie wierszy, zarządzanie buforami i kopie do GPU mogą kosztować więcej niż fizyczny odczyt z pamięci masowej. Plik w pamięci podręcznej może więc pozostawać wolniejszy od przypiętej pamięci DRAM, nawet gdy żądanie nie dociera do pamięci NAND flash.

Wyniki B200 ujawniły tę różnicę. Przy blisko 125 tokenach na sekundę dla każdego użytkownika konfiguracja DRAM zapewniła 121 milionów tokenów łącznie na jednostkę wydatków. Ścieżka SSD zapewniła 52 miliony.

DRAM dostarczyła zatem około 2,3 razy więcej tokenów w tym zmierzonym porównaniu. Zdominowała również obserwowane konfiguracje SSD pod względem interaktywności P90, która mierzy doświadczenie wolniejszych żądań zbliżonych do końca rozkładu.

Badacze nie mogli włączyć GPUDirect Storage, czyli GDS, na potrzeby testu. GDS może przenosić dane między NVMe a pamięcią GPU przy mniejszym zaangażowaniu CPU. Jego brak ogranicza to, co eksperyment mówi o zoptymalizowanej ścieżce pamięci masowej.

Wynik nie powinien być przedstawiany jako dowód, że NVMe nie może obsługiwać Engram. Pokazuje on, że tani nośnik danych nie tworzy automatycznie taniej inferencji.

Cztery GPU B200 pozostały w serwerze. Tak samo jak CPU, sieć, zasilanie i większość infrastruktury pomocniczej. Zastąpienie DRAM dyskami SSD zmniejszyło jedno wymaganie dotyczące pojemności, nie zmniejszając kosztownych elementów konfiguracji.

Korzyść ekonomiczna wymaga drugiego efektu. Offloading SSD musi umożliwić tańszy serwer, zmieścić więcej produktywnych replik, obsłużyć większy model lub uwolnić DRAM dla innego wartościowego obciążenia.

Prototyp nie osiągnął żadnego z tych rezultatów w zmierzonej konfiguracji. Jego pamięć podręczna systemu plików mogła również zużywać znaczną część DRAM, którą zaplecze plikowe miało oszczędzać.

Lokalność obciążenia tworzy kolejną niepewność. Stabilna usługa z powtarzalnymi promptami mogłaby utrzymywać użyteczną rozgrzaną pamięć podręczną. Zróżnicowane obciążenie agentowe mogłoby dotykać szerszego zakresu N-gramów i powodować więcej chybień pamięci masowej.

Batching ponownie zmienia równanie. Wiele żądań może ponownie wykorzystywać wiersze w ramach partii, a deduplikacja zmniejsza transfery. Jednak większe partie zwiększają również wymagania dotyczące pamięci podręcznej KV i mogą zmieniać opóźnienia.

Same specyfikacje sprzętowe SSD nie przewidzą wyniku. Składają się na niego opóźnienie odczytów losowych, głębokość kolejki, zachowanie systemu plików, rozmiar strony, narzut CPU i polityka cache’u.

Systemy rekomendacyjne stanowią użyteczny precedens historyczny. Od lat obsługują duże tabele embeddingów z pamięci warstwowej. Niektóre systemy przechowują popularne wiersze w DRAM, a długi ogon umieszczają na SSD.

Ruch Engram w modelach językowych jest wystarczająco podobny, aby zapożyczać pomysły, ale nie jest identyczny. Generowanie autoregresyjne nakłada rygorystyczne wymagania dotyczące sekwencyjnych opóźnień. Opóźnienie na jednej pozycji tokena może wstrzymać kolejne pozycje.

AgentX czyni ten problem bardziej widocznym. Reprezentuje ruch związany z kodowaniem agentowym o długim kontekście i wielu turach, a nie jeden krótki syntetyczny prompt. Takie obciążenia przeplatają intensywne przetwarzanie wejścia z generowaniem wrażliwym na opóźnienia.

Przypadek użycia pamięci masowej poprawi się tylko wtedy, gdy oprogramowanie potraktuje Engram jako podstawowy prymityw obsługi. Ogólny plik mapowany w pamięci jest przydatny do eksperymentów, ale pozostawia zbyt wiele pracy na ścieżce kontrolowanej przez CPU.

Przyszłe projekty wymagają bezpośredniego I/O, asynchronicznych kolejek, cache’owania świadomego wierszy i przewidywalnych harmonogramów prefetchingu. Mogą też wymagać układów pamięci masowej dostosowanych do skwantyzowanych wierszy Engram.

NVMe pozostaje więc szansą, a nie obecnym wyborem domyślnym. DRAM już pokazała, że warstwowanie może poprawić cały system. SSD nadal potrzebuje stosu obsługowego zaprojektowanego wokół wzorca rzadkiego dostępu modelu.

AgentX Pokazuje Przewagę Oprogramowania Wokół Nowych Architektur

Engram zmienia rozmieszczenie pamięci, ale wsparcie oprogramowania dostępne w dniu premiery nadal określa, który akcelerator może przekształcić tę architekturę w użyteczną usługę.

SemiAnalysis oceniło DeepSeek-V4.1-Flash na systemach Nvidia H100, H200, B200, B300, GB200 i GB300. Przetestowało również AMD MI355X za pomocą frameworka InferenceX.

Pomiary InferenceX measurements wykorzystują rzeczywisty sprzęt i śledzą przepustowość względem interaktywności. AgentX dostarcza obciążenie związane z kodowaniem o długim kontekście, mające przypominać powtarzające się sesje zorientowane na narzędzia.

Według SemiAnalysis ścieżka vLLM firmy Nvidia działała na wszystkich sześciu testowanych platformach Nvidia w momencie uruchomienia modelu. Referencyjny obraz kontenera AMD nie był publicznie dostępny w ciągu pierwszych 23 godzin.

Wsparcie AMD pojawiło się później, ale wczesna luka wydajnościowa pozostała znacząca w pomiarach analityka. Siedem dni po premierze SemiAnalysis umieściło wydajność MI355X na jednostkę wydatków od dwóch do czterech razy za B200.

Są to wrażliwe na dostawcę twierdzenia jednej organizacji benchmarkingowej. Zależą od założeń chmurowych, wersji środowiska wykonawczego, kwantyzacji, topologii i szybkich zmian oprogramowania. Nie należy ich uogólniać na każdy model ani każde obciążenie AMD.

Ujawniają jednak ważne ograniczenie. Architektura może być zaprojektowana z myślą o offloadingu, ale wdrożenie nadal zależy od kerneli, przechwytywania grafów, adresowania pamięci, kwantyzacji i rozproszonego harmonogramowania.

Offloading DeepSeek Engram wymaga więcej niż wystarczającej przepustowości PCIe. Środowisko wykonawcze musi nakładać transfery na obliczenia bez przerywania grafów dekodowania. Musi też efektywnie wybierać i dekwantyzować wiersze na każdej platformie.

Nowy model testuje zatem ekosystem akceleratorów, zanim zespoły sprzętowe mają miesiące na jego dostrojenie. Znajomość systemu przez opiekunów projektu i działające procesy wydawnicze stają się częścią wydajności.

Ta dynamika wzmacnia pozycję Nvidii w oprogramowaniu, nawet gdy architektura modelu zmniejsza pojemność HBM wymaganą na replikę. Mniej GPU na replikę może ograniczyć komunikację, ale każde pozostałe GPU potrzebuje dojrzałych kerneli i integracji ze środowiskiem wykonawczym.

Wpływ na całkowity popyt na akceleratory nie jest prosty. Lepsze wykorzystanie pamięci może zmniejszyć liczbę GPU wymaganą dla jednej repliki modelu. Niższe koszty obsługi mogą również zwiększać popyt, czyniąc więcej zastosowań ekonomicznie opłacalnymi.

Engram może zachęcać do większych modeli, ponieważ pamięć warunkowa skaluje się niezależnie od aktywnych obliczeń. Operatorzy mogą wykorzystać zaoszczędzoną HBM do obsługi większej liczby równoczesnych sesji zamiast kupować mniej akceleratorów.

Według materiałów premierowych DeepSeek zmniejszył również wymagania pamięci podręcznej KV w V4.1-Flash. Offloading Engram i kompresja KV razem uwalniają pamięć z dwóch różnych kierunków.

To połączenie ma znaczenie dla inferencji agentowej. Agenci przenoszą długie historie, wyniki narzędzi, kod i plany pośrednie. Ich pamięć podręczna KV może zajmować znaczną pojemność, nawet gdy wagi modelu już się mieszczą.

Serwer, który przenosi rzadko używane tabele wyszukiwania do DRAM, może przeznaczyć więcej HBM na te aktywne sesje. Praktyczna korzyść może objawić się jako wyższa współbieżność, a nie mniejszy model fizyczny.

Sceptyczne spojrzenie pozostaje konieczne. Reprodukcja Engram przez SemiAnalysis wykorzystała udostępniony kod i ustawienia treningowe, ponieważ DeepSeek nie opublikował dwóch wytrenowanych modeli badawczych z oryginalnego artykułu. Zachowanie produkcyjne może różnić się od kontrolowanych eksperymentów skalowania.

Ścieżka SSD była wyraźnie nieoptymalna. Wyniki Nvidii i AMD uchwyciły wczesne stosy oprogramowania, które będą się zmieniać. Nawet najsilniejszy wynik DRAM zależał od konkretnej topologii B300 i granicy obciążenia.

Engram przechowuje też wszystko, co nagradza trening. Większa pojemność może zachowywać szablonowy kod i przypadkowe wzorce obok użytecznych encji lub kodu. Lepsza alokacja pamięci nie gwarantuje lepszego doboru danych.

Dowody wspierają węższy wniosek. Pamięć warunkowa jest technicznie zgodna z niższymi warstwami pamięci, a DRAM może poprawiać pełną wydajność obsługi. Nie ustanawia to jeszcze jednej uniwersalnej konfiguracji.

Trzy Sygnały Zadecydują o Wpływie DRAM i NVMe

Kolejna faza zależy od zoptymalizowanej obsługi SSD, powtarzalnych korzyści topologicznych oraz szerokiego wsparcia środowisk wykonawczych poza jedną premierą modelu.

Pierwszym sygnałem jest zoptymalizowana implementacja NVMe wykorzystująca bezpośrednią ścieżkę zorientowaną na GPU. Ważne porównanie nie dotyczy szczytowej przepustowości SSD. Dotyczy pełnej granicy przepustowości i interaktywności P90 względem przypiętej pamięci DRAM.

Wsparcie dla GPUDirect Storage usunęłoby część obiegu przez CPU. Natywna deduplikacja wierszy, asynchroniczny prefetching i układy pamięci masowej świadome Engram mogłyby usunąć dalszy narzut.

Jeśli zoptymalizowana ścieżka zbliży się do wydajności DRAM, jednocześnie istotnie zmniejszając wymaganą pamięć hosta, szansa dla NVMe stanie się wiarygodna. Jeśli SSD z rozgrzaną pamięcią podręczną nadal będzie znacznie odstawać, Engram zamiast tego wzmocni popyt na DRAM.

Drugi sygnał to to, czy mniejsze topologie replik powtarzają się w różnych konfiguracjach sprzętowych i obciążeniach. Przejście SemiAnalysis na B300 z czterokierunkowego do dwukierunkowego równoleglenia tensorowego przyniosło najistotniejszy rezultat.

Niezależne testy powinny objąć B200, H200, MI355X oraz przyszłe systemy. Powinny uwzględniać różne długości kontekstu, rozmiary wsadów, poziomy współbieżności i stany pamięci podręcznej.

Powtarzalne zyski potwierdziłyby, że offload Engram zmienia ekonomikę serwerów dzięki ograniczeniu komunikacji. Brak możliwości ich odtworzenia zawęziłby wniosek do jednej wczesnej konfiguracji.

Trzecim sygnałem jest adopcja w ekosystemie. DeepSeek-V4.1-Flash stanowi widoczny test, lecz pamięć podobna do Engram musi rozpowszechnić się w większej liczbie rodzin modeli i silników obsługujących inferencję, aby przeobrazić popyt na sprzęt.

Raport SemiAnalysis wskazuje na powiązane mechanizmy N-gram w modelach LongCat i Qwen. Badacze zaproponowali również współdzieloną pojemność Engram za pośrednictwem CXL. Podejścia te wymagają stabilnego wsparcia w vLLM, SGLang i środowiskach wykonawczych dostawców.

Szeroka adopcja wzmocniłaby popyt na zrównoważone serwery z większą przepustowością DRAM, wydajnym lokalnym NVMe i elastycznymi interkonektami. Ograniczona adopcja pozostawiłaby Engram jako ważną optymalizację specyficzną dla DeepSeek.

Deweloperzy powinni śledzić receptury wdrożeniowe, a nie nagłówki o liczbie parametrów. Nabywcy korporacyjni powinni żądać wyników wydajności dla własnych długości kontekstu i celów opóźnień. Zespoły infrastruktury powinny osobno mierzyć stany zimnej, rozgrzanej i mieszanej pamięci podręcznej.

Pracownicy wiedzy odczują rezultat pośrednio. Lepsze rozmieszczenie pamięci może wspierać dłuższe sesje, niższe opóźnienia i szerszy dostęp do zaawansowanych modeli. Korzyści te mają znaczenie tylko wtedy, gdy kompletne aplikacje wykorzystują je niezawodnie.

Zespoły oceniające systemy AI powinny zachowywać własne dowody obok deklaracji z benchmarków. Przeszukiwalna baza wiedzy inżynieryjnej może utrzymać powiązanie kart modeli, wersji środowisk wykonawczych i wewnętrznych wyników testów.

Offloadowanie DeepSeek Engram nie oznacza końca inferencji zdominowanej przez HBM. To dowód, że architektura modelu może przede wszystkim decydować, które parametry zasługują na HBM. Kolejne pytanie brzmi, czy zoptymalizowane NVMe i współdzielona pamięć mogą powtórzyć wynik DRAM bez przenoszenia wąskiego gardła do oprogramowania.