리눅스 서버 GPU 첫 세팅 가이드
— 드라이버부터 PyTorch까지

1. 시작 전 체크

이 가이드는 리눅스 서버에 처음으로 GPU를 세팅하는 사람을 위해 썼습니다. 연구실에 새 서버가 들어왔거나, 클라우드 GPU 인스턴스를 처음 띄운 학생이 대상입니다.

전제 조건

• OS: Ubuntu 22.04 LTS 또는 24.04 LTS (x86_64)
• GPU: NVIDIA GPU 1장 이상 (RTX 4090, A6000, H100 등)
• 권한: sudo 사용 가능한 계정
• 네트워크: 인터넷 연결 (드라이버·패키지 다운로드)

전체 흐름

이 글은 다음 순서로 진행합니다. 중간에 재부팅이 두 번 있습니다.

하드웨어 확인 → OS 정리 → Nouveau 비활성화 → NVIDIA 드라이버 → Docker + Container Toolkit → uv + PyTorch → 모니터링

CUDA Toolkit, 설치하지 않습니다

많은 가이드가 NVIDIA 드라이버 다음 단계로 CUDA Toolkit과 cuDNN을 설치하라고 안내합니다. 이 가이드는 그렇게 하지 않습니다.

이유는 간단합니다. 요즘 워크플로에서는 호스트에 CUDA Toolkit이 필요 없습니다.

• Docker로 학습 환경을 띄우면, CUDA runtime은 컨테이너 이미지 안에 이미 들어 있습니다.
• PyTorch wheel (예: torch+cu124)을 설치하면, CUDA runtime과 cuDNN을 wheel이 자체 번들합니다.

호스트에 필요한 것은 NVIDIA 드라이버 하나입니다. nvcc로 직접 CUDA 커널을 컴파일해야 하는 특수한 경우에만 Toolkit을 따로 설치하세요. 이 글 마지막 부록에서 다룹니다.

소요 시간

처음 해보는 사람 기준 30분~1시간. 재부팅 대기 시간 포함.

2. 하드웨어 확인

드라이버를 설치하기 전에, 서버가 GPU를 물리적으로 인식하고 있는지 먼저 확인합니다. 이 단계를 건너뛰고 드라이버부터 설치하면, 인식 자체가 안 되는 상황에서 한참을 헤맬 수 있습니다.

CPU

lscpu
nproc

lscpu는 모델명·코어 수·아키텍처를 한 번에 보여줍니다. nproc은 사용 가능한 논리 코어 수만 출력합니다. 데이터 로더 num_workers 같은 값을 정할 때 참고합니다.

메모리

free -h
sudo dmidecode -t memory | grep -E "Size|Speed|Type:"

실험 모델이 GPU VRAM에 담기더라도, 데이터 전처리·캐시 때문에 시스템 메모리가 부족하면 OOM이 납니다. VRAM 합계의 2배 이상을 권장합니다. (예: A6000 48GB × 2 = 96GB → 시스템 RAM 192GB 이상)

디스크

lsblk
df -h
sudo nvme list   # NVMe 장착 시

딥러닝 데이터셋·체크포인트는 빠르게 쌓입니다. 최소 1TB NVMe를 권장합니다. SATA SSD는 대용량 데이터셋 학습 시 I/O 병목이 자주 보입니다.

GPU 물리 인식

가장 중요한 명령입니다.

lspci | grep -i nvidia

출력 예시:

01:00.0 VGA compatible controller: NVIDIA Corporation AD102 [GeForce RTX 4090]
01:00.1 Audio device: NVIDIA Corporation Device 22ba

여기서 GPU가 한 줄도 보이지 않는다면, 드라이버 문제가 아니라 다음을 의심해야 합니다.

• BIOS에서 Above 4G Decoding, Resizable BAR 활성화 여부
• PCIe 보조 전원 케이블 (8-pin, 12VHPWR) 결합 상태
• 슬롯 자체가 GPU 인식이 가능한 PCIe x16 슬롯인지

PCIe 링크 속도

sudo lspci -vv -s 01:00.0 | grep -i "LnkSta"

LnkSta: 줄에 Speed 16GT/s, Width x16으로 나오면 PCIe Gen4 x16 정상입니다. Width x8 또는 x4로 잡혀 있으면 슬롯을 잘못 꽂았거나 메인보드 레인 분배 문제입니다. 멀티 GPU 학습 시 통신 병목으로 직결됩니다.

