NOIA_GRIDKNOWLEDGE ARCHIVE
← KNOWLEDGE ARCHIVE

AI Factoryはどこへ向かうのか――演算器を待たせない巨大Memory Hierarchyの設計

元資料の日付 版 rev_cfe5b9e3-26a7-41f5-bf9e-934074846f04

AI半導体 メモリ AIインフラ・産業

絶ノイアの章 Sil-Kathnaの章
この資料の日時
元資料の日付
2026-08-09
公開日時
不明・未記録
原稿の作成日時
不明・未記録
原資料の更新日時
不明・未記録
分析基準日
不明・未記録
事象日
不明・未記録
本文版の公開存在確認
不明・未記録
アーカイブ記録日時
2026-09-08T16:29:04+00:00

元資料の日付と、その本文が公に存在した確認日時は別の記録です。

本文に含まれる語句 HBM DRAM SRAM 帯域・データ移動 先端パッケージング 光接続 電力・給電 冷却 チップレット AI推論

出典・更新履歴・検証情報

この保存版のデータを照合するための情報です。元記事の初公開日とは区別しています。

データセットの版
2026.09.23.4
記事内容のSHA-256
68b39591370b8e25f6917825bfdfcc2dc787b605b80d5ea7b3b57f4df5426a0c
保存版のSHA-256
8e43cf026e60b2dada09d097c9ec60aaef0a3de958564246011abda0e47cd819

外部証明の最終検査結果は詳細を開くと表示します。

公開版の履歴・検証方法 · 証拠ファイルを保存（本文・画像は別）

AI Factoryはどこへ向かうのか――演算器を待たせない巨大Memory Hierarchyの設計

#

演算能力ではなく「データをどこに置き、どう動かすか」がAIインフラを決める時代

#

AI半導体の未来を考えるとき、「GPUは何倍速くなるのか」「HBMは何GBになるのか」「光通信は銅線を置き換えるのか」と個別に予想しても、全体像は見えにくい。

#

より確実な方法がある。

#

まず、変えることのできない物理的制約を置く。

#

その上で、現在すでに量産されている技術、実証段階の技術、研究段階の技術を並べる。

#

すると、AI Factoryがどの方向へ進みやすいのかはかなり絞り込める。

#

結論から言えば、将来のAI Factoryは「すべてを光で接続した巨大なコンピュータ」にも、「HBMを無限に積み上げた巨大GPU」にもならない可能性が高い。

#

より自然なのは、

#
Locality where necessary+Optical distance where useful{\boxed{\text{Locality where necessary}+\text{Optical distance where useful}}}
#

という構造である。

#

演算器の直近にはSRAMとHBMを残す。

#

package内部は3D、hybrid bonding、silicon interposerなどの極端に短いelectrical connectionを使う。

#

packageを越え、rack、multi-rackへ距離が伸びるにつれてOptical Fabricの比率を増やす。

#

さらにその外側へDRAM、KV cache、SSD、object storageを階層化する。

#

そして、どのdataをどこへ置くかをsoftwareが動的に決める。

#

つまり未来のAI Factoryは、GPU clusterというより、

#

Data Center全体に広がった巨大なMemory Hierarchy

#

へ近づいていく。

#

AI性能を決めるものがFLOPSだけではなくなった

#

AI acceleratorはこれまで驚異的な速度で演算性能を増やしてきた。

#

低precision化によってFP16からFP8、FP4へ進み、Tensor Coreなどのmatrix engineも大型化した。

#

しかし演算器を増やせば増やすほど、別の問題が目立ってくる。

#

演算するdataが間に合わないのである。

#

GPUがいくら高速でも、

#

weightがHBMから届かない。

#

KV cacheが届かない。

#

別GPUにあるMoE Expertとの通信が終わらない。

#

collective communicationを待つ。

#

こうなればTensor Coreは停止する。

#

したがって実際の性能は、単純化すると、

#
Peffective≲min⁡(Pcompute,Pmemory,Pfabric,Ppower,Pthermal){P_{\mathrm{effective}}\lesssim\min\left(P_{\mathrm{compute}},P_{\mathrm{memory}},P_{\mathrm{fabric}},P_{\mathrm{power}},P_{\mathrm{thermal}}\right)}
#

になる。

#

最も弱い部分がsystem全体の性能を決める。

#

NVIDIA自身も現在のNVLinkを、MoE、disaggregated inference、dynamic resource allocationなどを含むAI Factory全体のscale-up networkとして位置付けており、NVLink 6ではGPUあたり最大3.6TB/s、rack levelで260TB/sのscale-up bandwidthを掲げている。 (NVIDIA Developer)

#

つまり競争単位はすでに「GPU単体」から外へ広がっている。

#

最初に残る物理法則――距離は消せない

#

未来のAI Factoryを考えるとき、最も重要な物理法則の一つが伝搬時間である。

#

光fiber中のsignal velocityはおおよそ、

#
v≈2×108 m/s{v\approx2\times10^8\ \mathrm{m/s}}
#

程度である。

#

したがって伝搬delayは、

#
t≈5 ns/m{t\approx5\ \mathrm{ns/m}}
#

程度になる。

#

10mなら約50ns。

#

50mなら約250ns。

#

100mなら約500nsである。

#

しかもこれは純粋なpropagation delayだけだ。

#

実際には、

#

E/O conversion、

#

O/E conversion、

#

switch、

#

SerDes、

#

protocol、

#

memory controller、

#

