この記事の要点

2026年7月31日に公開された DeepSeek-V4-Flash-0731（Hugging Face 公式モデルカード）を、AMD Instinct MI300X「1枚」で本番運用するための構成とパッチをまとめた実証リポジトリ deepseek-v4-flash-mi300x（GitHub）が HackerNews で話題になった。

このリポジトリは単なる「動かしてみた」ではない。フロンティアクラスに手の届くMoEモデルが、80GBのH100では載らないが192GBのMI300Xなら量子化なしで1枚に収まるという、オンプレ推論の前提が変わったことを示している。同時に、NVIDIA前提で書かれた推論スタックをAMDへ移植すると、ベンチマークは通るのに本番でツール呼び出しがおかしくなる、といったサイレントな品質劣化が起きうることも生々しく記録している。

本記事では、この事例を日本のインフラ担当者の視点で三つに再構成する。第一に304Bという数字の誤読、第二に「安さの正体はコストではなくデータ主権」という運用判断、第三にFP8フォーマットとMoEルーティングという移植の落とし穴である。

1. なぜ今これが重要か

日本企業がLLMを本番投入するとき、多くの現場が二択で止まっている。海外フロンティアAPIに頼るか、社内に置ける小型モデルで我慢するか、である。前者は速くて賢いが、プロンプトも生成物も国外のデータセンターを通る。金融、医療、自治体、防衛関連のように、そもそもデータを外に出せない領域では選択肢に入らないことが多い。後者は安全だが、能力が一段落ちる。

この二択の間を埋める第三の道が、フロンティア級モデルを自社の1台のGPUサーバーで動かす、という選択肢である。これまでこれは「数百Bのモデルなど1枚のGPUに載るはずがない」という常識で片付けられてきた。DeepSeek V4 Flashの登場と、それをMI300X 1基で動かした今回の実証は、その常識が崩れつつあることを具体的な数字で突きつけている。

前回の記事では、激安AI APIの正体がトークン転売リレーであり、匿名の従量アクセスを社内に作らないことが防御になると論じた。今回はその裏返しで、出せないデータを扱う組織が自前の推論基盤をどう評価すべきかという話である。

2. 何が起きているか ― 「304B」の誤読を解く

まず数字を正確にしておきたい。多くの紹介記事は「304B（3040億パラメータ）のモデルを1枚で動かした」と書くが、これは半分正しく半分ミスリードだ。

Simon Willison の解説や公式情報を突き合わせると、DeepSeek V4 Flashの実体は次のようになる。

ベースは総パラメータ約284BのMoE（Mixture of Experts）モデル
1トークンあたりに実際に働く活性パラメータは約13B
Hugging Faceが表示する304Bは、投機的デコード用のドラフトモジュール（DSpark）を含んだ数字
コンテキスト長は最大1M、ライセンスはMIT

ここで効いてくるのが活性パラメータ13Bという値だ。MoEは全エキスパートを毎回動かすわけではなく、ルーターが選んだ一部だけを使う。つまり速度と電力を決めるのは総パラメータではなく活性パラメータのほうである。総パラメータはメモリ容量の問題、活性パラメータは計算速度の問題、という別々の制約に分けて考える必要がある。

よくある誤解  「304Bだから1枚のGPUでは無理、まして高速化は夢」
実際の構造    メモリ制約 … 総284B（＋ドラフト）を格納できるHBM容量が要る
              速度制約   … 実際に計算するのは活性13Bなので単発は速い

この分離を理解しないと、オンプレ導入の可否判断を根本から誤る。「総パラメータが大きい＝重い＝無理」という直感は、MoE時代には通用しない。

3. 技術的な核心（1）なぜ「1枚」に載るのか

ここでハードウェアの話に移る。AMD Instinct MI300X の公式ページが公表するスペックの肝は、192GBのHBM3メモリと約5.3TB/sの帯域である。比較対象のNVIDIA H100 SXMは80GBなので、容量で2.4倍の差がある。

実証リポジトリのメモリ内訳を見ると、この容量差が決定的に効いていることが分かる。

MI300X 1基（HBM 約192GB / 実効205.8GB相当）での配分例
──────────────────────────────────────────────
モデル重み（HBM常駐）      156.67 GB   ← 量子化なしで丸ごと載る
GPU側 KVキャッシュ          20 GB      （fp8_ds_mla, 256トークンブロック）
──────────────────────────────────────────────
高負荷時のGPU使用量  204.5 / 205.8 GB（ほぼ上限まで使い切る）
CPUオフロード階層     96 GB           （追い出したprefixキャッシュの退避先）

重要なのは、モデル重みをPCIe越しにストリーミングしたりレイヤーをオフロードしたりせず、丸ごとHBMに常駐させている点だ。80GBのGPUだと重みだけで載り切らず、層をまたぐたびに外部メモリと往復が発生して速度が出ない。192GBという容量が、この往復を消してしまう。

