© SAKURA internet Inc. AIインフラを考える The 38th ISOC-JP Workshop 2025/09/26 ⼩林 正幸 

© SAKURA internet Inc. ⾃⼰紹介 ⼩林 正幸（Masayuki Kobayashi） さくらインターネット インフラエンジニア 担当業務： • ベアメタル型GPUクラウドサービス「⾼⽕⼒ PHY」のインフラ設計・構築 • 先端技術の調査・検証 略歴： • 2025-現在 さくらインターネット • 2017-2024 LINE → ヤフー → LINEヤフー • 2014-2017 IIJ 

© SAKURA internet Inc. Agenda •AIインフラを取り巻く状況と最新動向 •AIインフラを構成するインターネット基盤技術と課題 •分散学習から分散推論へのシフト •今後のAIインフラとエンジニアに必要なこと 

© SAKURA internet Inc. AIインフラを取り巻く状況と最新動向 

© SAKURA internet Inc. AIインフラ = LLM(⽣成AI)のためのインフラ •⽣成AIの需要を起点とする、インフラへの要求が激化している •現在のLLMは投⼊する計算資源とデータの量でモデルの精度が向上する（スケーリング則） •ハイパースケーラーを中⼼にAIインフラは巨⼤化の⼀途 計算量へ の需要 GPU性能向上 [PFLOPs] ネットワークへ の性能要求 密結合し たシステ ムの需要 消費電⼒増加 電⼒・冷却への要求 より多く のGPUを 集積可能 に “The Hot Chip is a Rack” (AI Literally Demands we Think Outside the Box) https://hc2025.hotchips.org/ Metaが発表したHyperion DCの規模 マンハッタン島との⽐較 

© SAKURA internet Inc. AIインフラを取り巻く状況 • LLMの分散学習では必要な計算資源の量が増加 • 複数のデータセンターで⼀つのモデルを学習する規模に • GPU間のスループットを要求する • 推論でも⼤規模なReasoningなどで分散推論の需要が増加 • より多くのメモリ容量が必要 (KV Cache Sharing等) • レイテンシ、TTFT削減 計算量へ の需要 GPU性能向上 [PFLOPs] ネットワークへ の性能要求 密結合し たシステ ムの需要 消費電⼒増加 電⼒・冷却への要求 より多く のGPUを 集積可能 に Computing Performanc e Deep dive into running DC network operations at scale IEEE HPSR 2025 https://hpsr2025.ieee-hpsr.org/ 

© SAKURA internet Inc. AIインフラを取り巻く状況 • パフォーマンスの限界は、単なるFLOPsではなく、 相互接続ネットワークによって決まる • 異なる3つのネットワークドメインでの最適化が進⾏中 • Scale Up (ラック内) → メモリ間のロードストア操作を超低遅延に • Scale Out (ラック間) → High-Radix, High-Bandwidth を追求 • Scale Outside (DC間) → ⻑距離・分散型AIクラスタ の実現 • Scale Up帯域 > Scale Out帯域 → 帯域の⾮対称性が課題 計算量へ の需要 GPU性能向上 [PFLOPs] ネットワークへ の性能要求 密結合し たシステ ムの需要 消費電⼒増加 電⼒・冷却への要求 より多く のGPUを 集積可能 に Network Throughput 

© SAKURA internet Inc. AIインフラを取り巻く状況 計算量へ の需要 GPU性能向上 [PFLOPs] ネットワークへ の性能要求 密結合し たシステ ムの需要 消費電⼒増加 電⼒・冷却への要求 より多く のGPUを 集積可能 に •計算機同⼠を可能な限り近くに配置・接続したい •GPUメモリを共有資源として扱い、 ラック全体をあたかも単⼀の巨⼤な計算機のように⾒せる •ラック内で 超低遅延・⾼帯域のインターコネクト規格 で GPU同⼠を相互接続 •ラックスケール（Scale Up）システムの台頭 • 銅線での接続から光インターコネクトへの転換期 • CPO（Co-Packged-Optics）スイッチの開発も本格化 NVIDIA Contributes NVIDIA GB200 NVL72 Designs to Open Compute Project https://developer.nvidia.com/blog/nvidia-contributes-nvidia-gb200-nvl72-designs-to-open-compute-project/ Scale Up System 

© SAKURA internet Inc. AIインフラを取り巻く状況 計算量へ の需要 GPU性能向上 [PFLOPs] ネットワークへ の性能要求 密結合し たシステ ムの需要 消費電⼒増加 電⼒・冷却への要求 より多く のGPUを 集積可能 に •GPUの消費電⼒は増加の⼀途 • NVIDIA B200 1,000W (単体) • ラックスケールシステムでは140kW程度 •直流給電へのシフトが加速 • 現在はDC48V給電(ORv3)ラックへの転換期 • ハイパースケーラーは1MW/ラックを想定した設計を推進中 • +/-400VDC, 800VDC給電 → Mt Diablo Project (OCP) • 電気⾃動⾞のサプライチェーンの活⽤ •冷却は⽔冷が前提 • 空冷でのサーバ集積率が限界に → ⽔冷化で⾼密度ラック化 • さくらインターネットでも⽔冷システムを運⽤中 • 今後はサーバーだけでなくネットワーク機器も⽔冷化の流れ Power & Cooling 

