들어가며
CPU는 NVMe 드라이브, 네트워크 카드, 혹은 GPU와 어떻게 대화를 나눌까요? 대부분의 소프트웨어 엔지니어는 드라이버나 커널 모듈이 알아서 해주겠거니 믿고, 그 밑바닥 메커니즘까지는 깊게 생각하지 않습니다. 하지만 성능 이슈를 디버깅하거나, 인터럽트 처리를 튜닝하거나, perf가 가리키는 병목 현상의 원인을 파악하려면 하드웨어 레벨에서 무슨 일이 벌어지는지 반드시 알아야 합니다.
x86 시스템은 CPU와 주변 장치 간 통신을 위해 크게 세 가지 메커니즘을 사용합니다:
- Port-mapped I/O (PMIO): CPU가 별도의 I/O 명령어를 사용해 독립된 주소 공간에 접근합니다.
- Memory-mapped I/O (MMIO): 주변 장치가 자신의 제어 레지스터를 메모리 주소처럼 노출합니다.
- Direct Memory Access (DMA): 주변 장치가 CPU의 개입 없이 RAM과 데이터를 직접 주고받습니다.
NVMe 드라이브, 네트워크 카드, GPU 같은 현대적인 PCIe 장치들은 거의 전적으로 MMIO와 DMA를 사용합니다. PMIO는 구형 ISA 장치나 하위 호환성 모드에서나 볼 수 있는 유물이죠. 이 메커니즘들을 이해하면 시스템의 동작을 해석하는 눈이 생깁니다. 왜 DMA 버퍼 크기가 처리량(Throughput)에 영향을 주는지, 왜 인터럽트 조절(Moderation)이 레이턴시에 중요한지, 그리고 irqaffinity 같은 커널 파라미터가 실제로 무엇을 제어하는지 알게 되니까요.
이 글에서는 각 메커니즘의 작동 원리와 성능 특성, 그리고 실제 시스템에서 이들을 어디서 마주치게 되는지 낱낱이 파헤쳐 보겠습니다.
x86 통신 채널 이해하기
현대 x86 시스템은 컴포넌트 간 데이터 이동을 위해 주로 세 가지 통신 경로를 사용합니다.
CPU-메모리 버스 (CPU-Memory Bus)
CPU-메모리 버스는 프로세서와 RAM을 잇는 전용 고속도로입니다. 요즘 CPU들은 내장 메모리 컨트롤러를 통해 여러 채널(플랫폼에 따라 보통 2~8개)을 운용합니다. 듀얼 채널 DDR4-3200 구성만 해도 CPU에 이론상 51.2 GB/s의 대역폭을 제공하죠. 이 버스는 다른 어떤 장치와도 공유되지 않습니다.
PCIe: 점대점 직렬 인터페이스 (Point-to-Point Serial Interface)
PCIe(Peripheral Component Interconnect Express)는 GPU, NVMe SSD, 네트워크 카드, RAID 컨트롤러 등 대부분의 내부 하드웨어를 연결합니다. 과거의 공유 버스 아키텍처와 달리, PCIe는 점대점(Point-to-Point) 링크를 사용합니다. 각 장치가 CPU나 PCIe 스위치와 전용 회선으로 연결되므로 물리 계층에서의 경합(Contention)이 사라졌죠. 물론 PCIe 스위치나 루트 컴플렉스(Root Complex) 상위 단계에서는 여전히 대역폭을 공유할 수 있습니다.
PCIe 레인 (Lanes)
PCIe 연결은 레인(x1, x4, x8, x16)으로 구성됩니다. 각 레인은 두 쌍의 차동 신호선(Differential Pair)—총 4가닥—을 가지며, 한 쌍은 송신용, 다른 한 쌍은 수신용입니다. 레인이 많을수록 대역폭도 정비례해서 늘어납니다:
- x1: 1개 레인
- x4: 4개 레인 (4배 대역폭)
- x16: 16개 레인 (16배 대역폭)
GPU는 보통 x16을, NVMe SSD는 x4를 씁니다. x4 카드를 x16 슬롯에 꽂아도 잘 작동합니다.
PCIe 세대 (Generations)
세대가 거듭될 때마다 레인당 대역폭은 대략 두 배씩 뜁니다:
- PCIe 3.0: 레인당 ~1 GB/s (x4 = ~4 GB/s, x16 = ~16 GB/s)
- PCIe 4.0: 레인당 ~2 GB/s (x4 = ~8 GB/s, x16 = ~32 GB/s)
- PCIe 5.0: 레인당 ~4 GB/s (x4 = ~16 GB/s, x16 = ~64 GB/s)
이 수치들은 128b/130b 인코딩 오버헤드(약 1.5% 손실)를 감안한 실제 처리량입니다. PCIe 4.0 x4 NVMe SSD는 8 GB/s를 찍을 수 있는 반면, PCIe 3.0 x4는 4 GB/s가 한계입니다.
DMA: 직접 메모리 접근 (Direct Memory Access)
DMA는 장치가 CPU를 거치지 않고 RAM을 읽고 쓸 수 있게 해줍니다. CPU가 데이터를 바이트 단위로 복사하는 대신, 장치가 메모리에 직접 접근하는 방식이죠.
작동 과정은 이렇습니다:
- CPU가 장치에게 명령합니다: “메모리 주소 0x12345000에 64KB를 써라.”
- 장치는 PCIe 연결을 타고 물리 메모리에 데이터를 직접 씁니다.
- 작업이 끝나면 장치가 인터럽트를 날려 완료 신호를 보냅니다.
- CPU는 결과를 처리합니다.
CPU는 명령을 내리고 완료 보고만 받을 뿐, 데이터 전송에는 손을 떼고 있습니다. 초당 기가바이트 단위로 데이터를 퍼 나르는 100GbE 랜카드나 NVMe SSD 같은 고성능 장비에 DMA는 필수입니다. DMA가 없다면 CPU는 모든 패킷과 디스크 블록을 복사하느라 말 그대로 ‘먹통’이 될 테니까요.
이제 이 통신 메커니즘을 바탕으로, 장치들이 PCIe를 통해 연결되는 두 가지 주요 방식을 살펴보겠습니다.
직통 vs 우회: PCIe 연결 방식

