なぜDeepSeekはKVキャッシュをSSDに保存して26倍速くし、Cloudflareで他顧客データ155件が漏洩したのか？──1日155兆トークンを捌く「DeepInfer」と100PiB「3FS」の真実

https://youtu.be/5ORgwroXAzU

はじめましての方は、ぜひこちらの自己紹介記事（コンサルオジのプロフィールと番組方針）もあわせてご覧ください。

導入：この記事の結論・対象読者・持ち帰れる判断軸

• この記事の結論（核心）: 「大規模言語モデル（LLM）の応答速度を高めたいなら、計算途中の記憶データであるKVキャッシュは超高価なGPUメモリ（HBM）に置かなければならない」という従来のAIインフラの常識は、2026年10月に公開された2つの一次資料によって根底から覆されました。第1に、DeepSeekがオープンソース化した大規模クラウド推論フレームワーク DeepInfer（DeepSeek V4.1 Flash）と分散ファイルシステム 3FS（総容量約100ペビバイトの専用SSDクラスタ）は、MLA（マルチヘッド潜在アテンション）による 93.3%のキャッシュ圧縮とFP4量子化、そしてGPUDirect RDMA（GDR）による層別スワップインを組み合わせることで、本番トラフィックの全入力トークンの56%をSSD（ディスク）から直接供給し、128Kトークン入力の最初のトークン到達時間（TTFT）を13秒から500ミリ秒へと26倍高速化（キャッシュヒット時のAPI単価はミス時の50分の1）していました。第2に、その裏側で2026年10月26日にCloudflareが公表したセキュリティ調査報告書では、同じくプレフィル・デコード分離（Mooncake RDMA転送）を用いるオープンソース推論エンジン SGLang において、KVプール容量（681,280トークン）とモデル公開上限（1,048,576トークン）の不一致および拒否処理のフラグ不整合（req.finished() == False）が重なり、未上書きのKVキャッシュページ（P1〜P7）から直前の他顧客のプロンプト・生成データが155件のレスポンスに混入して流出するという重大インシデントが発生していました。

• 対象読者: AIインフラ・LLMOps・クラウド基盤の設計エンジニア、RAGや自律型AIエージェントを開発するソフトウェアエンジニア、企業のAIセキュリティ・調達・ガバナンス責任者、およびAIデータセンターの経済性（GPU時間あたり売上・ストレージ階層設計）を分析する技術経営・投資担当者。

• 読み終えて持ち帰れる判断軸: 「なぜGPUで再計算するよりSSDから読み出す方が速いという物理的な逆転が起きたのか」「単一クラスタで1日155兆トークンを捌き、GPU 1時間あたり38米ドルの売上を生むDeepSeekの3階層キャッシュ設計（HBM・ホストメモリSWA・100 PiB 3FS）はどう動いているのか」「なぜ先頭1トークンの不一致で応答が26倍遅くなりコストが50倍に跳ね上がるのか」、そして「Cloudflareの155件漏洩事故から学ぶ、プレフィル・デコード分離環境の設定監査とKVページ所有権証明（Integrity by Construction）」を、明日からの設計・運用基準として持ち帰ることができます。

背景と全体像：「KVキャッシュはHBMに置くもの」という定説の崩壊と、表裏一体の2大一次資料

2026年10月、AI推論インフラの設計思想を根底から揺るがす2つの一次資料が、わずか数日の間隔で公開されました。

1つ目は、DeepSeekが公開した大規模クラウド推論フレームワーク DeepInfer の公式設計ドキュメント（DeepSeek V4.1 Flash Inference Deployment Q&A）と、データサイエンティストのAvi Chawla氏による技術解析レポート（Why DeepSeek stores its KV cache on disk）です。ここで明かされた本番稼働データは驚異的でした。

• 単一クラスタの処理規模: 1日あたり 155兆トークン（155 trillion tokens per day） を処理。

• GPU稼働採算性: 最も単価の安い時間帯（Valley pricing）で計算しても、GPU 1時間あたり38米ドル（US$38 per GPU-hour） の売上を達成。

• SSDからの直接供給比率: 本番トラフィックにおける全入力トークンの 56% が、GPUメモリではなくSSD（ディスク）から直接供給されている。

• 128Kトークン長文のTTFT（Time to First Token）: キャッシュミス時の 13秒 に対し、SSDキャッシュヒット時は 500ミリ秒（0.5秒） へと 26倍高速化。

• API利用単価の格差: deepseek-flash において、キャッシュヒット時のトークン単価はキャッシュミス時の 50分の1（50x less）。

2つ目は、2026年10月26日にCloudflareのKevin Flansburg氏とMichelle Chen氏が公開した公式ポストモーテム（事後検証報告書）「Cross-request KV cache exposure in the GLM-5.3 Workers AI model, and our remediation with SGLang」（Cloudflare公式ブログ）です。

