PyTorch가 GPU를 인식하지 못할 때: 가장 먼저 무엇을 확인해야 할까요?

네 가지 결정으로 이루어진 진단 과정

목표는 여러 설치를 연달아 시도하는 것이 아니라 처음 실패하는 계층을 찾는 것입니다. 실행한 명령, 첫 번째 오류 메시지, 각 점검의 결과를 보관하세요. Python, PyTorch 패키지, 배치 크기를 동시에 변경하면 어떤 수정이 문제를 해결했는지 알 수 없게 됩니다.

다운로드 가능한 스크립트는 이 순서를 적용하고 제한된 기술 보고서를 생성합니다. 모델을 실행하지 않고 설치를 변경하지도 않습니다. 프로젝트와 동일한 환경에서 사용하세요. 그렇지 않으면 문제가 발생한 프로그램과 다른 인터프리터를 점검하게 됩니다.

• Kernodeck 진단 스크립트 v1 다운로드 ↓
• 옵션과 종료 코드 읽기 ↓
• 스크립트와 JSON 예제 다운로드 ↓
• 프로젝트 환경 재구성하기 ↗

1. 실제로 실행되는 Python 확인하기

터미널, 노트북, 서비스는 서로 다른 인터프리터를 사용할 수 있습니다. 프로젝트를 실행하는 컨텍스트에서 sys.executable을 출력한 다음 버전을 확인하세요. 경로를 통해 잊고 있던 가상 환경이나 다른 커널에 남아 있는 노트북을 찾아낼 수 있습니다. 자신의 머신에서 확인하세요. 개인 디렉터리 구조를 보고서에 공개할 필요는 없습니다.

그런 다음 동일한 인터프리터로 패키지를 조회하세요. python -m pip show torch 명령은 해당 Python과 연결된 PyTorch 정보를 제공합니다. import torch가 실패하면 다음 단계는 이 설치를 수정하는 것입니다. 배치를 줄이거나 모델 가중치를 변경해도 없는 모듈은 해결되지 않습니다.

python -c "import sys; print(sys.executable); print(sys.version)"
python -m pip show torch

• Python: 사용 중인 실행 파일 확인하기 ↗
• PyTorch: 적합한 설치 명령 선택하기 ↗

2. CUDA, ROCm 및 GPU 가속 없는 패키지 구분하기

torch.__version__, torch.version.cuda, torch.version.hip을 각각 기록하세요. torch.version.cuda의 None 값만 보고 "CPU 패키지"라고 단정하지 마세요. ROCm용 PyTorch는 HIP를 사용하고 torch.cuda를 재사용하며 cuda라는 이름의 장치 역시 기대합니다. 이 이름을 rocm이나 hip으로 바꾸는 것은 적용해야 할 수정이 아닙니다.

그다음 torch.cuda.is_available()와 torch.cuda.device_count()를 확인하세요. 이 결과는 해당 Python 환경이 그 시점에 사용할 수 있는 것을 나타냅니다. 최소 연산을 대체하지는 않습니다. 시스템 도구에서는 카드가 보이더라도 패키지, 프로세스가 접근할 수 있는 드라이버 또는 그 환경 때문에 PyTorch가 이를 사용하지 못할 수 있습니다.

python -c "import torch; print(torch.__version__); print(torch.version.cuda); print(torch.version.hip); print(torch.cuda.is_available()); print(torch.cuda.device_count())"

• PyTorch: ROCm은 torch.cuda 인터페이스를 재사용합니다 ↗
• PyTorch 설치 및 초기 확인 ↗

3. Kernodeck 스크립트로 보고서 생성

파일을 다운로드한 후 작업 폴더에 넣고 프로젝트의 Python으로 실행하세요. 기본적으로 GPU를 요구합니다. CPU 모드는 명시적으로 요청해야 합니다. 성공하더라도 진단의 CPU 분기를 확인할 뿐이며, 사용할 수 없는 GPU를 검증된 GPU로 바꾸지 않습니다. 보고서는 터미널에 출력되며 --output을 사용하면 새 JSON 파일에 기록됩니다. 기존 파일은 절대 덮어쓰지 않으므로 다음 시도에는 다른 이름을 선택하세요.

