Ollama로 VPS에서 Qwen 27B 모델 실행하는 방법

GPU가 없는 VPS에서 Qwen 3.8 27B를 실행할 수 있습니까?

VPS에서 Qwen 3.8 27B를 실행하려면 먼저 존재하는 모델 태그가 필요합니다. 2026년 8월 4일 기준으로 Ollama 라이브러리에는 qwen3.8 항목이 전혀 없습니다. 가장 근접한 릴리스된 27B 태그는 qwen3.6:27b입니다. 이는 278억 개의 파라미터, Q4_K_M 양자화, Apache 2.0 라이선스를 포함합니다. 아래의 모든 명령어와 숫자는 2026년 7월 27일에 게시된 Ollama v0.32.5에서 해당 태그를 사용합니다.

결론부터 말씀드리면 32 GB 이상의 RAM을 갖춘 VPS에서 실행 가능하지만, 속도는 느립니다. Q4 양자화가 적용된 27B 밀집 모델은 컨텍스트 토큰을 저장하기 전에도 가중치만으로 약 17 GB의 RAM이 필요합니다. 따라서 8 GB 및 16 GB 플랜은 실행이 불가능합니다. 일반적인 듀얼 채널 DDR4 VPS에서의 성능은 초당 약 3 토큰 수준이며, 이는 대부분의 사람이 읽는 속도보다 느립니다.

3.8이라는 숫자는 어디서 나왔을까요? 파라미터 수에서 비롯되었을 가능성이 큽니다. qwen3.6:27b에 대한 Ollama 페이지는 278억 개의 파라미터를 보고하며, 27.8은 나중에 3.8로 기억하기 쉽습니다. 이전 릴리스의 동일한 Q4_K_M 빌드인 qwen3.5:27b도 존재합니다. 명령어를 복사하기 전에 Ollama qwen3.6 태그 페이지에서 실시간 목록을 확인하십시오. 나중에 실제 qwen3.8가 출시되더라도, 여기서 설명한 계산 방식은 버전 번호가 아닌 파라미터 수와 가중치당 비트 수에 의존하므로 그대로 적용됩니다.

어떤 Ollama 태그를 가져올 것인가, 그리고 확인 방법

존재하지 않는 태그를 가져오려고 하면 명확한 오류가 발생하므로, 서버에서 직접 확인하는 것은 간단합니다. 존재하는 태그라 하더라도 로컬에서 실행되지 않을 수 있는데, 이것이 라이브러리에는 나열되어 있지만 Ollama 클라우드에서만 제공되는 GLM 5.2와 관련하여 사용자들이 자주 겪는 문제입니다.

ollama pull qwen3.8:27b
# Error: pull model manifest: file does not exist

ollama pull qwen3.6:27b
ollama show qwen3.6:27b

ollama show은 현재 보유한 태그의 아키텍처, 파라미터 수, 컨텍스트 길이, 양자화 방식을 출력합니다. 파라미터 줄이 27.8B이고 양자화 줄이 Q4_K_M이라면, 이 가이드가 작성된 기준이 되는 빌드를 보유한 것입니다. 라이브러리에는 동일한 가중치에 대해 더 높은 정밀도를 가진 qwen3.6:27b-q8_0 및 qwen3.6:27b-bf16도 포함되어 있으며, CPU에서 매우 다르게 동작하는 MoE(mixture of experts) 모델인 35b-a3b 태그 세트도 있습니다. 이에 대한 자세한 내용은 아래에서 다룹니다.

파라미터 수와 가중치당 바이트 계산

[
  {
    "label": "Q4_K_M",
    "size_gb": 17,
    "bits_per_weight": 4.89,
    "notes": "published tag qwen3.6:27b"
  },
  {
    "label": "Q5_K_M",
    "size_gb": 19.8,
    "bits_per_weight": 5.7,
    "notes": "computed, no library tag exists"
  },
  {
    "label": "NVFP4",
    "size_gb": 20,
    "bits_per_weight": 5.76,
    "notes": "published tag 27b-nvfp4"
  },
  {
    "label": "Q8_0",
    "size_gb": 30,
    "bits_per_weight": 8.63,
    "notes": "published tag 27b-q8_0"
  },
  {
    "label": "BF16",
    "size_gb": 56,
    "bits_per_weight": 16.1,
    "notes": "published tag 27b-bf16"
  }
]

