VPS에서 Ollama로 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 페이지는 27.8B 파라미터를 보고하며, 27.8은 나중에 3.8로 기억하기 쉽습니다. 이전 릴리스와 동일한 Q4_K_M 빌드인 qwen3.5:27b도 존재합니다. 명령어를 복사하기 전에 Ollama qwen3.6 태그 페이지에서 실시간 목록을 확인하십시오. 나중에 실제 qwen3.8가 출시되더라도 여기에 기술된 계산 방식은 그대로 적용됩니다. 이는 버전 번호가 아닌 파라미터 수와 가중치당 비트 수에 의존하기 때문입니다.

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

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

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개 키/값 헤드, 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와 약간의 여유 공간을 남겨둔 헤드리스 Linux VPS에서, 가중치와 함께 f16 캐시로 사용할 수 있는 컨텍스트 토큰(단위: 1,000)을 의미합니다. 0은 가중치 자체가 메모리에 올라가지 않아 아무것도 실행할 수 없음을 뜻합니다.

8 GB와 16 GB는 고려 대상이 아닙니다. 17 GB의 가중치는 16 GB RAM에 적재할 수 없으며, 컨텍스트 설정을 변경해도 해결되지 않습니다. 스왑(swap)을 추가해도 소용없습니다. 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) 단계는 대역폭 제한이 아닌 연산 제한(compute bound)을 받으므로 코어 수에 비례하여 성능이 향상됩니다. 실제로는 긴 프롬프트 입력 시 출력이 시작되기까지 긴 대기 시간이 발생하고, 그 이후에는 앞서 언급한 느리고 일정한 속도로 출력이 진행됩니다. --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이 요청을 적절히 배치 처리하는 방식을 설명합니다.

사람들이 간과하는 세 번째 선택지가 있습니다. 배치 작업은 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가 필요하고, KV 캐시는 f16 기준 4000 토큰의 컨텍스트마다 약 1 GB를 추가로 점유합니다. 16 GB 플랜은 가중치를 아예 올릴 수 없으며, 파일이 메모리 매핑 방식으로 로드되므로 스왑을 사용해도 소용이 없습니다. 커널이 토큰마다 디스크에서 파일을 다시 읽어오기 때문입니다. 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 토큰보다 훨씬 빠르며 사용한 시간만큼만 비용이 청구됩니다. 64 GB VPS는 모델 로드 여부와 상관없이 한 달 내내 비용이 발생합니다. 하루에 실제로 토큰을 생성하는 시간이 몇 시간인지 계산해 보십시오. 하루 2~3시간 미만이라면 속도와 비용 면에서 시간제 GPU 대여가 유리합니다. 상시 가동이 필요한 저우선순위 배치 작업에는 항상 켜져 있는 VPS가 유리합니다.