좋습니다. 지금까지의 조건을 합치면 단순히 “RoCE가 된다/안 된다”를 보는 테스트가 아니라, 최종적으로 “B300 GPU node를 AIStor의 compute/storage architecture에 어떻게 배치하는 것이 가장 좋은가”를 수치로 결정하는 POC로 설계하는 게 좋습니다.

특히 이번에는 RHEL 10.2 + K8s 1.33 + B300 + Intel E810 + bond1(LACP active-active) + RoCEv2 + AIStor 별도 K8s cluster라는 조건이므로, 성능시험을 다음 5단계로 분리하는 것을 추천합니다.

---

1. 먼저 이번 POC에서 증명해야 할 것

최종적으로 아래 질문에 답할 수 있어야 합니다.

Q1. E810 자체의 RDMA 성능은 충분한가?

E810 ───── RoCEv2 ───── E810

Q2. 기존 bond1/LACP 위에서 RDMA를 사용해도 성능/안정성 문제가 없는가?

Cilium traffic
       +
RoCEv2
       ↓
     bond1

Q3. PFC/ECN을 적용하면 RoCE 성능과 기존 Cilium traffic에 어떤 영향이 있는가?

Normal traffic → P0
RoCE           → P3
                 ↓
              PFC/ECN

Q4. B300에서 실제 GPUDirect RDMA가 E810과 동작하는가?

B300 HBM
   ↓
GPUDirect RDMA
   ↓
E810
   ↓
RoCEv2

Q5. 최종적으로 AIStor에서 얻는 실효 성능이 얼마나 되는가?

B300/vLLM
     ↓
  network
     ↓
   AIStor

그리고 Q5가 가장 중요합니다.

왜냐하면 RDMA benchmark가 100Gbps라고 해도 실제 AI workload가 20Gbps밖에 못 쓰면 architecture 관점에서는 의미가 달라지기 때문입니다.

---

2. 전체 성능시험 Matrix

제가 권하는 테스트 matrix는 다음과 같습니다.

단계	비교	주요 목적
T0	NIC/PCIe baseline	하드웨어 병목 확인
T1	TCP vs RDMA	RDMA 자체 이득 확인
T2	1 QP vs multi-QP	E810/RoCE 최대 성능 확인
T3	host memory RDMA	순수 RDMA 성능
T4	GPU memory RDMA	GPUDirect RDMA 효과
T5	PFC OFF vs ON	lossless QoS 효과
T6	ECN OFF vs ON	congestion control 효과
T7	Cilium alone vs Cilium+RoCE	기존 K8s traffic 영향
T8	bond1 vs dedicated NIC path	LACP 구조의 비용
T9	S3/TCP AIStor	실제 object storage baseline
T10	RDMA AIStor path	AIStor RDMA 실효 성능
T11	local storage vs AIStor	storage bottleneck
T12	vLLM workload	최종 business 성능

이걸 한 번에 다 하는 것이 아니라 단계별 Gate로 운영하는 것이 좋습니다.

---

3. T0 — 하드웨어/PCIe baseline

가장 먼저 해야 합니다.

확인할 것

GPU node:

lspci -tv

nvidia-smi topo -m

lspci -vv -s <E810_PCI_ADDRESS>

GPU:

nvidia-smi -q

E810:

ethtool -i <port>
ethtool <port>

---

특히 PCIe link

E810이:

PCIe Gen5 x16

인지 확인합니다.

B300과 E810 사이의 PCIe topology도 중요합니다.

예를 들어:

        CPU/PCIe Root
          /       \
       B300       E810

과

        CPU
         |
      PCIe Root
         |
      PCIe switch
       /       \
     B300      E810

은 latency/topology가 다릅니다.

NVIDIA도 GPU/network/storage performance를 평가할 때 PCIe topology와 interconnect bandwidth/latency를 함께 측정해야 한다고 설명합니다. (NVIDIA Docs)

Gate

여기서는:

PCIe negotiated width
PCIe generation
NUMA
GPU↔NIC locality

를 기록합니다.

---

4. T1 — TCP vs RDMA

이 시험이 매우 중요합니다.

왜냐하면 사용자 환경에는 이미:

Cilium
+
25/100Gb Ethernet
+
AIStor

가 있기 때문입니다.

RDMA를 추가했을 때 TCP 대비 얼마나 좋아지는지가 engineering justification의 핵심입니다.

---

TCP

예:

iperf3 -s

client:

iperf3 -c <server> -P 1
iperf3 -c <server> -P 8
iperf3 -c <server> -P 16

