TT Lab
ブログ

한국어 English 日本語 中文

はじめる
ブログ

ブログ

RDMAとNCCLで読むGPUネットワーク: InfiniBand、RoCE、Kubernetes配置

2026-10-07 · 41 分で読めます · #RDMA#InfiniBand#RoCE#NCCL#GPUDirect#NVLink#쿠버네티스#NetworkOperator#토스 ML/AI Infra 준비

状態: ドラフト (2026-10-06更新)。 公式ドキュメントで確認した記述がベースであり、 ソフトウェアRoCE(rxe)で直接確認した部分(第10節の末尾の「実測」)のみ 使い捨て仮想マシンで測定した値です。実際のRDMAハードウェアとGPUを使用した測定はありません。 記事の末尾の「確認したバージョンと日付」と「確認できなかったこと」を先にお読みください。 作成ルール: 実測データが基本であり、測定できなかったものは「未実測」と表示します。

目次

要約

複数のGPUが一つのモデルを共同で計算する場合、通信がそのまま性能に直結します。サーバー内ではNVLinkが、サーバー間ではRDMA(Remote Direct Memory Access)をサポートするInfiniBandやRoCE(RDMA over Converged Ethernet)ネットワークがこの役割を担い、NCCL(NVIDIA Collective Communications Library)はこのレイヤーを検知して集合通信(all-reduceなど)を配置します。この記事では、レイヤー別の帯域幅の違い、RoCEが難しい理由、NCCLの環境変数と測定ツール、障害診断の順序、Kubernetesの構成について取り上げます。

この記事を読むことで面接で説明できるようになること

  1. TCPでは不十分な理由と、InfiniBandとRoCE v2の違い(特にRoCEにおけるPFC、ECNの役割と設定が間違っている場合の症状)。
  2. NCCLが集合通信をどのように実行するか、 nccl-tests のbusbwをどのように読み取るか、マルチノードの性能が低下したときのチェック順序。
  3. KubernetesでポッドがRDMAを使用するために必要な構成要素と、推論でRDMAが必要となるポイント(KV転送、Tensor Parallelism、モデルロード)。

執筆者の立ち位置。 私は一般イーサネット(1〜2.5GbE級)環境で実験を行っており、RDMA、InfiniBand、NVLink、VASTの経験はありません。この記事は公式ドキュメントを読んでまとめたものであり、運用経験談ではありません。実際に試すことは可能な範囲に限定しており、実行していないものはその旨を表示しています。

1. なぜTCPでは不十分なのか

Dynamoのドキュメントによると、RDMAはネットワークアダプターが1つのホストのメモリから別のホストのメモリへと(GPUDirect RDMAを使用する場合はGPUからGPUへ)CPU、カーネル、TCP/IPスタックを経由せずにデータを移動させます。一般的にTCPには、ユーザーバッファとカーネルバッファ間のコピー、システムコール、割り込みが伴います。RDMAはあらかじめ登録(ibv_reg_mr)してページを固定(pin)しておいたメモリをNICが直接読み書きするため、カーネルバイパス(kernel bypass)とゼロコピー(zero-copy)が可能になります。速度の差も算術的に大きいです。1GbEは0.125GB/s、400Gb/s NICは50GB/sであり、400倍です。そのためTCPは、RDMAがない場合の代替経路になります(NCCL_IB_DISABLE=1 の場合はNCCLがIPソケットにフォールバックします)。

2. InfiniBandとRoCE v2

項目 InfiniBand RoCE v2
ネットワーク RDMA専用ネットワーク 一般イーサネットスイッチ上で動作
プロトコル 独自トランスポート層 UDP/IP宛先ポート4791上で動作し、L3ルーティングが可能
管理 サブネットマネージャー(SM)が必要 PFC、ECN、DSCPなどイーサネットの設定が核心
診断 ibstat, perfquery, ibdiagnet, sminfo ethtool -S, スイッチカウンター, rping

RoCE v1はイーサネットリンク層のみを使用する単一のブロードキャストドメイン用であり、v2がUDP/IPを載せることでルーティングが可能になります(Wikipedia)。

