SK hynix otwiera HBF dla branży, ale prawdziwym sprawdzianem pozostaje sprzęt

SK hynix opublikował pierwszą specyfikację High Bandwidth Flash, przekształcając proponowaną warstwę pamięci dla AI w otwarty techniczny projekt. Ogłoszenie z 4 sierpnia szeroko pojawiło się w Google News, ale najważniejszy spór kryje się pod nagłówkiem. HBF obiecuje pojemność do 512 GB i przepustowość sięgającą 3,0 TB/s, jednak żaden komercyjny system HBF nie potwierdził jeszcze tych parametrów.

Specyfikacja, opracowana z Sandisk w ramach Open Compute Project, opisuje pamięć NAND flash umieszczoną między High Bandwidth Memory a tradycyjnymi dyskami półprzewodnikowymi. Jest przeznaczona dla wnioskowania AI, w którym akceleratory wielokrotnie odczytują duże zestawy wag modeli podczas obsługi zapytań użytkowników. Do konsorcjum dołączyły Google i producent procesorów AI Tenstorrent, co daje temu przedsięwzięciu potencjalnych użytkowników wykraczających poza dwóch dostawców pamięci.

Nie jest to komunikat OpenAI dotyczący technologii pamięci. „Otwarta” odnosi się do specyfikacji i modelu jej rozwoju, a nie do twórcy ChatGPT. Prawdziwa rywalizacja toczy się między otwartą, nastawioną na pojemność warstwą pamięci a ugruntowaną praktyką umieszczania modeli przede wszystkim w kosztownej pamięci HBM. SK hynix ma już specyfikację, wiarygodnych partnerów i ambitne cele. Nadal potrzebuje działającego krzemu, wsparcia ze strony akceleratorów oraz opłacalnej produkcji.

SK hynix przekształca HBF w otwartą specyfikację

Publikacja daje projektantom systemów wspólny cel dla HBF, ale nie gotowy produkt.

SK hynix i Sandisk zaprezentowały specyfikację wraz z rozpoczęciem konferencji Future of Memory and Storage w Santa Clara w Kalifornii. Wydarzenie trwało od 4 do 6 sierpnia 2026 roku. Ogłoszenie nastąpiło po około sześciu miesiącach prac standaryzacyjnych prowadzonych w ramach ścieżki roboczej Open Compute Project.

Firmy uruchomiły tę ścieżkę 25 lutego w siedzibie Sandisk w Milpitas. Początkowo opisywały HBF jako nową warstwę między HBM a pamięcią SSD. Nowo opublikowana specyfikacja nadaje temu pomysłowi określone pojemności, klasy wydajności, interfejsy, wymagania dotyczące obudowy oraz wytyczne niezawodnościowe.

Pierwsza wersja obejmuje pakiety z konfiguracjami ośmiu lub 16 ułożonych warstw matryc NAND. Maksymalna pojemność wynosi 512 GB na stos. Trzy klasy wydajności obejmują zakres od około 0,4 TB/s do 3,0 TB/s, zgodnie z opublikowanym komunikatem i późniejszymi doniesieniami technicznymi.

Ten zakres ma znaczenie, ponieważ HBF nie oznacza jednego, stałego poziomu wydajności. Niższe klasy mogą kłaść nacisk na pojemność i efektywność, podczas gdy późniejsze implementacje mogą dążyć do przepustowości zbliżonej do zaawansowanego HBM. Ta elastyczność oznacza również, że pułapu 3,0 TB/s nie należy traktować jako gwarancji dla pierwszej generacji dostępnej na rynku.

HBF wykorzystuje pamięć NAND flash, czyli nieulotną technologię stosowaną w SSD, a nie DRAM używaną przez HBM. Pamięć nieulotna zachowuje dane bez ciągłego zasilania. Zwykły NAND nie jest jednak w stanie zasilać akceleratora AI z prędkościami choćby zbliżonymi do HBM.

