AI 인터커넥트 — NVLink, NVSwitch, UALink, 그리고 스케일업의 기술

• 들어가며
• 분산 학습과 추론의 통신 병목
• 스케일업 vs 스케일아웃
• NVLink와 NVSwitch의 원리
• NVLink 도메인과 랙 스케일 — GB200 NVL72
• UALink와 Ultra Ethernet — 개방형 대안
• 네트워크 토폴로지 — fat-tree, dragonfly, rail-optimized
• 집합 통신 — all-reduce, ring vs tree
• 컴퓨트와 통신의 오버랩
• 네트워크가 학습 효율을 가른다
• 미래 — 더 큰 도메인, 광, 개방
• 개발자 시사점
• All-reduce 통신 시간 계산해 보기
• NVLink 세대와 NVSwitch 도메인 규모
• Google TPU의 광 회로 스위치(OCS)
• 컴퓨트-통신 오버랩을 더 깊이 — FSDP 프리페치
• 실무 체크리스트 — NCCL 튜닝과 토폴로지 인식
• 마치며
• 참고 자료

들어가며

GPU 하나의 연산 성능을 이야기할 때 우리는 흔히 TFLOPS 같은 숫자에 주목합니다. 그러나 수천 장, 수만 장의 GPU를 묶어 하나의 거대한 모델을 학습시키는 시대로 접어들면서, 정작 시스템 전체의 성능을 결정하는 것은 개별 GPU의 연산 능력이 아니라 GPU와 GPU를 잇는 인터커넥트(interconnect), 즉 통신 경로가 되었습니다.

조금 과장해서 말하면, 2026년의 대규모 AI 인프라 경쟁은 "누가 더 빠른 칩을 만드느냐"의 경쟁이 아니라 "누가 더 많은 칩을 손실 없이 하나처럼 묶느냐"의 경쟁입니다. NVIDIA가 Blackwell 세대에서 GB200 NVL72라는 랙 스케일 시스템을 전면에 내세운 이유도, AMD와 Broadcom, Google 등이 UALink 컨소시엄을 만든 이유도, Google이 TPU에 광 회로 스위치(OCS)를 도입한 이유도 모두 같은 곳을 향합니다. 바로 통신 병목을 어떻게 줄일 것인가입니다.

이 글에서는 분산 학습과 추론에서 통신이 왜 병목이 되는지부터 시작해, 스케일업과 스케일아웃의 차이, NVLink와 NVSwitch의 원리, GB200 NVL72 같은 NVLink 도메인, UALink와 Ultra Ethernet 같은 개방형 대안, 네트워크 토폴로지와 집합 통신(collective communication), 그리고 컴퓨트와 통신의 오버랩까지를 차근차근 정리해 보겠습니다. 하드웨어 엔지니어가 아니라 모델을 학습시키고 서빙하는 개발자의 관점에서, "왜 내 학습이 GPU를 늘려도 빨라지지 않는가"라는 질문에 답하는 것을 목표로 합니다.

분산 학습과 추론의 통신 병목

먼저 직관을 잡아 봅시다. 모델 하나를 여러 GPU에 나누어 학습할 때, 각 GPU는 자기 몫의 계산을 끝낸 뒤 반드시 다른 GPU와 결과를 주고받아야 합니다. 데이터 병렬(data parallelism)에서는 각 GPU가 서로 다른 데이터 배치로 그래디언트를 계산한 뒤, 이를 모두 합쳐 평균을 내야 합니다. 이 과정이 그 유명한 all-reduce입니다. 텐서 병렬(tensor parallelism)에서는 하나의 행렬 곱이 여러 GPU에 쪼개져 있어, 레이어마다 중간 결과를 교환해야 합니다.

문제는 연산은 점점 빨라지는데 통신은 그만큼 빨라지지 않는다는 데 있습니다. GPU의 부동소수점 연산 성능은 세대마다 가파르게 올라갔지만, 칩 바깥으로 데이터를 내보내는 대역폭은 물리적 제약 때문에 같은 속도로 따라오지 못합니다. 그 결과 연산-통신 비율(compute-to-communication ratio)이 나빠지고, GPU가 통신을 기다리며 노는 시간이 늘어납니다.

이를 간단한 모델로 표현하면 다음과 같습니다.

한 스텝의 시간 ≈ max(연산 시간, 통신 시간)            (완벽히 겹칠 때)
한 스텝의 시간 ≈ 연산 시간 + 통신 시간                (전혀 안 겹칠 때)

통신 시간 ≈ 전송해야 할 바이트 / 유효 대역폭 + 지연(latency)

여기서 핵심은 "유효 대역폭"입니다. 카탈로그에 적힌 최대 대역폭과 실제로 집합 통신을 돌렸을 때 나오는 대역폭 사이에는 늘 간격이 있습니다. 토폴로지, 메시지 크기, 통신 라이브러리의 알고리즘 선택, 그리고 다른 트래픽과의 경합이 모두 이 간격을 만듭니다.

대규모 학습에서 통신이 차지하는 비중은 결코 작지 않습니다. 수천 GPU 규모에서 데이터 병렬 all-reduce와 텐서 병렬 통신을 합치면, 잘 튜닝되지 않은 경우 전체 스텝 시간의 30퍼센트에서 절반 이상을 통신이 잡아먹기도 합니다. 추론에서도 마찬가지입니다. 거대 모델 한 개를 여러 GPU에 펼쳐 서빙할 때, 토큰 하나를 생성하는 지연 시간은 텐서 병렬 통신 지연에 크게 좌우됩니다. 특히 2026년 들어 추론 capex가 학습 capex를 처음으로 추월한 상황에서, 추론 경로의 통신 효율은 직접적인 비용 문제가 되었습니다.

