W systemach sztucznej inteligencji ograniczeniem bywa nie tylko szybkość dysków czy przepustowość łączy. Czas procesora pochłania również obsługa systemu plików: ustalanie, gdzie zapisane są potrzebne dane, i sprawdzanie, czy można uzyskać do nich dostęp. Południowokoreańska firma FADU chce przenieść te zadania do samego SSD. Jej koncepcja brzmi obiecująco, ale na pierwsze próbki nowego nośnika trzeba będzie poczekać do trzeciego kwartału 2027 roku.
SSD, który rozumie pliki
FADU zaprezentowało File-Semantic SSD (FS-SSD) podczas konferencji OCP Global Summit. Zamiast udostępniać dane wyłącznie jako bloki, dysk ma obsługiwać operacje na plikach, takie jak wyszukiwanie ich po nazwie, sprawdzanie uprawnień czy odczyt wybranych fragmentów. Te zadania mają być wykonywane przez oprogramowanie układowe kontrolera SSD, a nie przez procesor serwera.
Według założeń firmy pliki mogłyby pobierać bezpośrednio procesory graficzne, układy DPU i klienci zdalni. W ścieżce dostępu do danych nie byłoby wtedy konieczności angażowania hostowego systemu plików, warstwy blokowej ani procesora serwera pamięci masowej. FADU twierdzi, że takie podejście może ograniczyć narzut obliczeniowy w infrastrukturze AI.
Pomysł nie polega jednak na tworzeniu całkowicie nowego protokołu komunikacyjnego. FS-SSD wykorzystuje NFSv3, czyli wariant protokołu Network File System używanego do pracy z plikami przechowywanymi na innych komputerach. Żądania NFS są przenoszone w standardowych poleceniach NVMe, które mogą trafiać do dysku lokalnie albo przez NVMe-oF, czyli NVMe działające w sieci.
FADU wybrało NFSv3 ze względu na jego prostotę i szeroką zgodność. Protokół obejmuje 21 operacji, działa z różnymi systemami operacyjnymi i jest bezstanowy: każde żądanie zawiera informacje potrzebne do jego obsłużenia, więc dysk nie musi pamiętać, które pliki poszczególni klienci mają otwarte.
Jedna mapa zamiast dwóch etapów
W zwykłym komputerze ustalenie miejsca przechowywania danych odbywa się w dwóch krokach. System plików wskazuje blok, w którym znajduje się fragment pliku, a następnie oprogramowanie SSD — tzw. warstwa translacji pamięci flash — odnajduje fizyczne miejsce tego bloku w kościach pamięci.
FS-SSD ma połączyć te operacje w jedną warstwę opartą na F2FS, systemie plików Linuksa zaprojektowanym z myślą o pamięci flash. Według FADU takie rozwiązanie pozwala przejść bezpośrednio od pliku do jego położenia na nośniku i ograniczyć rozmiar mapowania potrzebnego do obsługi danych.
Typowy SSD może mieć około 1 GB pamięci DRAM na każdy terabajt pamięci flash, a większość tej przestrzeni zajmuje mapa bloków. FADU deklaruje, że w FS-SSD przy tej samej ilości DRAM około 95 proc. ma pozostać wolne, by przechowywać pod ręką informacje o często używanych plikach.
Zmiana ma też uprościć sprzątanie pamięci flash. Ponieważ dane na takiej pamięci nie mogą być nadpisywane w miejscu, dysk musi przenosić potrzebne informacje i czyścić całe bloki. W tradycyjnym układzie podobne zadania wykonują zarówno system plików, jak i sam SSD, co może oznaczać powielanie pracy.
FADU twierdzi, że połączenie tych funkcji ogranicza write amplification, czyli ilość zapisów wykonywanych przez nośnik w stosunku do zapisów zleconych przez użytkownika, o 63 proc. w porównaniu z F2FS działającym na zwykłym hoście. Mniejsza liczba zapisów może zmniejszyć zużycie pamięci flash, ale podany wynik pochodzi z symulacji w NVMeVirt, a nie z testów gotowego dysku.
Przeniesienie obsługi plików do kontrolera SSD może ograniczyć obciążenie procesora serwera. Na razie przedstawione wyniki należy jednak traktować jako wstępne, bo opierają się na symulacjach i testach producenta. O realnej przydatności rozwiązania zdecydują niezależne pomiary na gotowym sprzęcie.
Obiecujące wyniki, ale testy mają ograniczenia
W jednym z wstępnych pomiarów FADU raportuje około 460 tys. operacji na sekundę przy obsłudze zdalnych plików. Wynik utrzymywał się na podobnym poziomie, gdy liczbę rdzeni serwera ograniczono z 16 do jednego. Dla porównania standardowy serwer NFS z Linuksem miał osiągać około 150 tys. operacji na sekundę, a przy ograniczeniu zasobów — około 40 tys.
To jednak dane przedstawione przez producenta, które nie zostały niezależnie potwierdzone. Co więcej, testy przeprowadzono na komputerze z łączem PCIe 5.0, przez co sekwencyjne odczyty zatrzymały się w okolicach 14,1 GB/s — mniej więcej na granicy możliwości tego interfejsu. Tymczasem dyski PCIe 6.0, takie jak Micron 9650, są już dostępne w masowej produkcji i mają osiągać do 28 GB/s odczytu.
W testach wykorzystano procesory Intel Core i5-13600K, 128 GB pamięci DDR5 oraz kartę sieciową ConnectX-6 100 Gb/s. Układ ma 14 rdzeni fizycznych i 20 wątków, dlatego nie jest jasne, czy w opisie ograniczania serwera do „rdzeni” FADU liczyło rdzenie, czy wątki. Firma zapowiada wyniki z platformą PCIe 6.0 na pierwszy kwartał 2027 roku.
Przeczytaj także: Najpotężniejszy serwer: 81 920 rdzeni CPU i 1,28 PB RAM w jednym 42U racku.
Konkurencja i wcześniejsze pomysły
FADU nie jest pierwszą firmą, która próbuje ograniczyć udział procesora w dostępie do danych. Nvidia od lat rozwija GPUDirect Storage, dzięki któremu dane mogą trafiać z dysku bezpośrednio do pamięci GPU. Nadal jednak to oprogramowanie działające na hoście decyduje, jakie dane pobrać, i wysyła odpowiednie żądania.
Podobny kierunek opisano już w pracy badawczej DevFS z 2018 roku. Jej autorzy proponowali system plików umieszczony wewnątrz urządzenia pamięci masowej, ale sprawdzali go jedynie w emulowanym prototypie. Istnieją też standardowe polecenia NVMe typu key-value, które pozwalają adresować dane za pomocą kluczy zamiast numerów bloków, a SK hynix opracowało dysk tego rodzaju we współpracy z Los Alamos National Laboratory.
FS-SSD nie ma jednak jeszcze własnego standardu branżowego. FADU nie zgłosiło poleceń semantycznych dla plików do organizacji NVM Express ani OCP Storage, więc klienci będą na razie potrzebować oprogramowania firmy.
Na gotowy produkt trzeba poczekać
Długofalowa wizja FADU zakłada wykorzystanie obudowy flash, w której przed dyskami znajdowałyby się jedynie przełącznik PCIe oraz DPU lub karta sieciowa obsługująca NVMe-oF. Firma planuje przygotować projekt referencyjny oparty na DPU Xsight Labs 800G E1 do końca 2027 roku.
Według prognoz FADU taki system mógłby zużywać o 42 proc. mniej energii i kosztować o 57 proc. mniej na każde 16 dysków niż tradycyjny serwer pamięci masowej. To jednak wyliczenia, a nie wyniki pomiarów gotowego rozwiązania. Istnieją już konstrukcje z DPU, takie jak systemy Supermicro BlueField, ale w nich oprogramowanie pamięci masowej nadal działa na procesorach Arm karty DPU.
FADU wskazuje na realny problem: w systemach AI obsługa plików może pochłaniać zasoby, które przydałyby się do innych zadań. Na razie argumenty firmy opierają się jednak na testach z ograniczeniem PCIe 5.0, symulacjach zużycia flash i prognozowanych oszczędnościach. Wyniki z platformy PCIe 6.0, zapowiadane na początek 2027 roku, pokażą, czy SSD rzeczywiście będzie w stanie przejąć obowiązki procesora bez utraty wydajności.
Jeśli FS-SSD rzeczywiście przeniesie logikę plików do kontrolera i zostawi 95% DRAM wolne, to to może być game-changer dla inference-heavy klastrów. Czekam na wyniki z PCIe 6.0 — jeśli przepustowość nie będzie buttleneckiem, to mniejsze CPU overhead to realne przyspieszenie. Zamawiam preorder w myślach już teraz 😉
Kolejna marketingowa ściema dopóki nie zobaczę niezależnych testów i konkretnego firmware’u. NFSv3 to prostota, ale też brak wielu współczesnych mechanizmów (np. lepsze bezpieczeństwo, delegacje). Poza tym porównywanie symulacji w NVMeVirt do produkcyjnych dysków PCIe6 to trochę naciągane — łatwo podać procenty oszczędności na papierze. Obawiam się też vendor lock-in, skoro nie ma jeszcze standardu NVMExpress dla semantic ops.
Trochę merytorycznie: FADU łączy mapę plików z warstwą FTL — to może obniżyć RAM footprint i write amplification, ale wiele zależy od scenariusza I/O (random vs. sequential, mieszane read/write). Podany spadek WA o 63% z symulacji to obiecujące, ale NVMeVirt nie odzwierciedla wszystkich niuansów GC i wear leveling w realnym NAND. W testach użyli i5-13600K — typowy „14 rdzeni” to 6P+8E = 14 fizycznych, 20 wątków; trzeba wiedzieć czy ograniczali P-cores czy logiczne wątki. Również NFSv3 bezstanowość ma zalety, ale konsekwencje dla spójności plików i lockingu przy równoczesnych klientach trzeba dobrze przemyśleć. Czekam na pomiary z PCIe6 i realnym firmwarem.
Miałam okazję testować rozwiązanie z DPU (Supermicro+BlueField) i praktyka była taka, że sporo logiki ciągle lądowało na procesorach DPU/hosta. Jeśli FADU naprawdę przerzuci część operacji do SSD, to super — ale u mnie w labie problemem były edge-case’y: uprawnienia, race condition przy masowych odczytach, i drobne bugi w implementacji NFS. Trzeba bedzie zobaczyc jak z tym sobie poradzą na produkcyjnym urzadzeniu.
Kilka pytań do bardziej obeznanych: czy FS-SSD zachowa zgodność POSIX (locking, atomic append, mtime/atime)? Jak będą obsługiwane konsystencja i recovery po crashu kontrolera? Czy konieczne będą patche w kernelu/kliencie NFS, czy wszystko ma działać „out of the box” przez NVMe-oF? Ktoś wie, jak planują obsłużyć distribucję uprawnień i ACL?
Do tych co krzyczą „vendor lock-in” — każdy nowy feature w storage idzie w tym kierunku, ale w chmurze i tak i tak finalnie patrzysz na ecosystem (DPU, NVMe-oF). Tak, trzeba niezależnych testów i standaryzacji, ale z praktycznego punktu widzenia: mniej CPU cykli użytych na metadata ops to realne zyski w kosztach infrastruktury AI. Nie wierzę w magiczne 57% oszczędności na serio bez pełnych benchmarków, ale koncept ma sens.
Sceptyczny ton: FADU ma ciekawy pitch, ale to wygląda też jak idealny argument sprzedażowy inwestorom — „oszczędzisz 42% energii i 57% kosztów” brzmi ładnie, dopóki nie przychodzi faktura za integrację, wsparcie i konieczność przepisania części stacku. Brak zgłoszeń do NVM Express i OCP to czerwony flag. Jak ktoś pamięta wcześniejsze próby (DevFS, eksperymenty SK hynix) — pomysł nie jest nowy, realna trudność to interoperacyjność i standaryzacja.