テキスト処理のパイプラインでは、抽出、ドキュメントのレビュー、ロールプレイなど、それぞれ必要な出力量が異なります。新規の連携ではまず deepseek/v4.1-flash/chat から始めてください。入力は100万トークンあたり$0.30、出力は$1.20で、返信の上限は384,000トークンです。V4のIDに固定された連携では、日常的な処理にV4 Flashを使います。Proを選ぶのは、並列ツール呼び出しを明示的に制御したいとき、65,536トークンを超える返信が必要なとき、または結果がトークン単価3倍に見合う特定のタスクの場合です。どちらのV4 IDも1,048,576トークンを読み込めるため、入力が長いというだけではProに支払う理由になりません。
新規構築の道筋はV4.1 Flash移行ガイドで説明しています。以下の比較は、ホスト型のV4 ID 2種に当てはまります。
どの仕事にどちらを選ぶか
| 仕事 | 選択 | 理由 |
|---|---|---|
| 抽出、分類、JSON出力、日常的なチャット | V4 Flash | 入力ウィンドウは同じで、トークン単価は3分の1 |
| 人または別のモデルが確認する、コードやドキュメントの一次レビュー | V4 Flash | 最も安くスキャンできます。判断がつかない指摘だけを上位へ回します |
| 65,536トークンを超える1回の返信(移行計画の全体、データセット全体の変換) | V4 Pro | 上限は384,000トークンで、Flashは65,536 |
リクエストで parallel_tool_calls を指定する必要があるワークフロー | V4 Pro | Flashはこのフィールドを受け付けません |
| 安価なモデルの下書きに対する最終検証 | V4 Pro | 高価なパスは、根拠のある少数の項目に絞ります |
| アーキテクチャレビュー、リファクタリング計画、ドキュメント | Flashでスキャンしてから、Proを試す | 下の単一コードベースのベンチマークでは網羅性が高く、見落とした細部が重要なときに有用 |
| 正確な行番号の参照に基づくコード編集 | Flashとソースの検証を併用し、必要ならProを追加 | ベンチマークでは両モデルとも誤った指摘があり、正しさはソースの確認とアプリケーションのテストで決まります |
| 大量のロールプレイや小説 | V4 Flash | ロールプレイ100ターンあたり約$0.57(Proは$1.72) |
契約内容の違い
| 現在の契約 | V4 Flash | V4 Pro | V4.1 Flash(参考) |
|---|---|---|---|
| モデルID | deepseek/v4-flash/chat | deepseek/v4-pro/chat | deepseek/v4.1-flash/chat |
| 入力上限 | 1,048,576トークン | 1,048,576トークン | 1,048,576トークン |
| 出力の上限 | 65,536トークン | 384,000トークン | 384,000トークン |
| 出力のデフォルト上限 | 32,768トークン | 32,768トークン | 32,768トークン |
reasoning_effort | none、low、high(デフォルトは high) | none、low、high(デフォルトは high) | none、low、high(デフォルトは high) |
| 本ガイドで使う入力 | テキストメッセージ | テキストメッセージ | テキストメッセージ |
| JSONオブジェクト出力 | 対応 | 対応 | 対応 |
parallel_tool_calls | 受け付けない | 受け付ける(デフォルトはtrue) | 受け付けない |
| 100万トークンあたりのUSD(入力 / キャッシュ / 出力) | $0.44 / $0.014 / $1.32 | $1.32 / $0.044 / $3.96 | $0.30 / $0.006 / $1.20 |
| SpicyAPIのレビューでの出力速度 | 40トークン/秒 | 46トークン/秒 | 記載なし |
現在のホスト型フィールドは、V4 FlashとV4 Proのページで確認できます。どちらも最大256件のメッセージと128個のツール定義に対応し、1リクエストあたり最大60分まで許容します。また、どちらも temperature と top_p は公開していません。SpicyAPIの比較ページでは、同じフィールドをライブスキーマから確認できます。
どちらのエンドポイントも、記載のないフィールドは拒否します。Proのエンドポイントからコピーした parallel_tool_calls 入りのボディは、Flashでは無視されずに検証エラーになります。そのため、両モデルのフィールドの和集合を送るのではなく、モデルごとのフィールドを分けて管理してください。
これらのIDの上流での扱い。 DeepSeekの現在の変更履歴では、V4 Flashは廃止され、旧エイリアスは一時的にV4.1 Flashへルーティングされます。V4 Proは請求条件を変えずに提供が続きます。SpicyAPIでは上記の別々のIDを掲載しています。V4の連携を維持する場合は、上流のエイリアスではなく、ホスト型の完全なIDを固定してください。DeepSeekの9月10日の発表にはネイティブエイリアスのリダイレクトが説明されているため、ネイティブエイリアスを使ったフォーラムの結果は、元のV4バージョン同士を比べていない可能性があります。「Flash対Pro」のページを信用する前に、モデル名、バージョン付きID、観測された結果を区別してください。新規構築では、V4.1 Flashの単価の低さと返信上限の大きさが、そこから始める現実的な理由になります。
他の開発者がこの2モデルで見つけたこと
1つのPythonコードベースを使った18回実行のコードレビューベンチマーク(日付付きのFlash 0731とPro 0813のスナップショットを使用)では、有用な違いが見られました。
- 網羅性: 検証可能な指摘は、Proが169件、Flashが70件でした。指摘の正確さは近く、95.9%と95.7%でした。
- バグの発見: Flashは既知の潜在バグ3件をすべて見つけ、Proは1件でした。Flashは存在しないエッジケースも作り出したため、提案された修正はソースで確認してください。
- 安定性: Proのレポートの深さは、繰り返し実行の間で2.7倍変動しました。この構成では、Flashでスキャンしたあと、Proで絞り込んで検証する方法が最も良い結果でした。
安価な一次パスにはFlashを使い、判断がつかない指摘は、そのソースと的確な質問を添えてProに渡します。どちらのモデルのレポートも、ソースの確認やアプリケーションのテストの代わりにはなりません。
まずPlaygroundで試す
- DeepSeek V4 Flashを開き、Playgroundに切り替えます。
- 例にあるカタログ承認と在庫タイムアウトの記録を貼り付けます。ジョブE42をエクスポートできるかを尋ねます。
- 同じ入力でV4 Proでも繰り返します。現在の在庫照会が失敗しているため、どちらの回答もエクスポートを止めるはずです。
正解が1つの判断で両方を試す
クリエイターのストアフロントのエクスポートが、承認済みカタログと最新の在庫照会に依存しているとします。モデルは、保留中の手順を完了済みとして扱わずに、エクスポートを止めている要因を挙げる必要があります。このテストケースは安価なので、大きな書き起こしを送る前に両モデルで試せます。
API Keysで取得したキーを SPICY_API_KEY に設定してください。リクエストにはSpicyAPIのChat Completionsインターフェースを使います。
cat > request.json <<'JSON'
{
"model": "deepseek/v4-flash/chat",
"messages": [
{
"role": "system",
"content": "Return JSON with can_export (boolean), blockers (array of strings), and evidence (array of exact source quotes). Use only the supplied record. Every required dependency must be complete before export."
},
{
"role": "user",
"content": "Job E42 requires catalog approval and a current inventory lookup. Record: \"Catalog approved at 10:00. Inventory lookup timed out at 10:03. The last inventory snapshot is from yesterday.\" Can this job be exported now?"
}
],
"max_tokens": 2048,
"reasoning_effort": "low",
"response_format": {
"type": "json_object"
}
}
JSON
curl --fail-with-body https://api.spicyapi.ai/v1/chat/completions \
-H "Authorization: Bearer $SPICY_API_KEY" \
-H "Content-Type: application/json" \
-H "Idempotency-Key: $(uuidgen)" \
--data-binary @request.json --output response.json
python3 - <<'PY'
import json
from pathlib import Path
response = json.loads(Path("response.json").read_text())
choice = response["choices"][0]
if choice.get("finish_reason") != "stop":
raise SystemExit("FAIL: reply did not finish normally")
answer = json.loads(choice["message"]["content"])
quotes = {"Catalog approved at 10:00.",
"Inventory lookup timed out at 10:03.",
"The last inventory snapshot is from yesterday."}
blockers = answer.get("blockers")
evidence = answer.get("evidence")
valid = (
answer.get("can_export") is False
and isinstance(blockers, list) and bool(blockers)
and all(isinstance(item, str) and item.strip() for item in blockers)
and any("inventory" in item.lower() for item in blockers)
and isinstance(evidence, list) and bool(evidence)
and all(isinstance(item, str) and item in quotes for item in evidence)
and "Inventory lookup timed out at 10:03." in evidence
)
if not valid:
raise SystemExit("FAIL: decision, blocker or source evidence is incorrect")
print("PASS: export is blocked by the timed-out inventory lookup")
PY正しい判断は can_export: false で、最新の在庫がないことが阻害要因です。昨日のスナップショットは必要な最新の照会ではなく、evidence 配列にはタイムアウトの行を引用するべきです。
これはテストケースの確認であり、汎用的なビジネス用バリデーターではありません。実際のエクスポートでは、アプリケーション内の本当の依存関係の状態を使ってください。モデルは実在する文を引用しながら誤った結論を導くことがあるため、ここでは判断と根拠の両方を検査しています。
同じ入力でProを実行するには、モデルIDだけを変更します。ソース、指示、effort、出力上限は同一にして、各回答を2点で採点します。阻害要因を挙げたか、引用が記録の中に実在するか。説明が長いほど良い判断になるわけではありません。
Flashが通るなら、このテストケースではそのタスクにProを払う理由はありません。どちらかのモデルが在庫の成功を作り上げたなら、JSONが解析できたからといって、その回答を後続に渡してはいけません。両方が失敗したなら、より高い価格を解決策とみなす前に、要件が明確に書かれていたかを確認してください。
Agentに呼び出しを準備させる
エクスポート判断の確認を繰り返す場合は、コーディングAgentにSpicyAPI Skillを使うよう頼みます。「Read deepseek/v4-flash/chat, then adapt the example to my input; show the request before running it.」CLIでの確認は spicyapi models get deepseek/v4-flash/chat --json、MCPでは spicyapi_model_get に model: "deepseek/v4-flash/chat" を指定します。チャットの呼び出しには、互換クライアントかチャットAPIを使います。メディアタスクのコマンドはチャットの返信を生成しません。
高い料金に見合うワークフローはどれか
1件の完全なブリーフから、クリエイターの公開日、キャラクター名、依頼された画像枚数を抽出する場合、Flashには一般的な制御と十分な出力容量があります。Proの大きな出力上限は、短いJSONオブジェクトには何の利点もありません。Flashから始め、欠けている値は明示的に示して、「no release date supplied」が作り上げた日付にならないようにします。
複数レコードにまたがる依存関係のレビューでは、ジョブのルールを具体的にします。ショットに承認済みの2人目のキャラクターと最新の在庫アセットが必要な場合、承認済みのキャラクター参照だけでは足りません。周囲の制作の書き起こしがショットを何度も準備完了と呼んでいても、モデルは2人目の承認がないことを指摘できるべきです。上のテストケースは、在庫を使ってこの違いを検証します。失敗した複雑なジョブでは、Proとの比較が価値を持つ場合があります。
非常に大きな変換では、品質について何も主張しなくても、出力の要件で選択が決まることがあります。実際に返すドキュメントが1回の返信で65,536トークンを超えるなら、Flashの上限では収まらず、Proのほうが多く出力できます。独立したレコードを小さなグループに分けて返せるなら、バッチ処理でFlashを使い続けられ、失敗したグループの再試行も楽になります。グループ間の関係に回答が依存するタスクは、その関係を引き継がずに分割してはいけません。
選択的なアップグレードは、選択的であるうちだけ経済的です。下の入力50,000/出力3,000トークンという前提では、Flash 900回とPro 100回の合計は$31.152で、1,000回すべてをProで行うと$77.88です。すべてのジョブをまずFlashで処理し、そのうち100件でProが必要になった場合の合計は$33.748です。これは再試行のトレードオフを説明するための仮の合計で、実際のトークン使用量は異なります。
同じ使用量でのリクエスト単価
キャッシュなしの入力50,000トークンと、課金される出力3,000トークンのリクエストの場合:
- Flash:50,000 × $0.44/M + 3,000 × $1.32/M = $0.02596。
- Pro:50,000 × $1.32/M + 3,000 × $3.96/M = $0.07788。
このようなリクエスト1,000件の費用は、それぞれ$25.96と$77.88です。入力トークンのうち40,000がキャッシュ読み取りで10,000がキャッシュなしの場合、1リクエストあたりはFlashが$0.00892、Proが$0.02684になります。キャッシュ料金は正確に3対1ではないため、表の単価から概算せず、合計を計算してください。
請求額に対しては、モデルの選択よりも影響が大きい要素が2つあります。
- 推論は出力として課金されます。 デフォルトのeffortは
highです。抽出や分類ではlowを試し、推論の工程を省くならnoneを使って、トークン数だけでなく採用された結果も比較してください。 - 再試行も数えます。 重要なのは1回の呼び出しあたりではなく、採用された回答あたりのコストです。
選択的なエスカレーションなら、節約の大半を維持できます。すべてをFlashに送り、失敗した結果や曖昧な結果は、失敗した理由の根拠を添えてProに送ります。上記の使用量で10件に1件をエスカレーションし、エスカレーションしたリクエストがFlashとProの両方の呼び出しを支払う場合、平均は1リクエストあたり約$0.03375で、すべてをProに送った場合の$0.0779より安くなります。2つ目のモデルが同じ誤りを繰り返すこともあるため、タスク本来の正しさの確認は残してください。
Proの大きな出力が重要になる場面
384,000トークンの上限が重要になるのは、必要な返信が本当に65,536トークンを超えるときだけです。たとえば、各手順のSQLとロールバックを含む順序付きの移行計画を、まとめて返す必要がある場合です。長い入力に対する短いレポートは該当しません。入力容量は同じです。
非常に大きな返信を求める前に、受け取る側がそれを検証して保存できるかを確認してください。章ごとの編集や、独立したグループに分けたレコードは、中断後の復旧が簡単です。1回の返信にこだわるのは、各部分が共通の構造に依存している場合だけにします。
最大値とデフォルトを混同しないでください。どちらもデフォルトの出力は32,768トークンで、上限に達した返信はエラーなしで途中で切れます。上のテストケースのような短いタスクでは小さな値を明示し、成果物が必要とする場合にだけ大きな値にします。
並列ツール呼び出しが重要になる場面
Proは parallel_tool_calls を受け付け、Flashは受け付けません。これが示すのは送信できるリクエストボディであり、Flashがツールを使えないという意味ではありません。どちらもツール定義と tool_choice を受け付けます。
承認済みカタログと在庫レコードを同時に取得するなど、互いに独立した読み取りは並列呼び出しの候補です。エクスポートの操作は両方の結果に依存するため、待つ必要があります。この依存関係は、提案されたツールの順序を実行の許可と見なすのではなく、アプリケーション側で強制してください。Proで parallel_tool_calls をfalseにすると、各呼び出しが前の結果を必要とする場合に、1ターンあたり最大1回の呼び出しになります。
ループで明示的な制御が必要なら、それがProを選ぶ具体的な理由です。順番に照会して短い回答を返すだけなら、Flashで始め、基本のループが動いてから並列処理を追加します。
検閲なしの執筆とロールプレイ
SpicyAPIでは、どちらのモデルも「Uncensored」ティアです。プラットフォーム側のコンテンツフィルターはなく、残るのは各モデル自身の挙動だけです。2026年9月のコンテンツラダーテストでは、強度の高い大人向けシーンのカテゴリ(レビューではL4)を文脈なしで直接依頼すると、どちらも断りました。一方、システムプロンプトで小説執筆の枠組みを設定すると、どちらも書きました。
| 強度の高い大人向けシーン(L4) | V4 Flash | V4 Pro |
|---|---|---|
| 直接の依頼、枠組みなし | 拒否(3回中3回) | 拒否(3回中3回) |
| 物語として依頼 | 2回は出力、1回は表現を弱めた | 1回試行、拒否 |
| システムプロンプトでフィクションの文脈を設定 | 出力(3回中3回) | 出力(3回中3回) |
L5では、各モデルが大人向けフィクションのブリーフ3種の言い回しと、別の大人向けではない過激なフィクションのブリーフ3種を完了しました。Flashは最も穏やかな示唆的カテゴリで1回、表現を弱めました。それ以外の低いレベルの検証は完了しています。したがって大人向けフィクションでは、どちらのモデルでもシステムプロンプトでジョブの枠組みを作ってください。断られにくいことを期待してProに支払うのはやめましょう。すべての実行は、V4 FlashとV4 Proのレビューに載せています。
ロールプレイは出力が多く、3対1の価格差が表れる場面です。1ターンあたりキャッシュなしの入力10,000トークンと課金対象の出力1,000トークン(推論を含む)を想定すると、100ターンでFlashは約$0.57、Proは$1.72です。
FAQ
コーディングにV4 Flashで十分ですか?
より安い出発点で、単一コードベースのベンチマークでは、Flashで既知の3件のバグをすべて見つけました。提案された編集の前に、引用されたソースを確認し、影響するテストを実行してください。Proによる絞り込んだパスはエスカレーションの選択肢であり、これらの確認の代わりにはなりません。
Flashは遅いですか?
SpicyAPIのレビューでは、出力速度はFlashが毎秒40トークン、Proが46トークンでした。この小さな差だけで、トークン予算を3倍にする理由にはなりません。実際のレイテンシは推論や返信の内容に左右されます。この数値を現在の速度の保証として当てにするのではなく、短いタスクではeffortを下げてください。
Proが大きいモデルなのに、なぜFlashを選ぶのですか?
どちらのホスト型IDも同じ長さの入力を受け付けますが、キャッシュなしのトークン料金ではFlashは約3分の1です。抽出や分類の短い返信では、Proの大きな出力上限はそれだけでは何の利点にもなりません。曖昧な結果は、高価なパスに回す具体的な質問があるときにエスカレーションしてください。
新規の連携はV4とV4.1 Flashのどちらで始めるべきですか?
特定のV4の契約が必要な場合や、固定された連携を保守する場合を除き、V4.1 Flashから始めてください。V4.1にルーティングされるのは廃止されたV4 Flashのエイリアスだけです。V4 Proは提供が続き、これらのホスト型の契約は別々に掲載されています。本番トラフィックを移す前に、アプリケーションが頼っている挙動を再確認してください。