전원 용량

지나치기 쉽지만 중요합니다. GPU TDP 합계 + CPU TDP + 여유 30%를 PSU가 감당해야 합니다. RTX 4090(450W) 2장이면 GPU만 900W, 전체 시스템은 1200W급 PSU가 필요합니다. 부족하면 학습 중 갑자기 서버가 리셋됩니다.

3. OS 기본 세팅

드라이버를 올리기 전에 OS를 깔끔하게 정리합니다. 이 단계는 길지 않지만, 빌드 의존성이 빠지면 다음 섹션에서 드라이버 컴파일이 실패합니다.

패키지 업데이트

sudo apt update
sudo apt upgrade -y

커널이 함께 업그레이드된다면 업그레이드 직후 재부팅하세요. 새 커널 헤더로 드라이버를 빌드해야 다음 단계가 매끄럽게 진행됩니다.

빌드 의존성 설치

sudo apt install -y \
  build-essential dkms \
  linux-headers-$(uname -r) \
  curl git vim ca-certificates gnupg

dkms(Dynamic Kernel Module Support)가 핵심입니다. 커널이 업데이트될 때마다 NVIDIA 모듈을 자동으로 다시 빌드해 줍니다. 이게 없으면 커널 업그레이드 직후 nvidia-smi가 깨집니다.

시간대·로케일

sudo timedatectl set-timezone Asia/Seoul

로그 시간대를 한국 시간으로 맞춰 두면 디버깅이 편합니다.

SSH·방화벽

외부 접속이 필요한 서버라면 키 인증을 켜고 비밀번호 로그인을 끕니다.

# /etc/ssh/sshd_config
PasswordAuthentication no
PubkeyAuthentication yes

sudo systemctl restart ssh
sudo ufw allow OpenSSH
sudo ufw enable

주의. SSH 설정을 바꾼 직후에는 현재 세션을 끊지 말고 새 터미널로 로그인되는지 먼저 확인하세요. 잘못 끊으면 콘솔 접근이 없는 한 복구가 어렵습니다.

swap 확인

swapon --show
free -h

RAM이 충분하다면 swap 없이도 무방하지만, 데이터 전처리 중 일시적으로 RAM이 튀는 경우가 잦습니다. 시스템 RAM의 절반 정도(최대 64GB)를 swap으로 두면 OOM Kill 빈도가 줄어듭니다.

4. 기존 드라이버·Nouveau 정리

NVIDIA 드라이버 설치가 실패하는 가장 흔한 원인은 기존 드라이버나 오픈소스 Nouveau 드라이버가 메모리에 올라가 있는 상태입니다. 새로 설치하기 전에 깨끗이 비웁니다.

현재 상태 확인

lsmod | grep -E "nvidia|nouveau"

아무 출력도 없으면 깨끗한 상태입니다. nouveau 또는 nvidia가 보이면 다음 단계를 진행합니다.

Nouveau 비활성화

Nouveau는 우분투에 기본 포함된 NVIDIA용 오픈소스 드라이버입니다. NVIDIA 공식 드라이버와 동시에 로드될 수 없어서 명시적으로 막아야 합니다.

sudo tee /etc/modprobe.d/blacklist-nouveau.conf <<EOF
blacklist nouveau
options nouveau modeset=0
EOF

sudo update-initramfs -u

update-initramfs를 빼먹으면 재부팅해도 Nouveau가 계속 로드됩니다. 가장 자주 보는 실수입니다.

기존 NVIDIA 드라이버 제거

이전에 설치를 시도했다 실패한 흔적이 있다면 모두 제거합니다.

sudo apt purge "nvidia-*" "libnvidia-*" "cuda-*"
sudo apt autoremove --purge
sudo rm -rf /usr/local/cuda*

재부팅 후 확인

sudo reboot

# 재로그인 후
lsmod | grep -E "nvidia|nouveau"

이번에는 아무 출력도 없어야 정상입니다. 출력이 남아 있으면 blacklist 파일 경로나 update-initramfs 실행 여부를 다시 확인하세요.

5. NVIDIA 드라이버 설치

이제 본 작업입니다. 우분투 표준 저장소를 통한 apt 방식이 가장 안전하고 단순합니다.

권장 버전 조회

ubuntu-drivers devices

