DeepSeek V4 Flash API のコスト：思考モードで厳格 JSON が破損

DeepSeek V4 Flash の料金は、入力 100 万 token あたり $0.14、出力 100 万 token あたり $0.28、cache hit は $0.0028 だ。現在この名前で提供されている再学習版の 0731 build には、routing で回避すべき不具合がある。思考モードを有効にしたデフォルト設定で厳格な json_schema を使うと、独立した 2 つの request path で実行した 13 回のうち 8 回、整数 field が壊れた。思考モードを無効にすると全実行が正常になり、抽出に使う token も 7 分の 1 まで減った。リリース初日に deepseek-v4-flash-0731 を計測し、値の破損、再学習でさらに顕著になった思考モード無効時の性能低下、それを回復させる budget の下限、1,024 token 単位の cache page、preview build や V4 Pro との違いを調べた。

TL;DR

• デフォルトの思考モードと厳格な json_schema を併用すると、deepseek-v4-flash-0731 は 2 つの request path で 13 回中 8 回、整数 field を破損した。V4 Pro は 4 回中 2 回が破損し、preview だけは全件正常だった。
• 0731 の再学習で、思考モード無効時の性能低下がさらに顕著になった。2-hop の算術問題は 6／6 から 0／6 に落ちた。
• cache は約 1.1K token から 1,024 token 単位の page を返す。priming から 0.3 秒後には hit し、entry は 45 分を超えて保持された。
• enable_thinking: false にすると構造化出力は全件正常になり、使用 token は 7 分の 1 に減った。2-hop の算術問題では、安全な thinking budget は 256 だ。

3 つの V4 build は仕様と実測でどう違うか

tokenizer、cache、思考処理の仕組みは同じだが、料金と failure mode は異なる。以下はすべて、3 build に同一の probe を実行した結果だ。ダッシュは未計測を示す。リリース初日の分析 thread は benchmark が中心なので、ここでは運用面を比較する。

V4 Flash の思考モードは構造化出力を壊すのか

0731 build では壊れる。しかも、気付かないまま本番に到達し得る failure mode だ。厳格な json_schema を使い、請求書から vendor、date、total、line-item count の 4 field を抽出した。デフォルトの思考モードでは schema-valid な JSON が返ったものの、数値が誤っていた。明らかに 3 item が記載された文書に対して、line_items は -1、1、-1、-19 となり、当方の gateway では 5 回すべて不正解だった。budget を制限しても回避できない。64 token budget でも同様に破損し、256 token budget でも 3 回中 1 回、line-item count が 670 になった。破損は思考量ではなく、思考処理の有無に連動している。独立した 2 つ目の request path でも、2 batch の計 8 回中 3 回で同じ probe が破損した。文書の合計が $520.00 なのに 519.95 を返した例や、line-item count が 22 になった例もある。この path では無効化を指定しても reasoning が有効なままだったため、後述する修正策は primary path で検証した。JSON は常に parse でき、schema validation にも常に通る。間違っているのは値だけだ。validation を信用する pipeline にとって、最悪の failure mode といえる。

修正は 1 行で済む。enable_thinking: false を指定すると、すべての実行で正しく valid な JSON が返った。completion token は約 44 で、デフォルトの 328 に対して約 7 分の 1 だった。model family 内の差も明確だ。同じ probe を思考モード有効で実行すると、preview build は 4／4 で正常だった一方、V4 Pro は 4 回中 2 回が破損した。この不具合は V4 の思考系統全体にまたがり、再学習版 Flash で最も強く現れる。また、すでに報告済みの思考処理と schema の組み合わせによる不具合とは別物だ。vLLM は昨年 4 月、DeepSeek の JSON が content を空にしたまま reasoning field に入る 配線上の問題 を修正した。今回は配線自体は正常で、値が間違っているため、さらに深刻だ。DeepSeek が修正するまでは、これらの model で思考モードと厳格な構造化出力を併用しない方がよい。コスト面の不利益もない。単一 step の抽出は思考モードを安全に無効化でき、料金も 7 分の 1 になる workload だ。

API はどの思考制御を受け付けるか

