GPU 탑재 VPS가 꼭 필요한가요? CPU와 성능 비교

GPU가 탑재된 VPS가 필요한가요, 아니면 CPU만으로 충분한가요?

GPU가 있는 VPS를 사용하면 모델을 직접 실행할 때 토큰 생성 속도와 모델을 메모리에 올릴 수 있는지 여부, 이 두 가지만 달라집니다. 그 외에는 아무것도 변하지 않습니다. 한 번에 한 명의 사용자가 응답을 받는 7B에서 27B 크기의 양자화된 챗봇 모델, 소규모 임베딩 작업, 또는 Whisper small을 이용한 음성 변환 작업이라면 충분한 RAM을 갖춘 일반 CPU VPS로도 충분히 수행할 수 있습니다. 먼저 CPU에서 시작하여 불편함을 느끼는 수치를 측정한 뒤, 필요할 때 사양을 높이십시오.

이유는 메모리 대역폭 때문입니다. 언어 모델은 토큰 하나를 생성할 때마다 필요한 모든 가중치를 메모리에서 읽어옵니다. 4비트로 양자화된 8B 모델은 디스크에서 약 4.9 GB를 차지하며 메모리에서도 비슷한 용량을 사용하므로, 토큰 하나를 생성하려면 약 4.9 GB의 데이터를 이동해야 합니다. 기기의 메모리 대역폭을 이 수치로 나누면 초당 생성 가능한 최대 토큰 수가 나옵니다. 이 단순한 나눗셈 하나로 여러분이 접하는 거의 모든 벤치마크 결과를 설명할 수 있습니다.

GPU가 실제로 제공하는 것

대역폭. 최신 호스트의 서버 DDR5는 초당 수십 기가바이트를 전송한다. GPU 메모리(VRAM, video RAM)는 수백 기가바이트에서 1TB 이상을 전송한다. 이 비율이 속도 향상으로 이어지며, 그 차이는 크다.

속도를 갖춘 용량. RAM이 64 GB인 CPU 장비는 4비트 방식으로 70B 모델을 로드할 수 있다. 실행은 되지만 대화보다는 읽기에 가까운 속도다. 이 경우 GPU가 도움이 되려면 모델이 VRAM에 들어가야 한다. 레이어가 system RAM으로 넘어가는 순간 느린 경로가 다시 전체 속도를 좌우하기 때문이다.

배치 처리량. 많은 사람이 이 부분을 과소평가한다. GPU가 한 사용자에게만 생성 작업을 수행하면 메모리를 기다리느라 대부분의 연산 능력이 유휴 상태가 된다. 20개의 요청을 동시에 처리하면 동일한 weight 읽기 결과를 20개 요청이 함께 사용한다. 전체 초당 토큰 수는 몇 배까지 증가하지만 사용자별 속도는 거의 떨어지지 않는다. llama.cpp 같은 CPU 추론 엔진도 batching을 지원하며, 향상 폭은 하드웨어와 workload에 따라 달라진다. 많은 클라이언트가 호출하는 API를 구축한다면 GPU를 선택하는 근거는 단일 스트림의 원시 속도보다 batching에 있다.

프롬프트 처리. 긴 프롬프트를 읽는 작업은 memory-bound가 아니라 compute-bound이며, 이 지점에서 GPU의 우위가 가장 크다. CPU가 1분 동안 처리하는 30,000 token context를 GPU는 몇 초 만에 처리한다. 모든 요청에 문서를 넣는 retrieval 구성에서는 이 차이를 계속 체감하게 된다.

대략적인 수치와 해석 방법

실제 처리량은 대역폭을 모델 크기로 나눈 값보다 낮다. 컨텍스트가 길어질수록 attention 계산에 추가 작업이 필요하기 때문이다. 단순한 나눗셈으로는 이 작업량을 반영할 수 없다.

비교하면 성인의 영어 묵독 속도는 초당 약 4.0~4.3단어다. 논픽션은 분당 238단어이고, 픽션은 분당 260단어다. 초당 15토큰 이상이면 한 명의 독자가 일반적인 타이핑 속도로 느낄 정도다. 그래서 CPU만 사용하는 구성이 조용히 충분한 경우가 많다.

구매 전 VRAM 용량 산정하기

모델 파일 크기는 최소 사양일 뿐, 실제 요구 사양은 아닙니다. 모델 가중치(weights)에 KV 캐시(key-value cache, 어텐션이 유지하는 토큰별 메모리)를 더하고, 약 1 GB의 오버헤드를 추가하여 예산을 잡아야 합니다.