CPU 직결 연결 (CPU-Direct)
여러분의 CPU에는 소켓에 직접 배선된 16~20개의 PCIe 레인(메인스트림 플랫폼 기준)이 있습니다. 인텔은 CPU 다이에서 바로 나오고, AMD 라이젠은 컴퓨트 칩렛이 아닌 I/O 다이에서 나옵니다. 스레드리퍼(Threadripper)나 EPYC 같은 워크스테이션/서버 플랫폼은 이보다 훨씬 많은 48~128개의 직결 레인을 제공합니다.
CPU 직결 연결은 경합 없는 ‘풀 대역폭’을 보장합니다. PCIe 4.0 x16 연결은 양방향 각각 ~31.5 GB/s를 제공합니다(전이중 통신이 가능하지만, 실제 워크로드에서 양방향을 동시에 꽉 채우는 경우는 드뭅니다). 주(Primary) GPU가 첫 번째 PCIe x16 슬롯을 차지하는 이유가 바로 이 직결 레인을 독점하기 위해서입니다. 고급형 메인보드에서는 두 번째 x16 슬롯도 CPU 직결일 수 있습니다. ‘레인 분할(Bifurcation)’ 기능을 통해 하나의 x16 연결을 두 개의 x8/x8로 나눌 수 있는데, 대역폭은 반토막 나지만 GPU 워크로드가 PCIe 대역폭을 포화시키는 일은 드물어서 듀얼 GPU 구성 시 성능 손실은 미미한 편(0~5%)입니다.
칩셋: 다중화 허브 (The Chipset)
칩셋은 수십 개의 I/O 장치를 한데 모으는 역할을 합니다. USB 컨트롤러(보통 10개 이상의 포트), SATA 드라이브, 오디오 코덱, 네트워크 인터페이스, 보조 PCIe 슬롯, 그리고 레거시 I/O가 여기에 물립니다.
칩셋은 전용 링크를 통해 CPU와 통신합니다. 인텔의 DMI 3.0은 ~4 GB/s(PCIe 3.0 x4와 유사하지만 프로토콜 최적화가 들어감)를, DMI 4.0은 그 두 배인 ~8 GB/s를 제공합니다. AMD는 플랫폼마다 다르지만, X570/B550에서는 보통 PCIe 4.0 x4를 사용하여 ~8 GB/s를 제공합니다.
중요한 건, 칩셋에 연결된 모든 장치가 이 링크 하나를 공유한다는 점입니다.
왜 이런 아키텍처가 존재할까?
I/O가 복잡해질수록 제조 비용이 급증하기 때문입니다. PCIe 레인 하나하나가 SerDes(직렬/병렬 변환기) 로직, PHY 계층, CPU 패키지와 메인보드의 물리적 배선, 그리고 추가 핀을 필요로 합니다. 레인이 많아지면 다이 면적이 커지고 수율은 떨어집니다. CPU에 직결 레인 100개를 박아 넣으려면 가격이 천정부지로 솟고 메인보드 크기도 엄청나게 커질 겁니다.
대부분의 I/O 장치는 동시에 최대 대역폭을 쓰지 않습니다. 1Gbps 랜카드는 기껏해야 125 MB/s를 쓰고, USB 3.2 Gen 2 장치는 ~1.2 GB/s, SATA SSD는 ~600 MB/s가 한계입니다. 이들이 동시에 풀로 돌아가는 일은 드뭅니다. 칩셋은 이 점을 노려 ‘통계적 다중화(Statistical Multiplexing)‘를 수행합니다. 평소 칩셋 사용률은 활발한 워크로드 중에도 10~30% 수준에 머무르니까요.
하지만 칩셋 대역폭 한도를 초과하는 순간—예를 들어 칩셋 M.2 슬롯(보통 메인보드의 2, 3번 슬롯)에 꽂힌 NVMe 드라이브끼리 파일을 복사하면서 동시에 영상을 스트리밍하고 다운로드를 걸어놓으면—장치들은 대역폭을 놓고 싸우기 시작하고 처리량은 N분의 1로 줄어듭니다. DMI 링크가 병목이 되어 전송 속도가 곤두박질치는 거죠.
이게 언제 문제가 되느냐: 칩셋 NVMe 슬롯에 RAID를 구성하거나, SATA 드라이브 간 복사를 하면서 10GbE 전송을 하거나, 스토리지 작업 중에 헤비한 USB 3.2 장치를 쓸 때 칩셋 대역폭이 포화됩니다. 게임, 웹 서핑, 단일 고속 드라이브를 쓰는 영상 편집 같은 단일 스레드 작업 흐름에서는 칩셋 한계에 도달할 일이 거의 없습니다. 만약 iostat을 돌려봤는데 칩셋 장치들의 합계 처리량이 7 GB/s를 넘긴다면, 이미 천장에 머리를 찧고 있는 겁니다.
확실한 고대역폭이 필요한 장치는 CPU 직결 레인을 받고, 나머지는 칩셋 링크를 나눠 씁니다. 총수요가 용량을 넘지 않는 한 이 방식은 잘 작동합니다.
이러한 이중 경로(Dual-path) 아키텍처는 인텔과 AMD의 경쟁 속에서 크게 진화해 왔습니다.
두 아키텍처 이야기: 인텔과 AMD의 I/O 진화
오늘날 우리가 겪는 대역폭 문제는 CPU가 바깥세상과 연결되는 방식의 근본적인 변화에서 비롯되었습니다. 왜 두 번째 GPU가 대역폭 기근에 시달리는지 이해하려면, 우리가 어떻게 여기까지 왔는지 살펴봐야 합니다.
노스브리지/사우스브리지 시대
90년대 후반부터 2010년대 초반까지 PC 아키텍처는 두 개의 칩으로 나뉘어 있었습니다:
- 노스브리지(Northbridge): 고속 부품 담당 (CPU, GPU, 메모리)
- 사우스브리지(Southbridge): 나머지 전부 담당 (스토리지, 네트워크, USB, 오디오)
모든 스토리지와 네트워크 트래픽은 사우스브리지와 노스브리지 사이의 연결(주로 대역폭 2 GB/s 수준의 DMI 2.0)을 통과해야 했습니다. 하드디스크가 최고 100~200 MB/s, 기가비트 이더넷이 125 MB/s 정도일 때는 이걸로 충분했죠.

