DeepSeek、兆パラメータモデルを動かすエンジニアリング経験をオープンソース化：今回の国産計算力が補うのはソフトウェア層

9月30日、DeepSeekは公式WeChatアカウントで一連のコードを公開し、Huawei Ascendプラットフォーム向けに6つのモジュールをオープンソース化した。TileLang、DeepGEMM-Ascend、DeepEP-Ascend、TileKernels、FlashMLA、DeepSelectだ。名前だけ聞くと断片的だが、実際にカバーする範囲はよくまとまっている。1つのプログラミング言語、一群の計算カーネル、さらに分散通信である。

これは通常のオープンソースとは少し違う。公開されたのはモデルではなく、モデルを動かすために必要な土台の層だ。

チップが十分になった後、詰まるのは別のものだ

国産計算力をめぐってこの数年で最も議論されてきたのは、計算性能の数値だ。スペック表は年々見栄えがよくなっているが、実際にモデルの移行を手がけたエンジニアは知っている。トラブルのほとんどはピーク計算性能では起きない。

NVIDIAのCUDAエコシステムは20年以上かけて築かれてきた。コンパイラ、数学ライブラリ、通信ライブラリが何層にも積み重なり、開発者はカードを入手すればすぐ使える。ドキュメント、コミュニティ、落とし穴の記録もすでに揃っている。別のハードウェアに移ると、同じ演算子を自分で書かなければならず、スケジューリングも自分で調整し、マルチノード・マルチカード通信のライブラリも自分で実装しなければならない。チップのベンチマークスコアは低くないのに、モデルを載せること自体のコストが法外に高い。

この差には、あまり言及されない層がもう一つある。ハードウェアは一度投資すれば買えるが、ソフトウェアエコシステムは人が年単位で磨き上げるしかない。カードを買うのは調達の問題だが、ツールチェーンを整えるのは時間の問題であり、しかもその時間は実際のプロジェクトでしか交換できない。あるプラットフォーム上で最初にモデルを動かし、安定させ、規模まで到達させた者だけが、再利用可能な経験を蓄積できる。だから今回のオープンソースは個別に取り上げる価値がある。買ったものではなく、誰かが蓄積してきたものを差し出したからだ。

つまり、国産計算力の長期的な本当の弱点はソフトウェアにある。チップは計算できるが、使いにくい。DeepSeekが今回オープンソース化したものは、まさにこの空白を埋める。

6つのモジュールで最も注目すべきはTileLang

6つのモジュールの中で最も重みがあるのはTileLangだ。これはDeepSeekが独自開発した高水準プログラミング言語で、これまでは主にNVIDIAバックエンド向けだったが、今回Ascend 950を正式にサポートし、ネイティブコード生成、自動スケジューリング、同期を提供する。DeepSeekによる位置づけは非常に直接的だ。CUDAの代替案であり、しかも「プログラミングモデルはよりシンプル」である。

それに付随するTileKernelsは別の古い問題を解決する。NVIDIAまたはHuaweiのバックエンドを自動選択し、上位層には同じPython APIを公開する。言い換えれば、同じコードを2つのハードウェアプラットフォームで動かす際、切り替えコストはカーネルを書き直すことではなく、設定レベルまで抑えられる。

公開された内部テストのデータも曖昧ではない。一部のカーネルはAscend 950DT上で公称ハードウェア上限の高い割合に達した。BF16稠密行列積は99.8%、FP8は約99.5%。DeepSeek V4.1向けのスパースアテンション実装は、prefill段階で410 TFLOPSに達し、理論値の約95%となる。両社はさらに、128基のAscend 950によるスーパーノードソリューションを共同最適化し、計算とデータ移動の間のバランスを専門に取っている。

これらの数字の価値は、この道が実現可能だと証明している点にある。以前は国産計算力について、使えるかどうかが話題だった。今では自分たちがハードウェアを限界まで使い倒した経験を公開しようとするチームが現れ始めており、少なくとも共有できる水準まで使い込んだ人がいることを示している。

