GPU VPS가 필요한 경우와 CPU로 충분한 경우

GPU가 있는 VPS가 필요합니까, 아니면 CPU로 충분합니까?

GPU가 있는 VPS는 모델을 직접 실행할 때 2가지만 바꿉니다. 토큰이 생성되는 속도와 메모리에 모델이 들어가는지 여부입니다. 그 외에는 아무것도 바꾸지 않습니다. 양자화된 7B~27B 채팅 모델로 한 번에 1명에게 응답하거나, 낮은 처리량으로 임베딩 작업을 수행하거나, Whisper small로 음성을 전사하는 작업이라면 RAM이 충분한 일반 CPU VPS로도 이미 처리할 수 있습니다. CPU에서 시작하고, 불편하게 느껴지는 수치를 측정한 다음, 필요하면 상위 구성으로 전환합니다.

그 이유는 메모리 대역폭입니다. 언어 모델이 토큰 1개를 생성할 때 필요한 모든 가중치를 메모리에서 읽습니다. 4비트로 양자화된 8B 모델은 디스크에서 대략 4.7 GB이며 메모리에서도 거의 같은 크기입니다. 따라서 토큰 1개를 생성하려면 약 4.7 GB를 이동해야 합니다. 시스템의 메모리 대역폭을 이 수치로 나누면 초당 토큰 수의 상한을 구할 수 있습니다. 이 단일 계산으로 확인하게 될 벤치마크의 거의 전부를 설명할 수 있습니다.

GPU가 실제로 제공하는 것

대역폭. 최신 호스트의 서버 DDR5는 초당 수십 기가바이트를 처리합니다. GPU 메모리(VRAM, video RAM)는 수백 기가바이트에서 1,000기가바이트 이상을 처리합니다. 이 비율이 성능 향상 폭이며, 그 차이는 큽니다.

속도를 갖춘 용량. 64 GB RAM을 갖춘 CPU 시스템은 4비트로 70B 모델을 로드할 수 있습니다. 실행은 되지만, 대화라기보다 읽기에 가까운 속도입니다. 여기서 GPU가 도움이 되려면 모델이 VRAM에 들어가야 합니다. 레이어가 system RAM으로 넘어가는 순간 느린 경로가 다시 성능을 좌우하기 때문입니다.

배치 처리량. 많은 사람이 이 부분을 과소평가합니다. GPU가 한 사용자에게만 생성 작업을 수행하면 메모리를 기다리느라 대부분의 연산 장치가 유휴 상태가 됩니다. 한 번에 20개의 요청을 처리하면 동일한 가중치 읽기 작업을 20개 요청이 함께 사용합니다. 사용자별 속도는 거의 떨어지지 않으면서 전체 초당 토큰 수는 여러 배 증가합니다. CPU는 이렇게 동작하지 않습니다. CPU 시스템에서 동시 사용자 2명은 서로의 처리 속도를 대략 절반으로 낮춥니다. 여러 클라이언트가 호출하는 API를 구축한다면, GPU를 선택해야 하는 이유는 단일 스트림의 원시 속도보다 배치 처리입니다.

프롬프트 처리. 긴 프롬프트를 읽는 작업은 메모리 제한이 아니라 연산 제한을 받으며, GPU가 가장 큰 폭으로 우위를 보이는 부분입니다. CPU가 1분 동안 처리하는 30,000 토큰 컨텍스트를 GPU는 몇 초 만에 처리합니다. 모든 요청에 문서를 삽입하는 검색 기반 구성에서는 이 차이를 계속 체감하게 됩니다.

대략적인 수치와 해석 방법

아래 블록에는 2026년 7월 기준으로 4-bit 양자화를 적용한 8B 모델의 일반적인 단일 스트림 수치가 제시되어 있습니다. 이는 대략적인 규모를 판단하기 위한 지침이며, 보장된 값은 아닙니다. 양자화 방식, context length 및 inference engine에 따라 수치가 달라집니다.