RoCEが難しい理由。 RDMAはパケット損失に弱いため、イーサネットでは損失を防ぐか削減する必要があります。NVIDIA Cumulusのドキュメントでは2つの手段が説明されています。PFC(Priority Flow Control)は優先度ごとにホップ単位の一時停止をかけてバッファオーバーフローを防ぎ、ECN(Explicit Congestion Notification)はスイッチが混雑したパケットにマークを付けると受信NICがCNP(Congestion Notification Packet)を送り返して送信速度を落とさせる仕組みです。デフォルト設定では、RoCEデータは優先度3、CNPは優先度6の厳格優先キューを使用します。Onyxのドキュメントでは、ロスレス(ネットワーク全体でPFC)、半ロスレス(ホストとトップオブラック・スイッチの間でのみPFC)、ロスあり(PFCなし)のモードを区別しています。DCQCN(SIGCOMM 2015)はPFCの副作用を軽減するためのECNベースのRoCE v2混雑制御であり、概要によるとMellanox NICに実装されMicrosoftのデータセンターにデプロイされています。DCQCNがPFCを置き換えるわけではありません。論文の第7節には、損失率が0.1%を超えるとスループットが急減するため依然としてPFCが必要であると記載されています。PFCはネットワーク全体のデッドロックを引き起こす可能性があり(Microsoftの2016年の論文では、テストクラスターでMACアドレスが不明なパケットのフラッディングとPFCが絡み合って実際にデッドロックが発生した事例や、1つのNICがPAUSEを出し続けたことでネットワーク全体がブロックされた事故が報告されています。下記の「外部の根拠」)、イーサネットのDCB構成はInfiniBandよりも複雑であるという評価があります(Wikipedia)。

障害は静かに表面化します。MinIO MemKVのランブック(NVIDIAのドキュメントではないサードパーティ資料)によると、PFCの優先度、DSCPマッピング、MTUが互いに一致している必要があり、イーサネットのMTUが1500の場合、RoCEの有効MTUが1024にネゴシエートされ、ずれている場合は IBV_WC_RETRY_EXC_ERR で終了するものの、ノード間でしか判明しないと記載されています。

3. 階層と帯域幅

 노드(예: 8 GPU)
 GPU0 ... GPU7 ══ NVLink / NVSwitch ══ (노드 안 전체 연결)
   │PCIe          │PCIe
  NIC0    ...    NIC7 ──> 같은 번호 NIC 끼리 같은 리프 스위치 (rail)
階層 帯域幅 出所と単位
NVLink 第4世代(H100) GPUあたり900GB/s NVIDIA仕様、双方向合計
NVLink 第5世代(Blackwell) GPUあたり1,800GB/s 同左の表記
PCIe 5.0 x16 レーンあたり32GT/s、方向あたり約63GB/s 32GT/sはRambusのドキュメント、63GB/sは128b/130bエンコーディングを仮定した筆者の計算
ConnectX-7 1枚 400Gb/s、方向あたり50GB/s NVIDIA。DGX H100は計算用InfiniBandカード8枚
一般イーサネット 0.125〜0.31GB/s 1GbE、2.5GbEの理論値

NVLink第4世代を方向あたり(半分)に換算すると約450GB/sとなり、NIC1枚の約9倍です(筆者換算)。DeepSeek-V3レポートのH800クラスターでも、NVLinkの160GB/s対InfiniBandの50GB/sであり、この格差が第6部の「TPはサーバー内、PPとEPはサーバー間」という傾向を生み出します。NVL72のようなシステムでは72個のGPUが1つのNVLinkドメインとなるため、境界が変わります。 レール構造はDGX SuperPODリファレンスアーキテクチャで確認したもので、各サーバーの同じ番号のNICを同じリーフスイッチに接続することで、同じレールのサーバー間ではスイッチを1つしか経由しないようにします。

4. GPUDirect RDMAとGPUDirect Storage

