26O05g2
네. 이 자료가 들어오니 상당히 많이 확정할 수 있습니다. 특히 중요한 건 이 400G Fabric은 RoCE가 아니라 NDR InfiniBand로 설계된 것으로 거의 확실하다는 점입니다.
사진에서 읽히는 핵심은 NDR Switch 6EA, MQM9700-NS2F (SP:2), MQM9790-NS2F (LF:4), 그리고 “IB 스위치는 C2P 방식…”이라는 문구입니다. NVIDIA 공식 사양상 MQM9700-NS2F는 Quantum-2 기반 64-port NDR InfiniBand managed switch, MQM9790-NS2F는 동일한 64-port NDR InfiniBand unmanaged switch입니다. NVIDIA Docs
따라서 이 설계는 대략 다음과 같습니다.
NDR400 InfiniBand Fabric
┌──────────────────┐
│ SPINE #1 │
│ MQM9700-NS2F │
│ 64-port NDR │
└───────┬──────────┘
│
┌───────┴──────────┐
│ SPINE #2 │
│ MQM9700-NS2F │
│ 64-port NDR │
└───────┬──────────┘
│
┌──────────────┼──────────────┐
│ │ │
┌────▼────┐ ┌────▼────┐ ... ┌▼────────┐
│ LEAF #1 │ │ LEAF #2 │ │ LEAF #4 │
│ QM9790 │ │ QM9790 │ │ QM9790 │
└────┬────┘ └────┬────┘ └────┬────┘
│ │ │
GPU / AIStor ConnectX-7 NDR400즉 사진에 적힌 SP=2, LF=4는 Spine 2대 + Leaf 4대로 해석하는 게 매우 자연스럽습니다.
그런데 더 재미있는 건 1:1 blocking 구성입니다
사진 아래쪽에:
1:1.03, 1:1.1 Blocking 구성
그리고
토리지서버가 GPU서버와 상면혼합배치구성
이라고 보입니다.
이건 앞서 제가 추정했던 dual-plane 8-switch 구조와는 다릅니다. 실제 제안안은 2 Spine + 4 Leaf의 단일 Clos/Fat-tree 계열 fabric으로 보입니다.
대략:
Spine01 Spine02
64 NDR 64 NDR
│ │
┌─────┴─────────────┴─────┐
│ │
400G NDR 400G NDR
│ │
┌─────────┼─────────┬───────────────┤
│ │ │ │
Leaf01 Leaf02 Leaf03 Leaf04
│ │ │ │
├ GPU ├ GPU ├ GPU ├ GPU
└ AIStor └ AIStor └ AIStor └ AIStor가 핵심 topology라고 판단됩니다.
Transceiver 숫자도 topology와 잘 맞습니다
사진에는:
Transceiver : 216 EA
MMA4Z00-NS
SP : 64
LF : 128
MMA4Z00-NS400
Server : 24
Storage : 110이라고 되어 있습니다.
MMA4Z00-NS는 Quantum-2 switch에서 사용하는 twin-port 2×400G OSFP입니다. 즉 물리 OSFP 하나 안에 독립적인 400G NDR optical link 두 개가 들어갑니다. NVIDIA Networking
반면 MMA4Z00-NS400은 서버의 ConnectX-7 등에 꽂는 single-port 400G OSFP SR4이고 IB와 Ethernet 양쪽을 지원합니다. NVIDIA Networking
따라서 사진의 숫자를 논리 port로 바꿔보면:
Spine
MMA4Z00-NS ×64
→ 64 × twin 400G
→ 128 × 400G logical links
Leaf
MMA4Z00-NS ×128
→ 128 × twin 400G
→ 256 × 400G logical links입니다.
이 중 일부는 Leaf↔Spine uplink에 쓰이고 나머지가 server-facing downlink가 됩니다.
그런데 사진의 Server 24가 중요한 단서입니다
사진에:
MMA4Z00-NS400
Server : 24
Storage : 110이라고 되어 있습니다.
현재 우리가 확정한 GPU 서버는 12대죠.
따라서:
Server 24 optics
÷
GPU 12 nodes
=
2 optics / GPU node가 됩니다.
즉 이 스위치 제안서는 GPU당 4×400G를 실제로 연결하는 설계가 아닐 가능성이 매우 높습니다.
현재 자료만 보면 오히려:
GPU01
CX7-0 ──400G── IB Fabric
CX7-1 ──400G── IB Fabric
GPU02
CX7-0 ──400G── IB Fabric
CX7-1 ──400G── IB Fabric
...
GPU12
= 12 × 2
= 24로 해석하는 것이 숫자상 정확히 맞습니다.
이 부분은 우리가 앞에서 가정했던 GPU 4×400G 전 포트 활성화와 다릅니다.
Storage 110도 현재 30대와 안 맞습니다
현재 AIStor는:
30 nodes × 2 × 400G
= 60 server-side optics이어야 합니다.
그런데 사진에는:
Storage : 110이라고 되어 있습니다.
즉 이 NDR BOM은 현재 우리가 이야기하고 있는 30대 AIStor만을 위한 BOM이 아닐 가능성이 큽니다.
예를 들어 55대 × 2포트라면 정확히:
55 × 2 = 110이 됩니다.
따라서 Storage:110은 55대 Storage node × 2×400G를 상정했던 이전/전체 구성일 가능성이 있습니다.
사진 자체에도:
현재 구성은 요구사항에 따라 변경될 수 있음
이라고 되어 있으니 현재 12 GPU + 30 AIStor에 맞춰 다시 산정해야 합니다.
Cable 246도 단서가 됩니다
사진에는:
NDR Cable : 246 EA
LF → SP 112
LF → Server 24
LF → Storage 110입니다.
합계를 계산하면:
112 + 24 + 110
= 246정확히 맞습니다.
따라서 이것은 매우 명확한 port/cable allocation입니다.
즉 원래 설계자가 의도한 건:
NDR400 IB
Spine ×2
▲
│
112 × 400G
│
Leaf ×4
/ \
/ \
24 ×400G 110 ×400G
│ │
Servers Storage입니다.
이제 topology를 상당히 확신할 수 있습니다.
Leaf-Spine 비율도 계산됩니다
Leaf↔Spine:
112 × 400G
= 44.8 TbpsServer-facing:
(24 + 110) × 400G
= 53.6 Tbps따라서 aggregate downlink/uplink 비율은:
53.6 / 44.8
≈ 1.196즉 약 1.2:1 oversubscription입니다.
사진의 1:1.03, 1:1.1 Blocking이라는 메모와 완전히 동일하지는 않습니다. 따라서 여기에는 twin-port optics의 실제 port allocation이나 예비 port, 특정 topology 계산 방식이 추가로 있을 수 있습니다.
이건 정확한 port map을 받아봐야 확정할 수 있습니다.
현재 12 GPU + 30 AIStor로 다시 넣으면 이야기가 달라집니다
GPU의 4×400G를 전부 쓴다고 하면:
GPU
12 × 4
= 48 × 400G
AIStor
30 × 2
= 60 × 400G
합계
= 108 × 400G
= 43.2 Tbps downlink입니다.
재미있는 점은 현재 사진의 원래 downlink:
24 + 110 = 134 ports보다 오히려 적습니다.
현재 필요:
48 + 60 = 108 ports즉 GPU 4포트를 모두 활성화해도 이 4-Leaf topology의 endpoint port capacity 관점에서는 충분할 가능성이 높습니다.
그래서 저는 현재 장비에 이렇게 재배치하겠습니다
4개의 Leaf에 GPU와 AIStor를 섞습니다.
사진에도 스토리지서버가 GPU서버와 상면혼합배치구성이라고 되어 있으니 제안 업체도 같은 방향으로 보입니다.
예를 들면:
SPINE01 SPINE02
\ /
\ /
┌───────────────┼────────────────┐
│ │ │
▼ ▼ ▼
LEAF01 LEAF02 LEAF03 LEAF04
GPU01-03 GPU04-06 GPU07-09 GPU10-12
AIStor01-8 AIStor09-15 AIStor16-23 AIStor24-30각 GPU는 4개 NDR port를 사용:
GPU01
├ CX7-0 ──400G
├ CX7-1 ──400G
├ CX7-2 ──400G
└ CX7-3 ──400GAIStor는:
AIStor01
├ CX7-0 ──400G
└ CX7-1 ──400G입니다.
다만 GPU의 4포트를 동일 Leaf에 몰아넣는 건 권하지 않습니다.
최종 rail 설계는 NIC/GPU affinity와 rack placement를 넣어서 분산해야 합니다.
그리고 중요한 결론: 이건 RoCE 설계가 아닙니다
MQM9700/MQM9790이 결정적인 증거입니다.
NVIDIA 공식 문서에서 두 제품 모두 Quantum-2 NDR InfiniBand switch입니다. MQM9700은 managed, MQM9790은 unmanaged 모델입니다. NVIDIA Docs
따라서 현재 제안서가 의미하는 것은:
bond0
Public
│
Ethernet
bond1
Private / Kubernetes
│
100GbE Ethernet
│
Cilium
BGP
ECMP
ClusterMesh
CX-7
│
NDR400
│
InfiniBand
│
Quantum-2
│
GPU ↔ GPU
GPU ↔ AIStor
AIStor ↔ AIStor입니다.
즉 이전 질문에서 고민했던 “IB냐 RoCEv2냐”는 이 스위치 BOM을 채택한다면 사실상 IB로 결정됩니다.
PFC/ECN/DCQCN 기반 400G RoCE fabric을 설계할 필요도 없습니다. 대신 IB Subnet Manager/UFM, P_Key, adaptive routing, SHARP, rail/topology 및 NCCL/RDMA 설정 쪽이 중요해집니다.
한 가지는 업체에 바로 확인해야 합니다
사진의 수량으로 볼 때 이 제안서는 현재 확정된 12 GPU + 30 AIStor 구성과 일치하지 않습니다.
특히:
Server: 24가 왜 24인가?
이걸 먼저 물어보는 게 좋습니다.
GPU 12대라면 거의 정확히 2×400G/GPU를 의미합니다. 그런데 우리가 받은 GPU HW 사양은 4×400G ConnectX-7 endpoint가 있습니다.
따라서 업체에 다음과 같이 확인하면 됩니다.
“XE9780 12대의 ConnectX-7 NDR400 4-port를 모두 사용하는 설계인가? 현재 NDR BOM의 Server-side MMA4Z00-NS400이 24EA라서 GPU당 2-port만 연결하는 것으로 보이는데, 나머지 2-port는 미사용인지 확인 부탁드립니다.”
그리고 Storage도:
“AIStor 30대 × CX-7 2-port면 60 port인데 Storage-side optics/cable이 110EA인 근거가 무엇인지, 기존 55-node 기준 BOM인지 확인 부탁드립니다.”
이 두 질문의 답을 받으면 6대의 Quantum-2 스위치를 그대로 유지하면서 12×GPU의 48개 NDR port + 30×AIStor의 60개 NDR port를 어떻게 4개 Leaf에 꽂을지, 그리고 Leaf↔Spine 112개 링크가 실제로 필요한지까지 정확히 역산할 수 있습니다. 지금 사진만으로도 기존 제안 topology의 약 80~90%는 드러난 상태입니다.
좋습니다. GPU 12대 + AIStor 55대 + Compute 60대, 그리고 Kubernetes 3-Cluster를 전제로 다시 구성했습니다. 사진의 NDR BOM 수량과 정확히 맞춰서 해석했습니다.
핵심 NDR 계산은 다음과 같습니다.
| 항목 | 구성 | NDR400 링크 |
|---|---|---|
| GPU | 12대 × 2-port active | 24 |
| AIStor | 55대 × 2-port | 110 |
| Server-facing 합계 | 134 × 400G | |
| Leaf→Spine | 112 × 400G | |
| 전체 NDR cable | 112+24+110 | 246 |
| NDR Switch | Spine 2 + Leaf 4 | 6대 |
즉 사진의 LF→Server 24, LF→Storage 110이 12 GPU × 2포트 + 55 Storage × 2포트와 정확하게 일치합니다. 따라서 GPU의 ConnectX-7이 4포트를 보유하더라도, 현재 스위치/BOM 설계는 GPU당 2×400G만 활성화하고 나머지 2포트는 미사용/확장용으로 두는 구성으로 보는 것이 가장 타당합니다.
3개 K8s Cluster는 GPU/AI Training Cluster / General Compute Cluster / AIStor Cluster로 나눴고, 각 Cluster의 Kubernetes/Cilium 통신은 bond1 PRIVATE, 외부 접근은 bond0 PUBLIC, GPU↔GPU 및 GPU↔AIStor 고속 데이터는 별도의 NDR400 InfiniBand Fabric으로 분리했습니다.
Draw.io에는 3개 페이지를 넣었습니다. 첫 페이지는 전체 3-Cluster 및 Public/Private/NDR 관계, 두 번째는 MQM9700 Spine ×2 + MQM9790 Leaf ×4의 실제 NDR 물리 topology와 12 GPU/55 Storage 배치, 세 번째는 GPU/Compute/AIStor별 bond0·bond1·CX-7 물리 NIC 배치입니다.
AI_K8s_3Cluster_Network_Architecture.drawioDraw.io 네트워크 아키텍처 다운로드
한 가지 중요한 부분은 도면에도 표시했습니다. GPU에서 bond0와 bond1을 각각 2-member 100G bonding으로 반드시 구성하려면, 처음 주신 GPU BOM의 100G 포트 수를 다시 확인해야 합니다. NDR 쪽은 이번 자료로 상당히 명확해졌지만, GPU의 Public/Private 100G 물리 NIC 배치는 이 부분이 최종 확인 포인트입니다.
다시 계산해보니, GPU 12대 × 2 NDR active + AIStor 55대 × 2 NDR = 134개의 400G endpoint라는 현재 제안서 기준에서는 MQM9700 Spine 2대 + MQM9790 Leaf 4대 구성은 포트 수 자체는 맞습니다. 다만 중요한 점이 하나 있습니다. 이 구성은 완전한 1:1 non-blocking이 아니라 약 1.20:1 oversubscription입니다.
NVIDIA 공식 사양상 QM9700/QM9790은 각각 64개의 400G NDR logical port, 총 51.2 Tb/s aggregate bidirectional switching capacity를 제공합니다. 물리적으로는 32개의 twin-port OSFP cage입니다. NVIDIA Docs
제안서 숫자를 그대로 검산하면
| 구분 | 계산 | 400G logical links |
|---|---|---|
| GPU downlink | 12 × 2 | 24 |
| AIStor downlink | 55 × 2 | 110 |
| Leaf server-facing | 24 + 110 | 134 |
| Leaf→Spine | 제안서 | 112 |
| 전체 Cable | 134 + 112 | 246 |
| Leaf capacity | 4 × 64 | 256 ports |
| Spine capacity | 2 × 64 | 128 ports |
사진의 24 + 110 + 112 = 246과 정확하게 일치합니다.
그리고 4개 Leaf에서 134개의 endpoint를 수용하면서 112개 uplink를 쓰면 Leaf port 사용량은 총:
134 + 112 = 246 / 256 ports
입니다.
즉 4개 Leaf에 10 logical 400G port만 spare입니다. 포트 utilization이 약 96.1%라서 꽤 빡빡한 설계입니다.
Leaf당 평균을 보면 더 명확합니다
112개 Leaf→Spine link를 4대에 균등 분배하면:
Leaf당 28 uplink
입니다.
64-port switch니까:
64 - 28 = 36 downlink
를 사용할 수 있습니다.
따라서:
Spine01 Spine02
▲ ▲
│ │
14×400G 14×400G
│ │
└──────┬──────┘
│
Leaf #1
64 × 400G
│
┌─────────┴─────────┐
│ │
Uplink 28 Downlink ≤36이 구조를 Leaf 4대에 반복하면 최대 server-facing capacity는:
36 × 4 = 144 ports
입니다.
필요한 건 134 ports이므로:
144 - 134 = 10 spare
가 정확하게 나옵니다.
대역폭도 계산해보면
Server-facing은:
134 × 400G = 53.6 Tb/s
Leaf→Spine은:
112 × 400G = 44.8 Tb/s
따라서:
53.6 / 44.8 = 1.196 : 1
즉 약:
1.20 : 1 oversubscription
입니다.
다르게 말하면 최악의 all-to-all 상황에서 uplink bandwidth는 downlink 총 bandwidth의 약 83.6%입니다.
그래서 사진에 적힌 1:1.03, 1:1.1 Blocking이라는 숫자는 현재 24 GPU-links + 110 Storage-links + 112 uplinks라는 수량만 놓고 계산하면 나오지 않습니다.
이 부분은 업체에 산정 근거를 요청하는 게 좋습니다.
Spine 쪽은 충분합니다
Spine은 2 × 64 port이므로:
Spine01 56 used / 64
Spine02 56 used / 64라고 균등하게 배분할 수 있습니다.
112 uplink / 2 = 56 links per Spine이므로:
Spine당 8개의 400G logical port spare
입니다.
즉:
Spine01 Spine02
56 / 64 56 / 64
│ │
┌─────────┼────────┐ ┌────────┼─────────┐
│ │ │ │ │ │
14 14 14 14 ... 14
│ │ │ │ │
Leaf1 Leaf2 Leaf3 Leaf4처럼 구성 가능합니다.
이 부분은 깔끔합니다.
실제 Leaf 분배도 가능합니다
예를 들어 다음처럼 배치할 수 있습니다.
SPINE 01 SPINE 02
▲ ▲
│ │
14│ │14
│ │
┌──────┴──────────────┴──────┐
│ LEAF 01 │
│ 28 uplink / 34 downlink │
└────────────┬───────────────┘
│
GPU 3대 ×2 = 6
Storage 14×2 =28
│
total 34Leaf 1~3:
GPU 3 nodes = 6 ports
Storage 14 nodes = 28 ports
────────────────────────────
Downlink = 34
Uplink = 28
Total = 62 / 64
Spare = 2Leaf 4:
GPU 3 nodes = 6
Storage 13 nodes = 26
──────────────────────
Downlink = 32
Uplink = 28
Total = 60 / 64
Spare = 4전체적으로:
| Leaf | GPU | Storage | Downlink | Uplink | Total | Spare |
|---|---|---|---|---|---|---|
| LF01 | 3 | 14 | 34 | 28 | 62 | 2 |
| LF02 | 3 | 14 | 34 | 28 | 62 | 2 |
| LF03 | 3 | 14 | 34 | 28 | 62 | 2 |
| LF04 | 3 | 13 | 32 | 28 | 60 | 4 |
| Total | 12 | 55 | 134 | 112 | 246 | 10 |
수학적으로 정확하게 들어갑니다.
그런데 여기서 중요한 문제가 하나 있습니다
GPU 한 대의 NDR 두 포트를 같은 Leaf에 꽂으면 안 됩니다.
앞에서 단순 수량 계산 때문에 GPU 3대를 한 Leaf에 묶어 그렸지만, HA/failure-domain 관점에서는 실제 케이블링은 다르게 해야 합니다.
예를 들어 GPU01:
GPU01
CX7-0 ──400G── Leaf01
CX7-1 ──400G── Leaf02GPU02:
CX7-0 ── Leaf02
CX7-1 ── Leaf03GPU03:
CX7-0 ── Leaf03
CX7-1 ── Leaf04식으로 분산하는 게 좋습니다.
AIStor도 마찬가지입니다.
AIStor01
CX7-0 ── Leaf01
CX7-1 ── Leaf02즉 하나의 Leaf 장애로 Storage node의 두 NDR path가 동시에 없어지지 않게 해야 합니다.
그런데 이게 원 제안서의 “상면 혼합배치”와 관련 있어 보입니다
사진에 있는:
스토리지서버가 GPU서버와 상면혼합배치구성
이라는 문구가 의미가 있습니다.
아마 업체도:
Rack A
GPU
Storage
Leaf
Rack B
GPU
Storage
Leaf
Rack C
GPU
Storage
Leaf
Rack D
GPU
Storage
Leaf형태로 분산시키려는 것으로 보입니다.
그러면 GPU↔Storage traffic이 일부는 같은 Leaf에서 끝납니다.
GPU
│
Leaf
│
AIStor이 traffic은 Spine uplink를 소비하지 않습니다.
반대로 다른 Leaf에 있는 AIStor를 접근하면:
GPU
│
Leaf01
│
Spine
│
Leaf03
│
AIStor이렇게 됩니다.
그래서 업체가 말하는 실제 effective blocking ratio가 단순 134/112 = 1.196보다 좋다고 계산됐을 가능성은 있습니다.
하지만 그걸 1:1.03이나 1:1.1이라고 표현하려면 traffic locality를 포함한 계산 근거가 필요합니다.
더 큰 문제는 GPU 4-port를 모두 쓰고 싶을 때입니다
현재 BOM은 분명히:
12 GPU × 2 = 24
기준입니다.
그런데 GPU의 4×400G를 전부 연결하면:
GPU
12 × 4 = 48
Storage
55 × 2 = 110
Total downlink
= 158이 됩니다.
현재 112 uplink를 그대로 유지하면:
158 + 112 = 270
Leaf port가 필요합니다.
하지만 4 Leaf의 capacity는:
4 × 64 = 256
밖에 없습니다.
즉:
GPU 4×400G 전 포트 활성화는 현재 4 Leaf 구성에 안 들어갑니다.
이건 중요한 결론입니다.
GPU 4포트를 전부 쓰려면
최소 Leaf 1대를 추가해야 합니다.
예를 들어:
Leaf ×5
Total port
5 × 64
= 320가 되면 여유가 생깁니다.
하지만 그때는 Spine uplink 설계도 다시 해야 합니다.
따라서 현재 2 Spine + 4 Leaf = 6 switch BOM은 명확하게:
GPU 2×400G/node + AIStor 2×400G/node
를 목표로 한 최적화된 구성입니다.
성능 관점에서도 GPU 2-port면
GPU 측 aggregate:
12 × 2 × 400G = 9.6 Tb/s
Storage 측:
55 × 2 × 400G = 44 Tb/s
입니다.
즉 GPU↔AIStor workload만 생각하면:
GPU side
9.6 Tb/s
│
▼
NDR Fabric
│
▼
AIStor side
44 Tb/s이므로 Storage network가 GPU 쪽보다 훨씬 큽니다.
다만 NDR Fabric은 Storage용만이 아니라 GPU↔GPU NCCL distributed training도 담당하므로 GPU당 2×400G = 800Gb/s가 B300 workload에 충분한지는 별도로 benchmark해야 합니다.
이게 제가 이 설계에서 가장 확인하고 싶은 부분입니다.
최종 판정
“장비가 모자라나?” → 아닙니다. 현재 제안 조건에는 정확하게 맞습니다.
다만 여유가 큰 설계는 아닙니다.
GPU 12 × 2 = 24
AIStor 55 × 2 = 110
──────────────────────────
Downlink 134
Leaf-Spine 112
──────────────────────────
Total links 246
Leaf capacity
4 × 64 256
Spare 10따라서 Leaf port 기준 여유율은 약 3.9%뿐이고, downlink:uplink는 약 1.20:1입니다. NVIDIA는 QM9700/QM9790을 64-port NDR non-blocking switch로 명시하고 있으므로 이 계산에서 64 logical 400G port를 사용하는 것은 맞습니다. NVIDIA Docs
제가 발주 전이라면 업체에 딱 세 가지를 확인하겠습니다: ① 1:1.03 / 1:1.1 Blocking 산식과 traffic locality 가정, ② GPU의 4개 CX-7 중 왜 2개만 NDR에 연결하는지와 B300/NCCL 성능 근거, ③ Leaf 하나 장애 시 GPU와 AIStor의 두 NDR 포트가 서로 다른 Leaf에 물려 살아남도록 포트맵이 설계되어 있는지입니다.
특히 ②가 중요합니다. 현재 6대 switch BOM은 실수로 24포트를 산정한 게 아니라면, 사실상 GPU 4×400G 중 2개만 사용하는 것을 전제로 switch 수를 최적화한 설계라고 보는 게 맞습니다.