출력 중 recommended라고 표시된 버전을 사용합니다. 최신 GPU(예: H100, RTX 50 시리즈)는 표준 저장소 버전이 너무 낮을 수 있습니다. 그 경우에만 NVIDIA의 CUDA repo를 추가합니다.

설치 방법 비교

apt로 설치

sudo apt install -y nvidia-driver-550-server
sudo reboot

버전 번호(550)는 ubuntu-drivers devices가 추천한 값으로 바꿔 사용합니다. -server 접미사를 붙이는 것이 핵심입니다. 헤드리스 서버용으로 빌드되어 GSP firmware·전원 관리가 더 안정적입니다.

설치 검증

nvidia-smi

출력 예시:

+---------------------------------------------------------------------------------------+
| NVIDIA-SMI 550.90.07     Driver Version: 550.90.07     CUDA Version: 12.4         |
|-----------------------------------------+----------------------+----------------------+
| GPU  Name                 Persistence-M | Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp   Perf          Pwr:Usage/Cap |         Memory-Usage | GPU-Util  Compute M. |
|=========================================+======================+======================|
|   0  NVIDIA RTX A6000     Off           | 00000000:01:00.0 Off |                  Off |
| 30%   35C    P8             21W / 300W  |      0MiB / 49140MiB |      0%      Default |
+-----------------------------------------+----------------------+----------------------+

"CUDA Version: 12.4"의 의미. 이 값은 호스트에 CUDA Toolkit이 설치되어 있다는 뜻이 아닙니다. 현재 드라이버가 지원하는 CUDA 최대 버전을 표시할 뿐입니다. PyTorch나 컨테이너의 CUDA가 이 값보다 낮기만 하면 정상 동작합니다.

Secure Boot 이슈

BIOS에서 Secure Boot가 켜진 서버는 추가 절차가 있습니다. 설치 중 MOK(Machine Owner Key) 비밀번호를 묻는 화면이 나타납니다.

1. 임시 비밀번호 입력 (8자리 이상)
2. 재부팅
3. 파란 화면(MOK Manager)에서 Enroll MOK → Continue → 방금 입력한 비밀번호
4. 일반 부팅 → nvidia-smi 동작 확인

이 절차를 놓치면 모듈 서명 검증에 실패해 드라이버가 로드되지 않습니다. 콘솔이 없는 클라우드 서버라면 BIOS에서 Secure Boot를 미리 끄는 편이 안전합니다.

6. Container 환경 (Docker + NVIDIA Container Toolkit)

드라이버까지 설치했으면 절반은 끝났습니다. 이제 학습·추론 환경을 호스트에 직접 깔지 않고, 컨테이너로 격리해서 운영합니다.

왜 컨테이너인가

• 호스트 깨끗하게 유지 — CUDA·cuDNN·Python 버전을 호스트에 설치하지 않습니다. 드라이버만 호스트에 둡니다.
• 사용자별 환경 분리 — 학생 A의 PyTorch 2.1과 학생 B의 PyTorch 2.4가 충돌 없이 공존합니다.
• 재현성 — 같은 이미지를 다른 서버에서 그대로 띄울 수 있습니다.
• 롤백 — 환경이 깨져도 컨테이너만 다시 띄우면 됩니다.

Docker 설치

Docker 공식 설치 스크립트를 사용합니다.

curl -fsSL https://get.docker.com | sudo sh
sudo usermod -aG docker $USER

# 그룹 변경 적용 위해 재로그인 또는
newgrp docker

docker run --rm hello-world

hello-world가 정상 출력되면 Docker 자체는 OK입니다.

NVIDIA Container Toolkit 설치

컨테이너에서 GPU에 접근하려면 NVIDIA가 제공하는 런타임을 추가로 설치해야 합니다.

# GPG 키 등록
curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey \
  | sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg

# Repo 추가
curl -s -L https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list \
  | sed 's#deb https://#deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g' \
  | sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list

# 설치
sudo apt update
sudo apt install -y nvidia-container-toolkit

# Docker 데몬 설정 갱신
sudo nvidia-ctk runtime configure --runtime=docker
sudo systemctl restart docker

GPU 컨테이너 검증

docker run --rm --gpus all \
  nvidia/cuda:12.4.0-base-ubuntu22.04 nvidia-smi

