DGX Spark 統合メモリ運用
教科書 第2巻（実践編）

層1物理層 ── 帯域を売って容量を買った設計

GB10の統合メモリはLPDDR5X公開で、メモリ帯域は約273GB/s公開。HBM搭載のデータセンターGPUより桁で狭い代わりに、CPU/GPU共有の128GB（実使用可能121.7GB実測)という容量を得ている。CPUとGPUはNVLink-C2C公開で結合され、単一の物理メモリプールを共有する。

この取引 ──「帯域を売って容量を買う」── が本書の全事象の物理的前提である。容量があるから72Bクラスが載る。帯域が狭いからdecode（1トークン生成のたびにKVキャッシュ全体とモデル重みを読み直す工程）が律速になる。32Bの単流生成10.7 tok/s実測、72Bの約5 tok/s実測という観測はこの帯域の直接の帰結であり、後述の「RAG遅延の犯人はKV不足ではなく生成速度」（系統5）の物理的根拠でもある。

そしてもう一つ ── dGPUの時代にVRAMとホストRAMを隔てていた物理的な壁が、この設計では存在しない。推論サーバの暴走とデータベースの暴走が同じ床で起きる。壁の消失は層2以降のすべての事故の舞台装置である。

層2OS/ドライバ層 ── 同一のページアロケータを奪い合う

統合メモリでは、GPUドライバ（nvidia_uvm）が管理するページも、ファイルI/Oのページキャッシュも、プロセスのヒープも、同一の物理ページアロケータから供給される。ここでLinuxのページ2分類が生死を分ける：

filepage側だけなら手動でも解放できる：

sync
echo 3 | sudo tee /proc/sys/vm/drop_caches
# 解放されるのは file（回収可能側）のみ。anon は1バイトも減らない

7/25夜の暴走ではSurrealDBが87GB実測（うち回収不能なanonが57.7GB実測）まで肥大した。「pingには応えるがSSHできない」ホスト沈黙の機構はここにある：ICMP応答はカーネル内で完結するが、SSHログインは新プロセス起動＝新しいanonページの割当を要求する。fileを使い果たしanonの壁だけが残った時点で、カーネルは死んでいないのに新規割当だけができない。

もう一つの層2の教訓は計測ツールの信頼性である。同時刻にdocker statsは379.6MiB実測と報告し、cgroup v2の実計上は72.8GB実測だった ── 約190倍の乖離。会計の正本は/sys/fs/cgroup/.../memory.currentとmemory.statのanon/file内訳であり、中間の便利ツールは変換層である（系統3）。

層3ランタイム層 ── PagedAttentionの事前確保と、分母のずれ

vLLMは起動時に--gpu-memory-utilization（比率）で総予約を一括確保し、モデル重みと実行時バッファを差し引いた残りをKVキャッシュプールとして固定する。PagedAttentionはこのプールをOSの仮想メモリと同じ発想で固定ブロックに分割し、リクエストへページ単位で貸し出す ── 断片化を消す代わりに、プールは実行時に伸縮できない。

KVのトークン単価は第一原理から計算できる：

KV/token = 2 × 層数 × KVヘッド数 × head_dim × dtypeバイト数
72Bの例: 2 × 80 × 8 × 128 × 1B(fp8) = 160 KiB/token  [実測環境の構成]
プール = 152,224 tok × 160KiB = 23.2 GiB
検算: 152,224 ÷ 32,768 = 4.65 ≒ 起動ログの Maximum concurrency 4.65x ✓

さらに「分母のずれ」が2種類ある。第一に、--gpu-memory-utilizationの分母は物理総量であって空き容量ではない ── 0.75指定の72Bは常に91.3GB実測を要求し、他プロセスの占有を考慮しない。第二に、CUDA graphプロファイリング（vLLM 0.21以降既定有効）が予約の一部を消費し、その量は起動ごとに変動する。実ログ：

INFO [utils.py:240] non-default args: {'max_model_len': 32768, 'gpu_memory_utilization': 0.6}
INFO [gpu_worker.py:477] The current --gpu-memory-utilization=0.6000 is equivalent to
     --gpu-memory-utilization=0.5909 without CUDA graph memory profiling.
INFO [kv_cache_utils.py:1731] GPU KV cache size: 403,360 tokens
INFO [kv_cache_utils.py:1732] Maximum concurrency for 32,768 tokens per request: 12.31x

別インスタンスでは同じ0.6000指定が0.5837相当実測と表示された。固定の補正係数は存在しない ── 目標達成は必ず起動ログの実測トークン数で確認する（二重帳簿、系統3）。

最後に本書最重要の実測：総予約からKVプールを引いた非KV床（重み＋実行時バッファ）は約68GB実測で、utilizationをいくら下げてもこれ未満にはならない。空き66.3GB実測の環境では、72Bはいかなる設定でも起動不能だった。

層4モデル/カーネル層 ── ルーフラインとFP4の二面性

ルーフライン分析では、prefill（プロンプト一括処理）は行列積が支配する演算律速、decode（1トークンずつの生成）は重み・KVの読み出しが支配する帯域律速である。外部ベンチではGB10級でprefill約6,200 tok/s公開が出る一方、denseモデルのdecodeは約6 tok/s公開に落ちる ── 3桁の非対称。工場で言えば、段取り（prefill）は速いのに加工（decode）のたびに棚全体を読み直すから搬送レーンが詰まる。

この非対称の突破口が2つある。第一にMoE：総パラメータに対して各トークンが通るactiveパラメータが小さいモデルは、decodeで読む重みが減るため、同帯域でdense約6 tok/s vs MoE約50 tok/s公開という差が生まれる。帯域が固定なら、読む量を減らすのがモデル側の解である。第二に量子化 ── ただしsm121（GB10）のNVFP4は「格納形式としてのFP4」であり、演算はより高精度の形式に展開して行われる公開。FP4は帯域と容量を節約する圧縮であって、演算スループット4倍の魔法ではない。格納形式と演算形式の区別は、カタログ数値を読むときの必須リテラシーである。

層4にはもう一つ、今回の実務に直結した現象がある：prefix cacheのヒット率はモデルでなくワークロードの性質で決まる。反復プレフィックス主体の旧ワークロードでは82%実測、検索チャンクが毎回異なるRAGでは9.5%実測。同じ機構が負荷の形で天使にも置物にもなる。

層5システム設計層 ── 容量・帯域・安定性は独立の3制約

層1〜4を積み上げると、統合メモリ機の設計問題は独立した3つの制約に分解される：

重要なのは3つが独立であること。容量を解いても帯域は1バイトも速くならない（今回まさに容量と安定性だけ解いた）。逆に、帯域の問題（RAGが遅い）を容量の道具（KV増設）で解こうとした誤診が7/26朝まで生きていた。制約の分類を誤ると、正しい道具を間違った病気に使う。