2026年8月27日から9月9日までの約2週間、CloudflareのWorkers AI上でホストされていたエージェント・コーディング向けモデル @cf/zai-org/glm-5.3 において、681,280トークンを超える長文プロンプトを送信した顧客に対し、直前に同じモデルを利用した別の顧客のプロンプトや回答の断片が含まれたレスポンスが返却されるというテナント分離破綻が、合計 155件 発生していました。

一見すると、「DeepSeekの超高速SSDキャッシュ」と「CloudflareのKVキャッシュ情報漏洩」は別々のニュースに見えます。しかし、インフラの内部構造を解剖すると、この2つは「LLM推論エンジンが単なる行列計算器から『ネットワーク越しにメモリページをやり取りする分散仮想メモリOS』へと進化した結果として生じた、光と影」であることが分かります。

第1章：なぜGPUメモリ（HBM）だけでは破綻するのか ── Baseten CTOの証言と「MLA 93.3%圧縮」の物理計算

1-1. プレフィル（Prefill）の計算負荷と、H200×8基でもギリギリになるKVキャッシュの壁

LLMがユーザーのプロンプトを受け取って回答を生成するプロセスは、性質が全く異なる2つのフェーズに分かれています。

1. プレフィル（Prefill）段階: 入力されたプロンプト全文（数千〜数十万トークン）を一括で読み込み、モデルのすべての層・すべてのトークンについてアテンション機構のKey（鍵）とValue（値）のベクトル、すなわち KVキャッシュ を計算する工程です。入力が長くなるほど計算量が二乗〜線形で増大し、「最初の1文字目が出るまでの待ち時間（TTFT）」を決める最大のボトルネックになります。

2. デコード（Decode）段階: 計算済みのKVキャッシュを参照しながら、自己回帰的に1トークンずつ順番に出力を生成する工程です。こちらは計算量よりもメモリ帯域幅（HBMから重みとKVキャッシュを読み出す速度）に律速されます。

チャットボットで何往復も会話を続ける場合や、AIエージェントが数万トークンのシステムプロンプト・ツール定義・リポジトリ構造を毎ステップ送信する場合、プロンプトの先頭部分（プレフィックス）は前回のリクエストと全く同じです。したがって、一度計算したKVキャッシュを保存して次のリクエストで再利用（Prefix Caching）できれば、重たいプレフィル計算を丸ごとスキップできます。

しかし、ここで立ちはだかるのが GPUメモリ（HBM）の物理容量とコストの壁 です。推論クラウド基盤大手Basetenの共同創業者兼CTOであるAmir Haghighat氏と、SGLangのコアメンテナでもあるYineng Zhang氏は、技術ポッドキャスト『Latent Space』（Everything you need to run Mission Critical Inference）において、本番推論インフラの過酷な現実を次のように語っています。

1-2. 従来のMHAモデルのジレンマ：「ディスクから読むよりGPUで再計算した方が速い」

なぜ従来のLLM推論エンジン（標準的なvLLMやTensorRT-LLMの構成）は、KVキャッシュを安価なSSDに保存せず、高価で容量の小さいGPUメモリ（HBM）やホストDRAMにしか置かなかったのでしょうか。

理由は極めて単純な物理計算にあります。標準的なMulti-Head Attention（MHA）モデルでは、すべての層・すべてのアテンションヘッドごとに個別のKeyベクトルとValueベクトルを保存します。そのため、長文プロンプト1件のKVキャッシュだけで数ギガバイトから数十ギガバイトに膨れ上がります。

もしこれほど巨大なKVキャッシュをSSD（NVMeディスク）から読み出そうとすれば、PCIeバスとストレージの転送時間だけで数秒〜十数秒かかってしまい、「ディスクから古いKVキャッシュを読み出す時間 ＞ GPUの演算器（Tensor Core）で最初からプレフィルを再計算する時間」 となってしまいます。だからこそ業界全体が「KVキャッシュはHBMに置くしかない。HBMから溢れた古いキャッシュは捨てる（Evictする）しかない」と考え、結果として数分後や数時間後の会話再開時にはキャッシュが消えてしまい、毎回ゼロから再計算していたのです。

1-3. DeepSeekの第1の突破口：MLAによる「93.3%削減」とFP4量子化が物理法則を逆転させた

この「SSDは遅すぎて使えない」という前提を数式レベルで破壊したのが、DeepSeek-V2で導入され、V3・R1・V4.1 Flashへと受け継がれた MLA（Multi-head Latent Attention：マルチヘッド潜在アテンション） です（Avi Chawla解析）。

