GPU Topologyとは？NVLink・PCIe・NUMAを見てLLM推論を配置する

同じmodel、同じ8 GPU、同じTensor Parallel sizeでも、rankの置き方だけでLLM推論の速度が変わることがある。GPU 0と1がNVLinkで直結している構成と、別CPU socketをまたいでPCIe通信する構成では、All-Reduceの経路が違うからである。

GPU Topologyは、GPU、CPU、memory、PCIe switch、NICがどの経路でつながっているかを表す。GPU型番と台数だけでは分散推論の通信性能を判断できない。Tensor、Context、Expert Parallelismのgroupをどこへ置くかは、Topologyを見て決める必要がある。

node内通信にも複数の経路がある

一つのserverへ8 GPUが入っていても、すべてのGPU pairが同じbandwidthとlatencyで通信できるとは限らない。

NVLinkで直接またはNVSwitch経由につながる
同じPCIe switchを共有する
複数のPCIe switchを通る
CPUのPCIe Host Bridgeを通る
別NUMA nodeのCPU間linkを通る

近いGPU pairではPeer-to-Peerで直接memoryを読めても、遠いpairではhost memoryを経由する場合がある。collective libraryが同じAPIを提供しても、実際のdata pathは異なる。

`nvidia-smi topo -m`の記号を読む

NVIDIAのnvidia-smi topo -mは、GPUとNICの接続matrix、CPU affinity、memory affinityを表示する。代表的な記号は次の通りである。

表示	経路の意味
`NV#`	#本を束ねたNVLink接続
`PIX`	一つのPCIe switchを通る
`PXB`	複数のPCIe switchを通るがHost Bridgeは通らない
`PHB`	PCIe Host Bridgeを通る
`NODE`	同じNUMA node内の複数Host Bridgeを通る
`SYS`	PCIeに加えNUMA node間のCPU interconnectを通る

一般にNV#や近いPCIe経路は、SYSより頻繁なGPU通信へ向く。ただし記号だけで実効bandwidthを断定しない。GPU世代、link本数、PCIe世代、switch構成、同時trafficで変わる。

nvidia-smi topo -p2pではGPU間のP2P read、write、NVLink、PCIeなどのcapabilityを確認できる。Topology matrixと通信benchmarkを組み合わせる。

NVLinkとNVSwitchの役割は違う

NVLinkはGPU間の高速linkである。GPU pairを直接つなぐ構成では、どのpairに何本のlinkがあるかでbandwidthが変わる。

NVSwitchは複数GPUをswitch fabricへ接続し、多くのGPU pairへ高bandwidthな経路を提供する。全GPUが完全に同じ性能になるとは限らないが、pairwise linkだけの構成より大きなcollective groupを作りやすい。

Tensor Parallelismはlayerごとにcollectiveを繰り返すため、NVLink domain内へ収める効果が大きい。GPU数を増やすためTP groupをNVLink domainの外へ広げると、一部stepが遅い経路へ制約される。

PCIe switchとHost Bridgeをまたぐcost

GPU間にNVLinkがない場合、P2PはPCIeを使う。同じPCIe switch配下ならGPU同士のtrafficがCPU Host Bridgeまで上がらずに済む場合がある。

別Host Bridgeや別CPU socketへまたがると、dataはより長い経路を通る。CPU間interconnectやmemory controllerのtrafficと競合する可能性もある。

PCIe bandwidthの公称値だけで判断しない。複数GPUが同じuplinkを共有すれば、同時通信時のaggregate bandwidthが頭打ちになる。All-to-Allでは多数pairが同時に通信するため、単一pair benchmarkより早くbottleneckが出る。

NUMAはCPU処理とhost memoryにも効く

NUMA serverでは、CPU coreとmemoryがsocketごとのnodeに分かれ、local memoryとremote memoryでaccess costが違う。GPUとNICも特定NUMA nodeへ近い。

LLM servingはGPUだけで完結しない。tokenization、request queue、sampling、CPU offload、pinned memory、network処理をCPU側で行う。GPUに近いCPU coreとmemoryを使わないと、host-to-device transferやcontrol pathが遠回りする。

processのCPU affinity、memory allocation、GPU、NICを同じNUMA domainへ寄せる。containerへCPUを割り当てるときも、core数だけでなくsocketとNUMA nodeを見る。

KV Cache OffloadingでCPU DRAMを使う場合は特に重要である。remote NUMA memoryへ退避したKVをGPUへ戻せば、PCIe転送前にCPU socket間を通る可能性がある。

NIC affinityがmulti-node通信を決める

multi-nodeのcollectiveやKV transferでは、GPUからNICへdataを送る。GPUとNICが同じPCIe root complexや近いswitch配下にあるほど、短い経路を使いやすい。

GPU 0に近いNICがあるのに、processが遠いNICから送信すれば、node内で余分なPCIeやCPU interconnectを通る。dual-rail構成では、rankとNIC railの対応も重要になる。

Topology matrixでGPUとNICの関係を確認し、network interface名、RDMA capability、NUMA affinityを記録する。bondingされたinterfaceが表示されても、すべてがRDMAに使えるとは限らない。

GPUDirect RDMAはGPUとNICの直接経路を作る

通常のnetwork transferでは、GPU memoryのdataをhost memoryへcopyし、NICがhost bufferから送る経路がある。GPUDirect RDMAは、対応NICなどのpeer deviceがGPU memoryと直接data交換できる経路を提供する。

