Sandisk i SK hynix publikują otwartą specyfikację HBF, ale teraz nadchodzi test sprzętowy

Sandisk i SK hynix opublikowały pierwszą otwartą specyfikację High Bandwidth Flash 4 sierpnia, zaledwie sześć miesięcy po uruchomieniu swojej grupy standaryzacyjnej. Informacja trafiła do Google News z wyjątkowo konkretną obietnicą dotyczącą rozwijającej się technologii pamięci: pojemnością do 512GB i przepustowością sięgającą 3TB/s.

To połączenie ma wypełnić rosnącą lukę w systemach AI. High Bandwidth Memory, czyli HBM, zapewnia wysoką szybkość blisko procesorów, ale pozostaje ograniczona pojemnościowo. Dyski półprzewodnikowe oferują znacznie większą pojemność, lecz znajdują się zbyt daleko od procesora dla wielu zadań wnioskowania wrażliwych na opóźnienia.

High Bandwidth Flash, znana jako HBF, ma zajmować warstwę pomiędzy nimi. Sandisk i SK hynix nie proponują zastąpienia przez pamięć NAND flash każdego stosu HBM. Chcą, aby systemy wykorzystywały HBM do najczęściej używanych danych, a HBF do większych zestawów roboczych, które nadal wymagają szybkiego dostępu.

Specyfikacja ułatwia projektantom procesorów ocenę takiej architektury. Nie dowodzi jednak, że HBF może zapewnić deklarowaną wydajność w sprzęcie produkcyjnym. Prawdziwa rywalizacja nie toczy się więc między Sandisk a SK hynix. Chodzi o otwartą specyfikację kontra prace inżynieryjne i wdrożeniowe, które wciąż są potrzebne.

Specyfikacja HBF przekształca ideę pamięci we wspólny cel

Publikacja daje zespołom pracującym nad procesorami, pakowaniem i oprogramowaniem wspólny cel projektowy dla HBF, ale nie dostarcza gotowego produktu.

SK hynix ogłosił specyfikację wspólnie z Sandisk podczas FMS 2026 w Santa Clara w Kalifornii. Wydarzenie trwa od 4 do 6 sierpnia i koncentruje się na technologiach pamięci oraz pamięci masowej.

Firmy opublikowały prace za pośrednictwem Open Compute Project, czyli OCP — organizacji branżowej skupionej na otwartej infrastrukturze centrów danych. Ten wybór ma znaczenie, ponieważ HBF wymaga udziału większej liczby podmiotów niż dwóch dostawców pamięci.

Według ogłoszenia specyfikacji HBF początkowy projekt obsługuje dwie konfiguracje fizyczne. Jedną opcję zapewnia stos ośmiu układów, a stos 16 układów obsługuje najwyższą ogłoszoną pojemność.

Specyfikacja obejmuje pojemność do 512GB. Definiuje również trzy klasy wydajności, od około 0.4TB/s do 3TB/s przepustowości.

Klasy te pozwalają projektantom systemów dopasowywać implementacje HBF do różnych wymagań dotyczących obciążeń i kosztów. Niższa klasa mogłaby obsługiwać mniej wymagające zadania wnioskowania bez wymuszania w każdym projekcie zastosowania najbardziej złożonego pakietu.

Publikacja obejmuje także właściwości elektryczne, niezawodność pakowania, połączenia z procesorem oraz wytyczne dotyczące wejścia i wyjścia oprogramowania. Te szczegóły wyprowadzają HBF poza poziom koncepcji prezentacyjnej i przybliżają ją do czegoś, co zespoły inżynieryjne mogą oceniać.

Połączenie z procesorem wykorzystuje Universal Chiplet Interconnect Express, czyli UCIe. UCIe to otwarty interfejs na poziomie pakietu, który łączy odrębne rdzenie półprzewodnikowe w jednym systemie.

Oficjalne specyfikacje UCIe obejmują połączenia fizyczne, protokoły, działanie oprogramowania i testy zgodności. Wykorzystanie tego interfejsu zmniejsza potrzebę uzależnienia HBF od prywatnego połączenia jednego dostawcy procesorów.

Tworzy również drogę do łączenia HBF z CPU, GPU i innymi akceleratorami. Ta elastyczność ma kluczowe znaczenie dla argumentu za otwartym standardem, ponieważ infrastruktura AI obejmuje więcej niż jedną architekturę procesorów.

