AI 데이터센터 네트워크

AI 인프라를 이야기할 때 가장 먼저 떠오르는 것은 GPU다. H100, H200, B200, B300 같은 이름이 나오고, FLOPS가 얼마인지 텐서 코어 성능이 얼마나 좋아졌는지 시작한다. 그런데 막상 AI 시스템을 실제로 운영해 보면 질문은 조금 달라진다. GPU가 얼마나 빠른가보다 더 중요한 질문이 있다. GPU에 데이터를 얼마나 빨리 먹일 수 있는가? 여러 GPU가 서로 얼마나 빨리 대화할 수 있는가? GPU가 계산하지 못하고 기다리는 시간은 어디에서 생기는가? AI 인프라의 병목은 이제 단순한 연산 성능 문제가 아니다. 칩 안에서는 메모리가, 서버 안에서는 PCIe와 NVLink가, 서버 밖에서는 InfiniBand와 RoCEv2 네트워크가 성능을 결정한다. 이번 글에서는 AI 데이터센터 네트워크 관련 내용을 정리해 본다.

1. 왜 AI에는 CPU보다 GPU가 중요한가?

CPU와 GPU는 애초에 잘하는 일이 다르다. CPU는 복잡한 제어 흐름에 강하다. 운영체제를 돌리고, 파일 시스템을 처리하고, 네트워크 스택을 관리하고, 애플리케이션 로직을 실행한다. 분기가 많고 순서가 중요한 작업에 적합하다.

GPU는 다르다. 같은 종류의 단순 계산을 엄청나게 많이, 동시에 처리하는 데 강하다. 딥러닝의 핵심 연산은 대부분 행렬 곱셈과 벡터 연산이다. 특히 트랜스포머 모델은 대규모 병렬 연산 구조를 갖고 있다. 그래서 AI 모델 학습과 추론은 GPU의 구조와 잘 맞는다.

쉽게 말하면 CPU는 지휘자에 가깝고, GPU는 대규모 계산 공장에 가깝다. 예를 들어, PyTorch 코드에서torch.matmul() 한 줄을 실행하더라도 내부에서는 Python, PyTorch C++ Backend, CUDA Runtime, NVIDIA Driver, GPU Command Queue, GPU Kernel을 거친다. CPU는 이 과정을 준비하고 지시한다. 실제 행렬 연산은 GPU의 CUDA Core와 Tensor Core가 수행한다. 따라서 AI 워크로드에서 CPU가 사라지는 것은 아니다. CPU는 여전히 필요하다. 다만 핵심 계산의 무게중심이 GPU로 이동한다.

2. 그런데 병목은 GPU 연산이 아니다.

흥미로운 점은 GPU가 너무 느려서 문제가 생기는 경우보다, GPU가 너무 빨라서 문제가 생기는 경우가 많다는 것이다. GPU의 연산 코어는 엄청난 속도로 계산할 수 있다. 하지만 계산하려면 데이터가 필요하다. 모델 가중치, 입력 토큰, 중간 활성값, KV Cache가 계속 GPU 메모리에서 읽혀야 한다.

문제는 메모리가 GPU 연산 속도를 충분히 따라가지 못한다는 점이다. 이 현상을 흔히 ‘메모리 월(Memory Wall)’ 이라고 부른다. 연산 장치(Compute Unit)는 계속 빨라지는데, 데이터를 공급하는 메모리 대역폭은 그만큼 빠르게 증가하지 않는다. 결국 GPU는 계산할 준비가 되어 있어도 데이터를 기다리게 된다. AI 인프라에서 자주 나오는 표현이 있다. GPU Core가 놀고 있다. 말 그대로 연산 장치는 비싸고 빠른데, 메모리에서 데이터가 늦게 도착하면 GPU는 대기하고, 이 대기 시간이 비용으로 바뀐다.

3. LLM 추론의 병목은 Prefill과 Decode에서 다르다.

