LLM 推論サーバーの中身：HBM 同士が話している

俺の最初の疑問

Claude みたいな LLM が動いている場所、結局どんなサーバーやネットワークの上で動いてるんや？ 「Linux + Kubernetes やろ」というのはわかる。けど、その下の物理層、サーバー筐体やネットワークのハードがぼんやりしてる。

まず一言でいうと

LLM 推論サーバーの設計思想は 「HBM ↔ HBM ですべて完結させる」 こと。

GPU の中、同一サーバー内の GPU 間、別サーバーの GPU 間、どのスケールで切っても、実際に動いているのは HBM 同士の通信。CPU と DRAM はホットパスから外されている。

「LLM サーバーの中で何が起きているか」と問うと、答えは大半 HBM が他の HBM と話している、これに尽きる。

何と比べるとわかるか

普通のサーバーと LLM 推論サーバーは、データの主役からして違う：

	普通の Web サーバー	LLM 推論サーバー
主なメモリ	CPU の DRAM	GPU の HBM
データの居場所	DRAM に常駐	HBM に常駐
CPU の役割	計算もデータ移動も全部やる	起動指示だけ。実行は GPU 側
ホットパスを通る経路	CPU ↔ DRAM ↔ NIC	HBM ↔ NVLink / NIC ↔ HBM
サーバー間通信	TCP / IP over Ethernet	RDMA over InfiniBand

LLM サーバーは「CPU 中心のコンピュータ」ではなく、「HBM をいかに動かさないか」を最優先に作られた特殊な機械として見ると、構造が腑に落ちる。

何が問題なのか

LLM 推論は 数百 GB のモデル重みを、リクエストごとに何度も読みながら計算する 作業。

このとき重みは GPU の HBM に乗っている。もし計算のたびに重みを CPU の DRAM や別の場所に運んでいたら、メモリ帯域がボトルネックになって計算ユニットが遊んでしまう (前回 HBM 記事で扱った「メモリの壁」と地続き)。

そこで、

• 重みは HBM から動かさない (GPU 内に常駐)
• GPU 間で必要なデータも HBM ↔ HBM で直接運ぶ (CPU 経由しない)
• CPU は計画と起動指示だけ出し、あとはホットパスから外れる

この設計を成立させるために、サーバー筐体の中にも外にも特殊な仕掛けが要る。

図で見る

まず LLM 推論サーバー 1 台の内部構造：

次に「HBM ↔ HBM」というパターンが、GPU 内・サーバー内・サーバー間の 3 スケールを貫いている構造：

混乱しやすいポイント

① GPU は独立したコンピューターではない

GPU は「サーバー」ではなく「サーバーに挿す部品」。電源も Linux もない。CPU 上で動く Linux がドライバを読み込んで、初めて使える状態になる。

ゲーミング GPU と違って、データセンター用 H100 は 映像出力端子が物理的についていない。Linux からは VGA compatible controller ではなく 3D controller として認識される。実体は「画面のない並列計算機」。

② NVLink は GPU 内蔵端子、NVSwitch は独立チップ

	LLM サーバー内	通常のネットワーク
端末側の口	NVLink (GPU 内蔵)	NIC (差し込む)
スイッチ	NVSwitch (チップ)	Ethernet switch (機器)
配線	PCB の銅トレース	LAN ケーブル
帯域	約 900 GB/s	1〜400 Gbps

サーバー内に「もう一本の超高速・短距離専用ネットワーク」が走っている、と見ると正確。

③ PCIe は遅いが、ホットパスを通らない

NVLink (約 900 GB/s) に対し PCIe 5.0 x16 は約 128 GB/s で、約 1/7。本来ならボトルネックだが、計算中は CPU を経由しないので問題になりにくい。

PCIe を通る場面は限定的：

• ユーザートークン入出力 (数 KB)
• モデルロード時 (起動時のみ)
• サーバー間通信 (NIC が PCIe にぶら下がるため)

④ サーバー間通信は PCIe を通るが、CPU は通らない