호스트와 동일한 GPU 목록이 출력되면 성공입니다. 컨테이너 안에서 nvidia-smi가 보이는 이유는, NVIDIA Container Toolkit이 호스트 드라이버를 컨테이너 안으로 주입해 주기 때문입니다.

특정 GPU만 노출

다중 GPU 서버에서 컨테이너 하나에 일부 GPU만 할당할 수도 있습니다.

# 0번, 2번 GPU만 노출
docker run --rm --gpus '"device=0,2"' \
  nvidia/cuda:12.4.0-base-ubuntu22.04 nvidia-smi

자주 쓰는 베이스 이미지

7. Python 환경 — uv + PyTorch

호스트나 컨테이너 안에서 Python 환경을 구성할 차례입니다. 이 가이드는 uv 하나만 추천합니다.

왜 uv인가

conda·pyenv·pip·poetry·virtualenv를 따로 깔던 시절은 끝났습니다. uv 하나가 그 모든 역할을 합니다.

• 속도 — Rust로 작성. pip 대비 10~100배 빠름. 큰 의존성(torch)도 수 초 안에 해결
• Python 인터프리터 관리 — pyenv 없이 uv python install 3.11
• 가상환경 자동 관리 — venv 명령 따로 외울 필요 없음
• Lockfile — uv.lock으로 재현성 보장. 다른 서버에서도 동일 의존성
• 단일 바이너리 — Python이 깔려 있지 않아도 설치 가능

conda 환경에 익숙해서 망설인다면, 새 프로젝트부터 uv로 시작해 보세요. 한 번 써보면 conda로 돌아가지 않게 됩니다.

uv 설치

curl -LsSf https://astral.sh/uv/install.sh | sh

# PATH 적용
source $HOME/.local/bin/env

# 또는 새 셸 열기 후
uv --version

Python 인터프리터 설치

uv python install 3.11
uv python list

시스템 Python을 건드리지 않습니다. uv가 자체 디렉터리에 인터프리터를 따로 둡니다.

프로젝트 시작

mkdir my-gpu-project && cd my-gpu-project
uv init --python 3.11

다음과 같은 파일이 생성됩니다.

my-gpu-project/
├── .python-version
├── README.md
├── main.py
└── pyproject.toml

PyTorch (CUDA) 추가

PyTorch는 일반 PyPI가 아닌 NVIDIA 전용 인덱스에서 가져와야 CUDA wheel이 설치됩니다.

uv add torch torchvision \
  --index https://download.pytorch.org/whl/cu124

cu124는 CUDA 12.4용 wheel을 의미합니다. nvidia-smi가 표시한 CUDA 버전 이하 중 가장 가까운 wheel을 고릅니다.

GPU 인식 검증

uv run python -c "
import torch
print('CUDA available:', torch.cuda.is_available())
print('Device count :', torch.cuda.device_count())
print('Device name  :', torch.cuda.get_device_name(0))
print('Torch version:', torch.__version__)
"

출력 예시:

CUDA available: True
Device count : 2
Device name  : NVIDIA RTX A6000
Torch version: 2.4.0+cu124

True가 나오면 끝났습니다. 학습 시작해도 됩니다.

일상적으로 쓰는 명령

컨테이너 안에서 uv 쓰기

Dockerfile에서도 그대로 동작합니다.

FROM nvidia/cuda:12.4.0-base-ubuntu22.04

RUN apt-get update && apt-get install -y curl ca-certificates
ADD https://astral.sh/uv/install.sh /tmp/uv-install.sh
RUN sh /tmp/uv-install.sh && \
    ln -s /root/.local/bin/uv /usr/local/bin/uv

WORKDIR /app
COPY pyproject.toml uv.lock ./
RUN uv sync --frozen

COPY . .
CMD ["uv", "run", "python", "train.py"]

8. 모니터링·운영

설치가 끝났다면 이제 운영입니다. GPU가 어떻게 쓰이는지 보지 못하면 활용률을 끌어올릴 수도, 문제를 빨리 잡을 수도 없습니다.

실시간 상태 확인

# 1초 간격 갱신
watch -n1 nvidia-smi

# 한 줄 요약
nvidia-smi --query-gpu=index,name,utilization.gpu,memory.used,memory.total,temperature.gpu \
  --format=csv

TUI 대시보드 — nvitop

기본 nvidia-smi보다 한참 보기 좋습니다. 프로세스별 GPU·VRAM·전력까지 한눈에.

