DeepSeek V4 Flash×llama.cpp｜対応状況と測定方法

結論：llama.cpp本流へマージ済み

DeepSeek V4対応は、llama.cppの公式PR #24162が2026年6月29日にmergeされました。したがって「本流はまだWIP」という旧記述は現在は誤りです。ただし、upstreamにmodel実装が入ったことと、任意のGGUF・backend・1M contextで安定運用できることは分けて判断します。

確認日: 2026年8月12日 23:00（Asia/Tokyo）
固定した版: llama.cpp b10375 / ba360efe、DeepSeek V4 merge commit 8c146a83、vLLM v0.27.1 / 6e448d0
調査方法: 公式model card、llama.cpp公式PR/release/issues、vLLM公式releaseによる机上調査。model download、GGUF変換、推論、benchmarkは実施していません。
未検証範囲: GGUFごとの品質、必要memory、1M context、Metal/CUDA/ROCm/Vulkan別の安定性と速度、tool calling、複数request。

DeepSeek V4 Flashの公式仕様

DeepSeek公式model cardは、DeepSeek V4 Flashを総284B・活性13BのMoE model、context length 1Mとして掲載しています。Instruct weightはMoE expertにFP4、その他の多くにFP8を使うmixed precisionです。model cardのtechnical reportは2026年6月22日のcommit 60d8d70まで更新されています。

項目	公式model cardの記載
総parameter	284B
活性parameter	13B
最大context	1M token
Instruct weight	FP4 + FP8 mixed
license	MIT

「活性13B」はweight file全体が13B相当という意味ではありません。また、1M contextはmodel仕様上の上限であり、手元hardwareでその長さを確保できる保証ではありません。実際のmemoryにはweight、KV cache、compute buffer、runtime、OSの使用分が含まれます。

llama.cpp対応の時系列

2026年4月24日、公式model request #22319がopen。
community branchで実験が進み、公式本流とは別の状態が続いた。
2026年6月29日、DeepSeek V4 PR #24162がmerge。
model requestは同日にcompletedとしてclose。
2026年8月12日公開のb10375はmerge後のreleaseで、現行本流にDeepSeek V4実装を含む。

以前のWIP branchや当時のperformance値を、現在のupstream releaseの標準値として残すことはできません。検証ではrelease tagとGGUF hashを固定します。

「対応済み」の範囲

llama.cpp本流対応から確認できるのは、DeepSeek V4 architectureをupstream codeで扱う経路がmergeされたことです。次は別確認が必要です。

使用するSafetensorsからGGUFへの変換が完了するか
選んだquantizationで出力品質を保てるか
modelと必要contextがmemoryへ収まるか
Metal、CUDA、ROCm、Vulkanの各backendで同じ結果になるか
chat template、reasoning、tool callがapplication要件を満たすか

DeepSeek公式repositoryは公式weightと推論情報の一次資料ですが、任意のthird-party GGUFの正しさまでは保証しません。GGUFを利用する場合は、配布者、変換元revision、quantization、file hash、licenseを記録します。

vLLMとの選び分け

vLLM v0.27.1のmodel registryとDeepSeek V4 implementationは、このarchitectureへの対応を掲載しています。DeepSeek公式model cardが直接案内する推論手順は付属repositoryのinference/README.mdであり、次のvLLMコマンドは上流実装を確認するための最小構成例です。

vllm serve "deepseek-ai/DeepSeek-V4-Flash" --host 127.0.0.1

vLLM v0.27.1は2026年8月11日の現行releaseです。元のSafetensorsとvLLM上流の対応実装を優先するならvLLM、GGUF量子化、CPU/GPU offload、複数backendを細かく制御するならllama.cppが候補です。

ただし、この1行だけで全hardwareへ収まるわけではありません。vLLM側でも対応dtype、available memory、tensor parallel、container/PyTorch/CUDAの組み合わせを確認します。

llama.cppで測定する前準備

llama.cppをb10375などのrelease tagへ固定する。
公式build guideに従い、対象backendでbuildする。
GGUFの変換元model revisionとSHA-256を保存する。
短いpromptで読み込み・生成・終了を確認する。
baseline modelでも同じbackendが正常か確認する。

modelが読み込めても、出力が反復、文字化け、無関係な文章になる場合は成功扱いにしません。短い事実質問だけでなく、長文、reasoning、chat template、複数turnを含むgolden promptを用意します。

再現可能なbenchmark

llama-bench documentationに沿う最小例です。

./build/bin/llama-bench \
  -m /path/to/deepseek-v4-flash.gguf \
  -p 512 \
  -n 128 \
  -r 5 \
  -o json

記録する条件は次です。

llama.cpp tag/commit、compiler、backend、driver
GGUF file名、size、quantization、hash
prompt processing token数とgeneration token数
n-gpu-layers、batch、ubatch、KV cache type、context
warm-up、反復回数、error/OOM

llama-benchはtokenizationとsampling時間を含みません。chat applicationの評価では、HTTP/API、prompt rendering、tokenization、samplingを含むend-to-endのTTFTとtotal latencyも測ります。

既知issueを確認する

対応merge後もbackend固有のissueは起こり得ます。たとえばROCm/Strix Haloのgarbled output issue #25436は、2026年8月11日の最終更新時点でopenです。対象hardwareを使う場合はrelease notesだけでなく、同じmodel・backendのopen issueを確認します。

issue報告のcommunity benchmarkは有用な再現資料ですが、異なるfork、GGUF、GPU、contextの値を自分の環境の期待値として引用しません。

現時点の判断

本流対応: あり。PR #24162がmerge済み。
公式weightからのserve: vLLM上流にmodel実装あり。DeepSeek model cardの直接の案内は付属推論repository。
llama.cppの安定性: backend、GGUF、contextごとの検証が必要。
1M context: model仕様。この記事では実機検証なし。
performance値: 実測していないため掲載なし。

公式・一次資料

本流mergeによって「試せるか」という問いは前進しましたが、「自分のhardwareで安全に運用できるか」は固定条件の品質試験とbenchmarkで判断します。