SamsungがHot Chips 2026で示したのは、メモリをただの保管場所ではなく、計算の場としても使うProcessing-in-Memory、いわゆるPIMの具体像だった。LPDDR5Xの中にMAC演算器を入れつつ、外からは通常のメモリチップのように扱える、というのが肝だ。発想自体は昔からあるが、今回は理論ではなく、実装と運用の面倒さまでかなり踏み込んでいる。面白いのは、性能の話より先に、OSやキャッシュとの相性の悪さがはっきり見えてくるところにある。
元記事が紹介しているSamsungのLPDDR5X-PIMは、見た目こそ通常のLPDDR5X-9600チップだが、16 banksそれぞれにPIM blockを持たせた設計になっている。DRAMは内部で bank に分かれていて、通常は memory controller が bank を選び、row を開き、column access strobe、つまり CAS 命令でデータを読む。だがPIMでは、その bank にぶら下がった演算ブロックが内部帯域を直接使う。外部バスに縛られないので、16 banks全体で理論上 614 GB/s を使える一方、通常のDRAMアクセスは 2 banks までで、最大 76.8 GB/s にとどまると記事は説明している。
PIM block の中身は、MAC tree と複数の register file、制御ロジックだ。1024-bit の instruction register file には 16-bit 命令を最大64本入れられ、4 kbit の source register file には activation vector を置く。モデルの weight は DRAM 側に載せ、PIM block はそれを第二オペランドとして使う。さらに 2 kbit の scale register でスケールをかけられる。Samsungの提示した数字では、各PIM blockのMAC arrayは data clock あたり INT8 か FP8 の MAC を4回、DDRを数えなければ1 cycleで8回こなせる。4-bit input weights にするとスループットは倍になり、パッケージ全体では 2.4 TOPS。かなり大きい数字に見えるが、LPDDR5Xチップを複数並べれば伸ばせる。たとえば8 chipsなら 9.6 INT8 TOPS で、Intel Meteor Lake のNPUにだいたい並ぶ。ただしその構成は、16 GB chip を8本使うことになるので、128 GBのシステムメモリを抱える高い構成でもある。
このPIMは、標準の LPDDR5X protocol の範囲を外れないように作られているのも特徴だ。Samsungは特別な row address を用意し、それをMMIOのように使う。チャンネルごとに mode control 用の row が2つあり、片方で single-bank mode、もう片方で multi-bank mode に切り替える。single-bank mode は通常動作、multi-bank mode は 16 banks 全体へ命令を広げるモードだ。さらに bank ごとの特別な row を activate すると、read/write が通常のDRAM内容ではなく PIM registers を触るようになる。記事では、これを使ってまず normal mode で weight をDRAMに載せ、その後 multi-bank mode と PIM Registers Activated mode に切り替え、activation values、scale factors、instruction を各 register に書き込む流れが示されている。PIM register への write は、multi-bank mode では16 banksに broadcast されるので、ある意味でかなり制約の強い SIMD のように振る舞う。AAM、つまり Address Align Mode も用意され、memory controller がアクセス順を並べ替えても、column address から source register のインデックスを推定できるようにしてある。計算が終われば single-bank mode に戻し、通常の読み書きへ復帰する。
この記事を読んで最初に引っかかるのは、Samsungの工夫そのものより、実用化した瞬間にソフトウェアの前提が崩れることだ。PIMモードでは通常のmemory accessと計算トリガーが同じ命令列の中に混ざる。すると、ある thread がPIMを使っている最中に別の thread が普通に memory read/write をすると、意図せず計算が走ったり、逆にPIMの VRF に変な値を書き戻したりする。元記事は、Samsungが PIM region を分離するしかないと見ているが、その設計はなかなか重い。channel を PIM専用に割り当てるなら、通常のアプリはその帯域を使えない。しかもPIMそのものの per-chip throughput はそこまで高くないので、帯域を空けた見返りが大きいとも言い切れないと思う。
さらに厄介なのは multitasking だ。アプリ内で locks をかけるだけでは足りず、OS全体としてPIMの使用中に他 process が割り込まないようにする必要が出てくる。記事は、もし preemption するなら instruction/source/scale/vector register を各bankから退避しなければならないと指摘する。これはかなり面倒だ。現実のOSは、こういう「メモリの意味が変わる」装置を前にすると、単に高速化の話では済まない。ハードウェアの賢さが増すほど、ソフトウェア側は排他や保存・復帰のコストを背負わされる。
PIMのもう一つの難所は、CPUの基本的な最適化と真正面から衝突することだ。元記事では、PIM memory を cacheable にすると cache がPIM用の read/write を吸い込んでしまい、そもそも計算が起きない。だから Samsung は uncacheable mapping を勧める。だが、CPUやGPUはDRAM遅延を隠すために caching に大きく依存しているので、cache を外した領域は極端に遅くなる。しかもPIM read は単なる read ではなく、VRFを変える side effect を持つ。そうなると、prefetch や out-of-order execution も危ない。先読みした load が「まだ必要ない」だけなら普通のメモリでは問題ないが、PIMではその時点で計算結果が変わってしまうからだ。
ここから見えるのは、PIMが「高速な新しい命令」を足すのではなく、既存のメモリ階層の約束事を書き換える技術だということだと思う。速さはあっても、non-speculative にしなければならず、cache も prefetch も out-of-order も捨てるとなれば、CPU側の性能はかなり削られる。つまり、PIMを使う局面はかなり限定されるはずだ。巨大な行列演算のように、同じデータをまとめて扱い、途中でOSに触られず、cache の恩恵より転送削減の利益が勝つ場面に限られるのではないか。
SamsungのLPDDR5X-PIMが強いのは、標準の memory controller としゃべれる点にある。サーバー、desktop、laptop、mobile device まで入るかもしれない、という話が出てくるのはそのためだ。ただ、元記事を読むと、その「互換性」はかなり薄氷の上にある。命令自体は標準のDRAM command を流用しているが、mode を切り替えた瞬間に意味が変わる。互換というより、同じ口で別の機械を呼び出している感じに近い。
私はここに、PIMの現在地がよく出ていると思う。アイデアとしては前から魅力的でも、普及を決めるのは peak TOPS ではなく、既存システムにどこまで自然に溶け込めるかだ。今回の設計は、ハードウェア単体ではよくできている。一方で、OS、memory allocator、scheduler、さらにはアプリの同期設計まで巻き込まないとまともに使えそうにない。だからこそ、PIMは「メモリに計算を置く」技術であると同時に、「システムの境界をどこで引くか」を再設計する技術でもある。そこまで行って初めて、実験室の面白い仕組みから製品に近づくのだと思う。
