Majestic Labs rzuca wyzwanie ograniczeniom pamięci GPU, a Blocks Files zwraca uwagę na Prometheus
- Aisha Washington

- 3 godziny temu
- 12 minut(y) czytania
Majestic Labs podważa obecne podejście do GPU za sprawą Prometheus — serwera zaprojektowanego wokół 128 TB współdzielonej pamięci zamiast ograniczonej pojemności HBM. Raport Blocks Files wyraźnie koncentruje się na tym konflikcie. Majestic uważa, że infrastruktura AI zawiera dziś zbyt dużo kosztownej mocy obliczeniowej i zbyt mało dostępnej pamięci.
Startup nie obiecuje jedynie nieco szybszego GPU. Chce oddzielić pojemność pamięci od mocy obliczeniowej i skalować oba zasoby niezależnie. To podejście jest skierowane do zadań inferencyjnych, w których procesory często czekają na wagi modelu, tokeny z pamięci podręcznej lub inne dane.
Nvidia i AMD odpowiadają na tę samą presję za pomocą większych systemów HBM, szybszych połączeń międzyukładowych i ściśle zintegrowanych szaf serwerowych. Majestic wybiera przeciwną drogę. W jednym serwerze wykorzystuje dużą pulę konwencjonalnej pamięci, niestandardowe chipletowe interfejsy oraz programowalne procesory AI.
To rozróżnienie sprawia, że Prometheus jest czymś więcej niż kolejną zapowiedzią akceleratora. Stanowi bezpośredni test tego, czy przyszłe systemy AI potrzebują większej mocy obliczeniowej, czy innej relacji między procesorami a pamięcią.
Majestic ujawnił ambitne deklaracje dotyczące pojemności, wydajności i zużycia energii. Jego procesory nie trafiły jednak jeszcze do klientów, a niezależne wyniki testów porównawczych pozostają niedostępne. Pomysł jest wystarczająco wiarygodny, by przyciągać uwagę, lecz obiecana przewaga nadal zależy od realizacji sprzętowej, programowej i produkcyjnej.
Raport Blocks Files ujawnia inne wyzwanie dla GPU
Majestic Labs twierdzi, że branża kupowała dodatkowe GPU częściowo po to, by pozyskać pamięć, nawet gdy zadania nie były w stanie w pełni wykorzystać dodatkowej mocy obliczeniowej.
Opublikowany 23 lipca materiał o serwerze stawiającym pamięć na pierwszym miejscu opisuje odrzucenie przez firmę standardowego połączenia GPU i pamięci o wysokiej przepustowości. HBM umieszcza szybką, pionowo układaną pamięć blisko akceleratora. Taka bliskość zapewnia wysoką przepustowość, ale ogranicza całkowitą pojemność.
Według Majestic fizyczne krawędzie otaczające duży procesor ograniczają liczbę stosów HBM, które można efektywnie podłączyć. Zwiększanie wysokości stosów tworzy również komplikacje techniczne i produkcyjne. Nowoczesne systemy łączą więc wiele akceleratorów, gdy pojedyncze urządzenie nie ma wystarczającej ilości pamięci.
Rozwiązanie to zapewnia więcej pamięci, ale wprowadza narzut komunikacyjny. Dane muszą przemieszczać się przez połączenia GPU, przełączniki lub warstwy pamięci hosta. Deweloperzy muszą decydować, gdzie powinny znajdować się wagi modelu, aktywacje i pamięci podręczne klucz-wartość.
Pamięć podręczna klucz-wartość przechowuje informacje z wcześniej przetworzonych tokenów, dzięki czemu model nie musi ponownie obliczać całej rozmowy. Podczas inferencji z długim kontekstem może zużywać znaczną ilość pamięci. Większa liczba użytkowników zwiększa tę presję, ponieważ każde aktywne żądanie utrzymuje własny stan.
Majestic twierdzi, że konwencjonalne systemy łączą również każdy nowy blok pamięci z kolejnym drogim procesorem. Niektóre zadania otrzymują więcej mocy obliczeniowej, niż mogą wykorzystać, wyłącznie dlatego, że wdrożenie potrzebuje dodatkowej pojemności.
Prometheus próbuje zerwać to powiązanie. Planowany serwer łączy nawet 12 niestandardowych procesorów AI z jedną płaską pulą pamięci. Według firmy każdy procesor powinien widzieć tę samą przestrzeń adresową o spójnych charakterystykach dostępu.
Chipletowe układy agregujące pamięć, czyli MAC, znajdują się blisko komponentów pamięci montowanych na płycie. Zbierają ruch z wielu układów pamięci i łączą je z systemem obliczeniowym za pomocą krótkich kabli miedzianych. Blocks Files podaje, że połączenia te mogą mieć długość około jednego metra.
Odległość ma znaczenie, ponieważ HBM musi pozostawać bardzo blisko pakietu procesora. Podejście Majestic daje projektantom systemów więcej fizycznej przestrzeni na pamięć, bez konieczności otaczania centralnego układu obliczeniowego przez każdy komponent.
Firma nazywa swój procesor Ignite i opisuje go jako AIU, czyli jednostkę sztucznej inteligencji. Układ łączy programowalne rdzenie z akceleracją macierzową dla obliczeń wykorzystywanych przez sieci neuronowe.
Prometheus to kompletny serwer zbudowany wokół Ignite, chipletowych interfejsów, modułów pamięci i oprogramowania pomocniczego. Publiczne specyfikacje Prometheus firmy Majestic deklarują do 128 TB współdzielonej pamięci o wysokiej przepustowości w jednym systemie.
Dla porównania, współczesne serwery akceleratorowe mierzą bezpośrednio podłączoną pamięć w terabajtach dla całej szafy, a nie w dziesiątkach terabajtów wewnątrz jednego serwera. Ta różnica pojemności stanowi centralną obietnicę Prometheus.
Materiał Blocks Files uwypukla więc spór architektoniczny. Model Nvidia zaczyna się od wysokowydajnych GPU i skaluje na zewnątrz. Majestic zaczyna od zbioru roboczego, który aplikacja AI musi utrzymać, a następnie przydziela wystarczającą moc obliczeniową do jego przetworzenia.
Inferencja AI zwiększa presję na pamięć
Problem pamięci staje się trudniejszy, ponieważ inferencja łączy duże modele, dłuższe konteksty i wielu jednoczesnych użytkowników.
Szkolenie przyciąga dużą część uwagi wokół infrastruktury AI. Jednak inferencja, czyli uruchamianie wytrenowanego modelu dla użytkowników, tworzy inną równowagę między pamięcią a obliczeniami.
Parametry modelu muszą pozostawać dostępne podczas generowania wyników. Każdy krok generowania odczytuje wagi modelu i przetwarza bieżący stan. Gdy jednostki arytmetyczne kończą pracę szybciej, niż pamięć może dostarczyć dane, dodatkowa moc obliczeniowa przynosi ograniczone korzyści.
Taki stan jest powszechnie nazywany wydajnością ograniczoną przez pamięć. Procesor dysponuje dostępną mocą obliczeniową, ale tempo przesyłania danych kontroluje rzeczywistą szybkość ukończenia zadania.
Dłuższe okna kontekstowe pogłębiają tę nierównowagę. Model obsługujący krótkie prompty utrzymuje mniej stanu konwersacji. Model obsługujący długie dokumenty, repozytoria oprogramowania, zbiory badawcze lub rozbudowane sesje agentowe musi zachowywać znacznie więcej informacji.
Systemy agentowe dodają kolejne wymaganie. Agent może wywoływać narzędzia, analizować wyniki, korygować swój plan i powtarzać ten proces. Każdy krok wydłuża sesję i może zwiększać aktywne zapotrzebowanie na pamięć.
Modele mixture-of-experts tworzą powiązane wyzwanie. Systemy te zawierają wiele wyspecjalizowanych grup parametrów i aktywują wybrane grupy dla każdego tokenu. Ograniczają pracę arytmetyczną, ale szerszy zbiór parametrów nadal wymaga dostępnego miejsca do przechowywania.
Współzałożyciel Majestic, Sha Rabii, powiedział EE Times, że moc obliczeniowa rosła szybciej niż przepustowość pamięci. Stwierdził, że większość inferencji dużych modeli była już ograniczana przez przemieszczanie danych w pamięci. Szczegółowy projekt puli pamięci zakłada ponad 100 TB standardowej energooszczędnej pamięci DRAM na środowisko akceleratorowe.
Pamięć LPDDR, czyli energooszczędna pamięć o podwójnej szybkości transmisji danych, oferuje znacznie większą pojemność niż HBM, przy odmiennych charakterystykach przepustowości i opóźnień. Techniczne wyzwanie Majestic polega na tym, by ta pojemność działała jak szybki system pamięci akceleratorowej.
Firma nie może odnieść sukcesu, podłączając zwykłą pamięć przez konwencjonalną magistralę serwerową. Zapewniłoby to pojemność, lecz nie przepustowość potrzebną do zasilenia wielu procesorów AI.
Majestic rozwija natomiast równolegle interfejs fizyczny, protokół komunikacyjny, kontrolę przepływu, mechanizmy niezawodności i oprogramowanie. Jej chiplety muszą rozdzielać żądania między wiele urządzeń pamięci, utrzymując wysoką przepustowość i przewidywalne opóźnienia.
Firma planuje również rozproszyć dane w całej puli. Striping dzieli informacje między wiele urządzeń pamięci, umożliwiając wielu komponentom równoległą obsługę żądań.
Jeśli system ten będzie działał zgodnie z opisem, operatorzy będą mogli utrzymywać większe modele i pamięci podręczne w jednej spójnej domenie. Potrzebowaliby mniej transferów między lokalną pamięcią akceleratorów, zdalnymi akceleratorami i pamięcią hosta.
Ma to znaczenie dla firm prowadzących wyszukiwanie, analizę dokumentów, agentów programistycznych lub długie rozmowy. Te zastosowania często bardziej cenią liczbę ukończonych tokenów na jednostkę energii niż teoretyczną szczytową wydajność arytmetyczną procesora.
Majestic twierdzi, że jego projekt może obsługiwać znacznie więcej równoczesnych użytkowników na serwer. Twierdzenie to nie zostało niezależnie zweryfikowane. Mimo to wskazuje ono ekonomiczny wskaźnik, na który kupujący coraz częściej zwracają uwagę.
Centrum danych dysponuje ograniczoną ilością energii elektrycznej, chłodzenia, powierzchni i przepustowości sieciowej. Dodanie kolejnego GPU pomaga tylko wtedy, gdy zadanie może utrzymać aktywność tego GPU. Bezczynne jednostki arytmetyczne nadal zużywają zasoby, nie generując proporcjonalnych wyników.
Ujęcie Blocks Files jest użyteczne, ponieważ odwraca uwagę od szczytowej liczby operacji na sekundę. Rzeczywista rywalizacja dotyczy tego, ile użytecznej pracy cały system wykona w granicach swoich limitów energii i pamięci.
Prometheus zastępuje szafę GPU współdzieloną pulą pamięci
Prometheus traktuje pamięć jako centrum maszyny, a jego procesory stają się odbiorcami wspólnego zasobu danych.
Majestic został założony w 2023 roku przez Ofera Shachama, Sha Rabii i Masumi Reynders. Cała trójka wcześniej pracowała w organizacjach zajmujących się niestandardowym krzemem w Google i Meta.
Ich doświadczenie obejmuje procesory, systemy i dostarczony sprzęt konsumencki. Majestic twierdzi, że jego szerszy zespół posiada ponad 120 patentów i przyczynił się do stworzenia setek milionów niestandardowych układów.
Firma publicznie zaistniała, dysponując finansowaniem przekraczającym 100 mln dolarów. Bow Wave Capital poprowadził rundę Series A, a Lux Capital kierował wcześniejszą rundą seed. Wśród innych uczestników znalazły się SBI, Upfront, Grove Ventures, Hetz Ventures, QP Ventures, Aidenlair Global i TAL Ventures.
To ogłoszenie finansowania zaprezentowało system, który miał oferować 1000 razy więcej pamięci na procesor niż wiodący GPU. Twierdzono również, że jeden serwer mógłby skonsolidować pojemność pamięci i przepustowość kojarzone z wieloma zaawansowanymi szafami.
Są to prognozy firmy, a nie opublikowane niezależne wyniki. Zależą od tego, jaki sprzęt stanowi punkt odniesienia, jakie zadanie jest uruchamiane i jak test mierzy użyteczne wyniki.
Ujawniony mechanizm jest jednak konkretny. Prometheus zawiera dwa główne elementy niestandardowego krzemu. Jednym jest procesor Ignite, a drugim chipletowy interfejs pamięci łączący obliczenia ze współdzieloną pulą LPDDR.
Do 12 urządzeń Ignite może uzyskiwać dostęp do ciągłej przestrzeni pamięci. Majestic opisuje tę przestrzeń jako płaską, co oznacza, że oprogramowanie nie powinno musieć zarządzać kilkoma wyraźnie różnymi warstwami pamięci.
Ten model programowania atakuje istotną słabość wdrożeń wielo-GPU. Deweloper musi obecnie radzić sobie z lokalną pamięcią HBM, pamięcią podłączoną do innych GPU, pamięcią CPU i pamięcią masową. Każda warstwa ma inną pojemność, przepustowość i opóźnienia.
Frameworki dzielą modele między urządzenia, aby zmieścić się w tych ograniczeniach. Koordynują też komunikację między akceleratorami. Wydajność może spaść, gdy wybrany podział prowadzi do nadmiernych transferów lub nierównomiernego obciążenia.
Prometheus ma na celu usunięcie części tych decyzji. Według firmy każdy procesor Ignite miałby docierać do każdego miejsca we współdzielonej puli z porównywalnym opóźnieniem i przepustowością.
Projekt wykorzystuje luźną spójność zamiast odtwarzania każdego zachowania konwencjonalnej pamięci współdzielonej CPU. Spójność definiuje, w jaki sposób procesory utrzymują jednolity widok, gdy odczytują lub zmieniają wspólne dane.
Majestic nie opublikował wystarczająco szczegółów implementacyjnych, by osoby z zewnątrz mogły ocenić każdy kompromis. O tym, jak dobrze system poradzi sobie z rywalizacją o zasoby i synchronizacją, zadecydują jego zastrzeżone mechanizmy kontroli przepływu i operacji atomowych.
Znaczenie ma także architektura procesora. Według doniesień Majestic łączy własność intelektualną Arm, elementy RISC-V oraz własny projekt. Silniki macierzowe przyspieszają gęste obliczenia typowe dla modeli AI.
Firma planuje wspierać PyTorch, szeroko używany framework uczenia maszynowego, oraz Triton, język programowania do zoptymalizowanych jąder akceleratorów. Zgodność programowa jest kluczowa, ponieważ przewaga Nvidia wykracza daleko poza sam krzem.
CUDA zapewnia klientom Nvidia dojrzałe biblioteki, kompilatory, narzędzia debugowania, poradniki dotyczące wydajności i doświadczonych programistów. Nowy sprzęt może oferować atrakcyjne specyfikacje, a mimo to mieć trudności z adopcją, jeśli aplikacje wymagają rozległego przepisywania.
Rabii przyznał, że sukces serwera w dużej mierze zależy od tego, jak szybko programiści będą mogli z niego korzystać i jak niezawodne staną się jego narzędzia. To przyznanie ujawnia drugą połowę zadania stojącego przed Majestic.
Sprzęt musi efektywnie przenosić dane. Oprogramowanie musi też sprawić, by ten przepływ był na tyle niewidoczny, aby korzystały z niego istniejące aplikacje.
Nvidia i AMD rozbudowują HBM, a nie rezygnują z niego
Majestic stawia na model skalowania inny niż oparty na HBM, podczas gdy najwięksi dostawcy akceleratorów nadal intensywnie inwestują w ten model.
Systemy Nvidia w skali szafy łączą wiele GPU za pośrednictwem NVLink i powiązanych technologii sieciowych. Takie podejście tworzy większą domenę obliczeniową, zachowując jednocześnie niezwykle szybką pamięć blisko każdego akceleratora.
AMD podąża podobnym kierunkiem dzięki akceleratorom Instinct i konstrukcji szafowej Helios. Niedawno opisany MI455X wykorzystuje HBM4 i oferuje 432GB pamięci oraz przepustowość 23.3TB na sekundę na GPU.
W 72 akceleratorach architektura MI455X zapewnia 31.1TB HBM w jednej szafie. AMD twierdzi, że Helios łączy tę pamięć w spójną domenę.
Systemy te uznają ten sam problem, który wskazuje Majestic. Nvidia i AMD zwiększają pojemność pamięci, jej szybkość, przepustowość cache, wydajność połączeń międzyukładowych oraz koordynację na poziomie szafy.
Spór dotyczy tego, jak daleko strategię tę da się skalować w sposób ekonomiczny. Majestic twierdzi, że dołączanie kosztownej HBM do każdego wysokowydajnego urządzenia obliczeniowego utrwala niekorzystny stosunek pojemności do zasobów arytmetycznych.
Obecni dostawcy mogą odpowiedzieć na ten problem na kilka sposobów. Mogą zwiększać gęstość HBM, ulepszać pakowanie, kompresować dane modeli, udoskonalać cache lub efektywniej dzielić obciążenia.
Mogą także wykorzystywać szybsze sieci, aby obniżyć koszt dostępu do zdalnej pamięci. Ulepszenia programowe, takie jak kwantyzacja, zmniejszają liczbę bitów wymaganych dla każdego parametru. Dekodowanie spekulacyjne może zwiększać wydajność, pozwalając modelom jednocześnie weryfikować kilka proponowanych tokenów.
Metody te zmniejszają presję bez zastępowania architektury GPU. Działają też w dojrzałych środowiskach, które klienci już wykorzystują.
Największa szansa Majestic leży w obciążeniach, w których dominuje pojemność. Bardzo duże modele rzadkie, grafowe sieci neuronowe, długo działający agenci i ekstremalnie duże okna kontekstu mogą wymagać więcej pamięci niż mocy arytmetycznej.
Słabsza pozycja firmy dotyczy zadań, które w pełni wykorzystują gęste obliczenia macierzowe i mieszczą się wygodnie w lokalnej HBM. Konwencjonalne GPU nadal dobrze sprawdzają się w takich obciążeniach.
Trening stwarza również trudniejszą konkurencję. Wielokrotnie wykonuje duże operacje macierzowe i synchronizuje aktualizacje między wieloma urządzeniami. Może wykorzystywać ogromne ilości pamięci, lecz korzysta także z najwyższej dostępnej wydajności obliczeniowej i interconnectu.
Majestic twierdzi, że Prometheus może wspierać trening. Jednak jego początkowy nacisk pozostaje na inferencję i obciążenia agentowe. Taki fokus daje firmie węższy i łatwiejszy do sprawdzenia cel.
Qualcomm realizuje inną strategię skoncentrowaną na pamięci. Jego podejście near-memory umieszcza logikę akceleratora pod stosami DRAM, zamiast polegać na konwencjonalnym pakowaniu HBM.
Qualcomm deklaruje sześciokrotnie większą przepustowość na wat niż HBM oraz ponad 200 razy większą pojemność niż SRAM na chipie. Firma nie ujawniła bezwzględnej przepustowości architektury, pozostawiając ważne porównania nierozstrzygnięte.
Istnienie wielu podejść wzmacnia diagnozę Majestic, lecz niekoniecznie jego twierdzenia dotyczące produktu. Najwięksi projektanci chipów wyraźnie postrzegają przepływ danych jako kluczowe ograniczenie.
Rynek nie wybiera więc między firmami, które dostrzegają ścianę pamięci, a tymi, które ją ignorują. Wybiera między różnymi sposobami jej pokonania.
Artykuł blocks files przedstawia najbardziej agresywne stanowisko Majestic: połączenie GPU-HBM znalazło się w ślepym zaułku. Nvidia, AMD i ich dostawcy pamięci wydają ogromne środki, by udowodnić, że jest inaczej.
Niezweryfikowane twierdzenia są równie ważne jak architektura
Prometheus pozostaje systemem na etapie rozwoju, więc jego deklarowana pojemność nie może jeszcze potwierdzać wydajności aplikacyjnej, efektywności ani niezawodności komercyjnej.
Oczekuje się, że procesory Majestic i chiplet interfejsu pamięci osiągną tape-out w 2026 roku. Tape-out oznacza zakończenie projektu chipu przed rozpoczęciem produkcji. Nie oznacza, że działający krzem produkcyjny jest natychmiast dostępny.
Firma oczekuje, że serwery zaczną trafiać do pierwszych klientów w 2027 roku. Inny raport umieszcza szersze wprowadzenie produktu w połowie tego roku.
Ten harmonogram pozostawia kilka etapów między obecną architekturą a produktem gotowym do wdrożenia. Produkcja, pakowanie, walidacja płyt, firmware, rozwój kompilatora, testy termiczne i integracja systemu mogą ujawnić problemy.
Interfejs pamięci stanowi największe pytanie techniczne. LPDDR oferuje dużą pojemność i korzystne charakterystyki energetyczne, lecz pojedyncze urządzenia nie dorównują HBM pod względem przepustowości.
Majestic musi połączyć wiele kanałów pamięci, nie tworząc zatorów. Chiplety MAC, połączenia miedziane, protokoły i system stripingu muszą zapewniać zarówno przepustowość, jak i przewidywalne czasy dostępu.
Duże pule pamięci tworzą również wyzwania związane z zarządzaniem awariami. Więcej komponentów oznacza więcej możliwych usterek. System produkcyjny musi wykrywać błędy, izolować awarie i nadal działać bez uszkadzania stanu modelu.
Prometheus musi to osiągnąć, jednocześnie prezentując oprogramowaniu prosty model pamięci. Wygoda nie może ukrywać zachowania powodującego nieprzewidywalne przerwy lub załamanie wydajności przy rywalizacji o zasoby.
Definicje benchmarków budzą kolejne obawy. Majestic twierdził, że w niektórych scenariuszach osiąga ponad 50 razy wyższą wydajność oraz od 10 do 50 razy więcej tokenów na megawat.
Liczby te wymagają ostrożnej interpretacji. Architektura modelu, precyzja, rozmiar batcha, długość kontekstu, długość odpowiedzi, docelowe opóźnienie i liczba równoczesnych użytkowników mogą znacząco zmienić wyniki inferencji.
System zoptymalizowany pod duże batche może generować wiele tokenów, odpowiadając jednak zbyt wolno dla usługi interaktywnej. System o wyjątkowej pojemności nadal może osiągać słabe wyniki w mniejszych modelach intensywnie wykorzystujących obliczenia.
Porównania zależą także od wybranej bazy Nvidia lub AMD. Pojedynczy GPU, starsza szafa i aktualny system szafowy dają bardzo różne proporcje.
Żadne niezależne laboratorium nie opublikowało benchmarków aplikacyjnych z produkcyjnego sprzętu Prometheus. Majestic nie ujawnił kompletnych wyników dotyczących opóźnień, przepustowości, poboru mocy ani zgodności programowej.
Zgłaszane zamówienia klientów nie wypełniają tej luki weryfikacyjnej. Wczesne zobowiązania mogą wskazywać na silny popyt, ale klienci często uzależniają zakupy powstającego sprzętu od kamieni milowych i warunków dostawy.
Adopcja oprogramowania stanowi kolejne ryzyko. Wsparcie dla PyTorch i Triton jest koniecznym początkiem. Nie odtwarza automatycznie zakresu ani dojrzałości bibliotek CUDA.
Operatorzy potrzebują zoptymalizowanych jąder, narzędzi do rozproszonego wykonywania, obserwowalności, mechanizmów bezpieczeństwa, automatyzacji wdrożeń i stabilnych aktualizacji. Potrzebują także przewidywalnego zachowania w rzeczywistych modelach, a nie tylko w wybranych demonstracjach.
Według majowego profilu EE Times Majestic ma około 40 pracowników podzielonych między Kalifornię i Izrael. To niewielki zespół jak na jednoczesną pracę nad chipem, serwerem, pamięcią, kompilatorem i produkcją.
Założyciele mają odpowiednie doświadczenie, a finansowanie daje projektowi przestrzeń do rozwoju. Nvidia i AMD nadal dysponują znacznie większymi organizacjami inżynieryjnymi, relacjami z dostawcami i zainstalowanymi bazami klientów.
Sceptyczny wniosek jest prosty. Majestic wskazał rzeczywiste ograniczenie i zaproponował spójny mechanizm. Nie wykazał jeszcze, że Prometheus może osiągnąć deklarowane proporcje poza wewnętrznymi prognozami.
To rozróżnienie powinno kształtować sposób, w jaki nabywcy czytają materiały blocks files. Architektura zasługuje na uwagę, ale uwaga nie jest walidacją.
Trzy sygnały pokażą, czy Majestic potrafi dostarczyć rozwiązanie
Kolejny etap zależy od działającego krzemu, powtarzalnych benchmarków aplikacyjnych i dowodów, że istniejące oprogramowanie AI może zostać przeniesione bez rozległej przebudowy.
Pierwszym sygnałem będzie pomyślna walidacja krzemu. Majestic poinformował, że zarówno Ignite, jak i jego chiplet interfejsu pamięci osiągną tape-out w 2026 roku.
Zakończony tape-out podtrzymałby realność harmonogramu. Działające próbki osiągające oczekiwane cele zegarowe, energetyczne i dotyczące połączeń stanowiłyby znacznie mocniejszy dowód.
Każde opóźnienie osłabiłoby perspektywę dostaw dla klientów w 2027 roku. Problemy z interfejsem byłyby szczególnie istotne, ponieważ tkanina pamięci stanowi centralne wyróżnienie firmy.
Drugim sygnałem będzie benchmark ujawniający pełną konfigurację obciążenia. Przydatne wyniki powinny podawać model, precyzję numeryczną, rozmiar batcha, długość wejścia, długość wyjścia, docelowe opóźnienie i pobór mocy systemu.
Testy powinny porównywać Prometheus z aktualnymi szafami Nvidia i AMD, a nie z pojedynczym akceleratorem lub przestarzałą platformą. Powinny również oddzielać czas do pierwszego tokenu od późniejszego generowania tokenów.
Inferencja z długim kontekstem byłaby szczególnie wymownym testem. Prometheus powinien zyskać przewagę, gdy model i jego cache przekroczą praktyczną pojemność konwencjonalnej pamięci GPU.
Mniejsze modele intensywnie wykorzystujące obliczenia stanowią test przeciwny. Jeśli Prometheus utrzyma w nich konkurencyjne wyniki, jego rynek może wyjść poza wyspecjalizowane wdrożenia intensywnie wykorzystujące pamięć.
Trzecim sygnałem będzie migracja oprogramowania. Majestic musi pokazać, że rzeczywisty model PyTorch może zostać przeniesiony na Prometheus przy ograniczonych zmianach w kodzie.
Demonstracja powinna obejmować kompilację, zoptymalizowane jądra, monitorowanie i odzyskiwanie po awarii. Powinna też ujawnić, które komponenty zależne od CUDA wymagają zastąpienia.
Wdrożenia u pierwszych klientów będą ważniejsze niż ogólne deklaracje zgodności. Wiarygodny klient powinien opisać obciążenie, cel operacyjny i powód wyboru systemu stawiającego pamięć na pierwszym miejscu.
Sygnały te albo wzmocnią, albo osłabią centralną ocenę Majestic. Udany krzem, przejrzyste benchmarki i możliwa do opanowania migracja pokazałyby, że łączenie pamięci może rzucić wyzwanie szafom GPU.
Słaba przepustowość, wąskie warunki benchmarków lub ciężkie przepisywanie oprogramowania wsparłyby strategię obecnych dostawców. Nabywcy nadal akceptowaliby ograniczoną pojemność HBM w zamian za dojrzałe narzędzia i sprawdzoną wydajność.
Najważniejsze pytanie nie brzmi, czy AI potrzebuje więcej pamięci. Każda główna mapa rozwoju akceleratorów już odpowiada na nie większymi systemami pamięci.
Pytanie brzmi, czy pamięć powinna pozostać przypisana do każdego zaawansowanego procesora, czy stać się niezależnie skalowalnym zasobem systemowym. Majestic oparł całą swoją architekturę na tej drugiej odpowiedzi.
Dla programistów i nabywców infrastruktury kolejnym praktycznym krokiem jest przeanalizowanie śladów obciążeń przed przyjęciem argumentów którejkolwiek ze stron. Należy zmierzyć wykorzystanie akceleratorów, wzrost pamięci podręcznej, transfery danych, opóźnienia i zużycie energii przy rzeczywistym zapotrzebowaniu. Następnie warto obserwować, czy kolejna aktualizacja blocks files przyniesie pomiary z produkcji, a nie kolejną deklarację dotyczącą pojemności.


