26Z29c

QK·2026년 8월 28일

좋습니다. 현재 구성에서는 단순한 RDMA bandwidth test가 아니라 E810 → RoCEv2 → AIStor → B300/vLLM까지의 end-to-end benefit을 증명하는 형태로 잡는 것이 맞습니다.

먼저 현재 공식 문서를 다시 확인한 결과, GPU Operator 26.3.x는 RHEL 10.2 + Kubernetes 1.33을 지원합니다. 다만 NVIDIA가 명시한 GPUDirect RDMA 지원 조합은 별도의 matrix이며, NVIDIA Network Operator의 검증 NIC는 ConnectX/BlueField 계열입니다. 따라서 Intel E810에서 GPUDirect RDMA는 이번 POC에서 반드시 별도 검증해야 하는 항목으로 두는 것이 안전합니다. (NVIDIA Docs)

또한 NVIDIA는 GPUDirect RDMA에서 host-memory RDMA와 GPU-memory RDMA를 ib_write_bw로 비교하고, 지원되는 환경에서는 --use_cuda_dmabuf를 이용해 DMA-BUF 경로를 검증하는 방법을 제시하고 있습니다. (NVIDIA Docs)

1. 전체 Execution Flow

이번 POC는 다음 순서로 진행하는 것을 권장합니다.

Phase 0   Hardware / OS / PCIe
    ↓
Phase 1   TCP baseline
    ↓
Phase 2   E810 Host-memory RDMA
    ↓
Phase 3   QP / message-size scaling
    ↓
Phase 4   RoCEv2 + PFC/ECN
    ↓
Phase 5   Cilium + RoCE coexistence
    ↓
Phase 6   B300 GPU-memory RDMA
    ↓
Phase 7   DMA-BUF GPUDirect RDMA
    ↓
Phase 8   AIStor S3 baseline
    ↓
Phase 9   AIStor RDMA-capable path
    ↓
Phase 10  vLLM
    ↓
Phase 11  Soak / failure / lifecycle
    ↓
FINAL ARCHITECTURE DECISION

특히 Phase 2 → 6 → 8 → 9 순서가 중요합니다.

그래야 문제가 발생했을 때:

E810/RoCE 문제인지
GPUDirect RDMA 문제인지
AIStor 문제인지
vLLM application 문제인지

분리할 수 있습니다.

2. Benchmark 환경

이번 테스트의 기준 환경은 다음으로 고정합니다.

항목	기준
OS	RHEL 10.2
Kubernetes	1.33
GPU	NVIDIA B300
GPU Operator	26.3.x
NIC	Intel E810
NIC driver	`ice`
RDMA driver	`irdma`
Protocol	RoCEv2
K8s network	Cilium
bond0	External
bond1	Internal / LACP
Storage	MinIO AIStor
AIStor 위치	별도 K8s cluster
QoS	PFC / ECN 별도 검증
GPU↔NIC	PCIe topology 반드시 기록

GPU Operator 26.3.3은 Kubernetes 1.33을 지원하며, 26.3 계열의 구성요소에는 NVIDIA driver, Container Toolkit, Device Plugin, DCGM Exporter, NFD 등이 포함됩니다. (NVIDIA Docs)

3. Phase 0 — Hardware Baseline

GPU node에서 먼저:

cat /etc/redhat-release
uname -r

lscpu
numactl -H

lspci -nn | grep -Ei 'NVIDIA|Ethernet|Intel'

lspci -tv

nvidia-smi -q
nvidia-smi topo -m

E810:

ethtool -i <e810-interface>
ethtool <e810-interface>

cat /proc/net/bonding/bond1

RDMA:

lsmod | grep -E 'ice|irdma'
rdma link
ibv_devices
ibv_devinfo

반드시 기록할 것

GPU PCI address
E810 PCI address
PCIe generation
PCIe width
GPU NUMA
NIC NUMA
GPU↔NIC topology
E810 firmware
ice version
irdma version
NVIDIA driver
CUDA version

PASS

B300 정상 인식
E810 정상 인식
ice 정상
irdma 정상
RDMA device 정상
bond1 정상
예상 PCIe Gen/width
GPU/NIC NUMA locality 기록 완료

4. Phase 1 — TCP Baseline

먼저 RDMA를 사용하지 않습니다.

E810 ↔ AIStor node 또는 테스트용 E810 node 사이에서:

Server

iperf3 -s

Client

iperf3 -c <server-ip> -P 1 -t 60
iperf3 -c <server-ip> -P 4 -t 60
iperf3 -c <server-ip> -P 8 -t 60
iperf3 -c <server-ip> -P 16 -t 60

