한 줄 정의

CUDA는 NVIDIA GPU에서 병렬 계산 코드를 짜고 실행하게 해 주는 플랫폼이자 프로그래밍 모델이야. AI 문맥에서 “CUDA를 지원한다”는 말은 그냥 GPU가 있다는 뜻보다, NVIDIA GPU용 커널과 라이브러리 경로가 열려 있다는 뜻에 더 가까워.

어떻게 작동하나

CUDA는 CPU와 GPU가 같이 있는 이기종 시스템을 전제로 잡아. NVIDIA 문서도 CPU 쪽을 host, GPU 쪽을 device라고 부르고, host 코드가 device 메모리로 데이터를 옮기고 kernel을 launch한다고 설명해. 이 kernel은 GPU에서 같은 코드를 아주 많은 thread가 병렬로 실행하는 함수야.

실행 단위도 계층이 있어. thread는 block으로 묶이고, block은 grid로 묶여. block과 grid는 1차원, 2차원, 3차원으로 잡을 수 있고, warp는 32개 thread 묶음으로 움직여. CUDA C++ 예시는 vecAdd<<<...>>>처럼 launch를 적고, current GPUs에서는 block 하나에 최대 1024개 thread를 둘 수 있다고 설명해. 그래서 CUDA를 본다는 건 GPU가 빠르냐만 보는 게 아니라, kernel이 몇 개 thread로 어떻게 쪼개져 돌고 VRAM과 shared memory를 어떻게 쓰는지까지 같이 본다는 뜻이야.

실무에서는 raw CUDA 커널을 직접 안 짜는 경우도 많아. 그래도 CUDA가 중요하다는 점은 안 바뀌어. cuBLAS, cuDNN, CUTLASS 같은 라이브러리와 OpenAI Triton 같은 상위 레이어가 결국 CUDA 플랫폼으로 내려가서 돌아가기 때문이야. 런타임이나 프레임워크가 친절하게 감싸 줘도, 아래 바닥은 여전히 CUDA 경로일 때가 많아.

왜 중요한가

CUDA는 속도 자체보다 호환성 판단에서 더 자주 갈림길이 돼. 예를 들어 llama.cpp 공식 README는 backend 표에서 Metal은 Apple Silicon, CUDA는 Nvidia GPU, HIP는 AMD GPU로 따로 적어. 같은 로컬 LLM 도구를 써도 어떤 backend가 열려 있느냐에 따라 설치 방법, 드라이버, 메모리 배치, 지원 기능이 달라진다는 뜻이야. “GPU가 있다”보다 “CUDA backend가 있나”가 먼저인 경우가 꽤 많아.

이 차이는 커뮤니티 글에서도 바로 드러나. 2026년 4월 Apple Silicon DFlash 글은 M5 Max 64GB, MLX, no CUDA 조건에서 Qwen3.5-9B BF16이 1024 토큰 기준 85 tok/s라고 커뮤니티에서 보고했고, 같은 달의 llama.cpp 비교 글은 RTX 5080 16GB VRAM, CUDA 13.1, 2500+ 토큰 프롬프트 조건을 따로 적었어. 둘 다 LLM 속도 얘기지만, 한쪽은 Metal·MLX 경로고 다른 한쪽은 CUDA 경로야. 숫자는 참고할 수 있어도, 공식 성능 표가 아니라 환경표가 붙은 커뮤니티 예시로 읽는 편이 맞아.

주의해서 볼 점

첫째, CUDA는 GPU의 다른 이름이 아니야. NVIDIA 쪽은 CUDA가 강하고, AMD는 HIP·ROCm 쪽으로, Apple Silicon은 Metal이나 MLX 쪽으로 간다. 그래서 문서나 벤치마크에 CUDA가 적혀 있으면 “NVIDIA 전용 경로구나”부터 읽는 편이 덜 헷갈려.

둘째, CUDA 지원은 모델 품질 보장이 아니라 실행 경로 보장이야. 같은 모델이라도 CUDA 버전, 드라이버, 운영체제, 빌드 옵션이 바뀌면 성능과 안정성이 달라질 수 있어. Windows냐 Linux냐, prebuilt binary냐 직접 컴파일이냐 같은 차이도 여기서 영향을 준다.

셋째, 속도 향상이 전부 모델 자체 덕분은 아닐 수 있어. DFlash 논문도 순차 디코딩이 GPU utilization을 떨어뜨린다고 짚어. 그러니까 어떤 결과가 빨라졌다면 가중치가 좋아진 건지, speculative decoding 같은 추론 구조가 바뀐 건지, CUDA kernel이나 library 경로가 더 잘 맞은 건지 먼저 나눠 보는 게 좋아.