스케일업 vs 스케일아웃

인터커넥트를 이해하는 첫 번째 축은 스케일업(scale-up)과 스케일아웃(scale-out)의 구분입니다.

스케일업은 하나의 긴밀하게 결합된 도메인 안에서 GPU 수를 늘리는 것입니다. 한 서버 노드 안의 여러 GPU, 혹은 한 랙 안의 수십 개 GPU를 매우 빠른 전용 링크로 묶어, 마치 하나의 거대한 GPU처럼 동작하게 만듭니다. NVIDIA의 NVLink, NVSwitch가 대표적이고, 개방형 대안으로 UALink가 여기에 속합니다. 스케일업 도메인 안에서는 대역폭이 매우 크고 지연이 매우 작아서, 텐서 병렬처럼 통신이 빈번한 병렬화 기법을 마음껏 쓸 수 있습니다.

스케일아웃은 여러 노드, 여러 랙을 데이터센터 네트워크로 연결해 수백, 수천, 수만 GPU 규모로 확장하는 것입니다. InfiniBand나 이더넷이 여기에 쓰이며, 개방형 표준 진영에서는 Ultra Ethernet Consortium(UEC)이 이 영역을 겨냥합니다. 스케일아웃 링크는 스케일업 링크보다 대역폭이 작고 지연이 큽니다. 그래서 통신이 덜 빈번한 데이터 병렬이나 파이프라인 병렬을 이 계층에 배치하는 것이 보통입니다.

두 축을 표로 비교하면 다음과 같습니다.

실무에서는 이 둘을 계층적으로 조합합니다. 한 NVLink 도메인 안에 텐서 병렬을 두고, 도메인 사이를 데이터 병렬과 파이프라인 병렬로 잇는 식입니다. 이 배치가 통신량과 통신 위치를 결정하고, 결국 학습 효율을 좌우합니다.

NVLink와 NVSwitch의 원리

이제 스케일업 인터커넥트의 대표주자인 NVLink와 NVSwitch를 들여다봅시다.

NVLink는 GPU 사이를 직접 연결하는 NVIDIA의 고속 링크입니다. PCIe를 통해 CPU를 경유하지 않고, GPU끼리 점대점으로 데이터를 주고받습니다. 각 GPU에는 여러 개의 NVLink "레인" 묶음이 있고, 이를 다른 GPU나 스위치에 연결합니다. 세대를 거듭하며 링크당 신호 속도와 링크 수가 늘어, GPU 한 장이 외부와 주고받을 수 있는 총 대역폭이 꾸준히 커졌습니다.

세대별 대략적인 GPU당 양방향 NVLink 대역폭은 다음과 같습니다. 정확한 수치는 제품과 구성에 따라 다르므로 경향을 보는 용도로 참고하시기 바랍니다.

세대가 올라갈 때마다 대역폭이 사실상 두 배 가까이 늘어 온 점에 주목할 만합니다. Blackwell 세대의 5세대 NVLink는 GPU 한 장당 약 1.8 TB/s에 이르는데, 이는 일반적인 스케일아웃 네트워크 포트 대역폭보다 한두 자릿수 큰 값입니다. 같은 도메인 안에 있느냐 바깥에 있느냐가 왜 그토록 큰 차이를 만드는지 알 수 있는 대목입니다.

그런데 GPU를 둘씩 직접 연결하는 방식만으로는 한계가 있습니다. GPU가 8장만 되어도 모든 쌍을 직접 잇는 것은 비효율적이고, 더 많아지면 불가능에 가깝습니다. 여기서 NVSwitch가 등장합니다. NVSwitch는 NVLink 트래픽을 교환하는 전용 스위치 칩으로, 도메인 안의 모든 GPU가 마치 서로 직접 연결된 것처럼 균일한 대역폭으로 통신하게 해 줍니다. 이른바 "all-to-all" 비차단(non-blocking) 토폴로지를 NVLink 도메인 안에서 구현하는 것입니다.

NVSwitch가 있는 노드의 구조를 단순화하면 다음과 같습니다.

        +--------+   +--------+   +--------+   +--------+
        | GPU 0  |   | GPU 1  |   | GPU 2  |   | GPU 3  |
        +---+----+   +---+----+   +---+----+   +---+----+
            |            |            |            |
        ====+============+====NVLink==+============+====
            |            |            |            |
        +---+------------+------------+------------+---+
        |               NVSwitch  fabric              |
        +---+------------+------------+------------+---+
            |            |            |            |
        ====+============+====NVLink==+============+====
            |            |            |            |
        +---+----+   +---+----+   +---+----+   +---+----+
        | GPU 4  |   | GPU 5  |   | GPU 6  |   | GPU 7  |
        +--------+   +--------+   +--------+   +--------+

이 구조 덕분에 노드 안의 어떤 GPU 쌍이든 동일한 풀 대역폭으로 통신할 수 있고, all-reduce 같은 집합 통신이 토폴로지에 발목 잡히지 않습니다. 텐서 병렬을 NVLink 도메인 안에 두는 것이 정석이 된 이유입니다.

NVLink 도메인과 랙 스케일 — GB200 NVL72

