하드웨어 중급 #8 GPU와 가속기 — AI 시대의 다섯 번째 자원

이 시리즈는 줄곧 네 자원(CPU, 메모리, 스토리지, 네트워크)으로 세상을 봤습니다. 그런데 AI 워크로드가 서버실에 들어오면서 다섯 번째 자원이 표준 장비가 됐습니다. GPU입니다. 이번 글은 GPU를 운영자의 눈으로 봅니다. 내부 아키텍처의 깊은 곳이 아니라, GPU 서버를 굴릴 때 마주치는 지표와 병목과 나눠 쓰기의 문제입니다.

GPU는 무엇이 다른가 — 넓고 얕은 일꾼 #

기초 2편의 CPU는 복잡한 일을 빠르게 처리하는 소수의 코어였습니다. GPU는 반대 설계입니다. 단순한 계산만 하는 코어를 수천 개 이상 깔아 놓고, 같은 연산을 거대한 데이터에 동시에 적용합니다. 행렬 곱셈이 정확히 그런 일이고, 딥러닝의 학습과 추론은 본질적으로 거대한 행렬 곱셈의 반복이라서 GPU가 AI의 표준 장비가 된 것입니다.

운영 관점에서 중요한 따름정리가 하나 있습니다. GPU는 혼자 일하지 못합니다. 데이터를 준비해 GPU 메모리로 보내고 결과를 거두는 일은 CPU와 메모리, 스토리지의 몫입니다. 즉 GPU 서버의 병목이 GPU가 아닐 수 있습니다. GPU 사용률이 낮은 학습 서버의 범인이 느린 데이터 로딩(스토리지)이거나 전처리(CPU)인 경우는 흔한 일입니다. 네 자원의 진단법이 GPU 서버에서도 그대로 전제가 됩니다.

VRAM — 새로운 메모리 벽 #

GPU에는 자체 메모리인 VRAM이 붙어 있고, 고성능 GPU는 HBM(High Bandwidth Memory, GPU 패키지에 적층해 대역폭을 극대화한 메모리)을 씁니다. 일반 RAM과의 차이는 용량 대 대역폭의 거래입니다. 수백 GB〜TB 급으로 키우는 시스템 RAM과 달리, VRAM은 수십 GB 수준에 머무는 대신 수 TB/s 의 대역폭을 냅니다. 수천 개의 코어를 굶기지 않으려면 그 대역폭이 필요하기 때문입니다.

이 구조가 AI 운영의 제1 제약을 만듭니다. 모델과 작업 데이터가 VRAM에 들어가느냐입니다. 모델이 VRAM보다 크면 여러 GPU에 나누거나, 정밀도를 낮춰(양자화) 줄여야 합니다. LLM 추론에서는 모델 무게에 더해 동시 요청들의 컨텍스트(KV 캐시)도 VRAM을 먹어서, 동시 사용자 수가 VRAM 용량의 함수가 됩니다. CPU 세계에서 “메모리 부족 → 스왑"이던 문제가, GPU 세계에서는 “VRAM 부족 → 즉시 OOM 에러"라는 더 단호한 형태로 나타납니다.

nvidia-smi — GPU의 점검표 #

GPU 운영의 기본 도구는 nvidia-smi입니다. 1편의 사용률·포화·에러 틀을 그대로 적용해 읽습니다.

+-------------------------------+----------------------+
| GPU  Name        Persistence-M | GPU-Util  Memory-Usage |
|  0   H100 80GB   On            |   92%     71GiB/80GiB  |
| Temp  76C   Pwr  610W / 700W   |                        |
+-------------------------------+----------------------+