LLM 추론은 크게 두 단계로 나뉜다. 입력 프롬프트를 처리하는 프리필(Prefill) 단계가 있고, 출력 토큰을 하나씩 생성하는 디코드(Decode) 단계가 있다. 프리필은 비교적 GPU가 잘하는 작업이다. 입력 토큰 전체를 한 번에 처리할 수 있고, 대규모 행렬 연산이 많다. 병렬화가 잘 된다. 이 단계에서는 GPU의 연산 성능이 중요하다.

그러나 디코드는 성격이 다르다. 모델은 다음 토큰을 한 개씩 생성한다. 다음 토큰은 이전 토큰에 의존한다. 그래서 완전히 병렬로 처리하기 어렵다. 매번 모델 가중치와 이전 토큰들의 KV Cache를 읽고, 작은 계산을 수행한 뒤, 다시 다음 토큰으로 넘어간다. 이때 병목은 GPU FLOPS가 아니라 HBM 대역폭이다. 그래서 LLM 추론에서 출력 토큰이 입력 토큰보다 비싸다. 입력은 한 번에 병렬 처리할 수 있지만, 출력은 순차적으로 만들어야 한다. 긴 답변일수록 디코드 시간이 누적되고 비용도 증가한다.

4. KV 캐시는 속도를 높이지만 메모리를 차지한다.

LLM은 다음 토큰을 만들 때 이전 토큰들의 문맥을 참고한다. 이 과정을 매번 처음부터 다시 계산하면 너무 비싸다. 그래서 이전 토큰의 Key와 Value를 저장해 두고 다시 사용한다. 우리는 이것을 ‘KV 캐시(Cache)’ 라고 부른다.

KV 캐시는 계산량을 줄여준다. 하지만 공짜는 아니다. 메모리를 사용한다. KV 캐시 크기는 배치 크기, 레이어 수, 컨텍스트 길이, 히든(Hidden) 레이어 크기에 비례해서 커진다. 동시 사용자가 많아지거나 컨텍스트가 길어지거나, 에이전트가 여러 번 모델을 호출하면 GPU HBM은 빠르게 부족해진다.

특히, 에이전틱 AI에서는 이 문제가 더 커진다. 일반 챗봇은 보통 한 번의 요청과 한 번의 응답으로 끝난다. 하지만 에이전트는 계획을 세우고, 도구를 호출하고, 결과를 확인하고, 다시 계획을 수정한다. 이 과정에서 모델 호출이 여러 번 발생한다. 시스템 프롬프트, 대화 기록, 검색 결과, 코드, 로그, 도구 실행 결과도 계속 누적된다. 결국 에이전틱 AI는 단순히 모델을 한 번 호출하는 문제가 아니다. 긴 상태를 유지하면서 여러 번 추론을 반복하는 시스템 문제다. 이때 병목은 자연스럽게 HBM, KV Cache, 스케줄링, 네트워크, 스토리지로 확장된다.

5. AI 훈련, 추론, 에이전틱 AI는 같은 레벨이 아니다.

AI 훈련은 모델의 가중치를 만드는 과정이다. 데이터를 넣고, 출력과 정답의 차이를 계산하고, 역전파로 가중치를 수정한다. 이 과정에서는 Forward, Backward, Optimizer가 모두 중요하다. AI 추론은 학습된 모델을 사용하는 과정이다. 가중치는 고정되어 있고, 입력에 대해 예측이나 응답을 생성한다. LLM 추론에서는 Prefill과 Decode의 성격이 다르며 Decode 단계에서 메모리 병목이 커진다.

에이전틱 AI는 훈련이나 추론과 같은 모델 생명주기 단계가 아니다. 추론 모델을 사용해 계획, 도구 실행, 결과 확인, 재계획을 반복하는 애플리케이션 구조다. 그래서 에이전틱 AI의 핵심 지표도 단순한 tokens/sec만으로는 부족하다. 실제로는 하나의 업무를 성공적으로 끝내는 데 얼마의 비용이 들었는지 CPSO(Cost per Successful Outcome)가 더 중요해진다.