HBF niweluje tę różnicę, układając wyspecjalizowane matryce NAND w stos i uzyskując równoległy dostęp do wielu wewnętrznych macierzy. Bazowa matryca logiczna zarządza tymi połączeniami i zapewnia znacznie szerszą ścieżkę do procesora. Powstały pakiet przypomina filozofię ściśle sprzężonej konstrukcji HBM, zachowując jednocześnie przewagę NAND pod względem gęstości.

Specyfikacja wykorzystuje również Universal Chiplet Interconnect Express, czyli UCIe, do połączeń między HBF a procesorami hosta. UCIe to otwarty interkonekt między matrycami, umożliwiający chipletom wymianę danych wewnątrz jednego pakietu. Jego zastosowanie daje projektantom CPU, GPU i akceleratorów wspólną ścieżkę integracji.

Specyfikacja UCIe nie zapewnia automatycznej interoperacyjności. Dostawcy nadal potrzebują kontrolerów, zarządzania pamięcią, obsługi błędów, odpowiedniego pakietowania, oprogramowania układowego i wsparcia programowego. Zmniejsza jednak ryzyko, że każdy dostawca HBF stworzy niekompatybilne fizyczne połączenie.

Równie istotna jest publikacja za pośrednictwem Open Compute Project. Specyfikacje OCP mają ustanawiać wspólne wymagania, które może wdrażać wiele firm. Jego ramy dotyczące wkładu rozróżniają szerokie specyfikacje bazowe od szczegółowych, gotowych do produkcji dokumentów produktowych.

To rozróżnienie definiuje obecny stan HBF. SK hynix i Sandisk przeniosły ten pomysł poza slajdy i prywatne dyskusje. Nie dostarczyły jeszcze gotowego do produkcji komponentu, który producenci serwerów mogliby zamawiać i kwalifikować.

Dla czytelników trafiających tu przez Google News jest to pierwsza rzecz, o której należy pamiętać. SK hynix zaprezentował standardową specyfikację, a nie komercyjnie dostępną pamięć o pojemności 512 GB. Ogłoszenie wyznacza cel i część dróg prowadzących do jego osiągnięcia.

Dlaczego wnioskowanie AI potrzebuje kolejnej warstwy pamięci

HBF istnieje, ponieważ wnioskowanie AI wymaga zarówno szybkiego dostępu, jak i znacznie większej pojemności, niż HBM może zapewnić w opłacalny sposób.

Trenowanie przyciąga największą uwagę opinii publicznej, ale to wnioskowanie przekształca wytrenowany model w stale działającą usługę. Podczas wnioskowania procesory wielokrotnie uzyskują dostęp do wag modelu, danych uwagi i zapamiętanego kontekstu. Większe modele oraz dłuższe rozmowy zwiększają ilość danych, które muszą pozostawać blisko zasobów obliczeniowych.

HBM obsługuje najszybszą część tego obciążenia. Układa matryce DRAM obok akceleratora i łączy je szerokim interfejsem. Taka konstrukcja zapewnia wyjątkową przepustowość i niskie opóźnienia, lecz pojemność pozostaje ograniczona, a produkcja jest złożona.

SSD rozwiązują problem pojemności przy niższym koszcie na bit. Dane muszą jednak przejść przez kontrolery pamięci masowej i interfejsy, zanim dotrą do akceleratora. Ta ścieżka wprowadza opóźnienia i zapewnia znacznie mniejszą przepustowość niż pamięć na poziomie pakietu.

Twórcy systemów stają więc przed niewygodnym wyborem. Mogą kupować więcej akceleratorów wyposażonych w HBM, aby pomieścić duży model, nawet gdy zasoby obliczeniowe pozostają niewykorzystane. Mogą też przenosić dane modelu z SSD i akceptować wolniejsze odpowiedzi.

