ファーウェイ、年次イベント「Connect」でオープンソースAIロードマップを発表

オープンソースAI開発はHuawei Connect 2025の主要テーマとなり、同社は年末までにAIソフトウェアスタック全体を公開する具体的なスケジュールと技術的詳細を明らかにした。

今回の発表は開発者にとって特に意義深く、過去の困難を率直に認めつつ、どのコンポーネントを公開するかについての明確な約束、そしてソフトウェアが既存の開発ワークフローやOSとどのように統合されるかについての詳細が示された。

開発者との摩擦を認める

基調講演で、ファーウェイの徐直副会長兼輪番会長は、開発者がAscendインフラで経験した課題について異例の率直な発言で切り出した。今年初めにリリースされたDeepSeek-R1の影響に触れ、徐氏は「1月から4月30日まで、当社のAI研究開発チームはAscend 910Bおよび910Cチップの推論能力が進化する顧客ニーズを満たすよう集中的に取り組んだ」と述べた。

顧客フィードバックセッションを経て、徐氏は「お客様からはAscendに関する数多くの懸念や期待が寄せられ、常に貴重なご提案を頂戴している」と付け加えた。

こうした開発者課題への認識が、2025年8月5日のAscendコンピューティング産業発展サミットで初発表された包括的なオープンソース化方針の土台となり、後にXu氏がHuawei Connectで再表明した。

Ascendのツール、ドキュメント、エコシステムの成熟度に関する課題に直面してきた開発者にとって、この率直な評価は、プラットフォームの技術的潜在能力と実用的な使いやすさの間のギャップをHuaweiが認識していることを示している。オープンソース戦略は、コミュニティの貢献、透明性、外部からの強化を可能にすることで、これらの摩擦点を直接解決することを目的としているようだ。

CANN：コンパイラと仮想命令セットの詳細

技術的に最も重要な公約は、AIフレームワークとAscendハードウェアを橋渡しするファーウェイの中核ツールキットであるCANN（Compute Architecture for Neural Networks）に関するものだ。8月のサミットで徐氏は「CANNについては、コンパイラと仮想命令セットのインターフェースを公開し、残りのソフトウェアは完全にオープンソース化する」と明言した。

この段階的アプローチでは、完全なオープンソース化を受けるコンポーネントと、Huaweiがオープンインターフェースを提供する（独自実装の可能性あり）コンポーネントが区別される。高レベルコードをハードウェア実行可能命令に変換する重要な変換層であるコンパイラと仮想命令セットにはオープンインターフェースが提供される。これにより開発者は、コンパイラの中核実装が部分的に非公開のままでも、自身のコードがAscendプロセッサ向けにどのようにコンパイルされるかを把握でき、最適化の可能性が開かれる。

この区別は性能チューニングにおいて極めて重要だ。開発者は、レイテンシに敏感なアプリケーションを構築する際や、ハードウェア効率の最大化を目指す際に、コンパイルプロセスを可視化する必要がある。オープンインターフェースはその透明性を提供する。完全なオープンソース化はさらに、コンパイラ自体の修正や置換を可能にする。ファーウェイのアプローチは、特定の独自要素を保持しつつ最適化の可視性を実現する。

タイムラインは明確である：「既存のAscend 910B/910C設計に基づくCANNを、2025年12月31日までにオープンソース化し、オープンアクセスを提供する」。この「既存のAscend 910B/910C設計に基づく」という説明は、リリースが次世代アーキテクチャではなく現行ハードウェアに対応することを示している。

Mindシリーズ：アプリケーション実現キットとツールチェーン

基盤となるCANNレイヤーに加え、ファーウェイは開発者が日常使用するツールのオープンソース化を約束した。徐氏はHuawei Connectで「Mindシリーズのアプリケーション実現キットとツールチェーンについては、2025年12月31日までに完全オープンソース化する」と表明し、2025年8月5日のAscendコンピューティング産業発展サミットでの公約を再確認した。

Mindシリーズは実用的な開発環境——AIアプリケーション構築に用いられるSDK、ライブラリ、デバッグツール、プロファイラー、ユーティリティ——を包括する。一部コンポーネントにオープンインターフェースを設けるCANNの段階的アプローチとは異なり、Mindシリーズは包括的な完全オープンソース化を約束されている。

これによりアプリケーション層のツールチェーン全体が、コミュニティによる検証・修正・拡張が可能となる。デバッグツールは必要な機能で強化され、ライブラリは特定ユースケース向けに最適化され、ユーティリティはよりユーザーフレンドリーなインターフェースで提供される。要するに開発エコシステムはベンダー更新に依存せず、コミュニティ貢献によって進化し得る。

ただし、発表ではMindシリーズを構成する具体的なツール群、サポート対象のプログラミング言語、付属ドキュメントの網羅性については明記されていません。プラットフォームへの時間投資を検討する開発者は、12月のリリース後にツールチェーンの完成度を評価する必要があります。

OpenPangu基盤モデル

ファーウェイは「openPangu基盤モデルを完全にオープンソース化する」とも表明した。これにより同社は、MetaのLlamaシリーズやMistral AIの製品群など、コミュニティ参加を重視するオープンソース基盤モデル分野の他の取り組みと同列に位置づけられる。