NVSwitch의 진짜 힘은 한 노드를 넘어 랙 전체로 확장될 때 드러납니다. NVIDIA의 GB200 NVL72는 그 정점에 있는 시스템입니다.

GB200 NVL72는 하나의 랙 안에 72개의 Blackwell GPU를 담고, 이들을 NVSwitch 기반의 단일 NVLink 도메인으로 묶습니다. 즉, 랙 안의 72개 GPU가 모두 NVLink 대역폭으로 서로 통신할 수 있습니다. 전통적으로 NVLink 도메인은 한 노드(보통 8 GPU) 안에 갇혀 있었고, 그 바깥은 더 느린 스케일아웃 네트워크였습니다. NVL72는 이 경계를 랙 전체로 밀어냈습니다. 72개 GPU가 하나의 큰 GPU처럼 동작하는 셈입니다.

이것이 왜 중요할까요? 거대 모델을 학습하거나 서빙할 때, 텐서 병렬과 전문가 병렬(MoE의 expert parallelism)은 통신이 매우 빈번해 스케일아웃 네트워크 위에서는 효율이 크게 떨어집니다. 그런데 NVLink 도메인이 72 GPU로 커지면, 이런 무거운 통신 패턴을 모두 빠른 도메인 안에 가둘 수 있습니다. 특히 MoE 모델에서 토큰을 여러 전문가로 라우팅하는 all-to-all 통신이 NVLink 도메인 안에서 일어나면, 추론 지연과 처리량이 극적으로 개선됩니다.

랙 스케일 시스템을 단순화하면 다음과 같은 그림이 됩니다.

   GB200 NVL72  (단일 NVLink 도메인, 72 GPU)
   +-----------------------------------------------+
   |  컴퓨트 트레이 x N  (각 트레이: Grace CPU +    |
   |                      Blackwell GPU)            |
   |        |        |        |        |            |
   |   +----+--------+--------+--------+----+       |
   |   |        NVSwitch 트레이 (백플레인)     |    |
   |   +----+--------+--------+--------+----+       |
   |        |        |        |        |            |
   |  ...모든 GPU가 풀 NVLink 대역폭으로 연결...     |
   +-----------------------------------------------+
            |  (스케일아웃: 이더넷 / InfiniBand)
            v
   다른 랙들 (수천 GPU 규모 클러스터)

랙 단위로 보면 NVLink 도메인은 스케일업의 경계이고, 그 바깥으로 여러 랙을 잇는 것은 스케일아웃의 영역입니다. 다음 세대인 Vera Rubin은 2026년 말 등장이 예고되어 있으며, HBM4 메모리와 함께 와트당 성능을 큰 폭으로 끌어올리는 것을 목표로 합니다. 인터커넥트 역시 이 흐름에 맞춰 더 큰 도메인과 더 높은 대역폭으로 진화하고 있습니다.

UALink와 Ultra Ethernet — 개방형 대안

NVLink와 NVSwitch는 강력하지만 NVIDIA 독자 기술입니다. 단일 벤더에 묶이는 것을 우려하는 진영에서는 개방형 표준을 추진해 왔습니다.

**UALink(Ultra Accelerator Link)**는 스케일업 인터커넥트의 개방형 대안입니다. AMD, Broadcom, Google을 포함한 여러 회사가 UALink 컨소시엄을 구성해, 여러 벤더의 가속기를 하나의 스케일업 도메인으로 묶을 수 있는 공통 규격을 만들고 있습니다. 목표는 명확합니다. NVLink가 NVIDIA 생태계 안에서 하는 일을, 개방형이고 멀티 벤더인 방식으로 해내는 것입니다. UALink가 성숙하면, 가속기 제조사와 스위치 제조사가 분리되어 경쟁할 수 있는 생태계가 열립니다.

**Ultra Ethernet(UEC, Ultra Ethernet Consortium)**은 스케일아웃 영역을 겨냥한 개방형 표준입니다. 기존 이더넷을 AI/HPC 워크로드에 맞게 개선해, InfiniBand가 차지해 온 고성능 스케일아웃 영역을 표준 이더넷 생태계로 가져오려는 시도입니다. 더 나은 혼잡 제어, 더 효율적인 멀티패스 전송, 집합 통신을 위한 최적화 등이 핵심입니다.

세 진영을 정리하면 다음과 같습니다.

여기에 또 하나의 흥미로운 접근이 Google의 TPU입니다. Google은 TPU 사이를 ICI(Inter-Chip Interconnect)로 연결하고, 여기에 광 회로 스위치(OCS, Optical Circuit Switch)를 결합해 토폴로지를 동적으로 재구성합니다. 전기 패킷 스위치 대신 광 경로 자체를 바꿔치기함으로써, 장애가 난 노드를 우회하거나 작업에 맞는 토폴로지를 구성하는 유연성을 얻습니다. TPU v6 Trillium은 직전 세대 대비 피크 성능을 약 4.7배 끌어올렸고, 7세대인 Ironwood는 추론에 초점을 맞춘 세대로 자리매김했습니다.

이런 흐름의 배경에는 클라우드 사업자들의 커스텀 ASIC 확산이 있습니다. 추론용 ASIC의 점유율은 2024년 약 15퍼센트에서 2026년 약 40퍼센트 수준으로 빠르게 늘 것으로 전망됩니다. NVIDIA가 가속기 시장의 약 75에서 80퍼센트를 쥐고 있고 AMD MI350X 등이 도전하는 구도이지만, 인터커넥트 표준을 둘러싼 경쟁은 그보다 훨씬 다층적입니다.