性能面では、単発のデコードで中央値168.6トークン/秒、8ストリーム同時で合計542トークン/秒、64ストリームのバーストで830トークン/秒まで出ている。プリフィルはチューニング済みカーネルで毎秒7.9〜8.5Kトークン、検証済みコンテキストは256Kである。

つまりフロンティア級モデルをオンプレで動かせるかどうかは、これからGPUの「演算性能」ではなく「メモリ容量」で決まる場面が増える。そしてメモリ容量という土俵では、NVIDIA一択ではなくなっている。ここは日本のインフラ調達にとって見逃せない変化だ。

4. 技術的な核心（2）移植の落とし穴 ― FP8 FNUZとMoEルーティング

ここが本記事のいちばん伝えたい部分である。同じFP8でも、NVIDIAとAMDでビットの意味が違う。

vLLMなどの推論スタックは長らくNVIDIA前提で書かれてきた。そこにMI300Xを持ち込むと、数値フォーマットの微妙な差が牙をむく。vLLMのFP8ドキュメントと ROCm上のFP8量子化チュートリアル（AMD公式）を突き合わせると、次の事実が浮かぶ。

MI300X（gfx942）が使うFP8はAMD独自の float8_e4m3fnuz、表現範囲はおよそ±224
一般的なOCP標準のFP8は float8_e4m3fn、表現範囲はおよそ±240
名前は同じ「E4M3」でも、指数バイアスや無限大・NaNの扱い（FNUZ＝Finite, NaN-only, Unsigned zero）が異なる

同じ8ビットのつもりでスケール定数を流用すると、最悪の場合に2倍のスケール誤差が入る。これは「動かない」のではなく「動くのに答えがずれる」ため、非常に見つけにくい。

# 概念コード。同じ "FP8 E4M3" でもプラットフォームで意味が違う
# NVIDIA (OCP)     : torch.float8_e4m3fn   ≈ ±240
# AMD MI300X (gfx) : torch.float8_e4m3fnuz ≈ ±224

def dtype_for_platform(platform):
    if platform == "rocm_gfx942":         # MI300X
        return "float8_e4m3fnuz"          # FNUZ 変種
    return "float8_e4m3fn"                # OCP 標準

# 危険なコード ── NVIDIA前提のスケール定数をそのまま使うと
#   量子化・逆量子化の基準がずれ、最悪 factor-of-two のスケール誤差
scale = compute_scale(tensor, assume="float8_e4m3fn")   # ← ここが罠

# 正しいコード ── 実行プラットフォームの dtype に合わせて基準を取り直す
scale = compute_scale(tensor, assume=dtype_for_platform(current_platform))

これは机上の空論ではない。実際にvLLMには MI300XでFP8 KVキャッシュの精度がおかしくなる不具合（Issue #45562）が報告されており、FP8をvLLMに導入する初期の設計議論 Discussion #2461 から続く根の深いテーマだ。今回のリポジトリも、fused_compress_quant_cache のFNUZ変換を補正するパッチをMI300X用に当てている。

もう一つの落とし穴がMoEのルーティングだ。リポジトリの記録によれば、MXFP4エキスパートを扱うbitmatrixカーネルのパディングが誤ったテンソル境界でマスクされ、長いプロンプトで「よく似たツール名の取り違え」や「スキーマの忘却」が起きていた。これを1行のマスク修正で直している。

ここが実務上いちばん怖いところである。文法エラーやクラッシュなら気づけるが、この種の劣化は次のように現れる。

症状の出方
  短いプロンプト        … 一見正常、ベンチマークも通る
  長いプロンプト＋ツール … 似た名前のツールを取り違える／スキーマを一部忘れる
  結果                  … エージェントが静かに誤動作、原因はモデルではなく移植バグ

「モデルが賢くなったはずなのにエージェントの精度が落ちた」とき、犯人はプロンプトでもモデルでもなく、量子化フォーマットとカーネルの移植だった、という事態が現実に起きる。オンプレ推論を評価する担当者は、ツール呼び出しと長文スキーマを含む回帰テストを必ず持つべきだ。

5. 日本の実務への示唆 ― 「安いから」ではなく「出せないから」で選ぶ

ここで冷静にコストを見ておきたい。HackerNewsの議論では、率直な経済分析が交わされている。

MI300Xは単体販売されず、8基入りの箱（およそ25万ユーロ）で調達する
クラウドなら1時間あたり約1.99ドルで借りられる
しかしDeepSeek公式APIは入力100万トークン0.14ドル、出力0.27ドルと極端に安い
830トークン/秒で1時間回しても生成は約300万トークン、API換算で0.5ドル前後

つまり純粋なコスト勝負では、自社でGPUを回すより公式APIを叩くほうが安い場面が多い。ここを取り違えて「オンプレは安上がり」と稟議を通すと、後で梯子を外される。