発表ではopenPanguの性能、パラメータ数、訓練データ、ライセンス条件に関する具体的な情報は提供されなかった。基盤モデルのオープンソース化は、単なる利用可能性を超えた疑問を提起する。特に商用利用制限、訓練データセットの構成、潜在的なバイアス、微調整と再配布の許容性などが挙げられる。これらの詳細は、少なくとも公的には未解決のままである。

開発者にとって、オープンソース基盤モデルは、ゼロからトレーニングに必要な膨大な計算リソースを必要とせずに、ドメイン固有のアプリケーションの出発点を提供する。しかし、モデルの実用的な有用性は、その品質、ライセンスの柔軟性、利用可能なドキュメントによって決定される。12月のリリースにより、openPanguモデルが既存のオープンソース選択肢に対する競争力のある代替案となるかどうかが明らかになるだろう。

OS統合の柔軟性

Huawei Connect 2025で明らかになった実用的な実装詳細は、新たなAIインフラ導入における共通の障壁であるOS互換性に対処するものである。Huaweiは「UB OSコンポーネント全体をオープンソース化し、そのコードをopenEulerのような上流オープンソースOSコミュニティに統合できるようにした」と発表した。

この統合アプローチは顕著な柔軟性を提供する。発表によれば「ユーザーはUB OSコンポーネントのソースコードの一部または全部を既存OSに統合し、独立した反復開発とバージョン管理をサポートできる。またコンポーネント全体を既存OSにプラグインとして組み込み、オープンソースコミュニティと歩調を合わせて進化させることも可能だ」

このモジュール設計により、UbuntuやRed Hat Enterprise Linuxなどのディストリビューションを運用する組織は、ファーウェイ固有のOSへの移行を強制されない。OSレベルでSuperPod相互接続管理を担うUB OSコンポーネントは、既存環境に統合可能だ。開発者やシステム管理者にとって、これは導入時の摩擦を大幅に低減する。

ただし、柔軟性には責任が伴う。UB OSコンポーネントのソースコードを自社システムに統合する組織は、テスト、保守、更新の責任を負うことになる。ファーウェイは、任意のLinuxディストリビューション向けのベンダーサポート製品ではなく、オープンソースソフトウェアとしてこのコンポーネントを提供している。このアプローチはLinuxに関する深い専門知識を持つ組織には有効だが、ベンダーによるターンキーサポートを期待する組織にとっては困難を伴う可能性がある。

フレームワーク互換性戦略

開発者による採用において最も重要な要素は、既存のAIフレームワークとの互換性である。開発者に慣れ親しんだツールを放棄させるのではなく、ファーウェイは統合レイヤーを構築している。同社によれば、「PyTorchやvLLMといったオープンソースコミュニティのサポートを優先し、開発者の自律的なイノベーションを支援している」という。

PyTorchとの互換性は特に重要だ。同フレームワークがAI研究と実運用双方で支配的地位を占めるためである。開発者が大規模な修正なしに標準PyTorchコードをAscendハードウェア上で効率的に実行できれば、実験の障壁は大幅に低下する。組織はコードベースを最小限の調整で既存の状態で評価でき、全面的な書き換えを必要としない。

vLLM統合は特定の需要が高いユースケース、すなわち最適化された大規模言語モデル推論を対象としている。組織がLLMベースのアプリケーションを展開するにつれ、推論性能とコストが重要な要素となる。ネイティブvLLMサポートは、華為が研究能力だけでなく実用的な展開上の懸念に対処していることを示唆している。

ただし、発表内容ではこれらの統合の完成度については詳述されていません。特定の操作で回避策が必要だったり、最適とは言えないパフォーマンスしか提供しない部分的なPyTorch互換性は、有益というよりむしろ苛立たしい結果をもたらす可能性があります。フレームワーク統合の品質こそが、導入障壁を真に低減するのか、それとも新たな互換性問題のカテゴリーを生み出すだけなのかを最終的に決定づけるでしょう。

12月31日の期限とその後

CANN、Mindシリーズ、openPanguモデルのオープンソース化期限である2025年12月31日まで、約3ヶ月を切った。この短期的なタイムラインは、既に相当な準備作業が完了していることを示唆している：コードから内部依存関係が除去され、ドキュメントが作成され、ライセンス条項が最終調整され、リポジトリ基盤が整備されている。

初期リリースの品質がコミュニティの反応を大きく左右する。不完全なドキュメント、限られたサンプル、欠落した機能、未成熟なツール群で公開されるオープンソースプロジェクトは、技術的価値が優れていても貢献者を惹きつけられないことが多い。未知のプラットフォームを評価する開発者には、包括的な学習リソース、動作するサンプル、成功への明確な道筋が必要だ。

リリース後の数週間から数ヶ月が極めて重要となる。成功するオープンソースプロジェクトには、積極的なメンテナンス、迅速なガバナンス、そして歓迎的なコミュニティが不可欠だ。長期的な軌道は、開発者が十分な価値を見出して貢献を返し、改善の好循環を生み出すか、あるいはプラットフォームが主にベンダー主導のまま留まるかによって決まる。

今後の展望

ファーウェイのオープンソース動向を注視する開発者や組織にとって、12月のリリースは終着点ではなく出発点に過ぎない。真の試練は、コミュニティの手でソフトウェアがどう進化するか、統合の質の高さ、そして競争の激しいエコシステムの中でプラットフォームが持続可能な地位を確立できるかにある。その答えは今後数ヶ月で明らかになるだろう。