Analiza infrastruktury AI firmy SK hynix wskazuje, że architektura wyznacza obecnie granicę wydajności
SK hynix przeformułował swoją strategię infrastruktury AI wokół bezpośredniego konfliktu: szybsze procesory nie gwarantują już szybszych ani wydajniejszych usług AI. W analizie z 2 października firma przekonuje, że lokalizacja pamięci, projekt interkonektów i przepływ danych decydują dziś o tym, jaką część wydajności akceleratorów aplikacje mogą faktycznie wykorzystać.
Wniosek ten odzwierciedla zmianę w obciążeniach AI. Trenowanie nadal wymaga ogromnej mocy obliczeniowej, lecz wydatki produkcyjne w coraz większym stopniu wspierają inferencję, długie konteksty, pętle rozumowania i trwałych agentów AI. Te obciążenia wielokrotnie pobierają wagi modeli, wyniki pośrednie i zapisany kontekst.
Głównym polem rywalizacji nie jest już zatem jeden producent chipów przeciwko drugiemu. To projektowanie zorientowane na procesor kontra architektura zorientowana na pamięć. NVIDIA, dostawcy chmury, producenci pamięci i budowniczowie systemów reagują na tę zmianę, choć kontrolują różne części stosu.
Analiza infrastruktury AI firmy SK hynix redefiniuje wąskie gardło
Istotną zmianą nie jest nowy chip SK hynix, lecz szersza definicja tego, co składa się na wydajność AI.
Najnowsza analiza infrastruktury firmy przedstawia obliczenia jako tylko jeden etap znacznie szerszej ścieżki danych. Informacje przemieszczają się z pamięci masowej do pamięci operacyjnej, przez cache i interkonekty, a ostatecznie do akceleratora. Wyniki wracają następnie przez kolejne elementy tej hierarchii.
Każdy transfer zwiększa opóźnienia i zużywa energię. Szybszy GPU nie może usunąć tych kosztów, jeśli poświęca czas na oczekiwanie na dane lub wymianę informacji z innymi akceleratorami.
Argument ten podważa model zorientowany na procesor, który ukształtował informatykę ogólnego przeznaczenia. W tym modelu dane są przesyłane do centralnego procesora, wykonywana jest żądana operacja, a wynik przenoszony gdzie indziej. Cache, prefetching, wielowątkowość i wykonywanie poza kolejnością pomagają ukrywać opóźnienia, ale zwiększają też złożoność sprzętu i oprogramowania.
SK hynix twierdzi, że nierównowaga stała się poważna. Firma przytacza badania szacujące, że pojedynczy dostęp do DRAM może wymagać od 150 do 2 000 razy więcej energii niż prosta operacja arytmetyczna. Przywołuje też badania, w których dostęp do pamięci i przepływ danych zużywały ponad 90 procent energii systemu w przypadku dużych modeli uczenia maszynowego.
Liczby te nie opisują każdego modelu ani wdrożenia. Różne chipy, technologie pamięci, formaty precyzji i wzorce obciążeń prowadzą do różnych rezultatów. Ilustrują jednak, dlaczego dodatkowa przepustowość obliczeń arytmetycznych może przynosić rozczarowujące korzyści na poziomie całego systemu.
Inferencja dużych modeli językowych ułatwia dostrzeżenie tej nierównowagi. Wygenerowanie każdego tokena wymaga od modelu odczytania wag i sięgnięcia po informacje utworzone podczas przetwarzania wcześniejszych tokenów. Bardziej zaawansowane rozumowanie nie eliminuje tego zachowania. Często wydłuża sekwencję i zwiększa ilość stanu, który musi pozostawać dostępny.
Cache klucz-wartość, czyli KV cache, przechowuje dane uwagi z poprzednich tokenów, aby model nie przeliczał ponownie całego kontekstu. Oszczędza to obliczenia, lecz zajmuje pamięć, a jego rozmiar rośnie wraz z długością kontekstów i liczbą równoczesnych sesji.
Tworzy to inny problem pojemnościowy niż trenowanie modeli. Klaster treningowy często może przetwarzać duże, zaplanowane batch'e. Usługa inferencyjna musi obsługiwać nieprzewidywalne żądania, różne długości kontekstu i cele opóźnień widoczne dla użytkowników.
Aplikacje agentowe wprowadzają kolejną komplikację. Agent może wygenerować tekst, wywołać narzędzie, czekać na wynik, dodać go do kontekstu i rozpocząć kolejny cykl rozumowania. Akcelerator może naprzemiennie intensywnie przetwarzać dane i pozostawać bezczynny, podczas gdy dane sesji nadal zachowują wartość.
NVIDIA opisuje tę samą presję we własnych materiałach dotyczących inferencji agentowej. Wskazuje wzrost KV cache, nieregularne oczekiwanie na narzędzia i słabe wykorzystanie GPU jako problemy infrastrukturalne długotrwale działających agentów.
Obie firmy podchodzą do tej kwestii z różnych pozycji komercyjnych. NVIDIA sprzedaje platformy przyspieszonego przetwarzania, natomiast SK hynix dostarcza produkty pamięciowe zasilające te platformy. Ich diagnozy się jednak pokrywają: użyteczna wydajność zależy od skoordynowania procesorów, pamięci, pamięci masowej, sieci i oprogramowania.
SK hynix wysuwa również strategiczne twierdzenie. Jeśli pamięć staje się elementem projektu pierwszej klasy, dostawcy pamięci zyskują wpływ na architekturę systemów. Ich rola wykracza poza dostarczanie komponentów o większej pojemności lub przepustowości.
Ogłoszenie przypomina więc mniej premierę produktu, a bardziej deklarację dotyczącą kierunku rywalizacji. SK hynix chce, aby nabywcy oceniali kompletne ścieżki danych, a nie odizolowane specyfikacje procesorów.
Zmiana ta tworzy centralne napięcie artykułu. Infrastruktura AI była kupowana i promowana wokół mocy obliczeniowej, jednak ekonomika inferencji coraz bardziej zależy od zapewnienia ciągłego dopływu danych do tej mocy.
Inferencja czyni pamięć zasobem ograniczającym
Inferencja zmienia cel optymalizacji z ukończenia największego obliczenia na dostarczanie responsywnych tokenów przy akceptowalnym koszcie systemowym.
Procesy treningowe zużywają znaczną ilość energii i mocy obliczeniowej, ale mają określony początek i koniec. Inferencja jest usługą ciągłą. Każdy prompt użytkownika tworzy terminy, stan i przepływ danych, którymi operatorzy muszą stale zarządzać.
Chatbot już wymaga powtarzalnego dostępu do pamięci, ponieważ modele językowe generują wyjście po jednym tokenie. System rozumujący może wytworzyć wiele tokenów wewnętrznych, zanim udzieli końcowej odpowiedzi. Agent może powtarzać ten proces w wielu narzędziach i zewnętrznych źródłach danych.
Długość kontekstu potęguje obciążenie. Model musi zachować informacje, z których jego warstwy uwagi mogą później skorzystać. Warstwa uwagi określa, które fragmenty dostępnego kontekstu mają znaczenie dla kolejnego obliczenia.
KV cache pozwala uniknąć powtarzania wcześniejszych obliczeń uwagi, ale kompromis przenosi presję do pamięci. Pojemność określa, ile sesji może pozostawać aktywnych. Przepustowość określa, jak szybko system może pobrać ich stan.
High Bandwidth Memory, czyli HBM, rozwiązuje część tego problemu. HBM układa pionowo matryce pamięci i umieszcza pamięć o wysokiej przepustowości blisko akceleratora. Taki układ dostarcza dane znacznie szybciej niż konwencjonalna pamięć znajdująca się dalej od procesora.
SK hynix ma wyraźny interes w podkreślaniu znaczenia HBM, ponieważ jest jego głównym dostawcą. Firma nie twierdzi jednak, że samo HBM rozwiązuje problem wąskiego gardła. Jej analiza wskazuje, że pełna ścieżka musi obejmować pamięć masową, sieci, kontrolery pamięci i interkonekty.
To zastrzeżenie ma znaczenie. Kosztowny akcelerator może nadal czekać, gdy dane znajdują się w wolniejszej warstwie lub muszą przejść przez przeciążone połączenie. Dodanie szybszej pamięci obok akceleratora poprawia jedynie transfery, które faktycznie z tej pamięci korzystają.
Pojemność może również kolidować z szybkością. Najszybsze warstwy pamięci są ograniczone i kosztowne do zapewnienia dla każdej aktywnej sesji. Wolniejsze DRAM i pamięć masowa oferują większą pojemność, lecz przenoszenie zapisanego kontekstu między warstwami może wprowadzać opóźnienia.
Systemy produkcyjne potrzebują zatem polityk rozmieszczania danych. Informacje często wykorzystywane ponownie powinny pozostawać blisko akceleratora. Nieaktywny kontekst może zostać przeniesiony do innej warstwy, pod warunkiem że system pobierze go, zanim model znów go potrzebuje.
Dokumentacja NVIDIA dotycząca zarządzania cache opisuje ponowne wykorzystanie cache i routing jako kluczowe cele optymalizacji. Żądania powinny trafiać do workerów, które już przechowują przydatny kontekst, ograniczając zbędne transfery i ponowne obliczenia.
To sprawia, że oprogramowanie obsługujące staje się częścią argumentu architektonicznego. Sprzęt zapewnia pojemność i ścieżki transferu, ale oprogramowanie decyduje, gdzie znajduje się stan modelu. Decyduje też, kiedy ten stan się przemieszcza i który procesor obsługuje kolejne żądanie.
W rezultacie zmienia się jednostka operacyjna. Liczba żądań na sekundę nadal jest przydatna, ale nie opisuje w pełni agenta wykonującego wiele sekwencyjnych wywołań modelu. Operatorzy muszą również rozumieć tokeny, aktywny kontekst, ponowne wykorzystanie cache, opóźnienia i wykorzystanie sprzętu.
Presja spada na dostawców chmury i zespoły infrastruktury przedsiębiorstw. Muszą oni zapewniać zasoby pod kątem zachowania obciążeń, a nie liczby akceleratorów z nagłówka specyfikacji. Źle zrównoważony klaster może posiadać znaczną moc obliczeniową, a jednocześnie dostarczać niską przepustowość tokenów.
Deweloperzy również odczuwają skutki. Aplikacje, które przechowują każdą rozmowę bezterminowo, mogą zwiększać zapotrzebowanie na pamięć. Projekty agentów, które powtarzają duże prompty lub losowo przenoszą żądania między workerami, mogą niweczyć ponowne wykorzystanie cache.
Nie oznacza to, że deweloperzy muszą stać się architektami chipów. Oznacza natomiast, że zachowanie aplikacji wpływa teraz bardziej bezpośrednio na wydajność infrastruktury. Zarządzanie kontekstem, routing żądań i dobór modeli mogą zmieniać ilość danych przemieszczających się pod aplikacją.
Zespoły inżynieryjne potrzebują również zapisów łączących decyzje aplikacyjne z obserwowanym zachowaniem infrastruktury. Przeszukiwalna baza wiedzy inżynieryjnej może zachowywać założenia benchmarków, zmiany we wdrożeniach i ustalenia z incydentów między zespołami.
Szersza konsekwencja ma charakter ekonomiczny. Nabywcy nie mogą szacować wydajności inferencji wyłącznie na podstawie szczytowej liczby operacji na sekundę. Muszą pytać, jak system zachowuje się, gdy kontekst rośnie, sesje są wstrzymywane, a żądania konkurują o pamięć.
Dlatego argument SK hynix dotyczący infrastruktury AI ma teraz znaczenie. Inferencja przekształca architekturę ze szczegółu implementacyjnego w część kosztu i responsywności produktu.
Prawdziwa rywalizacja to architektura kontra szybkość komponentów
Głównym przeciwnikiem nie jest inny dostawca pamięci, lecz przekonanie, że szybsze pojedyncze komponenty automatycznie tworzą szybsze systemy AI.
Ulepszenia komponentów nadal mają znaczenie. Szybsze akceleratory wcześniej kończą obliczenia arytmetyczne, pamięć o większej przepustowości szybciej je zasila, a lepsze sieci przenoszą informacje między węzłami. Problem pojawia się, gdy nabywcy traktują te specyfikacje jako niezależne i sumujące się.
Wydajność systemu zależy od najwolniejszej istotnej ścieżki. Procesor z niewykorzystanymi jednostkami arytmetycznymi nie tworzy wartości, gdy czeka na wagi modelu. Dodatkowa pojemność pamięci nie pomaga, jeśli jej połączenie nie może dostarczać danych z wymaganą szybkością.
Systemy zorientowane na procesor próbują kompensować to coraz bardziej złożonymi mechanizmami. Wiele poziomów cache przechowuje często używane informacje blisko obliczeń. Prefetchery przewidują, jakie dane będą potrzebne w następnej kolejności. Równoległe wątki pozwalają procesorom wykonywać inną pracę podczas przestojów.
Metody te nadal są przydatne, ale obciążenia AI ujawniają ich ograniczenia. Parametry modeli i kontekst mogą przekraczać pojemność lokalnych cache. Wzorce dostępu zmieniają się między prefill, generowaniem tokenów, pobieraniem danych, wykonywaniem narzędzi i koordynacją wielu agentów.
Przetwarzanie zorientowane na pamięć rozpoczyna się od innego pytania. Zamiast pytać, jak szybko dane mogą dotrzeć do centralnego procesora, architekci pytają, gdzie dane już się znajdują. Następnie rozmieszczają obliczenia i ścieżki transferu wokół tej lokalizacji.
Podejście to nie wymaga, aby każda operacja odbywała się wewnątrz pamięci. Część danych należy przechowywać w HBM obok GPU. Inne informacje mogą znajdować się w puli pamięci współdzielonej przez urządzenia. Wybrane operacje mogą działać na akceleratorach umieszczonych blisko pamięci.
Właściwa konfiguracja zależy od obciążenia. Architektura modelu, wielkość batcha, długość kontekstu, wymagania dotyczące opóźnień i liczba równoczesnych żądań zmieniają tę równowagę. Topologia sieci i harmonogramowanie programowe mogą ją dodatkowo zmienić.
Ta zmienność wyjaśnia, dlaczego rekonfigurowalna infrastruktura przyciąga uwagę. Stałe konfiguracje serwerów łączą procesory i pamięć w z góry określonych proporcjach. Proporcje te mogą prowadzić do wyczerpania jednego zasobu, podczas gdy inny pozostaje niewykorzystany.
Systemy zdezagregowane rozdzielają zasoby na pule. Procesory CPU, akceleratory, pamięć, pamięć masowa i sieć można następnie łączyć zgodnie z potrzebami obciążenia. Usługa wymagająca dużej pojemności pamięci może korzystać z większej puli bez powielania wszystkich pozostałych komponentów.
Pule zasobów nie są darmowe. Zdalny dostęp zwykle zwiększa opóźnienia i zużywa przepustowość połączeń. Współdzielony zasób może również stać się nowym punktem rywalizacji. Architektura działa tylko wtedy, gdy elastyczność przynosi większe oszczędności niż koszty komunikacji.
To centralne odwrócenie w argumentacji SK hynix. Szybsze przesyłanie większej ilości danych nie zawsze jest najlepszą odpowiedzią. Lepszym rozwiązaniem może być takie, które w ogóle pozwala uniknąć przenoszenia danych.
Zasada ta zyskała na znaczeniu, ponieważ AI przesuwa się w stronę inferencji. Trening premiuje duże, zsynchronizowane klastry o znacznej gęstości obliczeniowej. Inferencja wiąże się z różnorodnymi rodzajami żądań i bardziej rygorystycznymi oczekiwaniami dotyczącymi czasu odpowiedzi.
Ta sama infrastruktura może obsługiwać krótkie prompty, analizę dokumentów, generowanie kodu i długotrwale działających agentów. Każde z tych obciążeń stawia inne wymagania wobec pojemności pamięci, przepustowości, pamięci masowej i komunikacji.
Statyczny klaster może być zoptymalizowany pod jeden profil, a słabo działać w przypadku innego. Rekonfigurowalne rozmieszczanie zasobów obiecuje lepsze wykorzystanie, ale wymaga także sprawnego oprogramowania do orkiestracji. Elastyczność sprzętowa bez inteligentnego harmonogramowania może jedynie przenieść wąskie gardło w inne miejsce.
Własne rozwiązania NVIDIA pokazują, że dostawcy akceleratorów dostrzegają ten problem. Jej NVLink fabric łączy GPU za pomocą dedykowanych ścieżek o wysokiej przepustowości, umożliwiając im koordynację wykraczającą poza zwykłe interfejsy peryferyjne.
Nie podważa to stanowiska SK hynix. Potwierdza, że wydajność procesorów coraz bardziej zależy od architektury pamięci i komunikacji. Konkurencyjne pytanie dotyczy tego, kto kontroluje tę architekturę i jak otwarcie jej części mogą współdziałać.
Własnościowe sieci scale-up oferują ściśle zintegrowaną wydajność. Otwarte standardy połączeń mogą zapewniać szerszy wybór urządzeń i rozbudowę pamięci. Żadne z tych podejść nie wygrywa automatycznie w każdym obciążeniu.
Dostawcy chmury mogą korzystać z obu. Ściśle połączone akceleratory mogą obsługiwać operacje modelowe intensywnie wykorzystujące komunikację, podczas gdy pule pamięci wspierają większe konteksty lub rzadziej używane dane. Pamięć masowa może zapewniać kolejny poziom pojemności dla informacji tolerujących dłuższy czas pobierania.
Etykiet „zorientowany na procesor” i „zorientowany na pamięć” nie należy więc traktować jako bezwzględnych kategorii. Nowoczesne systemy łączą oba podejścia. Istotne rozróżnienie polega na tym, który koszt dana architektura uznaje za podstawowy.
Konstrukcja zorientowana na procesor zakłada, że obliczenia są zasobem rzadkim, i przenosi do nich dane. Konstrukcja zorientowana na pamięć traktuje ruch danych jako zasób rzadki i umieszcza więcej obliczeń wokół danych. Inferencja wzmacnia drugie z tych założeń.
CXL, NVLink i przetwarzanie blisko pamięci dzielą pracę
Żadna pojedyncza magistrala połączeniowa ani akcelerator nie rozwiązuje problemu danych, ponieważ rozbudowa pamięci, komunikacja GPU i lokalne przetwarzanie pełnią różne funkcje.
Compute Express Link, czyli CXL, zapewnia spójne pamięciowo połączenie między procesorami, akceleratorami i urządzeniami pamięci. Spójność pamięci podręcznej umożliwia komponentom utrzymywanie zgodnego obrazu współdzielonych danych bez ręcznego kopiowania każdej aktualizacji.
CXL może obsługiwać rozbudowę pamięci i tworzenie jej pul. System może udostępniać pojemność wykraczającą poza pamięć fizycznie podłączoną do jednego procesora. Wiele urządzeń może również korzystać ze współdzielonych zasobów, gdy platforma i oprogramowanie obsługują taki układ.
Ta elastyczność jest ukierunkowana na niewykorzystaną pojemność. Jeden serwer lub akcelerator może nie mieć wystarczającej pamięci, podczas gdy inny dysponuje wolną przestrzenią. Tworzenie pul daje możliwość przydzielania pojemności na podstawie bieżących obciążeń.
CXL umożliwia także urządzenia łączące pamięć z lokalnym przetwarzaniem. Zamiast wysyłać kompletny zbiór danych do centralnego akceleratora, urządzenie działające blisko pamięci może wykonywać wybrane operacje lokalnie. Następnie zwraca mniejszy wynik.
NVLink i NVSwitch obsługują inną część systemu. NVLink zapewnia połączenia o wysokiej przepustowości między procesorami i akceleratorami NVIDIA. NVSwitch rozszerza te ścieżki, dzięki czemu większe grupy GPU mogą komunikować się za pośrednictwem struktury przełączającej.
Duże modele często dzielą parametry i wartości pośrednie między kilka akceleratorów. Urządzenia te muszą wymieniać aktywacje, częściowe wyniki i komunikaty synchronizacyjne. Wolna komunikacja może ograniczyć korzyści wynikające z dodawania kolejnych GPU.
CXL kładzie więc nacisk na elastyczny dostęp do pamięci i jej rozbudowę, podczas gdy NVLink skupia się na ściśle skoordynowanej komunikacji akceleratorów. Mogą wspierać ten sam szerszy cel, nie pełniąc identycznych ról.
Akceleracja blisko pamięci posuwa ten projekt dalej. Obliczenia są przenoszone do urządzeń pamięci lub obok nich, co ogranicza ilość danych przemieszczających się przez system. Podejście to działa najlepiej, gdy operacje można wykonywać lokalnie przy ograniczonej komunikacji.
Tesseract stanowi wcześniejszy przykład badawczy. Jego twórcy rozmieścili jednostki przetwarzające blisko pamięci warstwowej 3D i podzielili między nie dane grafowe. Każda jednostka przetwarzała lokalne dane i wymieniała komunikaty tylko wtedy, gdy było to konieczne.
Badanie Tesseract z 2015 roku wykazało dziesięciokrotną średnią poprawę wydajności w pięciu obciążeniach grafowych. Wykazało również średnie zmniejszenie zużycia energii o 87 procent w porównaniu z ocenianymi systemami konwencjonalnymi.
Wyniki te dotyczyły przetwarzania grafów, a nie współczesnych produkcyjnych usług modeli językowych. Eksperyment nadal zademonstrował zasadę architektoniczną: wydajność może skalować się, gdy przetwarzanie i przepustowość pamięci rosną razem.
Nowszy projekt stosuje podobne idee do inferencji modeli językowych. CENT, skrót od CXL-Enabled GPU-Free System, łączy rozbudowę pamięci CXL z jednostkami przetwarzającymi umieszczonymi blisko banków pamięci.
Recenzowane badanie CENT raportuje 2,3 razy wyższą przepustowość i 2,3 razy niższe zużycie energii niż wybrane bazowe konfiguracje GPU przy podobniej średniej mocy. Raportuje również 5,2 razy więcej tokenów na dolara.
Liczby te wymagają ostrożnej interpretacji. Opisują modelowaną i ocenianą przez autorów architekturę, obciążenia, konfiguracje bazowe i założenia. Nie dowodzą, że inferencja bez GPU jest gotowa zastąpić główne wdrożenia akceleratorów.
CENT mimo to testuje dominujący projekt pod presją. Inferencja autoregresyjna, która generuje jeden token po drugim, często ma niższą intensywność arytmetyczną niż trening. Intensywność arytmetyczna mierzy, ile obliczeń przypada na każdą jednostkę przenoszonych danych.
Obciążenie o niskiej intensywności arytmetycznej może stać się ograniczone przez pamięć. Dodawanie kolejnych jednostek obliczeniowych przynosi niewielkie korzyści, gdy pamięć nie może dostarczać danych wystarczająco szybko. Wyspecjalizowane projekty działające blisko pamięci mogą celować w tę niezgodność.
Pytanie architektoniczne brzmi, ile pracy można przenieść bez tworzenia nowych kosztów koordynacji. Uwaga, warstwy modelu i komunikacja rozproszona nie dzielą się idealnie. Niektóre operacje nadal wymagają wyników z wielu urządzeń.
Kolejną przeszkodę stanowi wsparcie programistyczne. Deweloperzy już polegają na dojrzałych frameworkach GPU, zoptymalizowanych kernelach i narzędziach wdrożeniowych. Nowa architektura blisko pamięci musi integrować się z tym oprogramowaniem albo uzasadniać kosztowną migrację.
Trudniejsze staje się także obserwowanie systemu. System rozproszony może przenosić obliczenia między akceleratorami, kontrolerami pamięci i warstwami pamięci masowej. Operatorzy muszą widzieć, gdzie na całej tej ścieżce zużywany jest czas i energia.
Uwagi wymagają również granice bezpieczeństwa. Współdzielone pule pamięci muszą izolować obciążenia i tenantów. Trwały kontekst agenta może obejmować wrażliwe prompty, pobrane dokumenty, poświadczenia lub wyniki narzędzi.
Te kwestie nie przekreślają projektu. Pokazują, dlaczego architektura determinuje więcej niż tylko szybkość benchmarków. Niezawodność, izolacja, programowalność i harmonogramowanie są częścią wydajności produkcyjnej.
Wyniki badań nie są dowodem gotowości produkcyjnej
Projekty zorientowane na pamięć mają wiarygodne podstawy badawcze, ale najsilniejsze wyniki pozostają specyficzne dla danych obciążeń i nie mogą gwarantować ekonomiki wdrożenia.
Artykuł SK hynix łączy opublikowane badania z prognozą branżową. Badania wspierają twierdzenie, że przenoszenie danych może dominować pod względem zużycia energii i opóźnień. Nie dowodzą, że jedna architektura stanie się standardem.
Tesseract zademonstrował przetwarzanie blisko pamięci w obciążeniach grafowych. CENT ocenił ambitny projekt oparty na CXL dla inferencji modeli językowych. Oba pomagają określić możliwości techniczne, lecz usługi produkcyjne wprowadzają ograniczenia, których prototypy badawcze nie są w stanie w pełni odtworzyć.
Rzeczywiste wdrożenia obsługują zmieniające się modele, formaty precyzji, polityki kontekstu i cele dotyczące opóźnień. Radzą sobie także z awariami, aktualizacjami oprogramowania, hałaśliwymi sąsiadami i skokami ruchu. Każda architektura musi działać w tych warunkach.
Porównania mogą silnie zależeć od wybranej konfiguracji bazowej. Platforma GPU ze słabym batchowaniem lub ponownym wykorzystaniem cache może wyglądać na nieefektywną. Wysoce zoptymalizowany stos obsługowy może poprawić wykorzystanie bez zmiany bazowego sprzętu.
Ewolucja modeli tworzy kolejną niepewność. Techniki zmniejszające rozmiar cache KV mogą osłabiać presję na pamięć. Kwantyzacja, która reprezentuje wartości za pomocą mniejszej liczby bitów, może zmniejszać rozmiar modelu i cache. Ulepszone metody uwagi mogą zmieniać wzorce dostępu.
Oprogramowanie może również unikać zbędnego przenoszenia danych. Cache prefiksów pozwala ponownie wykorzystywać współdzielone sekcje promptów. Routing uwzględniający cache kieruje powiązane żądania do workerów przechowujących istotny stan. Zdezagregowane prefill i dekodowanie przypisują różne fazy wyspecjalizowanym pulom zasobów.
Podejście NVIDIA multi-tier cache umieszcza dane KV w GPU HBM, pamięci CPU, lokalnej pamięci NVMe i zdalnej pamięci masowej. Jest to odpowiedź zorientowana na pamięć, zbudowana wokół infrastruktury GPU.
Ma to znaczenie dla konkurencyjnego ujęcia tematu. Obliczenia zorientowane na pamięć nie muszą koniecznie wypierać GPU. Mogą zwiększać ich efektywne wykorzystanie, ograniczając pracę poświęcaną przez nie na zarządzanie danymi.
Procesory blisko pamięci stają również przed pytaniami dotyczącymi produkcji i standaryzacji. Dodanie logiki może wpływać na powierzchnię, zachowanie termiczne, uzysk i koszt produktu. Nowe urządzenia potrzebują stabilnych interfejsów, zanim operatorzy chmury będą mogli wdrażać je na szeroką skalę.
CXL zapewnia elastyczność, ale połączenie CXL nie jest równoważne lokalnemu HBM. Pojemność, przepustowość i opóźnienie zajmują różne pozycje. Rozmieszczenie obciążeń musi uwzględniać te różnice.
Dezagregacja może poprawić wykorzystanie zasobów, jednocześnie zwiększając komunikację. Zdalna pula obsługująca zbyt wiele urządzeń może stać się zatłoczona. Źle umieszczona operacja może przebyć większą odległość niż w stałym serwerze.
Najmocniejsza wersja twierdzenia SK hynix jest więc zbyt szeroka, jeśli traktować ją dosłownie. Architektura nie zastępuje wydajności komponentów. Wolne procesory, słaba pamięć lub ograniczone sieci mogą każdy z osobna ograniczać system.
Bardziej obronny wniosek jest taki, że architektura określa, jaka część wydajności komponentów staje się użyteczna. Szybsze komponenty nadal są wartościowe, lecz ich wartość zależy od rozmieszczenia danych i koordynacji.
Przy interpretacji należy także uwzględnić zachęty komercyjne. SK hynix zyskuje, gdy klienci traktują pamięć jako strategiczny zasób systemowy. NVIDIA zyskuje, gdy klienci przyjmują ściśle zintegrowane platformy akcelerowane i własnościowe struktury połączeń.
Te zachęty nie czynią żadnego z tych argumentów fałszywym. Sprawiają jednak, że niezależne benchmarki stają się jeszcze ważniejsze. Kupujący potrzebują testów odzwierciedlających ich modele, długość sesji, wzorce żądań i wymagania dotyczące niezawodności.
Porównania kosztów powinny obejmować więcej niż zakup sprzętu. Energia, chłodzenie, przestrzeń w szafach rackowych, wykorzystanie zasobów, prace nad oprogramowaniem, operacje i migracja wpływają na całkowity koszt. Wyspecjalizowana konstrukcja może oszczędzać energię, a jednocześnie wymagać większego wsparcia inżynieryjnego.
Benchmarki powinny również raportować opóźnienia ogonowe, które mierzą wolniejsze żądania znajdujące się pod koniec rozkładu czasu odpowiedzi. Średnia przepustowość może ukrywać przerwy, których użytkownicy doświadczają bezpośrednio.
Trwałe agenty rodzą kolejne pytania. Utrzymywanie kontekstu blisko poprawia responsywność, lecz nieaktywne sesje mogą zajmować ograniczoną pamięć. Agresywne usuwanie zwalnia pojemność, ale wymusza kosztowne ponowne ładowanie, gdy agent wznowi działanie.
Ten kompromis przypomina buforowanie stosowane w innych obszarach informatyki, ale ma większą skalę. Pojedyncza sesja może zachowywać rozbudowany kontekst i stan pośredni. Tysiące równoczesnych agentów mogą uczynić politykę rozmieszczania kluczową decyzją dotyczącą pojemności.
Sceptyczne stanowisko nie zakłada, że informatyka skoncentrowana na pamięci nie ma wartości. Chodzi o to, że nie ustalono jeszcze uniwersalnego układu. Obciążenia zbyt mocno się różnią, a stos technologiczny nadal się zmienia.
SK hynix przedstawił kierunek, a nie gotowy zamiennik obecnych centrów danych. Kolejne dowody muszą pochodzić z wdrażalnych produktów, interoperacyjnych systemów oraz powtarzalnych pomiarów na poziomie obciążeń.
Trzy sygnały pokażą, czy AI skoncentrowana na pamięci zwycięży
Teza zyska na sile tylko wtedy, gdy nowe systemy przełożą mniejszy transfer danych na mierzalne korzyści w rzeczywistych obciążeniach inferencyjnych.
Pierwszym sygnałem będzie integracja na poziomie produktu wokół współdzielonej i warstwowej pamięci kontekstowej. Warto obserwować systemy zarządzające cache’ami KV w HBM, DRAM i pamięci masowej bez zmuszania aplikacji do obsługi każdego transferu.
Kluczowym wskaźnikiem nie jest teoretyczna pojemność. Jest nim to, czy takie systemy utrzymują opóźnienia, obsługując jednocześnie więcej równoległych sesji. Wysokie współczynniki trafień cache’a i przewidywalne opóźnienia ogonowe wspierałyby tezę o architekturze stawianej na pierwszym miejscu.
Jeśli kontekst często dociera z opóźnieniem, argument słabnie. Dodatkowa pojemność byłaby wtedy uzyskiwana kosztem responsywności. Operatorzy mogliby preferować więcej pamięci lokalnej lub prostsze, stałe konfiguracje.
Drugim sygnałem będzie szersze wdrożenie pul pamięci CXL i przetwarzania blisko pamięci. Same zapowiedzi nie rozstrzygną sprawy. Kupujący potrzebują interoperacyjnego sprzętu, wsparcia systemów operacyjnych, narzędzi orkiestracji i frameworków aplikacyjnych.
Udane wdrożenia powinny pokazać, że współdzielona pojemność poprawia wykorzystanie zasobów bez przeciążania interkonektów. Powinny także dokumentować izolację, obsługę awarii oraz wydajność przy mieszanych obciążeniach.
Jeśli CXL pozostanie ograniczony do wąskich ról rozszerzających, architektura skoncentrowana na pamięci nadal będzie się rozwijać, lecz jej wizja rekonfigurowalności będzie postępować wolniej. Własnościowe sieci scale-up mogą zachować większą kontrolę nad wdrożeniami o wysokiej wydajności.
Trzecim sygnałem będą niezależne benchmarki inferencyjne mierzące kompletny system. Testy powinny obejmować długie konteksty, agentów wieloturowych, oczekiwanie na narzędzia, usuwanie cache’a i równoczesnych użytkowników.
Szczytowa przepustowość arytmetyczna pozostanie istotna, ale powinna być prezentowana obok opóźnienia tokenów, energii na token, wykorzystania pamięci i ruchu sieciowego. Kupujący potrzebują również wyników dla zmieniających się obciążeń, a nie jednego starannie wybranego modelu.
Dowody obejmujące kilka rodzin modeli wzmocniłyby argument SK hynix dotyczący infrastruktury AI. Wyniki ograniczone do jednej architektury lub syntetycznego ruchu pozostawiłyby większą niepewność.
Czytelnicy powinni również obserwować, jak odpowiedzialności przesuwają się między dostawcami. Producenci pamięci mogą dostarczać więcej logiki, firmware’u i architektur referencyjnych. Firmy produkujące akceleratory mogą rozszerzać kontrolę nad pamięcią masową i zarządzaniem kontekstem.
Dostawcy chmury prawdopodobnie połączą oba podejścia. Mogą budować własnościowe warstwy orkiestracji obejmujące akceleratory, pule pamięci i pamięć masową. Ich skala zapewnia im wystarczającą ilość danych o obciążeniach, by dynamicznie optymalizować rozmieszczanie.
Dla programistów i nabywców korporacyjnych natychmiastowa lekcja jest praktyczna. Należy pytać, gdzie znajdują się wagi modelu i kontekst w każdej fazie obsługi. Należy pytać, jak często się przemieszczają, przez które łącza przechodzą oraz co dzieje się podczas przeciążenia.
Następnie należy zapytać, czy system mierzy te ścieżki. Samo wykorzystanie GPU nie wyjaśni usługi, która zatrzymuje się podczas transferów cache’a. Sama pojemność pamięci nie ujawni, czy pula dostarcza dane na czas.
Agenty AI czynią te pytania pilnymi, ponieważ przekształcają kontekst w trwały stan infrastruktury. Każda pętla rozumowania może rozszerzać ten stan, a każde wywołanie narzędzia może przerwać przewidywalne przetwarzanie.
Zwycięska architektura nie będzie po prostu umieszczać więcej pamięci obok większej mocy obliczeniowej. Dopasuje każde obciążenie do odpowiedniej ścieżki danych, kontrolując jednocześnie narzut komunikacyjny.
Taki rezultat będzie wymagał współpracy między chipami, interkonektami, pamięcią masową, oprogramowaniem obsługującym modele i projektowaniem aplikacji. Żadna pojedyncza specyfikacja nie będzie w stanie opisać wynikowej wydajności.
Pytanie na kolejny przegląd infrastruktury jest więc konkretne: czy najnowsza inwestycja ograniczyła transfer użytecznych danych, czy jedynie dodała kolejny szybki komponent? To rozróżnienie zdecyduje, czy skoncentrowana na pamięci teza SK hynix stanie się standardem produkcyjnym, czy pozostanie wpływowym argumentem projektowym.
