SK Hynix otwiera HBF wraz z Google, zwiększając presję na rywali w dziedzinie pamięci AI

SK Hynix opublikował wraz z Sandisk pierwszą otwartą specyfikację HBF, wprowadzając do przekazów Google News stos pamięci o pojemności 512 GB oraz cel przepustowości 3 TB/s. Ogłoszenie daje projektantom układów AI konkretną alternatywę pomiędzy kosztowną pamięcią o wysokiej przepustowości a wolniejszą pamięcią półprzewodnikową.

Specyfikacja nie zastępuje HBM, która wciąż jest niezbędna do zasilania akceleratorów z maksymalną szybkością. Zamiast tego High Bandwidth Flash, czyli HBF, dodaje większą warstwę opartą na NAND blisko procesora. Taka pojemność mogłaby utrzymywać wagi modeli i dane inferencyjne bliżej zasobów obliczeniowych, ograniczając powtarzające się transfery z konwencjonalnych dysków SSD.

Spór przenosi się teraz z poziomu propozycji technicznej na pole rywalizacji o wdrożenia. Według firm Google i projektant układów AI Tenstorrent uczestniczyli w pracach standaryzacyjnych. Nvidia, AMD, Samsung, Micron i inni czołowi dostawcy półprzewodników nie zadeklarowali jednak publicznie poparcia dla HBF.

Specyfikacja HBF zmienia propozycję pamięci w otwartą rywalizację

SK Hynix i Sandisk przekształcili HBF ze wspólnej ambicji w specyfikację, którą inne firmy mogą oceniać i wdrażać.

Partnerzy przedstawili pierwsze standardowe specyfikacje HBF podczas konferencji Future of Memory and Storage w Kalifornii 4 sierpnia 2026 roku. Udostępnili tę pracę za pośrednictwem Open Compute Project, organizacji rozwijającej otwarte projekty infrastruktury wspólnie z operatorami chmurowymi i dostawcami sprzętu.

To ważny wybór, ponieważ HBF wymaga udziału wykraczającego poza dwóch dostawców pamięci. Zastrzeżony interfejs wymagałby od firm procesorowych zaakceptowania zależności od jednego dostawcy. Otwarta specyfikacja daje projektantom układów, firmom zajmującym się pakowaniem, twórcom oprogramowania i konkurencyjnym producentom pamięci wspólny punkt wyjścia technicznego.

Początkowy projekt obsługuje konfiguracje NAND z ośmioma i 16 kośćmi. W najwyższym wariancie jeden pakiet może zapewnić 512 GB pojemności. Klasy wydajności obejmują zakres od około 400 GB/s do 3 TB/s, według szczegółów technicznych podanych po prezentacji.

Liczby te umieszczają HBF na nieznanym dotąd obszarze rynku. Konwencjonalny firmowy SSD może oferować ogromną pojemność, lecz łączy się przez interfejsy zaprojektowane dla pamięci blokowej. HBM znajduje się obok akceleratora i zapewnia znacznie wyższą przepustowość, ale ma mniejszą pojemność, a jej pakowanie nadal jest kosztowne.

HBF próbuje zająć przestrzeń pomiędzy nimi. SK Hynix opisuje ją jako nową warstwę pamięci między HBM a SSD, zaprojektowaną specjalnie dla obciążeń inferencyjnych. NAND zapewnia gęstość i nieulotność, podczas gdy pakowanie warstwowe i równoległe ścieżki dostępu zwiększają przepustowość.

Partnerzy rozpoczęli formalne prace standaryzacyjne przed opublikowaniem tych specyfikacji. W lutym utworzyli dedykowany strumień prac w ramach OCP po spotkaniu konsorcjum w siedzibie Sandisk w Milpitas. Plan standaryzacji przedstawiał HBF jako infrastrukturę dla skalowalnej, energooszczędnej inferencji AI.

Sierpniowe ujawnienie stanowi zatem postęp, a nie niespodziewany wynalazek. Przekłada wcześniejsze założenia na wymagania dotyczące pojemności, przepustowości, interfejsu, parametrów elektrycznych, pakowania, niezawodności i oprogramowania.

