2026年9月10日、DeepSeekは新アーキテクチャファミリーの中で最小サイズのメンバーであるDeepSeek-V4.1-Flashをリリースした。これは通常のバージョンアップではなく、552B総パラメータのMoEとまったく新しいCausal-Encoder-Decoder（CED）非対称アーキテクチャを組み合わせたものである。入力側では8Bのみを活性化し、出力側では16Bを活性化し、KV Cacheの積極的な圧縮と相まって、HBM要件を前世代の1/4、SSDストレージを1/8にまで抑え、初代DeepSeekと比べて全体で約437倍の縮小を実現している。1Mトークンのコンテキスト、384Kトークンの最大出力、ネイティブマルチモーダル、そして3段階の思考強度の組み合わせにより、FlashのベンチマークスコアはV4 Proを全面的に上回っている。本記事は2部構成で展開し、本パートではまずアーキテクチャとコスト計算を分解し、次パートでエンジニアリングの実装と移行戦略を扱う。CEDの非対称活性化を理解することが、Flashのあらゆるコスト優位性を理解する出発点である。
CED非対称アーキテクチャの全体像：552B MoEがなぜ入力側で8Bのみ、出力側で16Bを活性化するのか
Causal-Encoder-Decoderの設計直感は、「長い入力を読み解く」ことと「長い出力を書き出す」ことを2つの別々の計算予算に分割するというものである。入力側は1Mトークンのコンテキストに直面し、そのタスクは本質的にエンコーディングである。つまりコンテキストをデコーダが繰り返しクエリできる表現に圧縮する。出力側は384Kトークンの生成に直面し、新しいトークンはそれぞれ完全なアテンションとFFNのフォワードパスを通過する必要があり、推論コストの真の増幅要因となる。そこでFlashはMoEルーティングにおいて非対称な分割を行った。入力側では8Bのみを活性化し、出力側では16Bを活性化する。
この比率は場当たり的なものではない。入力側は1Mトークンのプリフィルとエンコーディングを一度に処理するため、活性化パラメータを非常に高く積み上げると、プリフィルの計算ピークとメモリ帯域が瞬時に飽和してしまう。一方で入力側のエンコーディング品質は「デコーダがクエリするのに十分」であればよく、8Bの活性化で長文ドキュメント、コードベース、マルチモーダル視覚特徴といった、理解は必要だが逐語的に再現する必要のないコンテンツをカバーできる。出力側は逆である。生成される各トークンは後続のトークンから依存されるため、出力品質は活性化容量に対してより敏感であり、したがって16Bが与えられる。一言でまとめれば、入力側が買うのは「カバレッジ」であり、出力側が買うのは「生成品質」である。
推論コストへの影響は二重である。第一に、プリフィル段階（長コンテキストで最も高価な段階）は8Bの活性化規模で課金されるため、単一トークンあたりの活性化計算量は同時期の同規模モデルよりも明らかに低い。第二に、デコード段階は16Bの活性化規模で課金され、完全対称の16B入出力モデルと比べて入力側の冗長分を節約できる。後述するKV Cache圧縮と相まって、Flashのキャッシュミス時の入力価格はアイドル時1元/百万トークン、ピーク時2元/百万トークンとなり、出力はアイドル時4元、ピーク時8元となる。V4 Flashと比較してキャッシュヒットで60%、ミスで約33.3%、出力で約11.1%の値下げとなる。価格構造そのものが、非対称活性化がもたらすコスト曲線を反映している。
強調すべきは、CEDの「非対称」とは活性化パラメータ数の非対称だけでなく、計算モードの非対称でもあるという点だ。入力側はエンコーダ的な因果アテンションであり、出力側こそが標準的な自己回帰デコードである。この2つのセグメントは同一の552B MoEベースを共有し、ルーティングとゲーティングによって段階ごとに異なる活性化サブセットを選択するのであって、2つの独立したモデルではない。これが、単一モデルとして外部にサービスを提供し、deepseek-flashという1つのモデル名だけを公開できる理由でもある。
Causal-EncoderとDecoderの責務分担：1Mコンテキストのアテンションパスはどう通るか
アテンションパスにおいて、Causal EncoderとDecoderの役割分担が、キャッシュをどこに書き、どこで読むかを決定する。入力側のCausal Encoderは1Mトークンに対して完全な因果アテンションのフォワードパスを一度行い、各層のK/V表現を計算してKV Cacheに書き込む。出力側のDecoderは生成時に、これらのすでに固定化されたK/Vを読み取り、自身が新たに生成するトークンに対してのみ新しいK/Vエントリを追加する。言い換えれば、キャッシュの書き込みはエンコーディング段階で発生し、キャッシュの読み取りがデコーディング段階を支配する。この分割により、入力側の重い処理は一度だけ行われ、デコーディング側の各ステップは可能な限り軽くなる。
この分担が1Mトークンを支えられる鍵は、アテンション計算のチャンク化とスパース化がEncoder側で完了し、Decoder側は「既存の圧縮キャッシュ＋新規トークン」という小さなワーキングセットにのみ直面する点にある。1MコンテキストのすべてのK/Vをそのまま保持すれば、メモリ要件は長さに比例して爆発する。Flashの手法は、Encoderがキャッシュに書き込む前に淘汰と量子化を完了させることで、キャッシュに入るエントリを数とビット幅の両方で圧縮する。これが、HBMとSSDという2つの公式指標が同時に大幅に低下できる構造的な基盤である。
エンジニアリング上、直感に反する点を1つ理解する必要がある。1Mコンテキストは、1Mのアテンション行列が常駐メモリに載ることを意味しない。Flashはチャンク化プリフィルによって長い入力を複数のチャンクに分割し、チャンクごとにエンコードし、チャンクごとにキャッシュを書き込むため、ピークメモリはチャンクサイズとキャッシュエントリ数にのみ依存し、総長に線形には依存しない。これが、バッチ処理のシナリオでも1Mコンテキストを提供できる前提である。以下の呼び出し例は、超長入力の基本的な形を示している。
from openai import OpenAI
client = OpenAI(
api_key="your-deepseek-api-key",
base_url="https://api.deepseek.com"
)
# 1Mトークン級の長文ドキュメント入力：Causal Encoderのチャンク化プリフィルに依存
# 思考モードはデフォルトで有効。ここでは長コンテキスト推論を観察しやすいようmaxを明示指定
resp = client.chat.completions.create(
model="deepseek-flash",
messages=[
{"role": "system", "content": "你是一名严谨的长文档分析助手。"},
{"role": "user", "content": long_document + "\n\n请给出结构化的风险清单。"}
],
extra_body={"thinking": {"type": "enabled", "intensity": "max"}}
)
print(resp.choices[0].message.content)
KV Cache圧縮革命：HBMが1/4、SSDが1/8に低下するメカニズムの導出
公式に示された2つの数字は、Flashの経済性を理解する核心である。HBM要件は前世代の1/4、SSDストレージは1/8に低下し、初代DeepSeekと比べて約437倍の縮小。圧縮は2つのレベルで発生する。第一に、キャッシュ構造そのものが再構築され、Encoder側が書き込むのは淘汰と量子化を経たコンパクトなK/V表現であり、層数×ヘッド数×ビット幅の積が体系的に小さく圧縮される。第二に、スケジューリングのレベルで、コールドキャッシュをSSDに降格し、ホットキャッシュをHBMに留める階層型キャッシュを形成する。1/4はHBM層の容量低下に対応し、1/8はSSD層のストレージ低下に対応しており、両者は同じ数字の2つの見方ではない。
437倍という桁の由来は、「同等のコンテキスト規模における初代DeepSeekのキャッシュフットプリント」と「Flashの圧縮後の階層型キャッシュフットプリント」の比を取ったものである。これはアーキテクチャの世代的な利得、非対称活性化によるキャッシュエントリの削減、そして量子化と淘汰戦略を同時に重ね合わせている。この点を理解することが重要である。437倍は単一の技術によってもたらされたものではなく、アーキテクチャ＋キャッシュ構造＋階層型スケジューリングの積である。これを何か1つのトリックに帰属させる主張は正確ではない。
開発者にとっての直接的な意味は、キャッシュヒットの価値が増幅されることである。公式価格では、キャッシュヒットの入力はアイドル時わずか0.02元、ピーク時0.04元/百万トークンであるのに対し、ミスはアイドル時1元、ピーク時2元である。ヒットとミスの価格差は50倍に達する。これは、長コンテキスト、マルチターン対話、繰り返しのシステムプロンプトのシナリオにおいて、プレフィックスを安定させキャッシュを再利用することが、モデルを切り替えるよりも効果的なコスト削減手段であることを意味する。以下の表は、異なる手法のキャッシュとコストのトレードオフを比較したものである。
| 手法 | HBMキャッシュ占有 | SSD階層化 | 入力課金（アイドル/ピーク） | 適用シナリオ |
|---|---|---|---|---|
| キャッシュなし、毎回全量再計算 | 高（ピークが長さに応じて増加） | 使用しない | 1元 / 2元 | 一度きりの短いリクエスト |
| プレフィックスキャッシュヒット | 低（コンパクトなK/Vを再利用） | 任意 | 0.02元 / 0.04元 | マルチターン対話、固定システムプロンプト |
| 長文書 + コールドキャッシュのSSD退避 | さらに低減 | 有効 | ヒット価格 + コールドスタート遅延 | 1Mコンテキストのバッチ処理 |
エンジニアリング上の落とし穴は次の点にある。キャッシュヒットの前提はプレフィックスがバイト単位で一致していることだ。システムプロンプトにタイムスタンプやランダム ID を挿入するいかなる手法も、ヒット率をゼロにし、コストを 0.02 元から 1 元へ押し戻してしまう。安定したプレフィックスを保ち、可変な内容を user メッセージの末尾に置くことが、長コンテキストアプリケーションの基本規律である。
1M 入力と 384K 最大出力：長コンテキスト下における VRAM とスループットのエンジニアリング制約
1M tokens のコンテキストと 384K tokens の最大出力は二つの独立した制約であり、混同してはならない。1M は入力側で Encoder が符号化すべき長さであり、384K は Decoder が一度に生成できる上限である。両者がエンジニアリングに課す要求は異なる。入力側ではチャンク化プリフィルとキャッシュ書き込みのピーク管理を解決する必要があり、出力側では長い生成過程における VRAM の定常状態とストリーミング返却を解決する必要がある。
バッチ処理のレベルでは、長コンテキストは有効バッチサイズを著しく低下させる。各リクエストの K/V キャッシュが VRAM を占有するため、1M コンテキストのリクエストが並行すると HBM はすぐに使い果たされる。解決策はチャンク化プリフィルである。長い入力を固定サイズのチャンクに分割し、一つずつ Encoder に送り込むことで単一パスのピーク VRAM を制御する。同時にキャッシュヒットを活用し、同じプレフィックスを共有する複数のリクエストに符号化済みの K/V を共有させる。出力側ではストリーミングを必ず有効化しなければならない。384K tokens の出力を全量完了まで待ってから返すのは、現実的でないだけでなく、クライアントができるだけ早く消費するのにも不利である。
ピーク VRAM 管理に関するもう一つの経験則は、同一リクエストで 1M 入力を詰め込みつつ 384K 出力も要求してはならないということだ。入力符号化のキャッシュ占有と出力追記のキャッシュ占有が重なり、上限に近づくと淘汰が誘発されやすく、かえって decode を遅くする。合理的な方法は、「重い入力理解」と「重い出力生成」を二つの段階または二つのリクエストに分け、会話プレフィックス継続で中間結果をつなぐことである。以下はツール呼び出しと JSON 出力を伴う定常状態のリクエスト例である：
import json
from openai import OpenAI
client = OpenAI(
api_key="your-deepseek-api-key",
base_url="https://api.deepseek.com"
)
# JSON Output + Tool Calls の組み合わせ：構造化出力で、下流での解析が容易
resp = client.chat.completions.create(
model="deepseek-flash",
messages=[
{"role": "user", "content": "Read /data/metrics.csv and summarize the anomalous metrics."}
],
tools=[{
"type": "function",
"function": {
"name": "read_file",
"description": "Read a local file",
"parameters": {
"type": "object",
"properties": {"path": {"type": "string"}},
"required": ["path"]
}
}
}],
response_format={"type": "json_object"}
)
print(json.loads(resp.choices[0].message.content))
新しい事前学習手法 + より大規模な RL 事後学習：ベンチマークで V4 Pro を全面的に上回る訓練側からの解釈
公式の表現は「新しい事前学習手法 + より大規模な RL 事後学習を採用し、ベンチマークで V4 Pro を全面的に上回る」である。訓練側から見ると、この二つは異なる能力次元に対応している。新しい事前学習手法が主に改善するのは表現品質と長コンテキスト外挿であり、これが Flash が 1M コンテキスト下でも推論の安定性を維持できる理由を説明する。より大規模な RL 事後学習が改善するのは指示追従、ツール使用、推論チェーンの品質であり、これが Terminal-Bench や CyberGym といった agent 寄り・安全性寄りのベンチマークの向上を説明する。
公式ベンチマークで最も対照すべきは二箇所である。CyberGym 88.1 対 V4 Pro の 83.3、Terminal-Bench 2.1 スコア 90.6 対 V4 Pro の 87.9。これら二項目はいずれも多段階のツール呼び出しと長距離計画に強く依存しており、まさに RL 事後学習の規模拡大が恩恵をもたらす項目である。ハードウェア側の指標も目覚ましい。GPQA Diamond 90.9、Codeforces レーティング 3471、MathArena Apex 65.6 は、推論とコード能力が活性パラメータの小ささによって縮小していないことを示している——非対称活性化が節約するのは推論計算量であり、能力の上限ではない。
抑制すべきなのは、公式が公表したのはこれらのベンチマークスコアと訓練手法の方向性の記述のみであり、事前学習データ量、RL ステップ数、計算規模は公表していないという点である。いかなる具体的な数字も推測してはならない。本段落で確定できるのは、Flash がファミリー最小サイズ、入力側 8B / 出力側 16B の活性規模で、V4 Pro を全面的に上回る成績を収め、訓練側の二つの変数（新しい事前学習手法、より大規模な RL）が帰属可能な二本の主軸であるということだ。
思考モードの三档強度：low / high / max とデフォルト思考モードの呼び出し戦略
Flash は非思考モードと思考モードをサポートし、かつ思考モードはデフォルトで有効である。思考強度は low、high、max の三档に分かれ、遅延、コスト、正確率の三者間のトレードオフに直接対応する。実用的な判断枠組みはこうだ。ルールや検索で答えられるなら非思考を使う。多段階推論が必要だが経路が明確なら low を使う。探索、検証、誤り訂正が必要なら high を使う。agent の長距離タスクや高難度の数学・コードなら max を使う。
コスト面では、思考強度が高いほどモデルが生成する思考 token が増え、出力課金が高くなる。出力はオフピーク 4 元、ピーク 8 元（100 万 tokens あたり）であるため、max 档の長い思考は請求額を明らかに押し上げる。遅延面では、max 档の初回 token 遅延と総所要時間はいずれも low より著しく高い。したがって max をデフォルト値にしてはならない。デフォルトの思考モードは強度未指定時にすでに合理的なバランスを備えており、本当に必要なときにのみ明示的に最大まで引き上げるべきである。
エンジニアリング上の落とし穴は、FIM は非思考モードのみをサポートすることだ。コード補完の経路が FIM に依存しているなら、思考モードを明示的に無効化しなければならない。そうでなければリクエストは失敗するか、FIM の経路に到達しない。これこそが思考強度の設定と機能能力を分離する理由である——両者は直交しない。以下の例は非思考モードの明示的な設定を示している：
from openai import OpenAI
client = OpenAI(
api_key="your-deepseek-api-key",
base_url="https://api.deepseek.com"
)
# 非思考モード：FIM コード補完の唯一の合法な組み合わせ
resp = client.completions.create(
model="deepseek-flash",
prompt="def quicksort(arr):\n ",
extra_body={
"thinking": {"type": "disabled"},
"fim": True
}
)
print(resp.choices[0].text)
FIM は非思考モード限定：コード補完シナリオのインターフェース境界と代替案
公式は FIM が非思考モードでのみ利用可能であることを明確にしている。この境界のエンジニアリング上の意味は、コード補完が独立した、低遅延で、思考チェーンを持たない高速経路であり、agent 型のコード生成とは別の形態だということである。IDE 補完のシナリオでは、低遅延が長い推論よりも重要であるため、思考を無効化して FIM を使うのが正しい選択である。一方、「要件に基づいてファイル全体を書き直す」といったタスクでは、思考モード + Tool Calls または会話プレフィックス継続を使うべきであり、無理に FIM を使うべきではない。
回避すべき設定の組み合わせは二つある。一つは FIM + 思考モード有効で、直接的に不正である。もう一つは FIM + 会話プレフィックス継続で、両者は意味が重複しており混用すべきではない。代替案はこうだ。コンテキストを意識した補完が必要なときは、非思考モード + 長いプレフィックス（ファイルの前文脈を prompt に詰め込む）を使い、プレフィックスのキャッシュヒットで入力コストを下げる。ファイルをまたぐ推論が必要なときは、思考モードに切り替えて chat インターフェースを使う。
JSON Output、Tool Calls、会話プレフィックス継続：構造化出力の実装要点
Flash は構造化出力に関して複数の能力の組み合わせを提供している。JSON Output、Tool Calls、Responses API、Anthropic API、会話プレフィックス継続、そして非思考でのみ利用可能な FIM である。それぞれの適用シナリオは異なる。JSON Output は固定 schema の抽出と分類に適し、下流で直接解析できる。Tool Calls はモデルがどの外部関数を呼ぶかを主体的に決める必要がある agent フローに適する。Responses API はサーバー側で状態を維持し多段階のやり取りが必要なアプリケーションに適する。Anthropic API 互換は、既存の Claude ツールチェーンを持つチームが低コストで移行できるようにする。会話プレフィックス継続は、与えられたプレフィックスの後にモデルに続けさせるのに適し、制御可能な生成と結合に用いられる。 組み合わせて使用する際には重要な制約が1つあります。JSON Output と Tool Calls は共存できますが、思考強度と FIM は排他的です。また、会話プレフィックスの継続生成はキャッシュキーのプレフィックス構造を変えるため、プレフィックスが頻繁に変わるとキャッシュヒット率が低下します。モデル名については、新しいモデル名は deepseek-flash で、同時実行制限は2500です。旧名の deepseek-v4-flash と deepseek-v4-flash-vision-exp は提供終了となりましたが、互換ルーティングは維持されているため、古いコードが直ちにエラーになることはありませんが、できるだけ早く新しい名前に切り替えるべきです。 コストに大きく影響する時点がもう1つあります。北京時間 2026-09-14 12:00 以降、deepseek-v4-pro へのリクエストはすべて V4.1-Flash にルーティングされ、Flash の料金で課金されます。料金は 2026-09-10 12:00 から有効で、ピーク時間は月曜から金曜の 9:00-12:00 と 14:00-18:00、アイドル時間はピークの半額です。バッチ処理タスクをアイドル時間帯に配置すれば、コストを直接半分に削減できます。ネイティブのマルチモーダル視覚理解は、画像リンク、base64、Files API の3つの入力方式をサポートし、ドキュメントやスクリーンショット理解のための統一された入口を提供します。次のセクションでは、上記の機能を移行とチューニングの具体的なエンジニアリング方案に落とし込みます。 前節の CED（Causal-Encoder-Decoder）非対称アーキテクチャの原理分解と KV Cache 圧縮の定量分析——入力側 8B アクティベーション、出力側 16B アクティベーションの責務分離、および HBM を前世代の 1/4、SSD を 1/8 に削減し、初代 DeepSeek と比べて約437倍小さくなったストレージ構造——を受けて、本節では実装層に入り、アーキテクチャ上の優位性を実行可能なエンジニアリング判断に翻訳します。 DeepSeek-V4.1-Flash はネイティブでマルチモーダル視覚理解をサポートし、画像リンク（URL）、base64 インライン、Files API の3つの入力経路を提供します。この3つは単純に等価ではなく、CED アーキテクチャ下では差異が増幅されます。なぜなら、視覚トークンはまずエンコーダ側（8B アクティベーション）で隠れ状態に圧縮され、その後デコーダ側で消費されるからです。どの経路を選ぶかが、呼び出しチェーンの長さ、キャッシュヒット率、帯域コストを直接決定します。 エンジニアリング上の推奨：高頻度で再利用する画像は Files API、単発の小さい画像は base64、すでに公網でホストされている静的画像は URL を使います。必ずバイトレベルでの安定性を確保してください。そうでなければキャッシュヒット率はゼロになります。 2026-09-10 のリリース後、公式 API の正式なモデル名は deepseek-flash です。旧名の deepseek-v4-flash と deepseek-v4-flash-vision-exp は提供終了となりましたが、互換ルーティングは維持されています。これは、本番環境の既存リクエストが名前変更によって 404 になることはなく、透過的に deepseek-flash に転送されることを意味します。エンジニアリング上、これは利点でもあり罠でもあります。利点はゼロ改修での移行であり、罠は互換ルーティングがパラメータの意味の完全な一致を保証しないこと、特に視覚実験版の旧名に対応する一部の視覚パラメータが正規化される可能性があることです。ネイティブのマルチモーダル視覚理解：画像リンク、base64、Files API の3つの入力経路
比較軸 画像リンク base64 インライン Files API リクエストサイズ 極小 約 +33% 極小（id 参照） 外部依存 強い（取得可能である必要） なし なし キャッシュ再利用性 低い 中程度（バイトが安定している場合のみヒット） 高い（id が安定） 呼び出しチェーンの複雑さ 中程度 低い 中程度（アップロード工程が1つ増える） 適用シナリオ CDN ホスト画像 小さい画像/単発推論 再利用画像、バッチタスク import base64
import requests
API_KEY = "your-deepseek-api-key"
BASE = "https://api.deepseek.com"
HEADERS = {"Authorization": f"Bearer {API_KEY}"}
# 経路1：Files API で一度アップロードし、以降は file id で再利用
with open("diagram.png", "rb") as f:
upload = requests.post(
f"{BASE}/files",
headers=HEADERS,
files={"file": ("diagram.png", f, "image/png")},
data={"purpose": "vision"},
).json()
file_id = upload["id"]
# 経路2：base64 インライン
with open("small.png", "rb") as f:
b64 = base64.b64encode(f.read()).decode()
payload = {
"model": "deepseek-flash",
"messages": [{
"role": "user",
"content": [
{"type": "image_url", "image_url": {"url": f"file://{file_id}"}},
{"type": "image_url", "image_url": {"url": f"data:image/png;base64,{b64}"}},
{"type": "text", "text": "2つのアーキテクチャ図の差異を比較し、JSON を出力してください。"},
],
}],
"response_format": {"type": "json_object"},
}
resp = requests.post(f"{BASE}/chat/completions", headers=HEADERS, json=payload)
print(resp.json()["choices"][0]["message"]["content"])
API 移行実践：deepseek-flash モデル名、旧名の互換ルーティング、2500 同時実行制限
deepseek-flash を記述します。古いコードは短期的に旧名を保持できますが、1回のイテレーションサイクル内に置換と回帰テストを完了することを推奨します。import time
import t
2026-09-14 ルーティング切り替え：deepseek-v4-pro リクエストをすべて V4.1-Flash へ転送する互換処理
北京時間 2026-09-14 12:00 より、すべての deepseek-v4-pro リクエストはすべて V4.1-Flash にルーティングされ、Flash の料金で課金されます。これは不可逆的な移行ウィンドウであり、本番システムは事前に次の3つを行う必要があります：
- 能力回帰：公式ベンチマークでは V4.1-Flash が V4 Pro を全面的に上回っていますが（例：GPQA Diamond 90.9、CyberGym 88.1 対 V4 Pro の 87.9 と 83.3）、ご自身の業務データセットで A/B テストを行い、出力スタイル、JSON 構造、ツール呼び出し動作が一致することを確認することをお勧めします。
- コスト予想の再計算：Flash へルーティング後は Flash 料金で課金され、キャッシュヒット 0.02/0.04 元、ミス 1/2 元、出力 4/8 元（アイドル/ピーク）。以前 Pro 料金で予算を組んでいた場合は、再計上し、値下げ分を活用して並行数とキャッシュ戦略を調整する必要があります。
- モデル名の収束：コード内の
deepseek-v4-proを明示的にdeepseek-flashに置き換え、長期的な暗黙的ルーティングへの依存を避け、後のパラメータレベルのカナリアリリースを容易にします。
互換戦略としては、ゲートウェイ層でモデル名マッピングテーブルを実装し、旧名を deepseek-flash に統一して正規化し、元のモデル名を観測用に記録して、切り替え前後の差異を特定しやすくすることをお勧めします。
料金体系とピーク/アイドル時間帯：キャッシュヒット、ミス、出力のコスト最適化の計算
料金は北京時間 2026-09-10 12:00 から有効です。ピーク時間帯は月曜日から金曜日の 9:00-12:00、14:00-18:00で、それ以外はアイドルです。アイドル料金はピークの半額です。V4 Flash と比較して：キャッシュヒットは 60% 削減、ミスは約 33.3% 削減、出力は約 11.1% 削減。
| 課金項目（元/百万トークン） | アイドル | ピーク | V4 Flash 比 |
|---|---|---|---|
| キャッシュヒット入力 | 0.02 | 0.04 | 60% 削減 |
| キャッシュミス入力 | 1 | 2 | 約 33.3% 削減 |
| 出力 | 4 | 8 | 約 11.1% 削減 |
コスト最適化の核心的なレバーはキャッシュヒットです：ヒットとミスの価格差は50 倍（アイドル 0.02 対 1）に達します。安定したプレフィックス（システムプロンプト、ツール定義、固定ドキュメント）をリクエストの先頭に固定し、会話プレフィックス継続とプロンプトキャッシュを活用することで、これらのトークンを 0.02 元の階層に抑えられます。次に、非リアルタイムタスクをアイドルウィンドウに移動し、直接半減させます。出力側は 11.1% しか削減されないため、出力長の制御（例：max tokens の制限、JSON Output による構造の制約）が入力の圧縮よりも投資価値があります。
公式ベンチマーク深読み：GPQA Diamond 90.9、Codeforces 3471、Terminal-Bench 2.1 90.6 の能力プロファイル
公式ベンチマークは明確な能力プロファイルを示しています：
- GPQA Diamond 90.9：大学院レベルの科学 Q&A で、トップレベルに迫り、CED デコーダ側の 16B アクティベーションが複雑な推論チェーンで非常に効率的であることを示しています。
- Codeforces レーティング 3471：競技レベルのプログラミングで極めて高い水準に達し、Tool Calls と FIM（非思考のみ）と組み合わせて、コード補完と自動修復に適しています。
- MathArena Apex 65.6：高難度数学ベンチマークで、思考モードが長鎖推論で得られる利得を体现しています。
- Terminal-Bench 2.1 スコア 90.6：ターミナル/コマンドラインタスクエージェント能力が突出しており、エージェント実行層として適しています。
- CyberGym 88.1：サイバーセキュリティシナリオのスコアで、V4 Pro の 83.3 と比較して明らかに向上しています。
V4 Pro との対比：公式の数値は GPQA Diamond 90.9 対 87.9、CyberGym 88.1 対 83.3 で、その他の項目も全面的に上回っています。これはPro から Flash への移行がダウングレードではなくアップグレードであることを意味し、しかもコストが低くなります。
オープンソースとエコシステム連携：Hugging Face の重み、技術レポート、WorkBuddy、OpenCode 統合
公式は重みを Hugging Face で公開し、技術レポートを添付しており、CED 非対称構造、KV Cache 圧縮の詳細、トレーニングレシピをカバーしています。自社開発チームにとって、これはプライベート環境で量子化、蒸留、ドメイン微調整が可能であることを意味します。エコシステム側では、公式パートナーの WorkBuddy（CodeBuddy を含む）と OpenCode が完全に統合され、開発者はこれらのツールで V4.1-Flash の視覚、ツール呼び出し、長コンテキスト能力を直接利用でき、統合のハードルが下がります。
- 重み：Hugging Face から直接取得し、技術レポートと合わせて CED 実装の詳細を理解できます。
- WorkBuddy / CodeBuddy：オフィスとコーディングシナリオ向けのプラグアンドプレイ統合。
- OpenCode：オープンソースコーディングワークフロー向けの統合で、自動化開発プロセスに適しています。
- API 側：JSON Output、Tool Calls、Responses API、Anthropic API、会話プレフィックス継続、FIM（非思考のみ）がすべて利用可能です。
CED 非対称アーキテクチャのエンジニアリングの落とし穴：キャッシュ一貫性、マルチモーダル混在、長出力切り捨てのトラブルシューティングチェックリスト
CED の非対称設計（入力 8B アクティベーション、出力 16B アクティベーション）は効率をもたらす一方で、いくつかの典型的な問題も引き起こします：
- キャッシュ一貫性の落とし穴：プレフィックス内のあらゆるバイト変化（タイムスタンプ、ランダム id、画像再エンコード）がキャッシュミスを引き起こし、コストが 0.02 から 1 元に跳ね上がります。トラブルシューティング：動的フィールドをプレフィックスの後に移動し、システムプロンプトとツール定義を固定；画像はまず Files API にアップロードして安定した id を取得。
- マルチモーダル混在の落とし穴：視覚トークンとテキストトークンが交互に並ぶとき、画像の順序やプレースホルダ方式が不安定だとキャッシュプレフィックスが壊れます。トラブルシューティング：content 配列内の画像の位置と順序を統一し、base64 または id のバイトレベル一致を維持。
- 384K 長出力切り捨ての落とし穴：最大出力は 384K トークンで、超えると切り捨てられます。トラブルシューティング：max_tokens 上限を設定し finish_reason を検出；切り捨て時は全量再試行ではなく継続（会話プレフィックス継続）を使用。
- 思考モード切り替えの落とし穴：デフォルトは思考モードで、low/high/max の3段階の強度が遅延とコストに影響します。トラブルシューティング：非推論タスクでは思考を明示的にオフにし、FIM は非思考時のみ利用可能。
- 並行数とレート制限の落とし穴：2500 並行上限の下では、バーストトラフィックが 429 を引き起こしやすいです。トラブルシューティング：ローカルセマフォ + 指数バックオフ、バーストと持続負荷を区別。
まとめとベストプラクティス
- モデル名の統一：新規コードは常に
deepseek-flashを使用；旧名deepseek-v4-flash/deepseek-v4-flash-vision-expは互換ルーティングに依存しているため、できるだけ早く置き換えてください。 - 9-14 移行ウィンドウ：北京時間 2026-09-14 12:00 より v4-pro は全量 V4.1-Flash にルーティングされ Flash 料金で課金されるため、事前に能力回帰とコスト再計算を行ってください。
- 視覚入力の選定：頻繁に再利用する画像は Files API、一度きりの小さな画像は base64、公開静的画像は URL；バイト安定性を確保してキャッシュヒットを狙います。
- コスト最適化：キャッシュヒット（0.02 元階層）の向上を優先し、非リアルタイムタスクをアイドルウィンドウに移動し、出力側の長さを制御；キャッシュヒットの価格差は 50 倍に達します。
- 並行設計：2500 並行上限の下で