HBF próbuje stworzyć trzecią opcję. Umieszcza setki gigabajtów trwałej pamięci NAND znacznie bliżej procesora i uzyskuje dostęp do niej przez silnie zrównoleglone kanały. Często zmieniające się dane mogą pozostać w HBM, a większe zestawy wag mogą znajdować się w HBF.

To podejście jest szczególnie istotne dla modeli mixture-of-experts. Takie modele zawierają wiele wyspecjalizowanych grup parametrów, lecz dla każdego tokenu aktywują tylko ich podzbiór. Ich całkowite zapotrzebowanie na pojemność może być ogromne, nawet jeśli każdy etap wnioskowania wykorzystuje mniejszy zbiór roboczy.

Warstwa stawiająca na pojemność mogłaby przechowywać więcej ekspertów blisko każdego akceleratora. Oprogramowanie przenosiłoby aktywne dane do HBM albo uzyskiwało do nich bezpośredni dostęp z HBF, zależnie od docelowej architektury. Każda z tych metod mogłaby ograniczyć transfery ze zdalnych SSD i zmniejszyć liczbę akceleratorów potrzebnych wyłącznie dla pojemności pamięci.

Sandisk wcześniej modelował HBF na podstawie modelu Llama 3.1 405B firmy Meta. Firma podała, że symulowana wydajność odczytu wag znalazła się w granicy 2,2 procent hipotetycznego systemu z nieograniczoną pojemnością HBM. Wynik ten pozostaje firmową symulacją, a nie niezależnym benchmarkiem produkcyjnym.

Jej analiza architektury HBF opisywała także 16-matrycowy stos o pojemności 512 GB. Sandisk stwierdził, że konstrukcja mogłaby ściśle odpowiadać HBM4 pod względem powierzchni, wysokości stosu i profilu energetycznego. Są to cele rozwojowe, dopóki fizyczne produkty nie przejdą testów.

Porównanie nie powinno sugerować, że NAND stał się DRAM. HBM zachowuje fundamentalne przewagi w zakresie opóźnień i wytrzymałości. HBF ma uzupełniać HBM w obciążeniach wnioskowania z intensywnym odczytem, a nie zastępować każdy bajt pamięci akceleratora.

Takie pozycjonowanie odróżnia to ogłoszenie od kolejnej historii o szybszym SSD. HBF przenosi flash do pakietu procesora i udostępnia go przez interfejs zorientowany na pamięć. Architektura zmienia miejsce przechowywania danych, sposób, w jaki procesory do nich docierają, oraz podział pracy między warstwami pamięci.

Może również wpłynąć na koszty usług AI. Jeśli jeden akcelerator będzie mógł adresować znacznie więcej danych modelu, operatorzy mogą potrzebować mniej replikowanych systemów dla obciążeń ograniczonych pojemnością. Miałoby to znaczenie wtedy, gdy liczbę serwerów określa pojemność pamięci, a nie przepustowość obliczeniowa.

Szansa wykracza poza modele z czołowej półki. Systemy wyszukiwania, silniki rekomendacji i obciążenia związane z wyszukiwaniem wektorowym utrzymują duże zbiory danych, które procesory wielokrotnie odczytują. Systemy brzegowe również mogłyby lokalnie przechowywać większe modele bez polegania na stałych transferach z wolniejszej pamięci masowej.

Żaden z tych scenariuszy nie jest gwarantowany. Oprogramowanie musi inteligentnie rozmieszczać dane między HBM, HBF i SSD. Obciążenia z częstymi zapisami lub rygorystycznymi wymaganiami dotyczącymi opóźnień mogą nadal słabo pasować do tego rozwiązania. Wartość HBF zależy od dopasowania właściwych danych do właściwej warstwy.

Główna rywalizacja dotyczy pojemności HBF i zależności od HBM

SK hynix nie próbuje pokonać HBM w każdym zadaniu; kwestionuje założenie, że wnioskowanie musi mieścić się przede wszystkim w HBM.

