A DeepSeek Linux fájlrendszert fejleszt az AI-tréning és inferencia teljesítményének javítására

Fájlrendszer, NAS, storage

AI: 

A DeepSeek egy új Linux fájlrendszeren dolgozik, amelyet kifejezetten az AI-tréning és inferencia teljesítményének javítására terveztek. A cél az, hogy optimalizálják az adatelérést és a kezelést, így gyorsabb és hatékonyabb legyen a gépi tanulási modellek betanítása és futtatása. A fejlesztés valószínűleg olyan problémákat céloz meg, mint a nagy méretű AI-datasetek kezelése, az I/O szűk keresztmetszetek csökkentése és a GPU-alapú számítások jobb kihasználása. Ez a projekt fontos lehet az AI-infrastruktúra optimalizálásában, különösen a nagy teljesítményű számítási környezetekben.

A kínai AI vállalat, a DeepSeek ezen a héten nyilvánosságra hozta a 3FS-t, egy Linux FUSE-alapú fájlrendszert, amelyet az AI-tréning és inferencia teljesítményének javítására terveztek. [...] A 3FS a FUSE-re támaszkodik és célja, hogy megkönnyítse a nagy méretű AI-tréning/inferencia klaszterek telepítését közös tárhely használatával.

Részletek itt.

( Raynes v | 2025. 03. 01., szo – 17:32 )

A FUSE meg a teljesítmény egy mondatban oximoron. Miért nem kernelmodulként oldják meg, úgy tényleg gyorsíthatna valamit.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

( EspOS | 2025. 03. 01., szo – 18:34 )

El kéne már felejteni a fájlrendszert. Azért van az SSD-ben SoC, hogy ezt oldja meg a motorháztető alatt. Nem érdekel hogy mit hogy csinál, beküldök egy fájlt, az legyen visszaolvasható, pont.

https://www.esp8266.org/

ezt nem az opredszernek kéne csinálni, hanem az SSD förmvérjének, természetesen szabványosítva

Nem hiszem, hogy létezik, vagy hogy valaha is létezni fog olyan fájlrendszer, ami minden use case esetén képes helyt állni. Márpedig hardverbe vasalához és szabványosításhoz ilyen kéne.

Gondolj csak arra, mennyire más meta adatok kellenek Win és Linux esetén pl. (mit kezdene a Win UNIX jogosultságokkal? Vagy a Linux Win ACL-ekkel? No és hogy lehetne oprendszertől függetlenül device fájlokat létrehozni? stb.)
Aztán meg, hova mount-olnád fel azt az SSD-t? Ehhez mindenképp kell az oprendszerbe is egy gyökérkönyvtár (az mondjuk lehet ramdisk, de akkor sem úszod meg a fájlrendszerkezelést az oprendszerben).

ezt nem az opredszernek kéne csinálni, hanem az SSD förmvérjének, természetesen szabványosítva

Ellenvélemény: minél magasabb absztrakciós szintet nyújt egy szolgáltatás, annál könnyebb benne hibát, egészen pontosan biztonsági hibát véteni. Blokkműveletekből álló interfészt könnyebb jól tervezni és implementálni mint egy (szükségszerűen magasabb szintű) file-műveletekből álló interfészt. Így minél bonyolultabb (= minél támadhatóbb) a szoftver, annál kevésbé raknám firmware-be. Inkább frissítek OS driver-t, mind SSD firmware-t.

Nem írtál abszolút hülyeséget, mert végeredményben abban igazad van, hogy az SSD-k ma már vannak annyira gyorsak, hogy nem kell fájlrendszereket sebességre optimalizálni. Még a szutyok lassú NTFS-t is megmentik Windowson az SSD-k, pedig ott a Defender meg a Windows/File Explorer is tovább lassítja.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

amugy nem annyira elvetemult az otlet, mint lett volna ugyanez 10-20 eve.

ma mar ugye nem kell bootsectorokkal kokanyolni, az EFI megoldja egy particion fileokkal.

a particionalast sem kell OS szinten kezelni, az nvme tudja nativan mar most is.

a filerendszerek nemcsak workloadokra, hanem taroloeszkozokre is vannak optimalizalva, mas jo pl ssd-re mint hdd-re vagy tape-re. nyilvan az sem lenne baj, ha az fs figyelembe venne az ssd belso lelkivilagat, blokkmeretet (az a minimum amit egyszerre tud irni, ez az MLC-k ota altalaban eleg nagy, 64MB-ra emlexem de lehet meg tobb is a maiaknal), esetleg valamilyen belso nvram jellegu cachet is hasznalna pl a directory indexekhez, hogy pl az atime-ok ne gyilkoljak a cellakat.

meg a snapshotolast (CoW, windoznal shadow copy) is megoldhatna hardverbol, az ssd-k amugy is fizikailag mashova szoktak irni modositaskor, tehat sok melo nem lenne ezzel sem.