• MLAの圧縮メカニズム: すべてのアテンションヘッドごとにKeyとValueを別々に保存する代わりに、各層の1トークンあたり たった1本の小さな圧縮潜在ベクトル（Compressed Latent Vector） だけをKVキャッシュとして保存します。デコードやアテンション計算を行う瞬間に、GPUの演算器上でこの潜在ベクトルから各ヘッドのKeyとValueを動的に復元（射影）します。

• 93.3%の容量削減: DeepSeek-V2の一次論文で実証された通り、MLAは従来の67Bモデルと比較して KVキャッシュのメモリサイズを93.3%削減（約15分の1に圧縮） しました。

■ V4.1 FlashにおけるさらなるFP4低精度化: 公開された DeepInfer の公式Q&A（DeepInfer GitHub）によると、DeepSeek V4.1 Flashではさらに以下の4ビット量子化を適用しています。

• Main KV（主KVキャッシュ）: 16要素単位の e4m3（グローバルスケールを持たないNVFP4相当の4ビット浮動小数点）。

• Indexer KV（インデクサ用KV）: 32要素単位の ue8m0, MXFP4。

• MoE Routed-Expert Weights（ルーティング専門家重み）: 32要素単位の ue8m0, MXFP4。

1トークンあたりの保存バイト数が15分の1以下に激減した結果、キャッシュヒット時にディスクから読み出すべきデータ量も15分の1以下になりました。これにより、歴史上初めて 「GPUでプレフィルを再計算するよりも、SSDからKVキャッシュを読み出す方が圧倒的に速い」 という損益分岐点の逆転が成立したのです。

第2章：100PiBの専用SSDクラスタ「3FS」と、1日155兆トークンを捌く「DeepInfer」の内部構造

2-1. 第2の突破口：30.73TB SSD×20本を束ねる100 PiB分散ファイルシステム「3FS」

もちろん、いくらKVキャッシュを93.3%圧縮しても、1台のSSDから順番に読み出していては数十ギガバイト毎秒の帯域は出ません。そこでDeepSeekが構築した第2の突破口が、自社開発の分散ファイルシステム 3FS（Fire-Flyer File System） を用いた専用ストレージクラスタです（DeepInfer公式Q&A）。

公式Q&Aで初めて公開されたハードウェアおよびクラスタ構成の定量仕様は以下の通りです。

• 全体アーキテクチャ ── DeepSeek V4.1 Flash（DeepInfer + 3FS）の公式仕様：E/P/D分離（Vision Encoder / Prefill / Decode）＋ 専用3FSストレージノード ／ 設計上の意図・効果：段階ごとに最適なGPU数・並列度を割り当て、TTFTとTBTを独立最適化

• 並列化方式（Parallelism） ── DeepSeek V4.1 Flash（DeepInfer + 3FS）の公式仕様：Prefill: EP2–8 / DP2–8（HBMが許す最小構成） ／ Decode: EP64–128 / DP64–128（Wide-EP、64〜128 GPU超ノード） ／ 設計上の意図・効果：Wide-EPによりMoE専門家部分のステップあたりメモリ通信量を劇的に削減（P:D比率は約1:1、最小効率単位は64P+64D）

• データセンター間接続 ── DeepSeek V4.1 Flash（DeepInfer + 3FS）の公式仕様：隣接する別データセンター間でのP/D分離も可能（8 GPUあたり約400 Gbpsの相互接続帯域を確保） ／ 設計上の意図・効果：V4.1 Flashの大幅なKV圧縮によりDC間転送も実用域に収まる

• 標準ストレージサーバー仕様 ── DeepSeek V4.1 Flash（DeepInfer + 3FS）の公式仕様：1台あたり 30.73 TB SSD × 20本（計約614.6 TB/台） ／ 読み出し 40 GB/s以上、書き込み 5 GB/s以上 ／ 設計上の意図・効果：数千台のSSDにチャンクを分散配置（ストライピング）し、並列読み出しで帯域を合算

• GPU対ストレージ比率 ── DeepSeek V4.1 Flash（DeepInfer + 3FS）の公式仕様：オンラインGPU 1基あたり 論理容量 約14.4 TB（物理容量はそれ以上）、クラスタ全体で 約100 PiB（ペビバイト） ／ 設計上の意図・効果：高価なHBMを圧迫せず、数日分の全ユーザー文脈を丸ごと保持可能

• 冗長化とテール遅延対策 ── DeepSeek V4.1 Flash（DeepInfer + 3FS）の公式仕様：10+2 イレージャーコーディング（EC） ／ 読込時はグループ内 11ノードへ同時要求し、最初の10応答で即時復元 ／ 設計上の意図・効果：2ノード同時故障に耐えつつ、最も遅い1ノードのネットワーク揺らぎ（ジッタ）を切り捨てて低遅延を維持

