제0부 개관

0.3 학습 환경 준비

이 장은 이 책 전체 실습이 가정하는 공통 전제 환경을 세운다. 이후 모든 장(2.1 첫 CUDA 커널부터 9.14 Isaac Lab까지)은 환경 셋업을 반복하지 않고 이 장과 부록 A.1를 참조한다. 한 번 제대로 세워 두면 책 끝까지 재사용한다.

0.3.1 이 장에서 배우는 것 / 선수 지식

학습 목표 — 이 장을 끝내면 다음을 할 수 있다.

NVIDIA 드라이버 ↔ CUDA Toolkit ↔ 딥러닝 프레임워크의 버전 호환 관계를 읽고, 자신이 쓸 조합이 맞물리는지 버전 매트릭스로 확인한다.
호스트에 무엇을 설치하고 무엇을 컨테이너에 맡길지 결정한다 — 이 책이 권하는 컨테이너 우선(container-first) 접근의 근거를 설명한다.
nvidia-smi · deviceQuery · 간단 텐서 연산으로 환경이 실제로 동작하는지 검증한다.
로컬 GPU가 없을 때 클라우드·Colab로 대체하고, 자율주행·로보틱스 실습용 Jetson devkit의 위치를 안다.
드라이버·CUDA 미스매치, 컨테이너 vs 호스트 혼동 같은 흔한 함정을 진단한다.

선수 지식 — 리눅스 CLI·패키지 관리·docker의 기초, 그리고 0.1·0.2(풀스택 전략·학습 지도). GPU·컨테이너 개념 자체는 BK-02 전제대로 설명하지 않는다. 더 깊은 셋업(에어갭 설치, 멀티노드, 특정 배포판 패키지 핀 고정 등)은 부록 A.1로 미룬다.

정직성(S-5): 이 장의 버전 숫자·드라이버 분기·이미지 태그는 모두 시점 의존이다. 본문은 "확인 방법"과 "구조"를 가르친다. 구체 버전을 외우지 말고, 항상 그 시점의 공식 CUDA Toolkit 릴리스 노트·프레임워크 지원 매트릭스·NGC 카탈로그로 대조하라.

0.3.2 개념과 동기(왜)

0.3.2.1 GPU 스택은 "층층이 맞물린 버전"이다

CPU만 쓰는 개발에서는 "리눅스에 파이썬 설치하고 패키지 받으면 끝"이지만, GPU 가속 스택은 커널 모듈 ~ 사용자공간 런타임 ~ 라이브러리 ~ 프레임워크가 한 줄로 맞물린다. 한 층의 버전이 어긋나면 빌드는 되는데 런타임에 죽거나, 조용히 CPU로 떨어진다(silent fallback).

핵심 비대칭: 드라이버는 호스트에 단 하나, 그러나 CUDA Toolkit·라이브러리·프레임워크는 프로젝트마다 다른 버전을 쓰고 싶다. 이 비대칭이 컨테이너 우선 전략의 출발점이다(0.3.4).

0.3.2.2 두 개의 핵심 호환 규칙

GPU 환경 디버깅의 90%는 아래 두 규칙으로 설명된다.

드라이버 ≥ Toolkit 요구치(상향 호환). CUDA에는 최소 드라이버 버전 규칙이 있다. CUDA 12.x를 쓰려면 드라이버가 그 12.x가 요구하는 하한 이상이어야 한다. 드라이버는 앞으로 호환: 새 드라이버는 옛 CUDA 앱을 실행한다(반대는 보장 안 됨). 그래서 호스트 드라이버는 충분히 최신으로, CUDA Toolkit은 프로젝트가 정한 버전으로 두는 것이 안전하다.
- 보강: CUDA Forward Compatibility / Compatibility 패키지로 "옛 드라이버 + 새 CUDA"를 데이터센터 GPU 한정으로 푸는 경로가 있으나 제약이 많다 — 일반 학습 환경에서는 "드라이버를 업그레이드한다"가 정공법이다(상세 A.1).
Compute Capability(sm_XX)가 맞아야 한다. GPU 세대마다 sm_70(Volta)·sm_80(Ampere)·sm_90(Hopper)·sm_100(Blackwell, 명칭·번호 확인 필요) 식 아키텍처 번호가 있다. 프레임워크·커널이 내 GPU의 CC를 위해 빌드(또는 PTX JIT)됐어야 한다. 너무 새 GPU + 너무 옛 프레임워크면 "no kernel image is available for execution on the device"가 뜬다.

