Huawei「openPangu-2.0-Pro」公開で何が再現可能になったのか

HuaweiによるopenPangu-2.0-Proの公開は、単なる「モデル重みの配布」以上の意味を持つ。一方で、これを直ちに「非NVIDIA環境で完全再現可能な学習から推論までの一式」と呼ぶのは早い。

公開によって、HuaweiのAscend（昇騰）プラットフォームを主眼に置いた大規模モデルを検証し、推論環境へ載せる道筋は大きく開かれた。しかし、元の大規模学習を第三者が同条件で再構築できるかは、別の問いである。

まず押さえたい仕様：505Bの全てが毎トークン動くわけではない

openPangu-2.0-Proは、総パラメータ数が約505B（5050億）のMixture-of-Experts（MoE）モデルだ。ただし、各トークンの処理で活性化されるパラメータは約18B（180億）とされる。対応コンテキスト長は512Kトークン、学習データ量は約34Tトークンである。 21

ここで重要なのは、505Bと18Bを混同しないことだ。MoEは、入力トークンごとに専門家（expert）の一部を選んで計算する仕組みである。総容量は非常に大きいまま、1トークン当たりの演算量を、同規模の密なモデルより抑える狙いがある。

もっとも、これは「軽量」を意味しない。505B規模の重みを保管・配信し、分散して提供するには、なお大きな計算資源とメモリ、通信基盤が必要となる。

現時点で公開されたもの

Huaweiは2026年7月31日、openPangu-2.0-Proのモデル重み、基本推論コード、技術報告書を公開した。関連するopenPangu 2.0のコンポーネントも、オープンソースのチャネルで順次公開するとしている。 12

それぞれの成果物が可能にすることは異なる。

• モデル重み：学習済みモデルの評価、推論、提供
• 基本推論コード：想定されるAscend環境で動かすための実装経路の確認
• 技術報告書・モデル文書：アーキテクチャや設計上の選択の把握

HDC 2026で示されたロードマップでは、事前学習コード、事後学習コード、学習演算子を含む7つのコンポーネントを段階的に公開する計画も掲げられた。 210

これらが実用可能な形でそろえば、重みだけを公開するケースよりも、学習から推論までを見通せるスタックに近づく。ただし「計画されている」ことと、「外部の研究・開発チームが同じ訓練を実行できる」ことは同義ではない。

「オープンウェイト」と「完全再現可能」は違う

ダウンロードできる重みがあれば、公開チェックポイントを試験・評価することはできる。しかし、それだけで同じモデルをゼロから生成した条件まで分かるわけではない。

34Tトークン規模の事前学習を再現するには、少なくとも次のような情報・資源が必要になる。

• 正確な学習データ、または再現可能なデータ生成仕様
• 完全な事前学習・事後学習の実装とハイパーパラメータ
• 分散学習設定、クラスタ構成、通信トポロジー
• ソフトウェア、コンパイラ、ランタイムのバージョン
• カスタム演算子と評価手順
• 十分な数の互換ハードウェア

公開済みと確認できるのは重み、基本推論コード、技術報告書であり、その他のコンポーネントは順次公開の位置付けである。 1221

したがって現段階で最も正確な表現は、**「Ascendファーストのオープンモデルであり、スタックの透明性を広げるための明示的な公開ロードマップを持つ」**となる。第三者が元の学習実行を独立して再現できる証明ではない。

512Kコンテキストを支える設計

長い入力を扱うほど、注意機構の計算量、メモリ消費、メモリアクセスが課題になる。openPangu-2.0-Proは、長文脈での推論負荷を抑えることを狙った複数の設計を採用している。

DSAとSWA：近傍情報と遠距離情報を分担

モデルはMLAを維持しつつ、DSAとスライディングウィンドウ注意（SWA）を1:2の層比で組み合わせる。Huaweiの説明では、SWA層が局所的な文脈を扱い、DSA層が疎なグローバル文脈を集約する。長文脈推論における計算、メモリ、メモリアクセスのコストを下げながら精度を保つことが目的だ。 21

全トークン同士を常に密に参照するよりも、近い文脈を低コストで処理し、離れた情報には疎な経路でアクセスする考え方である。