GPUDirect RDMAは、NICがGPUメモリを直接読み書きすることでホストメモリを経由しないようにします。公式ドキュメントの前提は、2つのデバイスが同じPCIeルートコンプレックスを共有し、その間にPCIeスイッチのみが存在する場合に最適であり(QPI/UPIを跨ぐと性能が低下)、IOMMUが無効であるか1:1パススルーでなければならないという点です。NCCLのドキュメントでは、 nvidia-peermem モジュールを起動ごとにロードするか、オープンソースドライバーのDMA-BUFパスを使用するように案内されており(未ロードやACSもよくある原因)、 NCCL_NET_GDR_LEVEL でNICとGPU間の最大距離(LOC、PIX、PXB、PHB、SYS)を制限します。

GPUDirect Storage(GDS)は、ストレージとGPUメモリ間のDMAによりCPUバウンスバッファをなくし、 cuFile APIとローカルNVMe、NVMe-oF、Lustre、WekaFS、NFS over RDMAをサポートします。条件が合わない場合はCPUメモリを経由する互換モードにフォールバックし、メリットが失われます。

5. NCCL

演算。 NCCL 2.32.3ドキュメントの集合演算は、AllReduce、Broadcast、Reduce、AllGather、ReduceScatter、AlltoAll、Gather、Scatterであり、ポイントツーポイントのsend/recvもあります。すべてのランクが同じcountとdatatypeで呼び出す必要があり、一致しない場合はハング、クラッシュ、データ破損などの未定義動作が発生します。

アルゴリズムとトポロジ。 NCCL_ALGO ドキュメントに列挙されているアルゴリズムは、Ring、Tree、CollnetChain、CollnetDirect、NVLS、NVLSTree、PATです(NVLSはNVLink SHARPオフロード)。NCCL 2.4のブログによると、リングは帯域幅を使い切るものの遅延がGPU数に比例し、二重二分木は帯域幅を維持したまま遅延が対数的に増加するため、Summitの24,576基のGPU環境ではリングよりも最大180倍遅延が改善されたとのことです(NVIDIAの測定主張)。NCCLは初期化時にNVLink、PCIe、NICの接続を検知してグラフを作成し、 NCCL_TOPO_DUMP_FILE で検知結果を出力します。

変数 役割(ドキュメント基準)
NCCL_DEBUG VERSION, WARN, INFO, TRACE(2.32で ATTN 追加)。 NCCL_DEBUG_SUBSYS でサブシステムフィルター
NCCL_SOCKET_IFNAME 使用するIPインターフェース。プレフィックスリスト、 ^ 除外、 = 完全一致
NCCL_IB_HCA 使用するRDMAアダプター。 <hca>[:<port>] リスト、 ^ 除外、 = 完全一致
NCCL_IB_DISABLE 1の場合、IB/RoCEを無効化しIPソケット等に代替
NCCL_NET_GDR_LEVEL NICとGPU間のGPUDirect RDMA許可最大距離
NCCL_IB_GID_INDEX, NCCL_IB_TC RoCEのGIDとトラフィッククラス。2.21以上はGID自動選択のため設定しない
NCCL_CROSS_NIC リングとツリーで異なるNICを使用することを許可するかどうか。レール最適化ネットワークかどうかに依存

ドキュメントではデバッグ変数やチューニング変数を本番環境の設定に残さないよう警告しており、あるベンチマークでの利益が別の場所での損失になることがあると述べています。推論において、NCCLはTPの層別all-reduceに使用され、EPはバックエンド（allgather_reducescatter、DeepEPなど）によってパスが異なります。KV転送はNIXL/UCXが担当するためNCCL変数は適用されません（第6部）。

6. 測定方法

./build/all_reduce_perf -b 8 -e 128M -f 2 -g 8                    # 노드 안 GPU 8장
mpirun -np 64 -N 8 ./build/all_reduce_perf -b 8 -e 8G -f 2 -g 1  # 8노드 x 8 GPU (MPI=1 빌드)
ib_write_bw -d mlx5_0 -a                       # perftest 서버
ib_write_bw -d mlx5_0 <서버주소> -a            # 클라이언트. --use_cuda=0 을 더하면 GPU 메모리 경로
ib_write_lat -d mlx5_0 <서버주소>              # 꼬리 지연 확인