© SAKURA internet Inc. AIインフラを取り巻く状況 - Scale Up と Scale Out • Scale Up と Scale Out それぞれで新たな規格仕様が提案・実装されている • それぞれが、どの領域の何の課題をどのように解決しようとしているのかを正確に理解することが重要 • 詳しくは後半のセッションで Scale-Up Ethernet Framework Specification https://docs.broadcom.com/doc/scale-up-et hernet-framework Ultra Accelerator Link Specification https://ualinkconsortium.org/wp-content/uploads/20 25/04/UALink200_Specification_v1.0_Evaluation_Co py.pdf Ultra Ethernet Specification https://ultraethernet.org/wp-content/uploads/sites/2 0/2025/09/Updated-9.5.25-UE-Specification-1.0.1.p df Scale Out Scale Up 

© SAKURA internet Inc. AIインフラを取り巻く状況 - さくらインターネット さくらインターネット、コンテナ型データセンターの稼働を開始 〜ベアメタル型GPUクラウドサービス「⾼⽕⼒ PHY」にて、H200プランを提供開始〜 https://www.sakura.ad.jp/corporate/information/newsreleases/2025/06/11/1968219778/ さくらインターネットは、国内最速のサービス提供を⽬指して「NVIDIA B200 GPU」の整備を 推進しています https://note.com/sakura_pr/n/na49bb969e36e •コンテナ型データセンターで⽔冷GPUサーバを運⽤中 •短期間での導⼊と⽔冷による⾼密度化を実現 

© SAKURA internet Inc. AIインフラを取り巻く状況 - さくらインターネット SAKURAONE: Empowering Transparent and Open AI Platforms through Private-Sector HPC Investment in Japan https://arxiv.org/abs/2507.02124 • さくらONE • 202506のTOP500で49位 • インターコネクトにSONiC Ethernetなどオープンな技術を採⽤したシステム 

© SAKURA internet Inc. 我々はいま岐路に⽴っている • ハードウェアやソフトウェア・フレームワークなどが驚異的な速度で進化している • 設計したシステムが構築・運⽤開始される頃には次のチップアーキテクチャとその周辺技術が世界の主流になっている • 最先端のインフラが1年で陳腐化する世界で、数年単位で再利⽤可能な共通アーキテクチャを決められなくなった • 各要素技術の本質を⾒極め、⾃分たちにとって最適な選択が何なのかを先読みし判断できる力が必要 NICの速度 400G 🡪 800G 🡪 1.6T 接続規格・⽅式はどうなる？ Switch ASIC 51.2T 🡪 102.4T SerDesはどうなる？ サーバのフットプリント EIA or OCP 21インチにシフトするか？ スイッチの⽔冷化タイミング ⽔冷ならORv3 ⽔冷NWラックはどうする？ LLMのアーキテクチャ MoEが当たり前に インフラへの影響は？ ネットワークアーキテクチャ Resilience向上 Multi Plane構成にするか？ 分散推論の時代 どこまで必要？ 同じインフラで提供できる？ Scale Up NVLink vs Ethernet オープンな技術？ ⾼速ストレージ Converged構成の流れ どのように設計する？ Optical CPOの商⽤化が開始 いま必要なのか？ Symmetric memory GPUDirect Async Scale Upの設計に影響する？ GPU消費電⼒ 700W🡪1,000W🡪1,400W 設置可能なラック数は？ 互いに疎に⾒える要素が複雑な依存とトレードオフの関係にある 

© SAKURA internet Inc. AIインフラに求められること 

© SAKURA internet Inc. AIワークロードの性能に影響を与えるもの Parallelism 巨⼤なモデルをどのように複数のGPUに分割、 計算を並列化するか？ 集団通信、メモリセマンティック通信 Parallelismに応じたGPU間での効率的な演算通信や、 GPUを起点とするリモートメモリ操作 RDMA (Remote Direct Memory Access) CPUを介さずにリモートメモリへ直接読み書きする 最適なトランスポートは何か？ ロスレス制御 バッファの輻輳によるパケットロスをいかに防ぐのか？ 輻輳制御アルゴリズム どのようにRDMAデータの送信速度を調整するか？ バーストトラフィックへの対応 ロードバランシング 複数のパスでトラフィックを分散させるか？ RDMAパケットの順序をいかに保つのか？ ネットワークトポロジ最適化 性能を上げるためのネットワークトポロジとは？ サーバ内部を含めたデータパスは最適な状況か？ 

© SAKURA internet Inc. AIワークロードの性能に影響を与えるもの Parallelism • Data Parallel • Model Parallel (Pipeline, Tensor, Expert) • 3D Parallel (TP + PP + DP) 集団通信、メモリセマンティック通信 • xCCL • AllReduce = ReduceScatter + AllGather • All-to-All, SendRecv • NVSHMEM RDMA (Remote Direct Memory Access) • RoCEv2 (Ethernet) • InfiniBand ロスレス制御 • ECN • PFC 輻輳制御アルゴリズム • DCQCN (ECN-based) • ZTR-RTT CC (w/o ECN) ロードバランシング • RDMA-unaware LB (DLB, Scheduled Fabric) • RDMA-aware LB (QP Flow Pinning) ネットワークトポロジ最適化 • Scale Up: NVLink, PCIe • Scale Out: Rail-Optimized 