Standard interfejsu nie tworzy jednak automatycznie interoperacyjności. Dostawcy nadal potrzebują współdziałających kontrolerów, metod pakowania, oprogramowania układowego, sterowników, zasad zarządzania pamięcią i testów zgodności.

To rozróżnienie łatwo przeoczyć w krótkim nagłówku Google News. Sandisk i SK hynix opublikowały specyfikację, a nie powszechnie dostępne moduły HBF ani produkcyjne serwery AI.

Ich tempo nadal jest godne uwagi. Sandisk i SK hynix ogłosiły pierwotne partnerstwo standaryzacyjne w sierpniu 2025 roku. Uruchomiły strumień prac OCP w lutym 2026 roku i opracowały tę pierwszą specyfikację około sześć miesięcy później.

Według SK hynix w konsorcjum uczestniczą obecnie Google i twórca procesorów AI Tenstorrent. Ich obecność zapewnia projektowi cenny wkład zarówno ze strony obciążeń, jak i procesorów.

Żadna z firm nie ogłosiła kwalifikowanego systemu produkcyjnego wykorzystującego tę specyfikację. Żaden niezależny benchmark nie potwierdził jeszcze przepustowości, opóźnień, trwałości ani efektywności energetycznej zgodnego urządzenia komercyjnego.

Otwarty dokument zmienia więc to, o czym branża może rozmawiać. Zamiast debatować nad niezdefiniowaną kategorią pamięci, inżynierowie mogą analizować rozmiary stosów, klasy przepustowości, interfejsy, oczekiwania dotyczące pakowania i wymagania programowe.

To jest bezpośrednie wydarzenie. Szersze pytanie brzmi, dlaczego wnioskowanie AI w ogóle potrzebuje kolejnej warstwy pamięci.

Dlaczego wnioskowanie AI wywiera presję na HBM i SSD

HBF istnieje, ponieważ wnioskowanie coraz częściej potrzebuje dostępu do zbiorów danych na poziomie HBM, które są zbyt duże, by w całości przechowywać je w HBM.

Trenowanie AI przyciąga dużą część uwagi poświęcanej infrastrukturze, ale wnioskowanie tworzy inny problem pamięciowy. Trenowanie buduje model. Wnioskowanie wielokrotnie uruchamia go, by odpowiadać na zapytania, generować media, korzystać z narzędzi lub obsługiwać agenta.

Wdrożona usługa może potrzebować wag modelu, danych uwagi, buforowanych tokenów, indeksów wyszukiwania i kontekstu aplikacji. Utrzymanie każdego aktywnego zestawu danych w najszybszej pamięci staje się trudne wraz ze wzrostem modeli i liczby równoległych obciążeń.

HBM umieszcza stosy DRAM blisko procesora i łączy je szerokim interfejsem. Taka konstrukcja zapewnia dużą przepustowość akceleratorom, które muszą szybko przenosić duże ilości danych.

Jej zalety nie eliminują ograniczeń fizycznych. Przestrzeń w pakiecie, złożoność produkcji, energia, pojemność i podaż wpływają na to, ile HBM może znaleźć się obok każdego procesora.

Korporacyjne dyski SSD rozwiązują inny problem. Przechowują znacznie więcej informacji przy niższym koszcie na bit, a pamięć NAND flash zachowuje dane bez ciągłego zasilania. Ich tradycyjna ścieżka pamięci masowej zwiększa opóźnienia i narzut programowy.

Pozostaje więc luka architektoniczna. Część danych używanych do wnioskowania nie wymaga najniższych możliwych opóźnień HBM, ale potrzebuje szybszego i bardziej bezpośredniego dostępu niż zapewnia tradycyjna ścieżka SSD.

SK hynix opisuje HBF jako warstwę wspierającą, podczas gdy HBM nadal obsługuje pracę wymagającą największej przepustowości. Ten model pamięci warstwowej przypisuje dane do różnych technologii zgodnie z częstotliwością dostępu i potrzebami wydajnościowymi.

Duży model stanowi użyteczny przykład. Często wykorzystywane fragmenty mogłyby pozostać w HBM, a mniej aktywne wagi znajdowałyby się w HBF. SSD mógłby przechowywać dane, których system potrzebuje rzadziej.