Specyfikacja ma wykorzystywać UCIe, czyli Universal Chiplet Interconnect Express, do połączenia pakietu HBF z procesorem hosta. UCIe definiuje wspólne połączenie między kośćmi dla chipletów montowanych w jednym pakiecie.

Interfejs ten ma kluczowe znaczenie dla otwartej strategii. Wspólne łącze może umożliwić różnym procesorom komunikację z kompatybilnymi urządzeniami HBF, bez konieczności tworzenia całkowicie zastrzeżonego połączenia dla każdej kombinacji.

Otwarty dokument nie jest jednak tym samym co otwarty rynek. Dostawcy nadal potrzebują kości możliwych do produkcji, logiki bazowej, możliwości pakowania, obsługi kontrolerów, oprogramowania firmware, integracji z systemami operacyjnymi oraz klientów gotowych zweryfikować kompletny system.

SK Hynix i Sandisk wyznaczyli linię startu. Nie wyłonili jeszcze zwycięzcy.

Dlaczego inferencja AI potrzebuje warstwy między HBM a SSD

Najmocniejszy argument za HBF wynika z obciążeń inferencyjnych, których użyteczne dane nie mieszczą się już wygodnie w pojemności HBM akceleratora.

Trenowanie i inferencja obciążają pamięć w różny sposób. Trenowanie wielokrotnie aktualizuje parametry modelu i wymaga wysokiej przepustowości między wieloma akceleratorami. Inferencja obsługuje zapytania do już wytrenowanego modelu, często jednocześnie zarządzając wagami modelu, danymi uwagi i rosnącymi pamięciami podręcznymi.

Jednym z istotnych obciążeń jest pamięć podręczna klucz-wartość, zwykle skracana do KV cache. Przechowuje ona informacje o uwadze generowane podczas przetwarzania promptu przez model, umożliwiając systemowi ponowne wykorzystanie wcześniejszych obliczeń przy generowaniu kolejnych tokenów.

Dłuższe konteksty i równocześni użytkownicy powiększają tę pamięć podręczną. Systemy wyszukiwania mogą również utrzymywać znaczne indeksy lub embeddingi blisko akceleratorów. Duże modele rekomendacyjne dodają kolejną klasę danych, która korzysta z większej pojemności blisko zasobów obliczeniowych.

HBM zapewnia przepustowość, której potrzebują te procesory, ale pojemności nie można zwiększać bez ograniczeń. Każdy dodatkowy stos wpływa na powierzchnię pakietu, pobór energii, prowadzenie sygnałów, uzysk i koszt. Przenoszenie nadmiarowych danych na SSD wprowadza większe opóźnienia i ścieżkę dostępu zorientowaną na pamięć masową.

HBF proponuje kompromis. Jego najszybsza klasa zbliża się do zakresu przepustowości kojarzonego z obecnymi produktami HBM, podczas gdy najwyższa określona pojemność wielokrotnie przewyższa typowy stos HBM.

Według jednej analizy specyfikacji stos HBF o pojemności 512 GB można porównać z około 48 GB do 64 GB w przypadku stosu HBM4. To porównanie nie czyni obu technologii wymiennymi. NAND i DRAM różnią się opóźnieniami, trwałością, zachowaniem przy zapisie oraz charakterystyką wydajności.

Pojemność nadal zmienia projekt systemu. Serwer utrzymujący więcej danych modelu w pakiecie akceleratora może ograniczyć ruch przez zewnętrzną pamięć masową i pamięć hosta. Mniejsza liczba transferów może poprawić spójność odpowiedzi i obniżyć energię zużywaną na transport danych.

To rozróżnienie wyjaśnia, dlaczego ogłoszenie przyciągnęło uwagę wykraczającą poza rutynową agregację wiadomości Google. Propozycja celuje w wąskie gardło coraz silniej kształtowane przez rozmieszczenie pamięci, a nie tylko przez wydajność obliczeniową procesora.

Sandisk prezentuje ten argument od 2025 roku. Jego opis techniczny HBF przedstawiał koncepcję pierwszej generacji z przepustowością odczytu 1,6 TB/s, pojemnością 512 GB w 16 kościach oraz profilem fizycznym porównywalnym z HBM4.