© SAKURA internet Inc. ニューラルネットワークと並列化戦略 (Parallelism) Parallelization Strategies in Neural Networks https://nwktimes.blogspot.com/2025/08/parallelization-strategies-in-neural.html 推論＝順伝播のみ 学習＝順伝播（推論）＋逆伝播（パラメータ更新） 活性化関数による⾮線形化 ⼊⼒と重みの計算 - 線形変換 損失=正解との距離 正解ラベル (教師あり) モデルの予測 (推論結果) これを逆伝播して重み・バイアスを更新するのが学習 • 各フェーズでどのような情報が交換されるのか、 何がボトルネックになるのかを知る • 並列処理のための正しいインフラを作るには アプリケーションの通信特性を理解することは不可⽋ 

© SAKURA internet Inc. ニューラルネットワークと並列化戦略 (Parallelism) • 単⼀のGPUメモリで処理しきれないモデルを複数のGPUにどのように分散・分割するのか • モデルアーキテクチャ、ユースケースの要件、ハードウェア構成などに応じて並列化⼿法を選択 • どの⽅式を使うにしても、基本的にGPU間を接続するネットワークが⾼速・低遅延であることが望まれる 並列化⽅式 内容 通信特性 主な通信ドメイン ボトルネック Data Parallel (DP) • モデルを複数のGPUに複製 • 基本的にはモデルがGPUに収まることが前提だが ZeROなどの最適化により⼤規模モデルにも適⽤可能 • All-Reduce • Scale Out • ノード間帯域 Pipeline Parallel (PP) • モデルを層で分割（NNを縦に切る） • 出⼒を次の層に伝搬 • Send/Recv (P2P) • Scale Out • ノード間帯域 • Pipeline Bubble Tensor Parallel (TP) • ⾏列演算を複数GPUに分割（NNを横に切る） • GPU間通信が完了するまで計算は完了しない • ReduceScatter or AllGather • Scale Up • Scale Out • ノード間帯域 • レイテンシ Expert Parallel (EP) • Mixture of Experts (MoE) モデルで利⽤ • ⼊⼒ごとにFFNのエキスパート層が異なり、 対応するGPUにルーティングする • all2all • Scale Out • ノード間帯域 3D Parallel (PP+TP +DP) • 各並列⽅式を階層的に組合せ⼤規模化 • 各⽅式に依存 • Scale Out • ノード間帯域 • Pipeline Bubble 基本的にネットワークが遅いと何をやっても遅い 

© SAKURA internet Inc. AIインフラ = 相互接続で性能が決まる •⾼帯域・低遅延・ロスレスが要求される • RDMA = Remote Direct Memory Access の通信性能を最⼤化するため •RDMAとは？ • リモートホストのメモリに直接アクセスする技術 •ロスレスとは何なのか？ • バッファの輻輳・競合によるパケットロスが起きない仕組み • ハードウェア障害で発⽣するパケットロスなど不可避なものは対象外 •どうやってロスレスを実現している？ • InfiniBandという専⽤のインターコネクト規格で実現 = 専⽤のハードウェアとトランスポートAPIが必要 • CBFC = Credit-based Flow Control という輻輳制御が根幹 • 宛先（受信側）のバッファに空きがあるかどうかを確認してから送信するため輻輳が起きない これらをコモディティな実装(Ethernet)で実現したい 

© SAKURA internet Inc. なぜEthernetなのか？ •コスト • コモディティな製品は市場で競争原理が働く •マルチテナンシー • クラウドサービスで提供するためには必須 • ネットワークをテナントごとに柔軟に分離したい •Ethernetでも性能を⼗分に出せるようになった • IBのほうが僅かに低遅延ではあるが、スループットに⼤差はない • 特定⽤途のHPCクラスタなどを除いてIBを選択する理由がなくなった •技術がオープンであること • ⾃分たちの要件と環境に合わせた技術・製品選定ができること • 誰もが議論に参加できる（インターネットの精神） RDMA over Commodity Ethernet at Scale https://www.microsoft.com/en-us/research/wp-content/uploads /2016/11/rdma_sigcomm2016.pdf 

© SAKURA internet Inc. RDMA over (Converged|Commodity) Ethernet •RoCEv2 = RDMA over Converged Ethernet (ロッキー) •InfiniBandのトランスポート(L4)をUDP/IPでカプセル化してEthernet上で転送 •ネットワークを正しく “converged” させるためには InfiniBandの仕様(IBA)を理解する必要がある IB BTH (L4 Header) IB Payload UDP Header IP Header Ethernet Header ICRC FCS IBA packet RoCEv2 5-tuple entropy RDMA Message Queue Pair Information 

© SAKURA internet Inc. RDMA over (Converged|Commodity) Ethernet RDMA Write Message Size < PMTU IB BTH (L4 Header) IB RETH (Extended Header) IB Payload UDP Header IP Header Ethernet Header ICRC FCS RDMA Write Only • 拡張ヘッダ(RETH)に宛先リモートメモリの仮想アドレスが格納されている • フラグメントが不要なメッセージは単一のRDMA Write Onlyとして完結する OpCode: 01010b 