CPU bounce bufferを避けることで、CPU負荷、copy回数、latencyを減らせる可能性がある。Prefill・Decode分離のKV transfer、multi-node Tensor Parallelism、Context Parallelismで重要になる。

ただし、software flagを一つ有効にすれば必ず動く機能ではない。GPUとNICのPCIe関係、driver、kernel moduleまたはDMA-BUF、RDMA stack、IOMMU設定、container権限などが関係する。

NVIDIAのGPUDirect RDMA資料は、GPUとpeer deviceが同じupstream PCIe root complexを共有する構成を基本条件として説明し、CPU socket間をまたぐ経路では性能や動作に制約がありうるとしている。

NCCLはTopologyを検出するが、環境が隠すことがある

NCCLは/sysなどからGPU、PCIe、NICのTopologyを検出し、P2P、shared memory、network transportを選ぶ。containerやvirtual machineから不完全な/sysしか見えなければ、実機とは違うTopologyとして認識する可能性がある。

NCCLが自動選択するから配置を考えなくてよいわけではない。schedulerが遠いGPUを一つのTP groupへ割り当てれば、libraryはその中で最善の経路を選ぶだけである。

起動logと通信benchmarkで、意図したP2P、NVLink、RDMAを使っているか確認する。TCP socketへfallbackしてもapplicationは動くため、機能testだけでは見逃しやすい。

parallelismごとに近さの優先度が違う

Tensor ParallelismはDecodeの各layerでcollectiveを行うため、最も近いGPU groupへ置く。可能なら一つのNVLink、NVSwitch domain内へ収める。

Pipeline Parallelismはstage境界でactivationを送る。TPほど頻繁なcollectiveを避けやすいため、node境界へ置く候補になる。ただしstage間trafficとbubbleを測る。

Context Parallelismは長文のKV blockを交換する。大きなmessageをcomputeとoverlapできるか、node間bandwidthが十分かを確認する。

Expert Parallelismはtoken routingによるAll-to-Allを使う。expert loadが偏ると特定linkやNICへtrafficが集中する。rankを均等配置するだけでなく、実際のrouting distributionを見る。

Data Parallelismのreplicaは比較的独立している。通信の強いmodel parallel groupをnode内へ閉じ、replicaをnode単位で増やす構成が扱いやすい場合がある。

KubernetesのGPU数だけでは配置を表せない

Podがnvidia.com/gpu: 4を要求しても、割り当てられた4 GPUが互いに近い保証は、device pluginやschedulerの構成次第である。

GPU UUIDとindex、PCI bus ID、NUMA node、NVLink domain、NIC affinityをnode inventoryとして持つ。Topology-aware schedulingやnode labelを使い、TP 4には同じ高速domainの4 GPUを割り当てる。

MIGでは一つのphysical GPUを複数instanceへ分ける。MIG instance数をphysical GPU数と同じように扱わない。memory、compute、P2P、通信機能の制約を使用構成で確認する。

GPU indexは再起動後も物理位置を表すとは限らない

applicationが見るGPU 0は、必ずしもchassis上の固定slotや最も近いNICを意味しない。CUDA_VISIBLE_DEVICES、container runtime、device pluginによってindexは並べ替えられる。

運用記録にはGPU indexだけでなくUUIDとPCI bus IDを残す。rank、GPU UUID、NIC、NUMA nodeのmappingをdeploymentごとに保存する。

performance regression時に「GPU 0から3を使った」という情報だけでは、以前と同じphysical pathだったか確認できない。

監視するmetric

rank、GPU UUID、PCI bus ID、NUMA node、NICのmapping
GPU pairごとのP2P capability
NVLink、PCIeの送受信量とerror
NICごとのthroughput、RDMA counter、retransmit、drop
CPU coreとmemoryのNUMA allocation
host-to-device、device-to-hostのbandwidthとlatency
collective種別ごとのdurationとmessage size
rankごとのcollective到着時刻
GPUDirect RDMAとfallback transportの利用状況
TTFT、ITL、token throughput、KV transfer時間

Topologyはdeployment時に一度記録して終わりにしない。driver、firmware、BIOS、container、scheduler変更後に再取得する。

負荷試験

全GPU pairのP2P bandwidthとlatencyを測る
NVLink、PIX、PXB、PHB、SYSの経路を分けて比較する
GPUとNICの組み合わせを変えてRDMA性能を測る
CPUとmemoryのNUMA bindingを変える
TP groupを高速domain内とdomain跨ぎで比較する
TP、CP、EPのcollectiveを実message sizeで測る
複数groupを同時実行しshared uplinkの競合を見る
CPU offloadとnetwork communicationを同時実行する
container内外でTopology認識とtransportを比較する
link、NIC、rankを一つずつ停止しfailure domainを確認する

単体のpeak bandwidthだけでなく、実LLM workloadのTTFT、ITL、throughputと関連付ける。

GPUを数える前に経路を見る

GPU Topologyは、GPU同士、GPUとCPU memory、GPUとNICの距離を表す。同じGPU台数でも、NVLink domain内か、PCIe switchを共有するか、NUMA nodeやNICをまたぐかでcollectiveとKV transferの性能が変わる。

Tensor Parallel groupは近いGPUへ置き、multi-node通信ではNIC affinityとGPUDirect RDMAの実利用を確認する。GPU indexではなくUUID、PCI bus ID、NUMA、NICまで記録し、実message sizeでbenchmarkする必要がある。