Były to cele producenta, a nie niezależne wyniki wydajności. Nowa specyfikacja podnosi pułap do 3 TB/s, lecz kupujący nadal potrzebują pomiarów krzemowych w realistycznych obciążeniach.

Najbardziej prawdopodobnym wczesnym zastosowaniem nie jest informatyka ogólnego przeznaczenia. HBF pasuje do systemów, w których modele lub powiązane dane inferencyjne przekraczają dostępną pojemność HBM, ale nadal potrzebują znacznie szybszego dostępu niż zapewnia SSD.

Rozważmy usługę uruchamiającą kilka dużych modeli na jednej platformie akceleratorowej. Konwencjonalna pamięć masowa może przechowywać wszystkie modele, podczas gdy HBM obsługuje aktywne obliczenia. HBF mógłby utrzymywać większy zestaw roboczy blisko procesora, zmniejszając częstotliwość i czas trwania wymian modeli.

Inny przykład obejmuje aplikacje o długim kontekście, obsługujące wielu jednoczesnych użytkowników. Ich pamięci KV cache mogą konkurować z wagami modeli o pojemność HBM. Umieszczenie wybranych danych w HBF mogłoby zachować ograniczoną HBM dla operacji najbardziej wrażliwych na opóźnienia.

Wyszukiwanie wektorowe oferuje trzecią możliwość. Badacze analizowali akceleratory wspomagane przez HBF dla dużych przybliżonych wyszukiwań najbliższych sąsiadów, gdzie duże indeksy wymagają znacznej przepustowości. Takie prace pozostają eksperymentalne, ale ilustrują obciążenia, które mogłaby obsłużyć pojemność HBF.

Oprogramowanie zdecyduje, czy te scenariusze się sprawdzą. Twórcy potrzebują przewidywalnych zasad określających, co pozostaje w HBM, co trafia do HBF, a co wraca do SSD. Nieodpowiednie rozmieszczenie może zniwelować korzyści przez niepotrzebne transfery.

Dlatego HBF należy rozumieć jako część hierarchii. HBM pozostaje najszybszą warstwą roboczą. HBF zapewnia większą pulę blisko zasobów obliczeniowych. SSD oferują ekonomiczną, trwałą pojemność poza pakietem.

Mechanizm brzmi prosto, lecz skoordynowane zarządzanie pamięcią jest trudne. Sprzęt musi przejrzyście udostępniać warstwy, a kompilatory i systemy wykonawcze muszą rozumieć ich opóźnienia, przepustowość, trwałość i pojemność.

Dla nabywców infrastruktury praktyczne pytanie nie brzmi, czy 512 GB robi wrażenie. Chodzi o to, czy HBF zwiększa liczbę tokenów na sekundę, obsługuje więcej równoczesnych żądań albo obniża zużycie energii na token po uwzględnieniu wszystkich kosztów systemowych.

Zainteresowanie Google News zwiększa presję na rynek pamięci AI

Udział Google daje HBF wpływowego podmiotu oceniającego, lecz szerokie poparcie dostawców pozostaje najważniejszym brakującym elementem standardu.

SK Hynix i Sandisk są naturalnymi orędownikami HBF. Obie firmy znają produkcję pamięci, pakowanie i pamięć masową dla centrów danych. Ich interes handlowy jest również jasny: wzrost inferencji stwarza okazję do sprzedaży bardziej wartościowych produktów opartych na NAND.

Google wnosi inną perspektywę. Projektuje układy tensor processing units, obsługuje ogromne usługi AI i zarządza infrastrukturą w skali, której niewiele organizacji może dorównać. Jego zaangażowanie sygnalizuje, że przynajmniej jeden hyperskaler dostrzega wystarczającą wartość, by pomagać w kształtowaniu specyfikacji.

Nie oznacza to, że Google zobowiązało się do wdrożenia HBF. Uczestnictwo może obejmować ocenę techniczną, wskazówki dotyczące obciążeń lub rozwój interfejsu, bez gwarancji zamówienia handlowego.