스크립트는 float32로 2 × 2 행렬 두 개를 할당하고, 그 곱과 그다음 그래디언트를 확인한 뒤 GPU 장치를 동기화합니다. 이 고정 연산의 예상 손실은 196입니다. 이 매우 짧은 확인은 모델 가중치를 로드하지 않고 처리량도 측정하지 않습니다. 단순한 장치 감지를 넘어 백엔드에 작은 실제 연산을 요청합니다.

선택적 시스템 확인은 nvidia-smi가 있을 때 이를 사용합니다. NVIDIA 드라이버 버전과 해당 도구가 볼 수 있는 총 메모리만 보고하며, ROCm에 대한 동등한 시스템 확인은 아닙니다. 연산 제한 시간은 기본 30초이며 5초에서 120초까지 설정할 수 있습니다. 시스템 확인에는 별도의 최대 3초 제한 시간이 있습니다.

python kernodeck-diagnostic-v1.py --device-index 0 --timeout 30 --output diagnostic-gpu.json

python kernodeck-diagnostic-v1.py --device cpu --output diagnostic-cpu.json

python kernodeck-diagnostic-v1.py --host-check --output diagnostic-gpu-systeme.json

• Python 스크립트 다운로드 ↓
• NVIDIA: nvidia-smi의 범위와 옵션 ↗

4. 보고서를 읽고 다음 행동 선택

먼저 status, code, exit_code, stage를 확인하세요. runtime 블록은 Python 버전과 시스템 계열을 식별합니다. pytorch 블록은 임포트된 패키지, CUDA/HIP 빌드 버전, 선언된 백엔드, 표시되는 장치를 구분합니다. execution 블록은 연산이 실제로 어디에서 수행되었는지, 그리고 곱과 그래디언트가 검증되었는지를 나타냅니다.

CPU 모드에서는 gpu_available과 visible_device_count가 null로 유지됩니다. 스크립트가 GPU 드라이버 상태를 요청하지 않기 때문입니다. 이는 0도 아니고 고장도 아닙니다. execution.device도 확인하세요. CUDA용으로 컴파일된 패키지라도 명시적으로 요청하면 이 검사를 CPU에서 실행할 수 있습니다.

보고서에는 일부 기술 데이터가 포함됩니다. 환경 변수, 로컬 경로, 세션 식별자, 전체 패키지 목록, 원시 예외 트레이스는 포함하지 않습니다. 스크립트는 Kernodeck에 어떤 보고서도 전송하지 않습니다. 애플리케이션의 자세한 오류가 필요하면 작업 공간에 그 트레이스를 보관하고, 공유하기 전에 비밀 정보를 제거하세요.

• CUDA 검사 실제 보고서 ↓
• CPU 검사 실제 보고서 ↓
• PyTorch가 없을 때의 실제 보고서 ↓

5. 작은 계산에서 자체 애플리케이션으로 넘어가기

실행 전에 재현 가능한 명령, 식별된 모델, 작은 데이터 세트, 접근 가능한 출력 디렉터리를 준비하세요. 최종 작업의 중요한 특성을 유지하는 입력을 선택하세요. 텍스트 길이, 이미지 크기, 오디오 형식 또는 필수 필드 등이 여기에 해당합니다. 인위적으로 짧은 입력은 관찰하려는 문제를 가릴 수 있습니다.

구체적인 성공 기준을 작성하세요. 임베딩 계산의 경우 각 입력 식별자가 기대한 차원의 벡터를 유한한 값으로 반환해야 합니다. 학습의 경우 한 단계가 사용 가능한 손실을 산출하고, 예정된 파라미터를 갱신하며, 저장을 허용해야 합니다. 프로세스의 종료 코드는 이러한 검사를 보완할 뿐 대체하지는 않습니다.

