fos-blog/study
01 / 홈02 / 카테고리03 / 시리즈
01 / 홈02 / 카테고리03 / 시리즈

카테고리

  • AI 페이지로 이동
    • RAG 페이지로 이동
    • agent 페이지로 이동
    • claude-code 페이지로 이동
    • harness 페이지로 이동
    • llm 페이지로 이동
    • ops 페이지로 이동
    • practice 페이지로 이동
  • algorithm 페이지로 이동
    • Alias Method: 가중치 랜덤 선택을 전처리 O(n), 추출 O(1)로 바꾸기
    • Welford's Online Algorithm: 값을 저장하지 않고 평균과 분산 계산하기
  • architecture 페이지로 이동
    • distributed-systems 페이지로 이동
    • domain 페이지로 이동
    • evolution 페이지로 이동
    • patterns 페이지로 이동
  • database 페이지로 이동
    • milvus 페이지로 이동
    • mysql 페이지로 이동
    • opensearch 페이지로 이동
    • postgresql 페이지로 이동
    • qdrant 페이지로 이동
    • redis 페이지로 이동
    • vespa 페이지로 이동
    • DB Connection Pool Saturation과 Thread Pool 격리
    • 커넥션 풀 크기는 얼마나 조정해야 할까?
    • gaps and islands: SQL 창 함수로 이어진 구간 찾기
    • MyBatis 기본기 — XML Mapper, resultMap, 동적 SQL, 운영 패턴 정리
    • MyBatis와 JPA/Hibernate 트레이드오프 — 레거시 백엔드를 다루는 시니어 관점
    • 한국어 형태소 분석기 Nori vs Lindera — OpenSearch에서 Milvus로 갈 때 어휘 검색은 유지되나
    • 정규화와 역정규화: 무결성과 조회 비용 사이의 선택
    • 벡터 DB 5종, 아키텍처는 어떻게 다른가
    • 벡터 DB 5종을 실제로 벤치마크했다 — 같은 recall에서 QPS는 얼마나 갈리나
    • 벡터 DB 어떻게 고를까 — OpenSearch · Milvus · Qdrant · Vespa · pgvector 비교
    • 벡터 DB를 실제로 도입한 사례 — 빅테크 프로덕션
  • devops 페이지로 이동
    • docker 페이지로 이동
    • k8s 페이지로 이동
    • Envoy Proxy
    • Graceful Shutdown
    • 종료 신호는 어디서 멈추는가
  • http 페이지로 이동
    • HTTP Connection Pool
    • HTTPS와 TLS: 핸드셰이크, 인증서, 종료 지점
  • java 페이지로 이동
    • concurrency 페이지로 이동
    • jdbc 페이지로 이동
    • spring 페이지로 이동
    • spring-batch 페이지로 이동
    • testing 페이지로 이동
    • Alpine 이미지의 Java 에서 링크 바꿔치기(TOCTOU)를 막지 못하는 이유
    • Java 동시성 락 정리 — 커머스 메뉴/프로모션 정책 캐시 갱신 관점
    • JVM 튜닝 실전: 메모리 구조부터 Virtual Threads, GC 튜닝, 프로파일링까지
    • 로그에 traceId 남기기 — MDC 부터 OpenTelemetry 까지
    • Java StampedLock — 읽기 폭주에도 쓰기가 밀리지 않는 락
    • Virtual Thread와 Project Loom
  • javascript 페이지로 이동
    • typescript 페이지로 이동
    • AbortController
    • Async Iterator와 제너레이터
    • CommonJS와 ECMAScript Modules
    • 제너레이터(Generator)
    • Http Client
    • Node 백엔드 운영 패턴 — Streams 백프레셔, pipe/pipeline, 멱등성 vs 분산 락
    • Node.js
    • `setImmediate()`
  • kafka 페이지로 이동
    • Kafka 클러스터 아키텍처: Broker, KRaft Controller와 복제
    • Kafka 기본 개념: Topic, Partition, Offset과 Segment
    • Kafka 실전 설계: 파티션 전략, 컨슈머 그룹, 전달 보장, 재시도, 순서 보장 트레이드오프
    • Kafka 파티션·리밸런스·컨슈머 지연 운영
    • Kafka를 로그로 이해하기: 복제, 재처리, 상태와 데이터 통합
    • Spring Kafka 컨슈머 오프셋 커밋과 트랜잭션 정렬: AckMode, manual ack, 멱등 처리
  • linux 페이지로 이동
    • fsync — 리눅스 파일 동기화 시스템 콜
    • SSH forced command 로 배포 키가 실행할 수 있는 명령 제한하기
  • mlops 페이지로 이동
    • llm-serving 페이지로 이동
    • model-router 페이지로 이동
    • Python CUDA 버전 생태계 — nvidia-smi, nvcc, pip, conda가 다 다른 버전을 말하는 이유
    • GPU 컨테이너의 CUDA 버전 호환성 — nvidia-smi부터 이미지 다이어트까지
    • Kubernetes GPU 노드에서 /run tmpfs가 꽉 차서 Pod가 안 뜰 때
    • GPU·CUDA·MPS 기초 — 자바 백엔드 개발자가 처음 만나는 그림
    • Multi-process GPU 워크로드 — 자바 ThreadPool 사용자가 만나는 모델 차이
    • ML 서비스 성능 분석 워크플로 — 자바 백엔드 트러블슈팅과 다른 점
    • 한 GPU 를 여러 프로세스가 나눠 쓰기 — Time-Slicing 과 MPS
  • network 페이지로 이동
    • Connection reset by peer는 누가 보낸 걸까 — 리버스 프록시 홉마다 TCP 연결은 따로 논다
    • L2(스위치)와 L3(라우터)의 역할 차이
    • L4와 VIP(Virtual IP Address)
    • IP Subnet
  • observability 페이지로 이동
    • Observability 입문: 시니어 백엔드가 장애를 탐지하고 대응하는 방식
    • K8s 위 Spring Boot 앱의 메트릭 수집
  • python 페이지로 이동
    • Python async/await — CompletableFuture·Reactor 와 다른 점, 그리고 blocking I/O 함정
    • Python 의존성 관리 — Java Maven/Gradle 사용자가 만나는 첫 충격
    • FastAPI 기초 — Spring Boot 사용자가 빠르게 익히는 법
    • Java 개발자를 위한 Python 심화 — OOP·데코레이터·컨텍스트 매니저
    • PyTorch 기초 — 텐서, 디바이스, 그리고 모델 로딩이 무거운 이유
    • Java 개발자를 위한 Python 문법 핵심
    • ThreadLocal 에서 contextvars 로 — Python 의 요청 컨텍스트 전파
    • OCR 동작 원리 — Layout · Text · Post-process 3단계
    • Python 서버의 RSS가 줄지 않는 이유: CPython, gc.collect(), malloc_trim
  • rabbitmq 페이지로 이동
    • RabbitMQ Basics — 실전 백엔드 관점에서 정리하는 메시지 브로커 기본기
    • RabbitMQ vs Kafka — 백엔드 메시징 선택 기준과 실전 운영 관점
  • resume 페이지로 이동
    • 경험 및 경력기술서
    • 김병태 경력기술서
    • 김병태 포트폴리오
  • task 페이지로 이동
    • ai-service-team 페이지로 이동
    • nsc-slot 페이지로 이동
    • personal-projects 페이지로 이동
    • sb-dev-team 페이지로 이동
    • the-future-company 페이지로 이동
  • thinking 페이지로 이동
    • 자기주도 학습: 질문에서 시작해 글로 검증하기
    • 좋은 일을 넘어 중요한 일을 하는 법
