H100やRTXを使うチームがまず知るべきこと
DeepInferでは、H100のサポートは公式発表・公式ドキュメントのいずれにも記載されていません。RTXも同様に、公式サポートは確認できません。 現行リリースの対象はDeepSeek-V4.1-Flashで、NVIDIAではCUDA 13を使うSM100、HuaweiではCANN 9.2を使うAscend 950が対応ハードウェアとして示されています。リポジトリの動作要件はLinux、GCC 13以降、Python 3.12です(公式DeepInferリポジトリ)。
「一覧に載っていない」というのは、調達や本番運用の判断におけるサポート対象外という意味です。実験的なパッチまで含めて、絶対にコンパイルできないという証明ではありません。
DeepInferが現在公式にサポートしている範囲
サポート対象は、単に「NVIDIA GPU」や「DeepSeekモデル」という括りではありません。アクセラレーターの世代、ソフトウェアスタック、モデルの実行経路まで含めた組み合わせとして定義されています。
| 項目 | 公式に記載されたサポート |
|---|---|
| モデル | DeepSeek-V4.1-Flash |
| デフォルトのチェックポイント | deepseek-ai/DeepSeek-V4.1-Flash-1017 |
| NVIDIAアクセラレーター | SM100(Blackwell世代のデータセンター向けGPUに関連) |
| NVIDIAツールチェーン | CUDA 13 |
| Huaweiアクセラレーター | Ascend 950 NPU |
| Huaweiツールチェーン | CANN 9.2 |
| ホスト要件 | Linux、GCC 13以降、Python 3.12 |
| 推論モード | オフラインのプロセス内推論 |
DeepSeekのデプロイに関するQ&Aでは、スケールアップ構成のベンチマークとして、PrefillにSM100 GPU 4基、DecodeにSM100 GPU 64基を使ったトポロジーが示されています。これはSM100での測定結果であり、H100の必要容量を示すものではありません。
SM100対応だけではH100やRTX対応とは言えない理由
DeepInferの公式リストには、H100、SM90、RTXの各製品型番は登場しません。CUDAに対応していることだけで、DeepInferの動作まで保証されるわけでもありません。
このリポジトリには、FlashMLA、DeepGEMM、DeepEP、TileLangのオペレーションなど、アーキテクチャに強く依存するコンポーネントが組み込まれています(プロジェクトドキュメント)。GPUターゲットとして認識されても、実行時に失敗したり、結果が不正になったり、移行の目的だった性能が得られなかったりする可能性があります。
したがって、次の3つは分けて考える必要があります。
- そのアーキテクチャ向けにコードをコンパイルできる。
- 正しい出力と安定した分散動作でモデルを実行できる。
- 実用的なレイテンシーとスループットでデプロイを検証できる。
ビルドに成功して確認できるのは、最初の項目だけです。DeepInferの公開資料には、H100やRTXのベンチマーク、公式のSM90ビルド手順、検証済みのコンシューマー向けRTX構成は掲載されていません。
既存インフラからの移行パターン
H100などHopperシステムを使っている場合
稼働中のH100向け推論基盤を、DeepInferを試すためだけに置き換えるべきではありません。現時点では、サポート済みのデプロイではなく、実験的な移植プロジェクトとして扱うのが適切です。
現実的な移行手順は次のとおりです。
- 本番のモデルサーバーは変更せず、そのまま維持する。
- DeepInfer、CUDA、ドライバー、コンパイラー、モデルのバージョンを固定した隔離ブランチを用意する。
- コンパイル前に、アーキテクチャ依存の各種依存関係を洗い出す。
- 既知の正常なランタイムと比較し、数値結果を検証する。
- Prefillレイテンシー、Decodeレイテンシー、同時実行数、メモリ使用量、障害復旧を測定する。
- チームにとって重要なワークロードが改善する場合に限り、その移植版を採用候補にする。
実用的な代替案としては、vLLM、SGLang、TensorRT-LLMのように、H100構成を明示的にドキュメント化している推論ランタイムを評価する方法があります。選定では、DeepInferのSM100ベンチマークではなく、使用するDeepSeekチェックポイント、量子化方式、API機能、分散トポロジーを基準にしてください。
RTXワークステーションやRTXサーバーを使っている場合
DeepInferの公式リストには、RTXの型番はひとつも掲載されていません。また、公開されているベンチマークのトポロジーは大規模推論向けです。RTX 1枚、あるいは小規模なRTXプールを、Prefill用4 GPU構成やDecode用64 GPU構成の安価な代替として考えるべきではありません。
開発、評価、小規模なセルフホスト型エンドポイントが目的なら、汎用のローカル推論ランタイムを使うのが現実的です。将来的なアーキテクチャ別ポートに備えてDeepInferをウォッチリストに入れておくのは構いませんが、まだマージされていないIssueやフォーラム上の情報を前提に予算を組むのは避けてください。
SM100またはAscend 950を利用できる場合
現行の公式サポート表に合致するのは、このルートだけです。ただし、この場合でもDeepInferは完成済みのオンラインAPIサービスではありません。公式のデプロイノートでは、永続KVキャッシュ、Prefill/Decodeのオーケストレーション、レプリカのロードバランシングなど、本番運用に必要なコンポーネントが未実装であることが説明されています。
そのためDeepInferは、エンジンの仕組みを研究・ベンチマークしたいチーム、必要なアクセラレーター構成を用意できるチーム、周辺のプラットフォームを自分たちで構築できるチームに向いています。マルチモデルAPIゲートウェイに最適な選択肢だと、自動的に判断できるわけではありません。
GPU以外にもあるデプロイ上の制約
ハードウェア対応は、移行判断におけるひとつの条件にすぎません。公開リリースは、完成したOpenAI互換サーバーではなく、オフライン推論として説明されています。未実装の機能は、システム構成にも影響します。
| 不足している機能 | 運用上の影響 |
|---|---|
| 永続または分散KVキャッシュ | オンラインでのマルチターン再利用を別の仕組みで補う必要がある |
| Prefill/Decodeの分離 | ステージのオーケストレーションと配置を運用側で用意する必要がある |
| レプリカのロードバランシング | ルーティングとキューを考慮した負荷分散が外部に残る |
| HTTP、認証、ツール連携 | APIゲートウェイとエージェント層が別途必要になる |
別プロジェクトのdeepseek-recipeは、Messages、Chat Completions、Responses形式の変換を行います。ただし、推論を実行するものではなく、完全な本番サービスを提供するものでもありません。
ハードウェアを変更する前の検証チェックリスト
DeepInferへの移行を承認する前に、少なくとも次の項目について根拠を確認してください。
- 公式のアーキテクチャおよびビルド対応:使用するGPUそのものがリストに掲載されているか。固定した環境をクリーンなマシンで再現できるか。
- カーネルと正確性の検証:Attention、GEMM、エキスパート並列の各カーネルが、期待どおりの出力、構造化レスポンス、長文コンテキストでの動作を実現できるか。
- 分散性能:想定するGPU数と接続トポロジーが、目標とする同時実行数およびメモリ使用量で安定するか。
- サービスとしての完成度:KVキャッシュ、ルーティング、認証、HTTP通信、レプリカの負荷分散をどこで提供するのか。
最初の質問への答えが「いいえ」なら、そのプロジェクトは実験として扱ってください。サービス関連の質問への答えが「外部に用意する」なら、その開発工数も移行コストに含める必要があります。
DeepInferのH100対応に関するFAQ
DeepInferはNVIDIA H100で動作しますか?
H100のサポートは公式にはドキュメント化されていません。現在、NVIDIA向けのサポート対象として記載されているのはSM100です。実験的な移植が可能な場合はありますが、引用した資料には公式のH100ビルド手順も、検証済みのH100ベンチマークもありません。
DeepInferはRTX 4090、5090などのRTXカードに対応していますか?
RTXのサポートは公式リストに掲載されていません。引用した公式資料にも、検証済みのRTX構成はありません。上流プロジェクトがアーキテクチャを明記し、カーネルを検証するまでは、RTXでのデプロイはサポート対象外として扱ってください。
H100チームは代わりに何を使うべきですか?
H100を明示的にサポートしているランタイムを継続利用または評価し、自分たちのチェックポイントとトラフィックパターンで比較してください。実用的な出発点としてはvLLM、SGLang、TensorRT-LLMがあり、DeepInferは将来の移植候補、またはSM100インフラを評価するきっかけとして捉えるのが適切です。
対象アーキテクチャ、カーネル、サービス層、ワークロードでの結果が文書化されるまでは、H100やRTXへの移植は実験扱いにしてください。