© SAKURA internet Inc. RDMA over (Converged|Commodity) Ethernet RDMA Write Message Size > PMTU IB BTH (L4 Header) IB RETH (Extended Header) IB Payload UDP Header IP Header Ethernet Header ICRC FCS IB BTH (L4 Header) IB Payload UDP Header IP Header Ethernet Header ICRC FCS IB BTH (L4 Header) IB Payload UDP Header IP Header Ethernet Header ICRC FCS RDMA Write First RDMA Write Middle RDMA Write Last • PMTUを超えるメッセージはフラグメントされる • 宛先リモートメモリの仮想アドレス（書き込み先）は先頭のパケットにのみ拡張ヘッダとして付与 • 後続のパケットが先に届くことは許容していない • “IBA does not support selective packet retransmission nor the out-of-order reception of packets.” OpCode: 00110b OpCode: 00111b OpCode: 01000b 

© SAKURA internet Inc. RDMA over (Converged|Commodity) Ethernet RDMA Write Message Size > PMTU IB BTH (L4 Header) IB RETH (Extended Header) IB Payload UDP Header IP Header Ethernet Header ICRC FCS • PMTUを超えるメッセージをRDMA Write Onlyにフラグメントすればよいのでは？ • すべてのパケットに拡張ヘッダ（宛先メモリアドレス）を付与する → これはIBA仕様規定外動作 • パケットの受信順序が逆転しても書き込める → 途中経路でパケットスプレーによる分散が可能 • 特定のファームウェアでこれを設定可能にしていたRNICもあった（現在の最新版では不可） IB BTH (L4 Header) IB RETH (Extended Header) IB Payload UDP Header IP Header Ethernet Header ICRC FCS IB BTH (L4 Header) IB RETH (Extended Header) IB Payload UDP Header IP Header Ethernet Header ICRC FCS RDMA Write Only RDMA Write Only RDMA Write Only OpCode: 01010b OpCode: 01010b OpCode: 01010b • このままでは完了通知つき転送（ RDMA_WRITE_WITH_IMM ）に対応できないため、ゼロ⻑の RDMA_WRITE_WITH_IMM を最後に送るなどの実装の⼯夫が必要になる • このすべてのパケットに宛先アドレス情報を付与するという動作は、RoCEv2に代わる新しいAIワークロード向けのEthernetベース技術のトランスポートでも採⽤されている 

© SAKURA internet Inc. RDMA over (Converged|Commodity) Ethernet RoCEv2_Packet_Walk_Through_Cheat_Sheet_1755351206 https://www.linkedin.com/posts/zeeshan-sabri-4497256_rocev2-packet-walk-through-cheat-sheet-activity-7362287966678892544-_XU3 

© SAKURA internet Inc. RDMA over (Converged|Commodity) Ethernet •現在のAI/MLネットワークで主流のRoCEv2は、要素技術に特別新しいものは使っていない •歴史のあるインターネット標準技術を組み合わせているに過ぎない •ECN (Explicit congestion Notification) •RFC3168 •PFC (Priority-based Flow Control) •IEEE 802.1Qbb •ETS (Enhanced Transmission Selection) •IEEE 802.1Qaz •これらを組み合わせてEthernet上でAIワークロードのトラフィックを処理している 現在の要求の激しいAIワークロードに最適とは⾔い難い 反応速度・回復⼒・可視性 に課題がある 

© SAKURA internet Inc. ECN運⽤の難しさ Reaction Point Congestion Point Notification Point 輻輳 ECN-Capable Transport bit “01” or “10” Congestion Experienced bit “11” CNP (Congestion Notification Packet) “01” 送信速度調整 送信速度回復 • ECN 2bitを利用してスイッチの輻輳を宛先に通知する • 宛先ノードから CNP が返ってきたらそのQPの送信レートを調整 • CNPはペイロードを持たないヘッダのみのackパケット • 輻輳に反応するまでの時間が長い • どこで輻輳したかわからない • マーキング閾値の設定がよくわからない • {min,max}-threshold の値の根拠は？ • max-mark-probability の値は100じゃないとだめ？ • デフォルト値で運用になりがち = 問題が起きてから調整 

© SAKURA internet Inc. ECN運⽤の難しさ Reaction Point Congestion Point Notification Point 輻輳 ECN-Capable Transport bit “01” or “10” Congestion Experienced bit “11” CNP (Congestion Notification Packet) “01” 送信速度調整 Reaction Point Congestion Point Notification Point 輻輳 ECN-Capable Transport bit “01” or “10” CNP (Congestion Notification Packet) “01” 送信速度調整 • 輻輳に早く反応したいなら、これでも良いのでは？ • CNPは単なるBTHだけのackなので、QPの情報だけ読み取ればスイッチでCNPを⽣成・送信できるはず？ 

© SAKURA internet Inc. ECN運⽤の難しさ Reaction Point Congestion Point Notification Point 輻輳 ECN-Capable Transport bit “01” or “10” Congestion Experienced bit “11” CNP (Congestion Notification Packet) “01” 送信速度調整 Reaction Point Congestion Point Notification Point 輻輳 ECN-Capable Transport bit “01” or “10” CNP (Congestion Notification Packet) “01” 送信速度調整 • 送信元QPの情報はBTHには含まれないので、スイッチが一意にコンテキストを特定できない。。 • 「送信元と宛先の情報は常に同一ヘッダ内に存在する」というIPネットワークの常識とは異なる Fast Congestion Notification Packet (CNP) in RoCEv2 Networks https://datatracker.ietf.org/doc/draft-xiao-rtgwg-rocev2-fast-cnp/ CNPには送信元のQPが輻輳対象のQP(Dest QP)として格納されるが スイッチはその情報をヘッダから読むことができない(BTHに無いため) 

