한 줄 정의
GPU는 같은 종류의 계산을 아주 많이 나눠서 동시에 처리하도록 만든 프로세서야. AI 문맥에서는 학습과 추론에서 큰 행렬곱, attention, 이미지·영상 처리, 양자화된 연산을 실제로 굴리는 하드웨어 계층이라고 보면 돼.
그래서 GPU는 모델 이름도 아니고 메모리 용량만 뜻하는 말도 아니야. 24GB, 80GB, 1,440GB 같은 숫자는 중요하지만, 그 숫자는 GPU 메모리, 대역폭, 정밀도 지원, 런타임, 전력 예산을 같이 볼 때 의미가 생겨.
어떻게 작동하나
GPU 작업은 보통 CPU가 전체 프로그램을 시작하고, 계산이 큰 구간을 GPU 쪽으로 보내는 식으로 돌아가. NVIDIA CUDA 문서는 CPU와 CPU 메모리를 host, GPU와 GPU 메모리를 device라고 부르고, GPU에서 실행되는 함수를 kernel이라고 설명해. kernel launch는 같은 함수를 많은 thread로 나눠 GPU에서 병렬 실행하는 동작이야.
CUDA 기준으로는 thread가 block과 grid로 묶이고, GPU 안의 Streaming Multiprocessor(SM)가 그 block을 실행해. warp는 32개 thread 묶음으로 움직이기 때문에, 같은 길의 계산을 많이 반복할수록 GPU 활용률이 좋아져. 반대로 thread마다 분기가 다르고 CPU와 데이터를 자주 주고받으면 GPU가 기다리는 시간이 생겨. 빠른 부품을 샀는데 대기실에 세워두는 상황이라 좀 억울해진다.
NVIDIA만 있는 건 아니야. 이쪽은 CUDA 생태계가 강하고, AMD 쪽은 ROCm과 HIP가 같은 종류의 GPU 계산 경로를 맡아. CPU와의 차이는 많은 작업을 한 줄로 빠르게 끝내기보다 비슷한 계산을 크게 나눠 처리한다는 데 있고, TPU나 전용 ASIC 대비 차이는 범용 프로그래밍과 라이브러리 선택지가 더 넓다는 데 있어. Apple Silicon, Intel GPU, TPU 같은 다른 가속기도 있어서, 실무에서는 “GPU가 있나”보다 “내 런타임과 모델이 그 장치의 kernel을 실제로 타나”가 더 중요한 질문이 돼.
왜 중요한가
AI 비용은 모델 파라미터 수만으로 안 끝나. 같은 로컬 LLM이라도 GPU 메모리가 부족하면 모델을 못 올리고, 대역폭이 부족하면 토큰 처리 속도가 안 나오고, FP8·BF16 같은 정밀도 경로가 맞지 않으면 기대한 처리량이 안 나와.
숫자로 보면 감이 빨라져. NVIDIA H100 SXM 사양은 80GB GPU 메모리와 3.35TB/s 메모리 대역폭을 적고, FP8 Tensor Core 성능을 sparsity 기준 3,958 teraFLOPS로 제시해. DGX B200은 아예 시스템 단위라서 8개 Blackwell GPU, 1,440GB 총 GPU 메모리, 64TB/s HBM3e 대역폭, 약 14.3kW 최대 시스템 전력을 적어. 이 정도가 되면 “GPU 몇 장”이 아니라 전력, 냉각, 네트워크, 운영까지 묶인 인프라 문제가 돼.
그래서 GPU는 에이전트형 코딩과도 연결돼. SOL-ExecBench는 235개 CUDA kernel 최적화 문제를 124개 production·emerging AI model에서 뽑아, agent가 kernel을 얼마나 하드웨어 한계에 가깝게 고칠 수 있는지 보려는 벤치마크야. 모델이 코드를 잘 쓰는 것과 GPU에서 빠른 kernel을 만드는 건 다른 문제라서, 이 둘을 구분해 읽어야 해.
주의해서 볼 점
GPU를 고를 때는 먼저 메모리 용량과 대역폭을 나눠 봐. 큰 모델을 올릴 수 있느냐는 용량이 결정하고, 같은 모델을 얼마나 빠르게 밀어내느냐는 대역폭과 kernel 품질이 크게 좌우해. A3B 같은 활성 파라미터 표기를 보더라도 전체 가중치, KV cache, 컨텍스트 길이, 양자화 포맷을 같이 봐야 실제 GPU 예산이 잡혀.
두 번째는 런타임이야. vLLM, TensorRT-LLM, llama.cpp, PyTorch, ROCm, CUDA 버전이 바뀌면 같은 GPU에서도 batch 처리, cache, FP8 kernel, multi-GPU 통신 경로가 달라져. “H100에서 된다”와 “내 서버의 드라이버, 컨테이너, 모델, 입력 길이에서 된다”는 꽤 다른 말이야.
세 번째는 전력과 조달이야. Tom’s Hardware는 Bloomberg와 Sightline Climate를 인용해 2026년 미국 데이터센터 증설에서 약 12GW 용량이 온라인 전환될 것으로 예상되지만 active construction은 약 1/3이라고 전했어. 같은 기사에서 고전력 transformer 납기는 2020년 전 24~30개월 수준에서 지금은 최대 5년까지 늘 수 있다고 설명해. GPU를 많이 사도 전력 장비가 늦으면 서버실은 그냥 비싼 창고가 돼.
실무 활용 기준
작게 시작할 때는 “내 작업이 GPU에 맞는가”부터 봐. 이미지 생성, embedding 대량 생성, 긴 문서 추론, batch inference, fine-tuning처럼 같은 연산을 많이 반복하는 작업은 GPU 후보야. 반대로 API 몇 번 호출하고 파일 몇 개 정리하는 자동화, 작은 데이터 전처리, 네트워크 대기가 긴 작업은 CPU나 외부 API가 더 단순할 수 있어.
로컬 LLM에서는 먼저 모델 파일 크기, 목표 컨텍스트 길이, KV cache, 양자화 포맷, 목표 tokens/sec를 적어. 그다음 GPU 메모리가 모자라면 더 작은 모델, 더 낮은 정밀도, CPU offload, multi-GPU 중 하나를 선택해야 해. 무턱대고 큰 GPU를 사기 전에 이 표를 한 번 만드는 편이 덜 아프다.
서비스 운영에서는 p50·p95 지연시간, tokens/sec, GPU utilization, memory usage, 에러율을 같이 봐. 평균 속도만 좋고 p95가 튀면 사용자는 느리다고 느끼고, utilization만 높고 처리량이 안 나오면 kernel이나 batch 전략이 막힌 걸 수 있어. GPU는 비싼 계산기라서, 얼마나 바쁘냐보다 쓸모 있는 일을 얼마나 밀어냈느냐가 진짜 기준이야.