테스트 size는 iperf3보다는 실제 RDMA benchmark와 맞추기 위해 이후 storage benchmark에서:

64 KB
1 MB
16 MB
256 MB
1 GB

를 사용합니다.

측정

Bandwidth
CPU utilization
TCP retransmission
RTT
NIC utilization
packet drop/error

이 값이 모든 최적화의 baseline입니다.

5. Phase 2 — Host-memory RDMA

여기서는 GPU를 완전히 배제합니다.

E810
  │
RoCEv2
  │
E810

Server

ib_write_bw -d <rdma_dev> -a

Client

ib_write_bw -d <rdma_dev> <server-ip> -a

NVIDIA 역시 RDMA network troubleshooting에서 ib_write_bw를 node-to-node bandwidth 측정의 기본 도구로 제시합니다. (NVIDIA Docs)

6. Message Size Matrix

다음 정도면 충분합니다.

4 KB
64 KB
1 MB
4 MB
16 MB
64 MB
256 MB
1 GB

다만 실제 RoCE 성능 tuning에서는:

Small message

4KB
64KB

→ latency / packet processing

Medium

1MB
4MB
16MB

→ 일반 workload

Large

64MB
256MB
1GB

→ GPU/storage bulk transfer

로 구분해서 봅니다.

7. QP Scaling

각 message size에서:

QP = 1
QP = 2
QP = 4
QP = 8
QP = 16
QP = 32

까지 테스트합니다.

예:

ib_write_bw \
  -d <dev> \
  -q 1 \
  -s 1048576 \
  -D 60

이후:

-q 2
-q 4
-q 8
-q 16
-q 32

으로 증가.

8. 이 테스트의 핵심 결과

예를 들어:

QP	BW
1	5 GB/s
2	8 GB/s
4	10.5 GB/s
8	11.7 GB/s
16	11.8 GB/s
32	11.8 GB/s

라면:

8 QP 이후 saturation

이라고 판단합니다.

이 값은 나중에 application tuning의 근거가 됩니다.

9. Phase 3 — RDMA Latency

ib_write_lat
ib_read_lat
ib_send_lat

size:

1 B
64 B
256 B
1 KB
4 KB

각각:

average
min
max
P99

를 기록합니다.

10. Phase 4 — PFC / ECN

세 가지 환경을 비교합니다.

A

PFC OFF
ECN OFF

B

PFC ON
ECN OFF

C

PFC ON
ECN ON

동일한 workload를 반복합니다.

11. Congestion Test

동시 flow:

RoCE bandwidth를 증가시키면서:

PFC pause
ECN marking
packet drop
RDMA retry/error
latency

를 측정합니다.

12. Cilium 영향 테스트

현재 구조에서 매우 중요한 테스트입니다.

동시에:

Cilium traffic
+
RoCE traffic

을 발생시킵니다.

Cilium utilization:

50%
70%
90%

RoCE:

10%
30%
50%
70%

수준으로 조합합니다.

예:

                 bond1
                   │
          ┌────────┴────────┐
          │                 │
       Cilium              RoCE
       70%                  30%
          │                 │
          └──────┬──────────┘
                 │
             E810/LACP

PASS 기준

기본값으로는:

PFC/ECN 적용 후 Cilium P99 latency 또는 error rate가 baseline 대비 5% 이상 악화되지 않는 것

을 권장합니다.

조직의 실제 SLO가 있다면 그 값을 우선합니다.

13. Phase 5 — LACP/Bonding

가능하다면:

Single E810 port
vs
bond1 LACP

비교합니다.

Intel E810의 RDMA+LAG는 driver/NVM/RoCEv2 및 구성 조건의 영향을 받기 때문에 이 테스트는 특히 중요합니다.

결과:

Single
94 Gbps

Bond
92 Gbps

라면 매우 양호합니다.

반대로:

Single 94
Bond   70

이면 bonding/RDMA interaction을 별도로 조사해야 합니다.

14. Phase 6 — B300 GPU-memory RDMA

여기부터 핵심입니다.

Host memory

CPU RAM
 ↓
E810
 ↓
RoCE
 ↓
E810
 ↓
CPU RAM

GPU memory

B300 HBM
 ↓
E810
 ↓
RoCE
 ↓
E810
 ↓
CPU RAM

를 비교합니다.

NVIDIA도 GPUDirect RDMA troubleshooting에서 host-memory와 GPU-memory ib_write_bw 결과를 비교하도록 안내합니다. (NVIDIA Docs)

15. GPU RDMA Test

환경에서 CUDA-enabled perftest가 제공된다면:

ib_write_bw \
  -d <dev> \
  --use_cuda=0 \
  <server-ip> \
  -a

이후:

QP 1
QP 4
QP 8
QP 16

을 반복합니다.

16. Phase 7 — DMA-BUF GPUDirect RDMA

가장 중요한 시험입니다.

ib_write_bw \
  -d <dev> \
  --use_cuda=0 \
  --use_cuda_dmabuf \
  <server-ip> \
  -a

단, 현재 perftest/kernel/driver 조합에서 해당 option이 실제 지원되는지 먼저 확인해야 합니다.

NVIDIA가 제시하는 DMA-BUF 방식이 이 경로입니다. NVIDIA는 GPUDirect RDMA에서 DMA-BUF를 nvidia-peermem보다 권장하며, 최근 GPU Operator에서는 적절한 driver branch에서 Open GPU Kernel module 사용을 권장합니다. (NVIDIA Docs)

17. GPUDirect RDMA의 PASS 기준

여기서는 단순히 "command가 성공"하면 PASS로 하지 않는 것이 좋습니다.

PASS 조건

실제 GPU memory buffer 사용
DMA-BUF path 확인
RDMA bandwidth 측정 가능
반복 테스트에서 안정적
CPU overhead 감소
GPU↔NIC PCIe path 정상
RDMA error 없음

특히 Intel E810에서 이 단계가 이번 POC의 가장 중요한 기술적 risk입니다.

NVIDIA의 공식 Network Operator 지원 목록은 NVIDIA ConnectX/BlueField NIC을 대상으로 합니다. (NVIDIA Docs)

따라서:

E810 RoCE PASS ≠ E810 GPUDirect RDMA 공식 지원 PASS

로 구분해야 합니다.

18. Phase 8 — AIStor TCP/S3 Baseline

이제 실제 AIStor입니다.

Object size:

4 KB
64 KB
1 MB
4 MB
16 MB
64 MB
256 MB
1 GB

Concurrency:

각 조합에서:

PUT
GET
Mixed GET/PUT

을 측정합니다.

19. AIStor에서 수집할 KPI

Application

PUT GB/s
GET GB/s
IOPS
P50 latency
P95
P99

Node

CPU
memory
network RX/TX
network drops
NIC errors

AIStor

API latency
API request rate
bytes in/out
drive utilization
drive latency
erasure-set activity
quorum errors

현재 운영 중인 Prometheus/AIStor metric 이름은 설치된 AIStor 버전에 맞춰 실제 /metrics에서 mapping하는 것을 권장합니다.

20. AIStor 병목 분석

예를 들어:

Network 95%
Disk    40%
CPU     30%

이면:

Network-bound

입니다.

반대로:

Network 40%
Disk    95%

이면:

Storage-bound

입니다.

이 차이가 매우 중요합니다.

Storage-bound인데 RDMA를 적용해도 AIStor 성능은 거의 안 올라갑니다.

21. Phase 9 — AIStor RDMA

여기서는 반드시 AIStor가 실제로 지원하는 RDMA data path를 먼저 확인해야 합니다.

중요한 점:

E810 + RDMA NIC

을 설치했다고:

S3 → RDMA

가 자동으로 되는 것은 아닙니다.

즉:

일반 S3
 ↓
HTTP
 ↓
TCP

과

GPU/Object Storage direct path
 ↓
RDMA

는 별개의 architecture입니다.

NVIDIA도 GPU↔storage direct path를 GDS로 별도 정의하고 있으며, 최근에는 object storage용 cuObject 같은 별도 data path를 제공하고 있습니다. (NVIDIA Docs)

따라서 AIStor vendor가 제공하는 실제 RDMA-enabled interface/API/data path가 무엇인지 확인한 후 T11을 실행해야 합니다.

22. Phase 10 — vLLM

최종 benchmark입니다.

Prompt:

1K tokens
8K tokens
32K tokens

Output:

256
1K
4K

Concurrency:

23. vLLM KPI

최소:

TTFT
TPOT
ITL
tokens/sec
requests/sec
GPU utilization
GPU memory
CPU utilization
network throughput
AIStor throughput

그리고:

P50
P95
P99

를 기록합니다.

24. 최종 비교 Scenario

이 4개를 비교하면 아주 좋은 engineering conclusion이 나옵니다.

Scenario A

vLLM
 ↓
TCP
 ↓
AIStor

Scenario B

vLLM
 ↓
RoCE-capable path
 ↓
AIStor

Scenario C

vLLM
 ↓
GPU RDMA
 ↓
AIStor

Scenario D

