WaveSpeedAI

DeepSeek V4 の価格設定: OpenAI より 20～50 倍安い（コスト分析）

DeepSeek V4 の価格設定: OpenAI より 20～50 倍安い（コスト分析）

最近、私は静かなモデルを探していました。毎時間メーターを監視する必要なく、何度も呼び出せるようなものです。DeepSeek V4は他のビルダーとのチャットで何度も出てきました。大抵は眉をひそめながら「本当に安いんだ」というような感じです。

Doraがここにいます。2026年1月後半の2週間を使って、いくつかの小さなワークフローに組み込みました。研究要約ツール、プロダクトノート書き直し、週間バックロググルーマーです。何も派手なことはありません。トークンがどのように通常の1週間の実際のドルに変わるかに関心がありました。DeepSeek V4 APIのコスト、重要な割引、そして出荷前に予算を立てるシンプルな方法について、ここに私が学んだことがあります。

現在のDeepSeek価格設定

数字が安定していると言い張るつもりはありません。価格は変動し、アクセスをどこで購入するか（直接対OpenRouterなどのブローカー）で異なります。したがって、2つのアンカーがあります。

  • ソースを確認してください。公式なDeepSeek APIドキュメントと価格ページです。直接接続する場合の標準レートです。
  • マーケットプレイス経由でルーティングする場合は、モデルカードを開いてください。例えば、OpenRouter上のDeepSeekモデルは、100万トークン当たりのレートと時間ベースの割引をリストしています。

2026年1月下旬にプロバイダー間で見たものは、精神的には一貫していました。DeepSeek V4は、入力トークンと出力トークンの両方で最前線のモデルをはるかに下回ります。正確なセント数は異なります。私は価格を固定するのではなく、価格でどのように機能するかを共有しています。

標準レート

使用量ベースのモデル請求が初めての場合、2つのラインが重要です。

  • 入力トークン（送信したもの）：100万トークンあたり請求されます。
  • 出力トークン（返されたもの）：100万トークンあたりも請求されます。通常は入力より高い。

私の実行では、V4の生のレートは十分に低かったため、小さい日次スパイクは傷つきませんでした。これはバッチジョブで最も顕著に現れます。例えば、週間バックロググルーマーは、約3～5K入力トークンの約20個のプロンプトを送信し、約1～2K出力トークンを受け取ります。保守的なサンプルレートでも、実行全体の合計は「コーヒー代」ゾーンに留まりました。

2つの実用的なメモ：

  • 出力インフレはあなたを忍び寄ります。プロンプトが長い思考を促す場合、出力ラインはあなたの請求を2倍にすることができます。私はmax_tokensを上限にし、スタイルをより厳しくしました。お金を節約し、結果が向上しました。
  • チャンクサイズが重要です。長いドキュメントを要約している場合、重複する各トークンに対して支払います。1,600トークンオーバーラップから400に移動しても、品質は失われませんでした。

キャッシュヒット割引（90％オフ）

これは私の精神的な計算を変えました。いくつかのプラットフォームとモデルベンダーは、繰り返されるプレフィックスのプロンプトキャッシングをサポートしています。プロンプトの最初のNトークンが変わらない場合（システムメッセージ、共有指示、スキーマ）、キャッシュヒットは急な割引で請求される可能性があります。90％オフは、いくつかのベンダーのキャッシング実装で文書化されている数字です（利用可能性は異なります：プロバイダーの価格ページで確認してください）。

実際には次のようでした：

  • 研究要約ツールは、長い固定システムプロンプトと安定したツールスキーマを共有しています。ソーステキストのみが変わります。
  • 最初の呼び出しの後、後続の呼び出しはその共有プレフィックスのキャッシュにヒットします。
  • キャッシュ請求を尊重するプラットフォームでは、これらの再利用されたトークンは割引レートに落ちました。

テストからの2つの注意：

  • 「クローズ」はキャッシュされません。共有プレフィックスの1行を変更すると、ヒットを失います。
  • 大きな固定スキーマは、それ自体の費用がかかります。指示とツールを安定したプレフィックスに統合できれば、1回実行して、キャッシュを乗り切ってください。