nccl-testsは時間、algbw（크기/시간）、busbwを出力します。busbwは演算ごとの補正係数を掛けてランク数に関わらずハードウェアの限界と比較するための値であり、AllReduceは algbw × 2(n−1)/n、ReduceScatter・AllGather・AlltoAllは algbw × (n−1)/n です。大容量メッセージのbusbwがNVLinkやNICの理論限界にどれほど近いかを確認し、小容量メッセージでは時間（レイテンシ）を確認します。NCCLドキュメントの順序としては、ノード内は nvbandwidth と nvidia-smi topo -m、ノード間は ib_write_bw/ib_write_lat を先に確認し、これらの値が期待通りであるにもかかわらずNCCLだけが遅い場合にNCCLの設定を疑います。

7. よくある障害

症状 確認 根拠
IBリンクのダウングレード ibstat のRateとActive状態、 mlxlink の幅と速度 NCCLドキュメント
誤ったHCA・インターフェース UPであっても通信不能なインターフェースを選択すると、初期化失敗やハングが発生します。 NCCL_SOCKET_IFNAME, NCCL_IB_HCA を指定。ログに NET/IB/GDRDMA ではなく NET/Socket と表示される場合はTCP NCCL、vLLMドキュメント
固定メモリ制限 ibv_create_qp, ibv_reg_mr エラーの場合はmemlock無制限。Kubernetesでは IPC_LOCK またはノード単位で解除 NCCL、vLLM、Dynamoドキュメント
RoCE GIDエラー ibv_modify_qp ... Invalid argument。2.21未満の場合は show_gids でRoCE v2 GIDを確認 NCCLドキュメント
MTUの不一致 ibv_devinfo の active_mtu。ノード間でのみ失敗 サードパーティ製ランブック
PFC・ECNの設定ミス テールレイテンシ、スループットの不安定化。 ethtool -S のpause・PFCカウンターと rdma statistic の再送カウンターを確認し、NCCLよりも輻輳制御を先に調査 NCCLドキュメント
遅いリンクが1つ 集合通信にはすべてのランクが参加するため、最も遅い区間が全体を遅延させます（執筆者の解説）。1つのレールのみが遅い場合は ibdiagnet NCCLドキュメント

8. KubernetesにおけるRDMA

flowchart TB
  subgraph Node[GPU 노드]
    OFED[MOFED 드라이버<br/>ofedDriver]
    PEER[nvidia_peermem<br/>GPU Operator]
    DP[RDMA 공유 디바이스 플러그인]
    MUL[Multus + NetworkAttachmentDefinition]
  end
  OFED --> DP
  DP -->|rdma/hca_shared_devices_a 광고| KL[kubelet]
  KL --> Pod[파드: GPU + rdma 자원 + 보조 인터페이스 net1]
  MUL --> Pod
  PEER --> Pod

NVIDIA Network Operator（最新 v26.4.2、2026-09-16）は NicClusterPolicy（README上の表記はNICClusterPolicy、名前は nic-cluster-policy に固定）の単一リソースで下位構成を有効化します。項目はMOFEDドライバコンテナ（ofedDriver), rdmaSharedDevicePlugin, sriovDevicePlugin, secondaryNetwork（Multus、containernetworkingプラグイン、IPoIB CNI）、 nvIpam, nicConfigurationOperator などであり、 MacvlanNetwork, HostDeviceNetwork, IPoIBNetwork CRDが NetworkAttachmentDefinition に変換されます。

9. 推論においてRDMAが必要となるポイント（第6部と関連）