공식은 한 줄로 간단합니다. 가중치 바이트 수 = 파라미터 수 * 가중치당 비트 수 / 8입니다. 4비트 기준에서 278억 개의 파라미터는 13.9 GB가 됩니다. 배포된 Q4_K_M 태그의 크기는 17 GB이며, 실제로는 가중치당 4.89 비트가 사용됩니다.

이 차이는 오류가 아닙니다. K-quant 형식은 모든 텐서를 동일한 비트 폭으로 저장하지 않기 때문입니다. 압축 시 품질 저하가 큰 텐서는 5비트나 6비트로 유지하며, 토큰 임베딩 및 출력 레이어는 보통 Q6_K나 Q8_0으로 남겨둡니다. 형식 이름은 평균치를 나타내며, 실제 평균은 4.9 근처에 형성됩니다. 이러한 현상은 다른 규모에서도 나타납니다. BF16의 경우 56 GB는 16비트가 아니라 가중치당 16.1 비트인데, 이는 파일에 메타데이터와 전체 정밀도 임베딩 테이블이 포함되어 있기 때문입니다.

Q5_K_M은 이 모델에 대해 게시된 태그가 없으므로, 19.8 GB 행은 측정값이 아닌 해당 형식의 일반적인 가중치당 5.7비트를 기준으로 계산되었습니다. Q8_0은 Q4 대비 거의 두 배인 30 GB가 됩니다. CPU 전용 장비에서 이 용량 증가는 토큰당 메모리 트래픽을 두 배로 늘리며, 결과적으로 초당 토큰 처리량(tokens per second)을 대략 절반으로 줄입니다. 이러한 이유만으로도 Q4_K_M이 기본값으로 적절합니다. 메모리 측면이 아닌 품질 측면에서 결정을 내리고 싶다면, Q4, Q8 및 fp16의 상세 비교를 통해 출력 품질이 실제로 어디서부터 저하되는지 확인할 수 있습니다.

컨텍스트가 증가함에 따라 발생하는 KV 캐시 비용

모델 가중치는 고정 비용입니다. KV 캐시(key and value cache, 모델이 이미 처리한 모든 토큰에 대해 유지하는 어텐션 상태)는 컨텍스트 길이에 비례하여 선형적으로 증가하며, 실제로 대부분의 사용자가 RAM 부족을 겪는 지점입니다.

[
  {
    "label": "4k tokens",
    "kv_f16_gb": 1,
    "kv_q8_gb": 0.5
  },
  {
    "label": "8k tokens",
    "kv_f16_gb": 2,
    "kv_q8_gb": 1
  },
  {
    "label": "16k tokens",
    "kv_f16_gb": 4,
    "kv_q8_gb": 2
  },
  {
    "label": "32k tokens",
    "kv_f16_gb": 8,
    "kv_q8_gb": 4
  },
  {
    "label": "64k tokens",
    "kv_f16_gb": 16,
    "kv_q8_gb": 8
  },
  {
    "label": "128k tokens",
    "kv_f16_gb": 32,
    "kv_q8_gb": 16
  }
]

위 수치는 Qwen이 최근 이 크기 등급의 dense 모델에서 사용한 구조인 64개 레이어, GQA(grouped-query attention) 하의 8개 키/값 헤드, 128의 헤드 차원을 가정합니다. 이는 f16 기준으로 토큰당 256 KiB에 해당하며, 32k 토큰에서 8 GB, 128k 토큰에서 32 GB가 됩니다. 제 계산을 그대로 믿지 말고 본인의 장비에서 직접 확인하십시오. 모델을 로드한 뒤 가중치, 캐시, 오버헤드를 합산한 수치를 보여주는 ollama ps의 SIZE 열을 확인하십시오.

이것이 모델 카드에 명시된 256K 컨텍스트가 실제 운영 계획이라기보다 홍보성 문구에 가까운 이유입니다. f16으로 이를 채우려면 가중치에 사용된 17 GB 외에도 64 GB의 캐시가 추가로 필요합니다. Ollama는 기본적으로 전체 윈도우를 제공하지 않습니다. 훨씬 작은 크기로 로드하며, OLLAMA_CONTEXT_LENGTH을 통해 의도적으로 높여야 합니다. 서버 전체에 적용되는 이 변수가 유일한 수단은 아니며, 개별 요청에 num_ctx 설정하기를 사용하면 다른 작업에는 낮은 기본값을 유지하면서 특정 긴 작업에만 더 큰 윈도우를 할당할 수 있습니다. 단계적으로 값을 올리면서 변경할 때마다 ollama ps를 확인하십시오.