• キャッシュ保持期間（TTL） ── DeepSeek V4.1 Flash（DeepInfer + 3FS）の公式仕様：AIエージェント通信：3日間（72時間超） ／ チャットボット通信：7日間（3FS側のLRU GC Workerが自動回収） ／ 設計上の意図・効果：チャットは少数のキャッシュが何度も読まれるロングテール特性が強く、3日TTLに縮めるとヒット率が0.5〜1%低下するため7日間保持

2-2. なぜ計算ノードのローカルメモリではなく「独立した3FSストレージクラスタ」なのか？

ここで多くのインフラエンジニアが抱く疑問は、「各GPUサーバーのホストDRAMやローカルNVMe SSDに階層キャッシュ（Tiered Storage）として置いた方が、ネットワークを経由しない分だけ速いのではないか？」という点です。

これに対するDeepSeek公式Q&Aの回答は、大規模本番運用の急所を見事に突いています。

1. プレフィックス親和性（Prefix Affinity）と負荷分散の衝突解消: もし特定の計算ノードのローカルディスクにしかキャッシュがなければ、次回同じユーザーがアクセスした際、たとえその計算ノードが満杯で高負荷であっても、キャッシュを当てるために同じノードへルーティングせざるを得ません。独立した3FSストレージクラスタに置けば、すべてのPrefillマシンがすべてのキャッシュ済みプレフィックスに等しくアクセスできるため、Prefillロードバランサは「純粋にいま計算クォータが空いているマシン」へ自由にリクエストを振り分けられます。

2. 故障率の1桁以上の差（Fault Isolation）: DeepSeekの実測データによれば、高負荷で稼働するGPU計算ノードの故障率は、ストレージ専用ノードよりも1桁以上（more than an order of magnitude）高いことが判明しています。計算とストレージを分離することで、GPUノードがクラッシュして再起動（数分所要）しても、100 PiBのKVキャッシュは一切失われず、別の健全なGPUノードが即座に引き継いで処理を継続できます。

2-3. 第3の突破口：GDR（GPUDirect RDMA）による層別スワップインと「SWA Bounded Replay」

DeepInferはKVキャッシュを性質に応じて 3つの階層 に分けて管理しています。

• 階層1：In-flight Block KV + State KV（GPU HBM）: 現在計算中のブロックと状態キャッシュ。

• 階層2：Paged Block KV（専用3FS SSDクラスタ）: メインKVとインデクサK。kvcache-store が管理。

• 階層3：SWA KV Cache（ローカルホストメモリ ＋ 400G VLAN）: スライディング・ウィンドウ・アテンション（SWA）用のキャッシュ。V4.1では先頭20層×134トークン×528バイト（MXFP8形式）＝ 1シーケンスあたりわずか1,415,040バイト（約1.41 MB） のみを生成元マシンのホストメモリに保持し、Entrypointのインメモリ・ディレクトリと400G VLAN経由でマシン間共有します。

そして、3FSからGPUへキャッシュを読み戻す際のオーバーヘッドは、以下の3段階パイプラインで完全に隠蔽（Overlap）されています。

1. Entrypointでのハッシュ連鎖一致判定: リクエスト到着時、Entrypointがメタデータのみに対するハッシュチェーン照合でヒット長を即時算出します。

2. 別プロセスによる非同期フェッチ: 3FSからホスト共有メモリへのデータ取得は、推論エンジンとは別のプロセスが非同期で実行します。

3. GDR（GPUDirect RDMA）による層別H2Dスワップイン: ホスト共有メモリからGPUのHBMへデータを移す際、通常のCUDAコピーエンジン（cudaMemcpyAsync）は細粒度なKVキャッシュブロックの転送効率が悪いため使用しません。代わりに RDMA NICを用いたGDR（GPUDirect RDMA） を使い、GPUの演算コア（SM）を1つも消費せずにPCIe帯域を飽和させ、第1層を計算している裏で第2層のKVキャッシュを流し込みます。

さらに特筆すべき発明が SWA Bounded Replay（有界リプレイ） です。もしSWAキャッシュが欠損していた場合や、CED（Coupled Encoder-Decoder）構造のデコーダ層（20層）のSWAキャッシュを再構築する場合、本来であれば末尾2,560トークン分を再計算する必要があります。しかしDeepInferは、アテンション窓を直近128トークンに切り詰めて近似再計算（Bounded Replay）することで、再計算コストを文脈長や層数に依存しない「定数」へと落とし込み、プレフィル全体の計算量をほぼ半減（nearly halving total prefill computation） させています。

第3章：対立する視点と死角 ── プレフィックス完全一致の壁とCloudflare「他顧客KVキャッシュ155件漏洩」の衝撃

3-1. 第1の死角：先頭1トークンが変わるだけで「500ms → 13秒」へ転落するRAG・エージェントの罠

