DeepSeek V4 Pro GA と Preview を実測：思考量を 18〜62％ 削減

DeepSeek V4 Pro の正式版は、同じタスクで Preview より推論 token が 18％ から 62％ 少ない。8,192-token の出力枠を使い切る障害も修正された。また、thinking を無効にすると厳密な JSON 抽出が安定する初の Pro ビルドでもある。その一方で、Preview にあった「分からない」と答える能力は失われた。GA の 4 日後、deepseek-v4-pro-0813 と Preview ビルド を同じバッチで計測した。比較対象は token 数だけにした。計測前日に DeepSeek が V4 の料金を変更し、ピーク時間帯とオフピーク時間帯で料金を分けたため、変動する 2 つの料金表をドル換算で比べても、token 数ほど有用な情報にはならない。DeepSeek は GA ビルドをブログ記事、changelog、プレスリリースなしで公開したため、変更点を知るには実測するしかない。

TL;DR

• GA はタスクあたりの推論 token が 18〜62％ 少ない。単純な検索では 48 に対して 18。
• 両ビルドとも thinking を有効にすると厳密な JSON の値が壊れる。正解は 2/8。GA で thinking を無効にした構成だけが安定し、8/8 で正解した。
• GA では Preview の障害が修正された。thinking_budget: 16 で Preview は 9 回中 5 回、8,192-token の出力枠を使い切った。GA は 9 回中 0 回。
• GA は明確な回答拒否ができなくなった。架空の対象について Preview は 100〜150 token で回答を控えるが、GA は何も返さないか、回答を捏造する。

GA ビルドの思考量はどれだけ減ったか

18％ から 62％ 減った。差が最も大きいのは浅い処理だ。標準の 4 タスクをそれぞれ 3 回、salt を加えて実行し、推論 token と完了 token の中央値を求めた。

すべてのタスクで両ビルドとも精度は 3/3 を維持した。品質とのトレードオフではなく、純粋な効率向上だ。運用設計で見るべきなのは勾配である。タスクが深くなるほど削減幅は小さくなり、1-hop の検索では 62％ だが、5 段階の処理では 18％ まで縮まる。両ビルドの利用料金がいくらであっても、差の傾向は変わらない。特に構造化抽出の改善が大きい。厳密な json_schema では推論 token が 159 から 40 に減り、4 倍の削減となった。

切り替え前後で cache の動作は同じだ。両ビルドとも 5,000-token の prefix のうち 4,096 token を cache し、初回リクエストの 4 秒後には hit を返した。現在変動しているのは仕組みではなく料金だ。DeepSeek は V4 系の料金を引き上げ、ピーク時間帯とオフピーク時間帯を導入した。オフピークは半額で、2026-08-16 16:00 UTC から適用されている。この token 数をドル換算する前に、各ビルドの最新料金と実行時間帯を確認してほしい。

GA で実測可能な問題は修正されたか

修正された。しかも、このモデル系で最も高くつく障害だ。Preview ビルドに thinking_budget: 16 を指定すると処理が破綻する。短く考えて回答する代わりに、「I’ll output: 168. I’ll output: 168…」のような反復 loop に入り、max_tokens を使い切る。同じ 5 段階タスクを 9 回実行したところ、Preview は 5 回、8,192-token の枠をすべて消費した。GA では 1 回も発生せず、毎回 79〜130 token で正常に回答した。

問題は障害発生時のコストだ。思考量を制限して料金を抑えるはずのリクエストが、通常なら約 130 token で済むところを 8,193 completion token 課金される。モデルに思考を減らすよう指定した結果、出力料金が 63 倍になる。Preview では 64-token の budget も安全ではなく、3 回中 2 回で 183 や 174 という誤答を返した。まだ Preview ビルドに固定し、小さい thinking budget でコストを制御しているなら、この組み合わせを最優先で廃止すべきだ。

ここでは thinking を無効にしても安全だ。同じモデル系のすべてで安全とは限らないため、この点は明示しておきたい。Flash 0731 は thinking を無効にすると 2-hop 算術の正解率が 6/6 から 0/6 に落ちた。一方、両 Pro ビルドは thinking: {"type": "disabled"} または enable_thinking: false を指定しても、5 段階の処理で 3/3 を維持した。Pro では reasoning タスクの精度を落とさずに無効化でき、構造化抽出の問題も修正できる。詳細は後述する。

