DeepSeek V4 Pro：本番環境向けフロンティアモデルの検証

DeepSeek V4 Proは、長文脈推論、エージェント性能、推論効率において真の進歩を遂げた、今年最も重要なオープンモデルリリースの一つです。しかし、初期の48時間で、ベンチマークでは明らかにならなかった問題が露呈しました。初期のデプロイ全体で、推論トレースが生成途中でトークンレベルの破損、不正なアーティファクト、予期しない構造化フラグメントに劣化する現象が観測されました。これらは孤立したグリッチやプロンプトの問題ではありません。Fireworksは自社のデプロイで最初にこの問題に遭遇し、その後週末にかけて複数のDeepSeek対応プロバイダーで同じ障害モードを再現しました。

これは初期のV4デプロイに影響を与える、より広範なサーバーパスの正当性問題を示していました。Fireworksの立場は単純です。エンドユーザーを本番システムの不安定性にさらすべきではないということです。そのため、モデルが本番準備完了になるまで出荷しません。彼らは再現結果をSGLang、vLLM、DeepSeekにエスカレーションし、修正が開発・適用されるにつれて実装間での検証を調整しました。そして今日、DeepSeek V4 ProがFireworks上で利用可能になりました。

この投稿では、モデルの概要、エンドポイントを検証する方法、そして本番環境でフロンティアモデルを検証するために実際に必要なことについて説明します。

正しい答え、間違ったトレース

初期の48時間に単純な推論プロンプトをテストした場合、次のような現象が見られたかもしれません。首尾一貫した推論が生成途中で劣化し、構造化されたステップが散在する数字、不正なトークン、トレース内のファイルパスやリポジトリのような断片に取って代わられます。これは一回限りのアーティファクトではなく、初期のV4統合全体にわたるより広範なサーバーパスの正当性問題を示していました。

バグにはより静かな側面もありました。最小限の再現プログラムが初期のエンドポイント全体で一貫して表面化しました。正しい答えは9ですが、影響を受けた実行では推論トレースが生成途中で劣化し始めます。これは標準的な幻覚ではありません。破損は推論トレース自体の内部で発生します。場合によっては、特殊トークンやトレーニングまたはツールアーティファクトに似た構造化フラグメントが推論ストリーム内に現れ、ファイルヘッダーやマークダウンライクな足場を含みます。

マルチステップのエージェントワークフローでは、これがより重要になります。推論出力とツール呼び出しが破損した状態で前方に渡され、ターン全体で障害が複合する可能性があります。Fireworksは週末にかけて、複数のDay-0のDeepSeek V4対応サービングスタックで同じ障害モードを観測しました。

DeepSeek V4は真の進歩

DeepSeek V4は、大規模推論システムを本番で実用的にする方法の転換を表しています。特に、コスト、安定性、コンテキスト長が直接相互作用する長文脈およびエージェントワークロードにおいて顕著です。中核として、V4はスパース活性化を備えた混合専門家アーキテクチャをスケールし、推論コストを線形に増加させることなくモデル容量を増やします。100万トークンのコンテキストウィンドウと組み合わせることで、単一モデルが維持できる状態の上限が変わり、即時のコンテキスト崩壊や法外な計算コストなしに、マルチドキュメント推論と拡張エージェントトレースが可能になります。

アーキテクチャは生のスケーリングではなく、長文脈効率を中心に設計されています。ハイブリッドアテンション機構は、スパースと圧縮パターンを組み合わせることでコンテキスト拡張のコストを削減し、KVキャッシュプレッシャーを低減し、先行世代モデルでコンテキスト長が増加するにつれて典型的に見られる劣化を軽減します。システム面では、V4は現在のアクセラレータハードウェアに適合する低精度FP4/FP8重みを備えた最新の推論スタック向けに設計されています。結果は理論上のピーク性能ではなく、本番環境で予測可能で経済的に viable な長文脈推論です。