1つのAPIで2社のバックエンドを同時に扱う価値はどこにあるのか

TileLangとTileKernelsを一緒に見ると、用途がより明確になる。TileKernelsはNVIDIAまたはHuaweiのバックエンドを自動選択し、上位層には同じPython APIを公開する。つまりチームが保守するのは2つではなく1つのコードになる。

現実には、少しきちんとした推論サービスは通常、複数のハードウェア上で同時に動く必要がある。クラウドはまだNVIDIAかもしれないが、自社構築や信創（国産化）の場面では国産カード、エッジデバイスではまた別のものになる。ハードウェアを変えるたびにカーネルを書き直す必要があるなら、チームは並行する複数の実装を維持し、テストもそれぞれ行わなければならない。同じAPI一式によって、これは「書き直し」から「設定変更」に格下げされ、省けるのは人的リソースだけではなく、ミスが起きる機会でもある。

ただ製品を形にしたいだけのチームにとって、こうした変更はどのリリースノートにも書かれない。しかし、彼らが国産ハードウェアを試そうと思うかどうかを左右する。

本当の変化は移行コストで起きる

一般の開発者にとって、今回のオープンソースで最も現実的な影響は移行コストだ。

これまで訓練や推論をAscendへ移行するには、低レイヤの演算子を自分で補い、ツールも自分で適合させる必要があり、1つのプロジェクトが数か月をそれに費やすことも珍しくなかった。今ではこうしたツールチェーンが直接オープンソース化され、多くの落とし穴はすでに誰かが踏んで直しており、そのまま再利用できる。敷居は「演算子適合を専門に担当するチームが必要」から「チーム内にこのツール群を理解できる人がいればよい」へと下がった。

これも、今回のリリースが開発者コミュニティでそれなりの反響を呼んだ理由を説明する。このところモデルはもう十分すぎるほど出ている。本当に希少なのは、少しでも遠回りを減らすことだ。

次に見るべきは、他人が使うかどうかだ

今回のオープンソースの重みを判断するには、DeepSeek自身が何を言ったかだけでは足りない。今後半年で他者が何をするかを見る必要がある。

ツールチェーンが定着するかどうかは、第三者にそれへ投資する意思があるかどうかにかかっている。TileLangがDeepSeek自社のモデルにしか役立たないなら、その意味はこの会社の内部で止まる。別のチームがそれを使って演算子を書き、issueを提出し、対応ハードウェアバックエンドを外へ広げるなら、初めて公共インフラになり始める。数値がどんなに美しくても、数か月の実負荷による検証を経て初めて意味を持つ。

もう1つの変数は、他の国産チップも追随して接続してくるかどうかだ。現在公開されている情報はAscendに集中している。この高水準言語が同じ論理でより多くのプラットフォームへ移行できれば、その価値はさらに一段上がる。この点については今まだ答えがない。

土台をオープンソース化するのは、モデルをオープンソース化するより遅い

過去2年、国産オープンソースの主戦場はずっとモデルの重みだった。パラメータ、ランキング、ダウンロード数は、どれもすぐに見えるものだ。低レイヤのツールチェーンは違う。ランキングには現れず、短期的には話題も生まない。しかしこの層がなければ、上にいくらモデルを積んでも不安定なままだ。

DeepSeekがAscend上で兆パラメータ級モデルを動かしたエンジニアリング経験を差し出したのは、まさにこうした目立たないが、業界が先へ進めるかどうかを決める埋め合わせである。

今すぐ手元のNVIDIAプロジェクトをAscendへ移すべきかどうかは、依然として具体的な状況次第であり、チーム内に低レイヤに時間を割く人がいるかにもよる。しかし少なくともこの日から、「エコシステムが使いにくい」という理由は、以前ほど説得力を保てなくなった。そしてエコシステムが一度使えるようになれば、その後に起きることは往々にして予想より速い。