vLLM
 ↓
GPUDirect/DMA-BUF
 ↓
AIStor

단, C/D는 실제 AIStor가 지원하는 data path가 있는 경우에만 비교합니다.

25. Prometheus/Grafana Dashboard

이번 POC에는 별도의 Benchmark dashboard를 하나 만드는 것을 권장합니다.

Panel 1 — GPU

GPU Utilization
GPU Memory Used
GPU Memory BW
PCIe TX
PCIe RX
Power
Temperature

DCGM Exporter가 GPU Operator에 포함됩니다. (NVIDIA Docs)

Panel 2 — NIC

RX bytes
TX bytes
RX packets
TX packets
drops
errors

Panel 3 — RDMA

RDMA BW
RDMA packets
RDMA errors
retry
congestion

Panel 4 — PFC

PFC pause frames
PFC duration
per-priority pause

Panel 5 — ECN

ECN marked packets
congestion events

Panel 6 — Cilium

packet drops
forwarding
latency
TCP connections

Panel 7 — AIStor

GET
PUT
request rate
request latency
bytes
drive latency
drive utilization
quorum

Panel 8 — vLLM

TTFT
TPOT
ITL
tokens/sec
requests/sec

26. 가장 중요한 Grafana 화면

저라면 POC 동안 아래를 한 화면에 배치합니다.

┌───────────────────────────────────────────────────┐
│                 GPU / NETWORK                     │
├──────────────┬───────────────┬────────────────────┤
│ GPU Util     │ NIC TX/RX     │ RDMA BW            │
├──────────────┼───────────────┼────────────────────┤
│ CPU          │ PFC           │ ECN                │
├──────────────┴───────────────┴────────────────────┤
│               AIStor Throughput                   │
├───────────────────────────────────────────────────┤
│               AIStor Latency P99                  │
├───────────────────────────────────────────────────┤
│               vLLM Tokens/sec                     │
├───────────────────────────────────────────────────┤
│               vLLM TTFT / TPOT                    │
└───────────────────────────────────────────────────┘

이렇게 하면 "RDMA를 켰더니 실제 application이 빨라졌는가?"를 한 화면에서 볼 수 있습니다.

27. Default PASS/FAIL 기준

초기 POC에서는 아래처럼 잡는 것을 추천합니다.

항목	PASS 기준
E810 RDMA	error 없이 안정적으로 동작
Host RDMA BW	실측 가능한 line-rate의 ≥90%
QP scaling	saturation point 확인
RDMA latency	반복 측정 ±5% 이내 재현성
PFC	congestion 상황에서 loss/error 억제
ECN	congestion 상황에서 tail latency 개선
Cilium	baseline 대비 P99 degradation ≤5%
Bond	single-port 대비 ≥90%
GPU RDMA	GPU memory buffer 사용 확인
DMA-BUF	실제 DMA-BUF path 확인
GPUDirect	반복 테스트 안정성 확보
AIStor	baseline 대비 의미 있는 KPI 개선
vLLM	TTFT/TPOT/tokens/sec 개선
Soak	unexplained RDMA/NIC/storage error 0
Reboot	GPU/RDMA resource 자동 복구

여기서 90%, 5%는 제안 default 값이고 실제 SLO/제품 요구사항이 있다면 그것을 우선해야 합니다.

28. Excel Benchmark Plan

실제 실행할 수 있도록 Excel 파일도 만들어 두었습니다.

AIStor B300/E810/RoCE Benchmark Test Plan 다운로드

파일에는 다음 Sheet가 들어 있습니다.

`Benchmark Plan`

16개 test case:

T00 Hardware/OS
T01 TCP baseline
T02 Host RDMA bandwidth
T03 RDMA latency
T04 QP scaling
T05 PFC/ECN
T06 Cilium + RoCE
T07 LACP
T08 GPU-memory RDMA
T09 DMA-BUF GPUDirect RDMA
T10 AIStor S3
T11 AIStor RDMA path
T12 CPU vs GPU-direct storage
T13 vLLM baseline
T14 vLLM optimized path
T15 Soak/failure
T16 Reboot/upgrade

각 항목에:

Server/client command
Data/message size
QP/concurrency
Duration
Metrics
Purpose
PASS/FAIL criteria
Priority
Run 1/2/3
Median
Owner
Date
Evidence/Log

까지 넣었습니다.

`Metrics`

Prometheus/Grafana에서 수집할 metric category를 정리했습니다.

`Decision Criteria`

최종 architecture 판단 기준입니다.

`Environment`

현재 POC 환경을 고정해 놓았습니다.