System przenosiłby następnie informacje między warstwami wraz ze zmianą warunków obciążenia. Podejście to przypomina ugruntowane hierarchie pamięci podręcznej, ale pojemności, wymagania dotyczące przepustowości i wyzwania związane z pakowaniem są znacznie większe.

Korzyść zależy od decyzji dotyczących rozmieszczenia danych. Jeśli oprogramowanie wielokrotnie pobiera niewłaściwe dane z wolniejszej warstwy, rdzenie procesora mogą czekać, a ogólna wydajność może spaść.

HBF musi zatem stać się czymś więcej niż gęstą pamięcią flash obok akceleratora. Otaczający ją system potrzebuje kontrolerów i oprogramowania, które przewidzą, jakie dane powinny znaleźć się w każdej warstwie pamięci.

Agentic AI wzmacnia tę presję. Agent może utrzymywać dłuższe historie, konsultować zewnętrzną wiedzę, wywoływać narzędzia programowe i koordynować kilka operacji modelu dla jednego zapytania użytkownika.

Takie przepływy pracy tworzą większe i mniej przewidywalne zestawy robocze. Mogą też zajmować infrastrukturę wnioskowania przez dłuższy czas niż pojedynczy prompt i odpowiedź.

Dla deweloperów pytanie nie brzmi, czy każda aplikacja potrzebuje HBF. Chodzi o to, czy przyszłe systemy wnioskowania potrzebują pośredniej warstwy, która ograniczy kosztowną pojemność HBM bez powrotu do zwykłej pamięci masowej.

Dla nabywców korporacyjnych architektura pamięci może wpływać na wykorzystanie serwerów, czas odpowiedzi, zużycie energii i liczbę modeli mieszczących się w jednym systemie. Czynniki te kształtują koszty operacyjne, nawet gdy użytkownicy nigdy nie widzą komponentów znajdujących się pod spodem.

Pracownicy wiedzy również mają pośredni interes w tym rozwiązaniu. Większy lokalny kontekst i bardziej trwałe agenty wymagają infrastruktury, która może efektywnie zachowywać i odzyskiwać dane robocze.

Przeszukiwalna baza wiedzy mierzy się z podobnym problemem rozmieszczenia danych na poziomie aplikacji. Odpowiednie materiały muszą szybko trafiać do modelu bez ładowania każdego dokumentu do najszybszej warstwy kontekstowej.

HBF odnosi się do sprzętowej strony tego szerszego wyzwania. Próbuje utrzymać więcej danych związanych z modelem wystarczająco blisko obliczeń, aby umożliwić praktyczne wnioskowanie, bez traktowania każdego bitu jak danych premium dla HBM.

Wywiera to presję na dostawców procesorów, operatorów chmur i producentów pamięci. Każda z tych grup musi zdecydować, czy kolejna warstwa wystarczająco poprawia system, by uzasadnić dodatkową złożoność pakowania i oprogramowania.

Uwaga Google News ukrywa prawdziwą rywalizację: specyfikacja kontra krzem

Specyfikacja jest wystarczająco wiarygodna, by przyciągać partnerów, ale tylko działający krzem może dowieść, że HBF powinno znaleźć się obok procesorów AI.

Sandisk po raz pierwszy przedstawił HBF jako architekturę pamięci opartą na NAND, przeznaczoną do wnioskowania. Pierwotny plan firmy zakładał pierwsze próbki HBF w drugiej połowie 2026 roku.

Firma oczekiwała również próbek pierwszych urządzeń do wnioskowania wykorzystujących HBF na początku 2027 roku. Cele te uwzględniono w jej publikacji o partnerstwie z 2025 roku.

Specyfikacja z sierpnia 2026 roku nie potwierdza, że te etapy dotyczące próbek zostały ukończone. Ustanawia techniczne ramy, których powinny przestrzegać potencjalne produkty.

Koncepcja pierwszej generacji Sandisk zakłada 1.6TB/s przepustowości odczytu i 512GB w stosie 16 układów. Przewiduje się, że późniejsze generacje przekroczą 2TB/s, a ostatecznie osiągną 3.2TB/s.

Liczby te pochodzą z własnego opracowania technicznego HBF firmy Sandisk. Pozostają celami firmy, a nie niezależnymi pomiarami z systemów komercyjnych.