reasoning_effort は両ビルドとも実質的に機能していない。low、medium、high、xhigh、max は受け付ける。none と minimal は、有効な値を示す 400 エラーになる。5 段階タスクでは、GA の推論 token は 76〜122、Preview は 116〜167 だったが、段階に応じた単調な増減はなかった。ベンダー横断の調整パラメータ比較で確認したとおり、DeepSeek で思考量を制御するのは無効化 switch と budget であり、enum ではない。

thinking は今も厳密な JSON を壊すか

両ビルドとも壊す。ただし、GA は問題を確実に回避できる初の Pro ビルドだ。この不具合は DeepSeek V4 Flash 0731 で確認した。schema としては正しいが、数値が誤っている JSON を返す。Pro にも同じ問題が残っている。3 行の請求書から 4 項目を厳密な json_schema で抽出させた。各構成を 8 回実行し、schema だけでなく値も検証した。

失敗した応答はすべて parse でき、schema にも適合するが、内容は誤っている。明らかに 3 項目しかない文書に対し、明細数として 45、22、2026、-4、-35、-3864 が返された。Preview の 1 応答では合計が -139,308,173,307,904 になった。GA の 1 応答では別の企業「MITRE」と合計 1000 を捏造した。validator はこれらをすべて有効な JSON と判断する。

運用上の結論は単純だ。GA ビルドで構造化抽出を行う場合は thinking を無効にする。今回の全実行で不具合が消えた。Preview は thinking を無効にしても 8 回中 6 回失敗したため、この設定だけでも Preview から移行する理由になる。この結果はFlash で計測したモデル系の傾向と一致する。Flash でも thinking を無効にすると全実行が正常になった。また、thinking 制御の比較表で確認した、単一ステップなら安全という傾向にも当てはまる。抽出に熟考は不要であり、このモデル系では熟考させるとむしろ結果が壊れる。

GA で失われたものは何か

「分からない」と答える能力だ。架空の対象を 5 つ用意し、企業の株価、研究所の職員数、町の憲章、合金の融点、受賞者について質問した。Preview ビルドは 100〜150 output token で明確に回答を控える。「1987 Pan-Continental Robotics Prize についての情報はありません」という応答だ。GA ビルドの挙動は 2 種類で、どちらも使えない。

公開前に別の独立したリクエスト経路でも確認した。そこでは Preview が抽出した 3 問すべてに 101〜148 token で回答を控えた。GA は 1 問で 8,191 token を消費して空の回答を返し、別の 1 問では断定を避け、残り 1 問では存在しない合金の具体的な融点として「2,314 degrees Celsius」と断定した。client が変わっても非対称性は同じだ。この挙動はモデル自体に由来する。

検索パイプラインでは二重にコストがかかる。index で回答できない質問に対して、非表示の推論で出力枠全体を消費する。その結果として返るのは空の応答か、validator がそのまま受理する捏造だ。未回答の query をこのモデルに流す場合は、障害を発見しやすく低コストに抑えられるよう max_tokens を十分低く設定する。空の completion はエラーではなく miss として扱うべきだ。

切り替えによるほかの変更点はあるか

ほとんどない。切り替えは integration の判断ではなく、挙動の判断になる。両ビルドとも 1 回の呼び出しで 279,000 input token を受け付け、その中央に埋め込んだ needle の質問に回答した。tokenizer も同じモデル系で共通だ。同一の英語、中国語、code 混在 corpus は、GA ビルド、Preview、deepseek-v4-flash-0731 のすべてで同じ token 数になった。token budget は変更せずにモデル系内で移行できる。両ビルドとも temperature、top_p、top_k を何も通知せず受け付ける。また、DeepSeek が prefix completion として文書化している、事前入力済みの assistant turn にも対応する。

cache の単位まで同一だ。どちらも 512-token の prefix はまったく cache しない。それを超えると 1,024-token 単位の正確な page で cache し、1,024、2,048、4,096 token となる。初回リクエストの 4 秒後に hit を返し、Flash が使う page sizeとも同じだ。もう 1 つ、コスト面で確認しておくべき点がある。両ビルドとも完全な chain of thought を reasoning_content で返すが、次の turn で再送しても無料だ。直前の turn の推論を含めても除外しても、follow-up turn で課金された input token は GA で 134、Preview で 56 と変わらなかった。保持した推論を token 単位で再課金するモデルとは異なり、このモデル系では単純に破棄される。