두 가지 설정으로 캐시를 절반 이하로 줄일 수 있습니다. OLLAMA_KV_CACHE_TYPE=q8_0는 캐시를 16비트가 아닌 8비트로 저장하여 32k 토큰 기준 8 GB를 4 GB로 줄여줍니다. 이 기능은 flash attention이 필요하므로 OLLAMA_FLASH_ATTENTION=1도 함께 설정하고, 설정이 적용되었는지 추측하지 말고 ollama ps에서 감소분을 직접 확인하십시오. OLLAMA_NUM_PARALLEL=1 또한 매우 중요합니다. Ollama는 여러 요청을 동시에 처리할 수 있으며, 각 슬롯은 고유한 컨텍스트 영역을 차지합니다. 따라서 병렬 처리 설정을 기본값으로 두면 예산으로 책정한 캐시가 배수로 늘어납니다. 여러 사용자가 이 장비를 사용한다면 이러한 배수 증가가 문제의 시작점이 되며, 자체 호스팅 모델이 수용할 수 있는 동시 사용자 수는 코어 개수보다 캐시 슬롯과 큐 깊이에 의해 훨씬 먼저 결정됩니다.

8, 16, 32, 64 GB RAM에 적합한 구성

[
  {
    "label": "8 GB",
    "q4_max_ctx_ktok": 0,
    "q8_max_ctx_ktok": 0,
    "notes": "Weights alone exceed the box. Use a 4b or 8b model."
  },
  {
    "label": "16 GB",
    "q4_max_ctx_ktok": 0,
    "q8_max_ctx_ktok": 0,
    "notes": "17 GB of weights does not fit in 16 GB of RAM."
  },
  {
    "label": "32 GB",
    "q4_max_ctx_ktok": 32,
    "q8_max_ctx_ktok": 0,
    "notes": "Q4 fits with room to spare. Q8 weights do not fit."
  },
  {
    "label": "64 GB",
    "q4_max_ctx_ktok": 128,
    "q8_max_ctx_ktok": 64,
    "notes": "Both fit. Q8 leaves much less room for context."
  }
]

두 숫자는 가중치와 함께 f16 캐시로 사용할 수 있는 컨텍스트 토큰 수(단위: 천)를 의미합니다. 이는 운영체제용으로 약 1.5 GB를 남겨두고 약간의 여유 공간을 확보한 headless Linux VPS 기준입니다. 0은 가중치 자체가 메모리에 올라가지 않아 아무것도 실행할 수 없음을 의미합니다.

8 GB와 16 GB는 여유가 없습니다. 17 GB 크기의 가중치는 16 GB RAM에 적재할 수 없으며, 컨텍스트 설정을 변경해도 해결되지 않습니다. 스왑을 추가해도 소용없습니다. Ollama는 GGUF 파일을 메모리 매핑하므로, 상주 페이지가 RAM을 초과하면 커널이 페이지를 교체하고 다시 읽어 들이기 시작합니다. 이 과정에서 매 토큰마다 수 GB의 데이터를 디스크에서 읽어오게 됩니다. 서버는 높은 iowait 상태가 되며 초당 1 토큰 미만의 속도로 동작합니다.

32 GB는 시작점입니다. 가중치가 17 GB를 차지하면 약 13 GB의 여유가 남으며, 이는 약 32k 토큰의 f16 컨텍스트를 여유 있게 수용합니다. 30 GB 크기의 Q8_0 가중치는 이 계층에서 전혀 실행할 수 없습니다.

64 GB는 충분한 용량입니다. Q4를 사용하면 약 128k 토큰의 컨텍스트를 확보할 수 있고, Q8_0 가중치를 사용해도 약 64k 토큰의 컨텍스트를 사용할 수 있습니다. Q8을 사용하기 위해 64 GB RAM을 구매하기 전에 무엇을 얻는지 명확히 해야 합니다. 이미 느린 머신에서 속도는 절반으로 줄어들고 출력 품질은 약간 향상될 뿐입니다. 거의 모든 사용자에게는 더 긴 컨텍스트를 사용할 수 있는 Q4가 더 나은 선택입니다.