To rozróżnienie zwiększa wiarygodność propozycji HBF. Bezpośrednia rywalizacja NAND z DRAM ujawniłaby ograniczenia NAND dotyczące opóźnień i wytrzymałości. Konstrukcja warstwowa zadaje natomiast pytanie, czy każda waga modelu zasługuje na miejsce w najszybszej i najdroższej pamięci.

Zgodnie z początkową specyfikacją jeden stos HBF może pomieścić do 512 GB. Obecne stosy HBM oferują znacznie mniejszą pojemność, choć nowe generacje zwiększają gęstość. HBF może zatem umieścić znacznie większą pulę trwałych danych obok akceleratora.

Najwyższa klasa wydajności HBF osiąga deklarowaną przepustowość 3,0 TB/s. Wynik ten wkracza w obszar przepustowości kojarzony z pojedynczymi stosami HBM kolejnej generacji. Specyfikacja obejmuje jednak szeroki zakres zaczynający się w pobliżu 0,4 TB/s, a sama przepustowość nie ujawnia opóźnień dostępu.

Procesor może także korzystać jednocześnie z kilku stosów HBM. Porównanie jednego stosu HBF z jednym stosem HBM nie opisuje przepustowości całego akceleratora. Rzeczywiste systemy prawdopodobnie połączą obie technologie i przypiszą każdej inną rolę.

Otwarta specyfikacja wywiera presję nie tylko na dostawców HBM. Stanowi również wyzwanie dla producentów akceleratorów, którzy kontrolują ściśle zintegrowane systemy pamięci. Nvidia, AMD, Google i inni projektanci układów muszą zdecydować, czy HBF wnosi wystarczającą wartość, by uzasadnić nowe kontrolery, pakiety i oprogramowanie.

Udział Google zapewnia konsorcjum ważne źródło wiedzy o obciążeniach. Google prowadzi duże usługi AI i projektuje własne Tensor Processing Units. Jego zaangażowanie sygnalizuje, że co najmniej jeden operator hiperskalowy dostrzega wartość w badaniu warstwy pamięci o dużej pojemności.

Nie potwierdza to wdrożenia w przyszłym TPU. Komunikat konsorcjum nie zawiera zobowiązania Google dotyczącego produktu, harmonogramu wdrożenia ani wielkości zakupów. Udział może wpływać na standard bez prowadzenia do komercyjnego urządzenia.

Tenstorrent wnosi inną perspektywę. Firma rozwija procesory AI i stosuje strategie otwartej architektury zorientowane na chiplety. HBF połączone przez UCIe pasuje do tego podejścia, chociaż Tenstorrent nie ogłosił procesora dostępnego na rynku, który zawierałby HBF.

Firmy nieobecne w ogłoszeniu mają równie duże znaczenie jak te, które w nim uczestniczą. Nvidia, AMD, Intel, Micron, Samsung, Kioxia, Broadcom, Marvell i Qualcomm nie zostały wskazane jako uczestnicy. Ich ewentualne wsparcie rozszerzyłoby ekosystem dostawców i procesorów.

Otwarta specyfikacja może obniżyć bariery wdrożenia, ale zmienia również dynamikę konkurencji. SK hynix i Sandisk udostępniają wystarczającą część interfejsu, by zachęcić do innych implementacji. Jeśli HBF odniesie sukces, konkurenci mogą wejść na rynek i wywierać presję na spadek cen lub marż.

To konieczny kompromis, by stać się standardem. Zastrzeżony interfejs może chronić jednego dostawcę, ale mieć trudności z uzyskaniem szerokiego wsparcia ze strony producentów procesorów. Otwarty interfejs może przyciągnąć użytkowników, jednocześnie przenosząc konkurencję na obszary produkcji, pakowania, uzysku i jakości kontrolerów.