Tenstorrent dodaje kolejny użyteczny głos. Firma rozwija procesory AI wokół idei chipletów i otwartej architektury, co czyni otwartą warstwę pamięci blisko zasobów obliczeniowych istotną dla jej strategii projektowej. Ma też znacznie mniejszą siłę rynkową niż Nvidia.

Google i Tenstorrent zapewniają konsorcjum zarówno perspektywę potencjalnego nabywcy, jak i perspektywę projektanta procesorów. Mimo to dwaj widoczni uczestnicy nie tworzą kompletnego ekosystemu dostaw.

Brakujące nazwy są istotne. Nvidia kontroluje dużą część rynku akceleratorów. AMD sprzedaje konkurencyjne GPU i CPU. Broadcom i Marvell tworzą niestandardowe układy krzemowe dla klientów chmurowych. Samsung i Micron konkurują na rynku pamięci, natomiast Intel i Qualcomm działają w obszarze procesorów, akceleratorów i platform.

Żadna z tych firm nie poparła publicznie inicjatywy HBF w momencie pojawienia się pierwszej specyfikacji. Ich nieobecność nie dowodzi sprzeciwu. Firmy często unikają popierania wczesnego standardu, dopóki harmonogramy produktów, wymagania klientów i kompromisy techniczne nie staną się bardziej klarowne.

Milczenie tworzy jednak ryzyko dla twórców oprogramowania. Jeśli HBF obsługuje tylko niewielka liczba procesorów, inwestycje w oprogramowanie trudniej uzasadnić. Jeśli produkuje je tylko dwóch dostawców pamięci, kupujący mogą nadal obawiać się ograniczonej różnorodności źródeł dostaw.

Otwarte standardy odnoszą sukces, gdy uczestnicy wierzą, że kompatybilność tworzy większy rynek niż zastrzeżona kontrola. Mają trudności, gdy wiodący dostawcy mogą osiągnąć lepszą ekonomię dzięki własnym interfejsom lub istniejącym planom produktowym.

Nvidia może na przykład koordynować akceleratory, połączenia międzyukładowe, systemy i oprogramowanie. Może uznać, że większa pojemność HBM, lepsze współdzielenie pamięci lub ściśle zintegrowana pamięć masowa lepiej służą jej klientom bez wdrażania HBF.

Dostawcy pamięci stoją przed kolejną kalkulacją. Samsung i Micron już intensywnie inwestują w HBM. Wsparcie HBF rozszerzyłoby rynek docelowy dla wysokowydajnego NAND, ale mogłoby również wprowadzić kolejny złożony produkt i wymóg dotyczący pakowania.

SK Hynix zajmuje nietypową pozycję, ponieważ już teraz jest wiodącym dostawcą HBM. Promowanie HBF nie musi podważać tego biznesu. Hierarchiczny system może wykorzystywać oba produkty, zapewniając firmie udział w dwóch wartościowych warstwach pamięci.

Zainteresowanie Sandisk jest bardziej bezpośrednio związane z NAND. Firma chce zbliżyć pamięć flash do procesorów i zdobyć większą część wydatków na infrastrukturę AI. Jej wcześniejszy plan rozwoju HBF zakładał próbki pamięci w drugiej połowie 2026 roku oraz próbki urządzeń do inferencji opartych na HBF na początku 2027 roku.

Ten harmonogram wywiera presję na konsorcjum, by szybko przekształciło dokumentację w sprzęt. Każde opóźnienie daje konkurentom więcej czasu na zwiększenie przepustowości HBM, rozwój rozszerzania pamięci opartego na CXL, odciążania do SSD i buforowania programowego.

CXL, czyli Compute Express Link, zapewnia procesorom spójne połączenie z urządzeniami rozszerzającymi pamięć. Rozwiązuje powiązany problem pojemności, choć jego topologia i wydajność różnią się od stosu HBF umieszczonego obok procesora.

Ścieżki danych w stylu DirectStorage, pamięć obliczeniowa i zaawansowane urządzenia NVMe również konkurują o część tych samych obciążeń. Podejścia te utrzymują duże zbiory danych dalej od akceleratora, ale mogą poprawić efektywność transferu.

