アリババ、SIGCOMM 2026 に12 篇論文が採択される
本文の状態
日本語全文を表示中
詳細モードで約36分の本文を読めます。
同じ出来事の情報源
この情報源を基点に整理
Alibaba Engineering
阿里巴巴集团在计算机网络顶级会议 SIGCOMM 2026 に12 篇論文を採択され、AI 智算ネットワークや非確定性収束検証システム「TianYan」などの技術で産業界のトップに位置づけられた。
AI深層分析を開く2026年8月19日 21:47
AI深層分析
キーポイント
SIGCOMM 2026 での圧倒的な成果
阿里巴巴集团は SIGCOMM 2026 に12 篇論文を採択され、中国の産業界機関として唯一、トップティアの大学・研究所と肩を並べる地位を確立した。
非確定性収束の検証システム「TianYan」
生産級広域网における非確定性収束問題を解決する世界初のシステム「TianYan」を開発し、数年前から運用で約 2% の前缀に潜在的な欠陥を発見して実害を防止している。
AI 活用による設定管理の進化
大規模クラウドネットワークの設定管理において、LLM を支援として活用し、複雑な多機種環境でも柔軟に対応できるモデル駆動型管理システム「AliYANG」を推進している。
形式化手法による運用の高度化
阿里巴巴の技術者が ACM SIGCOMM ワークショップの主席や司会を務め、形式化手法を用いたネットワーク運用の信頼性向上について学界と産業界で議論を主導した。
AliYANG: 設定モデルの統一と LLM 活用
AliYANG は設定セマンティクスをテキストテンプレートから抽出し、標準 YANG を拡張して多様なデバイス能力を記述可能にする。LLM はモデル設計や翻訳コード生成に利用され、確定的な検証ループで品質を保証する。
重要な引用
「これは 2026 年の第 53 篇文章」
「中国産業界機関として唯一、トップティアの大学・研究所と肩を並べる地位を確立した」
「TianYan は生産級広域网における非確定性収束問題を解決する世界初のシステムである」
AliYANG は設定セマンティクスを易碎的なテキストテンプレートから抽出し、統一され実行可能なモデルへと沈殿させるものである。
編集コメントを表示
編集コメント
今回の発表は、学術的な研究成果が実際の大規模インフラ運用で即座に検証され、効果を発揮した好例である。特に非確定性収束という複雑な問題を解決した「TianYan」の事例は、理論と実装のギャップを埋める技術的アプローチとして注目されるべき成果だ。
Source Article
元記事を日本語で読む
本文に関係しない購読案内、埋め込み通知、サイト内プロモーションは除いています。
アリババグループの論文12本が世界屈指のネットワーク学会 SIGCOMM 2026 に採択（ダウンロードリンク付き）
アリババ学術 2026-08-19 18:25 浙江
これは 2026 年第 53 回の記事です。
（本文を読むのに要する時間：約 15 分）
このほど、コンピュータネットワークと通信の分野における世界最高峰の国際学会「SIGCOMM 2026」が米国デンバーで開催されました。アリババグループからは主会に 12 本の論文が採択され、企業としてトップクラスの地位を築きました。中国の産業界において、一流大学や研究機関と肩を並べて第一梯队を形成しているのはアリババだけです。今回の採択論文は、AI による知能計算ネットワークと集合通信、クラウドゲートウェイデータ面、ネットワーク検証、インテリジェントな運用保守（AIOps）といった技術分野にまたがる研究成果であり、その継続的な突破により国際学術界から再び高い評価を得ました。
SIGCOMM はコンピュータネットワーク分野で最も権威ある国際学会の一つ（CCF A 類）として知られており、毎年 15%〜22% という極めて低い採択率を誇ります。その価値は非常に高いものです。
アリババのシニアテクニカルエキスパート、翟恩南氏は、第 3 回 ACM SIGCOMM フォーマルメソッド支援ネットワーク運用ワークショップ（The 3rd ACM SIGCOMM Workshop on Formal Methods Aided Network Operation、略称：FMANO）の共同議長を務めました。また、アリババのシニアテクニカルエキスパートである袁驿飛氏が本ワークショップを主宰しました。このワークショップには学界のネットワーク研究者とインターネットサービスプロバイダーが集結し、フォーマルメソッド（形式手法）がネットワーク運用にどのように応用されるかについて活発な議論が行われました。その目的は、ネットワークの可用性、信頼性、パフォーマンスの向上にあります。
各論文の詳細解説は以下をご覧ください⬇️
ネットワーク管理と検証
1. 大規模生産環境の広域 WAN における非決定性収束の検証
大規模な生産レベルの広域ネットワーク（WAN）では、設定の正しさを保証するためにシミュレーション検証ツールが不可欠です。しかし、アリババクラウドが開発した「Hoyan」や業界の同種ツールはすべて、「BGP 制御平面が収束すると、データ平面は一意で決定された状態になる」という前提に立っています。
ところが実際には、「非決定性収束」という現象が存在します。これは、同じ設定であっても、収束する順序の違いによって複数の安定したデータ平面が生成されてしまう現象です。このため、検証ツールは「設定は正しい」と報告しますが、実際のネットワークは期待された状態から逸脱してしまっています。その結果、トラフィックのブラックホールなどが発生しても、事後でしか発見されないという深刻な問題が生じます。
数千台ものルーターと数十万本のリンクが存在する WAN においてこの問題を検証しようとすると、指数関数的に増大するスケーラビリティの壁に直面します。既存の方法では対応が不可能でした。
本研究では、生産レベルの WAN 上で非決定性収束を検証できる世界初のシステム「TianYan」を提案します。その核心となる洞察は、「生産ネットワーク内では、同じグループに属するルーターが共有する戦略が似ているため、それらのルーティング動作も予測可能な類似性を示す」という点です。
この洞察に基づき、論文では 2 つの剪枝定理（pruning theorems）を証明しました。これにより、探索対象となるパス空間を「ルーター単位」から「グループ単位」へと圧縮し、分析の正確性を損なうことなく、指数級数の削減を実現しています。
システムは以下の 4 つの段階からなるパイプラインで構成されています。
- まず、改良されたルーティングシミュレーションを用いて、各プレフィックスごとに収束分析のための簡素化モデルを構築します。
- 次に、多項式時間アルゴリズムを用いて全 200 万個のプレフィックスを高速スクリーニングし、約 4 万個の疑わしいプレフィックスを特定します。
- さらに、根本原因に基づいてグループ分けを行うことで、計算コストのかかる制約求解（constraint solving）の回数を数万次から約百回にまで削減します。
- 最後に、非決定性収束を引き起こした根本原因——具体的にはどのルーターやどのような競合する戦略が関与しているか——を自動的に特定します。その後、問題となるループの排除や、シミュレーション結果を実際のネットワーク状態へ整合させることで、検証の精度を回復させます。
TianYan は既に 1 年以上にわたり本番環境で稼働しています。その運用により、約 2% のプレフィックス（約 4 万個）が非決定性収束の問題を抱えていることが判明しました。また、約 100 種類の根本原因を特定し、約 3 万個のプレフィックスに対する検証結果を誤りから正しく修正することに成功しています。
これにより、生産 WAN における非決定性収束の広範な実態とその実際の影響が初めて明らかにされました。これらの知見は、運用チームに対してこれまで認識されていなかった設計上の欠陥や実装ミスを特定する手助けとなり、是正措置の推進にも貢献しています。
論文のダウンロード先：
https://dl.acm.org/doi/pdf/10.1145/3789240.3829180
- AliYANG の進化：モデル駆動型かつ LLM 支援のネットワーク設定管理
大規模なクラウドネットワークでは、多様なメーカー機器や CLI/NETCONF/gNMI など複数の管理インターフェース、そして絶えず変化するネットワークアーキテクチャが複雑に絡み合い、長年にわたり設定管理は大量のメーカー固有テンプレートとスクリプトへの依存を余儀なくされてきました。アリババクラウドの実環境では、設定生成、変更、監査のために数万ものテンプレートと数百万行のコードが蓄積されています。これらは重複するロジックが多く、検証が困難で、ネットワークの急速な進化にも追いつけないという課題を抱えていました。
AliYANG の核となる考え方は、設定の意味を脆いテキストテンプレートから切り離し、統一された実行可能なモデルとして定着させることにあります。標準的な YANG を拡張することで、このモデルは構造化インターフェースの記述だけでなく、CLI コマンドの文法、階層構造、削除方法、そして意味比較ルールまでも表現可能になります。メーカー固有の拡張モデルがデバイスの実力を保持する一方、メーカーに依存しない Core YANG が跨メーカーの設定意味を統一し、「意味と実装の分離」を実現します。
NetCMDB はこのモデルをコンパイルして強タイプ設定オブジェクトに変換し、翻訳、シリアライズ、比較、バージョン管理において生産レベルのランタイム能力を提供します。これにより、ネットワークアーキテクチャ設計から全量設定生成、インクリメンタルな設定変更、そして継続的な設定監査に至るまで、すべてが同一モデルに基づいて実行されます。さらにシステムは LLM を導入し、メーカー固有モデルの強化やコアモデル設計、双方向翻訳コードの生成を支援します。品質保証には、決定論的なマージ、コンパイル、テストによる閉ループプロセスを採用しています。
このシステムはすでに 3 年間生産環境で稼働しており、10 万台規模のデバイスと 10 億行を超える設定を管理しています。その結果、ネットワーク全体の設定照会時間は従来の 20 時間以上から数秒に短縮され、新メーカーの導入にかかる工数は 4〜6 倍削減されました。AliYANG は、モデルが設定管理の長期的な進化における制御点となり得ることを示しました。また、LLM はオフライン環境で検証可能なエンジニアリング閉ループの中で、モデルの進化を加速させるのに適していることが明らかになりました。
論文ダウンロード先：
https://dl.acm.org/doi/pdf/10.1145/3789240.3829193
AIOps
- AIDA: LLM による推論を活用したマルチベンダー機器障害の根本原因分析の加速
クラウドネットワークにおける障害対応では、監視システムが「どのデバイスに問題が発生したか」を素早く特定できる一方、「なぜ問題が起きたのか」という問いへの回答には、依然として運用担当者がメーカーと繰り返しログを集め、メールでやり取りする必要があるという課題があります。メーカー固有の知識は膨大な非構造化された履歴メールの中に散在しており、障害タイプは長尾分布を示しながらも継続的に進化しています。このため、従来の機械学習やログテンプレート、そして汎用的な RAG/LLM では、精度、説明可能性、一般化能力を同時に満たすことが困難でした。
AIDA の鍵となるアプローチは、過去の故障対応プロセスに潜む専門家の診断ロジックを構造化し、現在のデバイスログを用いて段階的に検証することです。LLM に根因を直接推測させるのではなく、この方法を採用します。オフラインフェーズでは、AIDA は教師あり微調整と GRPO 強化学習を用いて専用抽出器を訓練し、メールから「問題記述—診断証拠—根因結論」という説明可能な推論チェーンへと蒸留します。その後、構造認識型のグラフ融合手法を用いて等価ノードを統合し、冗長性を排除しながら異なる因果経路を保持することで、継続的に更新可能な RCA 知識グラフを構築します。同時に、意味的なログテンプレートも生成されます。
オンライン診断において、AIDA は故障の記述に基づいて候補となる推論チェーンを検索し、膨大なログから関連する証拠を絞り込みます。その後、証拠ノードと完全な推論チェーンに対して段階的な検証と信頼度スコアリングを行い、最終的に重要なログ、過去の事例、そして推論プロセスを含む根本原因報告書を出力します。
もし証拠が不十分だったり、推論の連鎖に矛盾が見つかったりした場合は、システムは結論を拒否して手動対応へ引き継ぎます。これにより、部分的な証拠のみに基づく誤診を防いでいます。
AIDA はすでに阿里云（アリババクラウド）の生産ネットワークで 1 年以上運用されており、846 件の機器故障に対応してきました。診断の精度は 95.4% に達し、中位の根本原因分析時間は 72.6 時間から 1.6 分へと劇的に短縮されました。また、複雑な長尾ケースにおける P90（上位 10% の処理時間）も 329.9 時間から 19.4 時間にまで改善されています。
これらの実践結果は、信頼性の高い LLM による診断が単にモデルの能力に依存するだけでなく、構造化された知識と検証可能な推論の閉ループをいかに構築するかにかかっていることを示しています。
論文のダウンロード先：
https://dl.acm.org/doi/pdf/10.1145/3789240.3829126
ネットワーク化されたエージェント記憶と因果関係表現：解釈可能なクラウドスケールでの根本原因特定に向けた経験
大規模な物理ネットワークにおいて、機器やリンクの故障の影響は、物理トポロジー、ルーティング経路、プロトコルの依存関係に沿って段階的に拡散し、数分間で数千種類の異なるアラートを発動させることがあります。ルールベースのシステムでは未知の故障を網羅することは難しく、単一のアージェントもコンテキストの制限により、大規模なアラートストームに対して情報の切り捨てを余儀なくされがちです。その結果、重要な因果関係の信号を見逃したり、診断結論と元のアラートを対応付けられなかったりして、運用担当者が伝播プロセスを検証したり生産環境での処置を行ったりすることが困難になります。
論文では、生産ネットワークにおける根本原因特定のためのマルチエージェントシステム「XiHe」を提案しています。XiProxy がアラートを正規化・分散させ、その後、機器の故障ドメインやアラートの特性に応じて、非集中型の Xilet エージェント群へタスクを割り当てます。各 Xilet は運用知識ベースの制約下でツールを呼び出し証拠推論を行うことで、未知の故障に対応し、根拠のない推測を減らします。
規模と全体像の両方を兼顾するため、XiHe ではネットワーク化されたエージェント記憶を採用しています。これにより、各 Xilet がトポロジー認識型の通信を通じて、根本原因の仮説、因果関係の依存性、検証結果を共有できるようになっています。また、ネットワーク化された因果表現を活用することで、分散推論を集約して統一された因果図に変換し、異常の種類、故障ドメイン、元のアラートを関連付けます。これにより、根本原因からビジネス症状への伝播経路が可視化されます。
Xilet は並列推論を行い、統合投票と因果図の安定化後の早期停止機構を組み合わせることで、結果の安定性とタイムリー性をさらに高めています。
XiHe はすでに阿里云の生産ネットワークで 12 ヶ月以上運用されており、3,000 件以上の事象処理をサポートしてきました。全体の根本原因特定精度は 94.6% に達し、既存の最良手法と比較して診断エラーが 54.9% 減少しました。アラート量が百倍に拡大しても、精度は 90.0% を維持しています。
これらの結果は、検証可能な因果チェーンが診断効果の向上だけでなく、運用担当者が AI による診断を信頼する基盤にもなることを示しています。
論文ダウンロード先：
https://dl.acm.org/doi/pdf/10.1145/3789240.3829145
AI における集合通信（Collective Communication for AI）
1. Theseus: ランタイム適応型 GPU 集合通信とホットスワップ可能なスケジューリング
現在の GPU 集合通信ライブラリ（CCL）は、安定した環境を前提とした固定されたスケジュールを採用しています。そのサポート対象となるスケジュールの集合や選択ロジックは、コミュニケーターが初期化される時点で決定され、実行時に変化するワークロードの特徴やハードウェアの状態といった条件を反映することができません。そのため、長時間稼働する GPU ジョブでは、数時間から数日経過した後に性能が著しく低下し、ジョブの完了時間が延びてクラスターの資源が無駄になるという問題が発生します。
NCCL や RCCL などの既存ライブラリは、静的なスケジュール空間内での限定的な調整しかできず、初期化後に新しいスケジュールを受け入れたり通信構造を変更したりすることはできません。
Theseus は、「スケジューリングレベル」のランタイム適応能力を提供する新型 CCL バックエンドです。ユーザーが独自にスケジュールや選択戦略を定義可能であり、既存システムへの導入も容易なドロップイン代替案となっています。その中核となるのは「動的選択」と「ホットスワップ（熱交換）」という 2 つの機能です。
動的選択においては、Theseus は"selection context"（選択コンテキスト）を設計しました。これにより、ユーザーは CCL 内部の指標を超えた、クラスター全体のランタイム条件に基づいて柔軟に戦略を指定できます。また、カスタマイズされた合意形成プロトコルによって全 GPU で選択結果が一致することを保証し、各リクエストごとの交渉オーバーヘッドを実質ゼロまで削減しています。
ホットスワップ機能では、リソース管理ツリーを用いてスケジュール資源を階層的に整理し、異なるスケジューリング間での効率的な共有を実現します。古いスケジュールが不適切になり、新しいものへ置き換える必要がある場合でも、ゼロから再構築するのではなく増分的なデルタ移行を行います。これにより、すべての GPU 間で低オーバーヘッドかつ中断なしにスケジュールを一貫して切り替えることが可能になります。
多様な GPU ワークロードと直感的な戦略を用いた評価結果によると、Theseus は NCCL と比較して、安定環境下では通信時間が最大 1.61 倍、動的環境下では最大 2.46 倍の高速化を達成しました。また、エンドツーエンドのジョブ完了時間は最大 1.84 倍向上し、そのオーバーヘッドは同等かそれ以下に抑えられています。
論文ダウンロード先：
https://dl.acm.org/doi/pdf/10.1145/3789240.3829134
- PReCCL：統合型帯内テレメトリとワークロード再割り当てによる高性能かつ堅牢な集合通信
現代の集合通信ライブラリ（CCL）は、1 つの集合通信タスク（CCT）を複数のサブタスクに分割し、それぞれをリングやツリーといった仮想トポロジ（VT）にマッピングすることで、並列度とリンク利用率を最大化しています。AI 訓練がより大規模なクラスターへと拡大するにつれ、ネットワークの混雑や障害は避けられなくなりました。しかし、1 つでも VT が遅延したり停止したりすれば、それが原因で CCT 全体が遅れてしまいます。
既存の解決策には課題があります。一つ目は、伝送層の仕組みに依存しており、サブタスクを横断する視点を持っていない点です。二つ目は、静的な CCL スケジューリングを採用しているため、動的に変化する異種ネットワークへの適応が難しい点です。
PReCCL は NCCL の代替としてそのまま導入できる（drop-in）ソリューションであり、ソフトウェアレベルでの帯内（inband）テレメトリと、VT 間を跨ぐワークロードの再割り当て機能を組み合わせています。P4-INT のような専用ハードウェアに依存する従来の手法とは異なり、PReCCL は CCL 内部で帯内監視を実現しています。これにより、各 VT の停止（stall）カウントを正確に計測でき、テレメトリデータを既存の集合通信トラフィックに乗せることで、追加の転送オーバーヘッドをほぼゼロに抑えています。
この細粒度な可視性に基づき、PReCCL は動的な跨 VT 再割り当てメカニズムを用いて、混雑や障害によって遅延している VT の負荷を健全な VT へ移行します。再割り当ては CCT の境界でのみ発生します。各 CCT にはエポックがマーキングされ、各ランク（rank）は同一のエポックのメタデータから決定論的に次の割り当てを計算します。進行中の CCT は変更されず、NCCL 接続の新規作成や破棄も不要です。既存のチャネル上で転送するバイト範囲のみを調整するため、ランク間の整合性競争を防ぎ、追加の同期処理も不要となります。部分的な障害も同様のメカニズムで遮蔽・再割り当てされるため、訓練は中断されません。
PReCCL は 32 枚の GPU を用いたテストベッド、大規模シミュレーション、そして 1024 枚の GPU を持つ本番クラスターで評価されました。テストベッドでは、CCT の完了時間が最大 2.1 倍向上し、エンドツーエンドの訓練速度も 1.21 倍改善しました。また、最適化されたメッセージサイズ閾値を超えた場合でも、オーバーヘッドは極めて低く抑えられています。これらの結果は、CCL 自体が性能と堅牢性の両立において最適な観測・制御ポイントであることを示しています。
論文ダウンロード先：
https://dl.acm.org/doi/pdf/10.1145/3789240.3829133
- 均衡化とそれ以上：エキスパート並列における通信中心の最適化
混合専門家（MoE）アーキテクチャは、トークンごとに少数の専門家のみを活性化することで、大規模言語モデルを兆パラメータ規模へと拡張しています。本番環境での MoE 推論では通常、エキスパート並列（EP）が採用され、GEMM やカーネルの効率を維持するために、ブロック単位で専門家を異なる GPU に配置します。
しかし、オンラインでの EP デプロイメントには、2 つの主要なボトルネックが存在します。1 つ目は専門家の負荷不均一性です。これにより計算と通信の両面で「遅れ」が発生し、全体の処理速度を阻害します。2 つ目は通信効率の低さです。たとえ負荷が均衡化されたとしても、GPU 間のデータ転送が依然としてレイテンシの主要因となっています。
EPLB などの既存手法は、過去の統計に基づいて定期的に専門家の配置を再編成しますが、リアルタイムでの調整には対応できません。また、計算のバランスのみを最適化し、ネットワークトラフィックへの配慮が不足しているため、負荷の不均衡が依然として尾遅延（tail latency）の主要な原因となっています。
EPIC は、実環境での展開を想定した経験駆動型の EP 推論システムです。このシステムは、まず性能に応じた専門家（エキスパート）の移行とランタイム時の専門家活性化によって負荷分散の問題を解決し、次にトポロジー適応型の転送カーネルと細粒度な計算・通信の重なり合わせにより通信効率を向上させます。
均衡化の観点では、EPIC はトポロジー認識型の専門家配置と低コスト移行を融合させ、計算と通信のバランスを図ります。通信面においては、トポロジー認識転送カーネルと冗長性除去機構を提供して重複送信を防ぎ、各専門家の単位で細粒度な計算を行うことで通信時間を隠蔽しつつ、GEMM 効率を損ないません。EPIC はシナリオに応じて最適な最適化戦略の組み合わせを自動選択し、最大限のパフォーマンスを発揮します。
EPIC はすでにオンライン推論サービスにおいて O(10K) GPU の規模で稼働しており、Qwen3-Coder や DeepSeek-R1 などのオープンソースモデルや、社内で開発した独自モデルをサポートしています。サービスの安定性を維持しながら、通信時間を最大 40%、トークンあたりの遅延（TPOT）を最大 21% 削減し、スループット（TPS）は最大 27% 向上させました。
論文ダウンロード先：
https://dl.acm.org/doi/pdf/10.1145/3789240.3829201
Data Center Networks
- EPIC: Abstraction and Polymorphism of In-Network Collectives on Ethernet
インネット計算（In-network computing）は、集合通信をネットワークスイッチにオフロードすることでトラフィックを圧縮し、転送プロセスを加速します。インネット計算システムは通常、スイッチ、ネットワークカード、プロトコルスタック、通信ライブラリ、ネットワークマネージャで構成されますが、オープンなイーサネット生態系ではこれらのコンポーネントが異なるベンダーや開発者に属しており、相互依存関係にあります。各ベンダーや開発者は自らの機能範囲内でのみ活動するため、全体システムを構築することはできません。また、単一のニッチ（市場の隙間）で独自機能を果たしても他社との連携がなければ、その研究開発投資はシステムレベルでの加速能力として現れず、非効率な投資対効果をもたらします。
この課題に対し、ハイスループットイーサネット・コンソーシアム（High Throughput Ethernet Consortium）は標準組織として「EPIC プロトコル（Ethernet Polymorphic In-network Collective）」を設計しました。その核心となる考え方は「統一された抽象化」と「多様な実装」です。このアプローチにより、プロトコルの仕様と参考実装が提示されました。
プロトコル仕様では、機能コンポーネントの区分けがイーサネットベンダーの機能範囲に基づいて行われ、既存のインターフェース仕様が維持されています。また、参考実装においては、EPIC がプロトコル仕様に準拠した 3 つの形態のスイッチ設計を提示しており、これらはすべてネットワークカードと正しく相互運用可能です。この設計により、異なるハードウェア能力を持つスイッチベンダーが広く参画することが可能になりました。
さらに、EPIC の設計は以下の 3 つの課題も克服しています。第一に、形式化されたプロトコル検証手法を用いて 3 つの形態のプロトコルの正しさを分析・確認しました。第二に、モジュール型設計を採用して 3 つのプロトコルを構築し、簡素な形態から複雑な形態へと段階的に進化させることを可能にし、開発コストを削減しました。第三に、統一された抽象化の上に SDN（Software-Defined Networking）構造に基づくリソース管理方案を設計し、多様な AI 学習・推論シナリオに対応できるようにしています。
EPIC プロトコル仕様はハイスループットイーサネット・コンソーシアムのメンバー企業に提供され、実装と検証が行われました。コンソーシアムはプロトコル検証プラットフォームで正しさをテストし、プログラマブルスイッチプラットフォームで加速効果と RDMA プロトコルの互換性を確認しました。さらにシミュレーションプラットフォームでは大規模クラスター下でのリソース利用率を評価し、FPGA/RTL レベルの実装とテストによってチップの実現可能性を検証しました。
論文ダウンロード先：
https://dl.acm.org/doi/pdf/10.1145/3789240.3829196
Anytest: ハードウェア転送性能の異常（NPA）の根本原因を特定する
RoCEv2 をベースとした RDMA は、高性能計算やストレージ、大規模モデルのトレーニング・推論における基幹インフラとなっています。しかし、システム規模が拡大するにつれ、リンクやハードウェアに明らかな故障がないにもかかわらず、スループットの急落、持続的な不公平感、レイテンシの膨張といった転送層の性能異常（NPA）が頻発しています。
その根本原因を特定するのは、運用担当者にとって最も困難な課題の一つです。監視カウンターの粒度は 10 ミリ秒から数秒単位である一方、ハードウェアの状態機械はマイクロ秒以下の速度で動作するため、微細なバースト現象が平均化されてしまいます。また、RoCEv2 は送信側、受信側、スイッチが密結合した分散システムであり、同じ症状でも複数の箇所が原因となり得ます。さらに、異常は特定のネットワークトポロジやファームウェアに強く依存するため、オフラインで再現するのは極めて困難です。
従来のカウンター推定では因果関係を特定できず、商用のハードウェアテスターは配線変更とシステム停止を必要とします。また、ファジーテストツールは問題を検出できるものの、原因の特定まではできません。
Anytest の核心となるアプローチは、RoCEv2 に対して「その場（in-situ）」で動作するブラックボックステストツールを提供し、役割を分解することです。具体的には、「反応点（RP：送信側の輻輳制御）」「通知点（NP：受信側の CNP/ACK/NACK）」「輻輳点（CP：スイッチ）」の 3 つに分類します。
各テストでは、被験機（DUT）がこれら 3 つの役割のうち 1 つのみを担い、残りの 2 つはプロトコル仕様に準拠した DPDK エンドポイントでシミュレートします。これにより DUT をコンポーネント間の複雑な相互作用から切り離し、ブラックボックス化された挙動を検証可能な仮説へと変換します。
この仕組みを実現するために、Anytest は以下の 3 つの能力を備えています：
- プロトコル仕様に準拠したホワイトボックスパケット生成
- イベント注入（制御パケットや特定のメッセージシーケンスの操作）
- ハードウェアタイムスタンプに基づくマイクロ秒単位の高精度計測
さらに、O(1) 計算量の ICRC 高速パスや、パディングを利用したパケット間隔制御などの技術を組み合わせることで、シングルコアで 200Gbps のラインレートを実現し、400/800Gbps への拡張も可能です。全体として、「症状の特定→テスト軌道の設定→役割分離による回帰テスト→トリガー条件の抽出」というワークフローに従います。
Anytest はアリババクラウドの RoCE クラスターにおいて、約 1 年間オンデマンドで運用されています。対象は 4 種類のネットワークカードと 6 種類のスイッチで、これまでに 58 件の NPA を特定しました。そのうち 39 件（67.2%）は回帰テストスイートによって人手を介さず直接特定され、平均の特定コストはわずか 3.1 人時でした。一方、従来は複雑なケースで迂回調査を行うのに約 20 人日かかっていました。
Anytest は、ファームウェアの CNP 応答パターンや隠れたトークンバケット、パケットロス抑制による CNP の不具合などによる輻輳の急落、PER_QP タイマーの集約が引き起こす incast 時の不公平感、DCQCN の間隔への敏感性、ファームウェアに依存する輻輳制御の違いといった、実際の根本原因を次々と明らかにしました。
このプロジェクトから得られた重要な教訓は、信頼性の高い特定には「役割の分離」「マイクロ秒単位の分解能」「パケットレベルでの注入」が不可欠であることです。また、「設定内容と意味論は一致しない」「輻輳フィードバック自体も機能不全に陥る可能性がある」という事実を、オンライン実行による証拠で検証する必要性が浮き彫りになりました。
image
image
論文ダウンロード先：
https://dl.acm.org/doi/pdf/10.1145/3789240.3829125
3.Spillway: DPU とホストを統合した vSwitching ファブリックの構築
現代のクラウドデータセンターでは、ホスト側のリソース消費を抑え、テナント間の分離を強化するため、DPU に vSwitch の転送機能をオフロードするのが一般的です。しかし、DPU 自体のメモリや CPU リソースは限られており、ハードウェアのアップグレードサイクルも長いため、vSwitch が扱えるセッション表の容量や conntrack の接続数、CPS（秒間処理パケット数）性能がボトルネックになりがちです。
一方、AI の学習・推論や NFV などの業務では、短時間の接続バーストやコネクションストームといった、極めて動的なトラフィック特性が見られます。これにより DPU リソースはすぐに飽和状態に陥る一方で、ホスト側の計算リソースは大量に遊んでしまい、有効活用できていないのが実情です。
こうした課題に対し、アリババクラウドのネットワークチームは「Spillway」を提案しました。これは単一ノード内の DPU とホスト計算ドメイン間の硬直的な境界を打破し、業界初の DPU-Host 混合データプレーンを構築するものです。これにより、vSwitch の仮想転送機能を滑らかに弾力的に拡張することが可能になります。
DPU リソースの使用率が飽和状態になった際、統一リソーススケジューラがホストのアイドル vCPU 上で Elastic VM を起動し、vSwitch が溢れ出したトラフィックを処理します。このプロセスはテナントや制御プレーンに対して完全に透明です。トラフィックの振り分けには sketch 測定メカニズムを採用し、Top-K 戦略と組み合わせることで、コストパフォーマンスに最も優れたフローのみを戻すようにしています。
テナント間の分離については、pCPU バインド、NUMA 最適化、CAT/MBA コントロール、ユーザー空間での仮想 ATC など、先進的な仮想化技術を駆使してリソース競合を回避。これにより、テナント性能の強力な隔離を実現しています。
Spillway はアリババクラウドで既に 12 ヶ月以上、大規模に運用されています。対象サーバーは 3000 台を超え、単一ノードあたりの CPS 性能は最大 90% 向上しました。トラフィックの急増に対する弾力的な拡張にはわずか 200 ms で対応可能で、これはノード間のフェイルオーバーよりも 1 つオーダー（桁）速いものです。また、同一ノード内の他のテナントへのスループットへの影響は 1% を超えません。
大規模な生産環境での実証により、本手法の実用性と経済的価値が確認されました。これは AI エラにおけるクラウドネットワークが動的トラフィックに柔軟に対応するための新たな基盤となっています。
論文ダウンロード先：
https://dl.acm.org/doi/pdf/10.1145/3789240.3829154
Nimitz から NetPila へ：大規模コンテナネットワークの進化
大規模なクラウドコンテナサービスでは、ネットワークは「弾力性」「性能」「安定性」の三要素を同時に満たす必要があります。アリババは 2019 年より、この課題に対応する第一代コンテナネットワーク「Nimitz」の構築を開始しました。VxLAN を用いた"overlay–underlay"マッピングを採用した Nimitz は、数千ものテナントや数十種類の業務で 5 年間安定して稼働してきました。
しかし、AI のトレーニングと推論が急成長する中で、単一テナントのコンテナ規模は O(100K) を突破しました。これにより Nimitz は「C100K 問題」に直面します。VxLAN のマッピングテーブルはコンテナ数に比例して膨張し、単一の OVS（Open vSwitch）テーブル項目数は 50 万条に近づきます。10% の拡張を行う際にも 15 万件の同期リクエストを処理する必要があり、さらにエンカプシュレーションとデカプシュレーションによる約 5% のスループット低下やレイテンシ増加が発生します。これらは RoCE（RDMA over Converged Ethernet）の性能揺らぎ、ノードの冷間起動の遅延、およびクリーンアップの非効率化など、一連のパフォーマンス劣化を引き起こしました。
根本的な原因は、VxLAN が overlay と underlay の 2 つのアドレス空間を人為的に分断している点にあります。超規模環境下では、グローバルなマッピングを維持しブロードキャストする仕組みがもはや持続不可能です。
NetPila はこの課題に対し、VxLAN を完全に廃止し、IPv6 で置き換えるという革新的なアプローチを採用しました。64 ビットのノードアドレス、24 ビットのテナント ID、そして 40 ビットのコンテナアドレスを単一の 128 ビット IPv6 アドレスにエンコードすることで、コンテナアドレスを物理ネットワークアドレスの自然な延長線上に位置づけました。
これにより、コンテナネットワークは"overlay–underlay"マッピングテーブルやエンカプシュレーション/デカプシュレーション処理が不要となり、パケット処理テーブルの複雑さは O（コンテナ数）から O（ローカルコンテナ数）へと劇的に低下します。すべてのテーブル項目を NIC（Network Interface Card）ハードウェアへ静的にオフロード可能になりました。また、クラスタ更新もグローバルなブロードキャストから、ノード間のピアツーピア通信へと簡素化されました。
IPv6 がノードアドレスを露出させるプライバシーリスクについては、NetPila は対称鍵 AES-128 を用いて IP アドレスを暗号化置換することで対応しています。さらにデフォルトではすべてのパケットをドロップし、ソースと宛先を逐条検証してテナント間の完全な分離を実現します。
NetPila はすでに 2 年以上にわたり本番環境で稼働しており、その代表例として 9,205 ノード、589,120 コンテナの構成が確認されています。評価では最大 2.5 万ノード規模のジョブもカバーしました。
2.5 万ノードでの 10% 拡張において、所要時間は Nimitz の 12.5 分から 1.25 分へと短縮され、10 万ノード規模でも 5 分で完了します。RoCE のレイテンシは最大 4.281% 低下し、帯域幅は最大 6.055% 向上しました。また、vLLM 推論における最初のトークン到達時間、トークンあたりの処理時間、およびトークン間の遅延はそれぞれ約 0.8%、0.669%、1.081% 改善され、ネイティブ IPv6 と比較してもそのオーバーヘッドは無視できるレベルです。
これらの実践結果から、現代の大規模コンテナネットワークにおいて VxLAN が持つ「IP の移行」や「カスタムサブネット」といった機能は、実際にはほとんど利用されていないことが明らかになりました。シンプルであることこそが、より優れた弾力性、安定性、そして性能をもたらすのです。
論文ダウンロード先：
https://dl.acm.org/doi/pdf/10.1145/3789240.3829203
5. 透明な TCP 置換の再考：クラウドにおける SMC-R の実践的教訓
クラウド上のネットワーク帯域が 100Gbps を超える時代を迎え、Linux カーネルの TCP/IP プロトコルスタックにかかる処理オーバーヘッドが顕著になっています。一方、多くのアプリケーションはソケットインターフェースをベースに開発されているため、RDMA ネイティブインターフェースへの改修は容易ではありません。透明な TCP 置換技術を使えば、アプリケーション側の変更なしで RDMA の加速効果を得られます。この分野の研究は長年学術界で活発に行われてきましたが、本番環境での大規模導入には至っていませんでした。
アリババグループ傘下の阿里云が独自開発したコアネットワーク技術「eRDMA」を基盤に、研究チームは 4 年にわたり、カーネルレベルの SMC-R（Shared Memory Communications over RDMA）ソリューションを実際のビジネスシーンで普及させ、洗練させてきました。
論文では、透明な置換がなぜ「即座に使えるもの」になりにくいのかという深層原因を体系的に整理しています。具体的には、有効化メカニズムの柔軟性の欠如、アプリケーションが Linux TCP に対して持つ暗黙的な依存関係、運用エコシステムにおけるギャップ、そしてミドルウェアによる干渉などが挙げられます。これらに対する工学的な解決策として、eBPF を活用したカーネルレベルの有効化メカニズムと、接続単位での制御戦略を提案しています。このアプローチでは、テナントのイメージを改変することなく、必要に応じてオンオフを切り替えることが可能です。関連するパッチはすでに Linux 上流コミュニティへ貢献されています。
さらに論文では、エンドツーエンドのパフォーマンス向上がどこから来るのかという点も明確にしました。プロトコルスタック自体の高速化による効果は数マイクロ秒程度に過ぎません。本番環境で問題となるのは、非最適化されたシステム設定やアプリケーションの動作様式であり、透明な置換技術はこの弱点を回避する役割を果たします。
実際の生産環境に近いデフォルト設定での測定では、SMC-R により Redis のリクエスト遅延は最大 70% 削減され、MySQL のスループットは最大 52% 向上しました。
論文ダウンロード先：
https://dl.acm.org/doi/pdf/10.1145/3789240.3829194
ご意見やご感想はコメント欄でお待ちしています。
詳細は微信（WeChat）アプリにてご確認ください。
原文を表示
原创 阿里学术 2026-08-19 18:25 浙江
image
论文研究成果涵盖AI 智算网络与集合通信、云网关数据面、网络验证、智能运维等技术方向，以持续突破再次获得国际学术界的认可
image
这是2026年的第 53 篇文章
（ 本文阅读时间：约 15 分钟 ）
日前，计算机网络与通信领域顶级国际学术会议 SIGCOMM 2026在美国丹佛召开，阿里巴巴集团共有12 篇论文被主会收录，在全球企业中处于领先身位。作为唯一与顶尖高校/科研院所同处第一梯队的中国产业界机构，论文研究成果涵盖AI 智算网络与集合通信、云网关数据面、网络验证、智能运维等技术方向，以持续突破再次获得国际学术界的认可。
SIGCOMM 是计算机网络领域公认的最高级别国际学术会议（CCF A 类），常年录用率仅 15%–22%，含金量极高。
阿里巴巴资深技术专家翟恩南联合担任第三届 ACM SIGCOMM 形式化方法辅助网络运维研讨会（The 3rd ACM SIGCOMM Workshop on Formal Methods Aided Network Operation，FMANO）大会主席，阿里巴巴高级技术专家袁驿飞主持本届研讨会。研讨会汇聚学界网络研究人员与互联网服务提供商，围绕形式化方法在网络运维中的应用展开充分讨论，以提升网络的可用性、可靠性与性能。
以下为各论文解读⬇️
Network Management & Verification
1.Verifying Non-Deterministic Convergence on a Global Production WAN
大规模生产级广域网依赖仿真验证工具保障配置正确性，阿里云自研的 Hoyan 及业界同类工具均假设 BGP 控制平面收敛到唯一确定的数据平面。然而，非确定性收敛——同一配置因收敛时序不同而产生多个稳定数据平面——使验证器报告"正确"而实际网络已偏离预期，由此引发的流量黑洞等事故事后才被发现。在数千台路由器、数十万条链路的WAN上验证该问题面临指数级可扩展性挑战，现有方法均无法适用。
论文提出业界首个在全球生产级 WAN 上验证非确定性收敛的系统——TianYan。其核心洞察是：生产网络中同组路由器因共享相似策略，其路由行为具有可预测的相似性。TianYan据此证明两条剪枝定理，将路径搜索空间从路由器级压缩至组级，实现指数级缩减且不影响分析正确性。系统采用四阶段流水线：首先通过改进的路由仿真为每个前缀构建精简的收敛分析模型；然后以多项式时间算法对全量 200 万前缀快速筛选，识别约 4 万疑似前缀，再按根因分组将耗时的约束求解从数万次缩减至约百次；接着自动定位导致非确定性收敛的根因——具体到哪些路由器及冲突策略；最后通过消除争议环或对齐仿真至实际网络状态，恢复验证准确性。
TianYan 已部署超一年，发现约2% 前缀（~4 万）存在非确定性收敛，识别约 100 类根因，将约 3 万前缀的验证结果从错误对齐至正确，首次揭示了非确定性收敛在生产WAN中的广泛性与实际影响。相关结果已帮助运维团队识别多个此前未被察觉的设计与实现缺陷，并上报推进治理。
论文下载地址：
https://dl.acm.org/doi/pdf/10.1145/3789240.3829180
2.Evolution of AliYANG: Model-driven and LLM-assisted Network Configuration Management
在大规模云网络中，多厂商设备、CLI/NETCONF/gNMI 等多种管理接口以及持续变化的网络架构，使配置管理长期依赖大量厂商专用模板和脚本。阿里云生产环境中，仅配置生成、变更与审计就积累了数万套模板和数百万行代码，重复逻辑多、验证困难，也难以随网络快速演进。
AliYANG 的核心思想，是把配置语义从易碎的文本模板中抽离出来，沉淀为统一、可执行的模型。它扩展标准 YANG，使模型既能描述结构化接口，也能表达 CLI 命令的语法、层级、删除方式及语义比较规则。厂商增强模型保留设备真实能力，厂商无关的 Core YANG 则统一跨厂商配置语义，实现“语义与实现解耦”。
NetCMDB 将模型编译为强类型配置对象，为翻译、序列化、比较和版本管理提供生产级运行时能力，使网络架构设计、全量配置生成、增量配置变更和持续配置审计都基于同一套模型完成。系统进一步引入 LLM，辅助厂商模型增强、核心模型设计和双向翻译代码生成，并通过确定性合并、编译和测试闭环保障质量。
该系统已连续生产运行三年，管理十万级设备和超过十亿行配置；全网配置查询由 20 余小时缩短到秒级，新厂商接入工程投入降低4至6倍。AliYANG 表明，模型可以成为配置管理长期演进的控制点，而 LLM 更适合在离线、可验证的工程闭环中加速模型演进。
论文下载地址：
https://dl.acm.org/doi/pdf/10.1145/3789240.3829193
AIOps
1.AIDA: Accelerating Root Cause Analysis for Multi-Vendor Device Failures with LLM-Powered Reasoning
在云网络故障处置中，监控系统通常能快速定位“哪台设备出了问题”，但回答“为什么出问题”仍依赖运营人员与设备厂商反复收集日志、邮件沟通。厂商专有知识分散在大量非结构化历史邮件中，故障类型长尾且持续演进，使传统机器学习、日志模板和通用 RAG/LLM 难以兼顾精度、可解释性与泛化能力。
AIDA 的关键思路，是把历史故障处理中隐含的专家诊断逻辑结构化，再用当前设备日志逐步核验，而不是让 LLM 直接猜测根因。离线阶段，AIDA 通过监督微调和 GRPO 强化学习训练专用提取器，将邮件蒸馏为“问题描述—诊断证据—根因结论”的可解释推理链；随后利用结构感知的图融合方法合并等价节点、消除冗余并保留不同因果路径，构建可持续更新的 RCA 知识图谱，同时生成语义日志模板。
在线诊断时，AIDA 根据故障描述检索候选推理链，从海量日志中筛选相关证据，再对证据节点和完整推理链进行分步验证与置信度排序，最终输出包含关键日志、历史案例和推理过程的根因报告。若证据不足或链条存在矛盾，系统会拒绝下结论并转交人工，避免基于局部证据误诊。
AIDA 已在阿里云生产网络部署超过一年，处理 846 起设备故障，诊断精确率达到95.4%；中位根因分析时间由 72.6 小时缩短至 1.6 分钟，复杂长尾案例的 P90 由 329.9 小时降至 19.4 小时。实践表明，可靠的 LLM 诊断不仅依赖模型能力，更依赖结构化知识与可验证推理闭环。
论文下载地址：
https://dl.acm.org/doi/pdf/10.1145/3789240.3829126
2.Networked Agent Memory and Causality Representation: Experiences towards Interpretable Cloud-Scale Root-Causing
在大规模物理网络中，设备或链路故障的影响常沿物理拓扑、路由路径和协议依赖逐级扩散，几分钟内即可触发数千条异构告警。规则系统难以覆盖未知故障；单智能体受上下文限制，面对告警风暴常需截断信息，容易遗漏关键因果信号，且难以将诊断结论与原始告警对应，无法支撑运维人员核验传播过程和开展生产处置。
论文提出面向生产网络根因定位的多智能体系统 XiHe。XiProxy 归一化并分发告警，再按设备故障域或告警特征，将任务分派给去中心化的 Xilet 智能体群。各 Xilet 在运维知识库约束下调用工具开展证据推理，以适应未知故障并减少无依据的推断。
为兼顾规模与全局视角，XiHe 设计网络化智能体记忆，使各 Xilet 通过拓扑感知通信共享根因假设、因果依赖和验证结果；同时利用网络化因果表示，将分布式推理汇聚为统一因果图，关联异常类型、故障域和原始告警，呈现根因到业务症状的传播路径。Xilet 并行推理，配合集成投票和因果图稳定后的早停机制，进一步提升结果稳定性与时效性。
XiHe 已在阿里云生产网络部署超过 12 个月，协助处理 3000 余起事件，整体根因定位准确率达到 94.6%；与最佳现有方法相比，诊断错误减少 54.9%。即使告警量扩大百倍，准确率仍保持 90.0%。结果表明，可验证因果链不仅能提升诊断效果，也能增强运维人员对 AI 诊断的信任。
论文下载地址：
https://dl.acm.org/doi/pdf/10.1145/3789240.3829145
Collective Communication for AI
1.Theseus: Runtime-Adaptive GPU Collective Communication with Hot-Swappable Schedules
当前 GPU 集合通信库（CCL）采用为稳定环境预设的调度，其支持的调度集合与选择逻辑在 communicator 初始化时即固定，无法反映运行时不断变化的条件，如 workload 特征与硬件健康状态。因此长时间运行的 GPU 作业在执行数小时乃至数天后性能明显下降，导致作业完成时间变长、集群资源浪费。NCCL/RCCL 等库只能在静态调度空间内做有限调整，初始化后无法接纳新调度或改变通信结构。
Theseus 是一个提供“调度级”运行时自适应能力的新型 CCL 后端，允许用户自定义调度与选择策略，并作为 drop-in 替代方案便于集成。它的两大核心特性是动态选择与热切换。
动态选择方面，Theseus 设计了 selection context，让用户能用跨集群的运行时条件（超出 CCL 内部指标）灵活指定策略，并通过定制的 agreement 协议保证各 GPU 选择一致，把每次请求的协商开销摊薄到近乎为零。热切换方面，它用资源管理树分层组织调度资源，实现调度间高效的资源共享；当旧调度不再合适、需要替换时，做增量的 delta 迁移而非从零重建，从而以低开销、无中断地在所有 GPU 间一致地切换调度。
在多种 GPU workload 与直观策略下的评测表明，相比 NCCL，Theseus 在稳定环境下通信时间最多加速 1.61×，动态环境下最多加速 2.46×，端到端作业完成时间最多提升 1.84×，且开销相当或更低。
论文下载地址：
https://dl.acm.org/doi/pdf/10.1145/3789240.3829134
2.PReCCL: Performant and Resilient Collective Communication via Integrated Inband Telemetry and Workload Reallocation
现代集合通信库（CCL）把一次集合通信任务（CCT）拆解为多个子任务，各自映射到一个虚拟拓扑（VT，如 ring 或 tree）以最大化并行度与链路利用率。随着 AI 训练扩展到更大集群，拥塞与故障不可避免，任何一个掉队的 VT 都会拖慢整个 CCT。现有方案要么依赖底层传输层机制、缺乏跨子任务视角，要么采用静态 CCL 调度、无法适应动态异构网络。
PReCCL 是一个可直接替换 NCCL（drop-in）的方案，将软件在带内（inband）遥测与跨 VT 工作负载再分配相结合。不同于依赖专用硬件的遥测（如 P4-INT），PReCCL 在 CCL 内部实现在带监控，精确测量每个 VT 的 stall 计数，并把遥测元数据搭载在已有的集合通信流量上，几乎不引入额外传输。
借助这种细粒度可见性，PReCCL 用动态跨 VT 再分配机制，把拥塞或故障导致的掉队 VT 上的负载迁移到健康 VT。再分配只在 CCT 边界发生：每个 CCT 标记 epoch，各 rank 从同一 epoch 元数据确定性地计算下一次分配，在途 CCT 不被修改，也不新建或销毁 NCCL 连接，仅调整已有通道上的字节范围，从而避免跨 rank 一致性竞争、无需额外同步；部分故障同样以此机制屏蔽并重分配，训练不中断。
PReCCL 在 32 卡 GPU 测试床、大规模仿真和 1024 卡生产集群上评测。在测试床上，CCT 完成时间最多提升 2.1×，端到端训练提升 1.21×，且在调优的消息大小阈值之上开销很低。结果表明，CCL 自身正是兼顾性能与韧性的最佳观测与调控点。
论文下载地址：
https://dl.acm.org/doi/pdf/10.1145/3789240.3829133
3.Balancing and Beyond: Communication-Centric Optimizations in Expert Parallelism
混合专家（MoE）架构通过每个 token 只激活少量专家，把大语言模型扩展到万亿参数规模。生产中的 MoE 推理通常采用专家并行（EP），把整块专家放置到不同 GPU 上以保持 GEMM/kernel 效率。然而线上 EP 部署常受两个瓶颈困扰：一是专家负载不均，产生计算与通信上的掉队者；二是通信低效，即便负载均衡后 GPU 间传输仍主导延迟。EPLB 等现有方案靠周期性按历史统计重排专家，但无法实时调整，且只均衡计算、忽视网络流量，使不均衡仍是尾延迟的主要来源。
EPIC 是一个经验驱动的 EP 推理系统，针对真实部署逐步解决上述问题。它先通过性能感知的专家迁移与运行时专家激活缓解负载不均，再用拓扑自适应的传输 kernel 与细粒度的计算–通信重叠改善通信效率。
在均衡侧，EPIC 融合拓扑感知的专家放置与低成本迁移，同时均衡计算与通信；在通信侧，它提供拓扑感知传输 kernel 与去冗余机制以消除重复传输，并做每专家的细粒度计算来隐藏通信而不损失 GEMM 效率。EPIC 会根据不同场景自动选择最合适的优化策略组合，以取得最佳性能。
EPIC 已在线上推理服务中以 O(10K) GPU 规模部署，服务开源模型（如 Qwen3-Coder、DeepSeek-R1）与内部自研模型。在保持服务稳定的同时，将通信时间与每 token 延迟（TPOT）最多分别降低 40% 和 21%，TPS 最多提升 27%。
论文下载地址：
https://dl.acm.org/doi/pdf/10.1145/3789240.3829201
Data Center Networks
1.EPIC: Abstraction and Polymorphism of In-Network Collectives on Ethernet
在网计算将集合通信卸载到网络交换机进行，可以压缩流量，进而加速传输过程。在网计算系统的构成通常包括交换机、网卡、协议栈、通信库、网络管理器；但是在开放以太网生态中，上述组件分属不同的供应商或者开发者，彼此之间存在依赖。以太网生态的的供应商和开发者在自己的功能范围内无法实现整体的系统；在单独一个生态位实现自己功能而缺乏其他厂商配合的情况下，其研发投入无法体现为系统级别的加速能力，造成低效的投入回报比。
高通量以太网联盟作为标准组织，设计了EPIC协议（Ethernet Polymorphic In-network Collective）；依靠“统一抽象、多态实现”的核心思路，给出了协议规范和参考实现。协议规范中，功能组件的划分按照以太网供应商的功能范围划分，且保持已有接口规范；在协议参考实现中，EPIC给出符合协议规范的三种形态的交换机设计，都可以与网卡正确互操作，允许不同硬件能力的交换机厂商广泛参与。EPIC的设计另外克服了三项挑战：采用形式化协议验证的方法分析和确认了三种形态协议的正确性；采用模块化设计的方法设计三种协议，允许三种形态的协议从简到繁的演化，降低研发成本；在统一抽象基础上设计了基于SDN结构的资源管理方案，适用于多种人工智能训推场景。
EPIC协议规范交付给高通量以太网联盟的成员进行实现和验证，联盟通过协议验证平台测试了协议正确性，通过可编程交换机平台验证了加速效果和RDMA协议兼容性，通过模拟平台测试了协议在大规模集群下的资源利用率，通过FPGA/RTL级实现和测试验证了芯片可行性。
论文下载地址：
https://dl.acm.org/doi/pdf/10.1145/3789240.3829196
2.Anytest: Localizing the Root Cause of Hardware Transport Performance Anomalies
基于 RoCEv2 的 RDMA 已成为高性能计算、存储与大模型训练/推理的骨干互连。但随着规模扩大，即便没有链路或硬件故障，也频繁出现吞吐塌陷、持续不公平、延迟膨胀等传输层性能异常（NPA）。定位其根因是最棘手的运维难题：监控计数器停留在 10 毫秒到秒级，而硬件状态机在亚微秒级反应，微突发被平均掉；RoCEv2 是发送端、接收端与交换机紧耦合的分布式系统，同一症状可能源自多处；异常又与具体拓扑、固件强绑定，难以离线复现。传统计数器推断缺乏因果性，商用硬件测试仪需重新布线且离线，模糊测试类工具能发现却无法定位。
Anytest 的关键思路是做一个在位（in-situ）的黑盒测试工具，对 RoCEv2 进行角色分解：反应点 RP（发送端拥塞控制）、通知点 NP（接收端 CNP/ACK/NACK）、拥塞点 CP（交换机）。每次测试让被测设备（DUT）只扮演一个角色，用协议正确的 DPDK 端点模拟其余两个角色，从而把 DUT 从跨组件交互中隔离出来，把黑盒行为变成可检验的假设。为此它实现了三项能力：协议正确的白盒报文生成、事件注入（控制包与特定报文序列）、以及基于硬件时间戳的微秒级高精度测量；并用 O(1) 的 ICRC 快速路径、基于填充的包间隔控制等技术在单核实现 200Gbps 线速，可扩展至 400/800Gbps。整体遵循“症状→测试轨道→角色隔离回归测试→触发条件”的工作流。
Anytest 已在阿里云 RoCE 集群按需部署约一年，覆盖 4 款网卡与 6 款交换机，累计定位 58 起 NPA，其中 39 起（67.2%）由回归测试套件零人工直接定位，平均定位成本仅 3.1 人时，而此前单个复杂案例的绕行排查可达约 20 人天。它成功揭示了拥塞塌陷（固件 CNP 回复模式、隐藏令牌桶、丢包抑制 CNP）、PER_QP 定时器聚合导致的 incast 不公平、DCQCN 对间隔敏感、固件相关的拥塞控制差异等真实根因。核心启示是：可靠定位必须依赖角色隔离、微秒级分辨率与包级注入，配置并不等于语义、拥塞反馈本身也可能失效，都需以在线执行证据来验证。
image
image
论文下载地址：
https://dl.acm.org/doi/pdf/10.1145/3789240.3829125
3.Spillway: Orchestrating DPU and Host into a Unified vSwitching Fabric
现代云数据中心普遍依赖 DPU 卸载 vSwitch 转发功能，以降低主机侧资源开销、强化租户隔离。然而 DPU 的内存、CPU 等资源有限，硬件升级周期较长，严重制约了 vSwitch 所能支撑的 session 表容量、conntrack 流数和 CPS 性能。与此同时，AI 训推、NFV 等业务呈现出短连接突发、连接风暴等高度动态的流量特征，使得 DPU 资源更容易饱和，而主机侧算力却大量闲置、无法被利用。
为此，阿里云云网络团队提出了 Spillway —— 打破单节点内 DPU 与主机计算域之间的刚性边界，构建业界首个 DPU-Host 混合数据平面，实现 vSwitch 虚拟转发的平滑弹性扩展。当 DPU 资源使用饱和时，统一资源调度器在主机空闲 vCPU 上启动 Elastic VM 以运行 vSwitch 处理溢出流量，对租户和控制平面完全透明。流量调度采用 sketch 测量机制，结合 Top-K 策略只回注最具成本效益的流。在租户隔离方面，配合 pCPU 绑定、NUMA 优化、CAT/MBA 控制、用户态虚拟 ATC 等先进虚拟化技术规避了资源竞争，实现租户性能的强隔离。
Spillway 已在阿里云大规模部署超12个月，覆盖 3000 余台服务器，单节点CPS性能提升最高 90%，应对流量突发弹性扩容仅需 200 ms，比跨节点故障转移快了一个数量级，而对同节点其他租户的吞吐干扰不超过 1%。大规模生产部署验证了方案的实用性与经济价值，为 AI 时代云网络应对动态流量奠定了新底座。
论文下载地址：
https://dl.acm.org/doi/pdf/10.1145/3789240.3829154
4.From Nimitz to NetPila: The Evolution of Production-Scale Container Network
在大规模云容器服务中，容器网络需要同时满足弹性、性能与稳定性三重要求。阿里自 2019 年起构建的第一代容器网络 Nimitz 采用 VxLAN 实现"overlay–underlay"映射，在数千租户、数十种业务上稳定运行了五年。但随着 AI 训练与推理兴起，单租户容器规模突破 O(100K)，Nimitz 遭遇"C100K 问题"：VxLAN 映射表随容器数线性膨胀，单个 OVS 表项逼近 50 万条；一次 10% 扩容就要处理 15 万次同步请求；封装/解封装还带来约 5% 的吞吐与延迟开销，并引发 RoCE 性能抖动、节点冷启动与清理缓慢等一系列退化。根因在于 VxLAN 人为割裂了 overlay 与 underlay 两个地址空间，必须在全网维护并广播全局映射，这在超大规模下难以为继。
NetPila 的关键思路是彻底抛弃 VxLAN，用 IPv6 编码取而代之。它把 64 位节点地址、24 位租户 ID 与 40 位容器地址编码进单个 128 位 IPv6 地址，使容器地址成为物理网络地址的自然延伸。由此容器网络不再需要 overlay–underlay 映射表，也不再封装/解封装，报文处理表复杂度从 O（容器数）降至 O（本地容器数），全部表项可静态卸载到网卡硬件；集群更新也从全局广播退化为节点本地的点对点通信。针对 IPv6 暴露节点地址的隐私风险，NetPila 用对称密钥 AES-128 对 IP 做密文替换，并默认丢弃所有报文、逐条校验源与目的以实现租户隔离。
NetPila 已在生产环境部署超过两年，代表性部署含 9,205 节点、589,120 容器，评测覆盖多达 2.5 万节点的作业。在 2.5 万节点上完成 10% 扩容，耗时从 Nimitz 的 12.5 分钟降至 1.25 分钟，即便扩展到 10 万节点也仅需 5 分钟；RoCE 延迟最多降低 4.281%、带宽最多提升 6.055%；vLLM 推理的首 token 时延、每 token 时延与 token 间时延分别改善约 0.8%、0.669% 与 1.081%，且相较原生 IPv6 的开销可忽略。实践表明，现代大规模容器网络很少真正用到 VxLAN 的 IP 迁移、自定义子网等"灵活性"，简单反而带来更好的弹性、稳定与性能。
论文下载地址：
https://dl.acm.org/doi/pdf/10.1145/3789240.3829203
5.Rethinking Transparent TCP Replacement: Practical Lessons from SMC-R in the Cloud
随着云上网络带宽迈向 100Gbps+，Linux 内核 TCP/IP 协议栈的处理开销日益凸显，而应用大多基于 socket 接口开发，难以改造为 RDMA 原生接口。透明 TCP 替换技术让应用无需修改即可享受 RDMA 加速，相关研究多年活跃于学术界，却始终缺乏生产级规模落地。依托阿里云自研的核心网络技术 eRDMA，团队历时四年，将内核态 SMC-R 方案在真实业务场景中推广和打磨。
论文系统梳理了透明替换“难以即插即用”的深层原因：启用机制不灵活、应用对 Linux TCP 的隐性依赖、运维生态缺口、中间件干扰等，并给出工程化解法：基于 eBPF 的内核级启用机制与连接级管控策略，无需侵入租户镜像即可按需启停，相关补丁已贡献至 Linux 上游社区。论文还厘清了端到端性能收益的真实来源：协议栈自身提速仅数微秒，生产环境中普遍存在的非最优系统配置与应用行为才是差距的主因，而透明替换恰好绕开了这些短板。在贴近生产默认配置的实测中，SMC-R 将 Redis 请求延迟最高降低 70%，MySQL 吞吐量最高提升 52%。
论文下载地址：
https://dl.acm.org/doi/pdf/10.1145/3789240.3829194
欢迎留言一起参与讨论~
跳转微信打开
今日のまとめ
AIデイリーブリーフで今日の重要ニュースをまとめ読み