SK hynix rozumie obie strony tego rachunku. Firma stała się ważną siłą w pamięciach dla AI dzięki produkcji HBM i bliskiej współpracy z partnerami tworzącymi akceleratory. Dzięki HBF może połączyć swoją wiedzę w zakresie DRAM, portfolio NAND oraz zaawansowane możliwości pakowania.

Sandisk wnosi oryginalną koncepcję HBF i technologię procesową NAND. Jego umowa standaryzacyjna z 2025 roku zakładała przepustowość porównywalną z HBM przy pojemności od ośmiu do 16 razy większej. Określała również wstępny harmonogram dostarczania próbek.

Partnerstwo łączy więc uzupełniające się motywacje. Sandisk chce zbliżyć pamięć flash do obliczeń AI. SK hynix chce dostarczać większą część hierarchii pamięci, zamiast chronić HBM jako jedyną warstwę premium.

Dlatego ta historia jest większa, niż sugeruje jej ujęcie w Google News. Pierwsza specyfikacja tworzy forum, na którym producenci pamięci, projektanci procesorów i operatorzy chmur mogą negocjować wspólną architekturę. O zwycięzcy nie zadecyduje sam dokument.

Specyfikacji wciąż brakuje wiarygodności sprzętowej

Największe ryzyko HBF jest proste: jego najbardziej atrakcyjne liczby opisują specyfikację i prognozy dostawców, a nie zweryfikowany produkcyjny krzem.

Dostarczenie 512GB w gęstym stosie wiąże się z wyzwaniami produkcyjnymi. Szesnaście wyspecjalizowanych kości NAND musi zostać niezawodnie połączonych za pomocą zaawansowanego pakowania. Stos potrzebuje akceptowalnych właściwości termicznych, możliwego do opanowania odkształcania, wystarczającego uzysku oraz kości logicznej zdolnej koordynować masową równoległość.

Przepustowość tworzy kolejne wyzwanie. Macierze NAND muszą pracować równolegle, by zbliżyć się do proponowanych klas wydajności. Kontroler musi planować odczyty, korygować błędy, zarządzać uszkodzonymi blokami i utrzymywać przewidywalną obsługę przy wymagających obciążeniach.

Opóźnienia pozostają mniej jasno zdefiniowane niż przepustowość. Szczytowa prędkość 3.0TB/s mówi, ile danych może zostać przeniesionych w sprzyjających warunkach. Nie mówi, jak szybko wraca odpowiedź na małe żądanie ani jak zmienia się wydajność przy nieregularnych wzorcach dostępu.

Wnioskowanie AI często strumieniuje duże wagi modeli, co lepiej odpowiada pamięci flash niż losowe zapisy transakcyjne. Jednak pamięci podręczne mechanizmu uwagi i inny stan środowiska wykonawczego mogą zmieniać się szybko. Struktury te mogą nadal wymagać HBM lub konwencjonalnej pamięci DRAM.

Trwałość również wymaga dowodów z eksploatacji. HBF bazuje na NAND, która obsługuje ograniczoną liczbę cykli programowania i kasowania. Przechowywanie modeli z przewagą odczytu zmniejsza ten problem, ale systemy produkcyjne wciąż potrzebują aktualizacji, równoważenia i odzyskiwania po awariach.

Deklaracje dotyczące poboru energii także wymagają niezależnej weryfikacji. NAND zachowuje dane bez energii potrzebnej do odświeżania, co daje jej teoretyczną przewagę nad DRAM. Jednak kość bazowa, szeroki interfejs, korekcja błędów i równoległy dostęp do macierzy zużywają energię.

Wcześniejsza karta informacyjna Sandisk opisywała cel dla pierwszej generacji: 1.6TB/s i 512GB w stosie 16 kości. Firma twierdziła także, że będzie to jeden z najniższych kosztów na bit wśród technologii pamięci. Ani SK hynix, ani Sandisk nie opublikowały ostatecznej ceny komercyjnej ani zweryfikowanego całkowitego kosztu systemu.