VPS에서 CPU 추론은 얼마나 빠른가?

밀집 모델(dense model)에서 토큰 하나를 생성하려면 모든 가중치를 메모리에서 한 번씩 읽어야 합니다. 일부가 아니라 전부를 읽어야 합니다. 따라서 속도 제한은 코어 개수가 아니라, 가중치 크기로 나눈 메모리 대역폭에 의해 결정됩니다. Q4 양자화 모델의 경우 토큰당 17 GB의 메모리 트래픽이 발생합니다.

[
  {
    "label": "DDR4-2666, 2 channel",
    "mem_bandwidth_gb_s": 42.6,
    "ceiling_tok_s": 2.5
  },
  {
    "label": "DDR4-3200, 2 channel",
    "mem_bandwidth_gb_s": 51.2,
    "ceiling_tok_s": 3
  },
  {
    "label": "DDR5-4800, 2 channel",
    "mem_bandwidth_gb_s": 76.8,
    "ceiling_tok_s": 4.5
  },
  {
    "label": "DDR4-3200, 8 channel",
    "mem_bandwidth_gb_s": 204.8,
    "ceiling_tok_s": 12
  },
  {
    "label": "DDR5-4800, 12 channel",
    "mem_bandwidth_gb_s": 460.8,
    "ceiling_tok_s": 27.1
  }
]

위 수치는 이론적인 상한선일 뿐 실제 측정값이 아닙니다. 메모리 지연 시간과 불완전한 프리페칭(prefetching)으로 인해 이론적 최대치에 도달할 수 없으므로, 실제 출력 속도는 위 수치의 약 50~70% 수준입니다. 듀얼 채널 DDR4-3200 VPS의 상한선은 초당 3 토큰이므로, 실제로는 약 2 토큰 정도를 예상해야 합니다. 듀얼 채널 DDR5-4800 서버의 상한선은 4.5이므로, 약 3 토큰 정도를 기대할 수 있습니다.

대형 서버 상품에는 주의가 필요합니다. 12채널 EPYC 플랫폼은 460.8 GB/s의 대역폭과 초당 27.1 토큰의 상한선을 가지지만, 사용자가 EPYC 전체를 임대하는 것은 아닙니다. 메모리 대역폭은 해당 장비의 모든 테넌트가 공유하는 자원이므로, 8 vCPU를 할당받았다고 해서 12채널의 대역폭을 독점하는 것은 아닙니다. GPU 중심 가이드에서는 이 점을 간과하는 경우가 많으며, 이것이 동일한 vCPU 개수를 가진 두 VPS 상품이 같은 모델에서 3배까지 성능 차이를 보이는 이유입니다.

vCPU 개수를 늘려도 성능 향상이 금방 멈추는 이유도 같습니다. 코어가 데이터를 요청하는 속도가 메모리 컨트롤러의 처리 속도를 넘어서면, 추가적인 스레드는 스케줄링 오버헤드만 발생시킬 뿐입니다. OLLAMA_NUM_THREAD를 물리 코어 개수로 설정하여 측정해 본 뒤, 그 절반 값으로 다시 시도해 보십시오. 많은 공유형 상품에서는 낮은 설정값이 더 빠르게 동작합니다.

프롬프트 처리 방식은 다릅니다. 첫 토큰이 나오기 전 입력 데이터를 훑는 프리필(prefill) 단계는 대역폭이 아닌 연산 성능에 의존하므로 코어 개수에 비례하여 성능이 향상됩니다. 실제로는 긴 프롬프트 입력 시 출력 시작까지 긴 대기 시간이 발생하고, 그 이후에는 앞서 언급한 느리고 일정한 속도로 토큰이 생성됩니다. --verbose을 사용하여 두 단계를 각각 측정하십시오. 이 도구는 모든 요청에 대해 prompt eval rate와 eval rate를 출력합니다.