네트워크 토폴로지 — fat-tree, dragonfly, rail-optimized

스케일아웃 영역으로 나오면 토폴로지 설계가 중요해집니다. 토폴로지란 노드와 스위치를 어떻게 연결하느냐의 청사진이며, 같은 수의 GPU와 케이블이라도 토폴로지에 따라 집합 통신 성능이 크게 달라집니다.

**Fat-tree(클로스, Clos)**는 가장 널리 쓰이는 구조입니다. 여러 단의 스위치를 계층으로 쌓되, 위로 올라갈수록 링크를 두껍게 만들어 어떤 두 노드 사이든 충분한 대역폭을 보장합니다. 이상적으로는 비차단(non-blocking) 전이등분 대역폭(bisection bandwidth)을 제공해, 모든 노드가 동시에 통신해도 병목이 없습니다. 다만 단수가 늘면 스위치와 케이블 비용이 급증합니다.

Dragonfly는 그룹을 만들고 그룹 안은 촘촘히, 그룹 사이는 적은 수의 긴 링크로 잇는 구조입니다. 대규모에서 케이블과 스위치 비용을 줄이는 데 유리하지만, 그룹 간 링크가 적어 특정 트래픽 패턴에서 혼잡이 생길 수 있어 적응형 라우팅이 중요합니다.

Rail-optimized 토폴로지는 AI 학습에 특화된 배치입니다. 각 노드의 i번째 NIC(레일)를 같은 레일 전용 스위치에 모읍니다. 그러면 데이터 병렬 all-reduce처럼 "같은 순번의 GPU끼리" 통신하는 패턴이 단일 홉으로 끝나, 스위치 단계를 줄이고 대역폭을 최대로 살립니다.

세 토폴로지를 비교하면 다음과 같습니다.

토폴로지 선택은 추상적인 이야기가 아닙니다. 같은 GPU 수라도 토폴로지에 따라 실제 학습 처리량이 수십 퍼센트씩 갈리기도 합니다.

집합 통신 — all-reduce, ring vs tree

분산 학습 통신의 주인공은 집합 통신(collective communication)입니다. 그중에서도 all-reduce가 가장 중요합니다. all-reduce는 모든 GPU가 가진 텐서를 원소별로 합산(혹은 평균)한 뒤, 그 결과를 다시 모든 GPU에 분배하는 연산입니다. 데이터 병렬 학습에서 그래디언트를 합치는 바로 그 연산입니다.

all-reduce를 구현하는 방식은 여러 가지인데, 대표적으로 ring 방식과 tree 방식이 있습니다.

Ring all-reduce는 GPU들을 논리적인 고리로 배열하고, 데이터를 조각내어 고리를 따라 돌립니다. 두 단계로 나뉩니다. 먼저 reduce-scatter 단계에서 각 GPU가 자기 담당 조각의 합을 모으고, 이어 all-gather 단계에서 그 합산 결과를 모두에게 퍼뜨립니다. ring 방식의 장점은 통신량이 GPU 수에 거의 무관하게 일정하다는 점입니다.

ring all-reduce의 흐름을 의사코드로 적으면 다음과 같습니다.

# ring all-reduce 개념 (N개 GPU, 각자 길이 N의 청크 배열을 가짐)
# 1단계: reduce-scatter
for step in range(N - 1):
    send_chunk = (rank - step) % N
    recv_chunk = (rank - step - 1) % N
    send(buffer[send_chunk], to=(rank + 1) % N)
    incoming = recv(from=(rank - 1) % N)
    buffer[recv_chunk] += incoming   # 부분 합 누적

# 이 시점에서 각 GPU는 서로 다른 한 청크의 '완전한 합'을 가짐

# 2단계: all-gather
for step in range(N - 1):
    send_chunk = (rank - step + 1) % N
    recv_chunk = (rank - step) % N
    send(buffer[send_chunk], to=(rank + 1) % N)
    buffer[recv_chunk] = recv(from=(rank - 1) % N)

# 종료 후 모든 GPU가 동일한 '전체 합'을 보유

ring all-reduce가 각 GPU에서 주고받는 데이터의 총량은 대략 다음과 같습니다.

GPU당 전송량 ≈ 2 x (N - 1) / N x (텐서 크기)
            ≈ 2 x (텐서 크기)        (N이 클 때)

즉 GPU 수 N이 아무리 커져도 GPU당 전송량은 텐서 크기의 약 두 배로 수렴합니다. 대역폭 관점에서 매우 효율적이라 대규모 데이터 병렬에 널리 쓰입니다. 다만 단계 수가 N에 비례해 늘어나므로, 작은 메시지에서는 지연이 누적되는 단점이 있습니다.

Tree all-reduce는 트리 구조로 합산과 분배를 수행합니다. 단계 수가 N의 로그에 비례해, 메시지가 작거나 GPU 수가 많을 때 지연 측면에서 유리합니다. 반면 대역폭 효율은 ring보다 떨어질 수 있습니다.

실무에서는 라이브러리가 메시지 크기와 토폴로지를 보고 둘 사이에서 자동으로 알고리즘을 고릅니다. NVIDIA의 NCCL, 그리고 다른 집합 통신 라이브러리들이 이 일을 해 줍니다. 개발자가 외우기보다는, "라이브러리가 토폴로지를 정확히 인식하도록 환경을 잘 구성하는 것"이 더 중요합니다.