プロバイダーがキャッシングを公開しない場合でも、繰り返されたガイダンスをより短くて一貫性のあるシステムプロンプトに移動し、ユーザーメッセージから冗長性をトリミングすることで、節約の一部をシミュレートできます。

オフピーク割引（75％オフ）

いくつかのマーケットプレイスは、需要をスムーズにするための時間ベースの割引を提供し始めました。50～75％オフのような数字が表示されるオフピークウィンドウを見かけましたが、リセラーとモデルによって異なります。DeepSeekモデルは、経済がすでに効率的に傾いているため、参加する傾向があります。

これが私を助けた2つの方法：

  • 週間バックログジョブをオフピークウィンドウでスケジュールしました。同じワークロード、低いラインアイテム。
  • 研究要約を一晩中バッチ処理しました。レイテンシは問題ではなく、割引でした。

これは普遍的ではありません。DeepSeekに直接接続する場合は、時間帯の価格設定を公開しているかどうかを確認してください。ブローカー経由で行く場合は、モデルカードの細字を読んでください。スプレッドは、V4をループに保つか、品質上の理由で最前線モデルにタスクを切り替えるかどうかを決めるのに十分な大きさにすることができます。

DeepSeekがとても安い理由

低価格がプロモーション的なものかどうか、またはアーキテクチャが実際にそれをサポートするかどうかを理解したかったです。公開されているものから、2つのピースが目立ちました。

MoEアーキテクチャ

DeepSeekの新しい大規模モデルはMixture-of-Experts (MoE)に依存しています。簡潔に言うと：トークンごとに脳全体を目覚めさせるのではなく、ルーターはそれを処理するために少数のエキスパート部分ネットワークを選択します。あなたは依然として有能なモデルを得ますが、パラメーターの一部だけがステップごとに機能し、計算とコストを削減します。

これが実際に重要な理由：

  • スループットがより良くスケーリングされます。私の側では、並列ジョブを押しても、p95レイテンシは妥当な状態でした。
  • コストは複雑さに応じて線形に急上昇しません。長いプロンプトは、密集した常にオンのモデルほど罰しませんでした。

私は使用した他のMoEモデルは、ニッチなタスクで脆い感じがしました。V4は構造の重いプロンプト（JSON出力、ツール使用）を揺らがずに処理しました。その堅定性はコストストーリーの一部でもあります。より少ない再試行、より少ないやり直し。

Engram効率

DeepSeekのドキュメントは、コンテキスト処理とメモリ効率に関する作業について言及しています（いくつかのリリースで改善されたアテンション ルーティングとKVキャッシュ処理のようなことに言及しています）。内部を確認することはできませんが、観察したことを共有できます。

  • 長いコンテキストプロンプトは、2026年1月の私のテストのスループットを破壊しませんでした。「すべてが糖蜜になる」という感じなしに、32Kトークンコンテキストを実行しました。
  • 決定論的フォーマットは、私が予想した以上に高い温度で保持され、出力を短くしても品質を崩すことなく保つことができました。

私の読み方：価格はマーケティングの洒落ではありません。これは、トークンあたりの計算を低く保つために組み込まれたアーキテクチャと、ステッカー価格でそれを渡す意欲の結果です。技術的なメモに興味がある場合は、公式なDeepSeekドキュメントと、モデルカードからのリンクされた論文から始めてください。

コスト計算テンプレート

私は正確なセント単位でもう予算をロックしません。範囲を計画し、実際の使用が落ち着いたら調整します。これはDeepSeek V4に使用したテンプレートです。スプレッドシートで再作成するのに十分なほどシンプルです。

ワークロードごとに記入するインプット：

  • 1日あたりの呼び出し数（またはバッチあたり）
  • 呼び出しあたりの平均入力トークン
  • 呼び出しあたりの平均出力トークン
  • 100万トークンあたりの入力レート（プロバイダーから）
  • 100万トークンあたりの出力レート（プロバイダーから）
  • 呼び出しあたりのキャッシュ可能なプレフィックストークン（なしの場合は0）
  • キャッシュヒット割引（例：90％オフの場合は0.90）
  • オフピーク乗数（例：75％オフの場合は0.25、そうでない場合は1）