無効化手段が 2 つ、正確な budget 指定が 1 つ、無効化できない effort dial が 1 つある。計測した API surface では、reasoning_effort に low、medium、high、xhigh、max を指定できる。Qwen 3.8 Max と異なり、none と minimal は拒否されるため、dial だけで思考処理を止めることはできない。無効化には enable_thinking: false または thinking: {"type": "disabled"} を使う。どちらも同じ挙動で、単純な質問への回答は 9 token だった。thinking_budget は指定 token 数どおりに適用される。Qwen 3.8 での計測結果 と同じく、16 を指定すると meter も 16 になる。chain of thought 全体は reasoning_content で返り、固定の prompt overhead は 1 call あたり 5 token と小さい。

一方、effort dial には計測可能な差がなかった。負荷の高い素数カウント課題では、low と high の reasoning token はそれぞれ 31,374 と 31,370 で、デフォルトは 26,897 だった。3 設定とも正解している。通常のばらつきの範囲で、cap が働いた形跡はない。Qwen 3.8 の level は内部的な budget cap であり、深い処理では上限が効く。V4 Flash の level は、計測したどの深さでも何も変えなかった。この model で意味がある制御は、無効化 switch と thinking_budget の 2 つだ。dial は実質的に飾りと考えてよい。皮肉なことに、DeepSeek 自身の model card では agent benchmark を「max reasoning effort」に固定しているが、今回計測した API surface ではデフォルトとの違いを確認できなかった。

2-hop の算術問題に必要な thinking budget はどれくらいか

再学習前よりも多く必要であり、他の model で示した低コスト mode の推奨とは逆の結果になった。引用可能な 2-hop の算術 batch では、1850 箱に各 24 部品、75％ を出荷し、3,120 個が到着するという問題を使った。3 つの V4 build は、別々の model のように異なる挙動を示した。

ここから 2 点が分かる。まず、agent 向けの再学習により、算術処理が思考 channel に移った。preview build は思考モード無効でも辛うじて解けるが、0731 は完全に崩れ、Pro はまったく影響を受けない。次に、budget の下限は model ごとに異なる。Qwen 3.8 Max は同じ batch で 16 thinking token あれば完全に回復するが、0731 には 256 が必要だ。256 では全問正解し、デフォルトより安い。completion 合計は 53～188 で、デフォルトは 100～200 だった。thinking budget の設定を別 model に移す場合は、accuracy check をやり直す必要がある。制御方法は共通でも、必要な閾値は共通ではない。

implicit cache の性能はどうか

低い最低 prompt 長から 1,024 token 単位の page を高速に返し、長時間保持する。salt を付けた prefix pair では、prompt を伸ばすにつれて正確に 1,024、2,048、4,096、7,168 token の hit が発生した。1,024 token 単位に量子化された page 方式だ。最低 prompt 長は 1 page を少し超えたあたりにある。704 token の prompt は一度も hit せず、1,166 token では 1,024 token が hit した。priming から 0.3 秒後には hit したため、cache 構築待ちを考慮した設計は不要だ。entry は ＋45 分でも利用できた。この価格帯で計測した implicit cache の中では最長だ。Qwen 3.8 Max の entry は 15～45 分の間に失効し、最低 prompt 長も約 4.3K token だった。DeepSeek の cache hit 入力料金は 100 万 token あたり $0.0028 で、cache miss の 2％ だ。書き込み premium はない。通常の layering 原則 がそのまま使える。安定した prefix を先頭に置き、変動する content を後ろに置く。

1M context と 384K output の上限は実在するか

計測した範囲では、context window はすべて正常に機能した。prompt 内に埋め込んだ override code は、137,638、465,238、838,198 prompt token の各条件で一字一句そのまま返り、所要時間は 7～20 秒だった。この価格帯で計測した long-context recall としては最速だ。output 側は公開仕様より緩い。DeepSeek が公表する最大 output は 384K token だが、max_tokens に 393,217、さらに 524,288 を指定しても、思考モードの有効時と無効時の両方で request が受理された。上限は request 時点では強制されず、過大な budget を指定しても明示的な error にはならない。上限が必要なら、利用側で設定する必要がある。