Główna rywalizacja nie toczy się więc między SK Hynix a jednym konkurentem. To otwarta HBF przeciwko ugruntowanym hierarchiom pamięci zbudowanym z HBM, pamięci hosta, CXL i SSD.

Widoczność w Google News pomaga przyciągnąć uwagę do tej rywalizacji. Znacznie większe znaczenie niż nagłówki będą miały zobowiązania inżynieryjne.

Cel 3 TB/s nadal musi przetrwać zderzenie z rzeczywistym sprzętem

Pojemność HBF jest wiarygodna jako przewaga NAND, lecz jej deklaracje dotyczące przepustowości, opóźnień, wytrzymałości, poboru energii i oprogramowania pozostają niepotwierdzone w skali produkcyjnej.

Specyfikacja określa, co powinny robić zgodne produkty. Nie pokazuje jednak, czy SK Hynix lub Sandisk potrafią wytwarzać je ekonomicznie, na dużą skalę i z powtarzalną wydajnością.

Stos 16 matryc zwiększa złożoność obudowy. Każda matryca wymaga znacznego dostępu równoległego, a pakiet potrzebuje matrycy bazowej zdolnej koordynować ruch z procesorem hosta. Ciepło musi być odprowadzane bez przekraczania budżetu energetycznego systemu.

Osiągnięcie 3 TB/s wymaga także czegoś więcej niż szybkiego interfejsu. Matryce NAND muszą zapewniać wystarczającą równoległość wewnętrzną, kontroler musi sprawnie planować żądania, a oprogramowanie musi utrzymywać obciążenia odpowiednie dla wysokiej przepustowości odczytu.

NAND ma istotne zalety. Zachowuje dane bez zasilania i oferuje znacznie większą gęstość niż DRAM. Charakteryzuje się jednak wolniejszym dostępem i ograniczoną wytrzymałością zapisu w porównaniu z DRAM.

Różnice te wpływają na to, jakie dane powinny trafiać do HBF. Wagi modeli intensywnie wykorzystywane w odczycie wydają się lepiej dopasowane niż często aktualizowane dane robocze. Zachowanie KV-cache wymaga bliższego zbadania, ponieważ systemy stale tworzą i modyfikują wpisy pamięci podręcznej podczas inferencji.

Wydajność może zależeć od wzorca dostępu. Dostawca może osiągnąć imponującą przepustowość sekwencyjną, a jednocześnie uzyskiwać słabsze wyniki przy małych, nieregularnych odczytach. Obciążenia AI mogą obejmować zarówno przewidywalne strumienie, jak i rozproszone wyszukiwania.

Pierwsze niezależne testy powinny zatem raportować więcej niż maksymalną przepustowość. Nabywcy potrzebują rozkładów opóźnień, zachowania przy losowym odczycie, wydajności zapisu, ograniczania wydajności termicznej, wskaźników błędów, wytrzymałości i energii na przesłany bajt.

Potrzebują także pomiarów na poziomie systemu. Liczba tokenów na sekundę, czas do pierwszego tokenu, obsługiwana liczba równoczesnych użytkowników i energia na token łączą zachowanie pamięci z wynikami biznesowymi.

Analiza specyfikacji technicznej zauważyła, że projekt obejmuje wymagania dotyczące elektryki, interfejsu, obudowy, niezawodności i wejścia/wyjścia oprogramowania. Podkreśliła również trudność uzyskania nawet 400 GB/s z jednego pakietu 512GB.

Ta niższa wartość jest istotna. Standard oferuje wiele klas wydajności, dlatego pułap 3 TB/s nie powinien stać się skrótem myślowym dla każdego przyszłego urządzenia HBF.

Konfiguracje pojemności również wymagają ostrożnego traktowania. Pakiet 512GB reprezentuje górny zakres specyfikacji, a nie obietnicę, że każda początkowa próbka dostarczy taką pojemność przy maksymalnej przepustowości.

Harmonogram komercjalizacji pozostaje kolejną niewiadomą. Sandisk wcześniej zakładał próbki pamięci HBF w 2026 roku oraz urządzenia wykorzystujące HBF na początku 2027 roku. Ogłoszenie specyfikacji nie zastąpiło publicznie tego harmonogramu.