uv tool install nvitop
nvitop

htop이 CPU용이라면, nvitop은 GPU용입니다. 작업 종료(kill)도 TUI 안에서 바로 가능합니다.

Persistence Mode

드라이버는 GPU에 첫 작업이 들어올 때 초기화됩니다. 짧은 추론 작업을 자주 띄우면 매번 수 초의 콜드스타트가 발생합니다. Persistence Mode를 켜면 드라이버가 항상 메모리에 남아 이 지연이 사라집니다.

sudo nvidia-smi -pm 1

재부팅 후에도 유지하려면 nvidia-persistenced 서비스를 활성화합니다.

전력 상한 조정

여름철 발열·소음이 심하다면 전력 상한을 낮출 수 있습니다. 학습 속도는 약간 떨어지지만 안정성·전기료가 좋아집니다.

# RTX 4090 기본 450W → 350W로 제한
sudo nvidia-smi -pl 350

로그 확인

dmesg | grep -i nvidia
journalctl -k --since "1 hour ago" | grep -i nvrm

학습 도중 GPU가 갑자기 사라지거나 ECC 에러가 나면 여기에 흔적이 남습니다. Xid로 시작하는 코드가 가장 중요합니다 (예: Xid 79: GPU has fallen off the bus).

장기 모니터링

여러 사용자가 함께 쓰는 환경이라면 일회성 명령으로는 부족합니다. Prometheus + DCGM Exporter + Grafana 조합이 사실상 표준입니다.

• DCGM Exporter — NVIDIA 공식 메트릭 노출 도구
• Prometheus가 메트릭 수집, Grafana로 시각화
• 임계치 알람으로 ECC·발열·점유율 추적

9. 멀티 유저 환경

혼자 쓰는 워크스테이션이라면 여기까지만 해도 충분합니다. 그러나 연구실 서버는 보통 대학원생 5~10명이 공유합니다. 이때부터 진짜 문제가 시작됩니다.

전형적인 시나리오

• 학생 A가 GPU 0번을 쓰는데, B가 모르고 같은 GPU에 작업을 띄움 → OOM
• C가 CUDA 11.8용 프로젝트를 돌리려는데 D가 호스트에 12.4를 깔아둠 → 환경 충돌
• 졸업한 선배가 띄워둔 좀비 프로세스가 한 달째 GPU를 점유 중
• 실수로 누군가 rm -rf를 잘못 쳐서 다른 사람 데이터까지 삭제

리눅스 표준 도구로 어디까지 가능한가

• 사용자 분리 — 각자 계정, video·docker 그룹 부여
• 홈 디렉터리 격리 — /home/<user>, 디스크 quota
• 컨테이너 격리 — 각자 자기 컨테이너에서 학습. --gpus '"device=N"'으로 GPU 지정
• MIG (A100/H100) — GPU를 물리적으로 7조각까지 분할. 프로덕션 추론용
• MPS — 동일 컨텍스트를 여러 프로세스가 공유

한계

리눅스 도구만으로 다음을 자동화하기는 어렵습니다.

• "누가 어느 GPU를 언제까지 쓰는가" 예약·할당
• 학생 추가/제거를 셀프서비스로
• GPU 사용량 통계·비용 분배
• 유휴 GPU 자동 회수, 좀비 프로세스 정리
• 웹 IDE(JupyterLab, VS Code) 즉시 발급

이 시점부터는 별도 관리 레이어가 필요합니다. SLURM 또는 웹 기반 플랫폼이 그 역할을 합니다. 자세한 비교는 SLURM vs 웹 기반 GPU 관리 글을 참고하세요.

10. 트러블슈팅

"NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver"

원인: 커널 업데이트 후 DKMS가 새 커널용 모듈을 다시 빌드하지 못한 상태. 가장 흔한 케이스입니다.

해결:

sudo dkms status
sudo dkms autoinstall
sudo reboot

여전히 실패하면 헤더 패키지 누락을 의심합니다. sudo apt install linux-headers-$(uname -r)로 다시 설치 후 dkms autoinstall.

"No devices were found"

원인: 드라이버 문제가 아닐 가능성이 높습니다. GPU 자체가 PCIe 버스에 인식되지 않은 상태.

해결: lspci | grep -i nvidia가 비어 있다면 §2로 돌아가 BIOS(Above 4G Decoding, Resizable BAR)·보조 전원 케이블·슬롯을 점검하세요.

