DeepSeek V4.1-Flash 最速解説 — 552B MoE・KVキャッシュ890バイト/token

DeepSeekが2026年9月10日（北京時間）、新モデルDeepSeek V4.1-Flashを発表した。総パラメータ552BのMoEモデルで、アクティブパラメータはprefill時8B・decode時16Bと軽量。最大の技術的特徴はKVキャッシュがFP4主体で約890バイト/tokenまで圧縮されている点で、前世代のV4-Flashと比べて約4分の1（3.9分の1）の水準になる。重みはMITライセンスで公開され、ローカル実行・商用利用ともに可能である。

本記事は発表当日時点の一次情報とモデルカードの公表値にもとづく。DeepSeek公式のシステムカード・完全なベンチマーク表はまだ公開されておらず、流通している一部の速度・品質値はコミュニティ計測や報道経由の情報である点をあらかじめ断っておく。既存のV4系記事も合わせて参照したい: DeepSeek V4 必要スペック早見表、DeepSeek V4-Pro 0813 GA、DeepSeek V4-Flash ビジョン対応。

V4.1-Flashは従来のデコーダのみのTransformerとは異なり、非対称のCausal Encoder–Decoder構成（20層エンコーダ＋20層デコーダ）を採用している。MoE層は1つのshared expertと384のrouted expertから構成され、トークンごとにルーティングされたエキスパートのみが計算に参加する。この設計により、総552Bという規模を持ちながら、実際の計算負荷はprefill時8B・decode時16Bという小さなアクティブパラメータに抑えられている。

コンテキスト長は最大1Mトークンまで対応し、推論努力量（reasoning effort）を1〜100の範囲で連続的に制御できる点も特徴である。段階的なモード切り替えではなく数値指定で思考の深さを調整できるため、レイテンシとコストのチューニングがしやすい。

マルチモーダル対応も強化されており、DeepSeek-ViTと呼ばれるビジョンエンコーダをネイティブに搭載する。2D-RoPE（2次元回転位置エンコーディング）で学習されており、画像とテキストを同一のアーキテクチャで扱える。学習はマルチモーダル45Tトークンで実施され、34Tトークンの時点でコンテキスト長を1Mへ拡張したと公表されている。

V4.1-Flashで最も実務的なインパクトが大きいのがKVキャッシュの圧縮である。FP4（E2M1形式）を主体としたキャッシュ表現により、1トークンあたり約890バイトまで削減された。これは前世代のV4-Flashと比べて約4分の1（3.9分の1）の水準にあたる。

計算式はシンプルで、890バイト × 100万トークン ≒ 0.89GB。つまり1Mトークンの長文脈をフルに使っても、KVキャッシュは1GBに満たない。長文脈モデルでKVキャッシュが数十GB〜100GB級に膨らむケースが珍しくないことを踏まえると、この圧縮率は長文脈運用時のメモリ設計を根本的に変えるインパクトを持つ。重みの容量に対してKVキャッシュがほぼ無視できる水準になったことで、長文脈利用時の追加メモリを個別に見積もる必要性が大きく下がった。

公表されているベンチマーク値は限定的だが、傾向ははっきりしている。セキュリティ・エージェント系のタスクでは既存トップモデルを上回る結果が報告されている一方、汎用的な推論・ターミナル操作系のベンチマークでは見劣りする結果も同時に出ている。

CyberGym（セキュリティ攻防系）とAutomation-Bench（自動化タスク）では既存トップモデルを上回り、DeepSWE（ソフトウェア工学エージェント）ではClaude Opus 5とほぼ同水準にある。一方でTerminal-Bench 3.0（ターミナル操作の連続タスク）とHLE（Humanity's Last Exam、汎用推論）では明確に劣後しており、特にHLEの差は大きい。552BのMoEでアクティブパラメータが8B/16Bという軽さを踏まえれば、セキュリティ・自動化系タスクへの最適化が先行し、汎用推論力は発展途上という読み方が自然である。

繰り返しになるが、DeepSeek公式のシステムカード・完全なベンチマーク表は本記事執筆時点で未公開であり、上表を含め流通している評価値の一部はコミュニティ計測や報道経由の情報である。採用判断の前に公式発表の更新を確認したい。

上表はオフピーク時の単価で、平日UTC 01:00〜04:00 と 06:00〜10:00 のピーク時間帯は倍額になる。日本時間ではUTC+9のため、ピーク時間帯はおおむね午前10時〜13時と15時〜19時にあたる（日付をまたぐ場合は要確認）。バッチ処理や大量推論をこの時間帯の外に寄せられるかどうかで、実効コストが最大2倍変わる設計である。

キャッシュヒット時の入力単価はキャッシュミス時の50分の1という水準にあり、同じシステムプロンプトや長文ドキュメントを繰り返し参照する用途（コードベース解析、社内文書QAなど）では、プロンプトの前方一致設計がそのままコスト削減に直結する。

重み容量の目安は「総パラメータ × bit ÷ 8」で計算できる。552Bの場合、4bitで約276GB、8bit（FP8）で約552GB、BF16で約1.1TBとなる。実運用ではここに10〜20%のオーバーヘッドを見込む必要がある。一方でKVキャッシュは前述のとおり1Mトークンでも約0.89GBに収まるため、必要メモリのほぼ全量が重みで決まる点がV4.1-Flashの実務的な特徴である。

率直に言えば、552BというサイズはコンシューマーGPUや単体Macでの実行を想定した規模ではない。4bit量子化まで攻めても276GB前後の重みをVRAMに載せる必要があり、中小規模の組織であってもH100やH200を複数枚束ねたサーバー級環境が前提になる。KVキャッシュの軽さは長文脈運用時の追加負担をほぼゼロにする利点だが、それは「動くサイズになった」ことを意味しない。ローカル導入を検討する場合は、まず自社の予算とインフラでこの規模のGPUクラスタを用意できるかを先に確認すべきである。既存のVRAM早見表・量子化の考え方はDeepSeek V4 必要スペック早見表も参照されたい。

V4.1-Flashが向くのは、第一にAPI経由でセキュリティ検証・自動化エージェント用途を試したい組織である。CyberGymやAutomation-Bench相当のタスクで既存モデルを上回る結果が出ている以上、脆弱性診断や運用自動化のパイプラインに組み込む価値は検討に値する。第二に、1Mトークン級の長文脈をAPI経由で扱いたい開発者にとって、KVキャッシュの軽さは（自前でホストしない場合でも）サーバー側のスループットやレイテンシに好影響を与えうる設計として注目できる。

一方、汎用的な推論力やターミナル連続操作を重視する用途では、HLE・Terminal-Bench 3.0の結果を見る限り他モデルに分がある。自社でのローカルホスティングを前提にする場合は、552Bという規模に見合うGPUクラスタを構築・運用できる体制があるかどうかが導入の分岐点になる。予算や環境が対応しないなら、まずはAPI経由での評価から始めるのが現実的である。