밀집 27B 모델이 너무 느리다면 CPU 추론을 포기하기 전에 qwen3.6:35b-a3b 태그를 확인하십시오. 이 태그를 사용하면 전체 278억 개의 파라미터 대신 토큰당 약 30억 개의 파라미터만 활성화하므로, 디스크상의 파일 크기는 더 크더라도 토큰당 메모리 트래픽은 거의 10분의 1 수준으로 줄어듭니다. 즉, RAM 사용량을 희생하여 속도를 얻는 방식입니다. 이때 런타임 선택도 중요하며, Ollama와 llama.cpp는 동일한 기반 추론 코드에 대해 서로 다른 CPU 튜닝 제어 기능을 제공합니다.

GPU 시간을 대여해야 하는 경우

[
  {
    "label": "L40S, 48 GB",
    "mem_bandwidth_gb_s": 864,
    "ceiling_tok_s": 51
  },
  {
    "label": "RTX 4090, 24 GB",
    "mem_bandwidth_gb_s": 1008,
    "ceiling_tok_s": 59
  },
  {
    "label": "A100, 80 GB",
    "mem_bandwidth_gb_s": 2039,
    "ceiling_tok_s": 120
  },
  {
    "label": "H100 SXM, 80 GB",
    "mem_bandwidth_gb_s": 3350,
    "ceiling_tok_s": 197
  }
]

공개된 GPU 메모리 대역폭에 동일한 공식을 적용하면 다른 범주의 답이 나옵니다. 24 GB 소비자용 카드는 이 가중치에서 초당 59 토큰이라는 한계를 가집니다. 최신 데이터 센터용 카드는 197에 도달합니다. 이는 스레드 수를 조정한다고 해서 좁힐 수 있는 격차가 아닙니다. 해당 카드는 1008 GB/s로 메모리를 구동하는 반면, VPS는 수십 GB/s 수준에서 작동하기 때문입니다.

따라서 선호도가 아닌 작업 부하에 따라 기준을 정하십시오. 작업이 비동기식이고 기다리는 사람이 없을 때는 CPU 추론이 올바른 선택입니다. 밤사이 문서 더미를 요약하거나, 잠든 사이에 실행되는 야간 분류 작업이 이에 해당합니다. 사람이 출력 결과를 기다리고 있거나, 30초에 한 번보다 빠르게 요청이 들어오는 순간 GPU를 대여하십시오. CPU 전용 박스는 배치 처리 여유 공간이 없어 대기열이 계속 늘어나기 때문입니다.

비용 비교는 보이는 것보다 간단하지 않습니다. 64 GB VPS는 모델 로드 여부와 관계없이 매달 매시간 요금이 청구되지만, GPU 인스턴스는 실행하는 시간만큼만 요금이 청구됩니다. 실제 사용량이 하루 2시간이라면, 대여한 GPU가 더 빠르면서도 저렴할 수 있습니다. 먼저 작업 주기(duty cycle)를 계산한 뒤 가격을 책정하십시오. GPU가 탑재된 VPS 선택하기에서는 인스턴스 자체에서 확인해야 할 사항을 다루며, vLLM이 GPU에서 동시 요청을 처리할 때 Ollama보다 앞서는 이유에서는 vLLM이 요청을 적절하게 배치 처리하는 방식을 설명합니다.

사람들이 간과하는 세 번째 선택지가 있습니다. 배치 작업에는 27B 모델을 CPU에서 유지하고, 대화형 경로에는 호스팅된 API 모델을 배치하는 것입니다. 하나의 모델이 두 가지 역할을 모두 수행해야 할 이유는 없습니다.

Ollama 설치 및 시스템 성능 측정

공식 설치 스크립트를 사용하면 전용 ollama 사용자로 실행되는 systemd 서비스가 설정됩니다.

curl -fsSL https://ollama.com/install.sh | sh
ollama --version
free -g

ollama --version 명령은 0.32.5 이상의 버전을 출력해야 합니다. 모델을 다운로드하기 전에 free -g 명령으로 메모리 상태를 확인하십시오. Mem 행의 total 열이 32 미만이라면 작업을 중단하고 더 작은 모델을 선택하십시오. 실행할 수 없는 17 GB 크기의 모델을 다운로드하는 것은 시간과 디스크 공간을 낭비하는 일입니다.

런타임 옵션은 셸이 아닌 systemd override 파일에 설정하십시오. 모델은 서비스 내부에서 실행되므로 사용자의 대화형 환경 변수를 참조하지 않습니다.

