02. PCIe, NVLink, InfiniBand, Ethernet — 무엇이 무엇과 어떻게 연결되는가

이 장의 핵심 질문

• device를 나누면 반드시 그 사이를 잇는 "선"이 필요하다. 그 선들은 왜 한 종류가 아닌가?
• link · fabric · software 라는 세 scope를 왜 섞으면 안 되는가?
• 스펙 표의 "1.8 TB/s" 같은 명목 대역폭과, 실제 collective가 누리는 실효 통신은 왜 다른가?

앞 장과의 연결 — 01장에서 capacity 한계를 풀려면 모델을 여러 device로 나눠야(shard) 하고, 그 순간 device 사이 통신이 생긴다고 했다. 이 장은 그 통신이 흐르는 "물리적·논리적 배관"을 정리한다. 뒤 장(03–06)의 모든 collective는 이 배관 위를 흐른다.

먼저: 왜 인터커넥트가 갑자기 중요한가

단일 device 안에서는 모든 데이터가 같은 메모리(HBM)에 있어 이동이 "공짜에 가깝다"(선수 과정 ①의 memory-bound 논의). 하지만 모델을 여러 device에 나눈 순간, 한 device의 계산 결과를 다른 device로 옮겨야 한다. 이 이동 속도가 곧 분산 시스템의 새로운 병목이다.

비유하자면, 한 사무실 안에서 옆자리에 서류를 건네는 것(HBM 내부)과, 다른 층으로 서류를 보내는 것(같은 노드 내 GPU 간), 다른 건물로 택배 보내는 것(노드 간)은 속도가 완전히 다르다. 인터커넥트는 이 "거리별 배송 수단"의 집합이다.

세 개의 scope — link · fabric · software

인터커넥트를 이해하는 핵심 기율은 세 층위를 섞지 않는 것이다.

먼저 용어를 풀자.

• link (링크) — 두 지점을 잇는 하나의 물리적 연결과 그 규격. "이 선 하나가 초당 몇 바이트를 나르는가". 예: NVLink, PCIe, InfiniBand의 개별 링크.
• fabric (패브릭) — 여러 link를 엮어 만든 연결망 전체의 구조(topology). "어느 device가 어느 device와, 몇 홉(hop)을 거쳐, 경합 없이 통신할 수 있는가". 예: NVSwitch가 만드는 노드 내 all-to-all 패브릭, InfiniBand 스위치가 만드는 노드 간 패브릭.
• software scope (소프트웨어 범위) — 위 물리 계층 위에서 collective 연산(all-reduce·all-to-all 등)을 실제로 조직하는 라이브러리. 물리 topology를 숨기고 링/트리 등 논리 구조로 통신을 구성한다. 대표적으로 NCCL(NVIDIA Collective Communications Library, "니클"로 읽음).

⚠️ 경계 혼동 주의 — "NVLink가 빠르다"(link), "이 노드는 all-to-all이 non-blocking이다"(fabric), "all-reduce가 380 GB/s 나온다"(software가 측정한 실효 busBW)는 세 층위의 다른 진술이다. 스펙 시트의 링크 대역폭을 곧바로 collective 성능으로 읽으면 틀린다. 링크는 상한을, 패브릭은 경합 구조를, 소프트웨어는 실제 도달치를 결정한다.

flowchart TD
    subgraph SW["software scope — 논리 통신"]
        NCCL["NCCL / RCCL 등<br/>all-reduce·all-gather·all-to-all<br/>링·트리로 topology를 숨김"]
    end
    subgraph FAB["fabric scope — 연결망 구조(topology)"]
        NVSW["NVSwitch<br/>(노드 내 all-to-all)"]
        IBSW["InfiniBand / Ethernet 스위치<br/>(노드 간)"]
    end
    subgraph LINK["link scope — 물리 링크 규격"]
        NVL["NVLink"]
        PCIE["PCIe"]
        IB["InfiniBand / RoCE 링크"]
    end

    NCCL --> NVSW
    NCCL --> IBSW
    NVSW --> NVL
    NVSW --> PCIE
    IBSW --> IB

    classDef sw fill:#c4f1f4,stroke:#0891b2,color:#000
    classDef fab fill:#ffe0b2,stroke:#e07b00,color:#000
    classDef link fill:#cfe2ff,stroke:#2563eb,color:#000
    class NCCL sw
    class NVSW,IBSW fab
    class NVL,PCIE,IB link

link scope — 네 가지 배송 수단

각 링크 규격은 어느 거리(scope)를 담당하는가로 구분하면 헷갈리지 않는다.

PCIe — device를 서버에 꽂는 표준 버스

서버 메인보드의 표준 확장 버스. GPU를 시스템에 연결하는 기본 경로이며, NVLink가 없는 구성에서는 GPU 간 통신도 PCIe root complex를 거친다. 범용성이 장점이지만 GPU-GPU 전용 고대역 통신에는 상대적으로 좁다.

NVLink / NVSwitch — 노드 내 GPU끼리 직접