측정:

Bandwidth
CPU%
Latency
packet retransmission

---

RDMA

ib_write_bw <server>

그리고:

ib_write_bw -q 1 <server>
ib_write_bw -q 4 <server>
ib_write_bw -q 8 <server>
ib_write_bw -q 16 <server>

---

비교

예를 들어 결과가:

	TCP	RDMA
Bandwidth	85Gbps	94Gbps
CPU	65%	12%
Latency	80µs	12µs

라면:

"RDMA의 핵심 이점은 10% bandwidth 증가보다 CPU utilization 80% 감소와 latency 감소"

라고 설명할 수 있습니다.

이런 식으로 단순 bandwidth가 아니라 CPU/latency까지 포함해서 평가해야 합니다.

RDMA의 본질적인 장점도 network device가 application memory에 직접 데이터를 전송하여 throughput을 높이고 latency를 낮추는 것입니다. (Intel)

---

5. T2 — 1 QP → Multi QP

RDMA에서는 반드시 해보세요.

ib_write_bw -q 1
ib_write_bw -q 2
ib_write_bw -q 4
ib_write_bw -q 8
ib_write_bw -q 16

message size도:

4KB
64KB
1MB
4MB
16MB

정도로 변경합니다.

---

기대하는 그래프

Bandwidth
  │
  │                    ───────
  │              ─────
  │          ────
  │      ───
  │  ───
  └────────────────────────────
      1  2  4  8  16 QP

어느 지점에서 saturation되는지 확인합니다.

이것이 중요한 이유

E810이 예를 들어 100Gbps NIC라면:

100Gbps
≈ 12.5GB/s

입니다.

그런데 실제:

1 QP → 5GB/s
4 QP → 10GB/s
8 QP → 11.8GB/s
16 QP → 11.9GB/s

라면 8 QP 이후는 의미가 없습니다.

이 결과는 이후 vLLM/RDMA application의 QP 설정 근거가 됩니다.

---

6. T3 — Host Memory RDMA

이것을 GPUDirect RDMA의 baseline으로 잡습니다.

CPU RAM
  ↓
E810
  ↓
RoCE
  ↓
E810
  ↓
CPU RAM

테스트:

ib_write_bw
ib_read_bw
ib_send_bw

각각:

Write

local → remote

Read

remote → local

Send

message-oriented

를 비교합니다.

---

7. 반드시 Latency도 측정

ib_write_lat
ib_read_lat
ib_send_lat

small message:

1B
64B
256B
1KB
4KB

를 봅니다.

이 결과는:

latency vs message size

그래프로 만들면 좋습니다.

---

8. T4 — 가장 중요한 GPUDirect RDMA 비교

여기서:

A

GPU
 ↓
CPU RAM
 ↓
E810

B

GPU
 ↓
GPUDirect RDMA
 ↓
E810

를 비교합니다.

NVIDIA도 GPUDirect RDMA의 핵심을 GPU와 PCIe peer device 사이의 직접 데이터 교환으로 설명하며, CPU host memory를 거치는 경로를 피하는 것이 핵심입니다. (NVIDIA Docs)

---

9. GPU memory RDMA test

환경에 맞는 perftest를 CUDA 지원으로 build/install합니다.

일반적으로:

ib_write_bw \
    --use_cuda=0 \
    <server>

그리고 DMA-BUF가 지원되는 build라면:

ib_write_bw \
    --use_cuda=0 \
    --use_cuda_dmabuf \
    <server>

NVIDIA NCCL troubleshooting 문서에서도 host-memory와 GPU-memory ib_write_bw를 비교하고 DMA-BUF 옵션을 별도로 테스트하는 방식을 제시합니다. (NVIDIA Docs)

---

10. GPUDirect RDMA의 핵심 비교표

이걸 꼭 만들었으면 합니다.

Test	Path	Bandwidth	Latency	CPU
H1	Host RAM → E810
H2	Host RAM ← E810
G1	GPU → E810
G2	E810 → GPU
G3	GPU ↔ E810 DMA-BUF

여기서:

G1 / H1
G2 / H2

를 비교합니다.

---

11. GPUDirect RDMA의 성공 기준

단순히 command가 성공했다고 끝내면 안 됩니다.

다음 세 가지를 봅니다.

① Bandwidth

GPU RDMA ≥ Host RDMA의 90~95%

정도가 나오는지.

② CPU

GPU RDMA CPU utilization << TCP

인지.

③ GPU utilization

GPU memory transfer 중:

nvidia-smi dmon

등으로 GPU utilization/PCIe throughput을 확인합니다.

---

12. 그런데 여기서 E810의 가장 중요한 리스크

이 시험에서 E810이 실제 GPU memory DMA-BUF peer로 동작하는지가 이번 POC의 가장 중요한 기술적 Gate입니다.

NVIDIA 공식 GPUDirect RDMA 지원 matrix는 RHEL과 Network Operator 조합을 별도로 명시하고 있으며, 현재 문서의 지원 조합은 NVIDIA 네트워크 stack 중심입니다. (NVIDIA Docs)

따라서 결과가:

Host RDMA        PASS
GPU DMA-BUF RDMA FAIL

이어도 이상한 결과가 아닙니다.

그 경우:

"E810 RoCE는 정상이나, 현재 NVIDIA 공식 지원 경로에서 GPUDirect RDMA는 검증되지 않음"

이라는 중요한 engineering conclusion이 됩니다.

---

13. T5 — PFC OFF/ON 비교

현재 architecture에서 굉장히 중요합니다.

Case A

PFC OFF
ECN OFF

Case B

PFC ON
ECN OFF

Case C

PFC ON
ECN ON

세 가지를 비교합니다.

---

14. 단순 bandwidth만 보면 안 됨

각각:

Bandwidth
P99 latency
P99.9 latency
Packet drop
Retransmission
PFC pause
ECN marking
CPU

를 기록합니다.

---

15. 특히 congestion test

두 GPU node만 있을 때:

GPU1 → AIStor
GPU2 → AIStor

동시에 발생시키고,

GPU3
GPU4
...

가 들어온다고 가정하여 concurrent flow를 증가시킵니다.

예:

1 flow
2 flow
4 flow
8 flow
16 flow
32 flow

---

16. PFC의 효과를 어떻게 판단할 것인가

예를 들어:

PFC OFF

1 flow   94Gbps
4 flow   93Gbps
8 flow   80Gbps
16 flow  55Gbps

PFC ON

1 flow   94Gbps
4 flow   94Gbps
8 flow   92Gbps
16 flow  90Gbps

라면 PFC의 가치가 있습니다.

하지만:

PFC ON
→ pause storm
→ Cilium latency 증가

가 발생한다면 architecture를 다시 봐야 합니다.

---

17. T6 — ECN의 역할

PFC는:

"loss가 발생하지 않도록 해당 priority traffic을 멈춘다"

는 개념이고,

ECN은:

"혼잡을 감지해서 sender가 transmission rate를 줄이도록 한다"

는 개념입니다.

Intel도 E810에서 RoCEv2의 DCQCN/DCTCP/TIMELY 등을 지원하며, ECN은 congestion point에서 marking하여 sender에게 rate reduction을 유도하는 방식이라고 설명합니다. (Intel)

그래서:

PFC = immediate local lossless protection
ECN = end-to-end congestion control

로 이해하면 됩니다.

---

18. T7 — Cilium 영향 시험

이게 현재 사용자 환경에서는 매우 중요합니다.

왜냐하면 bond1이:

Cilium
+
RoCE

공유이기 때문입니다.

따라서 다음을 비교해야 합니다.

Case 1

Cilium only

Case 2

RoCE only

Case 3

Cilium + RoCE
PFC OFF

Case 4

Cilium + RoCE
PFC ON

Case 5

Cilium + RoCE
PFC + ECN

---

19. Cilium 부하를 어떻게 줄 것인가

예를 들어 iperf3를 통해:

Normal K8s traffic
50%
70%
90%

수준의 bond1 utilization을 만들고 동시에:

RoCE 10%
RoCE 30%
RoCE 50%
RoCE 70%

를 발생시킵니다.

그 결과:

Cilium latency
RoCE bandwidth
packet loss
PFC pause
ECN marking

을 측정합니다.

---

20. 이 시험에서 가장 중요한 그래프

예를 들어:

Cilium P99 latency
 │
 │                     × PFC
 │                  ×
 │             ×
 │        ×
 │   ×
 └──────────────────────────
       RoCE bandwidth

처럼 RoCE traffic이 증가할 때 기존 K8s traffic latency가 어떻게 변하는지를 봅니다.

이것이 현재 bond1 공유 구조의 engineering justification입니다.

---

21. T8 — Bonding의 영향

이건 가능하다면 비교해야 합니다.

A

bond1 LACP

B

single E810 port

가능한 환경이면:

RDMA single port
vs
RDMA bond

를 비교합니다.

