CPU-GPU 결합과 노드 아키텍처 — DGX Spark 해부

GPU 옆에 CPU가 필요한 이유

학습 잡에서 GPU 사용률이 60%밖에 안 나온다면, 원인의 상당수는 GPU 바깥에 있다.

• 데이터 로딩 — 스토리지에서 읽어 디코딩·토크나이징하는 작업. 이미지·비디오가 섞이면 CPU 부하가 급증한다.
• 전처리와 증강 — 텐서로 만들어 GPU에 올리기 전까지의 모든 것.
• 에이전트 오케스트레이션 — 추론 시점에 도구 호출, 검색, 분기 판단. 에이전틱 워크로드가 늘수록 이 부분의 비중이 커진다.
• 통신 스케줄링 — 어느 텐서를 언제 보낼지 결정하고 커널을 띄우는 일.

이 작업들이 늦으면 GPU는 기다린다. 그리고 CPU가 준비한 데이터를 GPU로 옮기는 통로가 PCIe라면, 그 통로는 HBM보다 100배 이상 좁다.

세 가지 결합 방식

코히어런트 결합이 실제로 바꾸는 것

NVLink-C2C 같은 코히어런트 링크는 단순히 「빠른 PCIe」가 아니다. 캐시 일관성(coherence) 이 보장되므로, GPU가 CPU 메모리의 주소를 그대로 참조할 수 있고 명시적인 복사 코드가 필요 없어진다. 프로그래밍 모델 자체가 바뀐다.

왜 모두 자기 CPU를 만드는가

표를 관통하는 논리는 두 가지다.

1. 기술적 이유 — 코히어런트 링크는 양쪽 다이를 다 설계할 수 있어야 만들 수 있다. 남의 CPU에 NVLink-C2C를 붙일 수는 없다.
2. 경제적 이유 — 랙 단위로 팔리는 시장에서 CPU를 남에게 사면 그만큼 마진이 빠진다. 규모가 충분히 크면 직접 만드는 편이 싸다.

Vera·Venice 등 커리큘럼 기준 시점에 출하 전인 제품의 사양은 벤더 발표값이다. 수업 직전 최신 자료로 확인할 것.

DGX Spark 해부 — 책상 위의 랙 한 칸

이 과목의 실습 장비인 DGX Spark는 GB10을 탑재한 소형 시스템이다. 성능만 보면 랙 제품과 비교할 수 없지만, 구조의 원리는 같다. Arm CPU와 Blackwell GPU가 한 패키지에서 메모리를 공유한다 — GB200/VR200에서 Grace(Vera)와 Blackwell(Rubin)이 하는 일과 정확히 같은 관계다.

이 장비로 무엇을 할 수 있는가

NVIDIA가 이 장비를 어떤 용도로 제안하는지 보면, 「책상 위 장비」의 자리가 어디인지 감을 잡을 수 있다.

실습 — 내 장비의 토폴로지를 읽는다

# GPU와 상호연결 구조
nvidia-smi topo -m
nvidia-smi -q | head -60

# CPU 쪽 구성
lscpu | egrep 'Model name|Socket|Core|NUMA'
numactl --hardware

# 메모리 구성 (통합 메모리인지 확인)
free -h
cat /proc/meminfo | egrep 'MemTotal|HugePages'

# CUDA 샘플의 대역폭 테스트 (경로는 설치에 따라 다름)
bandwidthTest --mode=shmoo

# 측정할 세 가지
#   1) Host to Device
#   2) Device to Host
#   3) Device to Device

참고 자료

• NVIDIA — Grace Hopper Superchip Architecture In-Depth : 이 페이지 도해 대부분의 출처
• NVIDIA DGX Spark 제품 페이지
• CUDA Programming Guide — Unified Memory 장
• Wikimedia Commons — DGX Spark 사진 (dllu, CC BY-SA 4.0)