4ストリームmHC、3ヘッドMTP、Muon

Huaweiは、表現の多様性と汎化性能の向上を意図して、4ストリームのmHC残差トポロジーを採用したとしている。また、3ヘッドのマルチトークン予測（MTP）モジュールは追加の将来トークンを予測し、推論高速化を狙う。学習の最適化には、収束速度の向上を目的としてMuonオプティマイザを用いたという。 21

ただし、これらはHuaweiが公開資料で示した設計意図である。実際のスループットやレイテンシは、アクセラレータ構成、精度、バッチサイズ、コンテキスト長、トラフィック特性、サービングソフトウェアに大きく左右される。特定条件の性能値を、あらゆる環境の性能として読むべきではない。

長文脈エージェントで期待される用途と、残るガードレール

512Kのコンテキスト長があれば、規程、手順書、運転ログ、保守履歴、過去のツール出力、仕様書など、より多くの資料を1セッションに含められる可能性がある。細かな分割処理への依存を減らせる場面はある。

ただし、検索、データのアクセス権、出典確認、監査、人間の承認を不要にするわけではない。活用を検討しやすい領域は、例えば次の通りだ。

• 行政・公共分野：法令、案件資料、意見募集、組織横断の文書の補助分析。アクセス制御と意思決定の監査性が必須となる。
• 金融：調査資料、開示書類、契約書、コンプライアンス文書の横断確認。ただし、未検証の生成結果を売買、与信、規制判断に直接使うべきではない。
• 製造・エネルギー：設備マニュアル、アラーム履歴、保全記録、工程文書、引き継ぎ記録を統合し、調査や保全計画を支援する。
• 医療：文献や長期記録の要約支援。診断・治療の自律的な代替ではなく、臨床ガバナンスの下で扱う必要がある。
• 自動運転の開発：試験ログ、シナリオ、安全ケース、設計文書のオフライン分析。検証済みのリアルタイム運転システムの代替ではない。

小規模な組織にとって、Proを自前で運用するハードルは、疎な活性化を採っていても高い。Huaweiは、総パラメータ92B、トークン当たりの活性化パラメータ6BのopenPangu-2.0-Flashも公開しており、評価・導入ではこちらが現実的な候補となる場合がある。 1520

ソフトウェア開発支援は「自律保守」ではない

Huaweiが報告するopenPangu-2.0-ProのThinking版のSWE-bench Verifiedスコアは68.5である。 24

これは注目に値するベンチマーク結果だが、複雑な本番ソフトウェアをモデルが一貫して単独で保守できる証拠ではない。実際のリポジトリでは、環境構築、依存関係、テスト実行、セキュリティレビュー、設計判断、変化する要件、多段階のデバッグが絡む。

現実的な導入パターンは、リポジトリ単位で権限を絞り、サンドボックス、テスト自動化、静的解析、コードレビュー、ロールバックを備えた人間監督下のコーディングエージェントである。自律的なマージを前提にすべきではない。

狙いはモデル公開だけでなく、Ascend＋Panguの開発循環

戦略上の価値は、モデル重みそのものだけにない。Ascendネイティブの参照モデルがあれば、開発者はAscend向けにワークロードを構築・検証・最適化しやすくなる。利用が増えれば、ランタイム、演算子、ツール、マネージドサービスの改善需要も生まれ、次の開発者の導入障壁を下げる循環が期待できる。

Huaweiは開発者、企業パートナー、研究者に対し、Ascend TribeコミュニティおよびHuawei CloudのMaaS（Model as a Service）でダウンロード・利用・フィードバックを呼びかけている。 12

FlashとProを異なる規模で出し、さらに学習・事後学習・演算子の層を公開対象に据えることは、単にチェックポイントを配る施策ではない。AscendとPanguを中心とした開発エコシステムを厚くする取り組みと見るのが妥当だ。 1015

オープン性はすでに、導入、検証、実験の面で意味を持つ。完全な再現性を評価するのは、残るコード、設定、データ関連の仕様がどこまで公開され、独立した組織が実際に何を再構築できるかが検証されてからである。