ポイント 通信 根拠
KVキャッシュ転送 NIXL（UCX）によるprefillからdecodeへのGPU-to-GPU。NCCLではない Dynamo RDMA、vLLM NixlConnectorドキュメント
エキスパート並列 層ごとにall-to-all。DeepSeek-V3はdecodeにおいてIB point-to-pointとIBGDAで遅延を削減 DeepSeek-V3、vLLM EPドキュメント
ノードをまたぐTP 層ごとにall-reduceとなるためInfiniBandなどの高速アダプターが望ましい（vLLMドキュメントの表現は「preferably」）。ノード間TPの拡張性が悪いという計測結果もある（下記の「外部の根拠」を参照） vLLM並列化ドキュメント、Singhania他 2026年
大規模モデルのロード 共有ストレージとGDS。Dynamoでは70B超のモデルをポッドごとにダウンロードすると数時間かかると警告 Dynamoのインストール、GDSドキュメント

NVIDIAのDynamoドキュメントには、TCPでKVを転送した場合のTTFTは約98秒、RDMAであれば200〜500msになると記載されています。ドキュメントセット内に条件があります。98秒はLlama-3.1-8B、入力8,000トークン、AWS p5.48xlargeにおいて EFAポッドのNIXLがUCXの低速パスに意図せずフォールバックした際の計測値であり、200〜500msは同じドキュメントが「仕様に基づく期待値」として示している値です（同一条件のEFA環境で実際に測定されたKV転送の追加分は37ms）。一般的なTCPとRDMAの対比として捉えてはなりません（第6部の「外部の根拠」を参照）。

10. 実際に試してみる

RDMAハードウェアがないため、ソフトウェアとTCPの範囲となります。1番と2番は直接実行しておらず、3番（ソフトウェアRoCE）については下記の「実測」にて実際に実行した結果を記載しています。

  1. iperf3 でイーサネットの限界を確認。 2台のサーバーで iperf3 -s と iperf3 -c <서버> -P 4 -t 10 を実行し、上の表にある1GbE、2.5GbEの理論値と比較します。コントロールプレーン（etcd）ノードは避け、閑散とした時間帯に行います。 実際に実行した結果： 異なる3組のノード（ポッドネットワーク、10秒）において、単一ストリームが894〜902Mbit/s、4ストリームが901〜912Mbit/sといずれも同等であり（再送0）、1GbEの線速度の約90〜91%（約112MB/s）でした。このネットワークでKVを転送する場合、8,000トークン（1トークンあたり114,688バイトの1.7Bモデルであれば約917MB）で約8秒、1トークンあたり256KiBの32Bモデルであれば約2.1GBで約19秒かかります（計算値）。同一の1.7Bモデルが8GB級GPUで8,000トークンの入力処理に要する時間が約1秒（8.2k tok/s、第21部）であることを考えると、 このネットワーク環境ではKVを転送するよりも再計算する方が高速です（第14部および第21部の測定値とこの計算の比較）。
  2. TCPソケットNCCL。 GPUを1枚ずつ搭載した2台のサーバー（例: hostA、hostB）で、 MPI=1 でビルドした nccl-tests をホスト上で直接 mpirun します。他のワークロードがGPUを使用していないことを事前に確認します。
    mpirun -np 2 -H hostA:1,hostB:1 -x NCCL_IB_DISABLE=1 -x NCCL_SOCKET_IFNAME=<인터페이스> \
  -x NCCL_DEBUG=INFO ./build/all_reduce_perf -b 8 -e 256M -f 2 -g 1
    予想としては、ログにソケット転送が表示され、大きなメッセージのbusbwがリンク速度（1GbEの場合は0.125GB/s）を超えることができないというものであり、実測値ではありません。GPUが1枚のみの単一ノードでは通信相手が存在しないため意味がありません。
  3. ソフトウェアRoCE（rxe）によるverbsの動作確認。 RHELのドキュメントによると、Soft-RoCEはテクノロジープレビューであり、RHEL 10では削除予定となっています。パフォーマンスはCPUに依存するため数値に意味はなく、デバイスの列挙、ポート状態、MTUなどの概念を確認するための用途となります。カーネルモジュールとRDMAデバイスを作成するため、運用中のノードではなく使い捨てのVM上で実施します。
    sudo rdma link add rxe0 type rxe netdev <이더넷 인터페이스>
rdma link show; ibv_devices; ibv_devinfo -d rxe0 | grep -E "state|active_mtu"
ib_write_bw -d rxe0 -a          # VM 두 대에 rxe 를 만들고 서버/클라이언트로
sudo rdma link delete rxe0      # 정리 (man rdma-link 로 확인)