このSSD型KVキャッシュにも、運用上の厳しい制約があります。それは 「最初の1トークン目からの完全一致（Exact Match from the very first token）しかキャッシュヒットとして認められない」 という鉄則です（Avi Chawla解説）。

自己回帰型TransformerのCausal Attention（因果的アテンション）では、あるトークンのKeyとValueは「それより前にあるすべてのトークン」に依存します。したがって、もしエンジニアが何気なくプロンプトの1行目に Current Date: 2026-10-29 20:15:03 や Request ID: 98a7f...、あるいはRAGで毎回検索してきた動的チャンクを挿入してしまうと、後ろに続く10万トークンのシステム指示書や社内規定ドキュメントが前回と1文字違わず同じであっても、キャッシュヒット率は0%（完全ミス） になります。

その結果、500ミリ秒で返るはずの応答が13秒かかり（26倍の遅延）、APIコストは一気に50倍へ跳ね上がります。また、DeepSeekのブロック管理は128トークン単位（YOCO切り詰め条件により長さ L の入力に対する最大ヒット長は L - 134）であり、エージェント通信のTTLは3日間であるため、動的なツール出力が激しく入れ替わるエージェントでは、プロンプト構造を厳密に「静的プレフィックス先頭・動的コンテキスト末尾」へ設計しなければ恩恵を受けられません。

3-2. 第2の死角：Cloudflare Workers AI（GLM-5.3 / SGLang）で起きた「他顧客データ155件漏洩」の7段階解剖

さらに深刻な「分散KVキャッシュの構造的リスク」を浮き彫りにしたのが、2026年10月26日にCloudflareが公開したセキュリティインシデント報告書です（Cloudflare公式ブログ）。

事故の概要とタイムライン

• 発生期間: 2026年8月27日（GLM-5.3ローンチ時）〜 2026年9月9日 14:00 UTC（モデル非公開化）。

• 発見経緯: 2026年9月8日 23:11 UTC、セキュリティ研究機関KnosticのGadi Evron氏がHackerOne経由で「非常に長いプロンプトを @cf/zai-org/glm-5.3 に送ると、他のユーザーのセッションのテキストが返ってくることがある」と通報。Cloudflareは翌9月9日 13:22にインシデントを宣言し、25分以内に独立した2アカウント間で再現を確認、40分後の14:00にモデルをオフライン化。同日19:40に設定修正とエンジンパッチを適用して復旧。

• 被害規模: 研究者と社内の検証を除き、681,280トークンを超えるプロンプトに対する合計155件のレスポンス に、直前に同モデルを利用した他顧客のリクエストデータや生成断片が混入。意図的な反復悪用の痕跡はなし。

なぜ他人のKVキャッシュが混入したのか？（2つの欠陥の重なり）

CloudflareはGLM-5.3を、オープンソース推論エンジン SGLang のプレフィル・デコード分離構成（Prefill GPUプールがKVキャッシュを生成し、Mooncakeを用いたRDMA転送でDecode GPUプールへ引き渡す構成）で運用していました。ここで以下の2つの問題が重なりました。

1. 問題1：公表コンテキスト長と実KVプール容量の不一致（Misconfiguration）:

• GLM-5.3の公開コンテキスト上限は 1,048,576トークン（1Mトークン） に設定されていました。

• しかし、SGLangのKVキャッシュプール容量は設定ファイルの固定値ではなく、「GPUにモデル重みをロードした後に残ったVRAM容量」から起動時に自動計算 されます。CloudflareのPrefillノードでは、このプール容量が 681,280トークン しかありませんでした。

• 担当チームは起動ログでこの不一致を認識していましたが、ローンチ前の長文ベンチマークテストで「HTTPステータス200が返り、エラーフレームなしでストリーミング応答が返ってくること」だけを確認し、出力テキストの中身の一貫性（Coherence）を検証していなかった ため、エンジン側がストリーミング等で適切に処理していると誤認していました。

2. 問題2：SGLangのP/D分離モードにおける拒否リクエスト処理バグ（Issue 第3023回3 / 第3698回8）:

• そもそもSGLangを含む高速推論エンジンでは、性能を最大化するため、GPUメモリ上のKVキャッシュページをリクエスト間でゼロ消去（Zeroing）しません。解放されたページには前の顧客のデータが残ったままになり、次のリクエストが自分のKVデータを上から書き込む（Overwriteする）ことで初めて古いデータが消える前提になっています。

• ところが、681,280トークンを超えるプロンプトが到着した際、SGLangの内部では以下の 7段階のバグ連鎖 が発生しました。

• Step 1: Bootstrap ── 実行コンポーネント：Router → Decode ／ 内部で起きた実際の挙動：ルーターがDecodeノードへ元の長文プロンプト長（図解例では 8ページ：P0〜P7）を通知し、Decodeノードは8ページ分のKV領域を予約した。