Ostrożna ocena komercjalizacji opisała obecne rozwiązanie jako istniejące na papierze, podczas gdy dostawcy przygotowują próbki. To rozróżnienie powinno kształtować oczekiwania.

Próbkowanie jest jedynie wczesnym kamieniem milowym. Klienci muszą przetestować funkcjonalność, zintegrować kontrolery i środowiska wykonawcze, zakwalifikować obudowy, zweryfikować niezawodność oraz zdecydować, czy wydajność uzasadnia nowe projekty systemów.

Ekonomia produkcji może okazać się czynnikiem decydującym. HBF wykorzystuje NAND, ale nie jest standardowym, towarowym pakietem pamięci flash. Specjalizowane matryce, logika, połączenia o dużej gęstości i zaawansowany montaż podnoszą koszty.

Jeśli gotowe urządzenie zbliży się ceną do HBM, nie dorównując zachowaniem HBM, jego przewaga pojemnościowa może nie wystarczyć. Jeśli zapewni kilkukrotnie większą pojemność przy atrakcyjnym koszcie systemowym, projektanci akceleratorów zyskają istotną nową opcję.

Pobór energii stwarza podobny kompromis. Utrzymywanie danych blisko zasobów obliczeniowych może ograniczyć energię zużywaną na ich przenoszenie z SSD. Jednak szerokie interfejsy, równoległy dostęp do NAND i złożone kontrolery również zużywają energię.

Konsorcjum musi wykazać oszczędności netto przy rzeczywistym ruchu inferencyjnym. Same szacunki dostawców nie rozstrzygną tej kwestii.

Dojrzałość oprogramowania stanowi mniej widoczne ryzyko. Procesor może technicznie połączyć się z HBF, podczas gdy aplikacje nie będą potrafiły efektywnie go wykorzystać. Alokacja pamięci, buforowanie, usuwanie danych, przenoszenie danych i obserwowalność wymagają nowego wsparcia.

Operatorzy chmurowi mają doświadczenie w zarządzaniu złożonymi warstwami pamięci masowej, lecz heterogeniczna pamięć na poziomie pakietu zmienia problem optymalizacyjny. Programiści potrzebują narzędzi, które ujawnią korzyści bez zmuszania każdego zespołu aplikacyjnego do ręcznego zarządzania poszczególnymi regionami pamięci.

Środowiska wykonawcze open source mogłyby zmniejszyć to obciążenie. Wspólne narzędzia pomogłyby też standardowi przyciągnąć użytkowników poza hyperscalerami zdolnymi budować własne oprogramowanie.

Dopóki te elementy nie powstaną, HBF pozostaje wiarygodną architekturą z niepełną historią produktu. To rozróżnienie ma znaczenie dla inwestorów, nabywców i programistów śledzących relacje Google News na temat ogłoszenia.

Co obserwować po ogłoszeniu Open HBF

Trzy sygnały zdecydują, czy HBF stanie się warstwą pamięci AI, czy pozostanie atrakcyjną specyfikacją bez szerokiego rynku.

Pierwszym sygnałem będzie działający krzem. SK Hynix i Sandisk muszą dostarczyć próbki HBF z ujawnionymi parametrami pojemności, przepustowości, opóźnień, poboru energii, wytrzymałości i zachowania termicznego.

Próbka zbliżająca się do opublikowanych celów w realistycznych obciążeniach wzmocni argumenty za HBF. Ograniczona demonstracja wykorzystująca korzystne sekwencyjne odczyty pozostawi centralne pytanie o wydajność bez odpowiedzi.

Znaczenie ma także czas. Wcześniej przedstawiony przez Sandisk plan rozwoju umieszczał początkowe próbki w drugiej połowie 2026 roku. Dotrzmanie tego terminu pokazałoby, że standaryzacja i inżynieria produktu rozwijały się równolegle.

Drugim sygnałem będzie przyjęcie przez producentów procesorów. Google i Tenstorrent pomogły ukształtować tę inicjatywę, lecz obserwatorzy powinni wypatrywać planu rozwoju akceleratora, płyty prototypowej lub publicznie opisanego testu inferencji wykorzystującego HBF.