Intel은 E810에서 RDMA+LAG를 지원하지만 조건이 있습니다. 최신 driver/NVM, RoCEv2, active-active/active-backup, 동일 device의 두 port, bonding 전 QoS 동일 등이 필요합니다. (Intel)

따라서 여기서:

single port
      ↓
RDMA bandwidth

bond1
      ↓
RDMA bandwidth

를 비교하면 됩니다.

---

22. 예상되는 중요한 결과

만약:

Single E810
94Gbps

bond1
93Gbps

이면:

LACP bond에 의한 RDMA performance penalty가 사실상 없음

이라고 볼 수 있습니다.

반대로:

single = 94
bond = 70

이면 bond/RDMA interaction을 반드시 분석해야 합니다.

---

23. T9 — AIStor TCP baseline

여기부터 실제 storage입니다.

GPU node에서 AIStor에:

S3 PUT
S3 GET

을 발생시킵니다.

Object size

최소:

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

정도로 나눕니다.

---

24. 왜 object size가 중요하냐

AIStor는 object storage이기 때문에:

small object

에서는:

request latency
metadata
CPU

가 지배적이고,

large object

에서는:

network
storage

가 지배적입니다.

따라서 GPUDirect/RDMA의 효과를 보려면 대용량 sequential transfer가 훨씬 중요합니다.

---

25. T10 — AIStor throughput

AIStor에서:

GET
PUT
mixed GET/PUT

를 각각 합니다.

Concurrency:

1
4
8
16
32
64
128

정도로 올립니다.

측정:

aggregate GB/s
IOPS
P50 latency
P95
P99
CPU
network utilization
disk utilization

---

26. 여기서 병목을 분해

예를 들어:

AIStor
 │
 ├── CPU
 ├── Network
 ├── Disk
 └── protocol

각각을 봅니다.

만약:

Network = 40%
Disk = 95%

라면 RDMA를 아무리 최적화해도 AIStor throughput은 거의 증가하지 않습니다.

반대로:

Network = 95%
Disk = 40%

라면 RDMA가 의미가 있습니다.

---

27. 이걸 꼭 해야 합니다

NVIDIA의 GDS benchmarking guide도 storage benchmark에서 storage뿐 아니라 network, PCIe, CPU/memory 등의 전체 data path를 같이 봐야 한다고 설명합니다. 또한 page cache가 storage 성능을 왜곡할 수 있기 때문에 실제 storage 성능을 평가할 때는 cache 영향을 배제해야 한다고 설명합니다. (NVIDIA Docs)

AIStor는 O_DIRECT를 사용하는 특성이 있으므로 이 점은 특히 유리합니다.

---

28. T11 — CPU copy vs GPUDirect

최종 비교는 이렇게 하는 게 좋습니다.

Path A

AIStor
 ↓
NIC
 ↓
Kernel/socket
 ↓
CPU memory
 ↓
CUDA copy
 ↓
GPU

Path B

가능한 경우:

AIStor
 ↓
RDMA
 ↓
GPU memory

즉:

CPU-mediated
vs
GPUDirect

입니다.

---

29. 이 비교가 진짜 engineering value

예를 들어:

	TCP/S3	RDMA	GPUDirect
Storage BW	8 GB/s	10 GB/s	10 GB/s
CPU	80%	35%	8%
GPU copy	필요	필요	없음
P99	15ms	8ms	6ms

라고 하면:

GPUDirect의 최대 장점은 storage throughput 자체보다는 CPU overhead 및 data movement 감소

라고 결론을 낼 수 있습니다.

반대로:

TCP = 8GB/s
RDMA = 10GB/s
GPUDirect = 10GB/s

이고 CPU가 이미 충분히 여유 있다면:

GPUDirect의 복잡도를 추가할 business justification이 낮다

고 판단할 수도 있습니다.

이런 "성능이 증가하지 않아도 결론이 있는 테스트"가 좋은 POC입니다.

---

30. T12 — vLLM 실제 workload

최종적으로는 synthetic benchmark에서 끝내면 안 됩니다.

vLLM에서:

1 GPU
2 GPU
4 GPU

등 실제 사용할 GPU 수를 기준으로 workload를 만듭니다.

그리고:

Prompt length
Output length
Concurrency
Batch size
KV cache

를 고정합니다.

---

31. vLLM에서 볼 KPI

최소:

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

입니다.

---

32. 가장 중요한 비교

최종적으로:

Scenario A

vLLM
 ↓
local/scratch

Scenario B

vLLM
 ↓
