AIREITERGitHubでコードが公開されていると、それだけでハードウェア環境まで誰でも使えるように見えてしまいます。DeepSeekのAscend対応は実用的な成果ですが、NVIDIAクラスタをワンコマンドで置き換えるものではありません。現行リリースの中心はAscend 950向けカーネルで、利用にはCANN、torch_npu、そして対応ハードウェアが必要です。
結論：公開されたコンポーネントであって、完成済みのAscendクラスタではない
DeepSeekは、HuaweiのNPUを対象にしたAscend専用コードを公開しています。その代表例がDeepGEMM-Ascendです。MITライセンスで提供されるカーネルライブラリで、DeepGEMMのAPI形状を保ちながら、Huawei NPU向けに実装されています。初期リリースが対応するのはAscend 950デバイスで、環境としてCANN 9.20、torch_npu、Python 3.10以降、C++20ツールチェーン、TileLangが指定されています。
つまり、対応するAscend環境を持つチームなら、公開コードを調査し、ビルドし、ベンチマークを取り、必要なカーネルを統合できます。ただし、これだけで学習や本番運用まで完結するわけではありません。
現時点でコードを評価できるのは、Ascend搭載の研究機関、クラウド事業者、企業チームです。NVIDIAだけを使っている開発者もコードを読むことはできますし、DeepSeekのNVIDIA向けプロジェクトを利用することもできます。しかし、AscendカーネルをH100やコンシューマー向けGeForceカードで実行することはできません。
DeepSeekが実際に公開したもの
DeepSeekのopen-infra-indexでは、インフラ関連の取り組みが複数のレイヤーに分けて整理されています。元のインデックスは主にNVIDIA/Hopper向けで、FlashMLAはHopper GPU用のMLAデコードカーネル、DeepEPはエキスパート並列通信ライブラリ、DeepGEMMはFP8 GEMMライブラリです。DualPipeとEPLBは分散並列処理を、3FSとSmallpondはデータアクセスを担います。
今回のAscend対応は、すべてのレイヤーを一度に置き換えるものではありません。対象となる計算パスのハードウェアを変更する取り組みです。公開されている成果の中で最も分かりやすいのがDeepGEMM-Ascendで、次の処理をカバーしています。
- BF16、FP8、FP4のGEMM
- MQA logits
- Grouped GEMMとMegaMoEの処理
- mHC prenormカーネル
- Ascend専用のJITコンパイルとレイアウト変換
プロジェクトはDeepGEMMとのAPI互換性をうたっています。これはモデルエンジニアにとって大きな利点ですが、CUDAバイナリがそのまま移植できるという意味ではありません。Ascend固有の行列レイアウト、スケーリング係数のパッキング、コンパイラ、ランタイム、デバイス管理APIは、依然として個別に対応する必要があります。
NVIDIA中心の構成をAscend側の要素に対応づける
以下の表は、実装が完全に同一だと主張するものではなく、システム上の役割を対応づけたものです。対応要素は似た仕事をしますが、API、通信ファブリック、カーネル戦略は異なる場合があります。
| レイヤー | 確認できるAscendコードまたは依存関係 | NVIDIA側の対応要素 | 境界 |
|---|---|---|---|
| 行列積 | DeepGEMM-Ascend | DeepGEMMとCUDA/Tensor Coreカーネル | GEMMとしての役割は同じだが、ハードウェア命令とデータレイアウトが異なる |
| MoEのGrouped Compute | DeepGEMM-AscendのM-Grouped GEMMとMegaMoE | DeepGEMMのMoEレイアウトとカスタムCUDAカーネル | エキスパート計算を融合するが、対応する形状や制約はプラットフォーム依存 |
| エキスパートのディスパッチ | このリリースでは、DeepSeekによるAscend向けの完全なディスパッチライブラリは確認できない。Ascendの集合通信とオペレーター統合を利用する | DeepEPとNVLink/RDMA | 解くべきシステム上の問題は似ているが、リポジトリを相互に置き換えられるわけではない |
| Attention/logits | DeepGEMM-AscendのMQA logits | Hopper向けのFlashMLA | 処理内容は近いが、FlashMLAは明確にHopper向け |
| PyTorchのデバイスブリッジ | TorchNPU（torch_npu） | PyTorch CUDAバックエンド、CUDAランタイム、cuBLAS | TorchNPUはAscend NPUを呼び出すもので、CUDAをエミュレートするわけではない |
| コンパイラ／オペレーターツールチェーン | CANNとAscend C/Bishengツール | CUDA Toolkit、NVCC、PTX、cuBLAS、Triton | Pythonコードが似ていても、デバイスとの契約は変わる |
| 分散ランタイム | TorchNPUの集合通信とHuawei／オペレーターのデプロイツール | NCCL、CUDA対応ネットワーク、NVIDIAクラスタソフトウェア | ファブリック、ドライバー、集合通信、フレームワークのバージョンは別々に管理する必要がある |
| ストレージ／データパス | ここで扱う範囲では、DeepSeekによるAscend専用のストレージコンポーネントは確認できない。ストレージは運用者が用意する | DeepSeekの3FS/Smallpondと、運用者側のストレージスタック | カーネルのリリースに対応するストレージクラスタは含まれない |
要するに、Ascend側の各要素はシステム上の役割を埋めるものですが、NVIDIAのソフトウェアエコシステム全体を消し去るものではありません。
計算カーネル：DeepGEMM-AscendとDeepGEMM
今回のリリースで最も具体的な橋渡し役となるのがDeepGEMM-Ascendです。READMEによると、AscendのMADプリミティブを薄く抽象化し、フラクタルレイアウト、アライメント制約、アドレス計算、低レベルパラメーターを隠蔽します。スパースデータロードやコルーチンベースのパイプライン処理など、Ascend固有の最適化も使われています。
動作要件はかなり具体的です。Ascend 950シリーズのハードウェア、CANN 9.20、torch_npu、Python 3.10以降、C++20対応の標準ライブラリ、TileLangに加えて、Tree-sitterなどのビルド依存関係が必要です。ドキュメントに記載されたインストール手順では、git clone --recursiveを実行した後、pip install . --no-build-isolationでインストールします。
リポジトリの報告では、Ascend 950DTのテスト環境で、Dense GEMMの利用率が公称ハードウェア上限の99.8%に達しています。BF16のあるケースでは、ハードウェア上限432 TFLOPSに対して431 TFLOPS、FP8では865に対して861と記載されています。ただし、これは特定の形状におけるカーネル性能であり、DeepSeek全体のエンドツーエンドスループットでも、NVIDIAクラスタとの性能が同等であることの証明でもありません。
MoE実行：MegaMoEとエキスパートのディスパッチ
DeepSeekのopen-infra-indexは、V3/R1システム向けのエキスパート並列インフラを示しています。重要なのは、1回の行列積がどれだけ速いかだけではありません。トークンを振り分け、各エキスパートで計算し、ランク間で結果を集約する必要があります。
DeepGEMM-AscendのMegaMoEベンチマークは、エキスパート並列のディスパッチ、2つのGrouped GEMM、SwiGLU、combine処理を融合しています。構成はEP8、top-k 6、共有エキスパート1個で、8ランクの平均値です。384エキスパート、16,384トークンのケースでは、READMEにある1つのhidden/intermediate構成で846.3 TFLOPS、別のケースで通信帯域103.3 GB/sが報告されています。
NVIDIA側で対応するのは、DeepEPに加えて、DeepGEMMのMoEレイアウト、そしてNCCL/NVLink/RDMAを含む周辺環境です。解くべきアーキテクチャ上の課題は似ていますが、トークン数、エキスパートのルーティング、精度、ランク数、ネットワーク条件をそろえない限り、ベンダー間で数値を単純に比較することはできません。
モデル固有のカーネル：MQA logitsとmHC prenorm
Ascend側のプロジェクトには、「GEMMの移植」とだけ説明すると見落としやすいカーネルも含まれています。DeepGEMM-Ascend READMEでは、MQA logitsのベンチマークをDeepSeek Lightning Indexer向けの処理として説明しています。FP8とFP4のprefillおよびdecodeケースが掲載されており、FP4 decodeは記載された形状で124.2マイクロ秒、FP8は150.9マイクロ秒です。
同じREADMEには、DeepSeekのmHCモジュール、つまりManifold-Constrained Hyper-Connections向けのHC prenormカーネルも記載されています。掲載されたNとKの値では、M=8,192のときメモリ帯域が3,463 GB/sに達します。これらは特定のワークロードに合わせた最適化の結果であり、モデルのあらゆるオペレーターやサービング経路をカバーしていることを示すものではありません。
フレームワークとランタイム：CANN／TorchNPUとCUDA
HuaweiのTorchNPUリポジトリでは、TorchNPUをAscend NPU向けのPyTorchアダプターと説明しています。機能として、標準およびカスタムのPyTorch API、FSDP2、DTensor、集合通信、グラフキャプチャ、プロファイリング、WatchDog監視、メモリ管理機能などを挙げています。
NVIDIA側で概念的に対応するのは、PyTorchとCUDAランタイムおよび各種ライブラリの組み合わせです。ただし、運用面の差は大きくなります。Ascend環境では、対応するCANNのリリース、ドライバー、ファームウェア、Python、PyTorch、TorchNPUのバージョンをそろえなければなりません。TorchNPUのドキュメント例ではCANN 9.1.0、PyTorch 2.12.0、torch-npu 2.12.0をインストールしています。一方、DeepGEMM-AscendはCANN 9.20を別途指定しています。この違いは、無関係なガイドのコマンドを混ぜず、各リポジトリの互換性マトリクスに従うべきだという注意点です。
HuaweiのCANNドキュメントでは、CANNをフレームワークとAscendハードウェアをつなぐソフトウェア層と位置づけ、ランタイムやオペレーター開発の機能を含むと説明しています。実際には、CANNは単一のCUDAライブラリというより、プラットフォームの土台に近い存在です。PyTorchモデルのPythonコードは見慣れた形を保てても、Ascend専用カーネル、グラフの挙動、デバッグ手順が必要になる場合があります。
今回のリリースに含まれないもの
DeepSeekの元のオープンインフラストラクチャーインデックスには、3FSやSmallpondのようなストレージおよびシステムレベルのプロジェクトも含まれています。また、DualPipe、EPLB、推論システムのアーキテクチャについても説明されています。これらは重要な参照先ですが、Ascend向けカーネルのリリースを、それらすべての完全な移植版と受け取るべきではありません。
本番クラスタには、ハードウェアのプロビジョニング、ドライバーとファームウェア、CANNのインストール、インターコネクト設定、分散ランタイム、可観測性、チェックポイント、障害復旧、サービングまたは学習用オーケストレーターが必要です。Huawei CloudのDeepSeek deployment guideでは、インスタンス、ネットワーク、サブネット、セキュリティグループなど、インフラ側の要素が説明されています。これらはデプロイの前提条件であって、DeepGEMM-Ascendそのものに含まれるものではありません。
この線引きが特に重要になるのが学習です。公開カーネルによってボトルネックを改善できても、公開リポジトリだけでフロンティア規模の学習を再現できることにはなりません。
現時点で利用できるのは誰か
| ユーザー／組織 | 今すぐ使えるか | 必要なもの | 実務上の判断 |
|---|---|---|---|
| Ascend 950ハードウェアを持つチーム | 対応カーネルなら利用可能 | Linux環境、対応するドライバー／ファームウェア、CANN 9.20、TorchNPU、コンパイラ、互換性のあるPython／PyTorch環境 | 最も適した初期導入先 |
| Ascendのキャパシティを持つHuawei Cloudまたは企業運用者 | 条件付きで可能 | 対応インスタンス／クラスタ、正確なソフトウェア構成、デプロイの知識 | 管理された評価やサービングには現実的 |
| 古いAscendハードウェアを持つ研究機関 | 自動的に使えるわけではない | デバイス対応を確認すること。初期のDeepGEMM-AscendリリースはAscend 950シリーズで開発・検証されている | 910B/910C互換だと決めつけない |
| NVIDIAのみを搭載したワークステーションの所有者 | Ascendカーネルは利用不可 | Ascendハードウェアが明示的な要件 | 代わりにNVIDIA向けのDeepSeekリポジトリを使う |
| アクセラレーターにアクセスできない一般的なPyTorch開発者 | 実行環境として意味のある形では不可 | コードやAPIを調査することはできるが、ハードウェアベンチマークは再現できない | ドキュメントを読めることと、実行できることは別 |
| フロンティア規模の学習環境を完成済みの形で置き換えたいチーム | 現時点で不可 | カーネルリポジトリを超えた完全なクラスタ、システム統合、本番検証が必要 | pip installではなく、インフラプロジェクトとして扱う |
必要条件を見ても、実際の境界は明確です。現行リリースは、Ascend 950ハードウェア、CANN、torch_npuに結びついています。これは、アクセラレーター全般に対応するという主張よりも、はるかに限定されたものです。
公開された数値から分かること、分からないこと
Dense GEMMで99.8%という数値は、記載されたAscendカーネルが、特定の形状においてテスト対象デバイスを効率よく使えることを示す有力な材料です。MegaMoEの表からは、DeepSeekが単独の行列積だけでなく、融合されたエキスパート並列ワークロードにも取り組んでいることが分かります。
ただし、調達担当者や学習基盤チームが最終的に知りたい次の疑問には答えていません。
- フルモデルでのエンドツーエンドのtokens-per-secondはどれくらいか
- 目標バッチサイズにおけるトークン単価はいくらか
- 長時間の実行や再起動に対して、どの程度安定しているか
- どのオペレーターが、最適化の進んでいない経路にフォールバックするのか
- インターコネクト、メモリ、消費電力は、想定するNVIDIAクラスタと比べてどうか
- 元のテスト環境以外でも同じ結果を再現できるか
DeepSeekは、セットアップ手順と一部の性能表を含む、本格的なAscend向けカーネルを公開しました。このリリースによって、すでにAscendエコシステムを利用しているチームはソフトウェア面で取り組みやすくなります。一方で、ハードウェアとバージョンの壁は残っています。
FAQ
DeepSeekのAscendインフラは完全にオープンソースですか？
いいえ。DeepGEMM-Ascendと関連ドキュメントは公開されていますが、すべての依存関係と運用手順を含む、DeepSeekの学習クラスタ一式がワンストップで提供されているわけではありません。
DeepGEMM-AscendをNVIDIA GPUで実行できますか？
できません。対象はAscend 950ハードウェアです。NVIDIAユーザーは、NVIDIA向けのDeepSeekプロジェクトを利用してください。
これで、DeepSeekがAscend上でフロンティアモデルを学習していることが証明されますか？
いいえ。DeepSeekがAscend向けカーネルを公開し、特定のワークロードをベンチマークしたことは分かります。しかし、フロンティアモデルの学習をエンドツーエンドで再現できることが、公開情報によって示されたわけではありません。
対応するAscendのキャパシティをすでに確保しており、CANNとTorchNPUの互換性調整まで自分たちで担えるなら、今すぐ試す価値があります。NVIDIAハードウェアしかない場合は、このリリースを実行可能なバックエンドではなく、技術的なリファレンスとして捉えるのが適切です。