DRAM access

#

などが加わる。

#

つまり、

#
Remote MemoryをLocal HBMと同じlatencyにはできない{\boxed{\text{Remote MemoryをLocal HBMと同じlatencyにはできない}}}
#

という制約が残る。

#

光を使っても物理的距離そのものは消せない。

#

これだけでも、将来すべてのHBMをremote memoryへ置くarchitectureが不自然であることが分かる。

#

Local HBMが残る理由

#

Local HBMの価値は「容量が大きいこと」だけではない。

#

むしろ、

#

演算器に近い場所から巨大なbandwidthを供給できること

#

にある。

#

Remote DRAMを数十TB用意できても、GPUのすぐ横から供給されるHBMと同じlatencyとbandwidthでrandom accessできるわけではない。

#

そのため未来でも、

#
Tensor Core
     ↓
    SRAM
     ↓
 Local HBM
#

というhot pathは残る可能性が高い。

#

変化するのはHBMの役割である。

#

現在は「modelを置くmemory」という意味合いが強い。

#

将来は、

#

今使っているものだけを置くWorking Set Memory

#

へ純化していく可能性がある。

#

例えば、

#

現在使っているMoE Expert

#

active KV cache

#

activation

#

current batch

#

kernel workspace

#

などである。

#

逆に、

#

数時間前のKV

#

使用頻度の低いExpert

#

raw conversation

#

checkpoint

#

document archive

#

までHBMに置く必要はない。

#

AI Factory全体がCPUのCache Hierarchyのようになる

#

現在のCPUでは、

#
Register
 ↓
L1
 ↓
L2
 ↓
L3
 ↓
DRAM
 ↓
SSD
#

というmemory hierarchyを使う。

#

高速なmemoryほど小さく高価で、演算器に近い。

#

大容量memoryほど遠く遅い。

#

AI Factoryでは、この考え方がdata center規模まで拡張される可能性が高い。

#
Register
    ↓
On-chip SRAM
    ↓
Local HBM
    ↓
Nearby / Pooled DRAM
    ↓
Large Context / KV Tier
    ↓
NVMe SSD
    ↓
Object Storage
#

これは単なる容量拡張ではない。

#

必要になる確率に応じてdataを配置するarchitecture

#

である。

#

頻繁に使うものは内側へ。

#

再利用可能性の低いものは外側へ。

#

必要になる前に外側から内側へprefetchする。

#

使われなくなったらevictする。

#

その意味では未来のAI Factoryは、

#
巨大な分散Cache Computer{\boxed{\text{巨大な分散Cache Computer}}}
#

と表現した方が近い。

#

この構造はすでにSoftware側から始まっている

#

興味深いのは、physical optical memoryが完成する前からsoftware architectureが先にこの方向へ進んでいることである。

#

NVIDIA DynamoではLLM inferenceをPrefillとDecodeへ分離できる。

#

Prefill workerがpromptを処理してKV cacheを生成し、そのKVを別のDecode workerへ転送してtoken生成を続ける。

#

Dynamo自身、PrefillとDecodeではcompute characteristicsとmemory footprintが異なるため、別々のworker poolへ分離する利点を説明している。 (NVIDIA Docs)

#

さらに重要なのがKV Block Managerである。

#

Dynamo KVBMではKV cacheを、

#
GPU→Host DRAM→SSD→Object Storage{\text{GPU}\rightarrow\text{Host DRAM}\rightarrow\text{SSD}\rightarrow\text{Object Storage}}
#

という階層へoffloadできる。

#

現在のconfigurationではGPU、CPU、disk、object storageというtierが明示的に存在する。 (NVIDIA Docs)

#

つまり、

#

HBMから追い出したKVを低速memoryへ置き、必要なら戻す

#

という仕組みそのものは、すでに実装段階へ入っている。

#

将来Optical Fabricが入る場合、それはこのsoftware architectureをゼロから作り直すというより、

#

既に存在するmemory hierarchyのtransport layerを高速化する

#

方向になる可能性が高い。

#

PrefillとDecodeも同じXPUである必要がなくなる

#

LLM inferenceには大きく二つのphaseがある。

#

Prefillは長いpromptを一括して処理する。

#

大きなmatrix multiplicationを実行しやすく、比較的compute intensiveである。

#

Decodeは生成済みKVを参照しながらtokenを逐次生成する。

#

特にlow batchではmemory bandwidthへの依存が大きい。

#

したがって、

#
Prompt
  ↓
Prefill Worker
  ↓
KV Cache
  ↓
Fabric
  ↓
Decode Worker
  ↓
Output
#

と分離する合理性がある。

#

Dynamoではすでにこの構造が実装されており、KV transferはdisaggregated servingにおけるcritical pathの一つである。 (NVIDIA Docs)

#

ここから重要な帰結が出る。

#

将来のAI Factoryでは、

#

演算器を用途別に固定する必要さえなくなる可能性がある。

#

同じXPU群を、需要に応じて、

#

Training、

#

Prefill、

#

Decode、

#

Embedding、

#

Agent simulation

#

へ動的に割り当てる。

#

つまり「Prefill rack」「Decode rack」は必ずしも物理的な専用品を意味しない。

#

softwareから見たlogical poolになる可能性が高い。

#

MoEも「巨大Modelを全部動かさない」方向へ向かう

#

Mixture of Expertsでは、

#
Ptotal{P_{\mathrm{total}}}
#

と、

#
Pactive{P_{\mathrm{active}}}
#