reduce-scatter와 all-gather를 따로 쓰는 패턴도 점점 중요해지고 있습니다. ZeRO나 FSDP 계열의 메모리 절약 기법은 all-reduce를 reduce-scatter와 all-gather로 분해해, 파라미터와 그래디언트를 샤딩하면서 통신을 수행합니다. 통신 패턴을 이해하면 왜 특정 병렬화 전략이 특정 토폴로지에서 빠른지 자연스럽게 보입니다.

컴퓨트와 통신의 오버랩

통신을 아무리 빠르게 만들어도 통신이 0이 되지는 않습니다. 그래서 두 번째 전략이 등장합니다. 바로 통신을 연산 뒤에 숨기는 것, 즉 컴퓨트와 통신의 오버랩(overlap)입니다.

핵심 아이디어는 단순합니다. 어떤 GPU가 다음 레이어의 그래디언트를 계산하는 동안, 이미 끝난 이전 레이어의 그래디언트를 백그라운드에서 all-reduce로 보내는 것입니다. 통신을 별도의 스트림에서 비동기로 돌려, 연산이 진행되는 시간 뒤에 통신을 숨깁니다. 잘만 겹치면 통신 시간이 사실상 공짜처럼 느껴집니다.

역전파에서의 오버랩을 단순화하면 다음과 같습니다.

# 역전파에서 그래디언트 통신을 연산 뒤에 숨기기 (개념)
for layer in reversed(layers):
    grad = compute_gradient(layer)        # 연산 스트림
    handle = async_all_reduce(grad)       # 통신 스트림에서 비동기 시작
    pending.append((layer, handle))
    # 다음 레이어의 연산이 바로 이어지며, 통신은 백그라운드에서 진행

for layer, handle in pending:
    handle.wait()                         # 필요한 시점에만 완료를 기다림
    apply_update(layer)

오버랩이 잘 되려면 몇 가지 조건이 맞아야 합니다. 통신 스트림과 연산 스트림이 같은 자원을 두고 심하게 경합하지 않아야 하고, 그래디언트를 적당한 크기로 묶어(bucketing) 너무 작은 통신이 잦지 않게 해야 하며, 통신을 시작하는 시점과 결과를 기다리는 시점 사이에 충분한 연산이 있어야 합니다. 프레임워크들은 이런 버킷팅과 비동기 통신을 기본으로 제공하지만, 모델 구조와 병렬화 설정에 따라 튜닝이 필요합니다.

오버랩의 효과를 시간 축으로 그리면 다음과 같습니다.

오버랩 없음:
  [연산 L1][통신 L1][연산 L2][통신 L2][연산 L3][통신 L3]   <- 통신이 그대로 더해짐

오버랩 있음:
  [연산 L1][연산 L2][연산 L3]
           [통신 L1][통신 L2][통신 L3]                     <- 통신이 연산 뒤에 숨음
  결과적으로 전체 시간이 짧아짐

여기서 다시 인터커넥트가 등장합니다. 도메인 안 대역폭이 충분히 크면, 통신이 짧아져 연산 시간 안에 더 쉽게 숨습니다. 반대로 대역폭이 부족하면 통신이 연산보다 길어져 아무리 비동기로 돌려도 통신 꼬리가 드러납니다. 결국 하드웨어 대역폭과 소프트웨어 오버랩은 서로를 보완하는 한 쌍입니다.

네트워크가 학습 효율을 가른다

지금까지의 이야기를 한 문장으로 요약하면, 네트워크가 곧 스케일링 효율을 결정한다는 것입니다. 이를 스케일링 효율(scaling efficiency)이라는 지표로 생각해 봅시다.

스케일링 효율 = (N개 GPU에서의 처리량) / (1개 GPU 처리량 x N)

이상적 = 1.0 (선형 스케일링)
현실   = 통신 오버헤드, 부하 불균형, 오버랩 한계 때문에 1.0보다 작음

GPU를 두 배로 늘렸는데 처리량이 두 배가 안 되는 것은 거의 항상 통신 때문입니다. 통신이 차지하는 비중이 클수록, 같은 GPU 추가로 얻는 이득이 줄어듭니다. 그래서 인터커넥트가 빈약한 클러스터는 GPU를 아무리 사 모아도 일정 규모 이상에서 효율이 무너집니다.

여기서 NVLink 도메인을 키우는 전략의 의미가 분명해집니다. 통신이 가장 빈번한 텐서 병렬과 전문가 병렬을 빠른 NVLink 도메인 안에 가두면, 스케일아웃 네트워크에는 통신이 덜 빈번한 데이터 병렬과 파이프라인 병렬만 남깁니다. GB200 NVL72가 72 GPU를 한 도메인에 넣은 것은, 무거운 통신을 더 큰 빠른 영역 안에 가두어 스케일링 효율을 끌어올리려는 설계인 셈입니다.

대략적인 직관을 표로 정리하면 다음과 같습니다.

이 표는 정밀한 측정값이 아니라 감을 잡기 위한 것입니다. 핵심은 통신 비중을 줄이는 모든 노력, 즉 더 큰 도메인, 더 좋은 토폴로지, 더 영리한 집합 통신, 더 촘촘한 오버랩이 곧바로 스케일링 효율로 이어진다는 점입니다.

미래 — 더 큰 도메인, 광, 개방

인터커넥트의 미래는 몇 가지 방향으로 모입니다.

