DeepSeekの自社運用とAPIを比較する：DeepInferの役割と導入前の確認事項

Ofox運営チームによる公式ガイドの転載です。AI支援で編集しました。DeepInferを実機にデプロイした記事ではなく、公式資料に基づく判断ガイドです。費用の数値例は架空の試算条件です。

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

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

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

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

• 構成要素: DeepSeekのモデル重み / 担当する役割: 出力を生成する学習済みモデル / 確認すること: 正確なチェックポイント、ライセンス、数値精度、必要な能力 /
• 構成要素: DeepInfer / 担当する役割: 対応ハードウェアで推論を実行し、計算をスケジューリングする / 確認すること: アクセラレーターへの対応、エンジン設定、実際の負荷での挙動 /
• 構成要素: deepseek-recipe / 担当する役割: API形式の変換、プロンプトの整形、トークン化、モデル出力の解析 / 確認すること: プロトコルの意味、トークナイザーとモデル版の整合性 /
• 構成要素: 自前のオンラインサービス / 担当する役割: リクエストを受け付け、バックエンドを安定して運用する / 確認すること: 通信、認証、利用枠、ルーティング、可観測性、復旧 /
• 構成要素: ホスト型API / 担当する役割: 外部の事業者が運用するエンドポイントをアプリに提供する / 確認すること: 対応モデル、実際の機能、課金、制限、データの取り扱い /

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モデルはそれらのカードでは一切動かない」とは言えません。別のエンジンでモデルを動かせるかどうかは別の互換性の問題です。また、コミュニティーが移植のプルリクエストを出していても、公開済みの版が対応しているとは限りません。

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

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

• 対応しているか：このエンジンの版のドキュメントに、そのプラットフォームが載っているか。

• 実行できるか：選んだ構成にモデルが収まり、推論を正しく完了できるか。

• 効率がよいか：想定負荷でスループットとレイテンシーの目標を満たすか。

公式のデプロイに関する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用ハードウェアの実見積もりではありません。

• 月間負荷: 10単位 / 仮定したAPI費用: 856米ドル / 仮定した自社運用費用: 50,200米ドル /
• 月間負荷: 1,000単位 / 仮定したAPI費用: 84,016米ドル / 仮定した自社運用費用: 70,000米ドル /

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

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

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

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

• 負荷と合格条件を定義する。適切に機密情報を除いた代表的なサンプルを保存します。品質、レイテンシー、失敗率、データ管理の条件は、方式を選ぶ前に決めます。

• プラットフォーム互換性を確認する。対応アクセラレーター、ソフトウェア環境、チェックポイント、コードの版を記録します。版が分からないブログのインストールコマンドではなく、リポジトリの最新例を参照します。

• オフラインで正しく動くか確かめる。その環境で適切な公式サンプルと評価を実行し、結果と失敗を保存します。ビルド成功だけでは、生成品質もプロトコル互換性も証明できません。

• 本物のサービス経路を試す。模擬バックエンドを置き換え、通常のリクエストとストリーミングを確認します。ツールが必要なら、生成された引数とアプリ側の実行を分けて検証します。不正入力、タイムアウト、クライアントのキャンセル、過負荷も試します。

• 現実的な負荷を測る。短い・長いプロンプト、温まった・空のキャッシュ、閑散時間、同時実行の急増を含めます。完了量、レイテンシー分布、失敗、課金される全資源を記録します。

• ホスト型の経路と比較する。モデル版とリクエストの挙動を可能な限りそろえます。量子化、推論設定、機能の欠落など、公平な比較を妨げる差は記録します。

• 費用を再計算して判断する。切り戻し先を確保し、運用責任者を決めます。必須条件を満たさない案を、都合のよい平均費用で合格にしないでください。

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

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

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

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

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

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

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

英語原文・出典