FOS-BLOG · FOOTERall systems normal·v0.1 · 2026.04.27·seoul, kr
Ffos-blog/study

개발 학습 기록을 정리하는 블로그입니다. 공부하면서 기록하고, 기록하면서 다시 배웁니다.

visitors
01site
  • Home↗
  • Posts↗
  • Categories↗
  • Glossary↗
  • About↗
02policy
  • 소개/about
  • 개인정보처리방침/privacy
  • 연락처/contact
03categories
  • AI↗
  • Algorithm↗
  • DB↗
  • DevOps↗
  • Java/Spring↗
  • JS/TS↗
  • React↗
  • Next.js↗
  • System↗
04connect
  • GitHub@jon890↗
  • Source repositoryjon890/fos-study↗
  • RSS feed/rss.xml↗
  • Newsletter매주 1 회 · 한 편의 글→
© 2026 FOS Study. All posts MIT-licensed.
built with·Next.js·Tailwind v4·Geist·Pretendard·oklch
fos-blog/mlops/Python CUDA 버전 생태계 — nvi…
mlops

Python CUDA 버전 생태계 — nvidia-smi, nvcc, pip, conda가 다 다른 버전을 말하는 이유

PyTorch를 pip install로 깔았는데 시스템에 CUDA Toolkit을 따로 안 깔아도 GPU가 돌았다. 그러다 nvidia-smi는 CUDA 12.2라고 하고, nvcc --version은 아예 명령이 없다고 하고, python -c "import torch; print(torch.version.cuda)"는 12.6이라고 한다. 같은 머신에서...