[
  {
    "label": "8 vCPU, DDR4",
    "mem_bandwidth_gbs": 40,
    "tokens_per_sec": 6
  },
  {
    "label": "16 vCPU, DDR5",
    "mem_bandwidth_gbs": 75,
    "tokens_per_sec": 11
  },
  {
    "label": "24GB GPU",
    "mem_bandwidth_gbs": 300,
    "tokens_per_sec": 50
  },
  {
    "label": "40GB data-centre GPU",
    "mem_bandwidth_gbs": 1555,
    "tokens_per_sec": 130
  }
]

24 GB GPU 행은 초당 50 tokens를 처리합니다. DDR5 CPU 시스템은 초당 11 tokens를 처리합니다. 이는 대략 5배 차이이며, 원시 연산 성능의 차이보다는 bandwidth 비율과 일치합니다. 실제 처리량은 bandwidth를 모델 크기로 나눈 값보다도 낮습니다. context가 증가하면 attention에 추가 작업이 필요하지만, 단순한 나눗셈에는 이 작업이 반영되지 않기 때문입니다.

비교를 위해 사람은 초당 약 5~10개의 단어를 읽습니다. 초당 15 tokens 이상이면 한 명의 독자에게 이미 일반적인 타이핑 속도처럼 느껴집니다. 따라서 CPU만 사용하는 많은 구성도 실제로는 충분히 사용할 수 있습니다.

구매 전 VRAM 용량 산정

모델 파일 크기는 최저 기준일 뿐, 실제 요구 사항이 아닙니다. 가중치와 KV cache(key-value cache, attention이 유지하는 토큰별 메모리), 그리고 약 1 GB의 오버헤드를 모두 고려해야 합니다.

2026년 7월 기준으로 사용할 수 있는 실용적인 규칙은 다음과 같습니다. 일반적인 8k~16k context에서는 모델 파일 크기를 GB 단위로 계산한 뒤 20 percent를 추가합니다. 4.7 GB 8B 모델에는 약 6 GB의 VRAM이 필요합니다. 4 bits의 27B 모델은 약 16 GB이며, 대략 20 GB가 필요합니다. 4 bits의 70B 모델은 약 40 GB이므로 48 GB 카드 1개 또는 더 작은 카드 2개가 필요합니다.

긴 context에서는 이 규칙이 맞지 않습니다. KV cache는 context length에 따라 선형으로 증가하며, 128k tokens에서는 가중치 자체보다 커질 수 있습니다. 긴 context를 사용할 계획이라면 먼저 cache 용량을 기준으로 산정하고, 사용하는 engine이 cache quantization을 지원하는지 확인해야 합니다.

시스템에 실제로 있는 항목 확인

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

nvidia-smi

GPU 이름, 드라이버 버전, 전체 메모리 중 사용 중인 메모리를 표시하는 표가 출력되어야 합니다. NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver가 출력되면 드라이버가 없거나, 커널 업그레이드 후 커널 모듈이 다시 빌드되지 않은 것입니다. 기본 Ubuntu 이미지에서는 일반적으로 sudo apt install -y ubuntu-drivers-common && sudo ubuntu-drivers install를 실행한 다음 재부팅해야 합니다. 그러면 새 모듈이 로드됩니다.

컨테이너에서는 드라이버만으로 충분하지 않습니다. Docker가 장치를 전달하려면 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 행이 표시되면 Toolkit은 설치되었지만 Docker를 다시 구성하거나 재시작하지 않은 것입니다. nvidia-ctk 행과 재시작을 다시 실행합니다. Compose에서는 이에 해당하는 설정이 deploy.resources.reservations.devices 항목입니다. 이 항목의 driver은 nvidia이고, capabilities 목록에는 gpu이 포함됩니다. 이 설정은 VPS에서 Docker Compose에서 설명한 일반적인 service 정의에 추가할 수 있습니다.

업그레이드하기 전에 측정합니다

실제로 사용하려는 모델을 현재 보유한 CPU 장비에서 실행하고 수치를 기록합니다. VPS에서 Ollama로 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

모든 모델이 GPU 메모리에 들어가면 PROCESSOR 열에 100% GPU가 표시됩니다. 들어가지 않으면 43%/57% CPU/GPU과 같은 값이 표시됩니다. 모델이 일부만 분할되면 예상보다 성능이 크게 떨어지는 경우가 많습니다. 모든 토큰이 여전히 느린 쪽의 처리를 기다려야 하기 때문입니다.