© SAKURA internet Inc. サイレントドロップの課題 ‒ Drop Notification • パケットがどこで輻輳・破棄されたのか知りたい → 再送要求のトリガーを高速化 • 最近は輻輳で破棄されるパケットのヘッダ部分をトリミングして通知する仕組みがある（未検証） • ペイロード部分を落として別の優先キューから、DSCP値を輻輳発生場所に応じた値に書き換えて送信 • 受信側NICには「Trimmed Packet」と理解して再送制御を起動するロジックが新たに必要 • 従来のEthernetの受信処理実装だけでは対応できないため、対応する NICが必要になる Original Packet L2 Header L3 Header Payload DSCP=1 Switch Congestion Point Ingress Port Egress Port Trimmed Packet L2 Header L3 Header DSCP=5 Q6 Q3 DCN Header Trimmed 

© SAKURA internet Inc. PFC運⽤の難しさ • 同⼀DCルーム内の均⼀で限定的な接続範囲(ケーブル⻑50m未満)ではデフォルト値で問題にならない • しかし、物理的制約のあるコンテナDCを運⽤している我々の環境では、AIインフラに必要なシステムが 異なる場所に分散して設置されることもある • このようなケースでパフォーマンスを最⼤化するためのチューニングをしなければならない • 回線帯域と正確な線路⻑、利⽤するSwitch ASIC固有の仕様のパラメータから計算する • 距離の測定やトポロジの認識を⾃動で⾏い最適値を動的に適⽤する実装が望ましく、⻑距離RDMAの観点では PFCが問題にならないようなジョブスケジューリングやトランスポート制御をソフトウェア側で⾏えると理想 Container DC GPU Farm Cable Length < 50m Cable Length < 50m Cable Length > 300m Building DC Storage Farm 

© SAKURA internet Inc. PFC/ECNの運⽤課題 • 様々な要件や制約の下で設計される実際の現場のネットワークは、机上の理想通りにはならない • すべての機器とポートに適⽤可能な共通の万能プロファイルはない • ベンダーデフォルト値やすべて同じ設定で運⽤すると深刻なPerformance Issueになることもある Shallow Buffer Switch Deep Buffer Switch RDMA Server RDMA Server C B A A~Cで適切なバッファプロファイルは異なる 

© SAKURA internet Inc. ロードバランシングの課題 RDMA-unaware LB RDMA-aware LB ⽅式 Pure ECMP DLB/GLB (flowlet) Scheduled Fabric Enhanced Ethernet Flow Pinning フローの識別⽅法 5-tuple 5-tuple Flow-agnostic Flow-agnostic Queue Pair 分散要素 ECMP Hash リンク使⽤率 Packet / Cell 単位 Packet単位 QP Flow単位 NIC側のサポート 不要 不要 不要 必要 ⼀部必要 リオーダー なし なし あり (スイッチ側) あり (NIC側) なし • RoCEv2はエントロピーの少ないフローが⽀配的、通常のL3 ECMP+ハッシュでの分散が困難 • 各社から様々なロードバランシング⽅式やその関連技術が提案・実装されている（⾞輪の再発明？） • エントロピーを増やす vs どこにリオーダーのインテリジェンスを置くか • ⾃社でGPUクラスタのワークロードを予測・制御できるようなインフラなら選択肢は豊富 • ベアメタルプランを提供する側としては、スイッチでインテリジェンスが完結すると運⽤しやすい • NICと連携した動作設定や細かなパラメータチューニングの負荷が⾼い • 細かいパラメータはデフォルト値で運⽤になりがち = 問題が起きてから調整 

© SAKURA internet Inc. トポロジの最適化課題 ‒ Scale Out Topology NIC NIC NIC NIC NIC NIC NIC NIC GPU GPU GPU GPU GPU GPU GPU GPU Scale Up Interconnect NIC NIC NIC NIC NIC NIC NIC NIC GPU GPU GPU GPU GPU GPU GPU GPU Scale Up Interconnect Leaf Leaf Leaf Leaf Leaf Leaf Leaf Leaf Leaf Leaf Leaf Leaf Leaf Leaf Leaf Leaf Spine Spine Spine Spine Spine Spine Spine Spine Plane A Plane B • 市場に供給されているNICの速度は800Gに到達、すでに1.6Tも⾒えている • NICの速度に合わせてスイッチ単体の転送容量もスケールアップさせていくのか？ (51.2T → 102.4T) • 102.4T Switch ASICからはスイッチの⽔冷化を考える必要がある = 空冷ではフットプリントが増加(最低3RU) • 800G以降、NICに複数のMPOケーブルを接続する前提なら、マルチプレーン構成の選択肢が⽣まれる • ⽚⽅のプレーンに問題があっても、もう⼀⽅のプレーンで計算を継続する選択肢がある → Resilience向上 • 既存の転送容量のスイッチ(空冷)でスケールアウトできる = 台数の増加に伴う運⽤負荷とトレードオフ Single Plane 102.4T Switch Fabric 51.2T Switch Fabric 51.2T Switch Fabric 1x800Gbps 2x400Gbps Rail-Optimized Topology Multi-Plane Multi-Rail Optimized Topology 