AIStor via TCP

Scenario C

vLLM
 ↓
AIStor via RoCE/RDMA

Scenario D

vLLM
 ↓
AIStor
 ↓
GPUDirect path

가능한 범위에서 비교합니다.

---

33. 단, 여기서 중요한 현실적인 부분

현재 AIStor가 S3-compatible object storage이고 vLLM이 일반 S3 client를 사용하는 구조라면,

S3
 ↓
HTTP
 ↓
TCP

가 기본입니다.

RDMA NIC를 설치했다고 S3 traffic이 자동으로 RDMA가 되지는 않습니다.

NVIDIA가 최근 공개한 cuObject가 바로 이 문제를 해결하기 위한 기술입니다. cuObject는 S3-compatible object storage와 GPU/system memory 사이에서 RDMA를 사용하도록 client/server library를 제공하는 구조입니다. (NVIDIA Docs)

따라서 AIStor에서 실제로:

S3
 ↓
RDMA

를 사용할 수 있는 vendor-supported data path가 있는지 확인해야 합니다.

이 부분은 GPUDirect RDMA benchmark와 별도의 AIStor integration test로 분리해야 합니다.

---

34. 성능시험 결과를 이렇게 정리하면 좋습니다

제가 추천하는 최종 결과표는:

Layer	Baseline	Optimized	Improvement
TCP bandwidth
RDMA bandwidth
RDMA latency
GPU RDMA bandwidth
CPU utilization
P99 latency
Cilium impact
AIStor GET
AIStor PUT
AIStor CPU
vLLM TTFT
vLLM tokens/sec

그리고 마지막에:

Technical benefit
Operational complexity
Supportability
Cost
Recommendation

을 붙입니다.

---

35. Engineering decision matrix

이건 제가 특히 추천합니다.

항목	TCP	RoCE	GPUDirect RDMA
구현 난이도	★	★★★	★★★★★
운영 난이도	★	★★★	★★★★★
CPU overhead	높음	낮음	매우 낮음
latency	높음	낮음	매우 낮음
bandwidth	높음	매우 높음	매우 높음
PFC/ECN 필요성	없음	권장	권장
NIC 요구사항	일반	RDMA NIC	GPUDirect 지원 NIC/driver
vendor dependency	낮음	중간	높음
Kubernetes 복잡도	낮음	중간	높음
vLLM benefit	baseline	workload dependent	workload dependent
AIStor integration	기본	별도 필요	별도 필요

이 표를 실제 benchmark 결과로 채우면 됩니다.

---

36. 그리고 현재 환경에서는 "성능" 외에 4개의 축을 같이 평가해야 합니다

사용자 환경은 단순 AI lab이 아니라 대규모 cloud-native data lakehouse 운영환경이므로 다음을 같이 봐야 합니다.

① Performance

GB/s
latency
CPU
tokens/s

② Reliability

packet loss
PFC pause
ECN
RDMA error
NIC reset
Cilium impact

③ Operability

Kubespray
GPU Operator
RDMA plugin
upgrade
node replacement
firmware

④ Supportability

특히:

B300
+
RHEL 10.2
+
Intel E810
+
GPUDirect RDMA

이 공식 지원 조합인지가 중요합니다.

NVIDIA의 현재 GPU Operator 26.3 GPUDirect RDMA 지원표는 RHEL 10.0 + Network Operator 26.1.0 등을 명시하지만 Intel E810을 그 표의 검증된 네트워크 stack으로 명시하지는 않습니다. (NVIDIA Docs)

따라서 이번 POC에서는 "기술적으로 동작"과 "vendor-supported"를 반드시 별도 판정해야 합니다.

---

37. 제가 제안하는 실제 POC Gate

전체를 다음 7개 Gate로 관리하면 좋습니다.

Gate 1 — NIC/RDMA

E810
ice
irdma
RoCEv2

PASS/FAIL

↓

Gate 2 — Kubernetes

RHEL 10.2
K8s 1.33
Cilium
RDMA Device Plugin

↓

Gate 3 — RDMA performance

TCP vs RDMA

↓

Gate 4 — QoS

PFC OFF
PFC ON
PFC+ECN

↓

Gate 5 — GPUDirect

Host RDMA
vs
GPU DMA-BUF RDMA

↓

Gate 6 — AIStor

TCP/S3
vs
RDMA-enabled path

↓

Gate 7 — Real workload

vLLM

---

38. 최종 의사결정은 이렇게

결과가 예를 들어:

RDMA bandwidth       +8%
CPU                  -70%
P99 latency          -60%