• Step 2: Prefill受付 ── 実行コンポーネント：Prefill Scheduler ／ 内部で起きた実際の挙動：Prefillスケジューラはプール容量超過を検知し、Req.set_finish_with_abort で拒否処理を実行。メモリ確保を避けるためプロンプトを 「1トークンのプレースホルダ（ダミー）」 に置換した。しかし、拒否理由は to_finish フィールドに格納され、finished_reason には入らなかったため、受付キューの判定式 req.finished() は False（まだ完了していない生存リクエスト） を返し続け、そのまま通過してしまった。

• Step 3: Prefill計算 ── 実行コンポーネント：Prefill GPU ／ 内部で起きた実際の挙動：置換された「1トークンのダミー」に対してのみ、ごくわずかな順伝播（Forward pass）を実行した。

• Step 4: KV RDMA転送 ── 実行コンポーネント：Mooncake RDMA ／ 内部で起きた実際の挙動：Prefillは1トークン分のKVキャッシュ、すなわち 先頭の1ページ（Page P0）だけ をDecodeノードへRDMA転送し、「転送完了（Transfer Complete）」のシグナルを送った。

• Step 5: Decode受付 ── 実行コンポーネント：Decode Queue ／ 内部で起きた実際の挙動：Decode側の受付キューも同じ req.finished() 判定を使っていたため、異常に気づかずハンドオフを受け入れた。

• Step 6: Decode Attention ── 実行コンポーネント：Decode GPU ／ 内部で起きた実際の挙動：Decodeが回答生成を開始し、アテンション機構が予約済みの全8ページ（P0〜P7）を読み取った。しかし 今回のリクエストで上書きされたのはPage P0だけであり、Page P1〜P7には直前の別顧客のリクエストが残したプロンプトと生成途中のKVキャッシュが手つかずで残っていた。

• Step 7: 汚染応答の返却 ── 実行コンポーネント：Client Response ／ 内部で起きた実際の挙動：クライアントにはHTTP 400エラーではなく HTTP 200 OK が返り、8ページ分の本来のプレフィルより不自然に速い速度で、他人のセッション内容が混ざったもっともらしい回答 が出力された。

第4章：【私なりの解釈】推論エンジンは「分散仮想メモリOS」へ変貌した

これら2つの一次資料を突き合わせると、これからのAIインフラとセキュリティに関する3つの本質的な構造変化が見えてきます。

4-1. 解釈1：LLM推論基盤で起きていることは「OSカーネル史の完全な再現」である

第1に、現代のLLM推論エンジン（DeepInfer、SGLang、vLLM等）は、もはや単なる「ニューラルネットワークの行列計算ランタイム」ではありません。GPUのHBMをL1/L2キャッシュ、ホストDRAMを主記憶、100 PiBの3FS SSDクラスタを高速スワップ領域としてページ単位で管理する「分散仮想メモリOS」 そのものへと変貌しました。

実際、Cloudflareが報告書の中で「現在も継続して潰し込んでいるKVキャッシュのメモリ安全性バグの2大要因」として挙げた内容は、1990年代〜2000年代のOSカーネル開発の歴史と完全に一致しています。

• 単一ノード内のページ寿命競合（Page Lifetime / Use-After-Free）: デコード中のトークン生成、ホストメモリへのオフロード、RDMA受信、エラー中断パスが同じKVページを同時に参照している際、1つのタスクがページを解放（Free）してしまうと、まだ読み書き中のページが別の顧客のリクエストに再割り当てされてデータが混ざる問題（SGLang PR 第2422回6, 第3089回9, 第3093回7 で修正）。

• ノード間のRDMAレースコンディション（Cross-Node In-flight Write Race）: PrefillノードがRDMAでDecodeノードへKVキャッシュを書き込んでいる最中にクライアント切断等でリクエストが中断された場合、すでにネットワーク上へ送出されたRDMA書き込みは取り消せません。もしDecode側が即座にそのページを解放して次のリクエストに割り当てると、遅れて着弾したRDMAパケットが新しい顧客のKVキャッシュを上書き汚染してしまいます（SGLang PR 第3745回4, 第4102回3 のDeferred KV Release既定化、第3275回8 のMooncake転送バッチ上限で対策）。

4-2. 解釈2：モデルのアーキテクチャ（数式）がストレージとネットワークの経済性を直接支配する

第2に、DeepSeekが単一クラスタで1日155兆トークンを捌き、GPU時間あたり38ドルの売上とキャッシュヒット単価50分の1を実現できた理由は、「速いSSDを買ってきたから」ではありません。

• モデル側の MLA（93.3%圧縮）＋ FP4量子化 で転送データ量を削り、

• モデル側の YOCO / CED構造 ＋ SWA Bounded Replay で再計算窓を128トークン（定数コスト）に封じ込め、