© SAKURA internet Inc. トポロジの最適化課題 ‒ Scale Up Topology DPUで外部ストレージと通信する場合、この構成のサーバでは GPUDirect RDMA ができない • Scale Upドメインのトポロジがどのようになっているのかを正しく理解する • サーバのブロックダイアグラムからボトルネックになりうる箇所を読み解けることが求められる この構成のサーバなら GPUDirect RDMA ができる 

© SAKURA internet Inc. そして分散推論の時代へ 

© SAKURA internet Inc. 最近の推論を取り巻く状況 • リクエスト（ユーザーの⼊⼒）の多様化と複雑化 • ⼊⼒の⻑さもリクエストごとにばらつきが⼤きくなっている • Reasoningの普及により、⼊⼒コンテキスト⻑のばらつきがより顕著になってきた • TTFT, ITL などユーザーの体験に影響するメトリクスとその要因を意識する必要性が⾼まった • スケール・性能の限界 • 単純にモデルが⼤きく、単⼀のGPUやノードでは処理しきれなくなっている • ⼤規模になるとGPUのメモリ(HBM)が⾜らない • GPUのメモリにはモデルだけでなく途中の計算結果(activations)なども格納される • 近年のLLMではMixture-of-Experts（MoE）と呼ばれるアーキテクチャを採⽤していることが多く 性能が良い⼀⽅で、このアーキテクチャのモデルは単⼀ノードに乗せることが難しい 分散学習だけでなく、推論も分散処理で⼤規模化する兆しが⾒え始めている 

© SAKURA internet Inc. LLMの推論とは - ⾃⼰回帰モデル（Autoregressive） • LLMによるトークン⽣成はユーザ⼊⼒を元に、モデルが次の単語を予測し⽣成する • さらにその⽣成したトークンを系列の末尾に加え、再度次のトークンの予測計算を⾃⼰回帰的に⾏う • 推論時のSelf-Attention（単語間の関連度）の計算は、新しいトークン以外はただの再計算になる • 計算結果をキャッシュすれば、以降の計算で使いまわすことで計算量を減らせるのでは？ • これが KV Cache と呼ばれるもの • さらに、推論時に「キャッシュを⽣成する段階」と「キャッシュを使い回す段階」を区別すれば効率的？ • これが Prefill と Decode と呼ばれるもの LLM Iteration 1 LLM Iteration 2 KV Cache Exactl y, LLM Iteration 3 KV Cache it LLM Iteration 4 KV Cache is. Is this a KV Cache? EOS Prefill ‒ Prompt phase Compute Bound Decode ‒ Token generation phase Memory Bound 

© SAKURA internet Inc. LLMの推論とは ‒ Prefill / Decode • 推論は Prefill と Decode と呼ばれる異なる2つのステップから構成される • Prefill • ユーザーの⼊⼒をトークン化、⼊⼒トークンを処理し、最初の出⼒トークンを⽣成するフェーズ • 同時にKV Cacheも⽣成 • 初回のAttention演算はスキップできないため、⾏列演算が主要な処理 • Compute Boundなフェーズ • Decode • 直前のトークンを系列に加え、後続の出⼒を⽣成していくフェーズ • 新規のトークンに対して、KV Cacheを更新 • KV Cacheによる計算結果の再利⽤ができるため計算処理は重くないが、KV Cacheのメモリ操作に時間がかかる • Memory Boundなフェーズ 

© SAKURA internet Inc. PD Disaggregation ‒ KV Cache Sharing • Prefill と Decode を別々のWorker(GPU)に分離する • PD Disaggregation • 処理特性の異なるボトルネックを分離し、それぞれで効率化する • ⼀⽅で、新たな課題も⽣まれる • KV CacheをどのようにWorker間で共有するのか？ → KV Cache Sharing • どのようにリクエストをルーティングするか？ → やりたいことは 「キャッシュに当てる」 それだけ • KV Cacheのサイズと転送に必要なネットワーク性能はどの程度なのか？ → 推論でもネットワークがボトルネックに？ DistServe: Disaggregating Prefill and Decoding for Goodput-optimized Large Language Model Serving https://arxiv.org/pdf/2401.09670v1 https://www.nvidia.com/ja-jp/on-demand/session/gtc25-s73042/ 

© SAKURA internet Inc. KV Cache サイズとデータ転送の⾒積もり パラメータ 説明 2 • KとVの両⽅を保存するための係数 • Attentionでは Query, Key, Value が使われるが、 推論時にキャッシュされるのは過去の Key と Value n_layers • Transformerモデルの中間層の数 • 各層ごとにK/Vを保存するので層数分メモリが増える n_heads • K/Vを持つMulti-Head Attentionのヘッド数 head_dim • 各ヘッドが持つ次元数 • ヘッド数と掛けることで、1トークンあたりのKまたはVの埋め込みベクトルの次元数になる seq_len • 処理するトークン数（コンテキスト⻑） • トークン数が2倍になればキャッシュも2倍必要になる precision_bytes • FP8, FP16などの精度 • 落とせばメモリ使⽤量は減る batch • 同時処理するリクエスト数 • 推論時に保持するKV Cacheのメモリ使⽤量 （1リクエストあたり） • KV Cache Size = 2 × n_layers × (n_heads × head_dim) × seq_len × precision_bytes × batch • Multi-Head Attention (MHA) 構造の場合の式 