29. 특히 T09를 "Go/No-Go Gate"로 두는 것을 추천

이번 POC에서 가장 중요한 것은 사실 이것입니다.

                   E810
                    │
                RoCEv2
                    │
              ┌─────┴─────┐
              │           │
           Host RAM     B300 HBM
              │           │
              │       DMA-BUF
              │           │
              └─────┬─────┘
                    │
                 RDMA

T02에서:

E810 RoCE가 잘 된다.

와

T09에서:

B300 HBM ↔ E810이 실제 DMA-BUF GPUDirect RDMA로 연결된다.

는 완전히 다른 문제입니다.

그리고 현재 NVIDIA 문서상 GPUDirect RDMA 지원은 일반 GPU Operator 지원 matrix와 별도로 관리되고, Network Operator의 검증 NIC도 NVIDIA ConnectX/BlueField 계열입니다. 따라서 E810은 "지원된다고 가정"하지 않고 POC에서 검증된 결과로 판단하는 것이 엔지니어링적으로 맞습니다. (NVIDIA Docs)

30. 최종 의사결정 기준

최종 보고서는 아래처럼 만들면 좋습니다.

                 ┌───────────────┐
                 │  TCP baseline │
                 └───────┬───────┘
                         ↓
                  Host RDMA PASS?
                         ↓
                    QP scaling
                         ↓
                  PFC / ECN
                         ↓
              Cilium coexistence
                         ↓
                 GPU RDMA PASS?
                    /          \
                  NO            YES
                  │              │
            Stop GPUDirect     DMA-BUF
                                ↓
                          GPUDirect PASS?
                           /          \
                         NO            YES
                         │              │
                    RoCE-only      AIStor path
                                      ↓
                                  vLLM test
                                      ↓
                              Business benefit?
                               /             \
                             NO              YES
                             │                │
                      TCP/RoCE 유지      GPUDirect 도입

제 판단으로는

현재 환경에서는 처음부터 Network Operator/PFC/GPUDirect/vLLM을 한꺼번에 올리지 않는 것이 가장 중요합니다.

먼저:

E810 → RoCEv2 → AIStor의 network baseline

을 만들고,

그 다음:

B300 → E810 GPUDirect RDMA

를 증명한 뒤,

마지막에:

AIStor → vLLM의 실제 workload 개선

을 확인해야 합니다.

이 순서라야 나중에 "GPUDirect RDMA를 도입했는데 실제 AIStor/vLLM 성능은 왜 안 좋아졌지?" 같은 상황이 발생해도 어느 계층이 병목인지 설명할 수 있습니다.

engineer

이전 포스트

26Z29b

다음 포스트

26Z29c

1. 전체 Execution Flow

2. Benchmark 환경

3. Phase 0 — Hardware Baseline

반드시 기록할 것

PASS

4. Phase 1 — TCP Baseline

Server

Client

측정

5. Phase 2 — Host-memory RDMA

Server

Client

6. Message Size Matrix

Small message

Medium

Large

7. QP Scaling

8. 이 테스트의 핵심 결과

9. Phase 3 — RDMA Latency

10. Phase 4 — PFC / ECN

A

B

C

11. Congestion Test

12. Cilium 영향 테스트

PASS 기준

13. Phase 5 — LACP/Bonding

14. Phase 6 — B300 GPU-memory RDMA

Host memory

GPU memory

15. GPU RDMA Test

16. Phase 7 — DMA-BUF GPUDirect RDMA

17. GPUDirect RDMA의 PASS 기준

PASS 조건

18. Phase 8 — AIStor TCP/S3 Baseline

19. AIStor에서 수집할 KPI

Application

Node

AIStor

20. AIStor 병목 분석

21. Phase 9 — AIStor RDMA

22. Phase 10 — vLLM

23. vLLM KPI

24. 최종 비교 Scenario

Scenario A

Scenario B

Scenario C

Scenario D

25. Prometheus/Grafana Dashboard

Panel 1 — GPU

Panel 2 — NIC

Panel 3 — RDMA

Panel 4 — PFC

Panel 5 — ECN

Panel 6 — Cilium

Panel 7 — AIStor

Panel 8 — vLLM

26. 가장 중요한 Grafana 화면

27. Default PASS/FAIL 기준

28. Excel Benchmark Plan

Benchmark Plan

Metrics

Decision Criteria

Environment

29. 특히 T09를 "Go/No-Go Gate"로 두는 것을 추천

30. 최종 의사결정 기준

제 판단으로는

26Z29b

26Z29d

0개의 댓글

`Benchmark Plan`

`Metrics`

`Decision Criteria`

`Environment`