sudo systemctl edit ollama

[Service]
Environment="OLLAMA_CONTEXT_LENGTH=8192"
Environment="OLLAMA_NUM_PARALLEL=1"
Environment="OLLAMA_MAX_LOADED_MODELS=1"
Environment="OLLAMA_FLASH_ATTENTION=1"
Environment="OLLAMA_KV_CACHE_TYPE=q8_0"
Environment="OLLAMA_KEEP_ALIVE=60m"

sudo systemctl restart ollama
ollama pull qwen3.6:27b
ollama run qwen3.6:27b --verbose "Name two Linux distributions."

--verbose 출력 결과가 측정하려는 성능 지표입니다. eval rate은 생성 중 초당 토큰 처리량(tokens per second)을 나타냅니다. prompt eval rate은 프리필(prefill) 속도입니다. load duration는 디스크에서 가중치를 읽어오는 데 걸린 시간입니다. OLLAMA_KEEP_ALIVE=60m 옵션을 설정하는 이유가 바로 이것입니다. CPU 환경에서 요청마다 17 GB의 가중치를 디스크에서 다시 불러오는 비용은 요청 자체를 처리하는 비용보다 큽니다. 기본 유휴 시간 제한은 5분으로, 항목 사이에 간격이 있는 배치 큐에서는 매번 로드 비용이 발생합니다. 모델을 상주시키는 옵션을 통해 요청별 keep_alive 필드를 설정하거나 재부팅 후에도 설정이 유지되도록 할 수 있습니다.

모델이 로드된 상태에서 다른 터미널을 열어 메모리 점유율을 확인하십시오.

ollama ps

SIZE 열은 KV 캐시를 포함한 실제 메모리 점유율이며, 가중치 크기에 KV 차트의 컨텍스트 길이에 따른 값을 더한 수치와 비슷해야 합니다. 8-bit 캐시를 사용하는 8192 토큰 환경에서는 가중치 외에 약 1 GB의 추가 메모리가 필요하며, 캐시가 f16으로 유지될 경우 2 GB가 추가됩니다. PROCESSOR 열에는 100% CPU가 표시되어야 합니다. 다른 값이 표시된다면 무언가 GPU를 점유하고 있는 것이며, 이 가이드의 속도 수치는 현재 시스템 환경과 일치하지 않습니다.

실패 유형과 확인 가능한 정확한 문자열

모델 로드 실패. Ollama는 model requires more system memory (18.6 GiB) than is available (15.2 GiB) 형식으로 두 수치를 모두 명시한 줄을 출력합니다. 이는 커널이 처리하게 두지 않고 Ollama가 할당 전에 미리 확인한 것이므로 양호한 실패 사례입니다. 컨텍스트 길이를 줄이거나, 더 작은 태그로 변경하거나, 더 큰 플랜으로 이동하십시오.

답변 도중 프로세스 종료. 클라이언트는 유용한 정보를 표시하지 않으며, journalctl -u ollama -n 50은 서비스가 재시작되고 있음을 보여줍니다. dmesg -T | tail을 실행했을 때 Out of memory: Killed process ... (ollama)라는 문구가 나타난다면 커널의 OOM killer가 프로세스를 강제 종료한 것입니다. 이는 사전 로드 검사는 통과했으나 긴 대화 도중 캐시가 예상치를 초과하여 커널 메모리가 부족해졌을 때 발생합니다. 컨텍스트 길이를 줄이십시오.

풀(pull) 즉시 실패. Error: pull model manifest: file does not exist은 해당 태그가 라이브러리에 없음을 의미합니다. qwen3.8:27b을 입력하면 정확히 이 오류가 발생하며, 버전 번호의 오타도 같은 결과를 낳습니다. 네트워크 문제를 의심하기 전에 라이브러리 페이지에서 태그를 확인하십시오.

작동은 하지만 속도가 지나치게 느림. 충분한 RAM을 갖춘 장비에서 초당 1토큰 미만으로 출력된다면 연산 성능보다는 페이징(paging) 문제일 가능성이 큽니다. 생성 중에 vmstat 1를 실행하십시오. si 또는 so 열의 값이 0이 아니라면 커널이 스왑을 사용 중인 것이며, 컨텍스트를 줄이거나 로드된 모델 수를 줄여야 합니다. 스왑 활동이 없는데도 wa가 계속 높게 유지된다면 메모리 매핑된 가중치가 디스크에서 계속 다시 읽히고 있는 것이며, 이는 모델이 실제 메모리 용량을 초과했음을 의미합니다.