© SAKURA internet Inc. KV Cache サイズとデータ転送の⾒積もり パラメータ 値 2 2 n_layers 32 n_heads 32 head_dim 128 seq_len 4096 precision_bytes 2 Byte (FP16) batch 1 • 推論時に保持するKV Cacheのメモリ使⽤量 （1リクエストあたり） • KV Cache Size = 2 × n_layers × (n_heads × head_dim) × seq_len × precision_bytes × batch • Multi-Head Attention (MHA) 構造の場合の式 Llama-2-7Bを参考に4Kトークンの⼊⼒を想定すると KV Cache Size = 2 × 32 × (32 x 128) × 4096 × 2 × 1 ≈ 2.0GB 

© SAKURA internet Inc. KV Cache サイズとデータ転送の⾒積もり フェーズ 累積tokens KV Cache サイズ 初期からの増加量 prefill 512 250.0MB 初期のためなし 1st token 513 (+1) 250.5MB (+512KB) +512KB 256th token 768 375MB +128MB 512th token 1,024 500MB +256MB 1,024th token 1,536 750MB +512MB 2,048th token 2,560 1,250MB +1,024MB • MHA構造の7B LLMで推論時に保持するKV Cacheのメモリ使⽤量 （1リクエストあたり） • 初期⼊⼒: 512 tokens, ⽬標出⼒: 2,048 tokens のチャットボットを想定（短⼊⼒ → ⻑出⼒） • 512 tokens ≈ ⽇本語テキストで750字程度の⼊⼒に対して、 2,048 tokens ≈ 3,000字程度の出⼒ • 1トークン増えたときの増分は seq_len が +1 されるだけ パラメータ 値 2 2 n_layers 32 n_heads 32 head_dim 128 precision_bytes 2 Byte (FP16) batch 1 • PD Disaggregationしている場合、この250MBを転送する必要がある • このサイズならまだ余裕？ • これは1リクエストあたりの転送量 

© SAKURA internet Inc. KV Cache サイズとデータ転送の⾒積もり フェーズ 累積tokens KV Cache サイズ 初期からの増加量 prefill 8,192 4.0000GB 初期のためなし 1st token 8,193 (+1) 4.0005GB (+512KB) +512KB 128th token 8,320 4.0625GB +64MB 256th token 8,448 4.125GB +128MB 512th token 8,704 4.25GB +256MB • MHA構造の7B LLMで推論時に保持するKV Cacheのメモリ使⽤量 （1リクエストあたり） • 初期⼊⼒: 8,192 tokens, ⽬標出⼒: 512 tokens の⽂書要約を想定（⻑⼊⼒ → 短出⼒） • 線形増加率（KB/token）は同じ、1トークンごとに何byte増えるかはモデル構造と精度で決まり、⼊⼒の⻑さとは無関係 • ⼊⼒可能なコンテキスト⻑を8,192まで拡張していると仮定 パラメータ 値 2 2 n_layers 32 n_heads 32 head_dim 128 precision_bytes 2 Byte (FP16) batch 1 • PD Disaggregationしている場合、この4GBを転送する必要がある • これも1リクエストあたりの転送量 

© SAKURA internet Inc. KV Cache サイズとデータ転送の⾒積もり 8B llama3 405B llama3 KV Cache サイズ n_layers 32 126 n_heads 8 8 head_dim 128 128 KV Cache / layer = 2 × (n_heads × head_dim) × 2 [FP16] 4,096 4,096 ⼊⼒トークン数 = 1K KV Cache size [GB] 0.13 0.53 ⼊⼒トークン数 = 8K KV Cache size [GB] 1.0 4.2 ⼊⼒トークン数 8K x 同時接続リクエスト数 100 KV Cache size [GB] 100 420 KV Cache 転送時間 100 Gbps = 12.5GB/s 8,000ms = 8s 33,600ms = 33.6s 400 Gbps = 50GB/s 2,000ms = 2s 8,400ms = 8.4s 800 Gbps = 100GB/s 1,000ms = 1s 4,200ms = 4.2s このKV Cache転送にかかる時間がユーザー体験を悪化させるが、 ユーザーの⼊⼒の傾向次第でシステムにかかる負荷が変わるのがインフラ設計上難しいポイント KV Cache Size Calculator を利⽤して算出 https://lmcache.ai/kv_cache_calculator.html 

© SAKURA internet Inc. KV Cache サイズと同時リクエスト数の⾒積もり シーケンス⻑ 単体メモリ使⽤量 同時接続可能数 1K トークン 0.125 GB 512 リクエスト 2K トークン 0.25 GB 256 リクエスト 4K トークン 0.5 GB 128 リクエスト 8K トークン 1.0 GB 64 リクエスト 16K トークン 2.0 GB 32 リクエスト 32K トークン 4.0 GB 16 リクエスト モデル例: 8B llama3 GPUメモリ: NVIDIA H100 80GB モデル容量: 16GB 利⽤可能メモリ: 64GB • すべてのリクエストが同⼀シーケンス⻑だと仮定し、単⼀GPUで処理可能なリクエスト数を試算 • モデルをロードした後のGPUメモリで、どの程度の推論リクエストが同時接続可能か • モデルによって入力可能コンテキスト数の上限があることに注意 • 以下はわかりやすさを優先し単純化した例です 

