AIアクセラレータはGPUから「計算機そのもの」へ
この資料の日時
元資料の日付と、その本文が公に存在した確認日時は別の記録です。
本文に含まれる語句 HBM DRAM SRAM 帯域・データ移動 先端パッケージング 電力・給電 冷却 チップレット AI推論 AIエージェント
出典・更新履歴・検証情報
この保存版のデータを照合するための情報です。元記事の初公開日とは区別しています。
- データセットの版
- 2026.09.23.4
- 記事内容のSHA-256
13d7249e8830f69911c5d05a48a5e3d8cca1c3c9a9ed9a0b67481748c58545f4- 保存版のSHA-256
a93cd59b29568aa84be628af33152a3170db8c08b9bd66a99fad20cb315004c4
外部証明の最終検査結果は詳細を開くと表示します。
AIアクセラレータはGPUから「計算機そのもの」へ
#Google×AMD観測から見えるCPU・HBM・ラック・供給制約の再編
#2026年8月、AI半導体を巡る興味深い観測が出てきた。
#SemiAnalysisの顧客向けレポートを基にした報道によれば、Googleが第10世代TPUの一部についてAMDと協業しているとの「market chatter」があるという。重要なのは、AMDがGoogleのTPUそのものを一から設計するという話ではない。SemiAnalysisがAMDの候補理由として挙げたのは、先端パッケージ、SoICを使った3D実装、そしてCPU IPだった。Googleとその顧客が、強化学習などCPU負荷の大きい処理のため、TPUとCPU coreを同一パッケージへ近づけようとしているとの観測である。現時点でGoogleもAMDも正式発表しておらず、これはあくまで未確認情報として扱う必要がある。 (Tom's Hardware)
#だが、この観測が本当かどうか以上に面白いことがある。
#なぜ候補がAMDなのか。
#ここを掘っていくと、Google TPU、AMD Instinct、NVIDIA Vera Rubin、BroadcomのXPUが、実は同じ方向へ収束し始めていることが分かる。
#それは、
#AIアクセラレータを「GPUやASICという一枚のチップ」として考える時代から、CPU・XPU・SRAM・HBM・ネットワーク・ストレージを一つの計算機として設計する時代への移行#
である。
##
1．Broadcom自身が予告していた「CPUを内蔵するXPU」
#GoogleとBroadcomは2026年4月、将来世代のTPUとAIラック向けネットワーク部品について2031年までの長期契約を結んだ。つまりAMD観測が事実だったとしても、GoogleがBroadcomを捨てるという話ではない。むしろGoogleのAI計算需要が大きすぎるため、複数の設計・供給元を持つ方向である。 (Reuters)
#BroadcomのHock Tan CEO自身も6月3日の決算説明会で、
#Broadcomとしてはすべての設計を獲得したいが、GoogleのAI computeの開発・消費速度を考えれば、供給元がある程度多様化することは十分想定している#
という趣旨を述べている。 (The Motley Fool)
#さらに重要なのが、同じ決算説明会の最後にHock Tanが説明した次世代XPU像である。
#彼は、XPU一個当たりの価値が世代を追って上がる理由として、
#- SRAMを増やす
- CPU coresをXPUに組み込む
- multi-die化する
- 大量のHBMを載せる
ことを挙げた。 (The Motley Fool)
#つまりBroadcom自身が、
#従来
CPU
│ PCIe
│
ASIC + HBMから、
#次世代
┌────────────────────┐
│ CPU chiplet │
│ AI XPU chiplet │
│ SRAM / Cache │
│ I/O die │
│ HBM × 多数 │
└────────────────────┘へ向かうと予告しているのである。
#これは非常に重要な変化だ。
##
2．なぜAIアクセラレータにCPUを入れるのか
#LLMのpre-trainingを極端に単純化すれば、巨大な行列積を長時間走らせる仕事である。
#こういう処理ではGPUやTPUが強い。
#ところがAIがReasoning、Reinforcement Learning、Agentへ進むと、
#LLM推論
↓
候補生成
↓
環境実行
↓
Python / Tool call
↓
検索・DBアクセス
↓
結果解析
↓
Reward / Evaluation
↓
次のLLM推論というループが増える。
#ここには、
#- 分岐
- scheduling
- code execution
- sandbox
- retrieval
- database
- parsing
- environment simulation
- reward計算
- tool orchestration
といった、GPUの巨大行列積とは性質の違う処理が大量に存在する。
#AMDも第6世代EPYCについて、Agentic AIではplanning、retrieval、tool executionなどCPU側の仕事が増えると説明している。 (AMD)
#SemiAnalysis由来の情報では、GoogleもTPU世代を進めるにつれCPU比率を高めているとされ、次世代ではCPUをTPUと同じパッケージへ近づけることが検討されているという。 (Tom's Hardware)
#つまりCPUはもう「GPUを起動するためだけのホスト」ではない。
#GPUやASICを高稼働率で動かすための、AIシステムのもう一つの演算器になりつつある。
##
3．ここで突然AMDが有力候補になる
#GoogleはTPUそのものの設計経験を十分に持っている。
#そのためAMDに期待されるものが、
#「Tensor演算器を設計してください」#
とは考えにくい。
#AMDが持つ独特の資産は別のところにある。
#AMD
Zen / EPYC CPU
+
Instinct / CDNA
+
chiplet
+
Infinity Fabric
+
HBM integration
+
3D stacking
+
Pensando
+
ROCm
+
Semi-Customである。
#特にAMDは、自社CPUとGPUを一つに統合する経験をすでに持っている。
#代表例がMI300Aだ。
#MI300Aは、
#- 24 Zen 4 CPU cores
- 228 CDNA 3 GPU Compute Units
- 128GB Unified HBM3
を一つのパッケージへ統合している。CPUとGPUが同じHBM poolを共有する。 (AMD Instinct)
#概念的には、
# MI300A
Zen CPU ─────────┐
│
├── Unified HBM
│
CDNA GPU ────────┘である。
#Googleが将来、
#Google TPU
+
CPU
+
HBMを一つのpackageへ統合したいなら、AMDにはそれに非常に近い経験がすでにある。
#だからGoogle×AMDが本当なら、この案件はAMDにとって単なるASIC受託売上以上の意味を持つ。
#他社AI ASIC＋CPU＋HBMを統合する実戦経験を積めるからだ。
##
4．Vera Rubinと次世代Custom XPUは同じ方向を向いている
#この構造をNVIDIA Vera Rubinと並べるとさらに分かりやすい。
#Vera Rubin NVL72は、
#- 72 Rubin GPU
- 36 Vera CPU
- NVLink 6
- ConnectX-9
- BlueField-4
- Spectrum-X / Quantum-X
- 20.7TB HBM4
をラック全体で一つの計算機として設計する。NVIDIA自身が「単一GPUサーバーではなく、ラック全体を一つのrack-scale acceleratorとして扱う」設計を強調している。 (NVIDIA Developer)
#さらに一つのVera Rubin Superchipは、
#Rubin GPU
↘
Vera CPU
↗
Rubin GPUという2 GPU : 1 CPU構成で、CPUとGPUをmemory-coherent NVLink-C2Cで結ぶ。 (NVIDIA Developer)
#一方、Broadcomが語る将来XPUは、
#CPU cores
+
ASIC/XPU
+
SRAM
+
大量HBM
+
multi-dieである。
#表面的には、
#NVIDIA
#CPU＋GPU＋HBM＋NVLink
#Google/Broadcom/AMD型
#CPU＋Custom ASIC＋HBM＋D2D
#と違って見える。
#しかしシステムの思想はかなり近い。
#CPUとAI acceleratorを近づけ、メモリを大量に載せ、ダイ間通信を高速化し、それらをラック単位で動かす。#
GPUとASICが違うだけである。
##
5．「ロジックとメモリの融合」とは何か
#ここでいう融合とは、いきなりDRAM cellの隣にGPU Tensor Coreを作るという意味だけではない。
#段階がある。
#第1段階
CPU ─ PCIe ─ GPU ─ HBM
↓
第2段階
GPU chiplet + HBM
同一package
↓
第3段階
CPU + GPU/XPU + HBM
同一package
↓
第4段階
logic die
↕ hybrid bonding
logic / cache / I/O die
↕
HBM logic base die
↕
DRAM stack
↓
第5段階
memory-on-logic
near-memory compute
3D DRAMである。
#HBM4ではlogic base dieの役割も大きくなり、将来的なHBM5 20-Hiでは、stack height、I/O density、thermalの制約からHybrid Bondingを使う方向が強いとTrendForceは報告している。 (TrendForce)
#つまりAI半導体は、
#ロジックを微細化する競争#
だけでなく、
#演算とデータの物理距離を短くする競争#
になっている。
##
6．AMD・Intel・Arm――CPUは何が違うのか
#ここでCPUの違いも整理しておきたい。
#AMD Zen / EPYC
#ZenはISAではなくCPU microarchitectureである。
#命令セットはx86-64。
#第6世代EPYC 9006では、
#- 最大256 cores
- 最大512 threads
- 16 memory channels
- 最大12.8GT/s MRDIMM
- PCIe Gen6
まで拡張されている。 (AMD)
#AMDの特徴は、chipletを早期から大規模CPUへ展開したことにある。
#Zen CCD
Zen CCD
Zen CCD
Zen CCD
↓
I/O Die
↓
DDR / PCIe / GPUという構造を得意としており、異種ダイを組み合わせる設計との相性がよい。
##
Intel Xeon
#Intel Xeonも基本的にはx86-64なので、AMD EPYCとのソフトウェア互換性は高い。
#Intelの特徴の一つは、
#- P-core
- E-core
という異なるCPU設計をデータセンター向けにも展開していること。
#さらにXeonにはAMX（Advanced Matrix Extensions）があり、CPU自身でもAIの行列処理を高速化できる。Xeon 6はDDR5-6400やMRDIMMをサポートし、メモリ帯域強化も重視している。 (Intel)
##
Arm
#Armは少し立場が違う。
#ArmはNeoverseなどのCPU IPを提供し、企業がそれを自社SoCへ組み込みやすい。
#Neoverse N3はperformance-per-wattを重視し、8～192 cores以上へスケールする構成を想定している。 (Arm Newsroom)
#そのためHyperscalerは、
#Arm CPU
+
自社AI ASIC
+
自社I/O
+
security
+
memory controllerという製品を作りやすい。
#Google AxionやAWS Gravitonのような方向である。
##
簡単に整理すると
#GoogleがAMDを欲しがる可能性が面白いのは、ArmのようなCustom SoCの世界へ、AMDがx86＋chiplet＋先端実装を持って入ってくる可能性があるからだ。
##
7．AMDは「CPU＋GPU会社」から「AIラック会社」へ変わった
#その変化を最も分かりやすく示すのがHeliosである。
#AMD Heliosは72基のMI455X、18基のEPYC Venice、Pensando networkを統合するrack-scale reference designである。AMD自身が完成ラックを一種類だけ販売するというより、OEM/ODMが製品化するための設計基盤に近い。 (Advanced Micro Devices, Inc.)
#構造は、
# Helios
18 × EPYC Venice
│
72 × MI455X
│
UALink / UALoE
│
Pensando Vulcano
│
Ethernet
│
他のHeliosとなる。
#つまりAMDは、
#- CPU
- GPU
- Scale-Up
- Scale-Out
- DPU/NIC
- Software
- Rack design
までを一つのsystemとして提供し始めた。
#これはNVIDIAがGrace/Blackwell/Rubinでやってきたことに非常に近い。
##
8．MIシリーズはRadeonとは何が違うのか
#AMDのconsumer GPUは主にRDNA。
#InstinctはCDNAである。
#目的が違う。
#Radeon / RDNA
#- graphics
- rasterization
- gaming
- display
- general GPU
Instinct / CDNA
#- matrix multiply
- BF16 / FP16 / FP8 / FP4
- HPC FP64
- HBM
- multi-GPU
- AI training / inference
MI300世代から特に目立つのは、演算量だけではなくHBM容量を猛烈に増やしていることである。
#MI300AではCPU・GPU・HBMのunificationまで実現した。 (AMD)
##
9．ROCmとCUDA
#NVIDIAの強さを「CUDA」と一言で呼ぶことが多いが、CUDAは単一の言語ではない。
#PyTorch / JAX / vLLM
│
↓
CUDA Runtime
│
┌─────┼──────────┐
cuBLAS cuDNN NCCL
│
TensorRT
│
NVIDIA GPUという巨大なソフトウェアplatformである。
#CUDA Toolkitにはcompiler、runtime、debug/optimization tools、accelerated librariesが含まれ、cuDNN、cuBLAS、NCCLなどがその上でAI計算を支えている。 (NVIDIA Developer)
#AMD側がROCmである。
#PyTorch / JAX / vLLM / SGLang
│
HIP
│
┌─────────┼────────┐
rocBLAS RCCL etc.
│
InstinctROCmはcompiler、runtime、librariesから構成されるopen-source GPU computing platformで、rocBLASやRCCLなどを含む。 (AMD ROCm)
#CUDAの優位は単なるAPIではなく、
#長年蓄積したkernel、library、profiling、開発者ノウハウ
#にある。
##
10．ROCm.ai――AMDはソフトウェア最適化をAI自身にやらせようとしている
#2026年、AMDはROCmの上にROCm.aiを展開し始めた。
#ROCm.aiではClaude、Codex、Cursorなどのcoding agentがAMD hardware/ROCmを理解し、GPU softwareの開発や最適化を補助する。 (Advanced Micro Devices, Inc.)
#これは非常にAMDらしい戦略である。
#CUDAとの差を、
#人間のエンジニアだけで何年もかけて埋める#
のではなく、
#AI coding agentを使ってAMD向けkernel optimizationを加速する#
のである。
#AMDとAnthropicがClaudeをROCm開発最適化にも利用し、OpenAIもTritonとROCmを組み合わせMI455X/Heliosを最適化すると発表していることも重要だ。 (Advanced Micro Devices, Inc.)
##
11．Dynamic VRAM――「VRAMを増やす」には複数の意味がある
#「Dynamic VRAM」「Unified Memory」という言葉は混同されやすい。
#少なくとも3種類に分ける必要がある。
#① Variable Graphics Memory
#Ryzen AI Max+ 395では128GB unified system memoryのうち最大96GBをgraphics memoryとして割り当てられる。 (AMD)
#ただしこれは、
#96GBのHBMを追加した#
わけではない。
#LPDDR系system memoryをCPU/GPUで共有している。
##
② MI300A型Unified HBM
#MI300AはCPUとGPUそのものが128GB HBM3を共有する。
#これはVGMより一段深い。
#CPU ─┐
├── 128GB HBM3
GPU ─┘である。 (AMD)
##
③ discrete GPUでのmemory oversubscription
#さらにdiscrete GPUでは、
#GPU HBM
↓
CPU DRAM
↓
NVMeへデータを退避することもできる。
#しかし、
#Address spaceが共通に見えること#
と、
#全メモリがHBMと同じ22TB/sで読めること#
は全く違う。
#ここが重要である。
##
12．そしてAMDはもう「HBMだけで解決する」設計ではない
#2026年7月、AMDは**AMD Infinity Context（AIC）**を公開した。
#これはKV cacheをGPU HBMの外へ逃がすための専用tierである。 (AMD ROCm Blog)
#AMDとMoonshot AIが構築したAgentic AI stackでは、さらにUMBP（Unified Memory & Bandwidth Pool）として、
#L1 GPU HBM
↓
L2 Host DRAM
↓
L3 Shared memory pool
↓
L4 SSDというmulti-tier KV cacheを構築している。 (AMD)
#つまりAMDの未来は、
#HBMを増やす#
か、
#CPU memoryへ逃がす#
かの二択ではない。
#両方をやる。
##
13．MI455X Helios vs Vera Rubin NVL72――GPU FLOPSを見ない比較
#両ラックの思想は、GPU性能を外して比較すると非常に面白い。
#AMD公式仕様とNVIDIA公式仕様を並べるとこうなる。 (AMD)
#特徴が非常にはっきりしている。
#AMD
#HBMを多くする。 Scale-Outを太くする。
#NVIDIA
#CPUを多くする。 CPUとGPUを密結合する。
#である。
##
14．HBMはAMDが50％多い
#MI455X：
#Rubin：
#なので、
#MI455XはRubinより50％多いHBMを持つ。
#72 GPUなら、
#Helios
#Rubin NVL72
#となる。
#推論ではこの差が大きい。
#HBMにはmodel weightsだけでなく、
#- KV cache
- activations
- communication buffer
- batch
- concurrent sessions
も入るからだ。
##
15．帯域差より容量差の方が大きい
#一方HBM bandwidthは、
#MI455X
#23.3TB/s
#Rubin
#22TB/s
#なので約6％差しかない。
#つまりAMDの特徴は、
#帯域を50％増やしたこと#
ではなく、
#ほぼ同じ帯域密度のまま、ローカルHBM容量を50％増やしたこと#
にある。
#decode-heavy inferenceや大KV cache、多数userを同時処理する場合にはかなり魅力的である。
##
16．CPUではNVIDIAが逆に非常に重い
#Vera Rubin NVL72は36 Vera CPU。
#Heliosは18 EPYC。
#つまり、
#NVIDIA
#2 GPU / CPU
#AMD
#4 GPU / CPU
#である。
#NVIDIAはVera CPUだけで3,168 Olympus coresと54TB LPDDR5Xをラックに載せ、GPUとNVLink-C2Cで結合する。 (NVIDIA)
#これはReasoning、RL、Agentを意識した設計と考えると非常に分かりやすい。
#AMDは反対に、強力なx86 EPYCを少ないsocket数で使い、GPU側へ大量HBMを与える。
##
17．Scale-Upは数字上ほぼ互角
#両方ともrack aggregateで約260TB/s。
#NVIDIA
#NVLink 6 / NVSwitch
#AMD
#UALink / UALoE
#である。 (AMD)
#ただしpeak bandwidthと実効bandwidthは同じではない。
#実際のAIでは、
#- AllReduce
- AllGather
- ReduceScatter
- Tensor Parallel
- Expert Parallel
- MoE routing
が走る。
#この効率はソフトウェアstackにも左右される。
#その意味では長い実運用実績を持つNVLink＋NCCLが現時点では有利と考えるのが無難である。
#一方AMDはRCCLのcollectiveをGPU copy engineへoffloadし、computeとcommunicationを重ねる機能まで進めている。 (AMD ROCm)
##
18．Scale-OutはAMDが非常に太い
#Helios：
#Rubin NVL72：
#なのでraw bandwidthではHeliosが約1.5倍。 (AMD)
#巨大MoEやmulti-rack inferenceではこれは重要である。
#ただしNVIDIAはSpectrum-X、ConnectX、BlueField、NCCLなどnetwork stackを垂直統合している。
#したがって、
#raw bandwidth：AMD#
ecosystem / optimization：NVIDIA#
という競争になる。
##
19．消費電力だけで単純比較してはいけない
#両社ともラック全体の最終消費電力はOEM構成、冷却、NIC、power shelfなどで変わる。
#したがって、
#Helios ○○kW vs Rubin ○○kW#
と一つの数字だけで断定するのは危険である。
#本当に見るべきなのは、
#である。
#NVIDIAはRubinについてBlackwell世代との比較で大幅なtokens/MW改善を主張しているが、これはAMDとの第三者比較ではない。 (NVIDIA Developer)
#AMDもHeliosについて、Vera Rubin NVL72を比較対象とした自社モデルで**最大30％高いinference tokens/$**を主張している。ただしKimi K2 Thinking、32K input / 8K output、推定GPU時間価格を使ったAMD Performance Labsのモデル値であり、中立的な実測benchmarkではない。 (Advanced Micro Devices, Inc.)
##
20．MFU――「GPU使用率100％」でもGPUは100％働いていない
#AIインフラでは「GPU utilization」という一つの数字を見るだけでは不十分である。
#例えば、
#GPU utilization 100％
HBM bandwidth 95％
Matrix unit active 35％なら、GPUは忙しく見えてもmemory-boundである。
#逆に、
#GPU utilization 100％
HBM bandwidth 45％
Matrix unit active 90％ならcompute-boundに近い。
#本当に見るべきなのは、
#- Matrix/Tensor unit utilization
- HBM bandwidth utilization
- occupancy
- interconnect utilization
- power utilization
- MFU
- TTFT
- ITL
- tokens/s
- tokens/s/W
- tokens/$
である。
##
21．PrefillとDecodeでも答えが変わる
#LLM inferenceには大きく、
#Prefill
#大量tokenをまとめてmatrix calculation
#Decode
#weightsとKV cacheを読みながらtokenを一個ずつ生成
#という異なる局面がある。
#Decodeは特にmemory-boundになりやすい。
#Google自身もIronwood上のQwen 3.5最適化で、decode-heavy workloadでは実性能がHBM bandwidth rooflineに強く近づくことを示している。 (Google Developers Blog)
#このためMI455Xの432GB HBMは、
#単に巨大モデルが入る#
以上に、
#大量のKV cacheとsessionを保持してGPUへ常に仕事を送り続ける#
という意味を持つ。
##
22．ASICならGPUより稼働率が高いのか
#必ずしもそうではない。
#ASICは特定workloadについて、
#- 不要回路を削る
- dataflowを固定する
- memory movementを最適化する
ことで高いperformance/Wを得やすい。
#Google TPUはその典型である。
#しかしworkloadが変則的になれば、
#MoE routing
branch
tool execution
CPU work
小batch
不規則sequenceなどで専用演算器が余る可能性もある。
#GPUは多少回路が余っても、softwareで用途を変えられる。
#今後のAI chip競争では、
#peak FLOPS#
より、
#実際のworkloadで何％の時間演算器を働かせ続けられるか#
が重要になっていく。
##
23．ここで一つの疑問が出る――なぜAMDはHBMを増やし、NVIDIAは減らそうとしているのか
#MI455X：
#Rubin：
#そしてMI500ではAMDは「next-generation memory」を明言している。 (Advanced Micro Devices, Inc.)
#一方NVIDIAについてTrendForceは8月4日、Rubin Ultraで当初の12-Hi HBM4Eだけでなく、
#- 8-Hi HBM4E
- 12-Hi HBM4
- 8-Hi HBM4
まで評価し始めたと報じた。
#さらにVera側のSOCAMM容量もLPDDR5X供給制約から削減する方向だという。最終HBM仕様はまだ決まっていない。 (TrendForce)
#一見すると矛盾している。
#世界的にDRAM/HBMが不足しているなら、なぜAMDだけ432GBも積めるのか。
##
24．答えの一つは「総生産量」
#ここで非常に重要な式が出てくる。
#である。
#例えば、
#AMD
#20万GPU × 12 HBM stacks
#NVIDIA
#170万GPU × 8 HBM stacks
#なら、
#一個当たりはAMDの方が多くても、
#総HBM消費ではNVIDIAが圧倒的に大きい。
#市場リーダーと挑戦者では最適戦略が違う。
##
25．NVIDIAは「一個を豪華にする」より「完成GPUを増やす」必要がある
#TrendForceによれば、Rubin Ultraで12-Hiから8-Hiへ減らした場合、目的の一つは限られたDRAM waferからより多くのGPUを出荷することである。 (TrendForce)
#同じ8 stackと仮定すれば、
#12-Hi
#DRAM dies
#8-Hi
#DRAM dies
#となる。
#つまり、
#GPU一個当たりDRAM dieを33％削減できる。
#他の制約を無視すれば、同じDRAM die量から、
#1.5倍のGPUへHBMを配れる。
#これは数百万GPUを作るNVIDIAには非常に大きい。
##
26．AMDはHBMを「差別化コスト」として使える
#一方AMDは市場シェアを取りに行く立場である。
#NVIDIAには、
#- CUDA
- NVLink
- ecosystem
- installed base
という理由がすでにある。
#AMDは、
#432GB HBM
+
高Scale-Out
+
open UALink
+
低tokens/$という明確な理由を作る必要がある。
#つまり余分なHBMは、
#AMDにとって市場シェア獲得のための投資#
とも考えられる。
#総GPU数量がNVIDIAより小さい限り、1GPU当たりHBMを贅沢に載せても、必要なHBM総量はNVIDIAより小さい。
##
27．MI500では576GB、768GBまで行くのか
#AMDが公式に発表しているのは、
#2027
#MI500 Helios 500 EPYC Verano Pensando Como / Monza
#2028
#MI600 Helios 600 EPYC Ferrara
#までで、MI500のHBM容量はまだ未発表である。 (Advanced Micro Devices, Inc.)
#ただしSamsungはHBM4Eについて、
#- 48GB 12-Hi
- 32GB 8-Hi
- 将来64GB 16-Hi
を公表している。 (Samsung Global Newsroom)
#仮にMI455Xのような12-stack級配置を維持できるなら、
#48GB × 12
#64GB × 12
#となる。
#これはAMDの発表仕様ではなく、HBM4E roadmapから見た技術的シナリオである。
#私は576GB級の方が768GBよりMI500には自然だと見る。
#16-Hiではstack height、yield、thermal、DRAM die消費量がさらに重くなるからだ。
##
28．しかしAMDは同時にHBM依存を減らす
#ここが重要である。
#AMD Infinity ContextやUMBPを見る限り、
#SRAM / Cache
↓
HBM
↓
Host DRAM
↓
Shared memory pool
↓
NVMe
↓
Distributed KV storeという階層化も同時に進む。 (AMD ROCm Blog)
#したがって、
#MI500はHBMを576GBへ増やすのか#
それともCPU memory/CXL/external KVを使うのか#
という問いは二者択一ではない。
#答えはおそらく、
#である。
##
29．CXLとUALinkは競合ではない
#将来のAMD systemでは、おおむね、
#UALink
#accelerator ↔ accelerator
#CXL
#CPU ↔ memory expansion / shared memory
#Ethernet/RDMA
#GPU ↔ remote KV/storage
#という役割分担が自然である。
#MI500 HBM
↕
UALink
↕
MI500 HBM
↓
EPYC
↕
DDR / CXL memory
↓
Pensando RDMA
↓
KV storage / NVMeとなる。
#そのためAMDもNVIDIAと同じく、単純な「VRAM容量競争」からmemory hierarchy競争へ移っていく可能性が高い。
##
30．FeynmanとMI500/MI600も同じ方向へ進む
#NVIDIAはRubin以降、Feynman世代へ進む。
#詳細仕様はまだ将来roadmapの段階だが、重要なのはNVIDIAも、
#- CPU
- GPU
- memory
- networking
- storage
- context memory
をAI Factory単位で設計していることである。
#AMDもMI500/MI600＋EPYC＋Pensando＋ROCm/AICを同じように統合する。
#したがって将来の競争は、
#MI500 GPU vs Feynman GPU#
ではない。
#AMD AI Factory
vs
NVIDIA AI Factory
vs
Google TPU Factory
vs
AWS Trainium Factoryになる。
##
31．そして最後にたどり着くのが「front-end wafer」
#ここまで来るとGPU性能より重要な制約が見えてくる。
#AI acceleratorを作るには、
#300mm wafer
↓
Front-End Logic Fab
N3 / N2
↓
完成logic wafer
↓
dicing
↓
Advanced Packaging
CoWoS / SoIC
↓
HBM
↓
substrate
↓
NIC / switch
↓
rackという工程が必要である。
#半導体の厳密な用語では、
#- FEOL＝transistor形成
- MOL
- BEOL＝metal interconnect
と分ける。
#一方、供給網分析でいう「front-end wafer capacity」は、しばしばadvanced packagingへ送る前のfoundry logic wafer能力全体という意味で使われる。
##
32．CoWoSが空いていてもlogic waferがなければ何も作れない
#以前AI半導体で最も有名なボトルネックはCoWoSだった。
#しかし、
#CoWoS capacity ↑しても、
#N3/N2 wafer不足ならGPUそのものが来ない。
#逆も同じ。
#さらにHBMを作るためにはSamsung、SK hynix、Micron側のDRAM front-end waferも必要である。
#したがってAI accelerator生産量は、
#で決まる。
##
33．HBMは特にwaferを大量消費する
#TrendForceによればHBM向けwafer投入は、主要DRAMメーカーの総DRAM wafer inputに対して、
#- 2025：約18％
- 2026：約22％
- 2027：約30％
へ上がる見込みである。
#一方HBMが占めるDRAM bit supplyは、
#- 2025：約8％
- 2026：約9％
- 2027：約13％
にすぎない。 (TrendForce)
#つまり2026年には、
#waferの22％を使ってbitの9％しか作らない#
ほどHBMはwafer-intensiveである。
#これは通常DRAMがHBMにcrowding-outされる理由でもある。
##
34．Google TPUが異常に見える理由
#SemiAnalysisの最新推計では、2026年のTPU v7 Ironwoodは、
#へ下方修正された。
#BroadcomのCoWoS wafer outputも、
#へ引き下げられたとされる。原因はCoWoS-S rampの難しさだという。 (データセンターのダイナミクス)
#それでも270万個である。
#Google公式仕様ではIronwoodは、
#を搭載する。 (Google Cloud Documentation)
#したがって、
#bit換算すると、
#となる。
##
35．Google TPUだけでRubinとほぼ同量のHBMを食う
#Rubinを180万GPUとすると、
#である。
#つまり偶然にも、
#となる。
#HBM bitではどちらも、
#である。
#Google TPU v7単独で、Rubin世代の年間HBM需要に匹敵する。
#これがGoogle TPUの数量が異常に見える理由だ。
#ただしNVIDIAにはBlackwellもあるので、Google TPUがNVIDIA全体を超えるという意味ではない。
##
36．2026年のNVIDIA出荷推計
#KeyBancの7月時点のsupply-chain推計では2026年に、
#- Rubin：170～180万
- Blackwell：550～600万
が見込まれている。これはNVIDIA公式出荷guideではなく、外部アナリスト推計である。 (Barron's)
#Rubinだけなら中心値175万として、
#である。
##
37．Blackwellを加えるとNVIDIAはまだ圧倒的
#Blackwellは製品mixによってHBMが192～288GB程度と大きく違う。
#したがって正確なHBM bit出荷量にはmix assumptionsが必要になる。
#ここでは、
#Low
#5.5M × 192GB
#Base
#5.75M × 平均240GB
#High
#6.0M × 288GB
#と置く。
#Rubinを足すとNVIDIA全体は、
#中心値、
#となる。
#これは出荷数量もBlackwell製品mixも外部推計に依存する分析値であり、NVIDIA公式値ではない。
##
38．AMDのHBM bit consumption
#Visible Alpha consensusを基にしたS&P Globalの分析では、AMD MI400 seriesは2026年に約25.8万基と推計されている。 (S&P Global)
#仮に全て432GB級MI455X相当として計算すれば、
#bit：
#である。
#さらにMI350/MI355X系も2026年に出荷されるため、AMD Instinct全体では私は、
#中心、
#程度を置く。
#後半部分はAMDがGPU数量を開示していないため、私のscenario estimateである。
##
39．AWS Trainium
#AWS Trainium3は公式に、
#- 144GB HBM3E/chip
- 4.9TB/s
を持つ。144個のTrainium3で20.7TB HBMのUltraServerを構成する。 (Amazon Web Services, Inc.)
#AmazonはTrainium2の累積deploymentが約140万chipに達したことを明らかにしており、Trainium3も既に量産へ移っているが、2026年年間新規出荷台数は公開されていない。 (Epoch AI)
#そこで本稿では2026年新規分について、
#中心約2.1Ebというscenarioを置く。
#ここはGoogle/NVIDIAより不確実性が高い。
##
40．Meta MTIA
#MetaはMTIA 300を既にproductionへ投入し、MTIA 400もGenAI向けに展開している。 (Meta AI)
#外部推計では2026年のMTIAが30～40万個程度とされる例がある。これはMeta公式数量ではないため低信頼度推定として扱う。 (X (formerly Twitter))
#216～288GB級HBMを仮定すると、
#中心約0.71Eb程度となる。
##
41．主要AI acceleratorの2026年HBM bit consumption
#以上を二重計上しないようにまとめる。
#レンジとしては、
#程度と見る。
#byte換算すれば、
#なので、
#のHBMが、主要AI acceleratorの2026年新規出荷分だけに載る計算になる。
#これはraw DRAM fab bitではなく、完成製品に搭載される有効容量換算である。yield lossなどを含む実際の製造bit量はさらに多い。
##
42．構成比
#中心推計23.7Ebなら、
#となる。
#ここで重要なのは、
#Google TPUだけで世界の主要AI accelerator向けHBMの2割弱#
まで来ている可能性があることだ。
#数年前の「TPU＝Google内部で使う特殊なチップ」というイメージではもう理解できない。
##
43．Broadcomは足してはいけない――二重計上になる
#ここで、
#NVIDIA＋AMD＋Broadcom＋Google＋AWS＋Meta#
を文字通り全部足すと問題が起きる。
#Google TPUはBroadcomが設計・供給を支援している。
#Meta MTIAもBroadcomとの共同設計である。BroadcomはGoogleとのTPU契約に加え、Metaの複数世代MTIAも手掛けている。 (The Motley Fool)
#したがって、
#Broadcom
+
Google TPUとすると同じHBMを二回数えてしまう。
##
44．Broadcom footprintとして別に見る
#Google TPU：
#Meta：
#なので、少なくともGoogle＋Metaだけで、
#のHBM bit consumptionにBroadcomが関与している可能性がある。
#中心値は、
#である。
#これはAMD全体の中心推定1.7Ebの、
#倍になる。
#しかもBroadcomにはOpenAIなど他のXPU customerも存在する。Broadcomは2026年第2四半期だけでAI semiconductor売上108億ドル、うちnetworking約40％、2027年AI semiconductor売上1000億ドル超を見込むとしている。 (The Motley Fool)
#HBM需要の源泉として見れば、Broadcomはすでに非常に大きい。
##
45．HBM/acceleratorだけを見ると真実を見失う
#一個当たりでは、
#なので、
#が圧倒的にmemory-heavyである。 (AMD)
#bit換算すれば、
#MI455X
#Rubin
#TPU v7
#である。
#MI455XはRubinの1.5倍、TPUの2.25倍のHBMを使う。
#しかし数量を掛けると逆転する。
##
46．一番重要な式
#AIメモリ市場を見るなら、
#で見る必要がある。
#さらにfront-end waferまで含めるなら、
#となる。
#この見方をすると、
#AMD
#1個をmemory-richにして差別化
#NVIDIA
#1個当たりmemoryを最適化しながら巨大volumeを出す
#Google/Broadcom
#ASICによってlogic wafer当たりの個数を増やし、数百万個を展開
#という3つの戦略が理解できる。
##
47．NVIDIAのHBM削減はHBM需要減少を意味しない
#例えば、
#旧構成
#100万GPU × 12 stacks
#新構成
#200万GPU × 8 stacks
#なら、1GPU当たりHBMを33％減らしても、
#HBM総需要は33％増える。
#TrendForceも2027年HBM bit shipmentについて前年比50～60％程度の成長を予想しながら、Rubin UltraのHBM configuration削減を報じている。つまり「per-GPU削減」と「HBM市場成長」は両立する。 (TrendForce)
##
48．Google TPUの本当に恐ろしいところ
#Google TPUが異常なのは単なるHBM需要量だけではない。
#ASICはワークロードを絞れるため、巨大なgeneral-purpose GPUとは違うdie economicsを作れる。
#しかもGoogle Ironwood自身が既にdual-chiplet architectureを採用しており、2つのchipletそれぞれが96GB HBMを持つ構造になっている。Google公式documentでも、この設計は製造効率とcost effectivenessを改善するためだと説明されている。 (Google Cloud Documentation)
#つまりGoogle TPUも、
#巨大monolithic ASICではなく、
#chiplet
+
chiplet
+
HBM
+
networkへ進んでいる。
#ここへ将来CPU chipletまで入れば、
#Vera Rubinと構造的にさらに似てくる。
##
49．GPUとASICの境界が消えつつある
#最終的には、
#NVIDIA
#CPU
+
programmable GPU
+
HBM
+
NVLinkGoogle/Broadcom/AMD
#CPU
+
custom XPU
+
HBM
+
D2DAWS
#CPU
+
Trainium
+
HBM
+
NeuronLinkとなる。
#違うのは「中央のacceleratorがどこまでprogrammableか」であり、
#システムarchitectureそのものは似ていく。
#これが今起きている最も大きな変化だと思う。
##
50．AMDにとってGoogle案件が本当なら何が最も重要か
#売上だけではない。
#AMDは、
#MI300A
#CPU＋GPU＋HBM
#↓
#MI455X
#3D/chiplet GPU＋大量HBM＋rack
#↓
#Google TPU案件
#他社ASIC＋CPU＋HBM＋advanced packaging
#という順で経験を積める可能性がある。
#その次に、
#MI500 / MI600
#自社CPU＋GPU/ASIC＋階層型memory
#へフィードバックできる。
#つまりGoogle TPUはAMDにとって、
#Vera Rubin型のCPU＋XPU融合技術をSemi-Custom市場で学ぶ場#
になる可能性がある。
#この意味では、仮にGoogle案件そのものの売上がAMD全体から見てそれほど大きくなくても、戦略価値はかなり高い。
##
結論――競争の単位が「GPU」から「AI Factory」へ変わった
#AMDとGoogle TPUの観測から始めると、最初は、
#なぜGoogleがAMDなのか#
という小さな疑問に見える。
#しかし調べていくと、それはもっと大きな構造変化につながっている。
#従来は、
#を競っていた。
#次に、
#になった。
#さらに、
#になった。
#そして現在は、
#を一つのAI計算機として設計する競争へ移っている。
#だからBroadcomはXPUにCPU coreを入れる。
#GoogleはTPUとCPUを近づける可能性を探る。
#NVIDIAはVeraとRubinをNVLink-C2Cで融合する。
#AMDはEPYC、Instinct、Pensando、ROCm、Heliosを一つにまとめる。
#そしてHBMも、
#GPUに何GB載っているか#
だけでは理解できなくなった。
#本当に見るべきなのは、
#である。
#2026年の公開情報と外部予測を組み合わせると、主要AI acceleratorだけで年間約20～28Eb、中心値約24Eb、約3EB相当のHBMを新規搭載する可能性がある。
#その中でGoogle TPU単独が約4.15Ebに達し、Rubin単独とほぼ同じHBM bitを消費する可能性があることは象徴的だ。
#一方NVIDIAはBlackwellまで加えれば依然として圧倒的だが、その巨大なvolumeゆえに、Rubin UltraではHBMやSOCAMMを減らしてでも完成GPU数を最大化する必要が出てくる。
#AMDは反対に、まだ相対的に小さいvolumeを利用して1GPU当たり432GBという大量HBMを与え、それを差別化要因にできる。
#そしてAMDのシェアが上がれば、AMD自身もいずれ同じ問題に直面する。
#だからMI500/MI600では、
#だけではなく、
#も同時に進む。
#HBM、CPU DRAM、CXL memory、NVMe、external KV cacheを階層化しながら、本当にhotなデータだけを最速memoryへ置く。
#これはNVIDIAもAMDもGoogleも最終的に向かっている方向である。
#AI半導体の次の競争は、
#誰が一番速いGPUを作るか#
ではなく、
#限られたlogic wafer、HBM wafer、CoWoS、電力、ネットワークから、最も多くの有効tokenを作れるAI Factoryを構築できるか#
になりつつある。
#そしてGoogle TPUの数百万個という規模は、その競争がすでに「NVIDIA対AMD」だけでは説明できない段階へ入ったことを示している。
#特定銘柄の推奨・勧誘・投資助言を目的とするものではありません。投資判断はご自身の責任でお願いいたします。
#