"CUDA driver version is insufficient for CUDA runtime version"

원인: 드라이버 버전이 PyTorch wheel·컨테이너 이미지가 요구하는 CUDA 버전보다 낮음.

해결: 둘 중 하나를 선택합니다.

• 드라이버를 최신 메이저로 업그레이드
• 더 낮은 CUDA wheel 사용 — 예: --index https://download.pytorch.org/whl/cu118

Secure Boot로 모듈 로드 실패

원인: Secure Boot가 켜진 상태에서 MOK 서명 등록을 마치지 않음. dmesg에 module verification failed 로그.

해결:

• §5의 MOK 등록 절차를 완료 (재부팅 후 파란 화면 → Enroll MOK)
• 또는 BIOS에서 Secure Boot OFF

Nouveau가 다시 살아남

원인: blacklist 파일을 /etc/modprobe.d/가 아닌 다른 곳에 두었거나, update-initramfs -u를 빼먹어 initramfs에 설정이 반영되지 않음.

해결: §4 절차를 처음부터 다시 진행. 특히 update-initramfs -u를 빼먹지 마세요.

주요 Xid 에러 코드

11. 다음 단계 — 클러스터로 가는 길

여기까지 따라왔다면 GPU 서버 한 대를 운영할 수 있습니다. 하지만 연구실은 곧 다음 문제와 마주합니다.

• 서버 1대 → 2대 → 4대로 늘어남
• 학생마다 SSH 키, 환경 설정, 실행 스크립트가 다 다름
• "누가 GPU 쓰고 있어요?"가 단톡방에 매일 올라옴
• 새 학생 온보딩에 며칠씩 걸림

해결 옵션은 크게 셋입니다.

1. SLURM — HPC 표준 스케줄러. 무료지만 운영 인력이 필요. 졸업 리스크.
2. Kubernetes + GPU Operator — 컨테이너 네이티브. 직접 운영은 부담이 큼.
3. 웹 기반 플랫폼 (Ocean 등) — 사용자·팀·할당량·이미지·웹 IDE를 한 번에 관리. 연구실에 맞춰 설계.

각 옵션의 장단은 SLURM vs 웹 기반 GPU 관리와 GPU 관리 솔루션 비교에 자세히 정리되어 있습니다.

자주 묻는 질문 (FAQ)

Q. CUDA Toolkit과 cuDNN은 정말 안 깔아도 되나요?

대부분의 경우 그렇습니다. PyTorch·TensorFlow wheel과 NVIDIA 공식 컨테이너 이미지가 CUDA runtime과 cuDNN을 자체 포함합니다. 호스트에 필요한 것은 드라이버 하나입니다. nvcc로 직접 CUDA 커널을 컴파일해야 하는 경우에만 Toolkit을 별도 설치하세요.

Q. uv 대신 conda를 써도 되나요?

됩니다. 다만 conda는 환경 해석이 느리고, 비파이썬 의존성을 함께 관리하는 강점이 GPU 워크플로에서는 잘 활용되지 않습니다. PyTorch 공식 빌드도 wheel을 우선합니다. 새 프로젝트라면 uv가 더 빠르고 단순합니다.

Q. PyTorch가 CUDA를 인식하지 못합니다.

다음 순서로 점검하세요. (1) 호스트에서 nvidia-smi 정상 — 드라이버 OK. (2) uv pip list | grep torch가 +cu124 같은 접미사가 붙은 빌드인지 — 일반 PyPI에서 받은 CPU 빌드일 수 있음. (3) 드라이버가 wheel의 CUDA 버전을 지원하는지.

Q. Docker 안에서도 uv를 써야 하나요?

강력 추천합니다. uv.lock이 있으면 어떤 호스트·이미지에서도 동일한 의존성이 설치됩니다. uv sync --frozen으로 lockfile만 신뢰하는 모드로 빌드하세요.

Q. 여러 CUDA 버전을 동시에 써야 합니다.

호스트에 여러 Toolkit을 깔지 마세요. 프로젝트별로 컨테이너 이미지를 다르게 쓰거나, PyTorch wheel의 CUDA 버전을 다르게 잡으면 됩니다. 호스트 드라이버는 가장 높은 CUDA 요구를 만족하는 한 버전이면 충분합니다.