2026.06.16·5 min read·180 views·SERIES · AI 서빙 인프라: GPU부터 문서 파싱까지 · 1/11

PyTorch를 pip install로 깔았는데 시스템에 CUDA Toolkit을 따로 안 깔아도 GPU가 돌았다. 그러다 nvidia-smi는 CUDA 12.2라고 하고, nvcc --version은 아예 명령이 없다고 하고, python -c "import torch; print(torch.version.cuda)"는 12.6이라고 한다. 같은 머신에서 CUDA 버전이 세 가지로 갈렸다.

처음엔 환경이 꼬인 줄 알았는데, 알고 보니 셋 다 정상이고 각자 다른 걸 말하고 있었다. 이 글은 그 생태계를 정리한 것이다. GPU 컨테이너에서의 드라이버 호환성은 GPU 컨테이너의 CUDA 버전 호환성에 따로 적었고, 이 글은 로컬 Python 환경에서 CUDA가 어떻게 여러 층으로 쪼개지는지를 다룬다.

CUDA에는 API가 두 개다

혼란의 뿌리는 CUDA가 하나가 아니라는 데 있다. CUDA는 두 개의 API 층으로 나뉜다.

  • Driver API — 드라이버에 들어 있는 저수준 API다. libcuda.so로 제공되고, NVIDIA 드라이버를 깔면 같이 들어온다. GPU에 직접 명령을 내리는 가장 아래층이다.
  • Runtime API — 그 위에 얹히는 고수준 API다. libcudart.so로 제공되고, CUDA Toolkit이나 PyTorch 같은 라이브러리에 묶여 들어온다. 우리가 코드에서 쓰는 대부분의 CUDA 함수가 여기에 있다.

이 두 층이 별도로 버전을 가진다. 드라이버 쪽 CUDA 버전(Driver API)과 런타임 쪽 CUDA 버전(Runtime API)이 서로 다를 수 있고, 그게 정상이다.

기본 규칙은 하나다. Driver API 버전이 Runtime API 버전보다 같거나 높아야 한다. 드라이버가 더 낮은 CUDA를 보면 못 돌린다. 반대로 드라이버가 더 높은 CUDA를 보는 건 괜찮다. 이게 forward compatibility다.

nvidia-smi와 nvcc는 서로 다른 층을 본다

이제 두 명령이 왜 다른 숫자를 말하는지가 풀린다.

nvidia-smi는 드라이버와 함께 설치되고, Driver API 쪽 버전을 보고한다. 정확히는 이 드라이버가 받아줄 수 있는 가장 높은 CUDA 버전, 즉 호환 상한이다. 실제로 무엇이 설치됐는지가 아니라 무엇까지 받아줄 수 있는지를 말한다.

nvcc는 CUDA Toolkit과 함께 설치되고, Runtime API 쪽 버전을 보고한다. 실제로 시스템에 깔린 Toolkit 버전이다. 컴파일에 쓰이는 버전이라 이게 정확해야 빌드가 맞물린다.

그래서 둘이 다르면 이렇게 읽으면 된다.

  • nvidia-smi가 12.2 = 이 드라이버는 CUDA 12.2까지 받아줄 수 있다
  • nvcc가 11.8 = 시스템에 깔린 Toolkit은 11.8이다
  • 11.8 ≤ 12.2 이므로 정상이다

