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 이상의 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 태그를 pull할 것인가, 그리고 확인 방법

존재하지 않는 태그를 pull하면 명확한 오류가 발생하므로, 서버에서 직접 확인하는 것이 빠릅니다.

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 전용 장비에서 이 용량 증가는 토큰당 메모리 트래픽을 두 배로 늘리며, 결과적으로 초당 토큰 처리량도 대략 절반으로 줄어듭니다. 이러한 이유만으로도 Q4_K_M이 기본값으로 적합합니다.

컨텍스트가 증가함에 따른 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개 key/value 헤드, 128의 헤드 차원입니다. 이는 f16 기준 토큰당 256 KiB를 차지하며, 32k 토큰에서 8 GB, 128k 토큰에서 32 GB가 됩니다. 제 계산을 그대로 믿지 말고 본인의 장비에서 직접 확인하십시오. 모델을 로드한 뒤 가중치, 캐시, 오버헤드를 합산한 단일 수치를 보여주는 ollama ps의 SIZE 열을 확인하십시오.

모델 카드에 명시된 256K 컨텍스트가 실제 운영 계획이 아닌 홍보용 수치인 이유가 바로 이것입니다. f16으로 이를 채우려면 가중치 외에 64 GB의 캐시가 추가로 필요하며, 이미 가중치에 17 GB를 사용하는 장비에서는 감당하기 어렵습니다. Ollama는 기본적으로 전체 윈도우를 제공하지 않습니다. 훨씬 작은 크기로 로드하며, OLLAMA_CONTEXT_LENGTH을 통해 의도적으로 높여야 합니다. 단계적으로 값을 올리면서 변경할 때마다 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."
  }
]

이 두 숫자는 운영체제용 1.5 GB와 약간의 여유 공간을 제외한 headless Linux VPS에서, f16 캐시를 사용하여 모델 가중치와 함께 수용 가능한 컨텍스트 토큰 수(단위: 1,000)를 의미합니다. 0은 가중치 자체가 메모리에 올라가지 않아 아무것도 실행할 수 없음을 뜻합니다.

8 GB와 16 GB는 고려 대상이 아닙니다. 17 GB의 가중치는 16 GB RAM에 들어가지 않으며, 컨텍스트 설정을 변경해도 해결되지 않습니다. 스왑을 추가해도 소용없습니다. Ollama는 GGUF 파일을 메모리 매핑하므로, 상주 페이지가 RAM을 초과하면 커널이 페이지를 교체하고 다시 읽기 시작합니다. 이때 토큰 하나를 생성할 때마다 디스크에서 기가바이트 단위의 데이터를 읽어 들입니다. 서버는 높은 iowait 상태에 빠지며 초당 1 토큰 미만의 속도를 보입니다.

32 GB는 시작점입니다. 가중치가 17 GB를 차지하면 약 13 GB의 여유가 남으며, 이는 여유 공간을 포함해 약 32k 토큰의 f16 컨텍스트를 처리할 수 있습니다. 30 GB인 Q8_0 가중치는 이 사양에서 전혀 실행되지 않습니다.

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

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

밀집(dense) 모델에서 토큰 하나를 생성하려면 메모리에 있는 모든 가중치를 한 번 읽어야 합니다. 일부가 아니라 전부를 읽어야 합니다. 따라서 속도 제한은 코어 수가 아니라, 가중치 크기로 나눈 메모리 대역폭입니다. 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 선택하기에서는 인스턴스 자체에서 확인해야 할 사항을 다루며, GPU에서 동시 요청을 처리할 때는 vLLM이 Ollama보다 앞섭니다에서는 vLLM이 요청을 적절히 배치 처리하는 방법을 설명합니다.

사람들이 간과하는 세 번째 선택지가 있습니다. 배치 작업은 CPU에서 27B 모델로 처리하고, 대화형 경로에는 호스팅된 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를 다시 불러오는 것은 요청 처리 자체보다 더 큰 비용을 발생시킵니다.

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

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 모델은 출력 결과물을 읽을 만한 가치가 있는 수준에서 가장 저렴한 선택지입니다.

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가 필요하고, f16 기준 4000 토큰의 컨텍스트마다 KV 캐시로 약 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가 유리합니다.