작성자 GPU 탑재 VPS가 꼭 필요한 상황과 판단 기준
GPU VPS는 배치 처리량과 대규모 모델 구동에 유리합니다. 7B-27B 양자화 모델이나 Whisper 작업은 CPU 서버로도 충분합니다. 먼저 CPU에서 성능을 측정하고 병목 현상이 발생할 때 GPU 업그레이드를 고려하십시오.
GPU가 탑재된 VPS가 필요한가요, 아니면 CPU만으로 충분한가요?
GPU가 탑재된 VPS를 사용하면 모델을 직접 실행할 때 토큰 생성 속도와 모델을 메모리에 올릴 수 있는 최대 크기, 이 두 가지가 달라집니다. 그 외에는 아무것도 변하지 않습니다. 만약 한 번에 한 명의 사용자가 질문하는 7B에서 27B 규모의 양자화된 챗 모델을 운영하거나, 저용량 임베딩 작업, 혹은 Whisper small을 이용한 음성 전사 작업을 수행한다면 충분한 RAM을 갖춘 일반적인 CPU VPS로도 충분히 업무를 처리할 수 있습니다. 먼저 CPU에서 시작하여 성능 수치를 측정해 보고, 만족스럽지 않을 때 업그레이드하십시오.
그 이유는 메모리 대역폭 때문입니다. 언어 모델이 토큰 하나를 생성할 때마다 필요한 모든 가중치를 메모리에서 읽어옵니다. 4비트로 양자화된 8B 모델은 디스크에서 약 4.7 GB를 차지하며 메모리에서도 비슷한 용량을 점유합니다. 즉, 토큰 하나를 생성하려면 약 4.7 GB의 데이터를 이동시켜야 합니다. 기기의 메모리 대역폭을 이 수치로 나누면 초당 생성 가능한 토큰 수의 상한선이 나옵니다. 이 단순한 나눗셈 하나로 여러분이 접하게 될 거의 모든 벤치마크 결과를 설명할 수 있습니다.
GPU가 실제로 제공하는 이점
대역폭. 최신 호스트의 서버용 DDR5는 초당 수십 기가바이트를 전송합니다. GPU 메모리(VRAM)는 수백에서 1,000 기가바이트 이상을 전송합니다. 이 비율이 곧 속도 향상이며, 그 차이는 매우 큽니다.
속도와 용량. 64 GB RAM을 탑재한 CPU 서버는 4비트 양자화된 70B 모델을 로드할 수 있습니다. 모델이 실행은 되겠지만, 대화보다는 독서에 가까운 속도로 동작할 것입니다. GPU는 모델이 VRAM 안에 들어갈 때만 도움이 됩니다. 레이어가 시스템 RAM으로 넘어가는 순간 다시 느린 경로가 주도권을 잡기 때문입니다.
배치 처리량. 사람들이 가장 과소평가하는 부분입니다. 한 명의 사용자를 위해 생성 작업을 수행하는 GPU는 메모리를 기다리느라 대부분의 연산 자원을 유휴 상태로 둡니다. 20개의 요청을 동시에 처리하면, 한 번 읽어 들인 가중치로 20개 요청 모두를 처리할 수 있습니다. 사용자당 속도는 거의 떨어지지 않으면서 초당 총 토큰 처리량은 몇 배로 증가합니다. CPU는 이런 방식이 불가능합니다. CPU 서버에서 두 명의 사용자가 동시에 접속하면 각자의 속도는 대략 절반으로 줄어듭니다. 다수의 클라이언트가 호출하는 API를 구축한다면, 단순한 단일 스트림 속도보다 배치 처리가 GPU를 도입해야 하는 결정적인 이유가 됩니다.
프롬프트 처리. 긴 프롬프트를 읽는 작업은 메모리 제한이 아닌 연산 제한 작업이며, GPU가 가장 압도적인 성능을 보이는 영역입니다. CPU가 1분 동안 처리해야 하는 30,000 토큰 분량의 컨텍스트를 GPU는 몇 초 만에 끝냅니다. 모든 요청에 문서를 삽입하는 검색 증강 생성(Retrieval) 환경에서는 이 차이를 지속적으로 체감하게 됩니다.
대략적인 수치와 해석 방법
아래 블록은 2026년 7월 기준, 4-bit 양자화된 8B 모델의 일반적인 단일 스트림 처리 성능을 나타냅니다. 이 수치는 보장된 성능이 아닌 자릿수 단위의 지침입니다. 양자화 방식, 컨텍스트 길이, 추론 엔진에 따라 수치는 달라질 수 있습니다.
The data behind this chart
[
{
"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 per second를 보여주며, DDR5 CPU 박스의 11와 대비됩니다. 이는 대략 5배 차이로, 순수 연산 능력의 차이보다는 대역폭 비율을 반영합니다. 실제 처리량은 모델 크기로 대역폭을 나눈 값보다 낮게 나타납니다. 이는 단순 나눗셈으로는 계산되지 않는, 컨텍스트가 늘어남에 따라 증가하는 어텐션(attention) 연산 부하 때문입니다.
비교하자면, 사람은 초당 약 5에서 10 단어를 읽습니다. 초당 15 토큰 이상의 속도라면 단일 사용자에게는 일반적인 타이핑 속도와 비슷하게 느껴집니다. 많은 CPU 전용 환경이 별다른 문제 없이 원활하게 작동하는 이유가 바로 여기에 있습니다.
구매 전 VRAM 용량 산정
모델 파일 크기는 최소 사양일 뿐, 실제 요구 사양은 아닙니다. 가중치 크기에 KV 캐시(key-value cache, 어텐션 메커니즘이 토큰별로 유지하는 메모리)와 약 1 GB의 오버헤드를 더해 예산을 책정해야 합니다.
2026년 7월 기준 실무적인 규칙은 다음과 같습니다. 모델 파일 크기(GB 단위)에 20%를 더하면 일반적인 8k~16k 컨텍스트를 처리할 수 있습니다. 4.7 GB 크기의 8B 모델은 약 6 GB의 VRAM이 필요합니다. 4비트 양자화된 27B 모델은 약 16 GB이므로 대략 20 GB의 VRAM이 필요합니다. 4비트 70B 모델은 약 40 GB이므로 48 GB 카드 한 장이나, 더 작은 카드 두 장이 필요합니다. 이 계산법은 그 이상의 규모에서도 유효하며, Kimi K3와 같은 2.8조 파라미터 모델을 위한 VRAM 계산을 보면 단순히 그래픽 카드 선택의 문제를 넘어선다는 점을 알 수 있습니다.
긴 컨텍스트를 사용하면 이 규칙은 적용되지 않습니다. KV 캐시는 컨텍스트 길이에 비례하여 증가하며, 128k 토큰 수준에서는 가중치 자체보다 더 많은 메모리를 차지할 수 있습니다. 긴 컨텍스트를 사용할 계획이라면 캐시 용량을 우선적으로 고려하고, 사용하는 엔진이 캐시 양자화를 지원하는지 확인하십시오.
시스템의 실제 상태 확인
GPU 인스턴스에서는 다른 작업을 수행하기 전에 드라이버가 카드를 인식하는지 먼저 확인해야 합니다.
nvidia-smiGPU 이름, 드라이버 버전, 전체 메모리 대비 사용량을 보여주는 표가 출력되어야 합니다. 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다음으로 컨테이너 내부에서 장치 전달(passthrough)이 정상적으로 작동하는지 확인합니다.
sudo docker run --rm --gpus all ubuntu:24.04 nvidia-smi동일한 표가 출력되어야 합니다. 특정 GPU 기능을 만족할 수 없다는 docker: Error response from daemon: could not select device driver 메시지가 나타난다면, 툴킷은 설치되었으나 Docker가 재설정되거나 재시작되지 않은 상태입니다. nvidia-ctk 명령을 다시 실행하고 Docker를 재시작하십시오. Compose에서는 deploy.resources.reservations.devices 항목을 추가하여 해결합니다. 이때 driver은 nvidia로 설정하고, 기능 목록(capabilities)에 gpu을 포함해야 합니다. 이는 Docker Compose on a VPS에서 다루는 일반적인 서비스 정의 방식과 동일하게 적용됩니다.
업그레이드 전 성능 측정
실제로 사용할 모델을 현재 보유한 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 psPROCESSOR 열의 값이 100% GPU이면 모든 데이터가 GPU에 적재된 것이며, 그렇지 않은 경우 43%/57% CPU/GPU과 같은 값이 표시됩니다. 일부만 분할되어 로드되는 상황은 예상보다 성능 저하가 심합니다. 모든 토큰이 느린 쪽의 처리를 기다려야 하기 때문입니다.
비용 문제
GPU 인스턴스는 동급 CPU 인스턴스보다 몇 배 더 비싸며, 생성한 토큰이 아니라 인스턴스가 존재하는 매 시간마다 요금이 청구됩니다. 하루에 몇 건의 요청만 처리하는 상시 가동 GPU는 추론을 실행하는 가장 비싼 방법입니다. 손익분기점은 활용률에 달려 있습니다. 바쁜 GPU는 토큰당 비용이 저렴하지만, 유휴 상태인 GPU는 순수한 낭비입니다.
세 가지 정직한 패턴이 효과적입니다. 적은 양의 꾸준한 작업은 CPU VPS에서 처리하십시오. 가끔 발생하는 어려운 요청은 호스팅된 API로 보내 토큰당 비용을 지불하십시오. 배치 작업, 파인튜닝, 대량 임베딩 실행을 위해서는 GPU를 시간 단위로 대여한 뒤 작업을 마치면 삭제하십시오. 이들을 혼합하여 사용하는 것은 일반적이며, 상시 가동 VPS에서의 AI 에이전트 비용 관리에서 설명한 예산 관리 원칙이 여기에도 적용됩니다. 단, 여기서는 토큰 수가 아니라 유휴 시간이 비용 누수의 원인이라는 점이 다릅니다.
GPU 없이도 원활하게 작동하는 작업
소량의 임베딩 작업. 소형 임베딩 모델은 몇 개의 CPU 코어만으로도 분당 수백 개의 짧은 문서를 처리할 수 있으며, 한 번 구축한 인덱스는 빠른 속도가 필요하지 않습니다.
전사(transcription)를 위한 Whisper small 및 base 모델. CPU 환경의 Faster-whisper는 small 모델을 사용하여 실시간에 가까운 속도로 전사할 수 있으며, 이는 야간에 실행되는 파이프라인에 충분한 성능입니다.
최대 약 27B 규모의 양자화된 채팅 모델(사용자 1~2명 기준). 속도는 느리지만 내용을 읽을 수 있고 사용 가능한 수준입니다.
배치 작업으로 분류할 수 있는 모든 것. 화면을 지켜보는 사용자가 없다면, 실제 처리 시간(wall-clock speed)은 요구 사항이라기보다 스케줄링의 세부 사항에 불과합니다.
GPU가 반드시 필요한 작업: 소형 어댑터 범위를 넘어서는 학습이나 파인튜닝, 다수의 동시 사용자 서비스, 이미지 및 비디오 생성, 그리고 지연 시간이 곧 제품의 품질인 실시간 음성 처리 등이 있습니다.
FAQ
7B 또는 8B 모델을 구동하려면 VRAM이 얼마나 필요한가?
4비트 양자화된 8B 모델을 8k에서 16k 정도의 일반적인 컨텍스트로 구동할 때 약 6 GB가 필요합니다. 모델 가중치가 대략 4.7 GB를 차지하며, 나머지는 KV 캐시와 약 1 GB의 오버헤드입니다. 12 GB 그래픽 카드를 사용하면 더 긴 컨텍스트를 처리할 때 여유가 있습니다. 128k 컨텍스트로 구동할 계획이라면 캐시 크기를 별도로 계산해야 합니다. 컨텍스트가 커지면 가중치보다 더 많은 메모리를 차지할 수 있기 때문입니다.
GPU 없이 Ollama를 실행할 수 있는가?
가능합니다. Ollama는 GPU가 없으면 자동으로 CPU를 사용하며, 모델을 올릴 수 있는 충분한 RAM만 있으면 됩니다. 메모리 속도에 따라 다르지만 4비트 8B 모델 기준으로 초당 약 5에서 12 토큰 정도의 속도가 나오며, 이는 한 명의 사용자가 읽는 속도와 비슷합니다. CPU 환경에서는 긴 프롬프트가 가장 큰 걸림돌입니다. 30,000 토큰의 컨텍스트를 읽는 작업은 연산 집약적이라 응답을 생성하는 것보다 훨씬 더 오랜 시간이 걸리기 때문입니다.
왜 GPU 성능이 CPU와 별 차이가 없는가?
가장 흔한 원인은 모델이 VRAM에 완전히 올라가지 않아 일부 레이어가 CPU에서 실행되고, 모든 토큰이 느린 쪽의 처리를 기다리기 때문입니다. ollama ps을 실행하여 PROCESSOR 열의 값이 100% GPU인지 확인하십시오. 만약 분할되어 있다면 더 작은 양자화 모델이나 더 작은 모델을 사용해야 합니다. 또 다른 흔한 원인은 벤치마크 시간이 짧아 모델 로드 시간이 측정 결과에 큰 영향을 미치는 경우입니다.
1인 사용자가 GPU VPS를 사용하는 것이 가치가 있는가?
보통은 그렇지 않습니다. 한 사람은 초당 5에서 10 단어 정도를 읽으며, CPU 서버만으로도 약 13B 크기의 모델까지는 읽는 속도보다 빠르게 토큰을 생성할 수 있습니다. 1인 사용자가 비용을 지불할 가치가 있는 경우는 긴 프롬프트 처리, 이미지 생성, 파인튜닝을 할 때입니다. 여러 사용자를 동시에 서비스하는 것이 GPU를 사용하는 가장 강력한 이유인데, 배칭(batching)을 통해 하나의 GPU로 한 명의 응답 비용과 거의 비슷한 수준으로 20명의 요청을 처리할 수 있기 때문입니다.
GPU를 시간 단위로 대여해야 하는가, 아니면 항상 켜두어야 하는가?
파인튜닝, 대량 임베딩 작업, 일괄 전사(transcription) 작업처럼 작업이 몰릴 때는 시간 단위로 대여하십시오. GPU 인스턴스는 토큰 생성량이 아니라 인스턴스 유지 시간에 따라 요금이 청구되므로, 카드가 계속 사용 중일 때만 항상 켜두는 것이 좋습니다. 트래픽이 적은 어시스턴트라면 유휴 상태의 GPU보다 CPU VPS나 토큰당 비용을 지불하는 호스팅 API를 사용하는 것이 더 저렴합니다.