DeepSeek DeepInferとは？自社運用の要件とAPI利用の選び方

DeepInferはDeepSeekが公開したオープンソースの推論フレームワークです。モデルを実行する仕組みであり、新しいモデルでも、すぐに呼び出せるホスト型APIでもありません。 DeepSeekの利用方法を選ぶ開発者が最初に考えるべきなのは、推論バックエンドの運用まで自分たちの仕事に含める必要があるかどうかです。アプリケーションを提供することが目的なら、ホスト型APIと、自分たちで構築・維持するサービス全体を比較します。

本稿は2026年10月22日に確認した公式ドキュメントに基づきます。対応アクセラレーター上へのDeepInferの導入や、公式の性能グラフの再現は行っていません。以下のチェックリストと費用計算は選定のための道具であり、数値例はすべて仮定です。OfoxはAPIサービスの提供者であり、本稿の発行元でもあります。その立場を明示したうえで、すべての読者にAPI利用を勧めるのではなく、両方の選択肢が成立する条件を説明します。

DeepInfer、モデル、deepseek-recipeの役割を分ける

モデルを提供するには複数の役割が必要です。これらの名前を同じものとして扱うと、費用の見積もりも障害の切り分けも難しくなります。

DeepInferのREADMEが挙げる対応モデルはDeepSeek-V4.1-Flashで、標準のチェックポイントはdeepseek-ai/DeepSeek-V4.1-Flash-1017です。モデル自体の変更は1017アップデートの解説を参照してください。本稿で扱うのは、推論エンジンとその運用方法の選択です。

別リポジトリのdeepseek-recipeは、Chat Completions、Responses、Messagesの各形式を変換します。モデル推論、ツールの実行、HTTP通信は呼び出し側が用意します。同梱されるPythonとRustのサーバー例は模擬推論を使うため、デモからJSONが返ってきても、実モデルが生成した証拠にはなりません。

開発時には、HTTP応答が返ること、プロンプトが正しく整形されること、実モデルが生成を完了することを別々に検証できます。どれか一つに成功しても、残り二つまで正常とは判断できません。

インストール計画の前に対応ハードウェアを確認する

現在のREADMEはNVIDIAのSM100 GPUとHuaweiのAscend 950 NPUを挙げています。基本環境はLinux、GCC 13以降、Python 3.12で、NVIDIA向けはCUDA 13、Ascend向けはCANN 9.2が必要です。これは確認日のドキュメントが示す対象であり、将来の移植を保証するものではありません。

RTX 4090やH100は、この対応対象には含まれていません。ただし、そこから「DeepSeekモデルはそれらのカードでは一切動かない」とは言えません。別のエンジンでモデルを動かせるかどうかは別の互換性の問題です。また、コミュニティーが移植のプルリクエストを出していても、公開済みの版が対応しているとは限りません。

構築工数を見積もる前に、デバイスのアーキテクチャ、ドライバーとツールチェーンの版、チェックポイント、エンジンのリビジョンを記録します。前提条件が足りなければ、まず互換性の確認にとどめます。非対応の構成がコンパイルできるか試すためだけに高価なマシンを借りることは、有用な最初の実験とは言えません。

次の三つを区別してください。

1. 対応しているか：このエンジンの版のドキュメントに、そのプラットフォームが載っているか。
2. 実行できるか：選んだ構成にモデルが収まり、推論を正しく完了できるか。
3. 効率がよいか：想定負荷でスループットとレイテンシーの目標を満たすか。

公式のデプロイに関するQ&Aでは、推奨する本番構成の最小の効率的な運用単位として、prefill用64 GPUとdecode用64 GPUを説明しています。すべてのオフライン試験に必要な絶対的な最小GPU数ではありません。READMEの性能測定でもprefillとdecodeでは構成が異なります。いずれかの数字をそのまま、全用途に共通する「最低限購入すべきハードウェア」に置き換えないでください。

オフライン推論からオンラインAPIにするために必要なもの