• インフラ側の 100 PiB 3FS（10+2 EC）＋ GDR（GPUDirect RDMA） でPCIe帯域を飽和させて計算と通信を完全に重ね合わせた、

という 「モデル数式とストレージ・通信プロトコルの完全な垂直統合（Co-design）」 の産物です。今後のAI開発において、モデル研究チームとインフラ運用チームが分断されている組織は、この推論経済性の勝負に構造的に勝つことができません。

4-3. 解釈3：マルチテナントAIのセキュリティ基準は「KVページの構造的完全性（Integrity by Construction）」へ移る

第3に、これまで企業のAIセキュリティ監査といえば「プロンプトインジェクション対策」や「学習データへの不使用（Zero Data Retention）」ばかりが注目されてきました。しかしCloudflareの155件漏洩事故は、「たとえモデルが学習しなくても、推論サーバーのGPUメモリやSSD上に数秒〜数日間残るKVキャッシュのページ管理にバグがあれば、他社へ機密データがそのまま流出する」 という事実を証明しました。

CloudflareとSGLangチーム（RadixArk）がこの事故を受けて導入した「多層ハードニング」と「長期アーキテクチャ方針」は、今後の全AIインフラ事業者の標準になります。

1. 即時緩和とSGLang v0.5.22パッチ群:

• GLM-5.3のPrefill KVプールを 約204万トークン（1,048,576トークン上限の約2倍） に拡張し、有効なリクエストが絶対に容量超過拒否パスに入らないよう構成変更。

• 受付時即時破棄（PR 第3698回8, 第3893回5）: 拒否保留（pending rejection）を持つリクエストを、ブートストラップ・ページ確保・KV転送が起きる前の受付キュー段階で即座にエラー破棄し、Decode側でも予約トークン数と実転送トークン数の一致を検証。

• 転送チェックサム検証（PR 第3950回0）: --disaggregation-enable-kv-checksum フラグにより、PrefillからDecodeへ転送されたKVキャッシュのチェックサムを生成前に検証。

• ロードバランサの中断抑止: クライアントが途中で切断しても、Prefill完了およびDecodeの最初の1トークン生成まで接続を保持してから閉じることで、ノード間RDMA転送の途中中断（Abort）そのものを発生させない設計へ変更。

2. Integrity by Construction（構造的完全性：ページ所有権タグ）:

• 設定チェックや個別のレース修正だけでは、未知のバグ経路をゼロにはできません。そこでCloudflareがプロトタイプ実証し、SGLang本体への統合を進めているのが 「物理KVページごとの世代・所有権タグ（Page-level Ownership Tags）」 です。物理ページが再割り当てされるたびにタグを更新し、各リクエストが期待するタグ一覧を記録して、Decodeがアテンションでページを読み出す瞬間に照合します。万が一他人のページを読もうとした場合は、データを返す前にその1リクエストだけを安全にフェイルストップさせます。実測では スループットおよびテール遅延への影響は1%未満（under 1%） で実現できています。

3. Integrity by Mathematical Impossibility（形式手法によるRDMAプロトコル証明）:

• Cloudflareが権威DNSサーバーの Topaz や QuePaxa で実績を持つ形式検証（Formal Verification）を、Mooncakeを用いたSGLangのRDMA KVキャッシュ転送プロトコルへ適用し、2ノード間の状態不一致が数学的に起こり得ないことを証明する取り組みを開始しています。

結論：明日からAIインフラ・開発チームが取るべき3つの実務アクション

最後に、私たちが明日からのシステム設計・開発・調達において直ちに実行すべき3つのアクションを整理します。

アクション1：プロンプト構造を「先頭完全固定・末尾動的追加」へ再設計し、プレフィックスキャッシュを最大化する

• 実施内容: LLM APIや自社推論基盤を呼び出す際、システムプロンプト、ツール定義（JSONスキーマ）、共通の業務マニュアルやコードベース概要など 「変わらない要素」を必ずプロンプトの最先頭に固定配置 してください。逆に、現在時刻、セッションID、ユーザーの直近の質問、RAGで動的に取得した検索チャンクなど 「リクエストごとに変わる要素」は必ず末尾に配置 します。

• 定量効果: 先頭1トークンの不一致によるキャッシュ全ミスを防ぐだけで、DeepSeek等の環境では長文TTFTが最大26倍短縮（13秒→500ms）され、キャッシュヒット部分のAPIコストを数十分の1に圧縮できます。

アクション2：プレフィル・デコード分離（SGLang等）の運用環境を直ちに v0.5.22 以降へ更新し、5項目のデプロイ検査を必須化する

• 実施内容: 自社または委託先でSGLang等の分散推論エンジンを運用している場合、以下の5項目をCI/CDのデプロイゲートに組み込んでください（Cloudflare推奨チェックリスト）。