단순히 일정 비율을 더하는 대신 캐시 용량을 직접 계산하십시오. 가중치를 양자화하더라도 캐시는 양자화되지 않기 때문입니다. 풀 어텐션(full-attention) 모델은 각 토큰마다 모든 레이어와 모든 KV 헤드에 대해 키와 값을 저장하며, Ollama의 기본 캐시 타입인 FP16 기준 숫자당 2바이트를 사용합니다. 2026-10-27에 확인한 Ollama 모델 메타데이터에 따르면 Llama 3.1 8B는 32개 레이어와 128 차원의 KV 헤드 8개를 가지며, 이는 토큰당 128 KiB로 계산됩니다. 즉, 8k 컨텍스트에서는 약 1.07 GB, 16k에서는 약 2.15 GB가 필요합니다. 따라서 4.9 GB인 8B 모델은 8k에서 약 7 GB, 16k에서 약 8 GB의 VRAM을 요구합니다. 4비트 27B 모델은 약 17 GB입니다(Ollama 라이브러리의 Gemma 3 27B). Gemma 3 메타데이터는 1,024 토큰 슬라이딩 윈도우를 명시하고 있어 캐시 증가가 제한적이므로 20 GB 이상을 계획하십시오. 4비트 70B 모델은 약 43 GB입니다(Llama 3.3 70B). 80개 레이어를 가진 이 모델의 FP16 캐시는 8k에서 약 2.7 GB, 16k에서 약 5.4 GB를 추가하므로, 여유가 거의 없는 48 GB 카드 한 장이나 더 작은 카드 두 장이 필요합니다. 이 계산 방식은 그 이상의 모델에도 동일하게 적용되며, Kimi K3와 같은 2.8조 파라미터 모델의 VRAM 계산을 보면 왜 카드 선택이 더 이상 중요한 문제가 아닌지 알 수 있습니다.

긴 컨텍스트를 사용할 때 이 문제가 가장 중요해집니다. Llama 3.1과 같은 풀 어텐션 모델에서 KV 캐시는 컨텍스트 길이에 비례하여 증가하며, 128k 토큰에서는 가중치 자체보다 커질 수 있습니다. 슬라이딩 윈도우나 청크 어텐션(chunked attention)을 사용하는 모델은 다릅니다. Hugging Face의 Transformers 문서에 따르면 Mistral, Gemma 2, Llama 4와 같은 모델은 해당 레이어의 캐시가 윈도우나 청크 크기에 도달하면 더 이상 증가하지 않으므로 전체 용량 증가 속도가 느립니다. 긴 컨텍스트를 사용할 계획이라면 캐시 용량을 우선적으로 고려하고, 사용 중인 엔진이 캐시 양자화를 지원하는지 확인하십시오. Ollama에서 OLLAMA_KV_CACHE_TYPE=q8_0는 기본값인 f16보다 메모리를 절반 정도 사용하며, 캐시 양자화는 Flash Attention이 활성화된 경우에만 적용됩니다. 컨텍스트 길이도 명시적으로 설정하십시오. Ollama는 VRAM을 기준으로 기본값을 선택합니다. 24 GiB 미만은 4k, 24~48 GiB는 32k, 48 GiB 이상은 256k입니다. 48 GB 카드에서 70B 모델을 실행할 때 이 기본값은 카드 용량을 훨씬 초과하는 캐시를 요구하게 됩니다.

실제로 시스템에 설치된 항목 확인

GPU 인스턴스에서는 다른 작업을 수행하기 전에 드라이버가 GPU를 인식하는지 확인합니다.

nvidia-smi

GPU 이름, 드라이버 버전, 전체 메모리 중 사용 중인 메모리를 표시하는 표가 출력되어야 합니다. NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver가 출력되면 NVIDIA-SMI가 드라이버에 연결할 수 없다는 뜻입니다. 드라이버가 설치되어 있고 커널 모듈이 로드되었는지 확인합니다. 기본 Ubuntu 이미지에서는 일반적으로 sudo apt install -y ubuntu-drivers-common && sudo ubuntu-drivers install를 실행한 다음 재부팅해야 새 모듈이 로드됩니다. 컴퓨팅 머신의 경우 Ubuntu 서버 문서에서는 서버 드라이버 브랜치를 선택하는 sudo ubuntu-drivers install --gpgpu를 권장합니다.