公開READMEは、完全なサービスに追加で必要なものとして、KVキャッシュシステム、VE/Prefill/Decodeの分離、データ並列レプリカ間の負荷分散を挙げています。VEは視覚エンコーダー、prefillは入力プロンプトの処理、decodeはその後のトークン生成を指します。一方、分離に必要なエンジン機能の多くは実装済みとも説明されています。基盤となる機能があることと、それらを組み上げたサービスが運用されていることは違います。

計画段階では、各役割に責任者と受け入れ試験を割り当てます。

これは運用の受け入れ基準の提案であり、左列の全機能がDeepInferに同梱されているという説明ではありません。特に、自社でハードウェアを運用すれば自動的にプライバシーが確保されるわけではありません。マシン、ログ、バックアップ、キャッシュされたプロンプトへのアクセス管理は引き続き必要です。

ホスト型APIの提供元にも同様の質問をします。互換性のあるエンドポイント名だけで、ツールの挙動、キャッシュの課金、保存条件まで同じとは判断できません。コーディングクライアントを接続したいだけなら、まずCodexの設定ガイドまたはClaude Codeの設定ガイドを読み、選んだ経路の最新対応状況を確かめてからインフラ追加の必要性を考えます。

同じ負荷とサービス目標で費用を比較する

毎秒トークン数のピーク値だけでは、月額費用は分かりません。まず入力長の分布、出力長、共通プレフィックスの反復率、必要に応じた画像利用、同時リクエスト数、日中のピークを含む代表的な負荷を用意します。完了件数、出力品質、最初のトークンまでの時間、ストリーミング速度に目標を設けます。安価でも目標を満たせないサービスは、同等の比較対象ではありません。

APIの見積もりでは、非キャッシュ入力、キャッシュ入力、出力の単価を分けます。キャッシュ書き込み、保存、プラットフォームなどの料金は、選んだ提供元が実際に課す場合だけ加算します。不明な料金は未確認事項であり、ゼロとして扱いません。トークン数も課金上の定義に合わせ、対象なら推論トークンを含めます。DeepSeek APIの料金ガイドで料金の考え方を確認し、購入判断の前には正確な経路の最新見積もりを取得してください。

課金対象トークン数を100万単位にそろえた一般的な計算式は次のとおりです。

APIの月額費用 =
  非キャッシュ入力の100万トークン単位の数量 × 単価
  + キャッシュ入力の100万トークン単位の数量 × 単価
  + 課金対象出力の100万トークン単位の数量 × 出力単価
  + その他の適用される月額料金

自社運用の月額費用 =
  アクセラレーターの賃料 または 配賦した減価償却費
  + ホスト、ネットワーク、ストレージ
  + 賃料に含まれない電力費
  + 運用とサポートの人件費
  + 冗長化と復旧用の容量
  + 負荷に応じて変わる費用

同じアクセラレーターを賃料と減価償却費の両方で計上しません。賃料に電力が含まれるなら、電力費を重ねて加算しないでください。兼務する人の作業時間も明示的に配賦します。不明な項目は見積もりや測定値を集め、根拠なく細かい合計額にするのではなく幅を示します。

再計算できる例：DeepInferの実際の見積もりではない

1負荷単位を入力1億トークン、課金対象の出力2,000万トークンとし、入力の60%がキャッシュヒットとして課金されると仮定します。説明のためだけに、非キャッシュ入力は100万トークン当たり0.80米ドル、キャッシュ入力は0.20米ドル、出力は2.00米ドルと置きます。いずれも計算用の架空の単価で、DeepSeekやOfoxの現在の料金ではありません。

1単位のAPI変動費は40 × 0.80 + 60 × 0.20 + 20 × 2.00 = 84米ドルです。さらに月額16米ドルのプラットフォーム料金を仮定します。自社運用側は固定費を月額50,000米ドル、追加の変動費を1単位当たり20米ドルとします。これらもDeepInfer用ハードウェアの実見積もりではありません。