대역폭 대폭발
NVMe SSD가 판도를 뒤집었습니다. 1세대 NVMe 드라이브(2013-2014)는 순차 읽기 속도가 2~3 GB/s에 달해 칩셋 연결 전체를 포화시킬 수 있었습니다. 2020년에 이르러 플래그십 드라이브는 7 GB/s를 넘겼습니다. 사우스브리지 연결 구간은 심각한 병목 지점이 되었습니다.
AMD의 Zen 혁신
AMD가 Zen 아키텍처(2017년 라이젠 1000 시리즈)를 설계할 때, 그들은 NVMe SSD를 위해 CPU에서 직접 나오는 PCIe 3.0 4개 레인을 할당했습니다. 덕분에 메인 스토리지 장치는 칩셋을 완전히 우회하여 ~4 GB/s의 전용 대역폭을 확보할 수 있었죠.
Zen 2(라이젠 3000, 2019)부터는 모든 PCIe와 메모리 컨트롤러를 관리하는 별도의 I/O 다이를 둔 칩렛 디자인으로 넘어갔습니다. 이 아키텍처 덕분에 공격적인 PCIe 세대 도입이 가능했습니다:
- 라이젠 3000: PCIe 4.0 (레인당 대역폭 2배 → ~2 GB/s)
- 라이젠 5000: PCIe 4.0 구현 최적화
- 라이젠 7000: PCIe 5.0 도입, CPU에서 총 24개 레인 제공:
- 16 레인: GPU용
- 4 레인: 메인 NVMe용 (PCIe 5.0 기준 ~8 GB/s 이상)
- 4 레인: 칩셋 연결용
PCIe 세대가 바뀔 때마다 레인당 대역폭은 두 배가 됩니다. PCIe 3.0은 ~1 GB/s, 4.0은 ~2 GB/s, 5.0은 ~4 GB/s입니다. PCIe 4.0 x4 NVMe 드라이브는 이론상 8 GB/s를 낼 수 있어 구형 칩셋 연결 속도를 훨씬 상회합니다.
인텔의 대응
인텔 CPU는 스카이레이크(6세대, 2015) 이후로 직결 PCIe 레인을 제공해 왔지만, 전통적으로 16개 레인 모두 GPU에 할당되었습니다. **로켓 레이크(11세대, 2021)**와 Z590 칩셋에 와서야 인텔은 레인 분할을 도입했습니다. CPU의 16개 레인을 x8+x4+x4로 나누거나 추가 레인을 두어, GPU 연결성을 유지하면서 M.2 드라이브를 CPU에 직결할 수 있게 했죠.
인텔은 11세대에서 PCIe 4.0을, 12세대(앨더 레이크)에서 PCIe 5.0을 채택하며 대역폭 능력 면에서 AMD와 동등한 수준에 도달했습니다.
이게 지금 왜 중요할까?
칩셋을 경유하던 I/O가 CPU 직결로 넘어가는 추세가 현대의 대역폭 경합 문제를 설명해 줍니다. CPU에 붙은 PCIe 레인은 한정된 자원입니다. 두 번째 GPU를 장착하면 보통 16개의 GPU 레인을 x8+x8로 나누게 됩니다. 여기에 직결 NVMe 드라이브를 추가하면 같은 자원 풀에서 레인을 끌어다 쓸 수도 있습니다. 고속 랜카드나 캡처 카드까지 더하면 경쟁은 더 치열해집니다.
내 장치가 어디에 연결되어 있는지—CPU 직결 레인인지 칩셋 레인인지—이해하는 것이 대역폭 기근을 진단하는 첫걸음입니다.
대역폭 전쟁: 두 번째 GPU가 도로를 공유할 때
칩셋에 연결된 모든 장치—두 번째 GPU, NVMe 드라이브, USB 컨트롤러, 이더넷, SATA 포트—는 CPU로 가는 단 하나의 업링크를 공유합니다.

인텔 플랫폼에서 이 업링크는 DMI(Direct Media Interface) 링크입니다. DMI 4.0은 양방향 각각 8 GB/s (PCIe 4.0 x8 레인 상당)를 제공하여 총 16 GB/s 대역폭을 냅니다. AMD의 칩셋 연결은 플랫폼마다 다릅니다. X570/B550은 PCIe 4.0 x4 (양방향 각각 4 GB/s), X670/X870은 PCIe 4.0 x8 (양방향 각각 8 GB/s)을 사용합니다.
두 번째 GPU가 칩셋을 경유한다면, 활성화된 모든 장치와 대역폭을 놓고 경쟁해야 합니다.
왜 AI 학습이 특히 문제일까?
게이밍은 PCIe 트래픽이 간헐적(Bursty)입니다. GPU가 씬 데이터를 로딩하고, 내부에서 프레임을 렌더링한 뒤, 완성된 프레임을 다시 보냅니다. 반면 AI 학습은 지속적으로 높은 대역폭을 요구합니다. 데이터셋이 스토리지에서 RAM으로 스트리밍되고, 배치가 GPU 메모리로 이동하며, 그라디언트(Gradient)와 체크포인트가 다시 저장되러 나옵니다.
두 번째 GPU와 NVMe 드라이브가 모두 칩셋을 경유한다면, 이들은 같은 업링크를 두고 싸우게 됩니다.
GPU 레인 vs 칩셋 대역폭
두 번째 GPU의 x4 PCIe 4.0 연결은 양방향 각각 ~4 GB/s, 합계 8 GB/s를 제공합니다. 어떤 병목이 먼저 터질지는 워크로드와 플랫폼에 따라 다릅니다.
업로드 경로 (CPU → GPU):
- 학습 데이터: RAM → 칩셋 → GPU
- NVMe 읽기: 스토리지 → 칩셋 → RAM
- X570/B550 같은 AMD 플랫폼(칩셋 업링크 4 GB/s)에서는, 디스크 읽기와 GPU 공급이 동시에 몰리면 GPU의 x4 레인이 꽉 차기도 전에 칩셋 업링크가 먼저 포화됩니다.
- 인텔 DMI 4.0(8 GB/s)에서는, 데이터 로딩이 적당하다면 GPU의 x4 레인이 먼저 한계에 도달하는 경우가 많습니다.
다운로드 경로 (GPU → CPU):
- 그라디언트/체크포인트: GPU → 칩셋 → RAM
- NVMe 쓰기: RAM → 칩셋 → 스토리지 (체크포인트 저장 시)
- 최신 칩셋 링크를 포화시킬 가능성은 낮지만, 경합으로 인한 레이턴시 증가는 여전히 발생합니다.
여러 NVMe 드라이브에서 대용량 데이터셋을 스트리밍하면서 GPU가 데이터를 처리한다면, 특히 X570/B550 플랫폼에서는 칩셋 업링크가 병목이 됩니다. 반면 I/O가 적당하고 GPU 연산 위주의 학습이라면 GPU 자체의 x4 레인이 먼저 발목을 잡습니다.
직결 SSD 레인: 부분적인 해결책
메인 NVMe 드라이브를 CPU 직결 레인(대부분 보드의 첫 번째 M.2 슬롯)에 연결하면 스토리지를 칩셋 경합에서 빼낼 수 있습니다. 이제 디스크 트래픽은 업링크 대역폭을 두고 두 번째 GPU와 싸우지 않습니다.
이로써 데이터 로딩 성능은 개선되지만, 두 번째 GPU는 여전히 나머지 장치들(이더넷, USB 스토리지, 추가 NVMe 드라이브)과 칩셋 업링크를 공유합니다. 만약 네트워크로 그라디언트를 동기화하는 분산 학습을 하거나 여러 드라이브를 동시에 쓴다면 경합은 계속됩니다.
결국 두 번째 GPU는 CPU 직통이 아닌 공유 허브를 통해 x4 PCIe 레인 위에서 돌아가는 셈입니다. 두 번째 GPU가 칩셋을 타느냐 마느냐는 메인보드의 PCIe 레인 분배 방식에 달려 있습니다.
메인보드의 진실: 레인 할당 게임
CPU PCIe 레인을 이해하는 것이 핵심입니다. 인텔 12~14세대 데스크탑 CPU(12900K, 13900K, 14900K 등)는 CPU에서 직접 16개의 PCIe 레인을 제공하며, 보통 단일 GPU용 x16이나 듀얼 GPU용 x8/x8로 구성됩니다. 여기에 M.2 스토리지용 전용 PCIe 4.0 4레인과 칩셋 연결용 DMI 4.0 x8 링크(~15.75 GB/s)가 추가됩니다. AMD 라이젠 7000 시리즈는 총 24개의 가용 PCIe 5.0 레인을 제공합니다(GPU용 16개, M.2용 4개, 칩셋용 4개).
칩셋이 레인을 더 만들어주긴 하지만, 칩셋에 연결된 모든 장치는 CPU로 가는 단일 링크를 공유합니다. CPU 직결 레인은 전용 대역폭을 주지만, 칩셋 레인은 공용 파이프를 나눠 씁니다.
주요 대역폭 수치 (단방향 기준):
- PCIe 3.0 x8: ~7.88 GB/s
- PCIe 4.0 x8: ~15.75 GB/s
- PCIe 5.0 x8: ~31.5 GB/s
PCIe 3.0 x16은 PCIe 4.0 x8과 대역폭이 같습니다(~15.75 GB/s). 즉, 레인 수만큼이나 세대(Generation)도 중요합니다.
인텔 Z790 vs B760: 레인 쪼개기의 차이
인텔 메인보드는 칩셋 등급과 보드 설계에 따라 멀티 GPU 처리 방식이 다릅니다:
Z790 (고급형): 보통 ‘레인 분할(Bifurcation)‘을 지원합니다. CPU의 16개 GPU 레인을 x8/x8로 쪼개서 두 GPU 모두에게 8레인씩 직결 연결을 제공합니다. 분할을 쓰려면 CPU와 보드 펌웨어 모두 지원해야 합니다.
B760 (보급형): 보급형임에도 제조사에 따라 분할 지원 여부가 갈립니다. 스펙을 꼭 확인해야 합니다. 분할을 지원하지 않는 보드는 보통 첫 번째 슬롯에 CPU 16레인을 몰아주고, 두 번째 슬롯은 칩셋 x4 레인으로 연결합니다.
주의: 어떤 보드들은 분할 모드(x8/x8)를 켜면 PCIe Gen 4에서 Gen 3로 속도를 낮추기도 합니다. x8/x8 모드에서 풀 Gen 4 속도가 나오는지 매뉴얼을 확인하세요.