Opracowanie podaje również, że symulowana konfiguracja HBF osiągnęła wynik w granicach 2.2 procent modelu HBM o nieograniczonej pojemności w jednym konkretnym teście. Obciążenie wykorzystywało ośmiobitowe wagi z modelu Llama 3.1 405B.

Wynik ten wymaga ostrożnej interpretacji. Sandisk oparł go na wewnętrznych testach i symulacji, a porównanie zakładało nieograniczoną pojemność HBM. Rzeczywiste produkty będą musiały uwzględniać skończoną pojemność, ograniczenia termiczne, zachowanie oprogramowania i konkurencyjny ruch danych.

NAND zachowuje się też inaczej niż DRAM. Oferuje gęstość i nieulotność, ale zwykle wiąże się z większymi opóźnieniami dostępu i bardziej rygorystycznymi kwestiami dotyczącymi trwałości.

Większy rozmiar strony HBF może komplikować obciążenia, które żądają małych, rozproszonych fragmentów danych. Przenoszenie niepotrzebnych bajtów zużywa przepustowość i energię, nawet jeśli deklarowana szybkość transferu wygląda imponująco.

Wnioskowanie modelu z przewagą odczytu jest prawdopodobnym punktem wyjścia, ponieważ wytrenowane wagi zmieniają się rzadziej niż wiele innych struktur danych. Zastosowania bardziej intensywnie wykorzystujące zapis wywierałyby większą presję na zarządzanie trwałością.

Pakowanie stanowi kolejny test. Stos 16 układów wymaga spójnej produkcji, kontroli termicznej, integralności sygnału i akceptowalnej wydajności produkcyjnej.

Projekt może działać w symulacji, a mimo to okazać się kosztowny przy produkcji na dużą skalę. Wady jednego komponentu mogą wpłynąć na ekonomikę całego zaawansowanego pakietu.

Wartość 512 GB jest zatem istotna, lecz użyteczna pojemność to tylko jedna część produktu. Nabywcy będą analizować rozkład opóźnień, utrzymaną przepustowość, zarządzanie błędami, temperaturę, żywotność i zachowanie przy mieszanych obciążeniach.

Trzy klasy przepustowości rodzą także pytania wdrożeniowe. Specyfikacja określa cele, ale dostawcy muszą wykazać, które procesory i pakiety są w stanie utrzymać każdą z tych klas.

UCIe zapewnia podstawę w postaci otwartego interfejsu, a nie gwarancję, że każdy stos HBF połączy się z dowolnym akceleratorem. Programy zgodności i projekty referencyjne zdecydują o tym, jaką interoperacyjność faktycznie uzyska rynek.

W tym miejscu znaczenie mają Google i Tenstorrent. Google wnosi doświadczenie w obsłudze dużych usług AI i projektowaniu niestandardowych akceleratorów. Tenstorrent może sprawdzić, czy interfejs działa poza dominującym modelem GPU.

Ich członkostwo w konsorcjum jest pozytywnym sygnałem dla adopcji. Nie jest jednak równoznaczne ze zobowiązaniem zakupowym, zapowiedzią produktu ani wdrożeniem.

Brak wskazanego procesora, który ma trafić na rynek, pozostaje kluczową luką wymagającą weryfikacji. HBF potrzebuje co najmniej jednej platformy akceleratorowej z kontrolerem, projektem pakietu, stosem oprogramowania i udokumentowaną korzyścią dla obciążeń.

Bez tej integracji standard ryzykuje pozostanie technicznie interesującym, lecz komercyjnie peryferyjnym rozwiązaniem. Branża półprzewodników zna wiele specyfikacji, które nigdy nie osiągnęły szerokiego zastosowania produkcyjnego.

Sandisk i SK hynix zwiększają szanse, ponieważ ich kompetencje się uzupełniają. Sandisk wnosi projektowanie NAND i architekturę pamięci flash, podczas gdy SK hynix obejmuje NAND, DRAM, HBM, pakowanie i produkcję masową.

Partnerstwo ogranicza też wrażenie, że HBF jest jedynie zastrzeżoną próbą ochrony jednego dostawcy. Publikacja przez OCP zachęca do szerszego przeglądu i potencjalnego udziału.