위 버전 숫자·세대 매핑은 시점 의존, 확인 필요(S-5). 정확한 값은 그 시점 공식 문서로 대조하라. Compute Capability의 의미는 1.1 이후 아키텍처 장에서 더 다룬다.

0.3.3 메커니즘 — 버전 호환 매트릭스 읽는 법

"무엇을 설치할까"가 아니라 "어디를 봐서 결정하는가"를 익힌다. 출처가 곧 메커니즘이다.

묻는 것	보는 곳(출처)	결정하는 것
이 CUDA Toolkit이 요구하는 최소 드라이버는?	CUDA Toolkit 릴리스 노트(버전별 표)	호스트 드라이버 하한
내 프레임워크 버전이 지원하는 CUDA는?	프레임워크 설치 가이드·지원 매트릭스(PyTorch/TF/JAX)	프레임워크 빌드의 CUDA 메이저
이 cuDNN이 어떤 CUDA를 받쳐주나?	cuDNN Support Matrix	라이브러리 짝
내 GPU의 Compute Capability는?	CUDA GPUs 표 또는 `deviceQuery` 출력	빌드 타깃 `sm_XX`
사전 검증된 조합 전체를 쓰고 싶다	NGC 컨테이너 이미지(이미지가 조합을 봉인)	위 전부를 한 번에

읽는 순서(권장):

"확인 필요" 라벨의 실제 운용: 위 표의 셀에 들어갈 구체 숫자는 적지 않는다. 시점마다 달라지기 때문이다. 대신 "어느 문서의 어느 표를 본다"를 기억한다. 이것이 S-5 정직성을 실습으로 옮긴 것이다.

0.3.3.1 무엇을 호스트에, 무엇을 컨테이너에

계층	어디에 두나	이유
커널 드라이버 + `libcuda.so`	호스트(단 한 벌)	하드웨어와 직접 대화, 커널 모듈은 컨테이너화 불가
NVIDIA Container Toolkit	호스트	컨테이너에 GPU·드라이버를 주입하는 런타임 훅
CUDA Toolkit·cuDNN·프레임워크	컨테이너 안	프로젝트마다 다른 버전을 격리·재현

그림으로:

이 그림이 이 장의 한 줄 요약이다: 드라이버는 호스트에 한 벌, 나머지는 컨테이너로 교체한다.

0.3.4 워크스루

아래는 우분투 계열 + Docker 기준의 표준 경로다. 명령은 복붙 가능하되, 버전 토큰·이미지 태그는 그 시점 값으로 바꾼다(아래에서 <...>로 표기). 출력 예시는 모두 환경 의존 개략값이다.

0.3.4.1 단계 0 — GPU가 보이는지(드라이버 이전)

lspci | grep -i nvidia
# 예상(개략): "... NVIDIA Corporation ... [GPU 명]" 한 줄 이상.
# 아무것도 안 나오면: PCIe 인식/전원/하드웨어 문제 — 드라이버 이전 단계.

0.3.4.2 단계 1 — 드라이버 설치·확인

드라이버는 (a) 배포판 패키지, (b) NVIDIA .run 설치기, (c) 데이터센터 드라이버 등 경로가 있다(상세 A.1). 설치 후 단 하나의 진실은 nvidia-smi다.

nvidia-smi

예상 출력(개략 — 값은 환경마다 다름):

+-----------------------------------------------------------------------------+
| NVIDIA-SMI <드라이버버전>      Driver Version: <드라이버버전>  CUDA Version: <X.Y> |
|-------------------------------+----------------------+----------------------+
| GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
|   0  <GPU 이름>          Off  | 00000000:..:00.0  Off |                  N/A |
| 30%   38C    P8    15W / <상한>|   100MiB / <메모리>   |      0%      Default |
+-------------------------------+----------------------+----------------------+
| Processes:  ... (지금은 비어 있을 수 있음)                                       |
+-----------------------------------------------------------------------------+

읽는 법(중요):

우상단 CUDA Version: X.Y 는 "이 드라이버가 받쳐줄 수 있는 최대 CUDA"다 — 설치된 Toolkit 버전이 아니다. 이 혼동이 초보 디버깅 1순위 함정이다(0.3.7).
이 한 표가 나오면 드라이버·커널 모듈·libcuda 경로가 동작한다는 강한 신호다.

0.3.4.3 단계 2 — NVIDIA Container Toolkit 설치·컨테이너에서 GPU 보기