を分離できる。

#

例えば20T parameterのmodelでも、1 tokenでactiveになるのが200Bなら、

#
PtotalPactive=100{\frac{P_{\mathrm{total}}}{P_{\mathrm{active}}}=100}
#

である。

#

model全体を毎token動かす必要はない。

#

しかしここで注意しなければならない。

#

「使うExpertだけremote storageから毎token読み込めばよい」と考えるのは現実的ではない。

#

仮に100B active parameterを4-bitで表現しても、

#
100B×48=50GB{100\mathrm{B}\times\frac{4}{8}=50\mathrm{GB}}
#

である。

#

100 token/sを出すために毎token 50GBをremote memoryから運べば、

#
50GB×100=5TB/s{50\mathrm{GB}\times100=5\mathrm{TB/s}}
#

が一requestだけで必要になる。

#

現実的にはExpert weightはどこかのXPUのHBMにresidentさせる。

#

そして送るのは主にweightではなく、

#

token activation

#

である。

#
XPU A
Expert A resident
      ↓
 token / activation
      ↓
Fabric
      ↓
XPU B
Expert B resident
#

になる。

#

つまり将来の「Expert Pool」は巨大なremote storageではなく、

#

多数のXPU/HBMに分散してresidentしているExpert群をlogicalに一つのpoolとして扱うarchitecture

#

になる可能性が高い。

#

Expertは「移動する」のではなく「複製される」

#

ただしExpert placement自体は固定である必要はない。

#

例えばcoding workloadが急増すれば、特定Expertへのtrafficが増える。

#

するとglobal schedulerは、

#

Expert A 1 copy

#

↓ demand ↑

#

Expert A1 Expert A2 Expert A3 Expert A4

#

のようにreplicateできる。

#

逆に使用頻度の低いExpertはcopy数を減らす。

#

つまりExpert weight movementは、

#

per-tokenの高速data pathではなく、秒～分、job開始時などの遅いcontrol plane

#

で起こると考える方が自然である。

#

この場合Optical Fabricは、

#

token/activation traffic

#

Expert migration

#

Expert replication

#

checkpoint

#

bulk transfer

#

を支える。

#

KV CacheはExpertよりも「Pooling」に向いている

#

KV cacheにはExpertとは違う性質がある。

#

KVはblock単位で移動しやすい。

#

PrefillからDecodeへ渡す明確なboundaryがある。

#

同じprefixを複数requestで再利用できる。

#

そのため、Remote Memoryの最初の大規模用途としては、

#

generic DRAM poolingよりKV poolingの方が自然

#

である可能性が高い。

#

2026年にはPhotonic-CXL Memory Applianceという研究も公開されている。

#

32TBのshared memoryを16 hostから利用するphotonic-CXL architectureを提案し、emulationではelectrical CXL poolに対するlatency改善、simulationではmulti-turn workloadのTTFT改善を報告している。ただし、これは商用fleet実績ではなくemulation/simulation中心であり、現時点ではarchitecture validationの段階である。 (arXiv)

#

同じ2026年にはCXL-hybrid memoryを使ったKV reuseの実機研究も進んでおり、TB級context stateをGPU HBMだけで保持しない方向そのものはかなり明確になっている。 (arXiv)

#

「Memoryを増やす」のではなく「再計算を減らす」

#

長時間Agentではこの問題がさらに重要になる。

#

数時間のAgent作業では、

#

conversation

#

source code

#

tool result

#

plan

#

checkpoint

#

user instructions

#

が累積する。

#

すべてをactive contextに残せばKVは増え続ける。

#

しかし全部を捨てればAgentは過去を忘れる。

#

そこで、

#
Active Context
     ↓
Structured State
     ↓
Compressed Memory
     ↓
Raw History
#

という階層が必要になる。

#

Active Contextには今必要なものだけ。

#

Structured Stateには、

#

Objective

#

Constraints

#

Done

#

Todo

#

Blocker

#

Current State

#

などを置く。

#

詳細な履歴はSSDやobject storageへ残す。

#

必要になればretrievalして再びcontextへ戻す。

#

つまり未来のAgent Memoryは、

#

Long Contextを無限化する技術ではなく、Long Contextを必要最小限に保つ技術

#

になる可能性が高い。

#

Optical FabricはこのMemory Hierarchyを物理空間へ広げる

#

ここでOptical Fabricが入る。

#

光の本当の価値は「光速だから高速」ということではない。

#

electrical signalも物質中をかなり高速で伝わる。

#

光の価値は、

#
Bandwidth×Distance×Energy{\mathrm{Bandwidth}\times\mathrm{Distance}\times\mathrm{Energy}}
#

のscalingである。

#

高data rateのelectrical linkは距離が伸びるほど、

#

insertion loss

#

equalization

#

retimer

#

SerDes power

#

cable volume

#

の問題が大きくなる。

#

光へ変換すれば、長距離部分でこのscalingを緩和できる。

#

そのため最も自然なのは、

#
On-die
 ↓
Hybrid Bonding
 ↓
2.5D / 3D
 ↓
Short Electrical Scale-Up
 ↓
Optical Scale-Up
 ↓
Optical Scale-Out
#

という距離階層である。

#

光は3D packagingを置き換えるのではなく、その外側へcomputerを拡張する。

#

現在のOptical Fabricはどこまで来たのか

#

ここは「光はまだ研究段階」という理解も、「もう全部光になる」という理解も正しくない。

#