実測：ソフトウェアRoCE（rxe）によるverbsの動作と2つの障害の再現

環境。 使い捨ての仮想マシン（4 vCPU、4GiB、Linux 6.8、仮想NICのMTU 1500）1台の中でサーバーとクライアントを両方実行しました（自分自身のアドレスへ接続）。 rdma-core, ibverbs-utils, perftest(ib_write_bw, ib_write_lat), iperf3 をインストールしました。デフォルトのクラウドカーネルイメージには rdma_rxe モジュールが含まれておらず、 modprobe がモジュールを見つけられなかったため、追加のモジュールパッケージ（linux-modules-extra-<커널 버전>）をインストールすることで有効になりました。パフォーマンスの数値はCPUに左右されるため、あくまで概念確認用となります。

確認した項目 結果
デバイスの作成 rdma link add rxe0 type rxe netdev <인터페이스> 1行で ACTIVE, LINK_UP. ibv_devinfo は transport: InfiniBand, link_layer: Ethernet, max_mtu 4096, active_mtu 1024
GIDテーブル 4つ、すべて RoCE v2。リンクローカルIPv6、IPv4をマッピングした ::ffff:a.b.c.d、さらには同マシンの 別インターフェース（オーバーレイネットワーク）のアドレスまで 1つのデバイスのGIDテーブルに登録されました（カーネルソースによると、RDMAが紐づくデバイスとその上位デバイスのアドレスが登録されるとのことです。オーバーレイインターフェース flannel.1 はVXLANデバイスであり、sysfs上で enp1s0 の上位デバイス（upper_flannel.1）として表示されるため、この説明と一致します）
MTU イーサネットMTU 1500上のデバイスは active_mtu 1024、MTU 65536のループバック上のデバイスは 4096。書き込みスループットはそれぞれ533MB/sと1,643MB/sで3.1倍（パスが異なるため厳密な比較ではありません）
サイズ別の書き込みスループット 2Bで0.30MB/s（メッセージレート約0.16Mpps）、1KiBで208MB/s、64KiBで536MB/s、2MiBで529MB/sとなり、約0.53GB/sで頭打ちになりました。小さなメッセージのメッセージレートは約0.24Mppsが上限です
同一パスにおけるTCP iperf3 単一ストリーム34.7Gbit/s（約4.3GB/s）、4ストリーム137Gbit/s。rxeの書き込みよりも 約8倍 高速
書き込み遅延 2Bの典型値2.09µs（同一マシン内であるためネットワーク往復がなく、ハードウェアの値と比較することはできません）
統計カウンター rdma statistic show link rxe0/1 に sent_pkts, rcvd_pkts, duplicate_request, out_of_seq_request, rcvd_rnr_err, retry_exceeded_err, completer_retry_err, link_downed などが存在します。第7部の表にある「リトライカウンター」が実際に存在することを確認しました
存在しないデバイス名 ib_write_bw -d rxe9 → IB device rxe9 not found, Unable to find the Infiniband/RoCE device、終了コード1

このテストの限界は、仮想マシン 1 台、ソフトウェア実装、GPU なしである点です。2 ノード間の RDMA、実際の NIC のスループットと遅延、PFC と ECN、 nccl-tests、GPUDirect RDMA は測定できていません（未計測）。

外部の根拠：論文と公式資料で確認した内容

直接測定できなかった RoCE 混雑制御と NCCL・GPUDirect の記述、およびソフトウェア RoCE の性能を 1 次資料で確認しました。外部の数値は機器や条件が異なるため、方向性と構造の一致のみを判定しています。