컨테이너에서는 드라이버만으로 충분하지 않습니다. Docker가 GPU 장치를 전달하려면 NVIDIA Container Toolkit이 필요합니다.

sudo apt-get update && sudo apt-get install -y --no-install-recommends ca-certificates curl gnupg2
curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg
curl -s -L https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list | sed 's#deb https://#deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g' | sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list
sudo apt-get update && sudo apt-get install -y nvidia-container-toolkit
sudo nvidia-ctk runtime configure --runtime=docker
sudo systemctl restart docker

그런 다음 컨테이너 내부에서 장치 전달이 작동하는지 확인합니다.

sudo docker run --rm --gpus all ubuntu:24.04 nvidia-smi

같은 표가 출력되어야 합니다. 충족할 수 없는 GPU 기능을 지정하는 docker: Error response from daemon: could not select device driver 행이 출력되면 Docker가 요청에 맞는 장치 드라이버를 찾지 못했다는 뜻입니다. toolkit이 설치되어 있는지 확인한 다음 nvidia-ctk 행과 restart를 다시 실행합니다. Compose에서는 driver가 nvidia이고 capabilities 목록에 gpu이 포함된 deploy.resources.reservations.devices 항목이 이에 해당합니다. 이 항목은 VPS에서 Docker Compose 사용에서 설명한 일반적인 service 정의에 넣을 수 있습니다.

업그레이드 전 성능 측정

실제로 사용할 모델을 현재 보유한 CPU 서버에서 실행하고 수치를 기록하십시오. Ollama를 활용한 VPS에서의 LLM 셀프 호스팅 가이드에 따라 다음 플래그 하나만 추가하면 됩니다.

ollama run llama3.1:8b --verbose "Summarise the causes of the 1929 crash in 200 words."

출력 결과의 마지막 부분에 시간이 표시됩니다. eval rate는 초당 토큰 생성 속도를 나타냅니다. prompt eval rate는 기계가 입력값을 읽는 속도입니다. 이 두 수치를 통해 어떤 업그레이드가 필요한지 알 수 있습니다. eval rate이 낮으면 메모리 대역폭 문제이며, 긴 입력값에서 prompt eval rate이 낮으면 연산 능력 문제입니다.

GPU가 장착된 기기라면 모델이 실제로 GPU에 로드되었는지 확인하십시오.

ollama ps

PROCESSOR 열의 값이 100% GPU이면 모든 데이터가 GPU에 적재된 것이며, 그렇지 않은 경우 43%/57% CPU/GPU과 같은 값이 표시됩니다. 일부만 분할되어 로드되는 상황은 예상보다 성능 저하가 심합니다. 모든 토큰이 느린 쪽의 처리를 기다려야 하기 때문입니다.

비용 문제

GPU 인스턴스는 토큰이 아니라 프로비저닝된 컴퓨팅 시간에 따라 과금되며, 요금과 중지된 인스턴스의 과금 여부는 제공업체가 정한다. 하루에 몇 건의 요청만 처리하는 GPU를 항상 켜 두면 유료 시간 대부분을 유휴 상태로 보내게 된다. 손익분기점은 사용률이다. 사용량이 많은 GPU는 토큰당 비용이 낮지만, 유휴 GPU는 비용만 발생한다.

현실적으로 효과적인 방식은 3가지다. 지속적으로 발생하는 소량의 작업은 CPU VPS에서 처리한다. 가끔 발생하는 복잡한 요청은 호스팅 API로 보내고 토큰 단위로 비용을 지불한다. 배치 작업, fine-tuning 또는 대량 embedding 작업에는 GPU를 시간 단위로 임대한 다음 작업이 끝나면 삭제한다. 이 방식을 조합해도 된다. 항상 실행 중인 VPS에서 AI 에이전트 비용 관리에서 설명한 예산 관리 원칙도 여기에 적용된다. 다만 여기서는 토큰 수가 아니라 유휴 시간이 비용 누수의 원인이다.

GPU 없이도 원활하게 작동하는 작업

소량의 임베딩 작업. 소형 임베딩 모델은 몇 개의 CPU 코어만으로도 분당 수백 개의 짧은 문서를 처리할 수 있으며, 한 번 구축한 인덱스는 빠른 속도가 필요하지 않습니다.

전사(transcription)를 위한 Whisper small 및 base 모델. CPU 환경의 Faster-whisper는 small 모델을 사용하여 실시간에 가까운 속도로 전사할 수 있으며, 이는 야간에 실행되는 파이프라인에 충분한 성능입니다.