Preview、0731、Pro のどの build が request を処理するのか

現在の DeepSeek の料金ページには、deepseek-v4-flash という SKU だけが掲載されている。model version は DeepSeek-V4-Flash-0731 で、料金は変更されていない。実際には、一部の route で preview build が独自の名前のまま提供されている。両者は tokenizer を共有しているため、英語、中国語、code corpus の token 数は同一で、budget もそのまま移せる。それでも外部から簡単に見分けられる。最も分かりやすい fingerprint は、思考モード無効時の probe だ。今回の batch では、2-hop の算術問題に対する正解数が preview で約 2／6、0731 で 0／6 だった。構造化出力の probe をすべて通過したのも preview だけで、4／4 だった。0731 は 5／5 が破損し、Pro は 2／4 が破損した。どちらかの挙動に依存する traffic では、名前を信用せず、実際に呼び出す endpoint を probe した方がよい。V4 Pro（$0.435／$0.87）は算術性能の急落を免れたが、構造化出力の不具合は免れなかった。

計画時には、もう 1 点考慮が必要だ。3 build が共有する tokenizer は、同一 corpus で Qwen 3.8 より約 6～9％ 多く token を使う。vendor 間で budget を比較する場合、料金表だけでなく 言語別の token 密度 も必要になる。

FAQ

DeepSeek V4 Flash の構造化出力は安全か

思考モードを無効にすれば安全だ。厳格な json_schema が適用され、今回の batch ではすべての抽出結果が正しかった。0731 build のデフォルト設定で思考モードを有効にすると、2 つの request path で 13 回中 8 回、schema validation には通る一方で整数 field が破損した。V4 Pro も同じ probe で 4 回中 2 回が破損し、preview build だけが全件正常だった。不具合が修正されるまで、構造化出力の route では enable_thinking: false を固定で指定した方がよい。

DeepSeek V4 Flash の思考モードは無効にできるか

できる。enable_thinking: false または thinking: {"type": "disabled"} の 2 通りがある。ただし 0731 の再学習により、複数 step の処理では無効状態の性能が不安定になった。2-hop の算術問題は 0／6 だった。single-hop の lookup を超える処理では、thinking_budget の下限を 256 にするとよい。計測では全問正解で、デフォルトより安かった。

V4 Flash の cache が使われる最小 prompt 長はいくつか

1,024 token を少し超えたあたりだ。704 token の prompt は一度も cache されず、1,166 token では正確に 1,024 token が hit した。hit は 1,024 token 単位の page に量子化され、priming から 0.3 秒後に発生し、45 分を超えて保持された。cache hit 入力の公表料金は 100 万 token あたり $0.0028 で、cache miss の 2％ だ。

0731 release で料金は変わったか

変わっていない。DeepSeek は入力 100 万 token あたり $0.14（cache miss）、$0.0028（cache hit）、出力 100 万 token あたり $0.28 を維持し、0731 を現行 model version として既存の deepseek-v4-flash という名前に統合した。変わったのは料金ではなく挙動だ。思考処理への依存が強まり、前述の構造化出力の不具合が発生している。

2026-08-04 に Synthorai gateway 経由で deepseek-v4-flash-0731 を計測した。比較対象は deepseek-v4-flash preview と deepseek-v4-pro。実行ごとの payload を記録した厳格な schema による抽出 batch を、独立した 2 つ目の request path でも検証した。さらに、dial が受け付ける値と異常値の probe、各条件 n＝4～6 で salt を付けた 2-hop の accuracy batch と thinking budget による段階的な回復試験、2.5 秒間隔で salt を付けた cache pair による最低 prompt 長、page、構築遅延、保持間隔の probe、両 mode での max_tokens 境界 probe、3 build と Qwen 3.8 Max に対する同一 3 corpus の tokenizer count を実施した。金額は公開時点で DeepSeek が公表していた定価であり、利用する provider の meter でも確認してほしい。DeepSeek が 0731 build を更新すれば、挙動が変わる可能性がある。

← ブログに戻る