• GPU-Util(사용률) — 주의해서 읽어야 하는 지표입니다. “그 순간 커널이 돌고 있었는가"라서, 코어 수천 개 중 일부만 일해도 100%가 나올 수 있습니다. 사용률이 높다고 알차게 쓰는 것은 아니고, 반대로 낮다면 확실히 문제(공급 병목)입니다.
• Memory-Usage(VRAM) — 위에서 본 제1 제약의 게이지입니다. 한도 근처라면 다음 요청 하나가 OOM이 될 수 있습니다.
• Temp / Pwr — 2편의 스로틀링이 GPU에도 똑같이 있습니다. 온도나 전력 한도에 닿으면 클럭이 깎입니다. 고밀도 GPU 서버에서 냉각은 성능 항목입니다.
• 에러 — ECC 에러 카운트와 XID 로그(드라이버가 남기는 GPU 오류 코드)가 하드웨어 이상의 신호입니다.

GPU를 나눠 쓰기 — 패스스루, vGPU, MIG #

GPU는 비싸고, 모든 워크로드가 GPU 하나를 다 쓰지는 않습니다. 그래서 기초 7편의 가상화 질문이 GPU에서 반복됩니다. 한 장을 누구에게, 어떻게 줄 것인가입니다.

MIG(Multi-Instance GPU)가 운영적으로 흥미로운 지점입니다. 연산 유닛과 VRAM, 캐시까지 물리적으로 갈라서, 파티션끼리 2편에서 본 시끄러운 이웃 문제가 구조적으로 없습니다. 큰 GPU 한 장을 작은 추론 GPU 일곱 장처럼 파는 클라우드 상품들이 이 기술 위에 있습니다. 반대로 학습처럼 GPU 전체를 갈아 넣는 일은 패스스루(클라우드라면 GPU 전용 인스턴스)가 기본입니다.

여러 장으로 가면 연결이 또 하나의 자원이 됩니다. GPU 사이를 PCIe보다 훨씬 넓게 잇는 전용 인터커넥트(NVLink 등)와, 서버 사이를 잇는 고속 네트워크(RDMA)가 분산 학습의 성능을 좌우합니다. 4편의 NUMA도 돌아옵니다. GPU가 어느 소켓에 붙었느냐에 따라 CPU〜GPU 데이터 이동 비용이 달라지기 때문입니다.

자주 만나는 함정 #

• GPU-Util 100%를 풀가동으로 읽는다 — 커널이 돌고 있었다는 뜻일 뿐입니다. 처리량(초당 토큰, 스텝 시간)과 함께 읽고, 정밀한 활용도는 프로파일링 도구의 영역입니다.
• GPU만 사고 공급로를 안 본다 — 데이터 로딩, 전처리, 네트워크가 굶기면 비싼 GPU가 놉니다. GPU 사용률이 낮으면 시선을 네 자원으로 돌립니다.
• VRAM을 평균으로 계획한다 — VRAM은 초과의 결과가 즉시 OOM이라 평균이 아니라 최대(동시 요청의 피크)로 잡아야 합니다.

정리 #

이번 글에서 잡은 그림입니다.

• GPU는 단순 코어 수천 개로 같은 연산을 동시에 처리하는 장치이고, 공급(CPU·스토리지·네트워크)이 따라와야 일합니다.
• VRAM이 AI 운영의 제1 제약입니다. 모델과 동시 요청의 피크가 용량 계획의 기준입니다.
• nvidia-smi도 사용률·포화·에러 틀로 읽되, GPU-Util의 의미를 정확히 압니다. 온도와 전력은 스로틀링의 예고입니다.
• 나눠 쓰기는 패스스루, vGPU, MIG의 스펙트럼이고, 격리 수준과 용도가 선택 기준입니다.

다음 — 실전 진단 워크스루 #

부품은 모두 모였습니다. 마지막 글인 “하드웨어 중급 #9 실전: 느려진 서버 진단하기"에서는 시리즈 전체를 하나의 사건에 적용합니다. “서비스가 느려요"라는 신고에서 출발해 네 자원을 좁혀 가며 원인을 찾고 처방을 검증하는, 운영 현장의 진단 과정을 처음부터 끝까지 따라갑니다.