이 책은 CUDA Toolkit을 호스트에 직접 까는 대신 컨테이너로 쓰길 권한다(0.3.6). 그 다리가 NVIDIA Container Toolkit이다.

# 설치(저장소 등록 → 패키지 설치 → 런타임 구성)는 시점별 공식 문서를 따른다(상세 A.1).
# 설치·구성 후, GPU가 컨테이너 안에서 보이는지 단 한 줄로 검증:
docker run --rm --gpus all <CUDA 베이스 이미지: 예 nvidia/cuda:<X.Y>-base-ubuntu<NN.NN> nvidia-smi

--gpus all: 호스트의 모든 GPU를 컨테이너에 주입(--gpus '"device=0,1"'로 일부만도 가능).
컨테이너 안에서 nvidia-smi가 단계 1과 같은 표를 내면 — Container Toolkit 다리가 놓였다.
베이스 이미지의 <X.Y>는 컨테이너 안 CUDA Toolkit 버전이고, 호스트 드라이버가 그 하한을 만족해야 한다(0.3.2.2 규칙 1).

0.3.4.4 단계 3 — deviceQuery(CUDA 런타임이 GPU를 제대로 여는지)

nvidia-smi는 드라이버 레벨, deviceQuery는 CUDA 런타임 레벨 검증이다(둘은 다른 층을 본다). deviceQuery는 CUDA Samples에 있다(과거 Toolkit 동봉 → 현재는 별도 GitHub 저장소, 확인 필요).

# CUDA 개발 이미지 안에서 샘플을 받아 빌드·실행하는 식(개략):
docker run --rm --gpus all -it <nvidia/cuda:<X.Y>-devel-ubuntu<NN.NN>> bash
# (컨테이너 안)
git clone https://github.com/NVIDIA/cuda-samples.git
cd cuda-samples/Samples/1_Utilities/deviceQuery
make            # nvcc로 빌드
./deviceQuery

예상 출력(개략):

Detected 1 CUDA Capable device(s)
Device 0: "<GPU 이름>"
  CUDA Driver Version / Runtime Version          <Drv> / <RT>
  CUDA Capability Major/Minor version number:    <예: 8.6 / 9.0 ...>   ← sm_XX (0.3.2.2 규칙 2)
  Total amount of global memory:                 <NNNNN MBytes>
  ...
  Result = PASS

Result = PASS와 더불어 CUDA Capability(= Compute Capability) 숫자를 여기서 확인한다 — 이것이 빌드 타깃 sm_XX를 정한다.

0.3.4.5 단계 4 — 간단 텐서 연산(프레임워크가 GPU를 실제로 쓰는지)

최상위 층 검증. NGC 또는 공식 프레임워크 이미지로 한다.

docker run --rm --gpus all -it <nvcr.io/nvidia/pytorch:<YY.MM>-py3> python3 - <<'PY'
import torch
print("torch:", torch.__version__)
print("cuda available:", torch.cuda.is_available())
print("device:", torch.cuda.get_device_name(0) if torch.cuda.is_available() else "CPU")
a = torch.randn(4096, 4096, device="cuda")
b = torch.randn(4096, 4096, device="cuda")
c = a @ b                      # GPU에서 행렬곱
torch.cuda.synchronize()       # 비동기 큐 비우고 실제 완료 대기
print("matmul ok, sum=", float(c.sum()))
PY

예상 출력(개략):

torch: <버전>
cuda available: True
device: <GPU 이름>
matmul ok, sum= <어떤 부동소수 값>

세 줄 요약:

cuda available: True 가 아니면 — 프레임워크가 CPU 빌드이거나, 컨테이너 안 CUDA가 드라이버와 안 맞거나, --gpus를 빼먹었다.
a @ b가 던지는 RuntimeError: no kernel image ... 는 — 프레임워크가 내 GPU의 sm_XX용으로 안 빌드됐다(규칙 2 위반). 더 새 프레임워크/이미지로 간다.
torch.cuda.synchronize()를 넣는 이유: CUDA 호출은 비동기라, 동기화 없이는 에러가 다음 호출에서 뒤늦게 오류로 드러나 원인 추적이 헷갈린다(비동기 실행 모델은 2.10에서 깊게 다룬다).

NGC 이미지 태그 <YY.MM>는 연·월 기반 월간 릴리스(예: 24.xx)로, 이미지 한 장이 드라이버 하한·CUDA·cuDNN·프레임워크 조합을 봉인한다 — 0.3.3의 "사전 검증된 조합 전체"이 이것이다.