첫째, 도메인 확장입니다. 한 노드 8 GPU에서 랙 72 GPU로 커진 NVLink 도메인은 앞으로 더 커질 가능성이 높습니다. 도메인이 커질수록 무거운 통신을 더 많이 빠른 영역 안에 가둘 수 있기 때문입니다. Vera Rubin 세대는 이 흐름의 다음 장을 예고합니다.

둘째, **광 인터커넥트(optical interconnect)**입니다. 전기 신호로 케이블을 길게 끌면 전력과 신뢰성에서 한계가 옵니다. 광은 더 먼 거리를 더 적은 전력으로 잇고, Google의 OCS처럼 토폴로지를 동적으로 재구성하는 유연성까지 줍니다. 공동 패키징 광학(co-packaged optics)이 스위치와 가속기에 가까이 들어오면, 대역폭과 전력 효율의 새 장이 열립니다.

셋째, 개방형 표준의 성숙입니다. UALink와 Ultra Ethernet이 자리를 잡으면, 가속기와 스위치가 분리되어 경쟁하는 생태계가 만들어집니다. 단일 벤더 종속을 줄이고 싶은 클라우드 사업자들에게 이는 전략적으로 중요합니다. 추론 ASIC의 점유율 확대와 맞물려, 인터커넥트 표준 경쟁은 앞으로 더 치열해질 것입니다.

넷째, 추론 중심으로의 무게 이동입니다. 2026년 추론 capex가 학습 capex를 추월하면서, 인터커넥트 설계의 우선순위도 변하고 있습니다. 학습은 처리량이, 추론은 지연이 중요하므로, 작은 메시지의 낮은 지연 통신과 MoE의 all-to-all 라우팅이 점점 더 중요한 설계 목표가 됩니다.

개발자 시사점

하드웨어 엔지니어가 아니더라도, 모델을 학습하고 서빙하는 개발자가 인터커넥트에서 얻어야 할 실무 시사점은 분명합니다.

첫째, 병렬화 전략을 토폴로지에 맞추십시오. 통신이 가장 빈번한 텐서 병렬과 전문가 병렬은 NVLink 도메인 안에 두고, 데이터 병렬과 파이프라인 병렬을 도메인 사이에 배치하는 것이 기본입니다. 이 배치를 거꾸로 하면 빠른 도메인을 놀리고 느린 네트워크를 혹사하게 됩니다.

둘째, 통신 라이브러리가 토폴로지를 제대로 인식하게 하십시오. NCCL 같은 라이브러리는 토폴로지를 보고 알고리즘을 고릅니다. 환경 변수와 토폴로지 정보가 잘못되면 최적이 아닌 경로를 탑니다. 프로파일링으로 실제 집합 통신 대역폭을 측정하고, 카탈로그 수치와의 간격을 의심하는 습관이 필요합니다.

셋째, 오버랩을 측정하십시오. 프레임워크가 오버랩을 켰다고 실제로 잘 겹치는 것은 아닙니다. 통신이 연산 뒤에 제대로 숨는지 타임라인 프로파일러로 확인하고, 버킷 크기와 비동기 설정을 조정하십시오.

넷째, 스케일링 효율을 지표로 삼으십시오. GPU를 늘릴 때마다 처리량이 비례해 느는지 측정하고, 효율이 무너지는 지점을 찾으십시오. 그 지점이 바로 인터커넥트가 병목이 되는 곳이고, 병렬화 재배치나 더 큰 도메인이 필요한 신호입니다.

다섯째, 통신량 자체를 줄이는 알고리즘을 고려하십시오. 그래디언트 압축, 더 큰 마이크로배치, 통신 빈도를 줄이는 학습 기법 등은 모두 통신 병목을 완화합니다. 하드웨어를 바꾸지 않고도 효율을 끌어올릴 여지가 여기에 있습니다.

All-reduce 통신 시간 계산해 보기

지금까지 추상적으로 다룬 통신 시간을 실제 숫자로 계산해 보면 감이 훨씬 잘 잡힙니다. 데이터 병렬 학습에서 한 스텝의 그래디언트 all-reduce에 걸리는 시간을 추정해 봅시다.

앞서 보았듯이 ring all-reduce에서 각 GPU가 주고받는 데이터의 총량은 텐서 크기의 약 두 배입니다. 모델 파라미터 수를 P, 한 파라미터당 그래디언트 바이트 수를 B라고 하면, all-reduce해야 할 텐서의 크기는 P 곱하기 B 바이트입니다. 따라서 GPU당 전송량은 그 두 배에 가깝습니다.

여기에 유효 대역폭과 지연을 넣으면 한 스텝의 통신 시간을 추정할 수 있습니다. 구체적인 수치를 넣어 계산하는 과정을 코드로 적으면 다음과 같습니다.

# all-reduce 통신 시간 추정 (개념적 계산)
params = 70e9          # 파라미터 수 (예: 70B 모델)
bytes_per_param = 2    # bf16 그래디언트는 파라미터당 2바이트
tensor_bytes = params * bytes_per_param        # all-reduce 대상 크기

# ring all-reduce에서 GPU당 전송량 ~ 2배
per_gpu_bytes = 2 * tensor_bytes

link_bw = 1.8e12       # 유효 대역폭 1.8 TB/s (Blackwell NVLink 가정)
scaleout_bw = 50e9     # 스케일아웃 유효 대역폭 50 GB/s 가정

t_nvlink = per_gpu_bytes / link_bw     # NVLink 도메인 안에서
t_scaleout = per_gpu_bytes / scaleout_bw  # 스케일아웃 네트워크에서

