07. GPU, node, rack, interconnect

이 장의 핵심 연결: 06장까지는 한 디바이스 안의 이야기였습니다. 이제 밖으로 나가, 여러 가속기·노드·랙을 잇습니다. 05장의 "데이터 이동"이 이번엔 디바이스 사이에서 일어납니다.
다음 질문: 모델·작업이 한 가속기에 다 안 들어가면 어떻게 되나? 디바이스를 잇는 인터커넥트는 무엇이고, all-reduce 같은 collective는 왜 비용이 드나?
목표:

• GPU·노드·랙의 계층과 그 사이 인터커넥트(PCIe·NVLink·네트워크)의 관계를 잡는다.
• collective 연산(예: all-reduce)이 왜 통신 비용을 낳는지 직관을 잡는다.
• "가속기를 더 붙이면 그만큼 빨라진다"가 왜 조건부인지 읽는다.

먼저: 왜 여러 대가 필요한가요?

한 가속기의 메모리·연산으로 부족할 때가 있습니다. 모델이 커서 06장의 유한한 메모리에 다 안 들어가거나, 처리량을 더 내고 싶을 때죠. 그러면 여러 가속기에 일을 나눠 맡깁니다. 그런데 나누는 순간 새로운 비용이 생깁니다 — 나눠 가진 조각들을 서로 주고받아야 하니까요. 이 주고받음이 인터커넥트를 지나며, 그 비용이 이 장의 핵심입니다.

약어·용어 풀이

• 인터커넥트(interconnect): 가속기·노드를 잇는 연결 통로의 통칭. 통로마다 대역폭·지연이 다릅니다.
• 노드(node): 대개 하나의 서버 단위. 여러 가속기 + CPU + 메모리 + 네트워크가 한 상자에 있습니다.
• 랙(rack): 여러 노드를 물리적으로 모아 놓은 단위(장비 선반).
• PCIe(PCI Express): 한 노드 안에서 CPU·가속기 등을 잇는 범용 연결 통로.
• NVLink: 일부 GPU들 사이를 잇는 (PCIe보다 넓은 대역폭을 겨냥한) 전용 연결의 예. 특정 벤더의 예시일 뿐, 추천이 아닙니다.
• collective(집합 통신): 여러 디바이스가 함께 수행하는 통신 패턴의 통칭(아래 all-reduce 등).

일상 비유: 통로마다 다른 폭과 거리

여러 작업장이 있고, 그 사이로 자재를 주고받는다고 합시다. 통로에는 위계가 있습니다.

• 같은 작업대 위(디바이스 내부, 06장): 손만 뻗으면 됨 — 가장 빠름.
• 같은 방의 옆 작업대(노드 안, 가속기끼리): 짧은 통로(예: NVLink 같은 전용 링크) — 빠른 편.
• 옆방(노드 안이지만 CPU 경유 등, PCIe): 조금 더 먼 통로.
• 다른 층·다른 건물(노드 사이, 네트워크): 가장 먼 통로 — 대역폭 좁고 지연 큼.

멀리 주고받을수록 느립니다. 그래서 "무엇을 어느 통로로 얼마나 주고받는가"가 성능을 좌우합니다. 나누기(분산)의 이득이 통신 비용에 잡아먹히지 않아야 합니다.

시각적 직관: 토폴로지 계층

flowchart TB
    subgraph RACK["랙 (여러 노드)"]
        subgraph NODE1["노드 1"]
            G1[가속기]:::hw
            G2[가속기]:::hw
            G1 <-->|노드 내 링크<br/>예: NVLink| G2
        end
        subgraph NODE2["노드 2"]
            G3[가속기]:::hw
            G4[가속기]:::hw
            G3 <-->|노드 내 링크| G4
        end
        NODE1 <-->|노드 간 네트워크<br/>더 좁고 느린 편| NODE2
    end

    CPU1[CPU·시스템 메모리]:::compute <-->|PCIe| G1

    classDef hw fill:#cffafe,stroke:#0891b2,color:#164e63
    classDef compute fill:#dbeafe,stroke:#2563eb,color:#1e3a8a

📌 핵심: 통로는 계층적입니다. 대체로 디바이스 내부 > 노드 내 가속기 링크 > PCIe > 노드 간 네트워크 순으로 대역폭이 좁아지고 지연이 커지는 경향이 있습니다(구체 수치는 제품·구성에 따라 다름 — 확인 필요). 작업을 나눌 때 자주 주고받는 것은 빠른 통로 쪽에 두는 것이 유리합니다.

collective가 왜 비용인가: all-reduce의 직관

작업을 여러 가속기에 나누면, 각자 계산한 부분 결과를 합쳐야 할 때가 많습니다. 예를 들어 각 가속기가 계산한 값을 모두 더해서 그 합을 모두가 나눠 갖는 연산이 all-reduce입니다.

sequenceDiagram
    participant A as 가속기 A
    participant B as 가속기 B
    participant C as 가속기 C
    Note over A,C: 각자 부분 결과를 가지고 있음
    A->>B: 부분 결과 교환
    B->>C: 부분 결과 교환
    C->>A: 부분 결과 교환
    Note over A,C: 모두 더한 값을 각자 갖게 됨<br/>(교환이 인터커넥트를 지남 = 통신 비용)