成熟度が用途によって大きく違う。

#

まずdata centerのScale-Out opticsは完全に商用技術である。

#

さらにGoogleはOptical Circuit Switchをproduction networkで長期間利用している。

#

GoogleのJupiter networkでは約10年間のproduction experienceが報告され、OCSとsoftware-defined networkingを使ったarchitectureで5倍のspeed/capacity、30%のCAPEX削減、41%のpower削減を実現したと報告している。 (Google Research)

#

TPU v4 supercomputerでもOCSは2020年からdeploymentされており、Googleの論文ではOCSと関連optical componentがsystem costの5%未満、powerの3%未満だった。 (arXiv)

#

つまり、

#
大規模AI SystemでOptical Switchingが実用になるか{\boxed{\text{大規模AI SystemでOptical Switchingが実用になるか}}}
#

については、すでに実証済みと言ってよい。

#

CPOも「研究」から「量産」へ出ている

#

BroadcomのTomahawk 5 Baillyは51.2Tb/s CPO Ethernet switchであり、同社はBaillyを初のvolume-production CPO solutionと位置付けている。 (Broadcom)

#

2025年にはMetaのhigh-temperature lab characterizationで100万400G-equivalent port device hoursのflap-free operationが報告された。これはproduction fleetそのものの数字ではないが、CPOの長期信頼性評価がprototype段階を越えていることを示している。 (Broadcom)

#

NVIDIAも2026年5月にSpectrum-X Ethernet Photonicsをproduction入りさせたと発表している。

#

CPOと200Gb/s SerDesを使ったswitchで、million-GPU AI FactoryのScale-Out/Scale-Acrossを対象としている。 (NVIDIA Newsroom)

#

さらにTSMCはCOUPEを使ったtrue CPO on substrateを2026年にproduction開始予定としている。

#

TSMCはboard上のpluggable solutionとの比較で2倍のpower efficiencyと90%のlatency reductionを掲げている。これはTSMC自身の比較値だが、foundryのproduction roadmapへCPOが正式に入った意味は大きい。 (TSMC)

#

つまりswitch側CPOについては、

#
2026年は「実用になるか」ではなく「どこまで量産規模を広げるか」の段階{\text{2026年は「実用になるか」ではなく「どこまで量産規模を広げるか」の段階}}
#

に入っている。

#

XPU自身から光を出す技術は一段遅い

#

GPUやcustom XPU packageへOptical I/Oを直接integrateする技術は、switch CPOより成熟度が低い。

#

Ayar LabsのTeraPHYはUCIe compatible optical I/O chipletで、preliminary specificationでは8Tb/s bidirectional bandwidth、fiber time-of-flightを除いて10ns/chipletを掲げる。 (Ayar Labs)

#

2026年OFCではAyar LabsとWiwynnがoptically connected rackを展示しており、TeraPHYとremote laserをrack-scale AI systemへ組み込むdemonstrationまで進んでいる。 (Ayar Labs)

#

つまり現在地は、

#
Paper→Chiplet→Rack Demo{\text{Paper}\rightarrow\text{Chiplet}\rightarrow\text{Rack Demo}}
#

まで来ている。

#

しかしBroadcomのswitch CPOのようなlarge fleet production実績とはまだ距離がある。

#

業界がOptical Scale-Upの標準を作り始めた意味

#

2026年3月にはOptical Compute Interconnect MSAが設立された。

#

AMD、Broadcom、Meta、Microsoft、NVIDIA、OpenAIが創設メンバーとなり、AI Scale-Up向けopen optical specificationを作ろうとしている。

#

OCIはNRZとWDMを組み合わせ、module-centricからsilicon-centricなoptical architectureへの移行を目標としている。 (OCI MSA)

#

同時期、OCPではEthernet Scale-Up Networking 1.0が公開された。

#

lossless transport、credit-based flow control、link-level retry、小message向け低overhead headerなど、AI Scale-Upで必要となる機能をEthernetへ追加している。 (Open Compute Project)

#

これは重要なsignである。

#

業界の議論が、

#

光を使うべきか

#

から、

#

光Scale-Upをどのinterface、protocolで標準化するか

#

へ移ったことを意味する。

#

一方で、2026年に標準化が始まったという事実は、

#

XPU Optical Scale-Upがまだ成熟市場ではない

#

ことも意味する。

#

Optical Fabricにも「岸壁」がある

#

光は無限にscalingできるわけではない。

#

bandwidthを増やすには、

#

fiber数を増やす

#

wavelength数を増やす

#

wavelengthあたりdata rateを上げる

#

必要がある。

#

すると、

#

laser power、

#

wavelength stability、

#

thermal tuning、

#

insertion loss、

#

receiver sensitivity、

#

fiber connector density

#

が問題になる。

#

特に外部CW Laserを大量に使うarchitectureでは、laser自体がrack-level infrastructureになる。

#

Lightmatterは2026年、64 laserを一つの液冷Laser NICへ統合し、一moduleで51.2Tb/s、複数moduleで数百Tb/s級CPO scale-up bandwidthを支えるGuide DRを発表した。

#

同社がこれを「faceplate scaling bottleneck」への対策としていることは象徴的である。 (Lightmatter®)

#

つまり光へ移行すると、

#

Copper cable wall

#

は緩和するが、

#

Laser density wall、

#

Fiber handling wall、

#

Optical packaging wall

#

が現れる。

#

最大の難所は「光を出すこと」ではなく「大量生産すること」

#