総合すると、V4はベンチマークのアップグレードというよりも、実際のデプロイ制約下での「スケールでの信頼できる推論」の意味の転換です。長文脈は使用可能なままであり、モデル容量は推論予算内に収まります。

あなたのDeepSeek V4エンドポイントは正常に動作していますか？

今日DeepSeek V4を使用している場合、健全なサービングパスと壊れたパスを区別するいくつかの簡単なチェックがあります。

1. 推論トレースは長い推論プロンプトの下で首尾一貫している必要があります。高い推論努力設定では、出力は散在トークン、ファイルライクな文字列の注入、不正なアーティファクトなしに、一貫した構造化推論を示す必要があります。推論システム内でのトークンレベルの破損の繰り返しは、基礎となるサービング問題の強いシグナルです。

1. 推論コンテンツはツール呼び出し間でクリーンにラウンドトリップする必要があります。エージェンティックワークフローでは、推論出力とツール呼び出しはターン間で構造的に intact でなければなりません。推論フィールドの欠落や null、または呼び出し間のアシスタント状態の受け渡しの失敗は、シリアライゼーションまたは推論統合の誤りを示します。

1. マルチターンのエージェント動作は安定している必要があります。シングルターンの完了は問題を隠す可能性があります。マルチステップワークフローでは、モデルはツール使用、コンテキスト更新、中間推論ステップにわたって劣化や構造のドリフトなしに首尾一貫している必要があります。

これらのチェックが失敗した場合、問題はプロンプト関連である可能性は低く、通常はモデル能力の制限ではなく、サービングまたは統合レベルの問題を示します。

私たちはこれをやるので、あなたはやる必要がありません

フロンティアモデルのローンチはもはや単一のスタック内に収まりません。モデルプロバイダー、推論フレームワーク、カーネル最適化、アプリケーション層にまたがり、障害はそのチェーンのどこにでも現れる可能性があります。DeepSeek V4に関して、私たちはこの問題をプロバイダー固有のバグではなく、システムレベルの正当性問題として扱いました。サービング実装全体でクロススタック再現を実行し、推論エンジンメンテナーと調整し、モデルを本番に公開する前に複数の環境で修正を検証しました。

目標は、モデルがエンドユーザーに届いた後にデバッグするのではなく、本番に達する前にサービングパスの問題を防ぐことです。これがFireworksの役割です。システムレベルでフロンティアモデルを検証し、チームがモデルの上に構築することに集中できるようにし、その下でどのように実行されるかのデバッグを不要にします。これがフロンティアモデルリリースと本番システムの間の信頼性レイヤーです。

ローンチ検証

今日のローンチ基準は運用上のものでした。上記のアーティファクトが本番トラフィック用のデプロイパスで再現しなくなることです。実際にそうなりました。

チェック：修正前 vs 修正後

• 数学のなぞなぞでの長い推論トレース：特殊トークンとファイルパス文字列がトレースにリーク → クリーンなトレース、アーティファクトなし
• 基本的なカウントプロンプトでの推論トレース：文境界で散在する数字がドロップ → クリーンなトレース、アーティファクトなし
• 推論努力モード全体でのマルチプロンプトスモークテスト：複数のプロンプトでトークンレベルのリークが再現 → リークなし

すべてのテストで、Day-0のサービングパスで観測された障害モードは、検証済みデプロイスタック上で再現不可能になりました。

FireworksでDeepSeek V4 Proを試す

DeepSeek V4 Proは現在、Fireworksのサーバーレスおよびオンデマンドデプロイメントで利用可能です。現在の価格とデプロイオプションについてはモデルページを参照してください。DeepSeek V4 Flashもまもなくオンデマンドデプロイメント限定で利用可能になる予定です。推論努力を有効にした使用例のコードも提供されています。

DeepSeek、SGLang、vLLMチーム、Ant Group（修正PR）、およびOllamaとhumansand.ai（最初に問題を表面化）に感謝します。SGLangのDay-0ブログにはV4推論スタックに関する詳細な技術解説があり、全文を読む価値があります。