최대 약 27B 규모의 양자화된 채팅 모델(사용자 1~2명 기준). 속도는 느리지만 내용을 읽을 수 있고 사용 가능한 수준입니다.

배치 작업으로 분류할 수 있는 모든 것. 화면을 지켜보는 사용자가 없다면, 실제 처리 시간(wall-clock speed)은 요구 사항이라기보다 스케줄링의 세부 사항에 불과합니다.

GPU가 반드시 필요한 작업: 소형 어댑터 범위를 넘어서는 학습이나 파인튜닝, 다수의 동시 사용자 서비스, 이미지 및 비디오 생성, 그리고 지연 시간이 곧 제품의 품질인 실시간 음성 처리 등이 있습니다.

FAQ

7B 또는 8B 모델에 필요한 VRAM 용량은 얼마입니까?

8k context에서 4-bit 양자화한 8B 모델을 실행하려면 약 7 GB가 필요하고, 16k에서는 약 8 GB가 필요합니다. Ollama의 기본 FP16 cache를 사용하는 경우입니다. 가중치는 약 4.9 GB이고, KV cache가 8k에서 약 1.07 GB, 16k에서 약 2.15 GB를 추가합니다. 나머지는 약 1 GB의 overhead입니다. 8 GB GPU는 8k에서 모델을 수용하지만 16k에서는 여유가 거의 없습니다. 12 GB GPU는 더 긴 context를 사용할 수 있는 충분한 여유를 제공합니다. cache를 q8_0으로 변경하면 cache가 차지하는 용량을 대략 절반으로 줄일 수 있습니다. 128k context로 실행할 계획이라면 cache 용량을 별도로 계산해야 합니다. cache가 가중치보다 커질 수 있기 때문입니다.

GPU 없이 Ollama를 실행할 수 있습니까?

가능합니다. Ollama는 자동으로 CPU를 사용하며, 모델을 저장할 수 있을 만큼의 RAM만 필요합니다. 4-bit 8B 모델은 memory speed에 따라 초당 약 5~12 tokens를 처리합니다. 이는 사용자 1명의 읽기 속도에 가깝습니다. CPU에서 실제 문제가 되는 부분은 긴 prompt입니다. 30,000 tokens의 context를 읽는 작업은 compute-bound이므로 응답을 생성하는 것보다 훨씬 오래 걸립니다.

GPU가 CPU보다 거의 빠르지 않은 이유는 무엇입니까?

일반적인 원인은 모델 전체가 VRAM에 들어가지 않아 일부 layer가 CPU에서 실행되는 것입니다. 그러면 모든 token이 느린 쪽의 처리를 기다립니다. ollama ps를 실행하고 PROCESSOR 열에 100% GPU가 표시되는지 확인합니다. 분할 실행이 표시되면 더 작은 quantization 또는 더 작은 모델을 사용합니다. 또 다른 일반적인 원인은 짧은 benchmark입니다. 이 경우 측정 시간의 대부분을 모델 load time이 차지합니다.

단일 사용자에게 GPU VPS를 사용하는 것이 가치가 있습니까?

대체로 그렇지 않습니다. 영어를 사용하는 성인의 조용한 읽기 속도는 평균 초당 약 4.0~4.3 words입니다. CPU 장비의 처리 속도를 이 속도와 비교하려면 tokens per second를 words per second로 변환해야 합니다. 단일 사용자가 비용을 정당화할 수 있는 경우는 긴 prompt, image generation, fine-tuning입니다. 여러 사용자를 동시에 처리하는 경우에는 GPU 1대가 여러 request에서 weight read를 공유할 수 있으므로 batching이 가능해집니다. 이것이 GPU를 사용하는 가장 강력한 이유입니다.

GPU를 시간 단위로 대여해야 합니까, 아니면 항상 켜 두어야 합니까?

작업이 bursty하다면 시간 단위로 대여합니다. fine-tuning, 대량 embedding 실행, batch transcription 작업이 이에 해당합니다. GPU가 계속 사용될 때만 항상 켜 둡니다. provisioned GPU compute는 생성한 token 수가 아니라 사용 시간에 따라 과금되기 때문입니다. traffic이 적은 assistant는 유휴 GPU보다 CPU VPS를 사용하거나 token 단위로 과금되는 hosted API를 사용하는 편이 저렴합니다.