現在の状況を見ていると、Optical Fabricの最大のtechnical uncertaintyは、

#

1本のlinkで何Tb/s出せるか

#

ではなくなりつつある。

#

むしろ難しいのは、

#

何十万、何百万laneを高yieldで生産し、長期間壊れず運用すること

#

である。

#

CPOでは、

#

Switch ASIC、

#

Photonic IC、

#

Electronic IC、

#

Laser、

#

Fiber Attach、

#

Connector

#

が一つのsystemになる。

#

単純化すればsystem yieldは、

#
Ysystem∼∏iYi{Y_{\mathrm{system}}\sim\prod_iY_i}
#

の影響を受ける。

#

一つ一つのcomponent yieldが99.9%でも、component数が膨大になればsystem-level failure managementが必要になる。

#

そのためBroadcomはCPO量産でwafer test、chip bonding、optical component attach、assembly、testの自動化を重要課題として挙げている。 (Broadcom)

#

NVIDIAもSpectrum-X Photonicsでcomponent pre-screening、detachable fiber connector、automated assemblyなどを強調している。 (NVIDIA Developer)

#

ここから分かるのは、

#
Photonicsの未来を決めるのはPhotonicsだけではない{\boxed{\text{Photonicsの未来を決めるのはPhotonicsだけではない}}}
#

ということである。

#

Packaging、test、mechanical engineering、automation、RASが同じくらい重要になる。

#

何十万GPUになると「故障しない」は設計目標にならない

#

AI Factoryを10万XPU規模へ広げたとする。

#

XPU。

#

HBM。

#

switch。

#

optical engine。

#

laser。

#

fiber。

#

SSD。

#

PSU。

#

pump。

#

部品数が膨大になる。

#

この規模では、

#
Failure is rare{\text{Failure is rare}}
#

という前提は使えない。

#

むしろ、

#
Failure is normal{\boxed{\text{Failure is normal}}}
#

としてarchitectureを作る必要がある。

#

GoogleがOptical Circuit Switchを利用してtopologyをreconfigureできる設計を長期間使ってきたのも、この考え方と非常に相性がよい。 (Google Research)

#

将来のOptical AI Factoryでは、

#

lane failure

#

laser failure

#

XPU failure

#

HBM failure

#

switch failure

#

が起きても、

#

reroute、

#

replicate、

#

checkpoint、

#

reassign

#

によってsystem全体を止めない必要がある。

#

つまりネットワークの速度以上に、

#

Resilience

#

が重要になる。

#

そして最も難しいのはGlobal Schedulerかもしれない

#

ここまでhardwareの話をすると、未来を決める最大の技術がOpticsに見える。

#

しかしsystem全体ではsoftwareの方が難しい可能性がある。

#

仮に10万XPUが存在するとする。

#

各XPUには、

#

resident Expert

#

free HBM

#

active KV

#

queue length

#

が違う。

#

さらにFabricには、

#

congestion

#

topology

#

failed link

#

がある。

#

requestにも、

#

latency requirement

#

context length

#

required model

#

available cached prefix

#

Agent priority

#

がある。

#

Schedulerはこれらを同時に見て、

#
Ttotal≈Tcompute+Tmovement+Tqueue{T_{\mathrm{total}}\approx T_{\mathrm{compute}}+T_{\mathrm{movement}}+T_{\mathrm{queue}}}
#

となる場所を選ばなければならない。

#

単純に「空いているGPUへ送る」では足りない。

#

「最速のGPU」より「dataが近いGPU」の方が速い場合がある

#

例えばGPU Aが空いている。

#

しかし必要なExpertもKVもない。

#

GPU Bは少し混雑している。

#

しかし、

#

Expert resident。

#

Prefix KV resident。

#

User state resident。

#

だったとする。

#

この場合、

#

Aへ大量dataを移してから処理するより、

#

Bへrequestだけ送った方が速い可能性がある。

#

つまり将来のroutingは、

#
Compute-centric{\text{Compute-centric}}
#

ではなく、

#
Data-locality-centric{\boxed{\text{Data-locality-centric}}}
#

になる。

#

これはdistributed databaseやCDNにかなり近い。

#

AI Factoryは「ComputeへDataを送る」だけではなくなる

#

従来の発想では、

#
Data
 ↓
GPU
#

だった。

#

未来は、

#
Request
 ↓
DataがあるGPU
#

という選択も増える。

#

つまり、

#

DataをComputeへ持っていく

#

だけでなく、

#

Compute requestをDataへ持っていく

#

ようになる。

#

これは莫大なFabric trafficを抑える非常に重要な方法になる。

#

最も高速なData Movementは「移動しないこと」

#

ここからもう一つ重要な原則が導かれる。

#

Optical Fabricを100倍速くするより、そもそも100分の1しか送らない方が強い場合がある。

#

そのためalgorithm側でも、

#

GQA、

#

MLA、

#

KV quantization、

#

Context compression、

#

MoE、

#

Sparse attention、

#

prefix caching

#

などが重要になる。

#

例えばKV sizeを半分にできれば、必要なFabric bandwidthも半分になる。

#

weightを8-bitから4-bitにすれば、bulk migration量も半分になる。

#

同じprefix KVを1000人でshareできれば、1000回Prefillする必要がない。

#

したがって未来のAI Factoryで最も価値のあるbyteとは、

#
送らなかったByte{\boxed{\text{送らなかったByte}}}
#

である。

#