첫 토큰 생성에 30초가 걸린 뒤 속도가 빨라짐. 이는 프리필(prefill) 과정이며 정상입니다. 긴 시스템 프롬프트는 캐시를 놓칠 때마다 매번 비용이 발생하므로, 다른 설정을 조정하기 전에 시스템 프롬프트를 먼저 단축하십시오.

CPU 전용 27B 모델의 실제 활용도

희망 사항이 아닌 수치를 바탕으로 기대치를 설정해야 합니다. 초당 2개에서 4개의 토큰을 생성하는 속도라면, 500개 토큰의 답변을 얻는 데 2분에서 4분이 소요됩니다. 이는 실시간 대화에는 사용할 수 없지만, 대기열(queue) 방식의 작업에는 충분히 활용 가능합니다. 답변 전 추론 과정을 거치는 모델은 이 계산을 더 어렵게 만듭니다. 숨겨진 추론 토큰 역시 답변과 동일한 느린 속도로 생성되기 때문입니다. 따라서 작업에 맞춰 추론 수준을 조정하는 것은 모델을 교체하지 않고도 답변 시간을 단축할 수 있는 몇 안 되는 방법 중 하나입니다. 문서 요약, 대량 태깅, 파일 백로그에서의 필드 추출, 무인 코드 리뷰는 모두 이러한 지연 시간을 감수할 수 있습니다. 답변을 기다리는 사람이 없기 때문입니다. 코딩 지원은 이 경계선에 위치합니다. 따라서 직접 호스팅하는 모델에 코딩 에이전트를 연결하는 것은 커밋 메시지 작성이나 테스트 스캐폴딩 같은 백그라운드 작업에는 효과적이지만, 사용자가 즉시 결과를 기다려야 하는 인라인 제안에는 적합하지 않습니다.

개인정보 보호는 가장 중요한 고려 사항입니다. 모델은 사용자가 임대하고 제어하는 하드웨어에서 실행되며, 어떤 요청도 외부로 나가지 않고 토큰당 비용도 발생하지 않습니다. 이는 규제 대상 데이터를 다룰 때 초당 3개의 토큰 속도라 하더라도 충분한 가치가 있습니다. 대안과 솔직하게 비교해 보십시오. 최상위급 모델을 직접 호스팅하려면 훨씬 더 많은 하드웨어가 필요하며, CPU 기반의 27B 모델은 출력 결과가 읽을 만한 가치를 지니는 가장 저렴한 지점입니다.

이를 벤치마크하려면 실제 구조화된 입력 데이터가 필요합니다. 대부분의 공개 데이터 API는 처리량을 측정하기 전 계정 생성을 요구합니다. Strasmore의 데모 엔드포인트(저희가 운영합니다)는 22년간의 미국 시장 데이터를 읽기 전용 SQL로 제공하며, 키나 가입 절차가 필요 없습니다. https://ai.strasmore.com/api/demo/sql?sql=SELECT ticker, close FROM delayed_stocks_minute_aggs LIMIT 5으로 GET 요청을 보내면 프롬프트 루프에 바로 전달할 수 있는 JSON과 이를 생성한 정확한 SQL이 반환되므로, 모델이 요약한 내용을 독립적으로 검증할 수 있습니다. 호출당 제한은 500행, 20초이며, 이는 초당 2토큰 속도의 장비가 처리하기에 충분히 여유로운 수준입니다. 전체 컬럼 목록은 https://api.strasmore.com/v1/schema에서 확인할 수 있습니다.

Ollama를 처음 설치한다면, VPS에서 Ollama를 실행하기 위한 전체 가이드를 참고하십시오. 이 가이드에는 서비스 설정, HTTP API, 그리고 본 문서에서 이미 갖추고 있다고 가정하는 방화벽 규칙이 포함되어 있습니다. 포트 11434를 인터넷에 직접 노출하지 마십시오. Ollama는 자체 인증 기능을 제공하지 않으므로, 해당 포트에 접근할 수 있는 누구나 모델을 사용하고 프롬프트를 읽을 수 있습니다.