Ekonomia będzie obejmować więcej niż kości NAND. Zaawansowane pakowanie, bazowa kość kontrolera, integracja UCIe, chłodzenie, projekt płyty i rozwój oprogramowania zwiększają koszty. Straty uzysku stają się szczególnie istotne w wysokich stosach zawierających wiele komponentów.

Szeroki zakres specyfikacji, od 0.4TB/s do 3.0TB/s, tworzy kolejną niepewność. Może obsłużyć kilka generacji produktów, ale sprawia, że ogólne twierdzenia o „wydajności HBF” są mniej użyteczne. Nabywcy będą musieli analizować klasę, pojemność, opóźnienia, trwałość i pobór energii każdej implementacji.

Istnieje także pętla adopcji. Dostawcy pamięci potrzebują zobowiązań ze strony producentów procesorów, zanim mocno zainwestują w produkcję. Dostawcy procesorów chcą niezawodnych próbek i wielu dostawców przed przeprojektowaniem pakietów. Operatorzy chmur chcą przetestowanych systemów przed przepisaniem oprogramowania do zarządzania pamięcią.

Otwarte standardy mogą przerwać tę pętlę, zapewniając każdemu uczestnikowi stabilny cel. Nie mogą jednak usunąć ryzyka finansowego. Konsorcjum HBF musi przełożyć zainteresowanie na projekty referencyjne, kontrolery, narzędzia walidacyjne i zobowiązania zakupowe.

Najbardziej korzystny publiczny harmonogram przedstawił Sandisk w 2025 roku. Zakładał on dostarczenie pierwszych próbek pamięci HBF w drugiej połowie 2026 roku. Oczekiwano próbek urządzeń do wnioskowania AI wykorzystujących HBF na początku 2027 roku.

Harmonogram próbek nie stał się harmonogramem produkcji masowej. Próbki pozwalają partnerom sprawdzić wykonalność. Nie potwierdzają uzysku, dostępności ani niezawodności w centrach danych.

Ta luka powinna kształtować sposób, w jaki czytelnicy interpretują ogłoszenie. SK hynix nie udowodnił, że HBF rozwiązuje problem bariery pamięciowej we wnioskowaniu. Opublikował szczegółową propozycję budowy i łączenia odpowiedniego sprzętu.

Najsilniejszy sceptyczny pogląd nie zakłada, że HBF nie ma użytecznego zastosowania. Problem pojemności pamięci jest realny, a architektury warstwowe stanowią uznaną odpowiedź inżynierską. Wątpliwość dotyczy tego, czy ta konkretna implementacja może zapewnić wystarczające korzyści po uwzględnieniu opóźnień, pakowania, oprogramowania i kosztów.

Otwarty HBF wywiera presję na szerszy rynek pamięci

Specyfikacja zmusza firmy z branży pamięci i akceleratorów do reakcji, nawet jeśli zdecydują się nie wdrażać HBF.

Samsung i Micron bezpośrednio konkurują z SK hynix w HBM. Kioxia konkuruje w NAND i łączy ją z Sandisk współpraca produkcyjna. Każda z tych firm stoi teraz przed wyborem: uczestniczyć, opracować zgodną implementację lub promować inną odpowiedź.

Dołączenie wzmocniłoby wiarygodność HBF, ale naraziłoby uczestników na standard początkowo kształtowany przez SK hynix i Sandisk. Pozostanie poza nim zachowuje strategiczną niezależność, lecz grozi tym, że dwóch konkurentów zdefiniuje powstający interfejs.

Dostawcy akceleratorów stoją przed podobnym rachunkiem. Bogata pojemnościowo warstwa flash mogłaby pozwolić im obsługiwać większe modele bez dodawania równoważnej pojemności HBM. Mogłaby też skomplikować projekt pakietu i osłabić prostotę ich istniejącej architektury pamięci.