0.3.5 중간 점검(체크포인트)

여기까지 왔다면 다음을 할 수 있어야 한다.

[ ] nvidia-smi로 드라이버 버전과 "드라이버가 받쳐줄 최대 CUDA"를 읽고, 그것이 설치된 Toolkit과 다름을 설명한다.
[ ] docker run --rm --gpus all ... nvidia-smi로 컨테이너 안에서 같은 GPU를 본다.
[ ] deviceQuery에서 Result = PASS와 내 Compute Capability(sm_XX)를 읽는다.
[ ] 프레임워크 컨테이너에서 torch.cuda.is_available() == True와 GPU 행렬곱 성공을 확인한다.

증상별 1차 의심:

증상	1차 의심	다음 행동
`nvidia-smi: command not found` 또는 "couldn't communicate with driver"	드라이버·커널 모듈 미설치/미로딩	단계 1 재점검, `dmesg \| grep -i nvidia`
호스트는 OK인데 컨테이너에서 GPU 안 보임	Container Toolkit 미설치/런타임 미구성 또는 `--gpus` 누락	단계 2, 런타임 등록 확인
`torch.cuda.is_available() == False`	CPU 빌드 프레임워크 또는 CUDA↔드라이버 미스매치	이미지 태그·CUDA 메이저 확인
`no kernel image is available`	sm_XX 미스매치(GPU가 너무 새 세대)	더 새 프레임워크/NGC 이미지

0.3.6 트레이드오프·대안 — 설치 방식 선택

같은 "CUDA 환경"을 얻는 길이 여럿이다. 의사결정으로 펼친다(BK-03·S-3).

0.3.6.1 ① 호스트 직접 설치(bare-metal CUDA Toolkit)

호스트에 드라이버 + CUDA Toolkit + cuDNN을 직접 설치한다.

장점: 컨테이너 계층 없음, 가장 직접적, 일부 저수준 프로파일링·디바이스 디버깅이 매끄럽다.
단점: 버전이 호스트에 고착 — 프로젝트마다 다른 CUDA를 쓰기 어렵다. 재현·이식이 약하다. 시스템 전역을 더럽힌다.
누구에게: 단일 프로젝트 전용 머신, 커널·드라이버 레벨 작업, A.1가 다루는 특수 셋업.

0.3.6.2 ② 컨테이너 우선(이 책의 기본 — "견해")

호스트엔 드라이버 + Container Toolkit만, CUDA·라이브러리·프레임워크는 컨테이너(특히 NGC 이미지).

장점: 재현성·격리(프로젝트마다 CUDA 교체), NGC가 조합을 봉인해 매트릭스 맞추기 부담↓, 클린 호스트, 이 책 전 장이 같은 방식으로 굴러간다.
단점: 컨테이너·볼륨·--gpus 사용법을 알아야 하고, 이미지가 크다(수 GB). 일부 호스트 레벨 프로파일링은 추가 플래그(--cap-add, --privileged 등) 필요.
누구에게: 이 책의 모든 독자 기본값. 학습·실험·재현이 중요한 거의 모든 경우. → 견해: 1차로 이 길을 택하라.

0.3.6.3 ③ 관리형/클라우드(로컬 GPU 없음)

GPU를 빌리거나, 노트북형 관리 환경을 쓴다.

Colab류 노트북: 진입장벽 최저(브라우저만). 단점 — 세션·런타임이 자주 바뀌고(드라이버·CUDA·할당 GPU가 통보 없이 변동, 확인 필요), 장시간·대용량·멀티노드 부적합, 디스크·세션 시간 제한.
클라우드 GPU 인스턴스(주요 CSP의 GPU VM, 또는 NVIDIA 측 관리형 환경): 원하는 GPU 세대를 골라 ②번 컨테이너 방식을 그대로. 단점 — 비용(시간당 과금), 쿼터·가용 리전 제약. 가격·인스턴스 사양은 변동이 크다 — 확인 필요.
누구에게: 로컬 GPU가 없거나, 특정 세대(Hopper·Blackwell 등) GPU가 잠깐 필요할 때.

비엔비디아 정직성(S-3): 동일 학습을 AMD ROCm·Intel oneAPI 등 다른 가속 스택에서도 할 수 있으나, 이 책은 엔비디아 스택을 다루므로(BK-04 경계) 비교 맥락에서만 언급한다. CUDA에 종속된 실습(TensorRT·NCCL·Isaac 등)은 대안 스택으로 그대로 옮겨지지 않는다.