nvcc가 아예 없다고 나오는 경우도 흔하다. CUDA Toolkit을 시스템에 설치하지 않았다는 뜻인데, 뒤에서 보겠지만 PyTorch만 쓸 거라면 이게 오히려 정상이다.

Python에서는 CUDA가 패키지로 따라온다

여기가 Python 생태계의 핵심이다.

pip install torch를 하면, PyTorch 휠은 자기가 쓸 CUDA 런타임 라이브러리를 의존성으로 같이 끌어온다. 요즘 PyTorch는 nvidia-cuda-runtime-cu12, nvidia-cudnn-cu12, nvidia-cublas-cu12 같은 패키지들을 딸려 설치한다. 이것들이 바로 Runtime API 쪽 라이브러리다.

중요한 건 이 패키지들이 런타임 라이브러리만 담고 있다는 점이다. libcudart.so, libcublas.so 같은 실행용 .so는 들어 있지만, nvcc 같은 개발 도구는 없다. 그래서 시스템에 CUDA Toolkit을 안 깔아도 PyTorch가 GPU에서 도는 것이다. PyTorch가 자기 런타임을 통째로 들고 다니고, 호스트에서는 드라이버(libcuda.so)만 빌려 쓴다.

이게 세 번째 버전의 정체다.

python
import torch
print(torch.version.cuda)   # 예: 12.6 — PyTorch 휠이 번들한 CUDA 런타임 버전

torch.version.cuda는 시스템 Toolkit도 드라이버도 아니다. PyTorch 휠 안에 묶여 들어온 CUDA 런타임 버전이다. 그래서 nvidia-smi(드라이버 상한)와도, nvcc(시스템 Toolkit)와도 다를 수 있다.

conda와 pip, 그리고 full toolkit의 차이

설치 경로가 여러 갈래라 더 헷갈린다. 정리하면 이렇다.

  • pip의 nvidia-cuda-runtime-cu12 류 — 런타임 라이브러리만. PyTorch가 의존성으로 끌어온다.
  • conda의 cudatoolkit — 마찬가지로 런타임 라이브러리 중심. conda 환경 안에 CUDA 런타임을 넣어준다. pytorch-cuda 메타패키지는 conda solver가 맞는 PyTorch 빌드를 고르도록 돕는 역할이다.
  • NVIDIA가 배포하는 full CUDA Toolkit — 런타임 + 개발 도구 전부. nvcc, cuda-gdb, cuda-memcheck까지 들어 있다.

여기서 갈린다. PyTorch나 PaddlePaddle로 추론/학습만 한다면 full toolkit이 필요 없다. 런타임 라이브러리만 있으면 되고, 그건 pip/conda가 프레임워크와 함께 넣어준다. full toolkit이 필요한 건 직접 CUDA 커널(.cu 파일)을 작성해서 nvcc로 컴파일할 때다. 커스텀 연산을 빌드하거나, 일부 라이브러리를 소스에서 빌드할 때가 그렇다.

그래서 "GPU 코드를 돌린다"와 "GPU 코드를 컴파일한다"를 구분해야 한다. 돌리기만 하면 런타임으로 충분하고, 컴파일하려면 full toolkit이 필요하다.

PyTorch는 CUDA 버전을 골라서 깐다

PyTorch 휠은 CUDA 버전별로 따로 빌드되어 배포된다. pip 기본 인덱스에서 받으면 PyTorch가 그 시점에 기본으로 정한 CUDA 빌드가 깔리는데, 특정 버전을 원하면 인덱스를 직접 지정한다.

bash
# CUDA 11.8 빌드
pip install torch --index-url https://download.pytorch.org/whl/cu118
 
# CUDA 12.4 빌드
pip install torch --index-url https://download.pytorch.org/whl/cu124

어떤 cu 버전을 고를지는 GPU와 드라이버에 달렸다.

  • cu118 — 가장 안전하고 호환 범위가 넓다. 오래된 카드도 잘 받는다.
  • cu121, cu124, cu126 — 최신 카드에 맞고, 최신 PyTorch가 기본으로 따라가는 쪽이다.