Mimo to otwartość może spowalniać decyzje, gdy firmy nie zgadzają się co do szczegółów implementacji. Ekosystem zyskuje zasięg, przyjmując więcej uczestników, lecz prace nad konsensusem i zgodnością wymagają czasu.

Specyfikacja pokonała pierwszą barierę instytucjonalną. Następne są walidacja krzemu, potem walidacja systemowa, wsparcie programowe, kwalifikacja klientów i ekonomika produkcji.

Nagłówek może przedstawiać publikację jako zakończenie. Rynki sprzętowe traktują ją jako początek dłuższego testu.

HBF uzupełnia HBM, a ten kompromis definiuje jego rynek

HBF wygrywa tylko wtedy, gdy dodatkowa pojemność rekompensuje koszty opóźnień i integracji, nie osłabiając obsługiwanych obciążeń.

Przedstawianie HBF jako zamiennika HBM tworzy niewłaściwą rywalizację. SK hynix wyraźnie pozycjonuje je między HBM a SSD, przy czym HBM zachowuje rolę w najbardziej wymagającej klasie przepustowości.

To rozróżnienie chroni architekturę przed nierealistycznym standardem. HBF oparty na NAND nie musi pokonywać DRAM w każdej operacji. Musi umożliwiać użyteczne wykorzystanie większej puli pamięci przy akceptowalnej wydajności.

Sandisk wcześniej informował, że HBF może oferować od ośmiu do 16 razy większą pojemność niż HBM przy podobnym koszcie. Obecna otwarta specyfikacja jest bardziej powściągliwa: definiuje konfiguracje i klasy wydajności, zamiast potwierdzać to twierdzenie ekonomiczne.

Porównanie pojemności będzie też zmieniać się z czasem. Dostawcy HBM nadal zwiększają pojemność stosów i przepustowość, więc HBF konkuruje ze zmieniającym się punktem odniesienia.

HBM korzysta z ugruntowanego wsparcia dla akceleratorów i popytu produkcyjnego. Plany rozwoju procesorów, inwestycje w pakowanie, kontrolery pamięci i narzędzia programowe już się wokół niego koncentrują.

HBF zaczyna bez tej zainstalowanej bazy. Jego proponowaną przewagą jest gęstość, a nie dojrzałość.

SSD wywierają presję z drugiej strony. Nie mogą dorównać warstwie pamięci w pakiecie, ale ulepszenia oprogramowania i interkonektów mogą zwiększyć użyteczność pamięci masowej dla obciążeń AI.

Projektanci systemów mogą uznać, że ulepszone buforowanie SSD zapewnia wystarczającą wydajność przy mniejszym ryzyku integracyjnym. Inni mogą zarezerwować większe pule HBM dla obciążeń premium zamiast dodawać trzecią warstwę.

HBF musi przewyższać te alternatywy na poziomie całego systemu. Korzystny koszt na bit nie pomaga, jeśli dodatkowe kontrolery, powierzchnia pakietu, chłodzenie lub oprogramowanie niwelują oszczędności.

Twierdzenia dotyczące energii wymagają podobnej ostrożności. NAND przechowuje informacje bez zasilania odświeżającego, co daje mu strukturalną przewagę dla zapisanych danych.

Zużycie energii obejmuje jednak także przemieszczanie danych, korekcję błędów, kontrolery i zarządzanie termiczne. Istotną miarą jest energia na ukończoną inferencję, a nie odizolowana charakterystyka poboru mocy komponentu.

Warstwa zarządzania pamięcią staje się decydująca. Oprogramowanie musi identyfikować często używane dane, odpowiednio je rozmieszczać i przenosić, zanim procesor się zatrzyma.

Wymóg ten tworzy możliwości dla dostawców akceleratorów i operatorów chmurowych. Kontrolują oni harmonogramowanie, zachowanie kompilatora, obsługę modeli i telemetrię, które mogą kierować rozmieszczaniem danych.

Tworzy też ryzyko uzależnienia od dostawcy. Otwarty interfejs fizyczny nie gwarantuje, że oprogramowanie wyższego poziomu pozostanie przenośne między procesorami i dostawcami pamięci.

Deweloperzy będą potrzebować narzędzi ujawniających zachowanie HBF bez zmuszania każdego zespołu modelowego do ręcznego zarządzania stronami. W przeciwnym razie tylko najwięksi operatorzy infrastruktury mogą osiągać powtarzalne korzyści.