0.3.6.4 자율주행·로보틱스 실습용 devkit(Jetson)

제8·9부의 일부 실습은 데이터센터·데스크톱 GPU가 아니라 엣지 SoC를 가정한다. 대표가 Jetson devkit(개발자 키트 보드)이다.

데스크톱 GPU와 다른 점: Tegra 계열 SoC(GPU + CPU + DLA·PVA 통합), 통합 메모리, x86용 CUDA Toolkit이 아니라 JetPack/L4T(아키텍처 aarch64)로 셋업한다. nvidia-smi는 Jetson에서 데스크톱과 다르게 동작할 수 있다(확인 필요) — 대신 tegrastats 등을 본다.
이 장에서는 존재와 위치만 짚는다. 모듈 선택은 9.1, JetPack·L4T·엣지 배포는 9.2·9.3, 전력·성능 운영은 9.4·A.1에서 본격적으로 다룬다.
견해: 자율주행·로보틱스 트랙을 실기로 따라갈 독자는 일찍 devkit 한 대를 확보해 두면 9.2 이후가 매끄럽다. 그렇지 않은 독자는 시뮬레이션(Isaac Sim, 9.11)으로 상당 부분을 대체할 수 있다.

0.3.7 흔한 함정

nvidia-smi의 CUDA Version을 "설치된 Toolkit"으로 착각. 그것은 드라이버가 받쳐줄 최대치다. 실제 빌드/실행에 쓰는 Toolkit은 컨테이너(또는 호스트)에 따로 있고, nvcc --version이 그것을 보여준다. 둘은 달라도 정상이다(드라이버 ≥ Toolkit이면 OK).
드라이버 < CUDA 요구 하한. 새 CUDA 이미지를 옛 드라이버 호스트에서 실행하면 런타임 오류. 정공법은 드라이버 업(0.3.2.2 규칙 1). Forward Compatibility는 데이터센터 GPU 한정·제약 많음(A.1).
컨테이너 vs 호스트 혼동. "호스트에서 되는데 컨테이너에서 안 됨" → Container Toolkit 미구성/--gpus 누락. 반대로 "컨테이너에선 되는데 호스트 파이썬에선 안 됨" → 그 패키지는 호스트가 아니라 컨테이너 안에 있다. 어느 환경에 서 있는지부터 확정하라.
CPU 빌드 프레임워크를 설치해 두고 GPU를 기대. pip로 받은 휠이 CPU 전용이면 cuda.is_available()이 조용히 False. NGC/공식 GPU 이미지를 쓰면 이 함정을 근본적으로 피한다.
sm_XX 미스매치(silent JIT 또는 에러). GPU가 프레임워크보다 새 세대면 no kernel image. PTX만 포함된 경우 첫 실행이 JIT로 느려질 수 있다(2.12 컴파일 흐름 참조) — 빌드가 내 CC를 직접 타깃하는지 확인.
Colab/클라우드의 "오늘과 내일이 다름". 관리형 환경은 드라이버·CUDA·할당 GPU가 통보 없이 바뀐다(확인 필요). 재현이 중요하면 버전을 고정한 컨테이너로 감싼다.
버전 숫자를 본문·블로그에서 외움. 이 장 포함 어떤 글의 구체 버전도 시점 의존이다. 항상 공식 매트릭스로 대조(0.3.3).

0.3.8 연습문제

각 문제의 정답·해설은 접어 두었다.

연습 1 (환경 검증). 자신의 머신(또는 빌린 클라우드 인스턴스)에서 0.3.4의 단계 1→2→4를 수행하고, ① nvidia-smi의 드라이버 버전·CUDA Version, ② 컨테이너 안 nvidia-smi가 같은 GPU를 보이는지, ③ PyTorch cuda.is_available() 결과를 적어라.

정답

셋이 모두 통과(드라이버 표 출력 / 컨테이너에서 동일 GPU / True + 행렬곱 성공)하면 이 책 실습 전제가 충족된 것. 하나라도 실패하면 0.3.5 증상표로 1차 의심을 좁혀라.

연습 2 (매트릭스 확인). 쓰려는 프레임워크 버전 하나를 정하고, 그것이 어느 CUDA 메이저로 빌드됐는지, 그 CUDA가 요구하는 최소 드라이버가 무엇인지 공식 문서에서 찾아 출처(문서명·표)와 함께 적어라. 내 호스트 드라이버가 그 하한을 만족하는가?