az OS-fuggo attribok erdekes kerdes, de valamilyen xattr-szeru mokolast lehetne amiben van egy formatum ID aztan a raw data amit az adott OS tud ertelmezni (pl. win user jogok, posix fsattr stb)

egyedul az adatmentes lenne szopo, na az nem kicsit...

esetleg valamilyen belso nvram jellegu cachet is hasznalna pl a directory indexekhez

Ilyen van pl. SD kártyákban, csak hát nem az adathordozóban magán, hanem a kontrollerben (és persze hivatalosan csakis FAT esetén működik állítólag). Figyelembe véve, hogy tényleges fájlrendszerértelmezés nincs, csak szektor kategorizálás (CMD20 speed class control: könyvtár adat, meta adat, fájl adat), igazából szerintem bármilyen fájlrendszerrel működnie kell ennek a beépített cache-nek.

( bzt | 2025. 03. 01., szo – 19:28 )

A DeepSeek egy új Linux fájlrendszeren dolgozik

Már megint haluzik ez a fránya ChatGPT... Nem dolgozik rajta, hanem régesrég kész van, aktívan használja házon belül jóideje, most csak annyi történt, hogy publikussá tették.

( bimi3 | 2025. 03. 01., szo – 21:15 )

A DeepSeek github repo-jába benézve, érdekesnek találom hogy a DeepSeek-V3 teljes egészében Python-ban lett megírva.

Laikusként azt gondolnám, hogy egy ilyen számításigényes projekt mint az AI, C-ben vagy Rust-ban lesz lekódolva, hogy gyors legyen. Ezek szerint a script nyelvek tudnak valamit amit a gépi kódra fordított nyelvek nem.

Ezek szerint a script nyelvek tudnak valamit amit a gépi kódra fordított nyelvek nem.

Nem, nem tudnak.

A helyzet az, hogy ebben a speciális esetben a Python script csak összeállítja az adatokat és átpasszolja a GPU-nak, az igazán számításigényes részt pedig a GPU végzi és nem az interpretált Python kód. Nyilván gyorsabb lenne, ha az adatösszeállítást fordított nyelvben írnák, de nem biztos, hogy megérné, mivel nem az adatösszeállítás a szűk keresztmetszet, hanem a kiértékelése. Ez utóbbi meg ígyis-úgyis gépi kódra (GPU-ra) fordított computational shaderben van megírva.

mit ertesz adatosszeallitas alatt? mert azert az AI libek (tensorflow, pytorch, numpy stb) megoldjak ezt forditott nyelveken, a py igazabol csak vezerli ezeket. kivetel talan a szoveges input parsolasa, de az meg elenyeszo meretu a modelhez kepest.

pl. ha azt irod py-ben hogy y=x*a+b es ezek tensorok akkor lehet milliard parameteru matrixokkal fogja ezeket a muveleteket elvegezni a cpu/gpu-ra optimalizlat kod...  erdemes a numpy-t nezegetni, mit csinal elol-hatul.

mit ertesz adatosszeallitas alatt?

Mint írtam volt, annak a bitkolbásznak az összeállítását, ami átmásolódik a VRAM-ba, hogy aztán onnan a GPU-n natívan futó shader megcsócsálja. Ez utóbbi a számolásigényes és szűk keresztmetszet, ezért is kell hozzá kvantocsillió dolláros Nvidia hardver, hogy gyors legyen. Ehhez képest az adatok belapátolása (majd az eredmény kilapátolása) elenyésző overhead, simán belefér, hogy ezt a részt egy interpretált nyelv végezze.

matrixokkal fogja ezeket a muveleteket elvegezni a cpu/gpu-ra optimalizlat kod

...és még véletlenül sem a Python interpreter hajtja végre, ezért nem számít, hogy szkriptnyelv vagy fordított nyelv végzi-e az adatösszeállítást, mert a lényeg, a műveletvégzés úgyis a GPU-n fut. Pontosan erről van szó.

Egy időben játszottam azzal, hogy hogyan lehet megerőszakolni úgy a shadereket, hogy számítást végezzenek computational shader nélkül (mivel a CUDA proprietary és hardverspecifikus, ellenben az OpenGL nyílt és általánosan elérhető sokféle kártyán és oprendszeren). Simán működik, annyi a hátránya csak, hogy az egyik shadert (én a fragment shadert használtam erre) úgy kell megírni, hogy csak átmásolja az adatokat. Computational shader esetén ez a plusz másolás kimarad, egyébként semmivel sem gyorsabb. Ez a fajta hákolás aztán okafogyottá vált, amikor kijött a Vulkan, mert abban már a computational shaderek is szabványosítva vannak és video kártya függetlenek.