自社運用が正当化されるのは、コストではなくデータを外に出せない事情があるときだ。HNの参加者も、自己ホストが意味を持つのはプライバシー、知的財産の保護、規制産業の三つだと整理している。日本の文脈に置き換えると次のようになる。

金融・医療・自治体で、要配慮個人情報や機微情報をプロンプトに載せざるを得ない
設計データやソースコードなど、競争力の源泉を推論のたびに国外へ送りたくない
デジタル庁のガバメントクラウドや経済安全保障の文脈で、データの管轄権（どの国の法律が及ぶか）が問われる

IPAの情報セキュリティ10大脅威 2026 が示すように、サプライチェーンや情報漏えいは組織にとって上位の脅威であり続けている。推論基盤を自社に引き込むという判断は、こうしたデータ主権の要請に応えるためのものだと位置づけるのが筋だ。安さは副次的なメリットにすぎない。

判断のフレームは次のように単純化できる。

オンプレ推論を選ぶ判断フロー
──────────────────────────────
プロンプト/生成物を国外APIに出せるか？
   └ 出せる  → まず公式APIを使う（自前運用よりほぼ安い）
   └ 出せない → 自社/国内クラウドで推論
        必要な総パラメータ量 → HBM容量でGPUを選ぶ（H100 80GB か MI300X 192GB か）
        活性パラメータ量     → 目標スループットを見積もる
        数値フォーマット      → FP8がFNUZかOCPか、KVキャッシュ精度を回帰テスト
        供給性               → GPU調達リード時間と代替（例 MI350P PCIe 144GB）

供給面でも選択肢は広がりつつある。HNでは、今後登場するPCIe版のMI350P（144GB）でもMXFP4のネイティブ量子化のおかげでV4 Flashは載る、という指摘があった。8基入りの箱を買えない中小の現場でも、1〜2枚差しのサーバーでフロンティア級を動かせる時代が近い。

6. まとめ ― エンジニアへのアクションアイテム

DeepSeek V4 FlashをMI300X 1基で動かした今回の実証は、三つの実務的な学びを残した。

第一に、MoEの評価は総パラメータではなく、メモリは総パラメータで速度は活性パラメータで、と分けて見積もること。304Bという見出しの数字に惑わされない。

第二に、オンプレ推論の是非は安さではなくデータ主権で決めること。出せるデータなら公式APIのほうが安い。自社で回す理由は、金融・医療・自治体のように、そもそも外へ出せないデータを扱うからである。

第三に、NVIDIA前提の推論スタックをAMDへ移すときは、FP8のFNUZとOCPの違い、MoEルーティングのカーネルバグという二つの落とし穴を疑うこと。クラッシュしないサイレントな品質劣化こそが最も危険で、ツール呼び出しと長文スキーマを含む回帰テストがそれを捕まえる唯一の網になる。

具体的な最初の一歩として、次を推奨したい。
①自社が扱うデータのうち国外APIに出せないものを棚卸しする。
②出せないデータがあるなら、MI300XやMI350Pをクラウドで1〜2時間借り、自社の代表的なプロンプトとツール群で回帰テストを流し、精度とスループットを実測する。
この一手間が、フロンティア依存とオンプレ自立のあいだの、自社にとっての正しい線引きを教えてくれる。

参考ソース

DeepSeek-V4-Flash-0731 公式モデルカード（Hugging Face） ― 総パラメータ・投機デコードモジュール・MITライセンス・FP8(E4M3)・ベンチマークの一次情報
deepseek-v4-flash-mi300x（GitHub 実証リポジトリ） ― MI300X 1基での本番構成・メモリ内訳・vLLM起動フラグ・FNUZ/MoE補正パッチの一次記録
HackerNews 議論スレッド（id=49166386） ― 供給形態(8基箱/クラウド$1.99h)・スループットと採算・MI350Pなど代替の議論
Simon Willison による解説 ― 総/活性パラメータ・価格($0.14/$0.27 per M)・コスト対能力の位置づけ
AMD Instinct MI300X 公式ページ ― 192GB HBM3・約5.3TB/s帯域・CDNA3の一次スペック
vLLM FP8量子化ドキュメント ― FP8(W8A8/E4M3)の一次仕様
ROCm上のFP8量子化チュートリアル（AMD公式） ― AMD Quark/vLLMでのFP8量子化の一次手順
vLLM Issue #45562（MI300XのFP8 KVキャッシュ精度不具合） ― FNUZ変種の取り扱いが精度に影響する実バグ
vLLM Discussion #2461（RFC: FP8 in vLLM） ― FP8対応の設計経緯
デジタル庁ガバメントクラウド ― 国内のデータ主権・クラウド調達の文脈
IPA 情報セキュリティ10大脅威 2026 ― 国内の脅威動向
DeepSeek V4 Flash 0731（Ollama ライブラリ） ― モデル公開状況の裏付け