AIのNAND/SSD storage：acceleratorを飢えさせない

storageはcapacity labelではなくpipelineである

SSDは、必要な時刻と粒度でdataを供給して初めてAIに寄与する。trainingではimmutable shardを読み、CPUでdecode/augmentし、host DRAMへstageしてからacceleratorへ送る。inferenceではweightの起動時load、document/vector retrieval、log、checkpointがある。「速いSSD」だけではlatency、concurrency、CPU cost、network path、cache状態を説明できない。

1. 1NAND page
2. 2SSD controller/FTL
3. 3NVMe/PCIe
4. 4host DRAM
5. 5decode
6. 6GPU HBM

1. 1read queue
2. 2mapping/GC
3. 3transport
4. 4staging
5. 5CPU/GPU
6. 6execute

NANDはpage単位でread/programしblock単位でeraseする。flash translation layerはlogical addressをphysical locationへ写し、garbage collection、over-provisioning、wear levelingを管理する。このためsequential/random、read-heavy/sustained-writeは異なる。cacheから高いburstが出ても、十分なwrite後にreclamationが働くsteady stateは別である。enduranceもdrive ratingだけでなく、small random writeや頻繁なrewritingによるwrite amplificationを含むworkload性質である。

経路全体を測る

玩具例としてloaderがdeviceを飢えさせないためdecoded sampleを8GB/sで供給する必要があるとする。各3GB/sと表示するSSDを4本使っても、decompression、CPU worker、shared PCIe、remote filesystem、stragglerが原因で8GB/sを逃し得る。逆にcache後に2GB/sしか要らなければ12GB/s購入はtraining timeを変えない。数値は例なのでfile format、compression、block size、worker数、queue depth、cache状態を実測で残す。

Solidigmの2025年記事はGPUへのdirect DMA pathとSSD→CPU/RAM→GPU pathを比較し、server、drive、software、block size、queue depthを公開する。vendor testであり、portableな性能法則ではない。同社のsolution pageもproduct positioningである。NVIDIAの構成表はlocal HBM仕様でありend-to-end storage benchmarkではない。

典型failureはwarm page cacheをSSD速度と誤認すること、large sequential readだけ測ること、decode/augmentationを落とすこと、driveを満たしてGC tail latencyを発見すること、direct pathを自動高速とみなすことだ。alignment、registration、I/O size、topology、software supportが結果を決める。容量増を売上へ結ぶ前にもshipment、mix、controller、endurance qualification、価格、inventory、customer architectureが必要である。

演習

固定shardでcold cache、warm cache、worker数制限の3試行を行う。median/tail batch wait、GPU utilization、storage read bytes、host CPU、device transferを取る。record size、queue depth、workerの一つだけを変える。SSD upgradeがcold startだけ改善しsteady-state utilizationが変わらなければ、その狭い結論を記す。checkpointがあるならsustained-writeも試し、未試験failureをunknownと残す。

同じSSDでも試験条件で結果が変わる

storage benchmarkはcache状態を明示しないと読めない。最初のreadはNAND/SSD、OS page cache、network、metadata lookupを通るが、二回目はhost DRAMから返る場合がある。warm runの高いthroughputをSSD性能と呼ばず、cold run、warm run、cacheを無効化または容量を超えるdatasetのrunを区別する。ファイル数が多いworkloadではmetadata serverやdirectory traversalが先に詰まることもある。

玩具例では、8GB/sのdecoded batchを要するtraining jobに、表示3GB/sのSSDを4台並べても12GB/sがそのままGPUへ届くわけではない。compressed recordの展開、augmentation、PCIe共有、workerの待ち、remote filesystemのstragglerが経路へ入る。反対にsteady stateが2GB/sしか必要としないなら、SSDの表示帯域を上げてもtraining timeは変わらない。測定表にはrecord size、compression、worker数、queue depth、CPU utilization、GPU utilizationを残す。

write pathも別試験にする。checkpointを数分ごとに書く場合、空のdriveの短いburstではなく、容量を使った後のsustained write、tail latency、write amplification、残りspare areaを観察する。小さいrandom updateが多いdatabase/index workloadと、大きいsequential shard writeを同じenduranceとして扱わない。電源障害保護、firmware、rebuild、data integrityも容量やread speedと別の運用条件である。

AI向けdirect storage pathの主張も、alignment、I/O size、DMA registration、topology、software versionを添えて試験する。GPUへCPUを介さず送る経路があっても、datasetが小さい、I/Oが細かい、CPU decodeが支配する、networkが遅いなら改善は限定的である。結論は「このserver、このdataset、このqueue depthでbatch waitが何ms変わった」と狭く書く。SSD売上へつなぐなら、capacity mix、controller、endurance qualification、価格、inventory、顧客構成という未測定の矢印を残す。