Pierwsze atrakcyjne obciążenia prawdopodobnie będą miały kilka wspólnych cech. Będą intensywnie odczytowe, ograniczone pojemnością, tolerujące pewne dodatkowe opóźnienia i wystarczająco istotne, by uzasadnić wyspecjalizowany sprzęt.

Obsługa dużych modeli pasuje do tego profilu. Systemy wyszukiwania, modele rekomendacyjne i niektóre aplikacje multimodalne również mogą skorzystać, gdy aktywne dane przekraczają praktyczną pojemność HBM.

Nie dotyczy to każdego zadania AI. Małe modele, które wygodnie mieszczą się w istniejącej pamięci, niewiele zyskują na kolejnej warstwie. Aplikacje wrażliwe na opóźnienia i o nieregularnych wzorcach dostępu mogą preferować HBM mimo jego ograniczeń pojemności.

Trening stanowi trudniejszy przypadek, ponieważ wielokrotnie odczytuje i zapisuje duże struktury danych. Pierwotna narracja wokół HBF koncentruje się na inferencji nie bez powodu.

Ten kompromis utrzymuje zapowiedź w realiach. HBF nie eliminuje hierarchii pamięci. Dodaje kolejny poziom i prosi projektantów systemów o bardziej inteligentne zarządzanie tą hierarchią.

Szersza strategia SK hynix wzmacnia ten pogląd. Firma promuje portfolio obejmujące HBM, konwencjonalny DRAM, NAND, korporacyjne SSD i powstające warstwy pamięci.

Portfolio to może ograniczyć wewnętrzną konkurencję między HBM a HBF. SK hynix może wspierać dowolną kombinację wybraną przez klientów, choć ekonomika poszczególnych produktów nadal będzie wpływać na jego priorytety.

Sandisk ma inną motywację. Koncentracja firmy na pamięci flash sprawia, że inferencja AI jest okazją do zbliżenia NAND do wysokowartościowych obliczeń.

Partnerstwo łączy te motywacje wokół wspólnego standardu. Nie eliminuje konkurencji ze strony Samsung, Micron, Kioxia, dostawców procesorów ani alternatywnych architektur pamięci.

Udział konkurentów wzmocniłby HBF jako kategorię branżową. Mógłby jednak osłabić zdolność Sandisk i SK hynix do różnicowania swoich produktów.

To zdrowe napięcie dla otwartego standardu. Szeroka adopcja zwykle wymaga od dostawców rezygnacji z części kontroli w zamian za większy rynek.

Trzy sygnały pokażą, czy HBF wyjdzie poza nagłówek

Kolejne dowody muszą pochodzić z próbek, zobowiązań dotyczących procesorów i zmierzonych obciążeń, a nie z kolejnej prezentacji specyfikacji.

Pierwszym sygnałem będzie działający krzem HBF powiązany z nową specyfikacją. Wcześniejsza mapa drogowa Sandisk zakładała pierwsze próbki w drugiej połowie 2026 roku, pozostawiając ograniczone okno na realizację.

Przydatna zapowiedź próbek powinna wskazywać pojemność, klasę przepustowości, konfigurację pakietu i status testów. Powinna też odróżniać wewnętrzne próbki inżynieryjne od sprzętu dostępnego dla klientów.

Niezależne testy lub testy klientów dodatkowo wzmocniłyby argumentację. Zmierzone opóźnienia, utrzymana przepustowość, pobór mocy, wytrzymałość i temperatura mają większe znaczenie niż szczytowa wartość transferu.

Jeśli zgodne próbki pojawią się zgodnie z harmonogramem, specyfikacja zyska wiarygodność jako podstawa produktu. Opóźnienie sugerowałoby, że pakowanie, zachowanie NAND, kontrolery lub produkcja pozostają nierozwiązane.

Drugim sygnałem będzie wskazany procesor lub platforma chmurowa. Google i Tenstorrent uczestniczą w konsorcjum, ale ani udział, ani wystąpienia panelowe nie potwierdzają komercyjnej adopcji.

Poważne zobowiązanie połączyłoby HBF z planem rozwoju procesora, pakietem referencyjnym, płytą rozwojową lub wdrożeniem chmurowym. Wskazałoby też, w jaki sposób oprogramowanie przydziela dane między HBM a HBF.

