DeepSeekは、大規模なAIサービスを支える推論フレームワーク「DeepInfer」をオープンソースで公開した。DeepSeek-V4.1-Flashに対応し、NVIDIAのGPUとHuawei AscendのNPU向けに、モデルの実行や処理の分散を最適化する推論エンジンを提供する。これまで個別の計算カーネルを公開してきたDeepSeekだが、今回、モデルの実行を管理するフレームワーク全体へと公開範囲を広げた。ただし、公開版はオフライン推論が中心であり、多数の利用者からの要求を処理するオンラインサービスを構築するには、追加の仕組みが必要になる。公開された最適化技術をどこまで活用できるのか、また、同社が示した性能を実際の運用環境でどう評価すべきかが、導入を判断するうえで重要となる。
公開された推論エンジンと、本番運用に必要な機能
DeepInferは、学習済みAIモデルを実行し、入力に応じた出力を生成するためのソフトウェアである。公式GitHubリポジトリでApache License 2.0の下に公開された。DeepSeekは公式READMEで、自社の大規模サービスを支える推論フレームワークだと説明する一方、今回の公開版については、大規模なサービス運用に必要な中核機能を備えたオフライン推論エンジンと位置づけている。
公開されたコードには、高速化された計算カーネルやモデル実行処理に加え、複数のデバイスに計算を分散する並列処理機能が含まれる。生成するトークンの候補を先に予測し、その正しさをまとめて検証する「投機的デコード」や、JSON Schema、正規表現、文法規則に従って出力を制限する「構造化出力」にも対応する。READMEによると、DeepInferは主にvLLMを基盤として開発され、SGLangやTensorRT-LLMの設計も参考にしている。
ただし、DeepInferだけでオンラインサービスを構築できるわけではない。DeepSeekは、サービス全体で利用するKVキャッシュ管理システムや、データ並列で動作する複数の推論エンジン間の負荷分散機能を、今回の公開範囲に含めていない。KVキャッシュは、過去の入力に対する計算結果の一部を保存し、同じ文脈を処理する際の計算量を減らす仕組みだ。推論エンジン内部でKVキャッシュを保持する機能と、複数のサーバー間でキャッシュを保存・共有する仕組みは区別する必要がある。
DeepInferの公開範囲と、本番導入に必要な作業
| 確認項目 | 今回の公開版で利用・確認できる機能 | 導入時に必要な作業 |
|---|---|---|
| モデルの実行 | V4.1-Flashのオフライン推論と各種最適化 | 対応ハードウェアと実行環境を用意し、動作を検証する |
| サービス構成 | 処理段階の分離に必要なエンジン側の機能の多くを実装 | 画像処理・入力処理・出力生成を分離する運用基盤を構築する |
| キャッシュと要求の振り分け | 公式Q&Aで本番システムの設計を公開 | サービス用KVキャッシュ管理とデータ並列間の負荷分散を実装する |
| 性能評価 | ベンチマーク用スクリプトと測定条件を公開 | 実際のトークン受理率や負荷条件を反映した性能を測定する |
この表は、公式READMEの公開範囲と、推論システムの構成を解説した公式Q&A、ベンチマークの測定方法を照合して整理したものだ。Q&AではDeepSeekが実際に使用している本番システムの設計も詳しく説明されているが、そこで紹介された機能がすべて公開コードに含まれるわけではない。推論エンジンそのものを検証する段階と、多数の利用者に安定して応答するサービスを構築する段階では、必要な技術や設備が異なる。
投機的デコードの効率化とGPUの待ち時間削減
DeepInferの特徴的な最適化の一つが、投機的デコードにおける検証処理の効率化だ。DeepSeekの「DSpark」は、あらかじめ生成した候補トークンのうち、実際に採用される見込みが高いものを優先して検証する。候補を大量に生成しても、採用される可能性が低ければ、検証に費やした計算が無駄になりやすい。そこで「Confidence Head」と呼ばれる予測機構で各候補の受理確率を推定し、処理効率が最も高くなるように検証対象の長さを動的に調整する。
公式Q&Aによると、DeepSeekの本番システムでは一度に5トークンの候補を生成する。ただし、毎回5トークンすべてを検証するのではなく、候補ごとの受理確率とハードウェアの処理性能を考慮して、検証する範囲を選択する。これはモデルが生成できる文章の品質や能力を高める技術ではなく、トークンの検証に必要な計算資源を効率よく使うための仕組みである。
もう一つの重要な機能が、CPUとGPUの処理を並行して進める非同期スケジューリングだ。通常の推論処理では、GPUの計算結果をCPUが受け取り、後処理や次の計算の割り当てを行うため、その間GPUが待機することがある。DeepInferでは、GPUが現在の計算を進めている間にCPUが次の処理を準備し、GPUの待ち時間を減らす。公式READMEによれば、この機能は既定で有効になっている。
過去の文脈を再利用する処理にも、「SWA bounded replay」と呼ばれる最適化が導入されている。これは、直近128トークンに再計算の対象を限定し、Sliding Window Attention（SWA）のKVキャッシュを近似的に再構築する技術だ。DeepSeekによると、出力生成を担うデコーダ側でもこの方法を使用することで、入力処理全体の計算量をほぼ半減できるという。本来であれば、過去の長い文脈を再計算してキャッシュを正確に復元する必要があるが、直近の限られた範囲だけを計算することで負荷を抑えている。ただし、再構築されるキャッシュは厳密な再計算によるものとは異なるため、計算量の削減効果だけでなく、近似を伴う方式であることも理解しておく必要がある。
公表された性能は、トークン受理率と負荷条件に注意
DeepSeekは公式READMEでDeepInferの性能測定結果を公開している。入力を読み込む「Prefill」段階にはNVIDIAのSM100 GPUを4基、出力を生成する「Decode」段階には64基を使用しており、それぞれ高速な相互接続で結ばれた単一の領域内で測定したものだ。GPUの台数や接続構成が異なる環境と性能を比較する場合は、こうした測定条件を考慮する必要がある。
特に注意が必要なのは、出力スループットの計算方法だ。公式のベンチマーク実行例では、投機的デコードで生成した候補トークンがすべて受理されることを前提に、処理量を算出している。1回の処理で生成されたとみなすトークン数は、要求ごとに「1＋候補トークン長」となる。この計算では実際の受理率を反映しないため、公表された毎秒・GPU当たりのトークン処理量を、利用者が実際に受け取る文章の生成速度と同一視することはできない。
この違いは、DSparkの最適化効果を評価する際にも重要になる。DeepSeekは、エキスパート並列（EP）とデータ並列（DP）をともに64に設定したベンチマークデータを基に、検証する候補の長さを動的に変更した場合の性能向上を推計している。同社によると、本番環境の動作条件に近い、各並列処理単位で約60系列を同時に扱う状況では、常に5トークンを検証する固定長方式と比べて、スループットが約4〜7%向上するという。
ただし、性能向上の幅は同時に処理する系列数によって変わる。DeepSeekが公開した比較表では、同時系列数が16の場合は動的長方式のスループットが1.5%低下する一方、60の場合は5.4%向上している。つまり、検証するトークン数を減らせば、どのような負荷条件でも必ず高速化するわけではない。また、これらの値は同社の測定データから算出した推計であり、他の推論フレームワークより優れた性能を持つことを直接証明するものでもない。
実際の導入に当たっては、同時に処理する要求数や候補トークンの受理率を踏まえ、必要な応答速度を維持できるかを確認しなければならない。公開されたベンチマークは推論エンジン自体の性能を評価する手掛かりにはなるが、オンラインサービス全体の処理能力は、KVキャッシュの再利用効率やサーバー間の負荷分散にも左右される。したがって、自社の利用状況に近い条件で測定し直すことが重要となる。
NVIDIAとHuawei Ascendに対応、ただし本番運用には追加の構築が必要
DeepInferが正式に対応するハードウェアは、NVIDIAのSM100 GPUとHuawei Ascend 950 NPUである。実行環境にはLinux、GCC 13.0以上、Python 3.12が必要で、NVIDIA環境ではCUDA 13、Ascend環境ではCANN 9.2を使用する。対応するプラットフォームが明確に限定されているため、既存のGPU環境でそのまま実行できるとは限らない。
推論結果の再現性を確保する機能にも制約がある。バッチの組み合わせが変わってもモデルの計算結果を一致させる機能はNVIDIA環境に限られ、明示的に有効化する必要がある。さらに、同じ入力トークンとサンプリング設定から同一の出力を得る決定的サンプリングを使用するには、動的長の検証を無効にし、固定シードを指定しなければならない。つまり、DeepInferが対応する機能をすべて同時に使用できるわけではなく、再現性と最適化の設定条件を確認する必要がある。
本番運用に必要なハードウェアの規模も、通常の動作検証とは大きく異なる。公式Q&Aでは、効率を重視した最小の構成として、入力処理に64基、出力生成に64基のGPUを使用する構成を挙げている。これは出力生成に64基以上のGPUを使用する同社の推奨構成を前提としたものであり、オフライン推論を動かすための最低要件ではない。小規模な環境でモデルを試すことと、大規模な利用者向けサービスで高い処理効率を確保することは、分けて考える必要がある。
DeepSeekはDeepInferとともに、APIの要求形式とモデルが処理するトークン列を相互に変換する「deepseek-recipe」も公開した。これは異なるAPI形式からの要求をDeepSeekモデル向けに変換し、生成結果を対応する形式で返すためのソフトウェアである。サービス構築に役立つ部品ではあるものの、要求の負荷分散や共有KVキャッシュ管理まで含めた仕組みではない。今回の公開によって、外部の開発者はDeepSeekが採用する推論最適化技術と、それをサービスに組み込むための具体的な実装を参照できるようになった。
DeepInferの公開は、DeepSeekの推論技術を第三者が検証し、自社のシステムに取り入れるための重要な一歩となる。ただし、公開された推論エンジンの性能が、そのままオンラインサービス全体の性能につながるわけではない。実際のトラフィックでトークン受理率や応答時間を測定し、KVキャッシュと負荷分散を含めたシステム全体の効率を評価することが、今後の導入判断を左右するだろう。
