DeepSeekは2026年9月30日、HuaweiのAIチップ「Ascend」向けに、演算プログラムを開発するための言語基盤や、計算・通信ライブラリを公開した。

これまでNVIDIA製GPU向けに蓄積してきたソフトウェア群にAscend対応を加え、開発者が利用するAPIや開発手順をできるだけ共通化する取り組みだ。Huaweiも開発を支援しており、単体の行列演算ではAscendの理論性能に近い測定結果も示された。

ただし、APIが共通でも、対応する機能やデータの配置方法まで同じになるわけではない。複数チップ間の通信性能についても、一般提供前の開発環境で測定された結果が含まれる。

今回の公開によって、NVIDIA中心の開発環境からAscendへ移行する際に何が共通化され、どの部分にハードウェア固有の最適化が残るのかを見ていく。

AD

6つのソフトウェアで、カーネル開発からチップ間通信まで対応

TileLang本体には、Ascend 950向けの正式なバックエンドが追加された。バックエンドとは、TileLangで記述したコードを対象チップで実行できる形へ変換する仕組みだ。

公式の更新履歴では、2025年9月29日に公開された外部のAscendアダプタと、今回TileLang本体へ統合された対応を区別している。

つまり、Ascendへの対応そのものが今回初めて登場したわけではない。対応するチップ世代と、TileLang内での位置づけが変わった。

TileLangは、Pythonに近い記法で「カーネル」を開発するための専用言語だ。ここでいうカーネルとは、行列積や注意機構など、AIチップ上で実行される個々の演算プログラムを指す。

今回公開・更新された主なソフトウェアを役割ごとに整理すると次のようになる。

構成要素 担当する処理 Ascend向け公開・更新の内容
TileLang カーネルの記述とコンパイル Ascend 950向けコード生成、処理順序や同期の調整
DeepGEMM-Ascend AI計算の中心となる行列積 BF16・FP8・FP4演算、MoE向け処理
DeepEP-Ascend 複数チップ間の通信 エキスパートへのデータ分配と結果の集約
TileKernels 周辺の演算やデータ処理 量子化やMoEの振り分けなど数十種類のカーネル
FlashMLA 注意機構 必要なトークンだけを参照する疎な注意機構
DeepSelect 候補の選択 スコア上位を選ぶTopK処理

これらは、AIモデルを実際に動かす際に必要となる一連の処理に対応する。

MoE（Mixture of Experts、混合エキスパート）では、各トークンについて処理を担当する一部のエキスパートを選び、そのエキスパートが配置された別のチップへデータを送る。

そこで行列演算を実行し、処理結果を元の場所へ送り返して集約する。

そのため、行列演算だけを高速化しても、チップ間のデータ転送や集約で待ち時間が発生すれば、チップの性能を十分に引き出せない。DeepGEMMによる演算高速化と、DeepEPによる通信高速化の両方が必要になる。

CUDAからの移行で減る手作業、それでも機種ごとの最適化は残る

DeepGEMM-Ascendは、既存のDeepGEMMとAPIを完全互換にし、同じパッケージ名や開発手順を利用できると説明している。

TileKernelsも同じPython APIを使い、実行環境に応じて適切なバックエンドを選択する。

DeepEP-Ascendでは、公開されているバッファAPIをNVIDIA版に合わせ、学習と推論で共通のインターフェースを利用できるよう設計した。

つまり、モデル側からライブラリを呼び出す部分を大きく書き換えずに済むようにすることが、今回の共通化の大きな狙いだ。

一方、その内部ではハードウェアの違いを吸収するための処理が必要になる。

Ascend 950向けTileLangガイドによると、行列演算はCubeコア、周辺のベクトル演算はVectorコアが担当する。

開発者が演算やデータ転送の処理を記述すると、コンパイラが各コアへの処理の割り当てや依存関係を解析し、実行順序や同期を調整する。

Ascend Cを直接使う場合に開発者が細かく指定する必要があるバッファ管理や同期処理の一部を、TileLang側が担う仕組みだ。