용어 풀이

• all-reduce: 여러 디바이스의 값을 합(또는 다른 연산)으로 모은 뒤, 그 결과를 모든 디바이스가 공유하게 하는 collective. 딥러닝 분산에서 흔히 등장합니다.
• 이 교환이 인터커넥트를 지나므로, 통신 대역폭·지연이 병목이 될 수 있습니다. 나눈 조각이 많고 자주 합칠수록 통신 비용이 커집니다.

📌 핵심: 05장의 병목 개념이 여기서 확장됩니다. 한 디바이스 안에선 "연산 vs 메모리 이동"이 병목을 갈랐다면, 여러 디바이스에선 "연산 vs 통신(인터커넥트)"이 새 병목 축이 됩니다. 통신이 병목이면 가속기를 더 붙여도 그만큼 빨라지지 않습니다.

⚖️ 절충(tradeoff): 더 넓게·더 많이 나눌 때

가속기를 더 붙여(분산 확대) 얻는 것:
  - 더 큰 모델을 담을 수 있음(메모리 합산)
  - 더 많은 요청·연산을 병렬 처리할 여지

치르는 것:
  - collective 통신 비용(인터커넥트를 지나는 교환)
  - 나눔이 늘수록 통신·동기화 오버헤드 증가
  - 느린 통로(노드 간 네트워크)를 자주 쓰면 이득이 상쇄될 수 있음

숨은 전제:
  "N배 가속기 → N배 성능"은 통신 비용이 작을 때만 근사적으로 성립.
  통신이 병목이면 추가 가속기의 이득이 급격히 줄어듦(수확 체감).
  어느 지점에서 체감하는지는 워크로드·토폴로지에 달렸고 measured 문제.

⚠️ 흔한 오해

• "가속기 N개면 N배 빨라진다." — 통신·동기화 비용 때문에 대개 N배에 못 미칩니다. 통신이 병목이면 추가 이득이 급감합니다.
• "모든 인터커넥트는 비슷하다." — 통로마다 대역폭·지연이 크게 다릅니다(노드 내 링크 vs 노드 간 네트워크). 어느 통로를 쓰는지가 성능을 가릅니다.
• "NVLink가 있으면 무조건 빠르다." — 특정 전용 링크의 존재가 이점일 수 있으나, 워크로드가 그 통로를 실제로 활용해야 하고, 통신량·패턴에 달렸습니다. 벤더 예시일 뿐 보증이 아닙니다.
• "통신 비용은 무시해도 된다." — 분산에서 통신은 자주 지배적 비용이 됩니다.

조건 명시

🔬 증거 읽기: 토폴로지·통신 주장의 유형

• "이 링크의 대역폭은 X GB/s" → vendor-reported 스펙(PRIMARY일 수 있음). peak일 때가 많아 실제 달성치와 구분해야 함.
• "이 구성에서 8-가속기 확장 효율이 Y%" → measured (워크로드·토폴로지·구현을 밝혀야). 조건이 다르면 다른 실험.
• "그러므로 이 하드웨어가 분산에 우월" → 조건을 지운 일반화면 inferred이자 지지되지 않는 결론.

이 장에서 배운 것

• 부족하면 여러 가속기에 나누지만, 나누는 순간 통신 비용이 생긴다.
• 통로는 계층적(디바이스 내부 > 노드 내 링크 > PCIe > 노드 간 네트워크)이고, 멀수록 느린 경향.
• collective(예: all-reduce)는 부분 결과를 모아 공유하며, 인터커넥트를 지나므로 비용이 든다.
• 여러 디바이스에선 병목 축에 연산 vs 통신이 추가된다.
• "N배 가속기 → N배 성능"은 통신이 작을 때만 근사 성립 — 수확 체감은 워크로드·토폴로지에 달림.

🔎 이 장의 '지지하지 않는 결론'

• 이 장으로 선형 확장(N배)을 단정할 수 없다. 통신 비용 때문에 실제 확장 효율은 measured가 필요하다.
• 특정 인터커넥트의 존재만으로 "빠르다"를 결론지을 수 없다. 워크로드의 통신 패턴이 그 통로를 활용해야 한다.

✍️ 확인 문제

1. 작업을 8개 가속기로 나눴는데 성능이 4배밖에 안 늘었습니다. 이 장의 개념으로 가능한 원인을 하나 설명하세요.
2. 노드 내 가속기 링크와 노드 간 네트워크는 대체로 어떻게 다른가요(대역폭·지연 경향)? 왜 "자주 주고받는 것을 빠른 통로에" 두는 게 유리한가요?
3. [조건 묻기 / peak-measured] "이 시스템은 가속기 N개이니 처리량이 N배"라는 주장이 성립하려면 무엇이 작아야 하나요? 그리고 링크 대역폭이 peak 스펙으로 주어졌을 때 확장성 추정에 주의할 점은?

다음 장: 08 · latency, throughput, concurrency — 지금까지의 모든 것을 어떻게 관측하는가를 엽니다. TTFT·ITL/TPOT·throughput·concurrency를 정의하고, "무엇을·어떻게·어떤 분모로" 재는 측정 계약을 씁니다.