시나리오 A: 제대로 된 레인 분할 (Z790 + Bifurcation)
분할이 활성화된 Z790 보드에서는:
- GPU 1: PCIe 4.0 x8 CPU 직결 (~15.75 GB/s)
- GPU 2: PCIe 4.0 x8 CPU 직결 (~15.75 GB/s)
- M.2 슬롯은 전용 4레인이나 칩셋 레인 사용
두 GPU가 서로 다른 배치를 병렬 처리하는 멀티 GPU AI 워크로드에서 x8 대역폭은 충분합니다. 병목은 GPU 간 빈번한 동기화가 필요하거나 거대 모델을 장치 간에 전송할 때 발생하는데, 일반적인 추론이나 학습 설정에서는 드문 일입니다.
시나리오 B: 칩셋 병목 (B760 분할 미지원)
분할을 지원하지 않는 보드에서는:
- GPU 1: PCIe 4.0 x16 CPU 직결 (~31.5 GB/s)
- GPU 2: 칩셋을 통한 PCIe x4 (대역폭 공유)
칩셋과 CPU 사이의 연결(DMI 4.0 x8)은 총 ~15.75 GB/s 대역폭을 모든 칩셋 장치(SATA, USB, 네트워크, 추가 M.2, 그리고 두 번째 GPU)가 나눠 씁니다. I/O 부하가 심할 때 두 번째 GPU가 가져갈 수 있는 대역폭은 2~4 GB/s 수준으로 떨어질 수 있습니다.
AMD 칩셋 비교
AMD 라이젠 7000 플랫폼도 비슷한 패턴을 보입니다:
X670E/X670: 보통 분할을 지원하여 x8/x8 GPU 구성을 PCIe 5.0 속도로 쓸 수 있습니다. X670E는 칩셋에서도 더 많은 PCIe 5.0 레인을 제공합니다.
B650E/B650: 제조사별로 분할 지원이 다릅니다. B650E는 일부 PCIe 5.0 레인을 주지만, 일반 B650은 보통 GPU와 스토리지에 PCIe 4.0을 씁니다.
칩셋 대역폭 공유 원칙은 똑같습니다. CPU 직결 레인이 칩셋 경유 레인보다 무조건 낫습니다.
레인 재할당 옵션
일부 메인보드는 M.2 슬롯을 포기하고 GPU 연결성을 얻을 수 있게 해줍니다. BIOS에서 특정 M.2 슬롯을 비활성화하면 그 CPU 레인을 두 번째 PCIe 슬롯으로 돌려, 칩셋 x4 레인 대신 CPU 직결 x4 레인으로 업그레이드할 수 있습니다. 메인보드 매뉴얼의 ‘PCIe 구성 표(Configuration Matrix)‘를 보면 어떤 슬롯이 레인을 공유하는지, 재할당 옵션이 있는지 알 수 있습니다. BIOS에서 “PCIe Slot Configuration”, “M.2/PCIe Sharing”, “Bifurcation Mode” 같은 메뉴를 찾아보세요. 저가형 보드는 보통 이런 제어권 없이 배선이 고정되어 있습니다.
비대칭 GPU 구성
비대칭 구성(예: RTX 4090 + RTX 3060)을 쓴다면, 모든 x16 레인을 더 강력한 GPU에 몰아주세요. 약한 카드는 소규모 모델 추론이나 인코딩 같은 보조 작업을 하므로 성능 손실이 덜 중요합니다.
현재 구성 확인하기
메인보드 매뉴얼에서 PCIe 구성 표와 블록 다이어그램을 확인해 CPU 대 칩셋 라우팅을 파악하세요. “Slot 2 operates at x4 and shares bandwidth with M.2_3(슬롯 2는 x4로 작동하며 M.2_3과 대역폭을 공유함)” 같은 문구를 찾아야 합니다.
실제 작동 중인 시스템 구성을 확인하려면 GPU-Z나 HWiNFO를 사용해 링크 폭(Link Width, x8/x16)과 PCIe 세대(3.0/4.0/5.0)를 모두 체크하세요. BIOS 설정이 실제 협상된 속도와 다를 수 있으니까요.
레인 할당은 각 GPU가 낼 수 있는 이론적 최대 대역폭을 결정합니다. x8 직결과 x4 공유의 차이는 멀티 GPU AI 작업에서 수치로 드러납니다. 하지만 이게 여러분의 워크로드에 얼마나 큰 영향을 미칠까요?
심층 분석: 왜 두 번째 GPU는 학습이 느릴까
레인 불평등: 4배의 대역폭 차이
PCIe 레인은 최대 처리량을 직접적으로 결정합니다. 구성 간의 차이는 엄청납니다:
- x16 레인: PCIe 4.0 기준 단방향 ~32 GB/s (합계 64 GB/s)
- x8 레인: 단방향 ~16 GB/s (합계 32 GB/s)
- x4 레인: 단방향 ~8 GB/s (합계 16 GB/s)
x4에서 도는 GPU는 x16보다 대역폭이 4배 적습니다. 24개 레인을 가진 CPU에서 두 GPU를 쓴다면 분할 지원 여부에 따라 x16/x4 혹은 x8/x8이 됩니다. 하지만 칩셋에 연결된 GPU는 보통 x4를 받는데다, 추가적인 문제까지 안고 있습니다.
참고로 PCIe 3.0은 이 수치들의 절반이고, PCIe 5.0은 두 배입니다. 레인 수만큼이나 세대도 중요합니다.
학습 데이터 파이프라인
학습 반복(Iteration)은 다음과 같은 ‘핫 패스(Hot path)‘를 따릅니다:
스토리지 → RAM → GPU 메모리 → 순전파/역전파 → 그라디언트 동기화
매 반복마다 다음이 필요합니다:
- 다음 배치를 RAM에서 GPU 메모리로 로딩
- 순전파(Forward) 및 역전파(Backward) 계산
- 그라디언트 동기화 (멀티 GPU 사용 시)
체크포인트 저장은 매번 하지는 않지만, 배치 로딩 시의 지속적인 처리량 요구가 바로 칩셋 GPU가 힘겨워하는 지점입니다.
칩셋의 이중 페널티 (Double Penalty)
칩셋에 연결된 GPU는 엎친 데 덮친 격의 문제를 겪습니다:

데이터 로딩 단계에서 스토리지 읽기와 GPU 데이터 전송이 순차적으로 발생할 때, 둘 다 CPU로 가는 동일한 칩셋 업링크를 통과해야 합니다. DMI 4.0의 단방향 ~8 GB/s 대역폭 안에서 NVMe 읽기와 GPU 전송이 서로 땅따먹기를 하는 셈입니다.
만약 NVMe 드라이브들도 칩셋에 물려 있다면(데스크탑 빌드에서 흔하죠), 그 ~8 GB/s 업링크 하나로 다음을 다 처리해야 합니다:
- 모든 스토리지 읽기/쓰기 작업
- 모든 GPU 데이터 전송
- 기타 칩셋 I/O (USB, SATA, 경우에 따라 네트워크)
CPU 직결 GPU는 이걸 피합니다. 데이터가 전용 CPU 레인을 통해 RAM에서 바로 오니까요. 오직 스토리지 읽기만 칩셋 대역폭을 씁니다.
프리페칭(Prefetching)이 이를 완화합니다: PyTorch 같은 최신 프레임워크는 GPU가 연산하는 동안 다음 배치를 RAM으로 미리 불러오는(Prefetch) 멀티 프로세스 데이터 로더를 씁니다. 프리페치 워커가 충분하고 RAM이 빠르다면, GPU 연산과 데이터 전송을 겹쳐서 수행할 수 있습니다. 칩셋 GPU가 단순 대역폭 계산보다는 성능이 잘 나오는 이유가 바로 이겁니다. GPU가 바쁠 때 I/O를 처리하니까요.
추론(Inference)은 신경 안 쓴다
추론은 I/O를 아주 적게 씁니다. 모델은 한 번만 로드하고, 입력 데이터는 작으며(기가바이트급 학습 배치 vs 킬로바이트~메가바이트), 역전파도 없습니다. 연산이 주가 되는 상황에서 대역폭은 거의 문제가 안 됩니다. 1MB짜리 추론 입력을 8 GB/s로 보내면 0.125ms밖에 안 걸립니다. 추론 연산 시간에 비하면 티도 안 나죠.
대역폭이 진짜 문제되는 순간
모든 학습 작업이 I/O 병목에 걸리는 건 아닙니다. 두 번째 GPU가 고통받을지는 여기에 달렸습니다:
I/O 고부하 시나리오 (칩셋 연결이 치명적):
- 고해상도 이미지를 쓰는 거대 비전 모델 (ImageNet, COCO 데이터셋)
- 프레임을 계속 로드해야 하는 비디오 처리
- RAM에 다 안 들어가서 스토리지 스트리밍이 필수인 데이터셋
- 학습 중 빈번한 체크포인트 저장
- 데이터 로더의 프리페치 워커 부족 혹은 느린 RAM
I/O 저부하 시나리오 (칩셋 연결도 괜찮음):
- 처음 로드 후 RAM에 쏙 들어가는 작은 데이터셋
- 데이터 대비 연산 비율이 높은 모델 (배치 크기가 적당한 거대 트랜스포머 모델)
- 캐싱된 전처리 특징(Features)으로 학습할 때
- 데이터 이동을 줄여주는 혼합 정밀도(Mixed Precision) 학습
- 공격적인 프리페칭으로 잘 튜닝된 데이터 로더
데이터셋이 한 번 RAM에 올라가서 거기 머문다면 칩셋 연결은 거의 상관없습니다. 대신 GPU 간 통신(분산 학습 시)과 연산 능력이 병목이 되겠죠.
그렇다면 균등한 레인 분배를 위해 최적화해야 할까요, 아니면 비대칭 설정도 괜찮을까요?
균형 잡기: 공평함이 능사는 아니다
PCIe 레인을 두 GPU에 x8/x8로 나누면 각 GPU의 대역폭은 줄어듭니다. 이게 문제가 되는 건 실행 중 PCIe 사용률이 지속적으로 70~80%를 넘길 때입니다. 잠깐 튀는 건 괜찮습니다.
집중이 분산보다 나을 때
데이터 로딩 중에 PCIe 대역폭을 포화시키는 딥러닝 학습 작업이라면, 레인을 쪼개는 순간 병목에 걸립니다:
- x8 GPU 두 개 (PCIe 3.0): 각자 ~7.88 GB/s. 둘 다 최적 속도보다 느리게 학습.
- x16 GPU 한 개 (PCIe 3.0): ~15.75 GB/s. 최대 처리량으로 학습.
- x8 GPU 두 개 (PCIe 4.0): 각자 ~15.75 GB/s. 보통 충분함.
PCIe 세대가 중요합니다. x8 Gen4 링크는 x16 Gen3와 대역폭이 같아서, 최신 플랫폼에서는 x8/x8 분할이 큰 문제가 안 됩니다.
GPU 간 병렬 처리가 안 되는 단일 학습 작업이라면, x8 GPU 두 개 중 하나에서 돌리는 것보다 x16 GPU 하나에서 돌리는 게 빠를 수 있습니다. 대역폭 제약으로 각 GPU가 제 성능의 60%만 낸다면, 두 GPU를 써도 x16 하나 대비 1.2배 처리량밖에 안 나옵니다. GPU 두 개 값을 냈는데 2배 성능은 못 얻는 거죠. 이게 중요한지는 병렬로 돌릴 일감이 있느냐에 달렸습니다.
대/소 전략 (Big & Small Strategy)
혼합 워크로드라면 비대칭 구성을 고려해보세요:
큰 놈 (1번 슬롯, x16): 학습이나 고연산 작업을 위한 고성능 카드 작은 놈 (2번 슬롯, x8 or x4): 화면 출력, 비디오 인코딩, 가벼운 추론을 위한 저사양 카드 (GTX 1650 등)
주 작업은 풀 대역폭으로 돌리고, 보조 GPU가 데스크탑 화면 합성, 주피터 노트북, 다중 모니터를 담당합니다. 현대 GPU는 데스크탑 화면 정도는 가볍게 처리하지만, 별도 카드를 두면 VRAM 단편화를 막고 큰 GPU의 메모리를 온전히 학습에 쓸 수 있습니다.
치명적 제약: 많은 소비자용 보드는 2번 슬롯에 뭘 꽂는 순간 1번 슬롯을 x8로 떨어뜨립니다. 물론 X570, Z690 이상의 고급 칩셋은 x16 + x4를 지원하기도 합니다. x16 + x8을 동시에 쓰려면 보통 스레드리퍼나 제온 W 같은 HEDT 플랫폼이 필요합니다. 반드시 보드 매뉴얼의 PCIe 토폴로지를 확인하세요.
쪼갤까 말까
레인 분배를 결정하기 전에:
x8/x8이 합리적인 경우:
- 호스트 전송이 적고 VRAM에 쏙 들어가는 모델
- 데이터 로딩이 아니라 GPU 연산이 병목인 추론 서빙
- 동기화가 드문 순수 연산 워크로드
- x8로도 대역폭이 차고 넘치는 PCIe 4.0/5.0 시스템
x16 (혹은 x16 + x4)이 합리적인 경우:
- 호스트-장치 전송이 빈번한 거대 모델 학습
- 시스템 RAM에서 데이터를 계속 끌어와야 하는 고해상도 이미지 처리
- Pinned Memory를 쓰지 않는 전송 (PyTorch DataLoader의
pin_memory설정을 확인하세요. 이거 안 끄면 엄청 느립니다.) - 대역폭에 민감한 워크로드를 돌리는 PCIe 3.0 시스템
nvidia-smi dmon -s pcie나 Nsight Systems 같은 도구로 실제 PCIe 사용률을 측정해보세요. 대역폭 제한에 걸렸다고 단정 짓기 전에 링크 처리량 수치를 먼저 확인해야 합니다.
병목 진단하기: 도구와 기법
I/O 병목을 최적화하기 전에, 그게 진짜 문제인지부터 확인합시다.
GPU 토폴로지
하드웨어 레이아웃을 확인하세요:
nvidia-smi topo -m # GPU 토폴로지와 연결 타입 표시
보게 될 연결 타입들:
NVLink: GPU 간 직접 연결 (최상)PHB: 동일 PCIe 호스트 브리지 (좋음)PIX: PCIe 스위치 연결 (무난함)SYS: CPU 소켓 간 통신 (느림)
GPU 1은 SYS인데 GPU 0은 PHB라면 비대칭 토폴로지입니다. CPU/PCIe 루트 컴플렉스에 더 가까운 GPU(보통 GPU 0)가 시스템 메모리와 스토리지에 더 낮은 레이턴시로 접근하고, 두 번째 GPU는 PCIe 홉(Hop)을 더 거쳐야 합니다.
실시간 PCIe 대역폭 모니터링
학습 중에 PCIe 트래픽을 지켜보세요:
nvidia-smi dmon -s pucvmet # p=전력, u=사용률, c=클럭, v=전압, m=메모리, e=인코더, t=온도
pcie_tx와 pcie_rx 컬럼(MB/s 단위)에 주목하세요.
학습을 돌리면서 다음 현상이 있는지 보세요:
- PCIe rx 대역폭이 PCIe 3.0 x16 기준 ~12-14 GB/s를 찍는다 (이론상 15.75 GB/s지만 프로토콜 오버헤드 때문에 실사용은 80% 정도)
- 대역폭이 꽉 찰 때 GPU 사용률(sm)이 60-80%로 떨어진다
- 비대칭 패턴: GPU 0은 95%로 도는데 GPU 1은 50~90%를 오락가락한다
GPU별 학습 처리량 비교
각 GPU의 초당 샘플 처리수(Samples/second)를 측정하세요. DDP 학습에서는 rank를 이용해 GPU를 구분합니다:
import time
import torch.distributed as dist
from collections import defaultdict
throughput_stats = defaultdict(list)
for batch in dataloader:
start = time.perf_counter()
# ... 학습 단계 ...
elapsed = time.perf_counter() - start
samples_per_sec = batch_size / elapsed
gpu_id = dist.get_rank() # DDP에서 rank는 GPU에 대응됨
throughput_stats[gpu_id].append(samples_per_sec)
GPU 1이 GPU 0보다 지속적으로 20~30% 적게 처리한다면, 데이터 공급 불균형을 찾은 겁니다.
P2P 대역폭 테스트
실제 GPU 간 전송 속도를 측정해보세요:
import torch
size = 1024 * 1024 * 1024 # 1 GB
# 정확한 바이트 크기를 위해 uint8 사용
tensor = torch.empty(size, dtype=torch.uint8, device='cuda:0')
torch.cuda.synchronize()
start = torch.cuda.Event(enable_timing=True)
end = torch.cuda.Event(enable_timing=True)
start.record()
tensor_copy = tensor.to('cuda:1')
end.record()
torch.cuda.synchronize()
elapsed_ms = start.elapsed_time(end)
bandwidth_gbps = (size / (elapsed_ms / 1000)) / 1e9
print(f"GPU 0 -> GPU 1: {bandwidth_gbps:.2f} GB/s")
기대 대역폭:
- NVLink: 링크당 25~50 GB/s (V100, A100 등)
- PCIe 3.0 x16: 단방향 12~14 GB/s
- PCIe 4.0 x16: 단방향 24~28 GB/s
이보다 현저히 낮다면 혼잡이나 설정 오류가 있는 겁니다.
데이터 로딩 구간의 사용률 급락 확인
데이터 로딩 중에 GPU 사용률이 곤두박질친다면 I/O 기근입니다. nvidia-smi dmon에서 sm (스트리밍 멀티프로세서) 사용률을 보세요:
# GPU 0: 98% -> 95% -> 97% -> 96% (안정적)
# GPU 1: 92% -> 65% -> 88% -> 58% (I/O 때마다 떨어짐)
GPU 1은 데이터를 기다리고 있고, GPU 0은 공유 I/O 경로에서 우선권을 쥐고 있는 상황입니다.
적신호 요약
다음 증상이 보이면 I/O 병목입니다 (기준치는 워크로드마다 다름):
- PCIe 대역폭이 지속적으로 포화됨 (이론상 최대치의 90% 이상)
- 학습 중 GPU 1 사용률이 GPU 0보다 15~30% 낮음
- GPU별 처리량에서 20% 이상의 비대칭 발생
- P2P 대역폭 테스트 결과가 예상보다 현저히 낮음
nvidia-smi dmon에서 PCIerx가 찰 때sm사용률이 동반 하락함
병목을 확인했고 극한의 성능이 필요하다면, 더 과감한 해결책이 있습니다.
데스크탑으로 부족할 때: HEDT 솔루션
데스크탑 플랫폼은 3~4 GPU 구성에서 한계를 드러냅니다. 라이젠 9 7950X는 CPU에서 24개의 PCIe 5.0 레인을, 인텔 i9-13900K/14900K는 20개(16 Gen5 + 4 Gen4)를 줍니다. 칩셋이 레인을 더해주긴 하지만, CPU로 가는 공유 업링크를 타야 하니 대역폭 특성이 다릅니다. 대역폭 분할 문제 이전에, 데스크탑 보드는 물리적으로 듀얼 슬롯 GPU 4장을 꽂을 공간이 부족하고, 4번째 슬롯은 보통 M.2나 다른 장치와 레인을 공유합니다.
PCIe 5.0 x8은 PCIe 4.0 x16과 대역폭이 같습니다(양방향 ~32 GB/s). 이론상 24레인 PCIe 5.0 CPU라면 GPU 3장을 PCIe 4.0 풀 속도로 돌릴 수 있습니다. GPU가 PCIe 5.0을 지원한다면 말이죠. 하지만 대부분의 워크스테이션 GPU(A5000, A6000)나 현세대 소비자용 카드는 여전히 PCIe 4.0을 쓰고, 물리적 슬롯 제한도 여전합니다. GPU 4장으로 넘어가려면 확실히 더 많은 레인이 필요합니다.
HEDT(High-End Desktop)와 서버 플랫폼은 CPU에서 직접 뿜어져 나오는 엄청난 수의 PCIe 레인을 제공합니다:
CPU 직결 PCIe 레인 수:
- 메인스트림 데스크탑 (Ryzen 9 7950X): 24레인 PCIe 5.0
- 메인스트림 데스크탑 (Core i9-13900K): 20레인 (16 Gen5 + 4 Gen4)
- 스레드리퍼 프로 5000WX: 128레인 PCIe 4.0
- EPYC 7003/9004: 128레인 PCIe 4.0/5.0 (싱글 소켓)
- 제온-W 3400: 64레인 PCIe 5.0
스레드리퍼 프로나 EPYC를 쓰면 GPU 4장에 풀 x16 대역폭(64레인)을 주고도 NVMe, 네트워크, 확장 카드를 위한 레인이 48개 이상 남습니다. HEDT 플랫폼은 대부분의 슬롯에서 레인 분할을 지원하여 데스크탑 보드에서는 불가능한 유연한 구성을 가능케 합니다.
참고로 EPYC/스레드리퍼 프로의 128레인 전부를 슬롯에 쓸 수 있는 건 아닙니다. 플랫폼이 칩셋 연결, BMC, 온보드 장치용으로 일부를 예약하거든요. 확장 카드용으로는 96~112레인 정도를 기대하면 됩니다.
플랫폼 투자가 가치 있는 이유
하이엔드 GPU 한 장은 200~300만 원(RTX 4090, A5000) 합니다. 4장이면 800~1,000만 원이 넘죠. 스레드리퍼 프로 워크스테이션은 CPU(200~700만 원+), TRX50 메인보드(100~150만 원), 쿼드 채널 ECC 메모리 등을 합치면 동급 데스크탑보다 400~800만 원 더 비쌉니다.
데이터 병렬 ML 학습, 멀티 GPU 렌더링, 병렬 시뮬레이션처럼 여러 GPU를 동시에 100% 굴리는 워크로드라면, GPU 활용률을 극대화하기 위한 플랫폼 투자는 충분히 값어치를 합니다. 하지만 한 번에 하나의 GPU 작업만 하거나 2 GPU 이상으로 확장할 일이 없다면 데스크탑에 머무르세요. HEDT는 CPU 코어나 메모리가 아니라 GPU 활용률이 병목일 때 쓰는 겁니다.
HEDT 플랫폼은 쿼드 채널(스레드리퍼 프로)이나 옥타 채널(EPYC) 메모리 대역폭을 제공하는데, 이는 시스템 RAM과 GPU 메모리 사이에서 거대한 데이터셋을 옮길 때 큰 차이를 만듭니다.
GPU 4장을 넘어서거나 PCIe 이상의 전용 인터커넥트가 필요하다면, NVLink와 GPU 최적화 서버 섀시 같은 데이터센터 기술이 필요해집니다.
데스크탑 그 너머: 데이터센터 기술
우리가 논의한 대역폭 문제는 데이터센터 스케일에서 벽에 부딪힙니다. GPT-4나 Llama 3 405B 같은 최신 LLM은 단일 GPU에 담기엔 너무 커서, 수십 수백 장의 GPU로 분산 학습을 해야 합니다. 이 정도 규모에서는 PCIe나 일반 네트워킹조차 용납할 수 없는 병목이 됩니다.
멀티 GPU 통신 문제
분산 학습 중인 GPU들은 끊임없이 그라디언트를 동기화하고 모델 파라미터를 교환해야 합니다. PCIe는 단방향 이론상 ~32 GB/s(Gen4 x16), 실효 속도 27~28 GB/s를 줍니다. 100 GbE 네트워킹도 ~12.5 GB/s에 불과합니다. 학습 반복마다 수백 기가바이트를 교환해야 하는 워크로드에서 이 속도는 턱없이 부족합니다.
NVLink와 NVSwitch: GPU 네이티브 인터커넥트
NVLink는 CPU를 완전히 우회하는 NVIDIA의 GPU 간 고대역폭 직결 인터커넥트입니다. 최신 세대(NVLink 4.0) 연결 하나는 양방향 450 GB/s 대역폭을 제공합니다. H100 GPU는 18개의 NVLink 레인을 가지고 있어, 8-GPU 셋업에서 보통 7개의 연결을 다른 GPU들과 맺어 GPU당 총 900 GB/s의 대역폭을 확보합니다.
이건 점대점 방식이라 모든 GPU가 서로 직접 연결되진 않습니다. 토폴로지가 중요하죠. NVLink는 연결된 GPU 간 캐시 일관성(Cache-coherent) 메모리 접근을 가능케 하여, 로컬 VRAM보다는 느리지만 시스템 메모리를 거치는 것보다는 훨씬 빠른 NUMA 아키텍처처럼 작동합니다.
NVSwitch는 토폴로지의 한계를 해결합니다. 이건 모든 GPU 간 통신(All-to-All)을 가능케 하는 물리적 스위치 패브릭입니다. NVSwitch 칩 하나는 8개의 NVLink 연결을 가진 18개 포트를 가집니다. NVIDIA DGX H100에서는 4개의 NVSwitch가 논블로킹(Non-blocking) 패브릭을 형성하여, 8개의 GPU가 동시에 다른 어떤 GPU와도 풀 NVLink 속도로 통신할 수 있게 해줍니다.
참고로 AMD의 Infinity Fabric과 인텔의 Xe Link도 비슷한 개념이지만, NVIDIA GPU를 쓴다면 NVLink가 유일한 선택지이며 생태계도 가장 성숙해 있습니다. 파운데이션 모델을 학습한다면 이런 GPU 네이티브 인터커넥트는 선택이 아니라 필수입니다. 대역폭 요구량을 다른 방법으론 맞출 수가 없거든요.
GPUDirect Storage: CPU 병목 제거
NVLink가 GPU 간 통신을 해결했다면, 스토리지에서 GPU로 학습 데이터를 보내는 대역폭 문제는 어떻게 할까요?
전통적인 경로:
스토리지 → RAM → CPU (바운스 버퍼) → GPU
CPU가 스토리지에서 데이터를 시스템 메모리로 복사하고, 그걸 다시 GPU 메모리로 복사합니다. 메모리 대역폭 낭비에, CPU 사이클 소모에, 레이턴시까지 늘어납니다.
**GPUDirect Storage (GDS)**는 이 경로에서 CPU를 제거합니다:
스토리지 → GPU (DMA 경유)