ただし、処理するデータ型や演算を分割する単位などは開発者が指定する必要がある。

DeepGEMMの低精度演算で使われる補正係数についても、AscendではNVIDIA製GPUとは異なる形式でメモリに配置する。

APIを共通化できても、ハードウェア内部のデータ表現まで統一されるわけではない。

DeepJITは、必要なカーネルを実行時にコンパイルし、生成したバイナリを保存して再利用する手順を両プラットフォームで共通化する。

ただし、カーネルのソースコードやコンパイラに渡す設定には、依然としてハードウェアごとの差が残る。

つまり、これらはCUDAコードをそのままAscend向けへ自動変換する仕組みではない。

上位のAPIや開発手順をできるだけ共通化しながら、その下にNVIDIA向け、Ascend向けの個別実装を用意する考え方だ。

その具体例は、DeepSeekが公開したFlashMLAの技術報告にも見られる。

疎な注意機構を処理するカーネルでは、1つのCubeコアと2つのVectorコアを組み合わせ、行列演算、データ転送、低精度データを演算可能な形式へ変換する処理を分担させている。

さらに、推論時に保持するKVキャッシュと補正係数をメモリ上で隣接して配置し、それぞれを別々にコピーする処理を減らした。

別のAIチップへ移植する際に必要なのは、同じ計算を異なる命令で書き直すことだけではない。チップの構造に合わせて、内部でデータをどう配置し、どう移動させるかまで設計し直す必要がある。

AD

99.8%は「行列演算単体」で理論性能に迫った数字

DeepGEMM-Ascendが公表したベンチマークでは、BF16による密な行列積で431 TFLOPSを記録した。

公表されているハードウェア上限432 TFLOPSに対し、99.8%に相当する。

測定にはAscend 950DTとCANN 9.20を使用し、L2キャッシュに対象データが残っていない状態で試験している。

行列サイズはM＝4096、N＝7168、K＝16384。同じサイズでFP8同士を演算した場合は861 TFLOPSとなり、上限865 TFLOPSに対して99.5%だった。

AIチップは理論上の演算性能が高くても、演算器へ十分な速度でデータを供給できなければ待ち時間が生じる。

今回の結果は、少なくとも測定された行列サイズとデータ精度では、Ascend向けに最適化した実装によって演算器をほぼ上限に近い状態で稼働させられたことを示している。

共通APIを維持しながら、内部ではハードウェアに合わせた最適化を行うという今回の設計が、特定の行列演算では高い性能につながったとみることができる。

ただし、99.8%という数字は、AIモデルの学習全体や推論サービス全体でチップ性能の99.8%を引き出せるという意味ではない。

実際のモデルでは行列積だけでなく、注意機構、チップ間通信、データ量の小さい演算など、さまざまな処理が組み合わされる。

この数字だけからNVIDIA製GPUとの総合的な性能差を判断したり、1回の推論に必要なコストを比較したりすることはできない。

単体の演算カーネルがどこまで理論性能に近づいたかと、モデル全体を動かしたときにどれだけの速度が得られるかは分けて評価する必要がある。

128並列まで増やすと見えてくる通信性能の課題

DeepEP-Ascendは、エキスパート並列の規模を8から128まで変えた場合の通信性能も公開している。

分散処理に参加する各プロセスを「ランク」と呼び、公表表では各ランクで測定された帯域の範囲を示している。

測定にはAscend 950DTとCANN 9.2.0を使い、複数の計算ノードを接続するClosネットワーク環境で計測した。

エキスパート並列の参加数 分配の帯域（GB/s） 集約の帯域（GB/s）
EP8 373〜375 345〜347
EP128 313〜320 272〜278

出典はDeepEP-AscendのPerformance表。

各ランクのトークン容量は16,384、隠れ層の次元は7168で、256のエキスパートから6つを選んで処理する設定だ。

データの分配にはFP8、結果の集約にはBF16を使う。