NVIDIA의 scale-up(한 노드/랙 안에서 GPU를 묶는) 전용 인터커넥트. GPU가 서로의 HBM에 직접 접근할 수 있게 해 준다. NVSwitch는 여러 NVLink를 엮어 노드 내 all-to-all non-blocking 패브릭을 만든다.

InfiniBand / Ethernet(RoCE) — 노드와 노드 사이

여러 서버(노드)를 잇는 scale-out 네트워크. 노드 경계를 넘는 통신은 NVLink가 아니라 이 계층을 탄다. InfiniBand는 저지연·RDMA(원격 직접 메모리 접근)에 강하고, Ethernet+RoCE는 범용 인프라 위에서 유사 기능을 제공한다.

📌 핵심 — scale-up vs scale-out — scale-up은 "한 노드/랙 안에서 GPU를 촘촘히 묶는 것"(NVLink·NVSwitch), scale-out은 "노드를 여러 대 잇는 것"(InfiniBand·Ethernet)이다. 둘의 대역폭·지연 특성이 크게 다르므로, 병렬화 축(03–05장)을 배치할 때 "이 통신이 노드 안에서 끝나는가, 노드 밖으로 나가는가"가 결정적이다. 통신량이 큰 축(예: TP)은 보통 scale-up 도메인 안에 가두는 것이 유리하다.

🔬 증거 읽기 — 링크 대역폭 근거표 (확인일 2026-07-20)

아래 수치는 명목(nominal) 링크 대역폭이며 vendor-reported다. 실제 collective가 누리는 값은 아래 "실효 통신" 절에서 다시 낮춘다.

conditions — 위 값은 특정 form factor(SXM 등)·세대·구성 기준이다. PCIe form factor GPU는 NVSwitch 패브릭에 붙지 않으며 GPU-GPU 통신이 PCIe를 탄다. does-not-support — 이 표는 "실제 앱이 이 대역폭을 다 쓴다"를 지지하지 않는다(아래 참조). 또한 특정 배포의 실측 성능이나 특정 클라우드 인스턴스의 실효 대역폭을 지지하지 않는다.

버전 고정 주의 — 위는 2026-07-20 기준 공개 자료 정리다. 세대·제품(Blackwell 이후 Rubin 등)과 사양은 계속 갱신되므로, 실제 사용 시 canonical URL에서 재확인하라. 로드맵상의 미래 세대(예: HBM4 기반 차세대) 수치는 발표치이며 이 안내서의 원리 학습에는 부수적이다 — 여기서는 버전 의존으로 표시하고 상세는 다루지 않는다.

fabric scope — 명목 대역폭이 곧 통신이 아닌 이유

링크 하나가 빠르다고 해서, 여러 device가 동시에 통신할 때 그 속도가 그대로 나오지는 않는다. 패브릭의 구조가 실제 도달치를 결정한다.

• non-blocking 패브릭 — NVSwitch처럼, 모든 GPU 쌍이 동시에 통신해도 피크율이 유지되는 구조. "누가 누구와 통신하든 경합이 없다"가 이상적 목표다.
• 경합(contention)이 있는 패브릭 — 링크·스위치를 여럿이 공유하면, 동시 통신 시 서로의 대역폭을 갉아먹는다. topology(트리·메시·링 등)와 홉 수가 실효치를 좌우한다.
• 노드 경계 — 노드 안은 NVLink 패브릭(수백 GB/s~TB/s급), 노드 밖은 InfiniBand/Ethernet(상대적으로 낮음). 같은 collective라도 노드를 넘느냐가 실효 대역폭을 크게 바꾼다.

⚖️ 절충 — 더 큰 패브릭(더 많은 GPU를 한 도메인에)은 더 큰 모델을 한 덩어리로 다룰 수 있게 해 주지만(scale-up 이득), 스위치·케이블·전력·냉각 비용과 실패 도메인(한 번에 죽는 범위)이 커진다. "패브릭을 키우면 항상 낫다"가 아니다.

software scope — collective와 실효 대역폭(busBW)

물리 계층 위에서 실제로 통신을 조직하는 것은 collective communication library다. 대표는 NVIDIA의 NCCL(AMD는 RCCL). NCCL이 제공하는 기본 연산은 03–05장에서 병렬화 축과 함께 자세히 쓰이므로 여기서는 이름만 짚는다: all-reduce, all-gather, reduce-scatter, broadcast, reduce, 그리고 point-to-point send/recv로 구성하는 all-to-all. (각 연산이 "무엇을 어떻게 나르는가"는 03·05장에서 정의한다.)

핵심은 이것이다: NCCL은 물리 topology를 숨기고 링(ring)이나 트리(tree) 같은 논리 구조로 데이터를 잘게 쪼개 파이프라인처럼 흘려보낸다. 그래서 측정 지표가 두 가지로 갈린다.

• algbw (algorithm bandwidth) — 입력 데이터 크기 ÷ 소요 시간. "이 collective가 얼마나 빨리 끝났나"의 직접 측정.
• busbw (bus bandwidth) — algbw를 통신 rank 수로 보정해 하드웨어 실효 대역폭을 추정한 값. collective마다 보정 계수가 다르다.