6. DMA는 CPU를 쉬게 만든다.

현대 서버에서 대용량 데이터 이동은 CPU가 직접 한 바이트씩 복사하지 않는다. 대부분 DMA(Direct Memory Access)를 사용한다. CPU는 어디에서 어디로 얼마나 옮길지만 설정한다. 실제 데이터 이동은 NVMe 컨트롤러, NIC, GPU Copy Engine 같은 장치가 수행한다.

이 구분은 중요하다. CPU는 Control Path를 담당하고, DMA 장치와 GPU, NIC는 Data Path를 담당한다. 그러니깐 CPU는 지시하고 장치가 옮긴다. RDMA와 GPUDirect RDMA도 같은 관점에서 보면 이해하기 쉽다. CPU와 OS를 완전히 제거하는 기술이 아니라, 반복적인 대용량 데이터 전송 경로에서 CPU와 커널의 개입을 줄이는 기술이다.

7. 그렇다면, 원격 메모리 접근은?

한 서버의 RNIC가 다른 서버의 등록된 메모리에 직접 데이터를 쓰거나 읽는다. 이때 원격 CPU가 매번 데이터를 복사하지 않아도 된다. RDMA에서는 사용할 메모리를 미리 등록한다. 이 과정에서 메모리 페이지를 고정하고, RNIC가 접근할 수 있는 주소 변환 정보를 준비하고, 접근 권한 키를 발급한다.

Queue Pair, Completion Queue, Work Request 같은 구조도 사용한다. RDMA Write는 로컬 서버가 원격 메모리에 데이터를 쓰는 방식이다. RDMA Read는 로컬 서버가 원격 메모리에서 데이터를 읽는 방식이다. Send/Receive는 메시지 기반 통신에 더 가깝다. 핵심은 반복적인 데이터 이동에서 CPU와 커널의 개입을 줄인다는 점이다. 그것이 바로 RDMA(Remote Direct Memory Access)이다.

8. InfiniBand와 RoCEv2 비교

AI 클러스터에서 RDMA를 구현하는 대표 기술은 단연 인피니밴드(InfiniBand)와 RoCEv2다. 인피니밴드는 RDMA를 위해 설계된 전용 네트워크 패브릭이다. 낮은 지연시간, 높은 대역폭, 안정적인 혼잡 제어, SHARP 같은 기능을 제공한다.

RoCEv2는 이더넷, IP, UDP 위에 인피니밴드 RDMA 트랜스포트를 올린 방식이다. 기존 이더넷 생태계를 활용할 수 있지만, 그만큼 네트워크 설계가 중요하다. RoCEv2에서는 PFC, ECN, DCQCN 같은 혼잡 제어가 제대로 동작해야 한다. 그렇지 않으면 패킷 손실, Head-of-Line Blocking, NCCL timeout이 발생할 수 있다.비유하자면, 인피니밴드가 전용 고속도로라면, RoCEv2는 일반 도로를 고속도로처럼 운영하려는 접근에 가깝다. 그래서 운영 난이도와 튜닝 포인트가 다르다.

9. NCCL은 GPU들이 대화하는 방식

NCCL은 NVIDIA GPU 간 Collective Communication을 수행하는 라이브러리다. PyTorch Distributed에서 backend=”nccl”을 사용하면 내부적으로 NCCL이 GPU 간 통신을 처리한다. 분산 학습에서 대표적인 연산은 AllReduce다. 각 GPU가 서로 다른 mini-batch를 계산하면 gradient가 서로 다르다. 이 gradient를 평균내서 모든 GPU가 같은 업데이트를 적용해야 한다.