GPUDirect bandwidth  +2%
CPU                  -75%

AIStor throughput    +5%
vLLM tokens/sec      +1%

라면:

RoCE는 도입 가치가 높지만, 현재 AIStor/vLLM data path에서 GPUDirect RDMA는 복잡성 대비 추가 성능 효과가 낮다.

라는 결론이 가능합니다.

반대로:

RDMA bandwidth       +10%
CPU                  -70%

GPUDirect bandwidth  +8%
CPU                  -90%

AIStor throughput    +40%
vLLM TTFT            -25%
tokens/sec           +18%

라면:

GPU–AIStor 간 GPUDirect RDMA architecture를 채택할 충분한 근거가 있다.

가 됩니다.

---

39. 그리고 현재 환경에서 제가 가장 중요하게 보는 예상 bottleneck

현재 사용자의 구조를 고려하면:

B300
 │
 │ PCIe
 ▼
E810
 │
 │ RoCE
 ▼
Switch
 │
 ▼
E810
 │
 │
AIStor
 │
 ▼
DAS/NVMe/SAS

에서 E810 자체보다 AIStor의 storage/data path가 먼저 병목이 될 가능성을 반드시 봐야 합니다.

NVIDIA도 storage performance는 NIC만 보는 것이 아니라 PCIe → network → storage까지 전체 data path를 봐야 한다고 권고합니다. (NVIDIA Docs)

따라서 "E810이 100Gbps니까 AIStor도 12.5GB/s가 나올 것"이라는 식의 접근은 하면 안 됩니다.

실제로는:

min(
  GPU PCIe BW,
  NIC BW,
  Switch BW,
  AIStor CPU,
  AIStor network,
  erasure coding,
  disk BW,
  object protocol
)

가 실효 throughput을 결정합니다.

---

제가 최종적으로 추천하는 benchmark 구조

한 장으로 표현하면 이렇습니다.

                         PERFORMANCE POC
                              │
        ┌─────────────────────┼─────────────────────┐
        │                     │                     │
   Network Layer         GPU/NIC Layer        Storage Layer
        │                     │                     │
   TCP vs RDMA          Host vs GPU RDMA       TCP/S3
   1→16 QP              DMA-BUF                vs RDMA path
   PFC OFF/ON           CPU usage              GET/PUT
   ECN OFF/ON           PCIe BW                Object size
   Cilium impact        GPU BW                 Concurrency
        │                     │                     │
        └─────────────────────┼─────────────────────┘
                              │
                         vLLM workload
                              │
                  ┌───────────┴───────────┐
                  │                       │
                TTFT                 tokens/sec
                  │                       │
                  └───────────┬───────────┘
                              │
                       FINAL DECISION
                              │
          ┌───────────────────┼───────────────────┐
          │                   │                   │
      Performance        Reliability        Operability
          │                   │                   │
       GB/s/latency      PFC/ECN/error       K8s upgrade
       CPU overhead      Cilium impact       Driver lifecycle
       vLLM KPI          NIC stability       Vendor support

특히 이번 환경에서는 T3(Host RDMA) → T4(GPU DMA-BUF RDMA) → T9/T10(AIStor) 순서를 반드시 지키는 것을 권합니다. 그래야 "E810 RDMA가 느린 것인지", "GPUDirect가 안 되는 것인지", "AIStor가 병목인지"를 명확하게 분리할 수 있습니다.

그리고 한 가지 중요한 방향성도 있습니다. NVIDIA가 현재 GPUDirect Storage/GPUDirect RDMA를 AI workload의 주요 data-path 최적화로 보고 있고, 최근에는 S3 object storage에 RDMA를 직접 연결하는 cuObject까지 제공하고 있기 때문에, 이번 POC에서는 단순 ib_write_bw 성공 여부보다 "GPU → AIStor object storage까지 실제 payload가 CPU bounce 없이 얼마나 빨리 이동하는가"를 최종 KPI로 잡는 것이 훨씬 의미가 있습니다. (NVIDIA Docs)

원하시면 다음 단계에서는 이걸 실제 수행할 수 있도록 RHEL 10.2 + E810 + B300 + K8s 1.33 + AIStor 기준으로 테스트별 서버/클라이언트 명령어, 테스트 데이터 크기, QP/concurrency 값, Prometheus/Grafana에서 볼 metric, PASS/FAIL 기준, 결과 기록용 Excel 형태의 Benchmark Test Plan까지 구체적인 실행계획으로 만들어드릴 수 있습니다.