FAQ

Ollama에 Qwen 3.8 27B 모델이 있습니까?

아니요. 2026년 8월 4일 기준으로 Ollama 라이브러리에는 qwen3.8 네임스페이스가 없습니다. 존재하는 27B 태그는 qwen3.5:27b와 qwen3.6:27b이며, 둘 다 278억 개의 파라미터를 가진 dense 모델의 Q4_K_M 빌드입니다. 검색어의 3.8은 27.8B 파라미터 수를 버전 번호로 잘못 기억했을 가능성이 매우 높습니다. 현재 목록은 https://ollama.com/library/qwen3.6/tags에서 확인하고, 최신 27B 릴리스를 원하면 qwen3.6:27b를 pull 하십시오. 존재하지 않는 태그를 호출하면 Error: pull model manifest: file does not exist 오류가 발생합니다.

VPS에서 Qwen 27B 모델을 실행하려면 RAM이 얼마나 필요합니까?

Q4_K_M 모델의 경우 32 GB가 실질적인 최소 사양입니다. 가중치 크기는 17 GB이며, 운영체제에 약 1.5 GB가 필요하고, KV 캐시는 f16 기준 4000 토큰의 컨텍스트마다 약 1 GB를 추가로 점유합니다. 16 GB 플랜은 가중치를 메모리에 올릴 수 없으며, 파일이 메모리 매핑(memory-mapped) 방식으로 동작하므로 스왑(swap)을 사용해도 커널이 매 토큰마다 디스크에서 다시 읽어오기 때문에 성능 향상을 기대할 수 없습니다. 64 GB 플랜을 사용하면 긴 컨텍스트를 처리하거나 30 GB 크기의 Q8_0 가중치를 사용할 여유가 생깁니다.

CPU 환경의 VPS에서 27B 모델은 초당 몇 토큰을 생성합니까?

메모리 대역폭을 가중치 크기로 나눈 뒤, 그 값의 50~70%를 계산하십시오. 듀얼 채널 DDR4-3200 VPS의 이론적 한계는 초당 3 토큰에 가깝지만 실제로는 약 2 토큰을 생성합니다. 듀얼 채널 DDR5-4800 장비는 이론상 초당 4.5 토큰에 가깝지만 실제로는 약 3 토큰을 생성합니다. 멀티 채널 서버 플랫폼이 수치상으로는 훨씬 뛰어나 보이지만, 호스트의 메모리 대역폭은 모든 테넌트가 공유하므로 ollama run qwen3.6:27b --verbose를 사용하여 직접 측정하고 eval rate 라인을 확인하십시오.

CPU 전용 VPS에서 Q4와 Q8 중 무엇을 사용해야 합니까?

거의 모든 경우에 Q4_K_M을 권장합니다. Q8_0은 17 GB 대신 30 GB를 차지하므로 64 GB 플랜이 필요하며, 토큰당 메모리 이동량이 거의 두 배가 되어 초당 토큰 생성 속도가 절반으로 줄어듭니다. 27B 모델에서 Q4_K_M과 Q8_0 사이의 품질 차이는 대부분의 작업에서 미미합니다. RAM을 더 긴 컨텍스트에 할당하십시오. 컨텍스트 길이는 모델의 문장 표현 방식보다 모델이 수행할 수 있는 작업의 범위를 결정짓는 더 중요한 요소입니다.

대용량 RAM VPS보다 GPU를 대여하는 것이 더 저렴한 경우는 언제입니까?

사용 빈도가 낮거나 사람이 직접 결과를 기다려야 하는 경우입니다. 24 GB 메모리를 탑재한 GPU는 해당 가중치로 초당 약 59 토큰을 생성하며, 일반적인 VPS의 2~3 토큰과 비교됩니다. 또한 GPU는 가동 시간만큼만 비용을 청구합니다. 64 GB VPS는 모델 로드 여부와 관계없이 한 달 내내 비용이 발생합니다. 하루에 실제로 토큰을 생성하는 시간이 몇 시간인지 계산해 보십시오. 하루 2~3시간 미만이라면 속도와 비용 면에서 시간제 GPU 대여가 유리합니다. 상시 가동이 필요한 저우선순위 배치 작업에는 상시 가동형 VPS가 유리합니다.