Analiza 4-hi HBM SemiAnalysis: dlaczego krótsze stosy mogą wygrać w inferencji AI
SemiAnalysis podważa wyścig branży pamięci AI ku coraz wyższym stosom, argumentując, że 4-hi HBM może zapewnić pełną przepustowość przy wykorzystaniu zaledwie jednej trzeciej liczby układów DRAM.
To istotne twierdzenie, ponieważ producenci akceleratorów od lat zwiększają wysokość stosów pamięci. Większa liczba warstw zwiększała pojemność, wspierała większe modele i pomogła ustanowić pamięć o wysokiej przepustowości jako kluczowy element obliczeń AI.
Analiza 4-hi HBM SemiAnalysis wskazuje, że inferencja zmienia dziś tę kalkulację. Systemy rack-scale zapewniają większą łączną pojemność, podczas gdy kwantyzacja i przenoszenie pamięci podręcznej ograniczają ilość danych, które musi przechowywać każdy GPU.
Raport nie twierdzi, że każde obciążenie wymaga mniej pamięci. Trening, duże batch’e i przyszłe modele nadal mogą uzasadniać wyższe stosy. Jego mocniejszy argument dotyczy interaktywnej inferencji, gdzie przepustowość często ogranicza generowanie tokenów, zanim pojemność stanie się deficytowa.
Powstaje w ten sposób bezpośrednia rywalizacja między dwoma priorytetami projektowymi. Jeden faworyzuje maksymalną pojemność pamięci na akcelerator. Drugi maksymalną przepustowość tokenów z każdego ograniczonego wafla DRAM.
Donoszone ograniczenie pamięci w Nvidia Rubin Ultra stanowi bezpośredni sygnał. SemiAnalysis podaje, że akcelerator będzie wyposażony w 192GB HBM, wobec 288GB w standardowym Rubin i Blackwell Ultra.
Firma nie przedstawiła publicznie szczegółów konfiguracji 4-hi Rubin Ultra. Jednak donoszony zwrot w stronę stosów 8-hi sugeruje, że coraz wyższe HBM nie są już automatycznym wyborem.
Jeśli to rozumowanie rozciągnie się na 4-hi HBM4E, infrastruktura AI może używać mniej układów DRAM bez poświęcania zewnętrznej przepustowości każdego stosu. Obniżyłoby to koszty pamięci i pozwoliło uzyskać więcej użytecznych pakietów HBM z ograniczonej podaży wafli.
Mapa rozwoju pamięci Nvidia nie zmierza już tylko w jednym kierunku
Znacząca zmiana nie polega na tym, że Nvidia nagle potrzebuje niewiele pamięci. Chodzi o to, że dodatkowa pojemność nie wydaje się już cenna za wszelką cenę.
Blackwell Ultra wyraźnie wyznaczył kierunek wysokiej pojemności. Nvidia podaje 288GB HBM3E na GPU Blackwell Ultra oraz 20TB w całym racku GB300 NVL72.
Specyfikacje GB300 firmy wskazują również, że łączna przepustowość pamięci GPU sięga 576TB na sekundę. Dane te pokazują, dlaczego Nvidia wcześniej podkreślała zarówno pojemność, jak i przepustowość.
SemiAnalysis informuje teraz, że Rubin Ultra odwróci część tego trendu. Oczekiwane 192GB na GPU oznacza redukcję o jedną trzecią w porównaniu z Blackwell Ultra i konwencjonalnym Rubin.
Porównanie wymaga pewnej ostrożności. Architektura Rubin Ultra miała podobno zmienić się z czterech układów obliczeniowych na dwa. Wcześniej oczekiwana pojemność pamięci dotyczyła więc innego projektu systemu.
Nawet po uwzględnieniu tej zmiany SemiAnalysis szacuje spadek pamięci z wcześniejszych 256GB na układ obliczeniowy do 96GB. To istotny reset architektoniczny, a nie kosmetyczna korekta specyfikacji.
Raport wskazuje podaż jako jeden z powodów. Nvidia miała zapewnić sobie znaczącą zdolność produkcyjną zaawansowanej logiki i pakowania, lecz dostępne wafle HBM nie mogą obsłużyć porównywalnych wolumenów stosów 12-hi.
Stos 12-hi zawiera dwanaście podstawowych układów DRAM ponad układem bazowym. Stos 8-hi wykorzystuje osiem, dzięki czemu ta sama przetworzona podaż DRAM może obsłużyć więcej gotowych stosów.
Jest to istotne, ponieważ HBM zużywa więcej zdolności produkcyjnych na bit niż konwencjonalny DRAM. Przelotowe połączenia krzemowe, znane jako TSV, przenoszą sygnały i zasilanie pionowo przez stos pamięci.
TSV wymagają dodatkowego przetwarzania. Układy HBM zawierają również obszar przeznaczony na pionowe połączenia, co obniża gęstość bitową w porównaniu ze zwykłą pamięcią wytwarzaną w podobnym procesie.
SemiAnalysis wcześniej szacował, że HBM zużywa około trzykrotnie więcej pojemności wafli na bit niż towarowy DRAM. Według jego szacunków wartość ta zbliża się do czterokrotności wraz z przejściem produkcji na HBM4.
Liczba ta jest szacunkiem analityków, a nie standardem branżowym. Jednak podstawowe obciążenie produkcyjne jest dobrze udokumentowane u dostawców pamięci.
SK hynix, Samsung i Micron muszą przetwarzać, ścieńczać, łączyć, testować i pakować wiele sprawnych układów. Każda dodatkowa warstwa zwiększa zużycie materiałów i naraża pakiet na dodatkowe ryzyko strat uzysków.
Wyższe stosy historycznie uzasadniały ten koszt, ponieważ akceleratory potrzebowały ich pojemności. Wagi modeli, aktywacje, gradienty, stany optymalizatora oraz pamięci podręczne klucz-wartość konkurują o pamięć w różnych obciążeniach.
Nowa decyzja sugeruje, że dla części systemów inferencyjnych pojemność przekroczyła pewien próg. Gdy rack mieści wymagany zbiór roboczy, dodawanie pamięci do każdego GPU przynosi mniejszą wartość.
Nvidia nie potwierdziła publicznie dokładnego podziału pojemności Rubin Ultra przedstawionego przez SemiAnalysis. Twierdzenie to powinno zatem pozostać donoszoną zmianą mapy rozwoju, a nie finalną specyfikacją produktu.
Mimo to przygotowania w łańcuchu dostaw mogą ujawnić kierunek przed publiczną premierą. SemiAnalysis twierdzi, że dostawcy przygotowują konfiguracje 8-hi, które mają stać się standardem po wcześniejszym branżowym nacisku na produkty 12-hi i 16-hi.
Donoszona zmiana otwiera drogę dla 4-hi HBM. Jeśli osiem warstw wystarcza, projektanci muszą zapytać, czy cztery warstwy mogą obsłużyć wybrane wdrożenia inferencyjne bardziej ekonomicznie.
Podczas niedawnego wyścigu pojemności takie pytanie brzmiałoby jak krok wstecz. Przy poważnych ograniczeniach DRAM staje się jednym z najbardziej praktycznych wyborów architektonicznych w branży.
SemiAnalysis 4-hi HBM zachowuje przepustowość, eliminując układy
Krótszy stos HBM zmniejsza pojemność, ale nie obniża automatycznie zewnętrznej przepustowości pakietu.
HBM przesyła dane przez bardzo szeroki interfejs, zamiast polegać wyłącznie na ekstremalnej szybkości sygnalizacji. HBM4 rozszerza ten interfejs do 2 048 połączeń danych na stos.
Standard HBM4 został opublikowany przez JEDEC w kwietniu 2025 roku. Definiuje on podstawę nowej generacji pamięci dla AI i obliczeń wysokiej wydajności.
Według SemiAnalysis każdy układ DRAM HBM4 może uzyskać dostęp do maksymalnie 512 połączeń danych stosu. Cztery układy mogą zatem obsadzić wszystkie 2 048 połączeń.
Dodanie od piątego do dwunastego układu zwiększa pojemność. Nie rozszerza zewnętrznego interfejsu ponad 2 048 połączeń.
Dostępne piny są dzielone między większą liczbę warstw pamięci w wyższym stosie. Stos nadal przedstawia akceleratorowi ten sam łączny interfejs.
To centralny mechanizm stojący za argumentem na rzecz krótkich stosów. Pakiety 4-hi, 8-hi i 12-hi mogą oferować porównywalną nominalną przepustowość, gdy wykorzystują tę samą generację i szybkość sygnalizacji.
Ich pojemności znacząco się różnią. SemiAnalysis modeluje podstawowe układy HBM4E o pojemności 32 gigabitów, co daje 16GB dla 4-hi, 32GB dla 8-hi i 48GB dla 12-hi.
Są to modelowane przyszłe konfiguracje, a nie powszechnie dostępne produkty detaliczne. Ilustrują, jak liczba warstw zmienia pojemność, pozostawiając interfejs pakietu nienaruszony.
Różnica ekonomiczna wynika z tego, co zużywają dostawcy. Zawartość DRAM stanowi znaczną część kosztu stosu HBM, podczas gdy klienci inferencyjni często cenią przepustowość zasilającą ich akceleratory.
Nabywca 4-hi otrzymuje mniej gigabajtów. Nadal może jednak otrzymać ścieżkę danych potrzebną do stałego zasilania jednostek obliczeniowych.
Zmienia to właściwą miarę efektywności. Zakupy skoncentrowane na pojemności pytają, ile gigabajtów mieści się obok każdego akceleratora. Zakupy skoncentrowane na przepustowości pytają, ile tokenów mogą obsłużyć te łącza pamięci.
W inferencji drugie pytanie może dominować. Dekodowanie autoregresyjne generuje wyjście sekwencyjnie, a każdy krok musi odczytać z pamięci aktywne wagi modelu.
Proces ten często wykonuje stosunkowo niewiele operacji arytmetycznych na każdy przeniesiony bajt. Oznacza to, że dekodowanie jest ograniczone przepustowością pamięci: dostarczanie danych ogranicza wydajność wcześniej niż sama moc obliczeniowa.
Wyższy stos pomaga tylko wtedy, gdy obciążenie wykorzystuje jego dodatkową pojemność. W przeciwnym razie dodatkowe układy przechowują informacje, których dostępna przepustowość nie potrafi odczytać wystarczająco często.
SemiAnalysis podaje przykładową przepustowość HBM4E na poziomie 3 328GB na sekundę na stos. Wyprowadza tę wartość z 2 048 pinów działających z szybkością 13 gigabitów na sekundę.
Przy 100 wygenerowanych tokenach na sekundę oznacza to 33,28GB teoretycznej przepustowości na każdy token. Użyteczny zbiór roboczy nie może przekroczyć tego budżetu, jeśli każdy token musi go odczytać raz.
Stos 48GB zawierałby wówczas więcej danych, niż teoretyczna przepustowość może przeskanować na token. Część pojemności pozostałaby niedostępna dla tego konkretnego obciążenia przy tej szybkości.
Rzeczywiste systemy nigdy nie utrzymują każdej jednostki nominalnej przepustowości. Narzut protokołu, wzorce dostępu, komunikacja i zachowanie oprogramowania obniżają efektywną wydajność.
To ograniczenie może wzmacniać argument za krótkim stosem. Niższa użyteczna przepustowość oznacza, że obciążenie osiąga limit przepustowości, zanim wykorzysta całą zainstalowaną pojemność.
Wyjaśnione tym mechanizmem 4-hi HBM nie jest po prostu tańszą pamięcią. To konfiguracja, która oddziela zewnętrzną przepustowość od maksymalnej gęstości pionowej.
Rozróżnienie to wpływa również na wydajność produkcji. Wafel wykorzystany do czterowarstwowych stosów może teoretycznie obsłużyć trzykrotnie więcej pakietów niż wafel użyty do stosów dwunastowarstwowych.
Rzeczywiste korzyści zależą od uzysków, dostępności układów bazowych, testowania i przepustowości pakowania. Krótsze stosy powinny też pozwolić uniknąć części skumulowanych strat montażowych związanych z dodatkowymi warstwami.
SemiAnalysis argumentuje, że wynikająca z tego przepustowość na wafel HBM ma równie duże znaczenie jak tokeny na wat. Obie miary oceniają użyteczny wynik AI względem zasobu, którego nie można szybko zwiększyć.
Dlaczego inferencja ceni przepustowość bardziej niż maksymalną pojemność
Interaktywna inferencja premiuje pamięć, która potrafi szybko zasilać procesor, podczas gdy niewykorzystana pojemność wnosi niewiele do przepustowości tokenów.
Trening i inferencja stawiają HBM różne wymagania. Trening przechowuje wagi, aktywacje, gradienty i dane optymalizatora, przetwarzając duże batch’e w przebiegach w przód i wstecz.
Takie obciążenie może zużywać ogromną pojemność. Wykonuje też wystarczająco dużo operacji arytmetycznych, aby podczas wielu operacji stać się ograniczonym mocą obliczeniową.
Dekodowanie inferencyjne jest inne. System wielokrotnie odczytuje aktywne wagi oraz pamięć podręczną klucz-wartość użytkownika, czyli KV cache, generując token po tokenie.
KV cache przechowuje informacje uwagi z wcześniejszych tokenów. Zapobiega konieczności ponownego obliczania przez model całej rozmowy przy generowaniu kolejnego tokenu.
Większa liczba użytkowników i dłuższe konteksty powiększają tę pamięć podręczną. Większa pojemność jest jednak wartościowa tylko wtedy, gdy system może obsłużyć tych użytkowników w akceptowalnym czasie odpowiedzi.
Batching komplikuje obraz. Przetwarzając kilka żądań razem, serwer może rozłożyć jeden odczyt wag modelu na wielu użytkowników.
Większe batch’e zwiększają całkowitą przepustowość, ale wymagają również większej pojemności KV cache. To obszar, w którym stosy 8-hi lub 12-hi mogą odzyskać przewagę.
Kompromisem jest interaktywność. Dostawca może dłużej czekać na utworzenie większych batch’y albo szybko zwracać tokeny przy mniejszych batch’ach.
SemiAnalysis modeluje tę zależność za pomocą Kimi K3 w przyszłej konfiguracji Rubin Ultra NVL576. Stwierdza, że wyższe stosy zapewniają malejące przyrosty przepustowości wraz ze wzrostem wymaganej szybkości przypadającej na użytkownika.
Przy modelowanych 213 tokenach na sekundę dla każdego użytkownika raport nie stwierdza korzyści dla przepustowości ponad 4-hi. Granica przepustowości pojawia się, zanim dodatkowa pojemność pamięci stanie się użyteczna.
W innych punktach krzywej 8-hi podnosi maksymalną przepustowość o 8 procent. Konfiguracja 12-hi podnosi ją o 10 procent względem 4-hi.
Te ulepszenia są rzeczywiste na poziomie modelu. Pytanie brzmi, czy rekompensują dodatkowy koszt pamięci i systemu.
SemiAnalysis szacuje, że jego modelowany system Rubin Ultra 8-hi kosztuje o 12,1 proc. więcej niż wariant bazowy 4-hi. Konfiguracja 12-hi podnosi koszt o 26,3 proc.
Są to szacunki analityków oparte na przyszłych komponentach i założonych cenach pamięci. Nie są to wyceny dostawców ani zmierzone koszty posiadania wdrożonych systemów Rubin Ultra.
W ramach tych założeń przepustowość rośnie wolniej niż koszt systemu. Wynikowy koszt na token jest wyższy w obu wyższych konfiguracjach.
To najmocniejsze twierdzenie w analizie SemiAnalysis dotyczącej HBM 4-hi. Krótsze stosy nie tylko obniżają rachunek za sprzęt; poprawiają też modelowaną wydajność wyjściową w przeliczeniu na jednostkę wydatków.
Obliczenia w skali szafy rackowej czynią ten argument bardziej wiarygodnym. Wcześniejsze serwery łączyły osiem GPU, więc pamięć każdego urządzenia silnie ograniczała cały system obsługi zapytań.
System H100 HGX zapewniał łącznie 640GB HBM. Wagi dużego modelu mogły zajmować większość tej pojemności, zanim system przechował jakikolwiek znaczący cache KV.
H200 złagodził tę presję, dodając pamięć do każdego GPU. Na tym etapie większa pojemność na urządzenie miała bezpośrednią wartość operacyjną.
GB300 NVL72 zmienia skalę. Nvidia łączy 72 GPU Blackwell Ultra za pośrednictwem NVLink, tworząc znacznie większą wspólną domenę komunikacyjną.
Szafa zawiera około 20TB pamięci GPU. Jej łączna pojemność jest znacznie większa niż w ośmiogpuowym serwerze Hopper.
SemiAnalysis porównuje ten wzrost z Kimi K3, modelem mixture-of-experts o 2,8 biliona parametrów. Takie modele aktywują dla każdego tokenu jedynie podzbiór swoich ekspertów.
Raport szacuje, że skwantyzowana replika Kimi K3 zajmuje 1 561GB. Stanowiłoby to mniej niż 8 proc. konfiguracji GB300 NVL72 o pojemności około 21TB.
Kwantyzacja reprezentuje liczby za pomocą mniejszej liczby bitów, zmniejszając zapotrzebowanie na przechowywanie wag i ruch pamięci. Poświęca część precyzji numerycznej w zamian za istotnie niższe wymagania sprzętowe.
Duże domeny NVLink rozkładają także ekspertów na większą liczbę GPU. Taki układ zwiększa wymagania komunikacyjne, lecz zmniejsza liczbę wag modelu, które musi przechowywać każde urządzenie.
Rubin Ultra ma podobno rozszerzać domenę z NVL72 do NVL576. Ośmiokrotny wzrost liczby połączonych GPU może przeważyć nad redukcją HBM na akcelerator o jedną trzecią.
Pojemność przestaje więc być problemem pojedynczego GPU, a staje się problemem alokacji na poziomie szafy. Wdrożenie może utrzymać duży model, korzystając z cieńszych lokalnych stosów pamięci.
Nie eliminuje to ograniczeń pamięci. Zmienia miejsce, w którym architekci je rozwiązują, oraz zasób, który jako pierwszy staje się deficytowy.
Odciążanie cache pomaga, ale HBM 4-hi nie jest darmowym rozwiązaniem
Strategia krótkich stosów działa tylko wtedy, gdy oprogramowanie, pamięć dodatkowa i zachowanie obciążeń nie pozwalają, by zmniejszona pojemność HBM stała się wąskim gardłem.
SemiAnalysis przetestowało część tego założenia przy użyciu obciążenia InferenceX z Kimi K3 i 16 GPU GB300. Osiem GPU obsługiwało prefill, a osiem decode.
Prefill przetwarza prompt przed rozpoczęciem generowania tokenów. Oddzielenie go od decode pozwala operatorom dostroić każdą fazę pod inne zachowanie obliczeniowe i pamięciowe.
Eksperyment obniżył dozwolone wykorzystanie HBM z 92 proc. do 85 proc. To znacznie mniej niż redukcja pojemności między stosami 8-hi i 4-hi.
Mimo to limit istotnie zmniejszył dostępną przestrzeń cache KV. Według raportu łączna pojemność cache KV dla obsługi zapytań spadła z 53GB do 34GB na GPU.
Dla rozdzielonych par dostępny budżet spadł z 44GB do 24GB. Zmiany te oznaczały redukcje o 36 proc. i 44 proc.
Przepustowość pozostała podobna dla większości testowanych poziomów współbieżności. Ograniczona konfiguracja przenosiła nieaktywny cache KV do zwykłej pamięci DRAM serwera.
Proces ten nazywa się odciążaniem cache KV. Utrzymuje często używane informacje w HBM, przenosząc mniej aktywny stan rozmów do wolniejszej, większej pamięci.
Obciążenia agentowe mogą dobrze pasować do tego podejścia. Często zatrzymują się, gdy działają narzędzia, CPU wykonują kod albo zewnętrzne usługi zwracają informacje.
Podczas tych przerw GPU nie potrzebuje od razu cache każdej rozmowy. Przeniesienie mniej aktywnych danych może zwolnić kosztowną pamięć HBM dla aktywnych żądań.
Ograniczony test napotkał wyraźną granicę. Gdy współbieżność przekroczyła 70, przepustowość spadła o niemal 30 proc. w porównaniu z konfiguracją o większej pamięci.
Wykorzystanie GPU przez cache KV osiągnęło 100 proc. Preempcja, powtarzające się transfery i kolejkowanie ograniczyły wtedy użyteczną pracę.
W ograniczonym uruchomieniu odnotowano także ponad dziesięciokrotnie więcej odczytów z cache KV opartego na DRAM. Odciążanie zmniejszyło presję pojemnościową, lecz zwiększyło ruch przez wolniejszą warstwę.
Wynik ten jednocześnie wspiera tezę i ostrzega przed jej ograniczeniami. Pokazuje, że oprogramowanie może zachować wydajność po istotnym zmniejszeniu pamięci, ale tylko poniżej progu zależnego od obciążenia.
Usługa produkcyjna z wieloma jednoczesnymi użytkownikami korzystającymi z długiego kontekstu może przekroczyć ten próg. W takim przypadku wyższe stosy HBM mogą obsłużyć większe batch’e i wyższą łączną przepustowość.
Znaczenie ma także przepustowość sieci. Rozłożenie ekspertów modelu i cache na setki akceleratorów tworzy intensywną komunikację all-to-all.
System może przestać być ograniczany pojemnością pamięci, a zamiast tego stać się ograniczany przez sieć. Taki rezultat nadal pozostawia niewykorzystaną dodatkową HBM, lecz nie gwarantuje efektywnej wydajności całego systemu.
Dodatkowa pamięć DRAM stanowi kolejne ograniczenie. Pamięć serwerowa odczuwa własną presję podażową, ponieważ systemy AI zwiększają pojemność po stronie CPU.
Odciążanie zwiększa także zużycie energii i złożoność operacyjną. Oprogramowanie musi decydować, co pozostaje aktywne, co jest przenoszone oraz kiedy dane muszą wrócić.
Słabe decyzje mogą zamienić oszczędności pojemności w skoki opóźnień. Architektura wymaga starannego planowania, zarządzania cache i izolacji obciążeń.
Przyszły wzrost modeli jest większą niewiadomą. SemiAnalysis przyznaje, że jego analiza stosuje obecne obciążenie do sprzętu oczekiwanego w przyszłości.
Serwery AI często pozostają wdrożone przez ponad pięć lat. Modele, konteksty, współbieżność użytkowników i obciążenia rozumowania mogą w tym czasie drastycznie się zmienić.
Raport przeprowadza test warunków skrajnych dla modelu trzy razy większego od Kimi K3 i z trzykrotnie większym wymaganiem cache na użytkownika. Wyższe stosy stają się przy tym założeniu bardziej użyteczne.
Konfiguracja 8-hi zapewnia o 36 proc. więcej wszystkich tokenów niż 4-hi. Wersja 12-hi zapewnia o 47 proc. więcej, choć obie działają z niższą szybkością na użytkownika.
Po uwzględnieniu szacowanych kosztów 8-hi staje się korzystniejsze poniżej 180 tokenów na sekundę na użytkownika. System 12-hi nadal nie rekompensuje modelowanego wzrostu kosztów.
Wyniki te pokazują, dlaczego HBM 4-hi nie może stać się uniwersalną receptą. Preferowana wysokość stosu zależy od rozmiaru modelu, celów opóźnienia, batchowania i cyklu życia systemu.
Systemy treningowe pozostają szczególnie słabym celem dla agresywnej redukcji pojemności. Ich aktywacje, gradienty i stany optymalizatora mogą wykorzystać całą dostępną pamięć.
Systemy inferencyjne obsługujące wiele niezależnych modeli również potrzebują pojemności. Operatorzy mogą bardziej cenić elastyczność niż najniższy koszt dla jednego zoptymalizowanego obciążenia.
Kupujący sprzęt mierzą się z problemem opcjonalności. Akcelerator 4-hi może być wydajny dla dzisiejszej usługi, lecz ograniczający po zmianie obciążeń.
Badacze mogą dostosować modele do zainstalowanego sprzętu. Obliczenia pętlowe, kwantyzacja, rzadzi eksperci i mniejsze cache mogą zmniejszyć zależność od przechowywanych parametrów.
Taka adaptacja nie jest gwarantowana. Poprawa jakości modeli może ponownie wynikać z większej liczby parametrów albo architektur intensywnie wykorzystujących pamięć.
Najlepsza interpretacja jest zatem węższa. Czterowarstwowa HBM oferuje silną konfigurację dla starannie scharakteryzowanej inferencji, a nie automatyczny zamiennik dla wyższej pamięci.
Mniejsza liczba warstw wywiera presję na dostawców pamięci i budowniczych systemów
Jeśli nabywcy będą optymalizować przepustowość zamiast gigabajtów, presja ekonomiczna przeniesie się z produkcji DRAM na base die, pakowanie, sieci i integrację kompletnych systemów.
SK hynix, Samsung i Micron od lat rozwijają gęstsze i wyższe HBM. Ich plany rozwoju kładą nacisk na pojemność, szybkość sygnalizacji, uzysk pakowania i kontrolę termiczną.
SK hynix rozpoczął dostawy 12-warstwowych próbek HBM4 w 2025 roku. Jego ogłoszenie HBM4 opisywało pakiety 36GB o przepustowości przekraczającej 2TB na sekundę.
Ten kierunek produktowy pozostaje użyteczny dla treningu i inferencji wymagającej dużej pojemności. Znaczące przejście ku 4-hi wprowadziłoby zupełnie inny priorytet zakupowy.
Klienci mogliby żądać pełnej przepustowości interfejsu przy mniejszej liczbie rdzeni DRAM. Dostawcy wysyłaliby więcej pakietów, ale mniej bitów DRAM w każdym z nich.
Na pierwszy rzut oka wygląda to niekorzystnie dla przychodów z HBM. Dostawcy korzystali na sprzedaży większej zawartości wyspecjalizowanej pamięci DRAM w każdej generacji akceleratorów.
SemiAnalysis twierdzi, że rezultat może być bardziej zrównoważony. Krótsze stosy mogłyby poprawić uzysk montażu i zwiększyć liczbę sprzedawalnych pakietów produkowanych z każdego wafla.
Dostawca mógłby także wyceniać wartość przepustowości, zamiast traktować HBM przede wszystkim jako produkt sprzedawany w gigabajtach. Niepewne pozostaje, czy klienci zaakceptują taki model.
Korzyść dla podaży jest wyraźniejsza. Przejście z 12-hi na 4-hi teoretycznie trzykrotnie zwiększa liczbę grup układów wielkości stosu dostępnych z ustalonej ilości DRAM.
Rzeczywisty wzrost może przekroczyć prosty stosunek, jeśli krótsze stosy zwiększą uzysk pakowania. Spadnie poniżej tego stosunku, gdy ograniczone staną się inne komponenty.
Każdy pakiet HBM nadal potrzebuje base die, testowania, układania warstw i montażu obok akceleratora. Pomnożenie produkcji pakietów zwiększa popyt na wszystkie te etapy.
HBM4 zwiększa znaczenie base die, ponieważ zawiera ono więcej logiki i może wykorzystywać zaawansowany proces foundry. Oszczędności DRAM nie tworzą równoważnej mocy produkcyjnej foundry.
Więcej pakietów pamięci wymaga również większej liczby pakietów akceleratorów. Te pakiety potrzebują interposerów, organicznych substratów, dostarczania energii, chłodzenia i montażu o wysokiej gęstości.
Wąskie gardło może więc migrować, zamiast znikać. Wafle logiczne, base die, substraty, płytki drukowane i integracja systemów odczułyby większy popyt.
Duże domeny scale-up nasilają kolejne ograniczenie. Większa liczba akceleratorów wymaga rozbudowanego przełączania i sieci, zanim ich łączna pamięć stanie się praktycznie użytecznym współdzielonym zasobem.
Nvidia GB300 NVL72 wykorzystuje dziewięć tac NVSwitch do połączenia 72 GPU. Jego tkanina NVLink piątej generacji zapewnia łączną przepustowość 130TB na sekundę.
Przyszłe systemy NVL576 muszą istotnie rozszerzyć tę skalę. Ich ekonomika zależy od tego, czy sieć pozostanie wystarczająco szybka, by obsługiwać rozproszonych ekspertów i przenoszenie cache.
Energia pozostaje ostateczną granicą. Podwojenie liczby pakietów HBM o wysokiej przepustowości pomaga tylko wtedy, gdy operatorzy mogą wdrożyć dołączone do nich akceleratory.
Strategia 4-hi może rozciągnąć podaż DRAM bez tworzenia nowej mocy elektrycznej. Budowa centrów danych, chłodzenie i dostęp do sieci energetycznej nadal określają użyteczną moc obliczeniową.
Ta presja wyjaśnia, dlaczego tokeny na wafel HBM są pomocną miarą, lecz nie kompletną. Operatorzy muszą jednocześnie optymalizować tokeny na wat, szafę, port sieciowy i budżet kapitałowy.
Zmiana wpłynęłaby także na konwencjonalne rynki pamięci. Produkcja HBM konkuruje o zasoby produkcyjne z serwerową, komputerową i mobilną pamięcią DRAM.
Wykorzystanie mniejszej liczby rdzeni HBM może zwrócić część pojemności wafli tym produktom. Ta ulga ma znaczenie, gdy pamięć po stronie CPU rośnie wraz z wdrożeniami agentowej AI.
Korzyść zależy jednak od faktycznej adopcji. Konstrukcja 4-hi, która umożliwia znacznie więcej dostaw akceleratorów, mogłaby pochłonąć część oszczędności przez większy łączny wolumen jednostek.
Dostawcy pamięci mogą również opierać się szybkiemu przejściu, jeśli osłabi ono popyt na bity. Ich reakcja będzie widoczna w dostępności produktów, harmonogramach kwalifikacji i alokacji mocy produkcyjnych.
Główny spór nie dotyczy więc Nvidii i jednego dostawcy pamięci. Chodzi o projektowanie inferencji zorientowane na przepustowość kontra ekonomię HBM zorientowaną na pojemność.
Taka mapa rywalizacji jasno pokazuje konsekwencje dla branży. Niskie stosy wygrywają, gdy przepustowość generuje przychody, a zainstalowane gigabajty nie.
Wyższe stosy wygrywają, gdy klienci potrafią przekształcić dodatkową pojemność w większe batch’e, większą liczbę modeli lub dłuższą elastyczność sprzętową.
Trzy sygnały pokażą, czy 4-hi HBM rzeczywiście wygra
Teza o niskich stosach staje się wiarygodna dopiero wtedy, gdy zbiegną się plany produktowe, dostępność produkcyjna i zmierzone wyniki inferencji.
Pierwszym sygnałem będzie ostateczna konfiguracja Rubin Ultra od Nvidii. Publiczna dokumentacja musi potwierdzić pojemność pamięci, wysokość stosu, przepustowość oraz architekturę systemu NVL576.
Potwierdzona konfiguracja 192 GB wykorzystująca 8-hi HBM wsparłaby argument kierunkowy. Powrót do 12-hi osłabiłby twierdzenia, że wymagania dotyczące pojemności zasadniczo złagodniały.
Komercyjny produkt Rubin z 4-hi dostarczyłby znacznie mocniejszych dowodów. Do tego czasu propozycja SemiAnalysis dotycząca 4-hi HBM pozostaje dobrze ugruntowaną prognozą dotyczącą przyszłych ASIC-ów i akceleratorów.
Drugim sygnałem będzie kwalifikacja przez dostawców szybkiej pamięci 4-hi HBM4 lub HBM4E. Producenci muszą oferować takie pakiety przy szybkościach sygnalizacji wymaganych przez projektantów akceleratorów.
Sama nominalna szerokość interfejsu nie wystarczy. Produkty muszą zapewniać akceptowalną uzyskiwalność, parametry termiczne, niezawodność i stałą wydajność w kompletnych systemach.
Warto obserwować, czy SK hynix, Samsung lub Micron dodadzą konfiguracje 4-hi do publicznych planów rozwoju. Próbki dla klientów pokazałyby, że niskie stosy wyszły poza etap wewnętrznych analiz architektonicznych.
Należy także obserwować model cenowy. Jeśli koszty 4-hi będą skalować się głównie wraz z niższą pojemnością, jego ekonomika przepustowości stanie się przekonująca.
Jeżeli dostawcy wycenią większość wartości w die bazowym i interfejsie, oczekiwane oszczędności mogą się zmniejszyć. Niedobory pakietów mogą też utrzymać wysokie premie mimo mniejszej zawartości DRAM.
Trzecim sygnałem będą niezależne testy inferencji dla zróżnicowanych obciążeń. Benchmarki muszą obejmować interaktywnych asystentów, usługi agentowe, zapytania o długim kontekście i wdrożenia z dużymi batchami.
Średnia przepustowość tokenów nie wystarczy. Testy muszą uwzględniać szybkość dla pojedynczego użytkownika, zachowanie kolejek, współczynniki trafień cache, ruch offload i opóźnienia krańcowe.
Wyniki powinny także porównywać modele różniące się rozmiarem i architekturą. Konfiguracja zoptymalizowana pod Kimi K3 nie może przesądzać o najlepszym wyborze dla każdego przyszłego modelu frontier.
Rozstrzygającym dowodem będzie trwała przewaga kosztu na token przy realistycznych celach poziomu usług. Przewaga ta musi utrzymać się przy wysokiej współbieżności i zmieniającej się mieszance obciążeń.
Deweloperzy powinni się tym interesować, ponieważ ograniczenia sprzętowe kształtują projektowanie modeli. Dostępna pamięć wpływa na kwantyzację, rozmieszczenie ekspertów, obsługę kontekstu i politykę cache.
Kupujący korporacyjni powinni zwracać uwagę, ponieważ deklarowana pojemność może być myląca. Więcej HBM nie gwarantuje bardziej użytecznej inferencji, gdy ograniczeniem stają się przepustowość, sieć lub opóźnienia.
Zespoły infrastruktury powinny oceniać zestawy robocze na poziomie szafy rack. Przed wyborem jednego profilu pamięci powinny rozdzielić obciążenia treningowe, prefill, decode i agentowe.
Powinny również zachować zapas operacyjny. Wąsko zoptymalizowany system 4-hi może stracić przewagę, gdy popyt przesunie się w stronę większych batchy lub większej liczby jednocześnie działających modeli.
Szersza lekcja nie polega na tym, że mniej pamięci zawsze wygrywa. Chodzi o to, że pamięć należy kupować pod kątem zasobu faktycznie zużywanego przez dane obciążenie.
W przypadku interaktywnej inferencji tym zasobem często jest przepustowość. Czterowarstwowa pamięć HBM może zachować pełną zewnętrzną ścieżkę danych, wykorzystując jednocześnie mniej rzadkich układów DRAM.
To sprawia, że analiza SemiAnalysis dotycząca 4-hi HBM stanowi poważne wyzwanie dla branżowych założeń o najwyższych stosach. Kolejne ujawnienia produktów pokażą, czy zespoły sprzętowe się z tym zgadzają.
Przed podjęciem decyzji o przyszłej flocie akceleratorów warto zadać trzy pytania. Czy zestaw roboczy mieści się w skali racka, czy dane z zimnego cache można bezpiecznie przenosić oraz czy dodatkowa pojemność zwiększa użyteczną przepustowość?
Jeśli odpowiedzi wskazują na przepustowość, niski król zasługuje na miejsce w planie rozwoju.