파라미터 읽기, 라이브러리 가져오기, 가중치 로드, 데이터 준비, 전송, 계산, 쓰기 전후에 마커를 추가하세요. 각 시도에 식별자를 부여하고 관련 파라미터를 보관하세요. "모델 로드됨" 메시지는 단순한 로드 의도가 아니라 완료된 이벤트에 대응해야 합니다.

전체 데이터 세트를 복사하지 말고 유용한 텐서의 형태, 유형, 장치를 로그로 남기세요. "입력: 8 시퀀스, 최대 길이 512, 장치 cuda:0"과 같은 요약은 두 시도를 비교하는 데 도움이 됩니다. 여기서 이 숫자들은 범용 설정이 아니라 로그 예시를 설명합니다. 이러한 메시지에 액세스 토큰이나 입력의 민감한 내용을 넣지 마세요.

6. 올바른 계층에서 오류 수정하기

작은 계산은 통과하지만 가중치를 찾을 수 없다면 경로, 형식, 접근 권한을 점검하세요. 확장 기능을 가져오는 데 실패한다면 PyTorch 패키지 및 프로젝트 백엔드와의 호환성을 확인하세요. 성공적인 진단이 애플리케이션의 모든 확장 기능을 검증하지는 않습니다. 여러 의존성을 한꺼번에 바꾸지 말고 처음 실패한 단계부터 다시 시작하세요.

장치 오류는 모델이 GPU에 있는데 입력이 CPU에 남아 있을 때 발생할 수 있습니다. 유형 오류는 부분 변환 또는 선택한 정밀도와 호환되지 않는 연산자에서 발생할 수 있습니다. 첫 번째 전체 메시지와 그 추적을 보관하세요. 한 번에 하나의 가정만 수정한 다음, 최종 볼륨을 다시 도입하기 전에 최소 입력을 재실행하세요.

7. 모델이 시작된 후 메모리를 초과하는 경우

초과가 가중치 로드 시, 첫 계산 시, 또는 여러 반복 후에 발생하는지 파악하세요. 이러한 시점은 서로 다른 원인을 가리킵니다. 모델이 너무 큰 경우, 활성화 또는 생성 캐시가 큰 경우, 보존된 텐서가 누적된 경우 등입니다. 동일한 단계에서 torch.cuda.memory_allocated()와 torch.cuda.memory_reserved()를 기록하세요. 전자는 텐서 할당을 추적하고, 후자는 할당자가 관리하는 메모리를 포괄합니다.

torch.cuda.empty_cache()는 사용되지 않는 캐시를 반환할 수 있지만 아직 참조 중인 텐서를 제거하지는 않습니다. 따라서 출력 목록, 손실 기록, 계산 그래프를 유지하는 객체를 점검하세요. 그런 다음 결정적 요인을 분리하기 위해 batch 또는 입력 길이를 줄이세요. 어느 단계에서 초과가 발생하고 실제로 필요한 여유가 얼마인지 알면 카드 교체가 정보에 기반한 결정이 됩니다.

• PyTorch: 텐서에 할당된 메모리 ↗
• PyTorch: 할당자가 관리하는 메모리 ↗
• PyTorch: empty_cache가 해제하는 것 ↗
• 메모리, 컨텍스트, 추론 batch 연결하기 ↗

8. 비동기성을 잊지 않고 계산 측정하기

GPU 연산은 Python 프로그램에 대해 비동기적일 수 있습니다. 따라서 호출 주위에 놓인 타이머는 주로 작업 전송 시간을 측정할 수 있습니다. 진단 측정을 위해서는 관찰하는 구간의 경계에서 GPU를 동기화하거나 적절한 이벤트를 사용하세요. 이 동기화는 실행 흐름을 변경하므로 이 계측을 애플리케이션의 정상 동작과 분리해 두세요.

입력 준비, 계산, 출력 쓰기의 세 단계로 구성된 간단한 예제를 만들어 보세요. GPU 단계에서는 torch.cuda.synchronize()를 호출하고, time.perf_counter()로 시간을 측정한 뒤 계산을 실행하고, 다시 동기화한 다음 차이를 계산합니다. 첫 번째 실행과 이후 실행은 따로 기록하세요. 로딩이나 초기화가 전체 응답 시간으로 제시된 평균에 섞여 들어가서는 안 됩니다.