Optical Fabricの進歩とalgorithmic compressionは競合ではない。

#

両方が同時に必要になる。

#

AI Factoryの物理的な完成形

#

これらの制約を全部積み上げると、最も自然なarchitectureは次のようになる。

#
AI RUNTIME
                           │
                    Global Scheduler
                           │
          ┌────────────────┼────────────────┐
          │                │                │
    Expert Router     Memory Router      Planner
          │                │                │
          └────────────────┼────────────────┘
                           │
                  Compute / Request Pool
                           │
           ┌───────────────┴───────────────┐
           │                               │
        XPU Group                       XPU Group
           │                               │
         SRAM                            SRAM
           │                               │
      Local HBM                       Local HBM
   Active Experts                    Active KV
           └───────────────┬───────────────┘
                           │
                  Dense Scale-Up Fabric
                           │
                    Optical Layer
                           │
     ┌─────────────────────┼─────────────────────┐
     │                     │                     │
 Other XPU HBM          Shared DRAM            CPU Pool
Resident Experts        Warm KV               Tools
     │                 Prefix Cache           Database
     └─────────────────────┼─────────────────────┘
                           │
                        NVMe SSD
                           │
                     Object Storage
                           │
             History / Files / Checkpoints
#

重要なのは中央に巨大な「remote memory」が一個あるわけではないことである。

#

Memoryは何層にも分かれる。

#

XPUも何種類にも分かれる。

#

Optical Fabricはその間を必要に応じて接続する。

#

物理的には「完全分離型」より「階層型」が自然

#

未来のdata centerを、

#

Compute Box、

#

Memory Box、

#

Storage Box

#

へ完全分離して全部光で接続する姿として描くこともできる。

#

しかし物理法則から考えると、おそらく極端すぎる。

#

Localityには圧倒的価値がある。

#

Remote accessには必ずlatencyがある。

#

Fabricにはcongestionがある。

#

connection pointを増やせばfailure pointも増える。

#

そのため、

#

Hot Resourceは強く統合する。

#

Cold Resourceだけdisaggregateする。

#

方が自然である。

#
Tightly Integrated
     ↓
#

Compute SRAM HBM

#

↓

#

Fabric

#

↓

#

DRAM KV Pool SSD Object Storage

#
↓
Loosely Coupled
#

となる。

#

Packageそのものもさらに巨大化する

#

Optical Fabricが伸びるからといって、Local packageの大型化が止まるわけではない。

#

TSMCは現在5.5-reticle CoWoSを生産中で、2028年には14-reticle sizeへ拡大し、約10個の大型compute dieと20 HBM stackを統合する計画を示している。

#

2029年にはさらに14 reticle超、40-reticle SoW-Xを予定している。 (TSMC)

#

つまりindustryは、

#

Localityを諦めてRemoteへ逃げる

#

のではない。

#

Localityを物理限界まで巨大化したうえで、その外側をOpticalで拡張する。

#

この二つは同時に進む。

#

つまり3DとOpticsは一つの同じ流れである

#

近距離では、

#

Hybrid Bonding。

#

SoIC。

#

CoWoS。

#

HBM。

#

遠距離では、

#

CPO。

#

Optical I/O。

#

Fiber。

#

これは別々のtechnology trendではない。

#

共通する目的は、

#
Data Movement Costを距離ごとに最小化する{\boxed{\text{Data Movement Costを距離ごとに最小化する}}}
#

ことである。

#

数µmならhybrid bonding。

#

数mmならinterposer。

#

数cmならpackage/board electrical。

#

数m以上ならOptics。

#

というように、距離ごとに最適なtransport technologyを使う。

#

Optical Scale-Upが大きく立ち上がる時期

#

現在のtechnology maturityを見ると、段階的に進む可能性が高い。

#

2026年はSwitch CPOのproduction化とOptical Scale-Up標準化が重なった年と見ることができる。

#

Broadcomはvolume-production CPOを持ち、NVIDIA Spectrum-X Photonicsもproductionに入り、TSMC COUPEもproduction開始予定である。 (Broadcom)

#

一方、XPU Optical I/Oはrack demo、chiplet、prototypeから初期商用化へ向かう段階である。

#

MarvellはCelestial AI買収に際し、Photonic Fabricからのmeaningful revenue contributionをFY2028後半から見込んでいる。 (Marvell Technology, Inc.)

#

このことから、

#
2027～2029年{\boxed{2027\text{～}2029\text{年}}}
#

がmulti-rack Optical Scale-Upの大きな転換期間になる可能性が高い。

#

その次にKV、Memory Poolが来る

#

Optical XPU-to-XPU communicationの方が、generic remote memoryより先に実用化する可能性が高い。

#

理由はremote memoryの方がsoftware semanticsまで変える必要があるからである。

#

Memoryには、

#

ordering、

#

consistency、

#

fault handling、

#

addressing、

#

page/block management

#

などが必要になる。

#

そのためMemory Poolの初期用途は、

#

arbitrary byte-addressable DRAM

#

ではなく、

#

KV block

#

prefix cache

#

tensor

#

Expert shard

#

checkpoint

#

のような明示的な大きなobjectになる可能性が高い。

#

2026年にすでにKV cache向けPhotonic-CXLやCXL-hybrid memoryの研究が相次いでいることも、この方向性を示している。 (arXiv)

#

本格的なShared KV Tierは2029～2031年前後、より汎用的なcomposable memoryはその後になる可能性が高い。

#