サーバー A の GPU0 → サーバー B の GPU0 への経路：

GPU0 → PCIe → NIC → InfiniBand → NIC → PCIe → GPU0

PCIe は両端で通る。ただし GPUDirect RDMA により、NIC は GPU の HBM を PCIe BAR 経由で直接 DMA できる。CPU と DRAM はバイパスされる。

「PCIe を通る」と「CPU を通る」は別物、というのが大事な区別。

⑤ 命令系統は 3 層分業

「GPU0 の HBM から GPU1 の HBM にデータを送れ」と CPU が毎回命令しているわけではない：

レイヤ	担当	役割
戦略	PyTorch などのフレームワーク	「この勾配を all-reduce しろ」など
実装	NCCL	通信パターン (リング型など) を起動時に計画
実行	GPU のコピーエンジン + NVLink / NIC	実際のバイト転送

CPU は起動時のセットアップと「行け」というカーネル発射だけ。実際のデータ移動は GPU 内の コピーエンジン (SM とは別の専用 DMA 回路) が、NVLink や NIC を直接駆動する。

たとえ話

GPU を「工場のある都市」と見るとわかりやすい：

• SM (計算ユニット) = 工場
• HBM = 倉庫 (材料置き場)
• NVLink = 都市間の高速道路
• NVSwitch = 高速道路のジャンクション
• DMA エンジン / NIC = トラック
• CPU = 配車計画を立てる本社 (日々の運送には関与しない)

工場 (SM) は自分の都市の倉庫 (HBM) からしか材料を取れない。他都市の材料が必要なら、まずトラック (DMA / NIC) が高速道路 (NVLink / InfiniBand) で運んできて、自分の倉庫に下ろす。本社 (CPU) は当日の運送一つひとつには口を出さない。

最新世代の動き

NVIDIA は「サーバー」という単位そのものを再設計する方向にも進んでいる：

• GB200 NVL72：1 ラックに 72 GPU を NVLink で接続。NVSwitch をベースボードから外して別トレイ (9 個) にし、銅ケーブルで NVLink をラック内に延伸する設計
• Grace Hopper / GB200 superchip：CPU と GPU の間も PCIe をやめて NVLink-C2C (約 900 GB/s) で直結

どちらも「HBM が主役」の設計を、より広い範囲に広げようとしている動き、と読める。

ニュースを読むための変換表

ニュースの言葉	つまり何の話？
DGX H100	H100 を 8 枚搭載した NVIDIA 純正サーバー
HGX H100	DGX の中身にあたる、GPU 8 枚 + NVSwitch のベースボード
NVLink	GPU 同士をつなぐ専用高速バス
NVSwitch	NVLink を全対全につなぐスイッチチップ
InfiniBand	サーバー間で使う低遅延・高帯域ネットワーク (Ethernet と別系統)
RDMA / GPUDirect RDMA	CPU を介さないメモリ間通信。NIC が GPU の HBM を直接 DMA する
NCCL	GPU 集団通信を実装する NVIDIA ライブラリ
GB200 NVL72	Blackwell 世代の 72 GPU ラックスケール構成
Grace Hopper / GH200	Grace CPU + Hopper GPU の superchip
NVLink-C2C	CPU と GPU を NVLink で直結する技術 (PCIe を置き換える)

深掘りメニュー 次におすすめのトピック

この記事の続きとして、未来の自分が次に掘るといいトピック。

• CPU の役割 (ホットパス外) ── 主役を外れた CPU が結局何のために載っているか。サーバーの全体像が締まる。
• 学習側のサーバー構造 ── 数千〜数万 GPU を 1 ジョブで回す学習。今回の推論向け構造とどう違うか。
• InfiniBand と Ethernet の違い ── なぜ学習では Ethernet では足りないか。GPU 間ネットワークの核心。
• NVL72 など新世代 ── 72 GPU を 1 台のように束ねる世代を、運用・K8s 側がどう扱うか。
• Kubernetes から見た GPU サーバー ── 8 枚 = 1 ノード？ k8s 記事の DevicePlugin と直結する入口。