정답

출처는 "프레임워크 지원 매트릭스"와 "CUDA Toolkit 릴리스 노트"의 드라이버 표여야 한다. 구체 숫자는 시점 의존(S-5)이므로 숫자보다 "어디서 확인했는가"가 채점 기준. 호스트 드라이버 ≥ 하한이면 ②번 컨테이너 경로가 안전.

연습 3 (개념 구분). nvidia-smi가 CUDA Version: 12.4라 표시하는데 nvcc --version은 release 12.1이다. 모순인가? 무엇이 무엇인가?

정답

모순 아님. nvidia-smi의 12.4는 드라이버가 받쳐줄 최대 CUDA, nvcc의 12.1은 설치된 Toolkit(빌드에 쓰는 것). 드라이버(12.4 지원) ≥ Toolkit(12.1)이라 정상 동작. (숫자는 예시.)

연습 4 (컨테이너 vs 호스트). 호스트 nvidia-smi는 멀쩡한데 docker run --rm --gpus all <cuda 이미지> nvidia-smi가 GPU를 못 본다. 가능한 원인 두 가지와 각 점검 방법을 써라.

정답

(a) NVIDIA Container Toolkit 미설치/런타임 미구성 → 설치·런타임 등록 확인(0.3.4.3, 상세 A.1). (b) Docker 권한·런타임 플래그 문제 또는 --gpus 처리 실패 → 데몬 재시작·런타임 설정 확인. (드물게 SELinux/cgroup 권한.)

연습 5 (sm_XX). deviceQuery에서 내 GPU의 CUDA Capability가 9.0으로 나왔다. 한 프레임워크 실행이 no kernel image is available for execution on the device로 죽는다. 무엇이 잘못이고 어떻게 푸나?

정답

프레임워크 빌드가 sm_90(CC 9.0) 타깃을 포함하지 않음(보통 GPU가 프레임워크보다 새 세대). 해당 CC를 지원하는 더 새 프레임워크/NGC 이미지로 교체하거나(권장), 소스 빌드 시 sm_90을 타깃 아키텍처에 추가한다(2.12).

연습 6 (devkit 위치). 자율주행/로보틱스 실습을 위해 Jetson devkit을 셋업하려 한다. 이 장에서 다루는 x86 + 데스크톱 GPU 셋업과 다른 점 두 가지, 그리고 본격 절차는 어느 장을 봐야 하는지 적어라.

정답

다른 점 — (1) x86용 CUDA Toolkit이 아니라 JetPack/L4T(aarch64), (2) GPU·CPU·DLA·PVA 통합 SoC + 통합 메모리(상태는 tegrastats 등). 본격 절차: 모듈 선택 9.1, JetPack·L4T·엣지 배포 9.2·9.3, 전력·성능 9.4, 셋업 레퍼런스 A.1.

0.3.9 요약·다음 장

GPU 스택은 드라이버 ~ CUDA ~ 라이브러리 ~ 프레임워크 ~ sm_XX가 한 줄로 맞물린다. 디버깅의 핵심은 두 규칙 — 드라이버 ≥ CUDA 요구 하한, Compute Capability 일치.
이 책의 기본은 컨테이너 우선: 호스트엔 드라이버 + Container Toolkit만, 나머지는 NGC 이미지로 교체한다. 재현·격리·매트릭스 부담↓.
검증은 층층이 — nvidia-smi(드라이버) → 컨테이너 nvidia-smi(Container Toolkit) → deviceQuery(CUDA 런타임·CC) → 텐서 연산(프레임워크).
로컬 GPU가 없으면 Colab(진입 쉬움·재현 약함)·클라우드 GPU(원하는 세대·과금)로 대체. 자율주행·로보틱스는 Jetson devkit(9.1·9.2·A.1).
구체 버전·태그·가격은 전부 시점 의존(S-5) — 외우지 말고 공식 매트릭스로 대조하라.

다음으로 — 환경이 섰으니 본론으로 들어간다. 제1부 1.1(처리량 vs 지연 컴퓨팅) 에서 이 GPU가 왜 그렇게 동작하는지부터 본다. 첫 CUDA 코드를 직접 실행하는 것은 2.1, 환경 셋업의 더 깊은 레퍼런스(에어갭·멀티노드·드라이버 분기·Jetson 상세)는 부록 A.1다.