© SAKURA internet Inc. KV Cache をどのネットワークで転送するか • ここで「Scale Up Network」と「Scale Out Network」をどう使うかが重要になる • KV Cacheの転送でパフォーマンスが落ちていては話にならない • ⾼速かつ低遅延に転送するためには Scale UP を利⽤する • サーバのレイアウトやインフラ構成によって選択できる経路が変わる → どこがボトルネックになるか知っておく ドメイン インターコネクト規格 最⼤伝送速度（1GPUあたり） 備考 Scale Up PCIe Gen5 64GB/s (x16, 単⼀⽅向) 1レーンあたり4GB/s PCIe Gen6 128GB/s (x16,単⼀⽅向) 1レーンあたり8GB/s NVLink 4.0 450GB/s (18Link,単⼀⽅向) Hopper 1リンクあたり25GB/s NVLink 5.0 900GB/s (18Link,単⼀⽅向) Blackwell 1リンクあたり50GB/s Scale Out 400G NIC/DPU 50GB/s (双⽅向) ConnectX-7 / BlueField-3 800G NIC 100GB/s (双⽅向) ConnectX-8 

© SAKURA internet Inc. KV Cache の置き場所と管理をどうするか • HBMに乗らなくなったらどうする？ • 外部のメモリ（ストレージ）にオフロードすることも考えられている • HBM < ホストメモリ < ローカルストレージ(SSD) < 共有ストレージ(GPUDirect RDMA) の順に遅い • 遅いストレージに聞きに⾏くのはコスト効率が悪いので、そこまでやるのかは個⼈的に疑問 • KV Cache⽤に共有メモリプールを⽤意して⾼速に接続しようという取り組みをしているスタートアップ企業もある • 最適なトランスポートの選択やキャッシュ管理をどうするか？ • NIXL: NVIDIA Inference Xfer Library (ニクセル) の登場 • https://github.com/ai-dynamo/nixl • NCCLを補完する通信ライブラリでKV Cache転送をサポートする • トポロジや利⽤可能なメモリストアなどをうまく判断し、最適なトランスポート（RoCE、NVLink ...etc）を選択 • スケジューリングやデータ転送まで含めて管理にする分散推論フレームワークも登場している ⾃分たちのインフラに合った最適化⼿法を検証・適⽤する必要がある 

© SAKURA internet Inc. まとめ 

© SAKURA internet Inc. AIインフラの設計・運⽤に必要なこと • インフラからモデルアーキテクチャに⾄るまでの幅広い知識と経験 • データパスのどこに問題があるのかを特定するための知識・経験・スキルが必要 • ワークロードがハードウェアトポロジに正しくバインドされることが重要 • アプリケーションはハードウェアを適切に使えるようになっているか？ • サーバとネットワーク機器の設定はそのインフラの⽬的に合っているか？ • アプリケーションとハードウェアが協調して最⼤パフォーマンスを発揮するということの理解 • 誰かのリファレンスアーキテクチャ(Validated Design)はあなたのベストアーキテクチャではない • どの程度のコストを払えば、ユーザにとって「何が」・「どれくらい」改善されるかという⼤局的な視座と感覚 • よくある「何故かパフォーマンスが出ない」という問い • 例) GPU間通信が遅い / ストレージとのデータ転送が遅い / なんかいつもと違う / こんなはずじゃない 正しいインフラはアプリケーションへの正しい理解の上で成り⽴つ 

© SAKURA internet Inc. これからに向けての個⼈のお気持ち • 特定の技術ドメインや専⾨領域だけに閉じた問題解決や最適化ができなくなりつつある • アプリケーションとインフラに明確に線を引くと、良いものが作れない • 特に現在のAIインフラの技術動向を⾒ると、垂直統合システムへの揺り戻しが来ていると感じている • ソフトウェアとハードウェアを⼀つのコンピューティングシステムとして⾒る • ただ、エンジニアの期待として採⽤する技術はオープンなものであってほしい • 昨今注⽬度が⾼まっているAIのための各種最新技術はオープンなのか？ • 開かれたメーリングリストで誰でも質問・議論ができる？ • “specification”という名のマーケティングでは困る • 本当に必要なものを⾒極める必要がある • ハイパースケーラーを中⼼に作られたものは、どうしても課題設定が⼤きくなる傾向にある • ⼩規模事業者の我々には First World Problems なものもあるので、本質的な課題を⾒失わないようにしたい • その技術が、我々の何の課題を解決し、どのような利益をもたらすのか、トレードオフが何か 

© SAKURA internet Inc. 参考情報 • Hot Chips 2025 • Hot Interconnects 2025 • 2025 OCP APAC Summit • NVIDIA Contributes NVIDIA GB200 NVL72 Designs to Open Compute Project • SAKURAONE: Empowering Transparent and Open AI Platforms through Private-Sector HPC Investment in Japan • Parallelization Strategies in Neural Networks • RDMA over Commodity Ethernet at Scale • RDMA over Converged Ethernet v2 (RoCEv2) Cheat Sheet • Fast Congestion Notification Packet (CNP) in RoCEv2 Networks • KV Cache Size Calculator • DistServe: Disaggregating Prefill and Decoding for Goodput-optimized Large Language Model Serving • Introducing NVIDIA Dynamo: A Distributed Inference Serving Framework for Reasoning models • NVIDIA Inference Xfer Library (NIXL) • Distributed Inference Serving - vLLM, LMCache, NIXL and llm-d Special Thanks!! さくらインターネット 道下さん