• PyTorch: 동기화와 GPU 계산 측정 ↗

9. 출력을 검증하고 재사용 가능한 진단을 보관하기

일반적인 추론에서는 model.eval()이 해당 모듈의 동작을 설정하고, torch.inference_mode()는 그래디언트에 필요한 추적을 비활성화합니다. 이 두 설정은 서로 다른 역할을 합니다. 생성된 텐서가 이후 그래디언트 계산에 참여하지 않아야 할 때는 후자를 사용하세요. 학습 중 모델 평가를 수행할 경우, 재개하기 전에 올바른 모드로 명시적으로 되돌려야 합니다.

이제 출력을 준비한 계약과 비교해 보세요. 결과 개수, 식별자 일치, 차원, 유한값, 적절한 비즈니스 지표를 확인합니다. 배치를 늘리면 이 일치 여부를 다시 확인하세요. GPU를 추가하면 입력 분배와 출력 수집을 점검하세요. 대여 배치는 주문한 카드를 가리키고, 배치는 프로그램이 함께 처리하는 예제를 가리킵니다.

이 방법의 결과물은 작은 기록 묶음입니다. 명령, 버전, 파라미터, 최소 입력, 마지막 성공 단계, 첫 번째 오류, 메모리 관찰, 얻은 출력입니다. 실행이 성공하면 부하를 늘리기 전 비교 기준점으로 이 기록을 보관하세요. 실행이 실패하면 전체 조사를 처음부터 다시 하지 않고 문제를 재현할 수 있습니다.

장시간 처리 전에는 이 작은 입력 세트로 정상 종료와 재개도 수행해 보세요. 이미 기록된 출력이 유실되거나 두 번 집계되지 않는지 확인하세요. 이 점검을 통과하면 배치, 길이, 동시성, 프로세스 수 중 하나의 축만 점진적으로 늘리고 관찰된 한계를 기록하세요. GPU 이름에 기반한 추측이 아니라, 애플리케이션에 대해 측정된 동작 범위를 얻게 됩니다.

• PyTorch: inference_mode와 eval의 차이 ↗
• 새 프로세스에서 재현 여부 확인하기 ↗

제공된 증거와 그 한계

다운로드 가능한 예시는 2026년 9월 24일에 수행된 실제 검사에서 나온 것입니다. PyTorch를 사용한 두 실행은 Windows, Python 3.14.6, PyTorch 2.11.0+cu128을 사용합니다. GPU 검사는 NVIDIA GeForce RTX 5070에서 CUDA를 사용하고, CPU 검사는 명시적으로 CPU를 요청합니다. 이 검사 하드웨어는 Kernodeck의 제공 상품으로 제시되지 않습니다. 이 증명을 위해 ROCm 계산은 실행되지 않았습니다.

성공한 작은 연산은 선택한 장치에서 할당 및 연산 경로가 작동함을 보여줍니다. 이는 여러분 모델의 속도, 가장 큰 입력에 필요한 메모리, 특정 확장 기능과의 호환성을 측정하지 않습니다. 또한 이 보고서는 멀티 카드 토폴로지를 보증하지도 않습니다. 부하나 대여를 늘리기로 결정하기 전에 대표성 있는 테스트로 넘어가세요.

CUDA 애플리케이션이라면 NVIDIA 사양을 메모리 및 라이브러리 요구 사항과 비교하고, ROCm 파이프라인이라면 MI300X의 조건을 검토하세요. 연결된 사양은 프로젝트에 맞게 검증할 옵션이며, 증거에 사용된 하드웨어 목록이 아닙니다. 초기 점검 및 내보내기 시간을 3일, 7일 또는 30일 기간에 포함해 두세요.

• 진단 프로토콜과 한계 읽기 ↓
• CUDA 프로젝트를 위한 RTX 4090 검토하기 ↗
• ROCm 파이프라인을 위한 MI300X 검토하기 ↗
• 프로젝트 검증 후 임대 구성 ↗