tool loop は改善でも悪化でもない。2 つの function を使う agent loop で、incident を検索し、そこに記載された service を再起動させた。GA は最初の hop で多く推論し、48 対 34 だった。2 番目の hop では少なく、18 対 35 だった。両ビルドとも正しい tool を 3/3 で選択した。DeepSeek はこの release を agent workload 向けに位置付けているが、hop ごとの思考量を見ると、見出しにある効率向上ほど明確な差ではない。行き止まりに遭遇する agent では、前述の回答拒否の挙動のほうが重要だ。

FAQ

GA ビルドの実行料金はどれだけ安くなるか

token 数では、タスクごとの推論が 18〜62％ 少なく、厳密な json_schema では 4 倍少ない。ドル換算は最新の料金表を確認してほしい。DeepSeek は 2026-08-16 に V4 系の料金を変更し、ピーク時間帯とオフピーク時間帯を導入した。オフピークは半額だ。同じ token 数でもビルドと時間帯によって料金が変わる。

GA ビルドの削減効果は単純なタスクと複雑なタスクのどちらで大きいか

単純なタスクだ。推論の削減率は 1-hop の検索で 62％、2-hop の文章題と JSON 抽出で約 48％、5 段階の算術処理では 18％ にとどまる。深い複数ステップの処理では両ビルドの差が縮まり、浅く大量に処理するトラフィックでは切り替えの効果が大きい。

DeepSeek V4 Pro で小さい thinking budget を引き続き使ってよいか

Preview ビルドでは使わないほうがよい。thinking_budget: 16 を指定すると反復 loop に入り、9 回中 5 回で 8,192-token の出力枠をすべて消費した。安くするためのリクエストで、出力料金が約 63 倍になる。64 token では誤答が発生した。GA は同じ budget を 9 回中 9 回、正常に処理した。小さい budget による制御が安全なのは日付付きの GA ビルドだけだ。

DeepSeek V4 Pro の厳密な JSON 出力を信用できるか

thinking を無効にした GA ビルドだけなら信用できる。各構成を 8 回実行したところ、thinking を有効にした両ビルドでは 8 回中 6 回、schema に適合する応答に誤った数値が含まれた。3 項目の請求書に対して、明細数が 45、2026、-3864 になった。GA で thinking: {"type": "disabled"} を指定すると 8 回中 8 回、正しい値を返した。Preview は thinking を無効にしても 8 回中 6 回誤った。schema だけでなく値も検証する必要がある。

DeepSeek V4 Pro は回答できない質問を拒否するか

Preview ビルドは 100〜150 token で拒否する。GA ビルドはほとんど拒否しない。架空の対象について質問すると、出力枠全体を thinking に使って空の message を返すか、枠を広げた場合は自信を持って捏造した回答を返す。拒否しなかったことを信用せず、自分の情報源と照合する必要がある。空の completion は miss として扱うべきだ。

2026-08-17 に Synthorai gateway 経由で計測した。GA ビルドの登場から 4 日後で、すべての比較について Preview ビルドも同じバッチで再実行した。実施内容は、調整パラメータと無効化 switch の matrix（effort 7 値、budget 5 値、無効化 param 2 種類、n=3）、4 タスクの推論 sweep、厳密な JSON による構造化出力、2-turn の function-calling loop、2 種類の出力枠での架空対象 5 問の probe、4 field の厳密な JSON 値整合性 probe（各構成 n=8）、推論再送時の課金比較、2 種類の待機時間による implicit cache の pair と cache 下限の bracket、needle を含む 279K-token context の受け入れ、V4 系の固定 corpus による tokenizer 比較、sampling、prefill、n>1 の受け入れ probe。暴走率は、各ビルドで max_tokens: 8192 を指定して 9 回実行した結果である。DeepSeek がこのバッチの前日となる 2026-08-16 に V4 系の料金を変更し、ピーク時間帯とオフピーク時間帯を導入したため、ドルではなく token 数を記載した。回答拒否の挙動と暴走は、別の独立したリクエスト経路でも確認した。料金と挙動は変わる可能性がある。特定の数値に依存する前に再計測してほしい。

← ブログに戻る