この条件で両者が等しくなる式は84x + 16 = 50,000 + 20xで、月間781単位です。ただし、この計算だけで自社運用を勧めることはできません。固定構成がその量を目標のレイテンシーと信頼性で処理できる必要があります。781単位の処理に別のクラスターを追加するなら固定費を再計算し、見かけの損益分岐点がなくなる可能性も考えます。

この例でキャッシュヒット率を60%から20%へ下げると、API変動費は1単位84米ドルから108米ドルに上がります。再利用できる計算が減れば、自社運用側の費用や容量も変わり得ます。一方だけを不自然に一定にしたまま、正確な節約額を主張しないでください。低負荷、通常負荷、ピークの月を分けて評価します。

どちらの案も不採用にできる試験を行う

自社運用を検討するチームは、本番導入を決める前に次の順序で試します。

1. 負荷と合格条件を定義する。適切に機密情報を除いた代表的なサンプルを保存します。品質、レイテンシー、失敗率、データ管理の条件は、方式を選ぶ前に決めます。
2. プラットフォーム互換性を確認する。対応アクセラレーター、ソフトウェア環境、チェックポイント、コードの版を記録します。版が分からないブログのインストールコマンドではなく、リポジトリの最新例を参照します。
3. オフラインで正しく動くか確かめる。その環境で適切な公式サンプルと評価を実行し、結果と失敗を保存します。ビルド成功だけでは、生成品質もプロトコル互換性も証明できません。
4. 本物のサービス経路を試す。模擬バックエンドを置き換え、通常のリクエストとストリーミングを確認します。ツールが必要なら、生成された引数とアプリ側の実行を分けて検証します。不正入力、タイムアウト、クライアントのキャンセル、過負荷も試します。
5. 現実的な負荷を測る。短い・長いプロンプト、温まった・空のキャッシュ、閑散時間、同時実行の急増を含めます。完了量、レイテンシー分布、失敗、課金される全資源を記録します。
6. ホスト型の経路と比較する。モデル版とリクエストの挙動を可能な限りそろえます。量子化、推論設定、機能の欠落など、公平な比較を妨げる差は記録します。
7. 費用を再計算して判断する。切り戻し先を確保し、運用責任者を決めます。必須条件を満たさない案を、都合のよい平均費用で合格にしないでください。

試験に失敗したら、追加費用をかける前に種類を分けます。コンパイラーエラーはビルド環境、メモリ不足はモデルと実行時の容量の問題です。有効な模擬応答はテスト用の仕組みが動いた結果にすぎず、ツール引数の形式不正にはプロトコルとモデル経路の調査が必要です。どの結果も、APIキーの変更やマシンの大型化で全部解決することを意味しません。

チームが運用できる方式を選ぶ

需要が不確か、利用が断続的、短期間で提供する必要がある、アクセラレーターの運用担当がいない、といった場合はホスト型APIが最初の候補になります。どの経路も同じだと思わず、提供元の制限と条件を確認します。

対応インフラとサービス全体を運用できるチームがあり、継続的な負荷や、利用可能なAPIでは満たせない具体的な要件があるなら、自社運用の試験には意味があります。ハードウェアをすでに所有していても無料ではありません。他用途に使えない機会費用と、支える人員を含めます。

最終判断の前に、次の記録を埋めてください。

タスクと正確なモデル版：
必須の品質、レイテンシー、データ要件：
通常時／低負荷時／ピーク時の月間負荷：
測定したキャッシュの挙動と課金トークンの分類：
自社運用のプラットフォームと担当者：
ホスト型の経路と未確認の契約・機能事項：
各案の月額総費用の範囲：
見積もりを支える処理容量の証拠：
試験結果、切り戻し先、判断日：

DeepInferは推論基盤の重要な技術を公開している点で注目に値します。ただし、採用判断の到達点は、運用できるサービスと自分たちの負荷に即した見積もりです。オープンソースであることだけでは、API料金が下がることも、稼働中のアプリを新しいバックエンドに作り替える必要性も証明できません。