PyTorch 버전마다 제공하는 cu 빌드가 다르다는 점도 주의한다. 예를 들어 어떤 PyTorch 버전은 cu118과 cu124만 주고, 다른 버전은 cu118과 cu126을 준다. 원하는 조합이 실제로 배포되는지를 인덱스에서 먼저 확인하는 게 안전하다.

그리고 앞에서 본 호환성 규칙이 여기서도 작동한다. PyTorch 휠이 cu126으로 빌드됐어도, 호스트 드라이버가 CUDA 12.x를 받을 수 있으면(같은 메이저의 최소 드라이버 이상) 돈다. 드라이버가 그 메이저를 아예 못 받으면 그때 막힌다.

내 환경의 CUDA를 진단하는 법

버전이 꼬였다고 느낄 때 한 번에 훑는 명령들이다.

bash
# 1. 드라이버가 받아줄 수 있는 CUDA 상한 (Driver API)
nvidia-smi
 
# 2. 시스템에 설치된 CUDA Toolkit (Runtime API, 없을 수 있음)
nvcc --version
 
# 3. PyTorch가 번들한 CUDA 런타임 버전
python -c "import torch; print(torch.version.cuda, torch.cuda.is_available())"
 
# 4. pip가 끌어온 CUDA 런타임 패키지들
pip list | grep -i nvidia

이 넷이 다 다른 숫자를 말해도 보통 정상이다.

  • nvidia-smi 숫자 ≥ torch.version.cuda 의 메이저 호환이면 GPU가 돈다
  • nvcc가 없거나 다른 버전이어도 PyTorch 추론에는 영향이 없다
  • torch.cuda.is_available()이 True면 실제로 GPU를 잡은 것이다

마지막 줄이 핵심 판정이다. 버전 숫자가 제각각이어도 is_available()이 True면 일단 동작하는 환경이다.

정리

같은 머신에서 CUDA 버전이 여러 개로 보이는 건 고장이 아니라 구조다.

  • CUDA는 Driver API와 Runtime API 두 층으로 나뉜다.
  • nvidia-smi는 드라이버 상한(Driver API), nvcc는 설치된 Toolkit(Runtime API)을 본다.
  • Python에서는 PyTorch 휠이 자기 CUDA 런타임을 번들로 끌어온다. 그래서 시스템 Toolkit 없이도 GPU가 돈다.
  • pip/conda가 주는 건 런타임 라이브러리고, nvcc가 든 full toolkit은 CUDA 코드를 직접 컴파일할 때만 필요하다.
  • 버전이 다 달라도 드라이버가 런타임의 메이저를 받아주면 동작한다.

결국 외워야 할 한 줄은 이거다. 호스트에는 드라이버만 맞추고, 런타임 CUDA는 프레임워크가 들고 다닌다. 이 구조를 알고 나니 버전 숫자가 제각각인 게 더 이상 불안하지 않았다.

참고 링크

  • CUDA Compatibility — NVIDIA 공식 문서
  • nvcc vs nvidia-smi: Why Different CUDA Versions Are Shown
  • PyTorch Previous Versions — 설치 인덱스
  • CUDA Toolkit: Full vs Conda-installed version
on this page
  • 01CUDA에는 API가 두 개다
  • 02nvidia-smi와 nvcc는 서로 다른 층을 본다
  • 03Python에서는 CUDA가 패키지로 따라온다
  • 04conda와 pip, 그리고 full toolkit의 차이
  • 05PyTorch는 CUDA 버전을 골라서 깐다
  • 06내 환경의 CUDA를 진단하는 법
  • 07정리
  • 08참고 링크
tags
#study📚 AI 서빙 인프라: GPU부터 문서 파싱까지
NEXT →GPU 컨테이너의 CUDA 버전 호환성 — nvidia-smi부터 이미지 다이어트까지

이런 글도

  • mlops

    추측 디코딩과 vLLM 적응형 검증

    2026.11.14
  • mlops

    같은 문제를 회사마다 다른 층에서 푼다

    2026.09.08
  • mlops

    캐시를 보고 인스턴스를 고른다

    2026.09.08
  • mlops

    vLLM 지표를 라우팅 판단에 쓰는 방법

    2026.09.08

댓글 (0)