GPU·PCIe 토폴로지 읽는 법: nvidia-smi의 SYS·PIX와 NUMA를 해석하기
GPU가 느릴 때는 설정을 바꾸기 전에 nvidia-smi topo -m으로 GPU·NIC 사이의 경로를 보고, lspci의 PCI 트리와 numactl의 NUMA 노드 정보를 함께 확인하세요. SYS·PIX·NV#는 연결 경로의 종류이지 실측 GB/s나 성능 점수가 아닙니다. 토폴로지는 병목의 후보를 좁히는 지도이고, 병목을 확정하는 벤치마크는 아닙니다.
30초 확인: 증상별로 무엇부터 볼까?
- GPU끼리 통신할 때만 느리다 → 해당 GPU 쌍의
topo -m경로를 확인합니다. SYS라고 즉시 불량으로 판정하지 않습니다. - GPU로 데이터를 넣을 때 느리다 → GPU의 CPU·NUMA 친화도와 데이터 준비 프로세스의 위치를 비교할 단서를 모읍니다. 아직 CPU 바인딩은 바꾸지 않습니다.
- VM·컨테이너에서 장치가 덜 보인다 → 현재 화면이 호스트 전체가 아닌 게스트·컨테이너의 관측 범위인지 확인합니다. 권한 확대나 보안 설정 해제부터 하지 않습니다.
적용 범위: NVIDIA 드라이버와 관련 도구가 준비된 Linux 서버의 읽기 전용 점검입니다. 문서 확인일은 2026-10-24 KST입니다. 실제 장비의 드라이버·도구 버전과 지원 옵션은 현장에서 확인해야 합니다. 이 글의 Linux 하드웨어 명령은 미실행이며, 아래 행렬과 도식은 설명용 가상 예시입니다.
목차와 한 줄 정의
- 토폴로지·PCIe·NUMA: 장치가 어디에 연결돼 있고 어느 CPU·메모리 노드와 가까운지 읽는 개념입니다.
- 읽기 전용 명령: 버전, 연결 행렬, PCI 트리, 노드 목록을 구분해 봅니다.
- SYS·PIX 행렬 해석: 경로 기호와 친화도를 별도로 읽습니다.
- 서로 대조하기: 장치 주소와 관측 환경을 맞춥니다.
- VM·컨테이너와 실패 조건: 보이지 않는 정보를 없는 하드웨어로 단정하지 않습니다.
- 요약·비교와 Appendix: 실행 여부와 다음 측정의 경계를 확인합니다.
1. GPU 번호보다 연결 경로를 먼저 읽는다
토폴로지(topology)는 GPU, 네트워크 카드(NIC), CPU, PCIe 브리지·스위치의 연결 구조입니다. GPU0과 GPU1이라는 번호가 붙었다고 같은 스위치 아래에 있거나 서로 가까운 것은 아닙니다. NVIDIA 문서는 GPU 열거 순서가 재부팅 사이에 유지된다고 보장하지 않으므로, 서로 다른 기록을 대조할 때는 번호만 믿지 말고 PCI 버스 주소 같은 식별 기준도 맞춰야 합니다.
PCIe는 장치 입출력 연결이고, NUMA는 프로세서가 접근하는 메모리의 위치에 따라 접근 특성이 달라지는 구조입니다. NUMA 노드 번호 0·1은 용량이나 속도의 단위가 아닌 식별자입니다. CPU Affinity의 0–15도 GHz가 아니라 논리 CPU 번호 범위입니다. 친화도 정보만으로 현재 스레드가 그 CPU에서 실행 중이거나 메모리가 그 노드에 배치됐다고 판단하면 안 됩니다. NVIDIA SMI 공식 문서
2. 먼저 조회만 한다: 네 가지 명령 묶음
아래는 Linux 셸에서 직접 실행할 때 사용할 문서 기반 예제입니다. 이 글을 작성한 Windows x64 환경에서는 PATH 검색으로 nvidia-smi·lspci·numactl 실행 파일을 찾지 못했습니다. 따라서 이 명령들의 성공 출력이나 GPU 드라이버 버전을 검증했다고 주장하지 않습니다. PATH에서 찾지 못했다는 사실 자체가 GPU가 없다는 증거도 아닙니다.
# 1) 환경과 도구 버전: 출력은 본인 장비에서 기록
uname -r
nvidia-smi --version
lspci --version
numactl --version
# 2) 설치된 nvidia-smi가 지원하는 topo 옵션 확인
nvidia-smi topo -h
# 3) GPU/NIC 경로와 친화도; NVLink를 제외한 PCI 경로와 비교
nvidia-smi topo -m
nvidia-smi topo -mp
# 4) PCI 장치 식별, 연결 트리, 사용 가능한 NUMA 노드
lspci -Dnn
lspci -t
numactl --hardwaretopo -m은 GPU·NIC 연결 및 GPU의 CPU·메모리 친화도를 보여줍니다. topo -mp는 NVLink 연결을 제외한 PCI 연결 행렬이므로, 두 결과가 다른 이유를 해석할 때 유용합니다. 장치·OS·드라이버별 지원 차이가 있으므로 로컬 도움말에 없는 옵션이나 Not Supported 결과를 억지로 우회하지 마세요.
lspci -Dnn은 도메인을 포함한 PCI 주소, 장치 이름과 숫자 ID를 함께 확인하는 용도입니다. lspci -t는 버스·브리지·장치의 연결 트리를 보여줍니다. 둘 다 전송 속도 테스트가 아닙니다. numactl --hardware는 시스템에서 사용 가능한 NUMA 노드 정보를 보는 옵션이며, --membind 같은 배치 정책 변경과는 다릅니다. pciutils 설명서, numactl 설명서
3. SYS·PIX·NV#를 속도 순위표로 읽지 않는다
| 기호 | 경로를 읽는 뜻 |
|---|---|
| X | 장치 자기 자신입니다. |
| PIX / PXB | 단일 / 여러 PCIe 스위치를 지나는 경로입니다. 호스트 브리지를 통과하지 않는 PXB의 조건도 구분합니다. |
| PHB / NODE | PCIe 호스트 브리지를 지나거나, 같은 NUMA 노드 안의 호스트 브리지 사이 연결을 지납니다. |
| SYS | PCIe뿐 아니라 NUMA 노드 사이의 SMP 인터커넥트도 지나는 경로입니다. |
| NV# | #개의 NVLink를 묶은 연결을 뜻합니다. #는 GB/s나 전체 서버 GPU 개수가 아닙니다. |
NVIDIA 문서의 topo -m 범례를 요약한 표입니다. 제품 세대별 링크 특성, 링크 공유, 실제 전송 방식과 부하가 다르므로 PIX는 항상 빠르고 SYS는 항상 느리다는 식의 절대 순위를 만들 수 없습니다. NV4가 보인다는 사실만으로 애플리케이션이 그 경로를 쓰거나 GPU 메모리가 자동으로 하나로 합쳐진다고도 결론 내리지 않습니다.
다음 행렬은 설명을 위해 만든 가상 예시이며 실제 nvidia-smi 출력이 아닙니다. 장치·열 일부를 줄였습니다. 가상의 GPU0은 NUMA 0, GPU1은 NUMA 1 쪽이며, NIC0은 GPU0과 단일 스위치 경로를 공유한다고 가정합니다.
# 설명용 가상 행렬 · 측정값 아님
GPU0 GPU1 NIC0 CPU Affinity NUMA Affinity
GPU0 X SYS PIX 0-15 0
GPU1 SYS X SYS 16-31 1
NIC0 PIX SYS X
가상 연결 지도 — 실행 결과 아님
NUMA 노드 0
논리 CPU 0–15 · 로컬 메모리
PCIe 스위치 아래 GPU0 ↔ NIC0
행렬에서 GPU0–NIC0: PIX
↕ 노드 사이 인터커넥트를 지나는 경로
NUMA 노드 1
논리 CPU 16–31 · 로컬 메모리
이 노드 쪽 PCIe에 연결된 GPU1
행렬에서 GPU0–GPU1: SYS
여기서 확실히 읽을 수 있는 것은 GPU0–GPU1과 GPU0–NIC0의 경로 분류가 다르다는 점입니다. 아직 알 수 없는 것은 몇 GB/s가 나오는지, 현재 통신량이 얼마인지, 지연의 원인이 그 경로인지입니다. NUMA 0이 표시돼도 데이터 로더의 실행 CPU와 실제 메모리 배치는 별도 관측 대상입니다.
4. 재현 기록은 장치·환경·구간을 맞춰 남긴다
- 환경을 먼저 적습니다. 호스트인지 VM인지 컨테이너인지, Linux 커널과 NVIDIA 드라이버·도구 버전을 기록합니다. 같은 모델의 GPU여도 관측 범위가 다르면 결과를 직접 비교하기 어렵습니다.
- GPU와 PCI 주소를 대조합니다. nvidia-smi 기본 화면의 Bus-Id와
lspci -Dnn의 해당 장치 주소를 맞춥니다. 도메인 등의 0 채움 형식이 다를 수 있습니다. GPU 번호와 PCI 버스 번호를 같은 번호로 취급하지 않습니다. - 문제가 생기는 장치 쌍만 골라 읽습니다. GPU 간 작업이면 GPU–GPU, 네트워크 데이터 이동이면 GPU–NIC 경로와 CPU·NUMA 친화도를 확인합니다. NIC가 행렬에 보인다고 애플리케이션의 RDMA 동작까지 검증된 것은 아닙니다.
- 그다음 측정 질문을 만듭니다. 같은 입력·동시성·전송 크기에서 시간이 어디에 쓰이는지 확인할 계획을 세웁니다. 이 글은 성능 측정이나 NUMA 바인딩 변경을 수행하지 않습니다.
공유할 때는 조직명·호스트명·GPU UUID·일련번호·네트워크 주소 등 식별 정보를 제거하세요. 비교에 필요한 장치 대응표는 내부에서 일관되게 익명화하면 됩니다. 전체 시스템 덤프를 공개 게시판에 그대로 올릴 필요는 없습니다.
5. VM에서 안 보인다고 연결이 없다고 단정하지 않는다
NCCL 2.32.3 문서는 GPU와 네트워크 카드의 PCI 토폴로지 탐색에 /sys를 사용하며, VM·컨테이너가 가상 PCI 토폴로지를 노출하면 성능에 영향을 줄 수 있다고 설명합니다. 게스트에서 보이는 트리를 호스트의 전체 물리 배선도라고 가정하지 마세요. 필요한 호스트 측 정보는 운영 담당자에게 읽기 전용으로 확인을 요청합니다. NVIDIA NCCL GPU 문제 해결 문서
| 관측 결과 | 안전한 다음 행동 |
|---|---|
| command not found | 현재 PATH·컨테이너 이미지·관리되는 도구 위치를 확인합니다. 드라이버부터 새로 설치하지 않습니다. |
| N/A / Not Supported | 모델·드라이버·OS 지원과 관측 범위를 기록합니다. 0이나 미연결로 바꾸어 해석하지 않습니다. |
| NIC 누락 / access denied | 권한 때문에 일부 sysfs 정보가 제한될 수 있습니다. 제한 자체를 기록하고 관리자에게 조회를 요청합니다. |
| SYS가 보임 | 장치 쌍과 작업의 실제 데이터 이동을 대조할 후보로 남깁니다. 설정 오류나 확정 병목으로 단정하지 않습니다. |
하지 않는 것: 진단을 위해 ACS·IOMMU를 끄거나, 컨테이너에 광범위한 권한을 주거나, 드라이버·BIOS·CPU 바인딩을 변경하지 않습니다. 읽기 명령이라도 모든 옵션이 같은 위험도를 갖지는 않습니다. pciutils 설명서는 일부 장치가 전체 설정 공간 읽기에서 문제를 일으킬 수 있다고 경고하므로, 이 입문 절차에는 lspci -xxx·-xxxx 덤프를 넣지 않았습니다.
6. 요약: 지도 → 관측 질문 → 별도 성능 측정
topo -m은 경로와 친화도, lspci는 PCI 장치·트리, numactl --hardware는 NUMA 노드 정보를 보는 데 씁니다. 세 가지를 맞춰 보면 무엇을 측정해야 할지는 명확해지지만, 병목의 원인이나 처리량이 자동으로 확정되지는 않습니다.
GPU 메모리 사용량 문제와 연결 경로 문제도 구분해야 합니다. 메모리가 부족하다면 같은 언어의 실습 글인 CUDA allocated·reserved·peak 로그를 읽는 법에서 사용량 기준 구간부터 확인할 수 있습니다. 그 수치만으로 PCIe 통신 병목을 판단할 수는 없습니다.
Appendix. 실제로 확인한 것과 아직 확인하지 않은 것
- 실제 확인: Windows x64, Node.js 24.14.1 환경에서 where.exe로 세 실행 파일의 PATH 검색을 수행했습니다. 세 검색 모두 종료 코드 1이었으며 실행 파일 경로를 찾지 못했습니다.
- 문서 검증: NVIDIA SMI 옵션·범례, NCCL 2.32.3의 /sys·가상화 주의, pciutils·numactl upstream master 설명서를 2026-10-24에 확인했습니다. master 문서는 고정 릴리스의 실행 보증이 아닙니다.
- 미실행: Linux 명령 묶음, GPU·NIC 행렬 수집, P2P·PCIe·NUMA 성능 측정입니다. 가상 행렬·자체 도식은 실제 로그가 아닙니다.
- 실패·중단 조건: 명령 미설치, 지원되지 않는 옵션, 권한 제한, 가상화에 따른 정보 누락은 미확인으로 남깁니다. 해당 정보를 얻으려고 운영·보안 설정을 바꾸지 않습니다.
출처와 확인 기준
- NVIDIA System Management Interface — topo -m/-mp, 범례, 버전·장치 식별과 지원 제한.
- pciutils 공식 저장소의 lspci 설명서 — 트리·도메인·숫자 ID와 설정 공간 덤프 주의.
- numactl 공식 저장소의 설명서 — --hardware 조회와 정책 설정의 구분.
- NCCL 2.32.3 GPU troubleshooting — 토폴로지 탐색, VM·컨테이너 관측 범위.
작성·확인: 2026-10-24 KST. 도구 출력 형식은 버전에 따라 달라질 수 있습니다. 이 글은 읽기 전용 진단 입문이며, 실제 장비에서 실행한 벤치마크나 성능 개선 보장이 아닙니다.
댓글
댓글 쓰기
안녕하세요 :)