Pozycja Nvidia zasługuje na szczególną uwagę, ponieważ jej akceleratory stanowią podstawę dużej części obecnego rynku infrastruktury AI. Nvidia nie ogłosiła wdrożenia HBF. Bez wsparcia czołowych platform akceleratorowych HBF może pozostać ograniczone do niestandardowego krzemu i wyspecjalizowanych systemów wnioskowania.

Udział Google częściowo równoważy to ryzyko. Hiperskaler z własnymi procesorami może wdrożyć nową architekturę pamięci bez oczekiwania na harmonogram komercyjnych GPU. Udane wdrożenie wewnętrzne mogłoby dostarczyć dowodów technicznych i znaczącego wolumenu.

Tenstorrent może sprawdzić, czy otwarty interfejs działa w mniejszym ekosystemie procesorowym. Jego udział poszerza także konsorcjum poza uznane firmy z branży pamięci i chmury. Jednak żaden z uczestników nie gwarantuje obecnie akceptacji na rynku masowym.

Inicjatywa HBF wpisuje się w utrwalony wzorzec sprzętu dla centrów danych. Kilka firm definiuje wspólny interfejs, publikuje go za pośrednictwem organizacji branżowej i rekrutuje użytkowników przed dojrzeniem produktów. Sukces zależy od tego, czy konkurenci uznają interoperacyjność za cenniejszą niż kontrolę.

HBM podążało inną ścieżką instytucjonalną, poprzez standardy JEDEC i ścisłą koordynację między dostawcami pamięci a projektantami procesorów. Ścieżka HBF przez OCP przybliża operatorów chmur i architektów systemów do procesu tworzenia specyfikacji.

Podejście to pasuje do zamierzonego obciążenia. Infrastruktura wnioskowania AI obejmuje procesory, pamięć, magazynowanie danych, sieci, orkiestrację i oprogramowanie aplikacyjne. Optymalizacja wyłącznie komponentu pamięciowego pominęłaby istotne wąskie gardła systemowe.

Stos HBF o pojemności 512GB nie może poprawić wydajności, gdy oprogramowanie wielokrotnie żąda małych, rozproszonych bloków. Staje się bardziej użyteczny, gdy kompilatory i środowiska wykonawcze układają wagi pod długie sekwencyjne odczyty. Architektura systemu decyduje, czy reklamowana przepustowość przełoży się na produktywną pracę.

Deweloperzy mogą więc zetknąć się z HBF przez oprogramowanie, zanim dotkną specyfikacji sprzętowych. Frameworki będą potrzebować zasad alokacji, narzędzi profilujących i mechanizmów kontroli rozmieszczenia. Operatorzy będą potrzebować obserwowalności obejmującej warstwy HBM, HBF i SSD.

Przypomina to szersze zadanie zarządzania informacją według jej znaczenia i częstotliwości dostępu. Przeszukiwalna baza wiedzy również oddziela aktywny kontekst od większych zachowanych zbiorów. HBF stosuje pokrewną hierarchię do danych maszynowych z szybkością sprzętową.

Analogia ma ograniczenia, ale zasada jest użyteczna. Najszybszy zasób pozostaje rzadki. Systemy poprawiają się, gdy przechowują natychmiast potrzebne informacje blisko, a mniej pilny materiał przenoszą do większej warstwy wspierającej.

To strategiczny argument za HBF. Nie musi zastąpić HBM, by stać się istotne. Musi sprawić, by pojemność HBM była mniej decydująca dla znaczącego zestawu obciążeń wnioskowania.

Co obserwować, gdy nagłówki Google News przeminą

Trzy sygnały zadecydują, czy HBF stanie się standardem pamięci AI, czy pozostanie ambitną architekturą na papierze.

Pierwszym sygnałem będzie fizyczne dostarczenie próbek. Publiczny harmonogram Sandisk zakładał próbki pamięci HBF w drugiej połowie 2026 roku. Działające pakiety pozwoliłyby partnerom mierzyć opóźnienia, trwałą przepustowość, trwałość, parametry termiczne i pobór energii w powtarzalnych warunkach.