GDS는 PCIe P2P(Peer-to-Peer) 지원을 필요로 하며, NVMe 컨트롤러가 DMA를 사용해 GPU BAR 메모리에 직접 쓸 수 있게 해줍니다. 모든 스토리지 컨트롤러나 시스템 BIOS가 이걸 지원하진 않습니다. 주로 데이터센터급 하드웨어에서 볼 수 있습니다.
장점:
- 더 높은 대역폭: 더 이상 CPU/메모리 처리량에 제한받지 않음
- 더 낮은 레이턴시: 두 번 전송할 걸 한 번에 해결
- CPU 해방: 전처리, 스케줄링 등 다른 학습 파이프라인 작업에 집중 가능
이런 데이터센터 기술들은 데스크탑 시스템과는 정반대 편에 있는 대역폭의 끝판왕들입니다. 비용과 인프라 문제로 대부분의 사용 사례에는 맞지 않지만, 대역폭이 절대적인 우선순위일 때 무엇이 가능한지를 보여줍니다.
결론: 하드웨어와 워크로드의 궁합 맞추기
x86 PCIe 토폴로지는 스펙 시트가 말해주지 않는 멀티 GPU 성능의 핵심을 쥐고 있습니다. CPU가 사용 가능한 레인 수를 정하고, 메인보드가 그걸 어떻게 쪼갤지 결정합니다. 그리고 보통은 단일 GPU 구성에 몰아주는 쪽으로 설계되어 있죠.
구매하기 전에:
메인보드 매뉴얼에서 실제 레인 할당을 확인하세요. “PCIe x16 슬롯 3개"라고 광고하는 보드도 부하가 걸리면 x16/x0/x4나 x8/x8/x4로 작동하는 경우가 허다합니다. GPU당 12GB/s를 밀어 넣어야 한다면 이 숫자들이 중요해집니다.
최적화하기 전에:
진짜 병목을 측정하세요. 학습 중에 nvidia-smi dmon -s pucvmet를 돌려 PCIe 처리량을 보세요. x8 레인에서 GPU 사용률이 90%를 넘긴다면 병목은 I/O가 아닙니다. 파이프라인 다른 곳에 있는 거죠. 레인을 늘려봤자 소용없습니다.
플랫폼의 현실:
데스크탑 CPU(라이젠 5/7, 코어 i5/i7/i9)는 보통 20~24개의 가용 PCIe 레인을 줍니다. GPU 두 개를 x8로 돌리고 NVMe 하나 쓰면 딱 맞습니다. 고대역폭 GPU 3~4장이 필요하다고요? 그게 바로 스레드리퍼, 제온 W, EPYC가 존재하는 이유입니다. 64~128레인을 주지만 가격표도 그만큼 무겁죠.
경제적 최적화:
A6000 4장을 x16으로 돌려야 한다면 300만 원짜리 HEDT 플랫폼이 합리적입니다. 하지만 Stable Diffusion을 2배 빨리 돌리겠다고 그 돈을 쓰는 건 낭비일 수 있습니다. 하드웨어 투자는 워크로드가 벌어다 줄 수익이나 시간 절약과 비례해야 합니다. x8이 x16 성능의 95%를 내준다면, “그 정도면 충분함(Good enough)“이 최적의 선택일 수 있습니다.
진짜 질문은 “GPU 여러 개를 꽂을 수 있냐"가 아니라, “내 워크로드가 그걸 제대로 굴릴 플랫폼을 갖출 만큼 가치 있냐“입니다. PCIe 토폴로지 지식을 충분히 갖추었다면, 이제 정확한 진단을 내릴 수 있을 겁니다. x4 병목에 시달리는 과소 투자나, 400만 원짜리 보드에서 레인을 놀리는 과잉 투자를 피하면서 말이죠.
레인을 확인하고, 병목을 측정하고, 적절한 시스템을 갖추시면 됩니다.