トピック 資料と確認した箇所 確認した内容と条件 本記事との関係
DCQCN Zhu 他、「Congestion Control for Large-Scale RDMA Deployments」、SIGCOMM 2015、第 1・2・6・7 節 ECN ベースのエンドツーエンドの混雑制御を NIC に実装。40Gbps 環境での 2KB 転送平均遅延は TCP が 25.4µs、RDMA の読み取りと書き込みが 1.7µs。インキャスト次数 10 での PAUSE メッセージ数は DCQCN なしだと 600 万件超、使用時は約 3,000 件。第 7 節では損失率が 0.1% を超えるとスループットが急減し、PFC が不要になるわけではないと明記 支持。 「PFC の副作用を軽減する混雑制御」の記述と一致。本記事の「配備されました」を抄録の「配備中」に修正
PFC デッドロックと PAUSE ストーム Guo 他、「RDMA over Commodity Ethernet at Scale」、SIGCOMM 2016、第 4.2・4.3・6.2 節 テストクラスターにおいて、MAC アドレス不明パケットのフラッディングと PFC の相互作用によりデッドロックが発生し、サーバーを再起動しても解消されない。NIC のバグにより 1 台のサーバーが毎秒 2,000 件を超える PAUSE を発信し、顧客サーバーの半分に影響。99 パーセンタイル遅延は RDMA が 90µs、TCP が 700µs（50:50 の混在トラフィック） 支持。 「PFC の設定ミスがネットワーク全体の障害になる」の実例の根拠
精密な混雑制御 Li 他、「HPCC」、SIGCOMM 2019 インバンド・テレメトリーを使用した速度制御。3KB 未満のフローにおける 99 パーセンタイル完了時間のスローダウンは、DCQCN の 53.9 に対し HPCC は 2.70（Alibaba による独自測定、FPGA NIC と P4 スイッチを前提） 関連。 ECN ベース方式の限界と PFC への依存性を示している
NCCL のよくある障害 NCCL 2.32.3「Networking Troubleshooting」、「GPU troubleshooting」 ibv_create_qp·ibv_reg_mr 失敗はピンロックメモリ制限の問題（memlock 無制限）。GID の選択を誤ると ibv_modify_qp ... Invalid argument、2.21 以上では GID が動的に選択される。ACS と IOMMU が有効な場合、GPUDirect P2P がバイパスされてパフォーマンス低下や停止につながる 支持。 第 7 節の表と今回の memlock の再現検証の解決策が一致
memlock と権限 Linux カーネル drivers/infiniband/core/umem.c（master、調査時点） ユーザーメモリの登録時に RLIMIT_MEMLOCK を超過した場合、 CAP_IPC_LOCK がないと -ENOMEM として失敗 支持。 root が制限に引っかからなかった理由を説明
MTU NVIDIA MLNX_OFED v5.9「RoCE」ドキュメントの ibv_devinfo の例、カーネル rxe_param.h イーサネット MTU が 1500 である mlx5 デバイスが max_mtu 4096, active_mtu 1024。rxe は 80 バイトのヘッダーを引いて切り捨てる 支持。 上記の MTU の記述をソースベースで修正
GPUDirect RDMA NVIDIA「GPUDirect RDMA」ドキュメント 第 1・3.4 節 NIC と GPU が同じ PCIe ルートコンプレックスを共有する必要があり、PCIe スイッチのみの場合が最適。CPU を経由すると遅くなり、QPI を経由すると性能の制限や不安定さにつながる。パフォーマンスの数値はドキュメントに記載なし 支持。 第 4 節の記述と一致。メリットの数値は DCQCN、2016 年の論文に記載あり（CPU サイクルが 20% から 3% 未満に減少）
ソフトウェア RoCE linux-rdma メーリングリスト（2019、メンテナーによる診断）、カーネル rxe_icrc.c、Red Hat RHEL 9 ドキュメント soft-RoCE は約 2Gbps、対して TCP は 20Gbps という報告があり、パケットごとに CPU が ICRC（CRC32）を計算する。RHEL ドキュメントにはテクニカルプレビューであり、RHEL 10 で削除予定と記載されている 限定的に支持。 我々の結果（rxe の書き込み約 4.2Gbit/s、同一マシンでの TCP 約 34Gbit/s）と同じ傾向。制御された測定論文はアクセス可能な範囲で見つからなかった
ノードをまたぐ並列化 DeepSeek-V3 技術報告書（arXiv 2412.19437）第 3.2・3.4 節。Singhania 他、arXiv 2511.09557。vLLM 並列化ドキュメント エキスパート並列処理ではトークンを最大 4 ノードまでしか送信せず、IB 経由で NVLink に転送し、デコード時は IB のポイントツーポイントと IBGDA を使用する（NVLink の 160GB/s に対し IB は 50GB/s）。ノード間 TP の拡張性が悪く、デコードが重いバッチ処理では PP も TP に劣る事例がある。vLLM のドキュメントでは高速アダプターが「望ましい」と表現されている 支持。 第 9 節の表と一致するが、「必要」という表現を「望ましい」にトーンダウン