Wdrożenie przez Google miałoby szczególną wagę, ponieważ firma kontroluje zarówno modele AI, jak i własne procesory. Nawet ograniczony test mógłby dostarczyć wiarygodnych danych o obciążeniach, niedostępnych w laboratorium dostawcy pamięci.

Tenstorrent mógłby zaoferować inny punkt potwierdzenia. Jego architektura zorientowana na chiplet może pokazać, jak niezależna firma procesorowa integruje HBF przez UCIe bez polegania na zamkniętym stosie jednego dostawcy.

Najsilniejszym potwierdzeniem byłoby dołączenie do specyfikacji kolejnej dużej firmy procesorowej lub chmurowej. Wsparcie AMD, Broadcom, Marvell, Microsoft, Meta lub Amazon zmniejszyłoby ryzyko, że HBF zostanie powiązane z niewielką grupą.

Trzecim sygnałem będzie oprogramowanie i ekonomia. Nabywcy potrzebują wsparcia środowiska wykonawczego, które traktuje HBF jako część zarządzalnej hierarchii, a nie ręcznie sterowane urządzenie pamięci masowej.

Warto obserwować funkcje kompilatorów, zasady rozmieszczania pamięci, zmiany w systemach operacyjnych, integracje z frameworkami inferencyjnymi i narzędzia monitorujące. Te wydania pokażą, czy ekosystem przygotowuje się do wdrożeń, a nie tylko analizuje specyfikację.

Muszą pojawić się również dowody ekonomiczne. Istotne wskaźniki obejmują liczbę tokenów na sekundę na serwer, liczbę równoczesnych sesji, energię na token i koszt hostowania modelu przy określonym poziomie usług.

Surowa przepustowość nie odpowie na te pytania. Sama pojemność również nie.

Porównanie powinno uwzględniać istniejące systemy wykorzystujące większe konfiguracje HBM, pamięć hosta, rozszerzenie CXL i zoptymalizowane odciążanie do SSD. HBF zasługuje na miejsce tylko wtedy, gdy jej łączna wydajność i pojemność poprawiają całą platformę inferencyjną.

Dla programistów ogłoszenie jest powodem, by dokładniej przyjrzeć się wykorzystaniu pamięci. Optymalizacja modeli coraz bardziej zależy od tego, gdzie znajdują się wagi, pamięci podręczne, indeksy wyszukiwania i dane pośrednie.

Zespoły oceniające przyszłą infrastrukturę AI powinny już teraz rejestrować te cechy obciążeń. Przeszukiwalna techniczna baza wiedzy może pomóc inżynierom porównywać specyfikacje, notatki z benchmarków, decyzje architektoniczne i deklaracje dostawców wraz z pojawianiem się produktów HBF.

Dla nabywców korporacyjnych natychmiastowe działanie jest skromniejsze. Zapytaj dostawców, jak planują rozwiązać problem pojemności pamięci dla inferencji, które otwarte interfejsy wspierają oraz jakie dowody dotyczące obciążeń potwierdzają ich plany rozwoju.

Nie traktuj oznaczenia HBF jako dowodu wydajności. Poproś o pomiary odzwierciedlające rozmiary Twoich modeli, długości kontekstu, cele współbieżności i wymagania dotyczące poziomu usług.

Specyfikacja SK Hynix i Sandisk uczyniła tę debatę konkretną. HBF ma teraz zdefiniowane klasy pojemności, cele wydajnościowe, otwarte forum standaryzacyjne i dwóch znaczących uczestników zewnętrznych.

Wciąż brakuje jej urządzeń produkcyjnych, niezależnych benchmarków i szerokiego wsparcia producentów procesorów. Te luki odróżniają interesujący standard od trwałego rynku.

Kolejny nagłówek Google News będzie miał mniejsze znaczenie niż pierwszy kompletny benchmark HBF. Obserwuj, czy działające systemy zapewnią niższe koszty inferencji bez pogarszania czasu odpowiedzi, a następnie porównaj te dowody z szybko rozwijającymi się alternatywami HBM i rozszerzania pamięci.