なぜHBM帯域が重要か：FLOPSの前にbyteを数える

帯域は性能そのものではない

acceleratorはoperandが間に合って初めて演算できる。HBMはprocessor近傍の幅広いDRAMであり、「AIが速い」という同義語ではない。kernelが有用なoperation一つ当たりに何byte動かすかを問う。この比率が算術強度である。大きなvectorを繰り返し読む低強度kernelはmemory bandwidthで止まりやすい。一方、matrix multiplyのような高強度kernelはcomputeで止まり得る。容量も別条件である。tensorが載らなければ、帯域だけ増やしても速くならない。

1. 1weight/activation
2. 2HBM read/write
3. 3arithmetic unit
4. 4result

1. 1byte/operation
2. 2算術強度
3. 3bandwidth上限またはcompute上限

1. 1容量不足
2. 2offload/recompute
3. 3別のdata movement

MicronはHBM3Eを1,024 I/O、pin当たり9.2Gb/s超と記載する。製品ページの数を掛け、bitをbyteへ直すとprotocol前で約1.17TB/sとなり、同社の1.2TB/s超という仕様と整合する。これはvendor仕様で、任意workloadの実測ではない。NVIDIAの構成表はH200 SXMを141GB・4.8TB/s、8 GPU nodeを1.1TBとする。device当たりとnode合計を混同しない。

玩具計算で上限を読む

2400億operation、HBM転送120GBなら算術強度は2 operation/byteである。持続4TB/sの仮想deviceでは帯域上限は8TOP/s。computeが40TOP/sでも最初の上限は8TOP/sで、compute倍増は効かない。byteを半減できれば16TOP/sになる。24000億operationで転送が同じなら20 operation/byte、帯域上限は80TOP/sとなり40TOP/sのcomputeが効く。数値は玩具例であり、現実にはcache、layout、同期、精度、競合が加わる。

weight、activation、workspace、KV cacheが150GBなら141GB deviceには全常駐しない。sharding、quantization、batch変更、checkpointing、host offloadは容量と経路の両方を変える。これを帯域問題と一語で呼ばない。NVIDIAの2023年発表も製品仕様であって、特定modelのlatency保証や市場成果ではない。

演習

warm-up後に固定stepを実行し、model revision、precision、batch、sequence length、HBM traffic、achieved computeを記録する。sequenceかbatchかlayoutを一つだけ変える。帯域もcompute利用率も低ければ、launch gapやinput stallを先に調べる、という反証条件を書く。residency reportも取り、capacityとbandwidthを別々に結論づける。

profilerで見る順序

まず一回目の実行を捨てる。JIT compilation、weight load、allocatorの初期化が混ざるからである。次に同一prompt・同一seed・同一batchで複数回実行し、中央値と遅い側の値を保存する。timeline上でCPUのdataloader、host-to-device copy、kernel launch、kernel execution、collective communicationを別の区間として読む。HBMのbyte counterが大きくても、その区間がcritical pathに無ければ当面の改善対象ではない。

例えばdecodeが1 token当たり20 msで、kernelが12 ms、network同期が6 ms、launchの空白が2 msなら、HBM転送だけを半分にしても理想的な改善は12 msの一部に限られる。対してprompt ingestionで同じweightを多数回読むkernelが支配し、sustained bandwidthが仕様の近傍に張り付くなら、layout、reuse、flash attentionのようなdata movement削減を検討する根拠になる。この数値は診断手順を示す玩具例で、製品比較ではない。

複数GPUではlocal HBMとGPU間通信も混同しやすい。8台のdeviceが各自で十分なHBM帯域を持っていても、all-reduce待ち、shardの偏り、host側のbarrierがstep時間を支配し得る。device単位の帯域、node合計、network fabricの帯域は単位と測定窓を分けて記録する。peak値を足してapplication throughputを作らない。

財務の読み方にも同じ順序を使う。high-bandwidth memoryの容量が増えても、設計採用、qualification、実際のshipment、実現ASP、yield、売上認識までには別の条件がある。「workloadが帯域制約だった」という実測は、その先の会社別売上の証明にはならない。反証として、softwareのreuse改善、より小さいmodel、容量を節約するKV cache設計、別packageの採用を同じ表に置く。