アクセス制限により閲覧できなかった資料（IEEE Network 2019 の論文、カーネルバグzilla 190951、SoftRDMA）の数値は使用していません。

11. 面接で想定される質問

  1. TCP の代わりに RDMA を使用する理由は何ですか？ カーネルのコピーや CPU の介入なしに NIC が固定メモリを直接読み書きするため、遅延と CPU 負荷が軽減されます。また、GPUDirect RDMA によりホストメモリを経由することすらなくなります。
  2. InfiniBand と RoCE v2 のどちらを選択すべきですか？ また、RoCE のリスクは何ですか？ IB は専用ネットワークと SM により設定がシンプルですが、RoCE は既存のイーサネットと L3 ルーティングを使用する代わりに、PFC、ECN、DSCP、MTU のすべてを一致させる必要があります。設定を誤ると、テールレイテンシの悪化やノード間でのみ通信が失敗する問題として現れ、スイッチのカウンターで確認することになります。
  3. all_reduce_perf の busbw が NIC の線速度の半分である場合、どこから確認しますか？ ib_write_bw で NIC 自体が線速度を出しているか確認し、 nvidia-smi topo -m で GPU と NIC の距離を確認し、 NCCL_DEBUG=INFO で選択された転送方式（NET/IB、GDRDMA かどうか）とレール構成を確認します。
  4. マルチノード学習が突然遅くなった場合の診断手順は？ リンクのダウングレード（ibstat Rate）、ポートエラーカウンター、特定のレールへの偏り（ibdiagnet）、RoCE の場合は PFC・ECN カウンターの順に確認します。ハードウェアが正常である場合にのみ NCCL の環境変数を調整します。
  5. Kubernetes で Pod が RDMA を使用するために必要なものは何ですか？ MOFED とデバイスプラグイン（Network Operator）、Pod による rdma/... のリソース要求、 nvidia_peermem、memlock 制限、必要に応じて Multus 補助インターフェースや SR-IOV、そして GPU に近い NIC が割り当てられる配置です。

12. よくある誤解

参考資料（実際に閲覧したもの）

確認したバージョンと日付、確認できなかったこと

確認日は2026年10月5日です。NCCL v2.32.3-1 (2026-09-17)、perftest 26.07.8 (2026-09-28)、Network Operator v26.4.2 (2026-09-16)、RDMA共有デバイスプラグイン v1.5.4 (2026-07-28)、Multus v4.3.1 (2026-09-08)、SR-IOVデバイスプラグイン v3.11.0 (2025-12-16)をGitHubリリースAPIで確認し、nccl-testsはリリースなしでmaster (2026-10-02のコミット)を参照しました。

確認できなかったこと: (1) DCQCN論文の本文は直接読みました(以下の「外部の根拠」)。 (2) Network OperatorのREADMEのシステム要件(ConnectX-5、Ubuntu 20.04)は古く見えるため、現在のサポートマトリックスは確認できていません。 (3) KubernetesでGPUとNICのペアを合わせて割り当てる方法。 (4) rdma link delete とnccl-testsの予想出力は実行していません。 (5) MTUネゴシエーションのルールはサードパーティのランブックを基準としています。 (6) InfiniBandリンク層フロー制御とNVLink第6世代の詳細については扱っていません。 (7) 第10章の3つのハンズオンはいずれも未実行です。

ログインするといいねできます

コメント

まだコメントはありません。

ログインするとコメントできます