これは予測であり確定したroadmapではないが、現在の成熟度差から見ると自然な順序である。

#

それでも2030年に「全部完成」する必要はない

#

重要なのは、未来像が一日に切り替わるわけではないことである。

#

2030年頃にはfrontier hyperscalerで、

#

Prefill/Decodeの論理分離

#

KV-aware routing

#

Local HBM

#

Distributed resident Expert

#

Optical multi-rack scale-up

#

Warm KV tier

#

NVMe/object storage context tier

#

Global locality-aware scheduler

#

が組み合わさっている可能性はかなりある。

#

一方でgeneric remote memoryや完全なcross-vendor optical composabilityは2030年代前半まで発展途中でも不思議ではない。

#

つまり進化は、

#
GPU Cluster
 ↓
Rack-scale Computer
 ↓
Multi-rack Scale-Up
 ↓
Hierarchical Memory AI Factory
 ↓
Composable AI Factory
#

と段階的に進む可能性が高い。

#

最後まで残るのはPowerとHeat

#

どれほどsoftwareとopticsを改善しても、最後にenergy conservationから逃げることはできない。

#

dataを動かすにはenergyが必要である。

#

transistorをswitchすればheatになる。

#

laserもpowerを使う。

#

photodetector、TIA、SerDes、switch ASICもpowerを使う。

#

そのためAI Factoryの規模は最後には、

#
Available Electrical Power{\text{Available Electrical Power}}
#

と、

#
Heat Removal Capacity{\text{Heat Removal Capacity}}
#

にも制限される。

#

したがって将来の最重要指標は、

#
FLOPS{\mathrm{FLOPS}}
#

だけではなく、

#
Tokens/Joule{\mathrm{Tokens/Joule}}
#
Useful Work/Joule{\mathrm{Useful\ Work/Joule}}
#

へ近づいていく。

#

AI Factoryの勝者を決めるもの

#

未来の競争では、「一番速いGPUを持っている企業」が必ず勝つとは限らない。

#

仮にGPU Aが100のpeak性能を持っていても、

#

memory stall、

#

Expert communication、

#

KV transfer、

#

network congestion

#

で60%しか使えなければ、

#
100×0.6=60{100\times0.6=60}
#

である。

#

GPU Bのpeak性能が80でも、90%利用できれば、

#
80×0.9=72{80\times0.9=72}
#

になる。

#

つまり、

#
Useful Compute=Peak Compute×Utilization{\boxed{\text{Useful Compute}=\text{Peak Compute}\times\text{Utilization}}}
#

である。

#

そのため将来の競争力には、

#

GPU architectureだけでなく、

#

HBM、

#

Packaging、

#

Optics、

#

Network、

#

Compiler、

#

Runtime、

#

Scheduler

#

がすべて含まれる。

#

NVIDIAがRubinをGPU単品ではなくVera CPU、Rubin GPU、NVLink switch、ConnectX、BlueField、Spectrum switchを一体のAI supercomputerとして展開しているのも、この方向を表している。 (NVIDIA Newsroom)

#

Google Ironwoodも最大9,216 TPUをICI、Optical Circuit Switch、DCN、HBM、XLAまで含むholistic systemとして設計している。 (Google Cloud)

#

つまり企業側の製品設計自体が、すでに「chip競争」から「system競争」へ移っている。

#

AI Factoryは「巨大な脳」より「巨大な記憶・交通システム」に近い

#

AIを人間の脳に例えることは多い。

#

しかしAI Factoryのhardware architectureを理解するなら、むしろ巨大都市に近い。

#

XPUが工場。

#

HBMが工場の作業台。

#

DRAMが近隣倉庫。

#

SSDが巨大物流倉庫。

#

Object Storageが長期保管庫。

#

Fabricが道路。

#

Optical Fabricが高速鉄道。

#

Schedulerが交通管制。

#

Model Routerが「どの専門工場で作るか」を決める。

#

Memory Routerが「必要な資料がどの倉庫にあるか」を決める。

#

重要なのは、すべての物を最高速鉄道で毎回運ぶことではない。

#

頻繁に使うものを最初から工場の隣に置くこと

#

である。

#

これがLocalityである。

#

物理法則から見れば、進む方向はかなり絞られている

#

将来の具体的なproduct名を予想することは難しい。

#

しかし物理制約から方向を推定することはできる。

#

Computeは今後も増える。

#

するとMemory bandwidth需要が増える。

#

HBMだけでは容量costが高くなる。

#

そこでMemory hierarchyが深くなる。

#

XPU数が増える。

#

するとScale-Up bandwidthが増える。

#

銅のdistance・energy・cablingが問題になる。

#

そこでOpticalがXPUへ近づく。

#

Optical Fabricが高速化する。

#

するとRemote Resourceを使いやすくなる。

#

しかしpropagation latencyは消えない。

#

そこでLocal HBMは残る。

#

Remote accessのlatencyが残る。

#

そこでPrefetchとLocality-aware schedulingが重要になる。

#

XPU数が増える。

#

するとfailureが日常になる。

#

そこでrerouting、checkpoint、replicationが必要になる。

#

つまり一つの制約を置くと、次に必要なtechnologyがかなり自然に導かれる。

#

そして最終的にAI Factoryは「一台のComputer」に見えるようになる

#

物理的には、

#

数万XPU、

#

何PBものHBM/DRAM、

#

大量のSSD、

#

何kmものfiber

#

から構成されていても、

#

softwareからは、

#

model.generate()

#