print("all-reduce 대상:", tensor_bytes / 1e9, "GB")
print("GPU당 전송량:", per_gpu_bytes / 1e9, "GB")
print("NVLink 통신 시간:", t_nvlink * 1000, "ms")
print("스케일아웃 통신 시간:", t_scaleout * 1000, "ms")

70B 모델의 bf16 그래디언트는 약 140 GB이고, GPU당 전송량은 약 280 GB입니다. 유효 대역폭 1.8 TB/s인 NVLink 도메인 안에서는 약 0.16초, 유효 대역폭 50 GB/s인 스케일아웃 네트워크에서는 약 5.6초가 걸립니다. 같은 통신이 도메인 안이냐 바깥이냐에 따라 수십 배 차이가 나는 셈입니다. 이 단순한 계산 하나가 왜 모두가 NVLink 도메인을 키우려 하는지를 그대로 보여 줍니다.

물론 실제로는 그래디언트를 버킷으로 나누어 연산과 겹치므로, 위 통신 시간 전체가 그대로 스텝 시간에 더해지지는 않습니다. 하지만 통신량 자체가 줄지 않으면, 오버랩이 숨길 수 있는 한계도 분명히 존재합니다.

NVLink 세대와 NVSwitch 도메인 규모

앞서 본 세대별 대역폭 표를 조금 더 확장해, NVSwitch가 묶는 도메인 규모까지 함께 살펴보면 흐름이 더 또렷해집니다. 아래 수치는 제품과 구성에 따라 달라지므로 경향을 보는 용도로 참고하시기 바랍니다.

주목할 점은 대역폭만 커진 것이 아니라 한 도메인에 들어가는 GPU 수도 함께 커졌다는 사실입니다. 8 GPU 노드에 갇혀 있던 NVLink 도메인이 Blackwell 세대에서 랙 전체 72 GPU로 확장된 것은, 단순한 대역폭 증가보다 더 본질적인 변화입니다. 무거운 통신을 가둘 수 있는 빠른 영역의 크기가 통째로 커졌기 때문입니다.

Google TPU의 광 회로 스위치(OCS)

NVIDIA가 전기 기반 NVSwitch로 도메인을 키우는 동안, Google은 전혀 다른 길을 택했습니다. 바로 광 회로 스위치(OCS, Optical Circuit Switch)입니다.

일반적인 데이터센터 스위치는 전기 패킷 스위치입니다. 들어온 패킷을 전기 신호로 받아, 목적지를 읽고, 적절한 포트로 내보냅니다. 패킷마다 전기-광 변환과 라우팅 결정이 일어나므로, 대역폭이 커질수록 전력과 지연 부담이 늘어납니다. 반면 OCS는 패킷을 들여다보지 않습니다. 그저 입력 광섬유와 출력 광섬유를 작은 거울(MEMS)로 물리적으로 연결할 뿐입니다. 한번 경로가 설정되면 빛이 변환 없이 그대로 통과하므로, 대역폭에 무관하게 전력이 거의 일정하고 지연이 매우 작습니다.

대신 OCS는 패킷 단위로 경로를 바꾸지 못합니다. 경로를 바꾸려면 거울을 다시 정렬해야 하므로 밀리초 단위의 시간이 듭니다. 그래서 OCS는 트래픽을 매 순간 스위칭하는 용도가 아니라, 작업에 맞춰 토폴로지 자체를 재구성하는 용도로 쓰입니다. TPU 포드에서 어떤 작업이 들어오면, OCS가 필요한 TPU들을 원하는 형태(예: 3차원 토러스)로 연결해 주고, 작업이 끝나면 다시 풀어 다른 작업에 재배치합니다.

전기 스위칭과 광 회로 스위칭의 차이를 그림으로 그리면 다음과 같습니다.

전기 패킷 스위치:
  광 -> [전기 변환] -> [패킷 라우팅] -> [전기 변환] -> 광
        (패킷마다 변환과 결정, 대역폭 커질수록 전력 증가)

광 회로 스위치(OCS):
  광 ============ [MEMS 거울로 경로 연결] ============ 광
        (변환 없이 빛 그대로 통과, 토폴로지를 재구성)

  작업 A: TPU들을  3D 토러스로 연결
  작업 B: 다른 TPU 집합을 다른 형태로 연결
  장애 노드: 거울을 재정렬해 우회

이 유연성 덕분에 Google은 장애가 난 TPU를 토폴로지에서 빼고 예비 노드로 교체하거나, 작업 규모에 맞춰 포드를 잘라 쓰는 일을 소프트웨어처럼 할 수 있습니다. 전기 스위치 중심의 고정 토폴로지와 비교하면 운영 유연성과 전력 효율에서 분명한 강점입니다.

컴퓨트-통신 오버랩을 더 깊이 — FSDP 프리페치

앞서 역전파에서의 오버랩을 보았는데, 최신 메모리 절약 학습에서는 순전파에서도 오버랩이 중요합니다. FSDP(Fully Sharded Data Parallel)는 파라미터를 GPU들에 샤딩해 두었다가, 한 레이어를 계산하기 직전에 all-gather로 그 레이어의 전체 파라미터를 모읍니다. 계산이 끝나면 다시 버려 메모리를 아낍니다.

