https://mpls.jp/2025/index.html ## IOWN APNを活用した分散データセンタ検証事例 張 暁晶(NTTドコモビジネス) - ドコモビシネスは約70箇所のDC - APN plusは1300回線以上 - Interop Tokyo 2025 ShowNet - IOWNユースケース - 遠隔経由でGPUクラスタを使う - 湘南アイパーク x IOWN - 製薬創薬研究で使うからセキュリティ要件が厳しい - Confidential Computingも組み合わせ - スマートシティ - 千歳市の自動運転バス実証実験 - 無人化して、バス外バス内のカメラを遠隔地へ映像をリアルタイム伝送 - 大阪万博 - 3D空間が伝送される体験 - 3Dメガネ - AI向けGPUインフラの要件と課題 - ラックあたりの電力密度 - 冷却能力 - 床荷重制限 - 事業継続災害復旧 - AIワークロードの継続性 - 巨大なAIデータセットやモデル - AIインフラ 総務省見解 - 地方分散しつつ、オール光 - 分散DC x IOWN - 首都圏へのDC一極集中 - AIによるGPUニーズ - GPU over APN - 分散配置 GPUクラウド - 処理量の変動に応じてオンデマンドGPUリソース確保 - 構成方法 - GPUサーバ同士を引き離し - GPUサーバとストレージを引き離してみる - アプリケーションからみると地理分散していることはわからない - 2DC 1DC leaf x spineでDC間をAPN接続 - AI学習 Training - 秋葉原 三鷹DC - APN 100Gbps 35km - 100?G Eth SW - GPUサーバ H100 x 2 - NVIDIA NeMo - LLM (tsuzumi 7B) - 処理時間 1stepあたりの時間 x 所定ステップ数 - 単一DC -> (分散DC)APN 1.005倍 - 3拠点？ - 分散DC (internet TCP) - ping RTT 0.526ms - Bandwidth 100GBS - RTT 15.0ms Band 300Mbps (tcで制限） - 8.36倍 - 距離を増やしたとき - (DC海外想定) vs DC（日本想定） - 100Gbps , 500km~3000km - 1.07倍 - 5.10倍 - ping RTT 30.6ms <> 50.6ms - AI推論 - H100 x 4来 x 3ノード - AIME - gemma3 27B 複数並列(8モデル) 多数決 - 分散DC(APN)は1.009倍 ? - 拠点間データ転送 - 遠隔ストレージ性能 - NFS obver RDMA - GPU Direct Storageベンチマーク gdsio READスループット - IOサイズを大きくしていくと分散DCが単一DCに接近するスループット - APNが遅れて立ち上がる - 小さいI.Oブロックでは遅い - MLPerf Storage - Unet 3Dモデル - NFS nconnect 100km距離で1.07倍 - 800G広帯域実証 - DC(武蔵野) <-> DC(秋葉原) - 800G-ZR - RDMA転送ツール - RDMA弱点は長距離伝送 - 接続の並列化 1回あたりのの転送データ量増加 - Send Queue を並列化 - 他方式（scp,rsync,nfs,mscp）より1/6へ - Q&A 100GBpsのうち、70-80GBps消費している ## 2. A study on accelerating LLM inference using KV cache sharing with IOWN APN 田仲 顕至 (NTT デバイスイノベーションセンタ) - OCP APAC Summit:25の発表内容の深堀り - なぜ分散DCか？ - AMDのキーノート GPU数年1.6倍増加 - 電力負担が高い - 送電 変電にも負荷がかかる - 印西市 電気足りない 送電ふやす 地下ケーブルで1.5倍にした - 集中型DCのみでは需要の速度に追いつけない - 小型DCを分散展開 - IOWN All-Photonics Network - KVキャッシュ - 永続ストレージに保存して他のGPUでも使い回す - ユーザー間キャッシュ共有 - Alibaba cloudだとCache hit.missで料金 - KVキャッシュ再利用率は、良いケースで6割 - KVキャッシュの前方一致 - ユーザ情報やメモリを含むシステムプロンプトがあるので、ユーザー間の共有は難しい - コンテキストを個別にキャッシュしても精度が落ちる - KVキャッシュ間の関係性には再計算が必要でコストがかかる。Prefillをフル計算したくない、CacheBlend (EuroSys'25) Decode, KVShare - 部分的にキャッシュを再計算 - 不定形入力でも共有率>50%が可能 - SCBenchでベンチマーク - CacheBlend -> LMCache - vLLMにおけるKVキャッシュマネージャーであったが、NVIDIA Dynamoからもサポート - llm-dも - KVキャッシュ圧縮転送 - 計算と通信のオーバラップ - NIXLとの連携 - NTT Early Adaptor - 初期検討：共有KVストレージ - NW帯域 7B-mistral - input 1k, KVキャッシュサイズ 120MB A100 - 10Gだと9割 TFTT改善 - 100Gだと - 検証２ APNをエミュレート - 文書のKVキャッシュ - Llma-3.1-8B - TTFT短縮効果は維持される - 電力効率もよくなる 道下さんから - ストレージ・ソリューションはなに？ - MoonCake?とかは使ってない - 普通のストレージ - Hot Spotが生まれる - TTFTテールが長い - CacheBlend -> シャーディングみたいな効果 -> TTFTテールが短くなるのでは？ - KVキャッシュをコールドなストレージ - どれぐらいの大きさで、どれぐらいのブロック - 入力トークン x モデルサイズ - KVキャッシュをどれぐらいのチャンクで書くかは、ハンドチューニング用 - CacheBlend的には細かいほうがいい - ストレージ側のキャッシュにどうのせるか？ - あるKVキャッシュがどこにあるかをどう検索するか？ - LMCache - Mooncacke 中央コントローラ - Dynamoも同じ - consistent hashingを使う ## 3. AIネットワークのボトルネックを打破する：JuniperによるAI ロードバランシングの革新 - 塚本 広海, Mahesh Subramaniam - (ジュニパーネットワークス) - HPEがjuniper買収 - AI/MLクラスター - 自動チューニング手法 - DCQCN -> ECN/PFC 送信タイミング - バッファ割当 - 負荷分散：フロー識別やflowテーブルサイズなど - JANOGでは銀の弾丸がないといわれる - Juniperではラボで机上で計算したり - Apstra - CI Cluster templateが最近実装された - GPUの数とかNIC帯域とか入力とかすると、Rails optimizerの構成を生成して、コンフィグも生成される - 可視化 - マイクロバーストとかの可視化 - Rail単位の可視化 - Apstra GPUエージェントをインストールするとNICの情報がとれる - PFC/tail dropはないがECN発生 - ECS遅くする - こういうのが自動化できる AutoTune - バッファの fill-levelも設定する - GPU側のOOS(out of sequence)を監視 - これをトリガーにinactivety_interbalを増加 - ロジックにAI/ML使えないかの議論はある - AI DC Software - RDMA-aware - QP分割してIPv6 addrつける - カラーリングして経路を選択できる。 - ECMPなしで決定論的なパスを選択できる。 - No ECS, No PFC, No OOS ## SRv6 uSID for AI Backend Network CISCO - MPLS Japan 6回 award - AIのbackendネットワークにSRv6 uSID - エレファントフローが大きい - Traditional ECMPでは難しい - AI Training Traffic - Long lasting - Low Entropy - Higly synchronized - Periodic - Bursty, maximum link capacity - Predictable! - IPV6 uSIDを用いたDetermionitsicにパスを選択 - GPUがe2eでパスをコントール可能 - SRv6の本質 - アプリケーションがnetwork programとしてe2eのパス制御 - Smart NICレベルでFB loopを高速に回せる - Ultra Scalable: SRv6ステートレス - Ultra Convergence: GPU(NIC)がSRV6パス切り替え可能 - uSIDがNICやスイッチを識別 - そのあとのロケーター情報をみて転送 - NICが経路上のuSIDたちを指定する - スイッチがパケットがなにかは無視して、ヘッダだけみて転送する - NIC側制御だけ - 障害ではNICがuSIDを変更することでパス切り替え - 検証結果がCISCOの著作権のみじゃない... - いい結果が得られている... - MSの事例 - Global topo managerがBGPでトポロジ情報もたせて、local topo mgrがNICに対して設定してあげる - sSwitch - 高度なCongestion Control - SRv6 Path Tracing - probeだしながらpathの可視化性 - これがCongestion Controlに有効なのでは？ - SONiCで実装 ## AIネットワークの可視性の提供 -CVP UNO(Universal Network Observability) - AIネットワークでなにが必要なのか？ - 症状の検出には優れているがRCAは手作業 - 自己診断ネットワーク - プロアクティブリスク分析 - CloudVision UNO - Realtime telemetry - コントローラを用意するのが大変 - ネットワークの観測性 - アプリケーションの発見 - 依存関係のマッピング - Metaの論文の障害分類 - EOS LANZ (latency Analyzer) - ASICの状況 - マイクロ秒でキュー混雑 - ボックスがマイクロバースをみる機構がないとだめ - CVaaS CV UNO - Jobとネットワークパフォーマンスの統合 - 相関分析 - EOS AIエージェント - ECMP cluster loadbalancing - QPごとに負荷分散できる - トラフィックの偏り 1. - 「AI時代のデータセンター」セッション - - AI-RANが実現するモバイルインフラの未来像 - 野崎 潔 - (ソフトバンク) - - データセンター排熱技術検討 - 杉田 正 - (エルエックススタイル) - - MUPアーキテクチャ - コンピューティングとモバイルアクセスの設計と実装 - 松嶋 聡 - (ソフトバンク) 1/10 1/12 1/17 1/24 17:04 原因特定 1/27 17:00 --- DynamoDBで internal DNS 100万個 遅延したモジュールが古いものでレコードを上書き 30-40台ぐらいdrain 空孔コアファイバ ライテラジャパン 武笠さん シリカガラス -> 空孔コアファイバ（中国は力をいれている） ほぼシリカガラスと空気の内部構造 ガンマ線とかあてても損失が少ないので、宇宙に持っていけるかも ファイバの融着ができない 遅延で制限されるとことを50%のばせる ファイバは損失が高いと、0.174。 アンチレゾナントファイバの損失、 CO2とか水分入っちゃうと長期間運用でどうなるかはまだわからない。 CO2とかなにも入らない状態であれば、2年ぐらいは損失が悪化しない。 水圧、 ファイバは中国から帰る？ 伝送実験としてはすごく良いパフォーマンスがでる。研究者とかはこれをやる。 UPS、発電機は中国から買っていいか？ 国の指針はないのか？ インフラを変える技術らしい そろそろ量産のフェーズなのでは？と 経産省