Obserwuj wsparcie dla kontrolerów i narzędzia deweloperskie obok sprzętu. Urządzenie pamięci bez oprogramowania do harmonogramowania, profilowania i rozmieszczania danych nie może zapewnić pełnych korzyści systemowych.

Jedna zaangażowana platforma nie zagwarantuje standardu branżowego. Ustali jednak, że projektant procesora dostrzega wystarczającą wartość, by ponieść koszt integracji.

Kilku uczestników ze strony procesorów lub chmury wsparłoby tezę o otwartym ekosystemie. Pojedyncza zastrzeżona implementacja zawęziłaby rolę HBF i zwiększyła zależność od jednego klienta.

Trzecim sygnałem będą dowody dotyczące obciążeń w realistycznych ograniczeniach. Symulacja Sandisk oferuje punkt wyjścia, ale systemy produkcyjne muszą obsługiwać ograniczoną HBM, mieszane żądania, limity termiczne i zmieniające się wzorce dostępu.

Benchmarki powinny porównywać kompletne konfiguracje, a nie odizolowane komponenty. System HBF musi wykazać przepustowość, opóźnienia, zużycie energii i koszt względem większych pul HBM lub alternatyw opartych na SSD.

Najbardziej miarodajne testy obejmą inferencję dużych modeli z wieloma równoczesnymi użytkownikami. Powinny również wyjaśniać precyzję modelu, rozmiar partii, długość kontekstu, politykę buforowania i wykorzystanie procesora.

Korzystny wynik wykazałby, że HBF utrzymuje zajętość kosztownych jednostek obliczeniowych, jednocześnie obsługując większe aktywne modele. Wzmocniłby argument za pamięcią warstwową wraz ze skalowaniem inferencji.

Słabe wyniki ujawniłyby koszt opóźnień NAND lub przemieszczania danych. Mogłyby ograniczyć HBF do węższych zastosowań, w których pojemność ma większe znaczenie niż czas odpowiedzi.

Udostępnienie specyfikacji przez OCP daje badaczom i potencjalnym użytkownikom wspólną podstawę dla tych ocen. Uruchomienie otwartego strumienia prac pokazuje również, że firmy zamierzają rekrutować ekosystem, zamiast utrzymywać HBF jako zamknięte rozwiązanie.

Czytelnicy śledzący tę historię przez Google News powinni rozdzielać każdy przyszły kamień milowy. Członek konsorcjum, próbka, zintegrowane urządzenie i wdrożenie produkcyjne reprezentują bardzo różne poziomy dowodów.

Sandisk i SK hynix ukończyły pierwszy z tych etapów. Zdefiniowały otwartą architekturę z jasnymi celami dotyczącymi pojemności, przepustowości, interfejsu, pakowania i oprogramowania.

Teraz ciężar przenosi się z dokumentu standardu na zespoły inżynieryjne. Muszą one wykazać, że HBF można niezawodnie produkować, łączyć z różnymi procesorami i zarządzać nim bez tworzenia nowego, kosztownego wąskiego gardła.

Wynik ma znaczenie wykraczające poza dwie firmy pamięciowe. Udany sprzęt HBF zapewniłby projektantom systemów AI kolejny sposób równoważenia pojemności, przepustowości, energii i kosztu.

Niepowodzenie również przyniosłoby użyteczną lekcję. Pokazałoby, że luki między HBM a SSD nie można zamknąć po prostu przez umieszczenie gęstego NAND bliżej obliczeń.

Kolejny nagłówek w Google News, który warto otworzyć, powinien zatem zawierać więcej niż kolejne partnerstwo. Szukaj wymiernego krzemu, wskazanego procesora i wyniku obciążenia, który inna organizacja może przeanalizować.

Dopóki te sygnały się nie pojawią, HBF pozostaje wyjątkowo szczegółową propozycją z wiarygodnymi sponsorami. Nie jest jeszcze sprawdzoną warstwą w produkcyjnej infrastrukturze AI.

Śledź próbki, integracje i benchmarki, a nie liczbę zapowiedzi. Który dostawca procesorów jako pierwszy pokaże, że otwarte HBF może poprawić działanie rzeczywistego systemu inferencyjnego?