여기서 핵심은 "다음 레이어의 파라미터를 미리 가져오는(prefetch)" 것입니다. 현재 레이어를 계산하는 동안, 다음 레이어에 필요한 파라미터의 all-gather를 백그라운드에서 미리 시작해 두면, 다음 레이어 계산이 시작될 때 통신이 이미 끝나 있습니다. 개념을 코드로 적으면 다음과 같습니다.

# FSDP 순전파에서 파라미터 프리페치 오버랩 (개념)
def forward(layers, x):
    handle = async_all_gather(layers[0].shard)   # 첫 레이어 파라미터 모으기
    for i, layer in enumerate(layers):
        handle.wait()                            # 현재 레이어 파라미터 준비 완료
        params = layer.full_params

        if i + 1 < len(layers):
            # 다음 레이어 파라미터를 미리 백그라운드에서 모으기
            handle = async_all_gather(layers[i + 1].shard)

        x = layer.compute(x, params)             # 현재 레이어 계산 (통신과 겹침)
        layer.free_full_params()                 # 메모리 회수
    return x

이렇게 하면 통신(all-gather)이 연산(layer.compute) 뒤에 숨어, 통신 지연이 계산 시간 안에 흡수됩니다. 다만 프리페치를 너무 멀리까지 하면 메모리를 그만큼 더 쓰게 되므로, 보통은 한두 레이어 앞만 미리 가져옵니다. 여기서도 도메인 대역폭이 충분히 커야 all-gather가 짧아져 계산 안에 잘 숨는다는 점은 똑같습니다.

실무 체크리스트 — NCCL 튜닝과 토폴로지 인식

앞서 다룬 개발자 시사점을 곧바로 실행에 옮길 수 있도록, 분산 학습을 셋업할 때 점검할 항목을 체크리스트로 정리합니다.

• 토폴로지 인식 확인: 통신 라이브러리가 노드 안 NVLink/NVSwitch 구조와 노드 간 네트워크를 정확히 인식하는지 확인하십시오. 토폴로지 파일이나 자동 탐지가 어긋나면 최적이 아닌 경로를 탑니다.
• NIC와 GPU 친화도(affinity) 정렬: 각 GPU가 물리적으로 가까운 NIC를 쓰도록 친화도를 맞추십시오. 어긋나면 통신이 불필요하게 CPU 소켓을 가로지릅니다.
• 집합 통신 대역폭 실측: 학습 코드 전에 마이크로벤치마크로 all-reduce 대역폭을 측정하고, 카탈로그 수치 대비 얼마나 나오는지 확인하십시오. 유효 대역폭이 기대보다 낮으면 설정 문제일 가능성이 높습니다.
• 알고리즘 선택 점검: 메시지 크기에 따라 ring과 tree 중 적절한 알고리즘이 선택되는지 확인하고, 필요하면 환경 변수로 유도하십시오.
• 버킷 크기 조정: 그래디언트 버킷이 너무 작으면 통신 오버헤드가 늘고, 너무 크면 오버랩 기회가 줄어듭니다. 모델에 맞는 적정 크기를 찾으십시오.
• 오버랩 타임라인 확인: 프로파일러로 통신이 실제로 연산 뒤에 숨는지 눈으로 확인하십시오. 통신 꼬리가 드러나면 버킷과 비동기 설정을 손보십시오.
• 병렬화 차원 배치 점검: 텐서/전문가 병렬이 NVLink 도메인 경계 안에 들어가는지, 데이터/파이프라인 병렬이 스케일아웃에 놓이는지 확인하십시오.
• 스케일링 효율 추적: GPU 수를 늘릴 때마다 처리량이 비례해 느는지 기록하고, 효율이 꺾이는 지점을 병목 신호로 삼으십시오.

이 체크리스트는 특정 라이브러리에 한정되지 않는 일반 원칙입니다. 핵심은 "하드웨어가 가진 대역폭을 소프트웨어가 끝까지 끌어내고 있는가"를 늘 의심하고 측정하는 태도입니다.

마치며

AI 인프라의 경쟁이 칩 단위에서 시스템 단위로 옮겨 가면서, 인터커넥트는 더 이상 배경 인프라가 아니라 성능을 가르는 핵심 변수가 되었습니다. NVLink와 NVSwitch가 만드는 스케일업 도메인, GB200 NVL72 같은 랙 스케일 시스템, UALink와 Ultra Ethernet 같은 개방형 대안, 그리고 Google TPU의 광 회로 스위치까지, 모두가 같은 질문에 서로 다른 답을 내놓고 있습니다. "어떻게 더 많은 가속기를 손실 없이 하나처럼 묶을 것인가."

개발자에게 이 모든 이야기가 주는 교훈은 한 가지로 모입니다. 연산만 보지 말고 통신을 보라는 것입니다. 통신을 이해하면 왜 어떤 학습은 GPU를 늘려도 빨라지지 않는지, 왜 어떤 추론은 지연이 길어지는지, 왜 같은 모델이 다른 클러스터에서 전혀 다른 효율을 내는지가 보이기 시작합니다. 그리고 그 이해가 곧 더 빠르고 더 저렴한 AI 시스템을 만드는 출발점이 됩니다.

참고 자료

• NVIDIA 공식 사이트
• NVIDIA 개발자 문서
• NVIDIA NCCL — 집합 통신 라이브러리
• UALink Consortium
• Ultra Ethernet Consortium
• Google Cloud TPU
• AMD 공식 사이트
• SemiAnalysis — 반도체/인프라 분석
• IEEE Spectrum — 반도체와 컴퓨팅