AllReduce는 보통 Reduce-Scatter와 All-Gather로 나눠 수행된다. Ring AllReduce에서는 GPU들이 논리적인 링을 만들고, 데이터를 조각으로 나눠 서로 주고받는다. 모든 링크를 동시에 활용할 수 있어 효율적이다.

하지만 GPU 수가 많아질수록 네트워크가 중요해진다. 한 GPU가 느리면 다른 GPU들이 기다린다. 한 링크가 나쁘면 전체 학습이 느려진다. NCCL timeout은 단순한 에러 메시지가 아니라, 클러스터 어딘가의 병목이나 장애를 드러내는 신호일 수 있다.

10. Scale-Up과 Scale-Out은 다르다.

GPU 클러스터 확장은 크게 두 방향으로 나뉜다. Scale-Up은 서버 내부 또는 랙 내부에서 GPU를 고속으로 묶는 방식이다. NVLink, NVSwitch, NVL72가 여기에 해당한다. 지연시간이 낮고 대역폭이 높다. Tensor Parallelism처럼 자주 동기화해야 하는 작업에 유리하다.

Scale-Out은 여러 서버와 여러 랙을 네트워크로 연결하는 방식이다. InfiniBand, RoCEv2, Ethernet Fabric이 여기에 해당한다. 대규모 확장이 가능하지만, 네트워크 지연시간과 대역폭 관리가 중요해진다. 가능하다면 빠른 Scale-Up 도메인 안에서 많은 통신을 처리하는 것이 좋다. 더 큰 규모가 필요할 때 Scale-Out으로 확장한다. 이 방향은 앞으로 더 중요해질 가능성이 크다. NVL72처럼 한 랙 안에서 많은 GPU를 하나의 큰 NVLink 도메인처럼 묶는 구조가 등장하는 이유도 여기에 있다.

11. AI 데이터센터 네트워크는 서버 연결망이 아니다.

일반적인 데이터센터 네트워크는 서버와 서버를 연결하는 관점으로 설계된다. AI 데이터센터에서는 관점이 달라져야 한다. 핵심은 GPU 메모리와 GPU 메모리 사이의 데이터 이동이다.

AI 데이터센터에는 목적별 패브릭(Fabric)이 필요하다. 데이터셋과 체크포인트를 위한 Storage Fabric, 학습용 GPU 통신을 위한 Training Fabric, 추론 요청과 KV Cache 이동을 위한 Inference Fabric, 운영과 모니터링을 위한 Management Fabric이 나뉠 수 있다.

특히 학습 Fabric에서는 AllReduce, AllGather, AlltoAll 같은 Collective가 중요하다. 추론 Fabric에서는 Prefill과 Decode 분리, KV Cache 이동, Cache-aware Routing, 모델 서비스 간 호출이 중요하다. AI 네트워크는 단순히 빠른 스위치를 넣는다고 해결되지 않는다. GPU와 NIC의 배치, PCIe 토폴로지, Rail 설계, 혼잡 제어, 광모듈 상태, NCCL 경로 선택까지 함께 봐야 한다.

12. Rail-Optimized Design이 중요한 이유

AI 서버에는 보통 여러 GPU와 여러 NIC가 있다. 이때 각 GPU를 특정 네트워크 Rail에 대응시키는 설계를 ‘레일 최적화 디자인(Rail-Optimized Design)’ 이라고 볼 수 있다. 예를 들어, 서버마다 8개의 GPU가 있다면 GPU 0은 Rail 0, GPU 1은 Rail 1, 이런 식으로 일관되게 매핑한다. 여러 서버가 같은 방식으로 연결되면 GPU 간 통신 경로가 예측 가능해진다.

이 설계는 네트워크 경로를 단순하게 만들고, 특정 링크에 트래픽이 몰리는 상황을 줄인다. 특히 대규모 학습에서 GPU들이 반복적으로 통신할 때 효과가 크다. 서버를 연결하는 것이 아니라 GPU의 통신 패턴을 기준으로 네트워크를 설계해야 한다.