HBM4 interfaceとpackaging：pin増加はsystemを変える

interface widthは設計選択である

SamsungはHBM4を2,048 I/O pin、前世代を1,024 pinと説明する。pinが増えれば同じpin rateで同時に運べるbitは増える。ただしmemory、base die、package、accelerator、board、softwareの契約なので、pin数だけでapplicationが二倍速くなるわけではない。

1. 1DRAM layer
2. 2logic base die
3. 32,048-pin interface
4. 4accelerator package
5. 5kernel

1. 1lane増加
2. 2power/signal/thermal設計
3. 3qualification
4. 4sustained bandwidth

玩具計算では2,048 pin×8Gb/sは16,384Gb/s、byte換算で2,048GB/sである。protocolや実装損失の前のraw rateにすぎない。pinを二倍にしてもrateが維持できなければ二倍にならない。rate上昇にはtiming、signal integrity、power delivery、thermal marginが必要で、capacityやend-to-end throughputを自動的に二倍にはしない。

Samsungの製品ページは最大3,300GB/s、1c DRAMと4nm logic base dieを記載する。2026年2月の発表は自社の11.7Gb/s、capacity option、出荷を述べる。これらはissuer claimであり、顧客qualification、market share、特定workloadの独立結果ではない。

base dieはsignal/powerを扱い、process選択はlogic density、I/O、leakage、integrationに影響する。wide interfaceでは同時switchingが増えるため、return path、crosstalk、clock、skew、test access、熱をpackageが扱う。JEDECはHBMを含む標準を扱う組織だが、標準は個々のmemory–accelerator組合せを認定しない。compatible silicon、firmware、cooling、manufacturing test、顧客受入が必要である。

演習

precision、batch、context、cooling、software versionを固定し、achieved bandwidth、temperature、clock、error counter、end-to-end throughputをbaseline化する。contextかconcurrent streamを一つだけ増やし、sustained bandwidthと温度をplotする。狭い技術結論、反証条件、未測定のpackage yield/長期reliabilityを別々に記す。

raw rateから有効性能へ

2,048 I/Oという数はinterfaceの幅を示す。実際にapplicationが使える帯域は、command、refresh、access pattern、bank競合、error correction、clock変動、他kernelとの共有で変わる。したがってpin数×pin rateの計算は上限を理解する出発点であり、profile上のGB/sと同じではない。測定結果にはread/write比、transfer size、concurrency、測定時間を添える。

玩具例では、raw 3.0TB/sのinterfaceを持つsystemでも、readとwriteが交互に発生し、短いkernelが同期を挟むなら平均1.6TB/sしか観測しないことがある。一方でlong sequential streamでは2.6TB/sに近づくかもしれない。この差は製品の虚偽ではなくworkloadの差である。比較する際は同じmodel、precision、context、batch、cooling、firmwareを揃え、token/s、kernel時間、request latencyのどれを改善したかを明記する。

packageは配線図以上のものだ。wide interfaceはpower delivery network、return path、crosstalk、clock skew、熱抵抗、mechanical stress、test accessを同時に扱う。base dieのlogic processを変えれば、I/Oの動作、leakage、設計rule、verificationも変わり得る。memory dieのspecだけでaccelerator packageのyieldやreliabilityを推論しない。

実務ではacceptance tableを作る。行に温度、clock、correctable error、sustained bandwidth、throughput、tail latencyを置き、列にbaselineとstress条件を置く。例えばcontextを二倍にして帯域が上がるがtail latencyも悪化した場合、capacity pressure、thermal throttling、schedulerを切り分ける追加試験を決める。短期にerrorが無いことは寿命保証ではなく、standard準拠は全組合せのqualification完了を意味しない。