測定時間には通信開始から完了待ちまでを含む一方、最後の後処理は含まれていない。また、測定環境では手動で追加設定した試験用HDKが使用されている。

DeepSeekが公表した範囲の中央値を使って単純計算すると、EP8からEP128へ規模を拡大した際、ランク当たりの帯域は分配で約15.4%、集約で約20.5%低下する。

分配を374 GB/sから316.5 GB/s、集約を346 GB/sから275 GB/sとして、「（EP8 − EP128）÷ EP8 × 100」で計算した。

ただし、これは公表された帯域幅の中央値から編集部が算出したもので、平均実測値ではない。

また、参加するランク数を増やした場合のシステム全体の総通信量や、モデル全体の処理速度が同じ割合で低下することを意味する数字でもない。

DeepSeekによると、EP32以下の分配処理では、物理ネットワークが実際に利用できる帯域の約90〜95%まで到達する。

一方、大規模な並列構成や集約処理については引き続き最適化を進めている。

集約では、各チップから届いた結果を加算する処理が必要になるほか、高帯域メモリの帯域をAI演算と通信処理の双方で使うため、競合も発生する。

行列演算がハードウェアの上限近くまで高速化されれば、その次にはチップ間でデータを送る速度だけでなく、受信したデータをどれだけ効率よく集約できるかが性能を左右する。

AD

公開コードを実用環境で使うには、まだ条件が残る

DeepEP-Ascendが公表した通信性能は、DeepSeek向けに提供された試験用PoC HDKを手動で追加設定した環境で測定されたものだ。

HDKは、ドライバやファームウェアなどを含む、ハードウェア開発に必要なソフトウェア環境を指す。

この設定は現時点で一般には配布されていない。

DeepEP-Ascendの説明では、必要な設定を含むAtlas 850E向け商用HDKは、2026年10月中旬、15日前後に公開される予定だ。

これはHuawei側の提供予定として記載されたもので、今回のベンチマークは一般提供済みの商用環境で再現された結果ではない。

機能面でも、CUDA版とAscend版には違いが残る。

FlashMLAのAscend版は、疎な注意機構について入力処理と逐次生成に対応する一方、複数の処理をまとめて実行する一部の融合カーネルや、密な注意機構向けの一部カーネルはCUDA版のみが対応している。

DeepSelectのAscend版も入力形式はBF16に限られ、CUDA版が対応するFP32のサンプリング処理まで同じように利用できるわけではない。

また、FlashMLAの今回のバージョンではHopperや一部の旧モデルへの対応が外され、KVキャッシュの形式も変更されている。そのため既存環境へ導入する場合は、利用するバージョンや互換性を確認する必要がある。

分散学習に必要な通信機能も、まだすべて完成しているわけではない。

DeepEP-Ascendでは、すべてのランクの値を合計する「all-reduce」や、集約結果を複数のランクへ分散して配置する「reduce-scatter」のカーネルを現在実装中としている。

エキスパート間の負荷を均等化するための通信についても、未実装の部分が残っている。

したがって、学習向けAPIが公開されたことと、大規模AIモデルの学習をAscendだけで最初から最後まで完了できることは分けて考える必要がある。

それでも、モデル開発者自身が必要とする演算・通信処理をオープンな形で公開すれば、他の開発者もハードウェア向けの実装を調べ、別のモデルやサービスへ再利用できる。

DeepSeekとHuaweiの協力は、DeepSeekのモデルをAscend上で高速に動かすための個別最適化を、より広いAI開発基盤へ発展させる可能性がある。

今後、一般提供される商用HDKでも同様の性能を再現できるか、未対応の通信・演算機能がどこまで実装されるかが重要になる。

さらに実際のモデルやサービスを使った測定で、推論の遅延や処理量、学習性能まで確認できれば、開発者はNVIDIA製GPUとAscendを比較する際に、単純な演算性能だけでなく、移植に必要な手間と実運用時の性能を合わせて判断しやすくなる。