이 busBW가 링크 명목 대역폭보다 낮은 것이 정상이다. 예를 들어 HGX 계열 노드 안에서 all-reduce의 실효 busBW는 링크 명목치의 일부에 그친다(정리 문헌들은 노드 내 all-reduce busBW를 수백 GB/s대로 보고하나, 이는 구성·메시지 크기·NCCL 버전에 따라 달라지므로 특정 수치를 이 안내서에 못박지 않고 조건 의존으로 둔다).

🔬 증거 읽기 — NCCL 근거표 (확인일 2026-07-20)

conditions — SHARP(스위치 내 연산 오프로드)·busBW 실측치는 하드웨어 세대·메시지 크기·토폴로지·NCCL 버전에 강하게 의존한다. does-not-support — 이 표는 "특정 배포에서 이 실효 대역폭이 나온다"를 지지하지 않는다. 특정 클러스터 실측은 그 클러스터의 NCCL 로그(버전·busBW·rank·메시지 크기)로만 뒷받침된다. NCCL 세부 버전 번호는 계속 갱신되므로 최신은 저장소에서 확인하라.

이 배관 위에 무엇이 흐르는가 (다음 장 예고)

병렬화 축(03–05장)마다 요구하는 collective가 다르고, 그 collective가 노드 안에서 끝나는지 밖으로 나가는지가 실효 성능을 좌우한다. 미리 지도만 그려 두면:

⚠️ 경계 혼동 주의 — data parallelism의 all-reduce는 학습(training) 때 gradient를 합치는 통신이다. 추론(inference) 에서 DP는 보통 "엔진을 복제해 요청을 나눠 받는" 것이라 매 스텝 gradient all-reduce가 없다. 이 안내서는 추론 인프라가 주제이므로, 04·09장에서 이 구분을 다시 못 박는다.

이 장에서 배운 것

• device를 나누면 그 사이 통신이 생기고, 그 통신은 link · fabric · software 세 scope로 나눠 봐야 한다.
• link은 물리 규격(PCIe·NVLink·InfiniBand·Ethernet), fabric은 연결망 구조(NVSwitch의 non-blocking all-to-all 등), software는 collective를 조직하는 라이브러리(NCCL)다.
• scale-up(노드 내, NVLink·NVSwitch)과 scale-out(노드 간, InfiniBand·Ethernet)은 대역폭·지연이 크게 다르다. 통신량 큰 축은 scale-up 도메인에 가두는 것이 유리하다.
• 스펙의 명목 대역폭 ≠ 실효 통신. 패브릭 경합·노드 경계·collective 종류·메시지 크기·NCCL 버전이 실효 busBW를 결정한다. algbw와 busbw를 구분하라.
• 병렬화 축마다 요구 collective가 다르고, 그것이 노드 안/밖 중 어디를 타는지가 실효 성능을 좌우한다(03–05장의 전제).

🔎 이 장의 '지지하지 않는 결론' + 'unknown으로 남겨야 할 것'

• 지지하지 않는 결론 — "NVLink가 1.8 TB/s니까 all-reduce도 1.8 TB/s로 흐른다"는 지지되지 않는다. 명목 링크 대역폭은 상한일 뿐, 실효 busBW는 그보다 낮고 조건에 의존한다.
• unknown으로 남길 것 — 특정 배포의 실효 all-reduce busBW, 특정 클라우드 인스턴스의 노드 간 실효 대역폭, SHARP 오프로드의 실제 이득은 그 환경의 측정 로그(버전·메시지 크기·topology) 없이는 unknown이다. 정리 문헌의 예시 수치는 원 측정 조건이 다르면 다른 배포로 옮기지 않는다.

✍️ 확인 문제

1. "우리 노드는 NVSwitch로 GPU가 all-to-all non-blocking 연결이다"라는 문장은 link·fabric·software 중 어느 scope의 진술인가? 이 문장만으로 "all-reduce가 명목 대역폭대로 나온다"고 결론 내릴 수 있는가? 왜인가?

1. (비교 가능성 유형) 문서 A는 "NVLink 900 GB/s"를, 문서 B는 "이 배포의 all-reduce busBW 370 GB/s"를 말한다. 이 두 수치를 "B가 A의 41%밖에 안 된다, 비효율적이다"라고 나란히 비교할 수 있는가? 두 수치가 서로 다른 무엇을 재고 있는지로 답하라.

1. 통신량이 큰 병렬화 축을 노드 경계 밖으로 배치하면 왜 위험한가? scale-up과 scale-out의 차이로 설명하고, 이때 "명목 대역폭 표"만 보면 왜 이 위험을 놓치는지 말하라.

다음 장에서는 첫 번째 병렬화 축인 텐서 병렬화(tensor parallelism) 를 연다. "무엇이 shard되고 / 무엇이 replicate되며 / 어떤 collective가 생기는가"라는 이 과정의 핵심 골격을 여기서 처음 표로 세운다.
다음 → 03. Tensor parallelism — tensor를 어디서 나누고 무엇을 통신하는가