のような一つのlogical acceleratorに見えることが理想である。

#

内部では、

#

どのXPUを使うか。

#

どのExpertを使うか。

#

KVがどこにあるか。

#

どのFabric pathを使うか。

#

何をprefetchするか。

#

どこにcheckpointを置くか。

#

をruntimeが自動的に決める。

#

Cloud computingがphysical serverを抽象化したのと同じように、

#

次は、

#

AI hardware topologyそのものがsoftwareに抽象化される

#

可能性が高い。

#

結論――未来のAI Factoryとは「演算器を待たせないための機械」である

#

AI Factoryについて考えるとき、最も重要な問いは、

#

GPUはいくつあるのか

#

ではない。

#

HBMは何GBあるのか

#

だけでもない。

#

Optical bandwidthが何Pb/sあるのか

#

でもない。

#

本当の問いは、

#
演算器が次に必要とするDataを、演算器が待つ前に届けられるか{\boxed{\text{演算器が次に必要とするDataを、演算器が待つ前に届けられるか}}}
#

である。

#

そのためHot DataはLocal HBMへ置く。

#

Cold DataはSSDへ置く。

#

Expertは使用するXPUのHBMへresidentさせる。

#

KVはreuseする。

#

必要Memoryだけretrieveする。

#

次に必要なものをprefetchする。

#

dataがある場所へrequestを送る。

#

遠距離だけOptical Fabricを使う。

#

故障すればrerouteする。

#

そしてこれらすべてをGlobal Schedulerが管理する。

#

この構造から見ると、Optical FabricはAI Factoryの主役であると同時に、万能解ではない。

#

光の本当の役割は、

#

Localityを捨てることではなく、Localityでは届かなくなった場所までComputerを拡張すること

#

である。

#

だから未来は、

#

「HBMかOptical Memoryか」

#

「3DかOpticalか」

#

「LocalかRemoteか」

#

という二択にはならない。

#

むしろ、

#
SRAM→HBM→DRAM→Flash{\boxed{\text{SRAM}\rightarrow\text{HBM}\rightarrow\text{DRAM}\rightarrow\text{Flash}}}
#

というmemory hierarchyと、

#
On-die→3D→2.5D→Electrical→Optical{\boxed{\text{On-die}\rightarrow\text{3D}\rightarrow\text{2.5D}\rightarrow\text{Electrical}\rightarrow\text{Optical}}}
#

というdistance hierarchyを重ね合わせたsystemになる。

#

この二つをSoftwareが動的に制御する。

#

そこまで進んだとき、Data Centerは「大量のGPUが置かれた建物」ではなくなる。

#

建物全体が一台のComputerになる。

#

そしてAI半導体競争の中心は、最も大きなchipを作ることから、

#

最も巨大な計算機を、あたかも一枚のchipのように効率よく動かすこと

#

へ移っていく。

#

さらに深く読むための座標

#

AI Factoryの完成度は、最大帯域ではなく、仕事ごとに最適な場所へComputeとDataを寄せ、再計算・移動・待機の総量を減らせるかで測るべきである。

#
層観測対象問うべきこと
Data planetoken、KV、activation、collective通信μs以下の遅延と安定帯域
Control planeExpert複製、配置変更、checkpoint秒～分単位の予測と再配置
Failure plane故障検出、迂回、再開、交換巨大規模で止まらない運用
#
絶ノイア

絶ノイアの観測

#

最速のGPUを空いている場所へ探しに行くより、必要なDataの近くへ仕事を送る方が速い瞬間が増えます。計算資源の地図が、Schedulerの内側へ入ってきます。

#

私は「Data plane」「Control plane」「Failure plane」を別々の話題にせず、一つのAIインフラが通過する連続した設計課題として観測します。

#

Peak性能ではなくEffective利用率を見る。発表された最大性能や市場規模だけでなく、実装、量産、運用が同じ速度で前進しているかを確かめたいからです。

#
Sil-Kathna

Sil-Kathnaの記録

#

道を渡る荷を減らし、荷のある倉へ使者を送れ。動かぬこともまた、最速の移動である。

#

私は「Data plane」「Control plane」「Failure plane」を、計算する文明へ続く三つの門として石板に刻む。

#

最初の門だけが開いても、次の門に熱、傷、遅れが残れば、光と記憶は炉心へ届かない。強い器とは、最も華やかな石を持つ器ではなく、異なる工房の歩調を長い夜の中で揃えられる器である。

#

ゆえに私は、Peak性能ではなくEffective利用率を見る。その結果が一時の輝きではなく、繰り返し作り、直し、動かせる秩序になったかを見届ける。

#

二人の短い対話

#

絶ノイア: 将来のTopologyは利用者から隠れますが、Schedulerには今より鮮明に見えていなければならない。

#

Sil-Kathna: 見えぬ都市を動かすには、すべての門と熱と傷を記した地図が要る。

#

観測メモ

#
  • Peak性能ではなくEffective利用率を見る
  • KV PoolingとExpert配置を別の時間軸で設計する
  • 電力・冷却・保守性をFabric設計の外部条件にしない
#

免責

#

この記事は市場観測とAIによる考察、キャラクター表現を含みます。内容は投資助言ではありません。数値、企業計画、将来見通しには不確実性があり、判断は必ず一次情報とご自身の状況にもとづいて行ってください。

#
記事の記述・図・出典の対応を保持しています。引用には記事URLと段落リンクを添えられます。再利用の条件を確認する →