Wyniki zbliżone do deklarowanych klas wydajności wzmocniłyby argument, że masowo równoległa pamięć NAND może służyć jako pamięć blisko procesora. Opóźnienia lub duże różnice między wydajnością szczytową a trwałą osłabiłyby argument specyfikacji oparty na pojemności.

Najbardziej użyteczny benchmark porównywałby kompletne systemy, a nie izolowane pakiety. Powinien mierzyć liczbę tokenów na sekundę, czas do pierwszego tokenu, energię na token oraz całkowity koszt serwera. Powinien także ujawnić, jaka część danych pozostaje w HBM.

Drugim sygnałem będzie wskazany z nazwy projekt procesora. Google i Tenstorrent dołączyły do konsorcjum, ale żadna z tych firm nie ogłosiła produkcyjnego akceleratora z HBF. Konkretny układ, pakiet lub platforma referencyjna pokazałyby, że prace integracyjne wyszły poza udział doradczy.

Próbka urządzenia do wnioskowania z początku 2027 roku, zgodna z wcześniejszym harmonogramem Sandisk, potwierdziłaby deklaracje konsorcjum dotyczące realizacji. Cisza ze strony partnerów procesorowych sugerowałaby, że prace nad pakowaniem lub oprogramowaniem pozostają nierozwiązane.

Dołączenie Nvidia, AMD lub innego dostawcy komercyjnych akceleratorów byłoby szczególnie istotne. Ich udział rozszerzyłby HBF poza systemy niestandardowe i zwiększył jego szanse na przyciągnięcie wielu dostawców pamięci.

Trzecim sygnałem będzie szersze wsparcie dostawców i oprogramowania. Otwarty standard staje się odporny, gdy niezależne firmy mogą budować zgodne komponenty. Dlatego Samsung, Micron, Kioxia, dostawcy kontrolerów, firmy pakujące i operatorzy chmur mają kluczowe znaczenie.

Wsparcie oprogramowania ma równie duże znaczenie. Frameworki AI muszą rozpoznawać HBF jako odrębną warstwę i rozmieszczać dane zgodnie ze wzorcami dostępu. Bez tej warstwy deweloperzy staną przed ręcznym dostrajaniem i niespójną wydajnością.

Sierpniowe ogłoszenie SK hynix wyznacza ważny punkt kontrolny. Firma i Sandisk zdefiniowały pojemności, klasy wydajności, konfiguracje stosów, łączność i cele niezawodnościowe. Google i Tenstorrent zapewniły wiarygodny udział branżowy.

Ogłoszenie nie rozstrzyga jednak trudniejszych kwestii. Żaden publicznie dostępny system produkcyjny nie wykazał deklarowanej równowagi między pojemnością, przepustowością, opóźnieniami, poborem energii i kosztem. Żaden czołowy producent akceleratorów komercyjnych nie zobowiązał się do wykorzystania tego interfejsu.

Czytelnicy śledzący tę historię za pośrednictwem Google News powinni obserwować te trzy sygnały, zamiast kolejną rundę teoretycznych porównań. Należy szukać zmierzonego krzemu, nazwanego akceleratora oraz dodatkowych niezależnych wdrożeń.

Jeśli pojawią się wszystkie trzy, HBF może stać się praktycznym uzupełnieniem HBM i SSD. Jeśli będą przybywać jedynie specyfikacje i symulacje, branża nadal będzie zwiększać pojemność na potrzeby inferencji poprzez większą ilość HBM, konwencjonalne pamięci masowe i optymalizację oprogramowania.

Kolejny rozstrzygający nagłówek powinien zatem zawierać nazwę produktu i wyniki pomiarów dla rzeczywistych obciążeń. Do tego czasu SK hynix otworzył obiecującą drogę przez barierę pamięciową AI, lecz sprzęt jeszcze jej nie przekroczył.