1. 重み、量子化、並列度、メモリ比率を変更するたびに、すべてのPrefillおよびDecodeノードの起動ログから 実KVプール容量がモデルのコンテキスト長以上であること を直接計測・比較する（プロキシの制限やHTTP 200応答だけを信用しない）。

2. 第3698回8 および 第3893回5 を含む SGLang v0.5.22以降 へアップグレードする。

3. 両ロールで 遅延KV解放（Deferred KV Release、第4102回3以降既定） を有効化し、Mooncakeの転送バッチサイズを解放タイムアウト内に制限（第3275回8）する。

4. --disaggregation-enable-kv-checksum および --kv-canary による破損・未初期化検知を有効化し、デプロイテストではカナリア文字列を用いた出力内容の整合性検査を実施する。

5. ロードバランサでクライアント切断時の即時Abortを抑止し、初回トークン到達まで転送を完了させる。

アクション3：機密データを扱う外部LLM API・推論クラウドの調達基準に「KVキャッシュのテナント分離と永続化保護」を追加する

• 実施内容: 法務・財務・ソースコード解析など長文の機密プロンプトを外部推論プロバイダへ送信する場合、従来の「学習に使わない（Zero Data Retention）」条項だけでなく、「DRAMやSSD（3FS等の分散ストレージ）に数時間〜7日間保持されるKVキャッシュのテナント別暗号化・アクセス分離、およびGPUメモリページ解放時のゼロ消去または所有権タグ検証の有無」 をセキュリティ審査票の必須確認項目に追加してください。

検証済み一次資料・出典リンク一覧

1. Daily Dose of Data Science (Avi Chawla): Why DeepSeek stores its KV cache on disk — MLAによる93.3%削減、3FS並列SSD読み出し、128KトークンTTFT 26倍高速化（13秒→500ms）、本番入力トークン56%のディスク供給、キャッシュヒット単価50分の1、先頭完全一致条件の検証。

2. DeepSeek Official GitHub: DeepSeek V4.1 Flash Inference Deployment Q&A (DeepInfer) — 1日155兆トークン・GPU時間あたり売上38ドルの本番指標、E/P/D分離とWide-EP（EP64–128）、30.73TB SSD×20本（読込40GB/s・書込5GB/s）のストレージサーバー仕様、GPUあたり論理14.4TB（全体約100PiB）の3FSプール、10+2イレージャーコーディング、エージェント3日・チャット7日のTTL、GDR層別スワップイン、SWA（20層×134トークン×528B＝1,415,040B）とBounded Replay、FP4量子化、DSpark動的長検証（+4〜7%スループット）の公式仕様。

3. Cloudflare Security Blog: Cross-request KV cache exposure in the GLM-5.3 Workers AI model, and our remediation with SGLang — 2026年8月27日〜9月9日に発生した681,280トークン超過リクエストにおける155件の他顧客データ混入インシデント、P0〜P7ページ予約と1トークン置換による未上書き参照の7段階メカニズム、SGLang v0.5.20〜v0.5.22の修正PR一覧、ページ所有権タグ（オーバーヘッド1%未満）と形式手法によるRDMA検証の公式ポストモーテム。

4. Latent Space Podcast: Everything you need to run Mission Critical Inference (ft. DeepSeek v3 + SGLang, Amir Haghighat & Yineng Zhang) — Baseten CTO Amir Haghighat氏によるH200（141GB VRAM、4.8TB/s帯域）8基ノードでのKVキャッシュ制約とミッションクリティカル推論の3本柱に関する対談記録。

あわせて読みたい関連記事・番組案内

• 関連note記事（100万行のC言語を捨てて300行のアセンブリへ置き換えたTinfoilの機密VM設計）: なぜ100万行のC言語を捨てて「300行のアセンブリ」へ置き換えたのか？──4,000億トークンの脆弱性探索とTinfoilが示した「AI時代のソフトウェア還元主義」 — https://note.com/consuloji_ch/n/n55af8cf2c4a9

• 関連note記事（ビッグテックのAI設備投資によるFCF圧迫とローカル・オンプレ推論への回帰）: なぜビッグテックのAI投資で現金が細り、現場はローカルへ戻るのか？──Microsoft 645億ドル投資・Oracle赤字・Google検索の壁 — https://note.com/consuloji_ch/n/n5443199d598a

• 初めての方へ（番組案内・固定記事）: コンサルオジの「海外一次資料で読み解くAI・テクノロジー深掘り」番組ガイドと記事一覧 — https://note.com/consuloji_ch/n/n1975ecc3cf48

#生成AI #DeepSeek #Cloudflare #LLM #AIインフラ #サイバーセキュリティ #システム設計 #エンジニアリング