비용 문제

GPU 인스턴스는 비슷한 성능의 CPU 인스턴스보다 몇 배 더 비쌉니다. 또한 생성하는 토큰 수가 아니라 인스턴스가 존재한 모든 시간에 대해 요금을 부과합니다. 하루에 몇 건의 요청만 처리하는 상시 실행 GPU는 추론을 실행하는 가장 비싼 방법입니다. 손익분기점은 사용률입니다. 사용률이 높은 GPU는 토큰당 비용이 낮고, 유휴 GPU는 비용만 낭비합니다.

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

GPU 없이도 정상적으로 실행되는 작업

낮은 처리량의 임베딩 작업입니다. 소형 임베딩 모델은 몇 개의 CPU 코어만으로도 분당 수백 개의 짧은 문서를 처리합니다. 한 번 생성한 인덱스는 빠르게 처리할 필요가 없습니다.

전사를 위한 Whisper small 및 base 모델입니다. CPU에서 실행하는 faster-whisper는 small 모델을 거의 실시간으로 전사합니다. 따라서 밤새 실행하는 파이프라인에 충분합니다.

1~2명의 사용자를 대상으로 하는 약 27B 이하의 양자화된 채팅 모델입니다. 속도는 느리지만 읽을 수 있고 사용할 수 있습니다.

일괄 작업이라고 할 수 있는 모든 작업입니다. 화면을 지켜보는 사람이 없다면 실제 경과 시간은 필수 조건이 아니라 일정 관리상의 세부 사항입니다.

실제로 GPU가 필요한 작업은 소형 adapter를 넘어서는 학습 또는 fine-tuning, 다수의 동시 사용자에 대한 서비스 제공, 이미지 및 동영상 생성, 그리고 지연 시간이 제품의 핵심인 실시간 음성 처리입니다.

FAQ

7B 또는 8B 모델에 필요한 VRAM은 얼마나 됩니까?

일반적인 8k~16k 컨텍스트에서 4-bit 양자화 8B 모델을 실행하려면 약 6 GB가 필요합니다. 가중치는 약 4.7 GB이고, 나머지는 KV cache와 약 1 GB의 오버헤드가 차지합니다. 12 GB 카드라면 더 긴 컨텍스트를 사용할 여유가 충분합니다. 128k 컨텍스트로 실행할 계획이라면 cache 용량을 별도로 계산해야 합니다. cache가 가중치보다 커질 수 있기 때문입니다.

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

가능합니다. Ollama는 자동으로 CPU를 사용하며, 모델을 저장할 수 있는 충분한 RAM만 필요합니다. 메모리 속도에 따라 4-bit 8B 모델에서 초당 약 5~12 tokens가 나옵니다. 이는 사용자 1명 기준으로 읽는 속도에 가깝습니다. CPU에서는 긴 프롬프트가 가장 큰 문제입니다. 30,000 tokens의 컨텍스트를 읽는 작업은 계산 집약적이며, 응답을 생성하는 것보다 훨씬 오래 걸립니다.

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

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

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

대체로 그렇지 않습니다. 한 사람은 초당 5~10단어를 읽으며, CPU 서버도 약 13B 이하의 모델에서는 이보다 빠르게 token을 생성합니다. 단일 사용자에게 비용을 정당화할 수 있는 경우는 긴 프롬프트, image generation, fine-tuning입니다. 여러 사용자를 동시에 처리해야 하는 경우가 가장 강력한 근거입니다. batching을 사용하면 GPU 1개로 1건을 처리하는 비용에 가깝게 20건의 요청에 응답할 수 있기 때문입니다.

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

작업이 간헐적으로 발생한다면 시간 단위로 대여합니다. 예를 들어 fine-tuning, 대량 embedding 작업 또는 batch transcription 작업이 이에 해당합니다. GPU instance는 생성한 token이 아니라 인스턴스가 실행 중인 시간에 대해 비용을 청구하므로, GPU 사용률이 계속 높을 때만 항상 실행합니다. 트래픽이 적은 assistant는 유휴 GPU보다 CPU VPS 또는 token 단위로 결제하는 hosted API를 사용하는 편이 저렴합니다.