ステップ：

  1. キャッシュ可能なトークンとキャッシュ不可能な入力トークンを分割します。

    • cacheable_input = cacheable_prefix_tokens
    • variable_input = max(avg_input_tokens - cacheable_prefix_tokens, 0)

  2. キャッシュ可能な部分を割引レートで価格設定します。

    • cacheable_cost = (cacheable_input / 1,000,000) × input_rate × (1 − cache_hit_discount)

  3. 変数入力を完全入力レートで価格設定します。

    • variable_input_cost = (variable_input / 1,000,000) × input_rate

  4. 出力レートで出力を価格設定します。

    • output_cost = (avg_output_tokens / 1,000,000) × output_rate

  5. 呼び出しごとに追加して、オフピーク乗数を適用します。

    • raw_cost_per_call = cacheable_cost + variable_input_cost + output_cost
    • cost_per_call = raw_cost_per_call × off_peak_multiplier

  6. ボリュームでスケーリングします。

    • daily_cost = cost_per_call × calls_per_day
    • monthly_cost ≈ daily_cost × 30

テストの1週間から小さくて実際の例（1月23～30日、2026）：

  • 1日120回の呼び出し
  • 呼び出しあたり3,200入力トークン。そのうち1,800は固定のキャッシュ可能なプレフィックス
  • 呼び出しあたり1,100出力トークン
  • 例のレート：入力ごとに100万あたり$0.40、出力ごとに100万あたり$1.60（実際に置き換える）
  • キャッシュヒット割引：90%
  • オフピーク乗数：0.5（リセラー経由で使用される50％オフウィンドウ）

数学（四捨五入）：

  • 呼び出しあたりのキャッシュ可能コスト = (1,800/1,000,000) × $0.40 × (1 − 0.90) ≈ $0.0000072
  • 呼び出しあたりの変数入力コスト = (1,400/1,000,000) × $0.40 ≈ $0.00056
  • 呼び出しあたりの出力コスト = (1,100/1,000,000) × $1.60 ≈ $0.00176
  • 呼び出しあたりの生コスト ≈ $0.0023272
  • オフピーク調整済み ≈ $0.0011636
  • 日次 ≈ $0.14
  • 月次 ≈ $4.20

それはタイプミスではありません。100万あたりの低レートに加えてキャッシングとオフピークは、「メーターを見守る」サービスを忘れることができるものに変えました。最初は時間を節約しませんでしたが、キャッシュ可能なプレフィックスを本当に固定するのに1時間を費やしました。しかし、その後のすべての呼び出しはより安くなりました。

シートに保ちます。いくつかの保護柵：

  • max_tokensにハード キャップを置きます。出力肥大化は静かな予算の殺し手です。
  • 再試行を個別に追跡します。再試行は実際の支出です。
  • 週単位で平均トークンをログします。トークンドリフトはプロンプトが進化するときに発生します。

これが誰に合うか：

  • 多くの小さくて同様の呼び出しを実行しているチーム（ETL、要約、QA）。
  • バッチジョブをオフピークに移動できるメーカー。

それを愛しないかもしれない人：

  • 長くストリーミングされた出力が必要なアプリケーション。一日中、ピークの時間帯。節約は狭まります。
  • キャッシング サポートなしでセットアップします。あなたはまだ低レートを支払いますが、愚かに低いものではありません。

開始点が必要な場合は、選択したツール内の上記のテンプレートを再構築してください。セットアップは10分で、その後は数時間のGuess を節約できます。

**最後の1つの注意：**複数のプロバイダーを混合している場合は、「1Kトークンあたりのコスト」にシート内のすべてを正規化します。V4をループに保つか、品質上の理由で最前線モデルにタスクを切り替えるかどうかを決めるときに、迅速な並列比較が簡単になります。

オフピークウィンドウがどのように移動するかを見守っています。最近、夕方の初期に移動しました。バッチジョブには問題ありませんが、注視しているだけです。