Ollama로 VPS에서 Qwen 3.8 27B 실행하기

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

Qwen 3.8 27B를 VPS에서 실행하려면 qwen3.8:27b 태그가 필요하다. 21 October 2026 기준으로 Ollama 라이브러리에서 이 태그를 로컬로 pull할 수 있다. 이 모델은 27.3 billion parameters, Q4_K_M quantisation, Apache 2.0 licence, 256K context window를 사용하며, 약 0.9 GB인 vision projector를 포함해 18 GB를 다운로드한다. Ollama는 14 August 2026에 출시한 v0.32.12에서 Qwen 3.8 27B 지원을 추가했다. 따라서 이전 버전이 설치되어 있다면 먼저 업그레이드해야 한다. 29 October 2026 기준 최신 stable release는 28 October 2026에 공개된 v0.40.13이다.

짧게 답하면, 32 GB 이상인 VPS에서는 실행할 수 있지만 속도가 느리다. 27B dense model을 Q4로 실행하면 context의 토큰을 하나도 저장하기 전에 weights만으로 약 17 GB의 RAM이 필요하다. 따라서 8 GB 및 16 GB 요금제는 완전히 제외된다. 일반적인 two-channel DDR4 VPS에서는 한계가 대략 3 tokens per second이므로, 대부분의 사람이 읽는 속도보다 느리다.

이전 27B 태그도 여전히 라이브러리에 있다. qwen3.6:27b와 qwen3.5:27b은 모두 비슷한 크기의 Q4_K_M 빌드다. Qwen3.8-27B는 Qwen3.6-27B의 아키텍처를 유지하며, 두 모델의 공식 config 파일은 동일한 layer layout을 제공한다. 따라서 아래의 메모리 계산은 어느 모델에도 적용된다. 명령을 복사하기 전에 Ollama qwen3.8 태그 페이지에서 현재 목록을 확인해야 한다. 여기서 사용하는 계산은 version number가 아니라 parameter count, bits per weight 및 attention layout에 따라 달라진다.

가져올 Ollama 태그와 확인 방법

존재하지 않는 태그를 가져오면 명확한 오류가 발생하므로, 서버에서 바로 빠르게 확인할 수 있다. 존재하는 태그라도 로컬에서 실행할 수 없는 경우가 있다. 이것이 라이브러리에는 등록되어 있지만 Ollama 클라우드에서만 제공되는 GLM 5.2에서 자주 혼동되는 부분이다.

ollama --version
ollama pull qwen3.8:27b
ollama show qwen3.8:27b

ollama show는 실제로 보유한 태그의 아키텍처, 매개변수 수, 컨텍스트 길이, 양자화 방식을 출력한다. 매개변수 줄에 27.3B가 표시되고 양자화 줄에 Q4_K_M이 표시되면, 이 가이드가 기준으로 삼는 빌드를 사용 중인 것이다. 라이브러리에는 동일한 가중치에 더 높은 정밀도를 적용한 qwen3.8:27b-q8_0 및 qwen3.8:27b-bf16, 27b-mtp 변형도 있다. 또한 태그 페이지에서 MLX로 표시하는 27b-nvfp4, 27b-mxfp8, 27b-mlx, 27b-mlx-bf16 태그도 있다. MLX는 Linux VPS가 아니라 Apple Silicon을 대상으로 하는 형식이다. qwen3.6와 달리 qwen3.8 항목에는 35b-a3b 태그가 없다. 이러한 MoE(전문가 혼합) 모델도 qwen3.6 아래에 있지만 CPU에서 동작하는 방식은 매우 다르다. 이에 대해서는 아래에서 자세히 설명한다.

가중치당 바이트 수를 매개변수 수와 곱하기

[
  {
    "label": "Q4_K_M",
    "size_gb": 17,
    "bits_per_weight": 4.98,
    "notes": "published tag qwen3.8:27b, language model file"
  },
  {
    "label": "Q5_K_M",
    "size_gb": 19.5,
    "bits_per_weight": 5.7,
    "notes": "computed, no official library tag exists"
  },
  {
    "label": "NVFP4",
    "size_gb": 18,
    "bits_per_weight": 5.27,
    "notes": "published tag 27b-nvfp4, MLX build, one file including the vision encoder"
  },
  {
    "label": "Q8_0",
    "size_gb": 29,
    "bits_per_weight": 8.5,
    "notes": "published tag 27b-q8_0, language model file"
  },
  {
    "label": "BF16",
    "size_gb": 55,
    "bits_per_weight": 16.1,
    "notes": "published tag 27b-bf16, language model file"
  }
]

공식은 한 줄이다. 가중치의 바이트 수 = 매개변수 수 * 가중치당 비트 수 / 8이다. 정확히 4비트라면 27.3 billion 매개변수는 13.7 GB가 된다. 제공된 Q4_K_M 태그의 language model 파일은 17 GB이며, 실제 가중치당 비트 수는 4.98비트다.

이 차이는 오류가 아니다. K-quant 형식은 모든 tensor를 명목상 비트 폭으로 저장하지 않는다. 압축으로 품질이 가장 크게 떨어지는 tensor에는 더 많은 비트를 할당한다. 제공된 qwen3.8:27b 파일에 대한 Ollama의 tensor 목록을 보면 다음 항목이 Q6_K로 저장된다. output layer, feed-forward down projection의 약 절반, full-attention layer 중 약 절반에 해당하는 attention V projection, linear-attention layer에 있는 fused QKV projection의 약 절반이다. 작은 normalisation tensor는 32-bit 정밀도를 그대로 유지한다. token embedding, attention Q 및 K projection, feed-forward gate 및 up projection은 모델의 대부분과 마찬가지로 Q4_K를 유지한다. 형식 이름은 평균을 나타내며, 실제 평균은 5에 가깝다. 같은 현상은 반대쪽에서도 나타난다. BF16의 55 GB는 고정된 16비트가 아니라 가중치당 16.1비트다. 이 경우 token embedding도 다른 항목과 마찬가지로 BF16이며, 작은 초과분은 파일의 metadata, 32-bit로 유지되는 normalisation tensor, 그리고 가장 가까운 GB 단위로 반올림된 표시 크기에서 발생한다.

language model 파일만이 아니라 전체 태그를 기준으로 용량을 계산해야 한다. qwen3.8:27b의 모든 GGUF 태그에는 약 0.9 GB의 vision projector도 포함되므로 Q4_K_M 태그는 18 GB로 표시된다.

공식 qwen3.8 library entry에는 Q5_K_M의 공개 태그가 없으므로 19.5 GB 행은 측정값이 아니라 해당 형식의 일반적인 가중치당 5.7비트를 사용해 계산한 값이다. Q8_0은 Q4보다 거의 2배 크며 29 GB다. CPU만 사용하는 시스템에서는 이 차이로 token당 memory traffic도 2배가 되므로 초당 token 수가 대략 절반으로 줄어든다. 이 이유만으로도 여기서는 Q4_K_M을 기본값으로 사용하는 것이 적절하다. 메모리 사용량이 아니라 품질 측면에서 이 결정을 판단하려면 Q4, Q8 및 fp16을 자세히 비교한 내용에서 출력 품질이 실제로 저하되기 시작하는 지점을 확인할 수 있다.

컨텍스트가 늘어날 때 KV 캐시에 필요한 비용

가중치는 고정 비용이다. KV 캐시(키 및 값 캐시, 모델이 이미 확인한 각 토큰에 대해 유지하는 attention 상태)는 컨텍스트 길이에 따라 직선적으로 증가하며, 대부분의 사용자가 실제로 RAM이 부족해지는 지점도 여기다.

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

이 수치는 모델 자체의 config 파일에서 가져온 것이다. Qwen3.8-27B는 Qwen3.6-27B와 마찬가지로 hybrid-attention 모델이다. 64개 layer 중 16개만 full attention을 사용하며 모든 토큰마다 증가하는 캐시를 유지한다. 이 layer들은 GQA(grouped-query attention)에서 4개의 key/value head와 256의 head dimension을 사용한다. 나머지 48개 layer는 linear attention(Gated DeltaNet)을 사용하고 대신 고정 크기의 상태를 유지한다. 내가 계산한 바로는 컨텍스트 길이와 관계없이 conversation slot당 약 150 MB다. 따라서 f16에서는 토큰당 64 KiB가 필요하며, 32k 토큰에서는 2 GB, 128k에서는 8 GB가 된다. 이 계산을 자신의 장비에 그대로 적용하지 말아야 한다. 모델을 로드한 뒤 ollama ps의 SIZE 열을 확인해야 한다. 이 열은 가중치, 캐시, 오버헤드를 합친 단일 수치를 보여준다.

모델 카드에 표시된 256K 컨텍스트는 이 아키텍처에서 사용할 수 있는 범위지만, 비용이 없는 것은 아니다. 이를 f16으로 채우려면 가중치에 이미 17 GB를 사용한 시스템에서 가중치 외에 약 16 GB의 캐시가 추가로 필요하다. Ollama는 기본적으로 전체 window를 제공하지 않는다. Ollama의 context-length 문서에 따르면 기본값은 VRAM이 24 GiB 미만이면 4k 토큰, 24~48 GiB이면 32k, 48 GiB 이상이면 256k다. CPU-only VPS에는 VRAM이 전혀 없으므로 4k tier가 적용된다. OLLAMA_CONTEXT_LENGTH를 사용해 의도적으로 값을 높여야 한다. 이 server-wide 변수만 조정할 수 있는 것은 아니다. 개별 request에서 num_ctx 설정을 사용하면 다른 모든 작업에는 낮은 기본값을 유지하면서 하나의 긴 작업에만 더 큰 window를 할당할 수 있다. 값을 단계적으로 높이고 변경할 때마다 ollama ps을 확인해야 한다.

캐시 사용량을 줄이는 설정은 2가지다. OLLAMA_KV_CACHE_TYPE=q8_0는 캐시를 16비트 대신 8비트로 저장하므로 32k 토큰에서 캐시가 2 GB에서 1 GB로 줄어든다. 이 기능에는 flash attention이 필요하므로 OLLAMA_FLASH_ATTENTION=1도 설정해야 한다. 적용되었다고 가정하지 말고 ollama ps에서 실제 감소 여부를 확인해야 한다. 이전에 캐시 유형을 변경한 적이 없다면 Ollama의 KV 캐시에서 q8_0과 f16을 비교하는 안내에서 두 변수를 설정하고 변경 전후의 수치를 확인하는 방법을 설명한다. OLLAMA_NUM_PARALLEL=1도 그만큼 중요하다. Ollama는 여러 request를 동시에 처리할 수 있으며 각 slot은 자체 context 영역을 사용한다. 따라서 parallelism을 높이면 예상한 캐시 사용량이 조용히 배수로 증가한다. 현재 기본값은 이미 1이며, 아래 override가 이를 1로 고정한다. 여러 사람이 이 장비를 사용할 예정이라면 문제가 시작되는 지점은 이 배수 증가다. self-hosted 모델이 처리할 수 있는 동시 사용자 수는 core 수보다 훨씬 먼저 cache slot과 queue depth에 의해 결정된다.

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": 128,
    "q8_max_ctx_ktok": null,
    "notes": "Q4 fits with room for long context. Q8 weights fit, but usable context needs a measured total memory budget."
  },
  {
    "label": "64 GB",
    "q4_max_ctx_ktok": 256,
    "q8_max_ctx_ktok": 256,
    "notes": "Both fit with the full 256K window."
  }
]

두 숫자는 가중치와 vision projector를 함께 적재한 뒤, f16 cache를 사용하고 운영 체제에 약 1.5 GB와 소량의 여유 메모리를 남긴 headless Linux VPS에서 사용할 수 있는 context의 천 token 수로 읽으면 된다. 0은 가중치 자체가 적재되지 않으므로 아무것도 사용할 수 없다는 뜻이다. null은 가중치는 적재되지만 해당 등급에서 확인된 사용 가능한 context 수치가 없다는 뜻이다.

8 GB와 16 GB는 경계에 있는 선택지가 아니다. 17 GB의 가중치는 16 GB RAM에 들어가지 않으며, context 설정을 바꿔도 해결되지 않는다. swap을 추가해도 문제가 해결되지 않는다. Ollama는 GGUF 파일을 memory-map하므로 resident page가 RAM을 초과하면 kernel이 해당 페이지를 계속 내보냈다가 다시 읽는다. 그러면 모든 token을 처리할 때마다 디스크에서 GB 단위의 데이터를 읽게 된다. 시스템은 높은 iowait 상태에 머물고 초당 1 token에도 훨씬 못 미치는 속도를 낸다.

32 GB가 최소 기준이다. 가중치가 17 GB를 차지하고 vision projector가 약 0.9 GB를 추가하므로, 약 12.5 GB가 남는다. 이 용량이면 여유를 두고 f16 context 약 128k token을 처리할 수 있다. 29 GB인 Q8_0 가중치도 32 GB 안에 들어가지만, 사용 가능한 context는 vision projector, cache, 운영 체제, runtime 메모리에도 영향을 받는다. 이 등급에서 Q8을 실행할 수 있다고 보기 전에 시스템에서 전체 메모리 사용량을 확인해야 한다.

64 GB는 여유가 충분하다. Q4는 전체 256k window를 사용할 수 있고, Q8_0 가중치도 그 뒤에 전체 256k를 확보한 상태로 적재된다. Q8을 사용하기 위해 64 GB를 구입하기 전에 무엇을 얻는지 분명히 해야 한다. 이미 느린 시스템에서 속도는 절반이 되고 출력 품질만 약간 향상된다. Q4는 32 GB 구성에서도 이미 128k token에 도달하므로, 대부분의 사용자에게 더 나은 선택이다.

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

dense model에서 토큰 1개를 생성하려면 모든 weight를 메모리에서 한 번 읽어야 한다. 일부만 읽는 것이 아니다. 전부 읽는다. 따라서 속도 한계는 코어 수가 아니라, weight 크기로 나눈 memory bandwidth다. 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
  }
]

이 값은 측정값이 아니라 상한값이다. 실제 출력 속도는 표시된 값의 약 50~70% 수준이다. 메모리 지연과 불완전한 prefetching 때문에 이론상 최대치에 도달할 수 없기 때문이다. 2채널 DDR4-3200 VPS의 상한은 초당 3 tokens이므로, 실제로는 약 2 tokens/s를 예상해야 한다. 2채널 DDR5-4800 서버의 상한은 4.5이므로, 실제로는 약 3 tokens/s를 예상해야 한다.

대형 서버 행에는 주의가 필요하다. 12채널 EPYC 플랫폼은 460.8 GB/s의 memory bandwidth와 초당 27.1 tokens의 상한을 제공한다. 그러나 EPYC 전체를 임대하는 것은 아니다. Memory bandwidth는 해당 장비의 모든 tenant가 공유하는 호스트 전체 리소스다. 따라서 8 vCPU slice에 12채널의 전용 bandwidth가 제공되는 것은 아니다. GPU 중심 가이드는 이 점을 완전히 생략하는 경우가 많다. 동일한 model에서도 vCPU 수가 같은 2개의 VPS plan이 3배까지 차이 날 수 있는 이유가 여기에 있다.

같은 이유로 vCPU를 늘려도 일찍부터 효과가 사라진다. 코어가 memory controller가 전달할 수 있는 속도보다 빠르게 데이터를 요청하기 시작하면, 추가 thread는 scheduling overhead만 늘리고 다른 효과는 없다. Ollama에는 thread 수를 지정하는 서버 전체 환경 변수가 없다. 따라서 요청의 options에서 num_thread을 physical core 수로 설정하고 측정한 다음, 그 절반도 시도한다. 여러 shared plan에서는 더 낮은 설정이 더 빠르다.

Prompt 처리 방식은 다르다. 첫 토큰이 나타나기 전에 입력 전체를 처리하는 prefill은 bandwidth bound가 아니라 compute bound다. 따라서 코어 수에 따라 속도가 향상된다. 실제로는 큰 prompt에서 출력이 시작되기 전 긴 지연이 발생한 뒤, 앞에서 설명한 느리고 일정한 속도로 출력이 이어진다. --verbose으로 두 구간을 각각 측정한다. 이 명령은 모든 요청마다 prompt eval rate과 eval rate를 출력한다.

dense 27B가 너무 느리다면 CPU를 포기하기 전에 qwen3.6:35b-a3b tags를 확인한다. 이 tags는 전체 27.3 billion parameters 대신 토큰마다 약 3 billion parameters만 활성화한다. 따라서 디스크의 file은 더 커도 토큰당 memory traffic은 거의 한 자릿수 배만큼 감소한다. RAM footprint와 속도를 맞바꾸는 것이다. 여기서는 runtime 선택도 중요하다. 동일한 inference code를 사용하더라도 Ollama와 llama.cpp는 서로 다른 CPU tuning control을 제공한다.

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 추론이 적합하다. 예를 들어 문서 묶음을 밤새 요약하거나, 사용자가 자는 동안 매일 실행되는 분류 작업이 이에 해당한다. 사람이 결과를 기다리는 순간, 또는 요청이 서버가 처리할 수 있는 속도보다 빠르게 도착하는 순간 GPU를 대여해야 한다. CPU 런타임이 한 번에 하나의 요청만 처리하는 것은 아니다. llama.cpp server는 CPU와 GPU 모두에서 병렬 디코딩과 연속 배칭을 지원한다고 문서화하고 있으며, Ollama도 캐시를 더 사용하는 대신 병렬 요청을 처리할 수 있다. 기준은 측정한 처리 속도와 요청 도착 속도의 비교다. 따라서 실제 환경과 유사한 배치를 자체 서버에서 실행해 시간을 측정해야 한다. 요청이 그 속도보다 빠르게 도착하면 대기열이 증가한다.

비용 비교는 겉보기보다 단순하지 않다. 64 GB VPS는 모델이 로드되었는지와 관계없이 한 달 내내 매시간 요금이 부과된다. 반면 시간 단위 GPU 대여는 연산 요금과 스토리지 요금을 분리하며, GPU를 중지한 뒤에도 스토리지 요금만 계속 부과될 수 있다. 실제 사용량이 하루 2시간이라면 대여한 GPU가 더 빠르고 저렴할 수 있다. 먼저 사용률을 계산한 다음 비용을 비교해야 한다. GPU가 포함된 VPS 선택에서는 인스턴스 자체에서 확인할 항목을 다루며, GPU에서 동시 요청을 처리하면 vLLM이 Ollama보다 앞선다에서는 vLLM이 요청을 적절히 배칭하기 때문에 유리한 이유를 설명한다.

사람들이 자주 잊는 세 번째 방법도 있다. 배치 작업에는 27B 모델을 CPU에서 계속 사용하고, 대화형 경로 앞에는 호스팅 API 모델을 배치하면 된다. 하나의 모델이 두 작업을 모두 처리해야 할 이유는 없다.

Ollama 설치 및 자체 서버 성능 측정

설치 스크립트는 공식 스크립트이며, 전용 ollama 사용자로 실행되는 systemd 서비스를 설정한다.

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

ollama --version는 Qwen 3.8 27B를 지원하는 첫 릴리스인 0.32.12 이상을 출력해야 한다. 무엇이든 가져오기 전에 free -g를 확인한다. 이 값은 GiB 단위로 표시되므로, RAM 32 GB로 광고된 요금제도 total 열에는 약 29로 표시될 수 있다. 사용 가능한 메모리를 앞에서 계산한 가중치와 캐시 예산과 비교한다.

셸이 아니라 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.8:27b
ollama run qwen3.8:27b --verbose "Name two Linux distributions."

--verbose 출력이 확인하려던 측정값이다. eval rate은 생성 중 초당 토큰 수다. prompt eval rate은 prefill 속도다. load duration는 디스크에서 가중치를 읽는 데 걸린 시간이다. 따라서 OLLAMA_KEEP_ALIVE=60m가 설정되어 있다. CPU에서는 요청마다 디스크에서 17 GB를 다시 읽는 비용이 요청 자체보다 크기 때문이다. 기본 유휴 시간 제한은 5분이다. 항목 사이에 간격이 있는 배치 큐에서는 이 로드 비용을 반복해서 지불하게 될 만큼 짧다. 모델을 상주 상태로 유지하는 옵션에는 요청별 keep_alive 필드와 재부팅 후에도 설정을 유지하는 방법이 모두 포함되어 있다.

모델이 로드된 동안 두 번째 터미널에서 메모리 사용량을 확인한다.

ollama ps

SIZE 열은 KV 캐시를 포함한 실제 메모리 사용량이다. 가중치, vision projector, 그리고 KV 차트에서 해당 context length에 해당하는 행의 합계와 비슷해야 한다. 8-bit 캐시에서 8192 토큰을 사용할 때 캐시의 증가분은 약 0.25 GB에 불과하다. 캐시가 f16으로 유지되었다면 0.5 GB가 되었을 값에 비해 작으며, 여기에 고정된 linear-attention 상태가 추가된다. PROCESSOR 열은 100% CPU로 표시되어야 한다. 다른 값이 표시되면 무언가가 GPU를 사용하고 있는 것이다. 이 경우 이 가이드의 속도 수치는 해당 서버의 성능을 나타내지 않는다.

실패 유형과 실제로 보게 되는 정확한 문자열

모델이 로드되지 않는다. Ollama는 두 수치를 모두 표시하는 줄을 출력하며, 형식은 model requires more system memory (18.6 GiB) than is available (15.2 GiB)과 같다. 커널이 처리하도록 두지 않고 Ollama가 메모리를 할당하기 전에 확인하므로, 이는 정상적인 실패 유형이다. context length를 줄이거나 더 작은 tag로 변경하거나 더 큰 플랜으로 이동한다.

응답 중간에 프로세스가 사라진다. 클라이언트에는 유용한 내용이 표시되지 않고, journalctl -u ollama -n 50에는 서비스가 다시 시작되는 내용이 표시된다. dmesg -T | tail을 실행한다. Out of memory: Killed process ... (ollama)라는 줄이 있으면 kernel OOM killer가 프로세스를 종료한 것이다. 사전 로드 확인은 통과했지만 긴 대화 중 cache가 예상치를 초과할 때 발생한다. context length를 줄인다.

pull이 즉시 실패한다. Error: pull model manifest: file does not exist은 해당 tag가 library에 없다는 뜻이다. 아직 release되지 않은 version number를 사용해도 정확히 같은 결과가 나오며, tag에 오타가 있어도 마찬가지다. qwen3.8:27b 자체는 실제 tag이므로, 해당 tag를 그대로 사용했는데 실패한다면 먼저 오타를 확인한다. 네트워크를 원인으로 판단하기 전에 library 페이지에서 tag를 확인한다. 실제 tag는 pull되지만 실행되지 않는다면 ollama --version를 0.32.12와 비교한다.

모든 기능은 작동하지만 속도가 지나치게 느리다. RAM이 충분한 시스템에서 초당 1 token 미만으로 생성된다면 compute보다 paging을 의심해야 한다. 생성 중에 vmstat 1을 실행한다. si 또는 so 열의 값이 0이 아니면 kernel이 swap을 사용하고 있다는 뜻이다. context를 줄이거나 로드한 model 수를 줄인다. swap 활동 없이 wa이 계속 높다면 memory-mapped weights를 디스크에서 반복해서 다시 읽고 있다는 뜻이다. 즉, 실제로 메모리에 맞지 않는 것이다.

첫 token까지 30초가 걸리지만 이후 출력 속도는 빨라진다. 이는 prefill이며 정상적인 동작이다. 긴 system prompt는 cache가 적중하지 않는 모든 요청에서 처리 비용이 발생한다. 다른 항목을 조정하기 전에 system prompt를 줄인다.

CPU만 사용하는 27B 모델이 실제로 잘하는 일

기대치는 희망이 아니라 수치에 맞춰 설정해야 한다. 초당 2~4토큰이면 500토큰 응답에 2~4분이 걸린다. 이는 채팅에는 사용할 수 없지만 큐 처리에는 충분히 실용적이다. 응답 전에 사고하는 모델은 숨겨진 추론 토큰도 응답과 같은 느린 속도로 생성하므로 계산 결과가 더 나빠진다. 따라서 작업에 맞춰 추론 수준을 조정하는 것은 모델을 교체하지 않고 응답 시간을 줄일 수 있는 몇 안 되는 방법 중 하나다. 문서 요약, 대량 태그 지정, 파일 백로그에서 필드 추출, 무인 코드 검토는 응답을 기다리는 사람이 없으므로 이런 속도도 감당할 수 있다. 코딩 지원은 그 경계에 있다. 따라서 직접 호스팅하는 모델에 코딩 에이전트를 연결하는 것은 커밋 메시지와 테스트 스캐폴딩 같은 백그라운드 작업에는 효과적이지만, 사용자가 기다리는 인라인 제안에는 적합하지 않다.

핵심은 개인정보 보호다. 모델은 사용자가 임대하고 관리하는 하드웨어에서 실행되며, 요청이 장비 밖으로 나가지 않고, 토큰별 요금도 없다. 초당 3토큰에 불과하더라도 규제 대상 데이터에는 이점이 크다. 다만 대안을 현실적으로 비교해야 한다. 프런티어급 모델을 자체 호스팅하려면 한 자릿수 차원이 아니라 10배 더 많은 하드웨어가 필요하다. 27B CPU 모델은 출력 결과를 여전히 읽을 가치가 있는 범위에서 가장 저렴한 지점이다.

이를 벤치마크하려면 실제 구조화된 입력이 필요하다. 대부분의 공개 데이터 API는 처리량을 측정하기도 전에 계정을 요구한다. Strasmore의 데모 스키마는 US 주식 및 옵션 데이터에 대한 읽기 전용 SQL을 설명하며, API key와 signup이 필요 없다. 이 스키마는 데이터베이스로 한정한 테이블 이름을 사용한다: https://ai.strasmore.com/api/demo/sql?sql=SELECT ticker, close FROM global_markets.delayed_stocks_minute_aggs LIMIT 5. 데모의 제한은 호출당 500행과 20초이며, 데이터 이력은 1 January 2025부터 제공된다. 따라서 초당 2토큰을 처리하는 장비가 소비할 수 있는 양보다 충분히 많다. 전체 열 목록은 https://ai.strasmore.com/api/demo/schema에 있다.

Ollama를 처음 설치한다면 VPS에서 Ollama를 실행하는 전체 안내에서 이 가이드가 이미 구성되어 있다고 가정하는 서비스 설정, HTTP API, firewall rule을 설명한다. port 11434를 인터넷에 노출하지 않아야 한다. Ollama의 로컬 API에는 인증이 필요하지 않으므로 해당 포트에 접근할 수 있는 모든 사용자가 모델을 사용할 수 있다.

FAQ

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

있습니다. 2026년 10월 21일 기준으로 Ollama 라이브러리에 qwen3.8 항목이 있으며, qwen3.8:27b(latest 태그도 사용)는 27.3 billion parameter dense model을 Q4_K_M으로 양자화한 18 GB 빌드입니다. vision projector와 256K context window가 포함되어 있습니다. 로컬에서 실행되며 Ollama v0.32.12 이상이 필요합니다. 이전의 qwen3.6:27b 및 qwen3.5:27b 태그도 계속 등록되어 있습니다. 현재 목록은 https://ollama.com/library/qwen3.8/tags에서 확인합니다. 존재하지 않는 태그를 지정하면 Error: pull model manifest: file does not exist 오류가 발생합니다.

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

Q4_K_M 기준으로 32 GB가 현실적인 최소 용량입니다. 가중치는 17 GB입니다. vision projector에 약 0.9 GB가 추가되고, 운영 체제에는 약 1.5 GB가 필요합니다. f16에서 context 16,000 tokens마다 KV cache가 약 1 GB씩 추가됩니다. 모델의 64개 layer 중 16개만 증가하는 cache를 유지하기 때문입니다. 16 GB 요금제는 가중치조차 모두 담을 수 없습니다. 파일이 memory-mapped되므로 swap도 도움이 되지 않습니다. 커널이 각 token마다 디스크에서 파일을 다시 읽기 때문입니다. 64 GB를 사용하면 Q8_0 가중치가 29 GB인 경우에도 전체 256K window를 사용할 여유가 있습니다.

CPU에서 27B 모델은 초당 몇 tokens를 처리합니까?

메모리 bandwidth를 가중치 크기로 나눈 뒤 그 값의 50~70%를 적용하면 됩니다. 2-channel DDR4-3200 VPS의 이론적 한계는 초당 3 tokens에 가깝고, 실제 처리량은 약 2 tokens per second입니다. 2-channel DDR5-4800 서버의 이론적 한계는 초당 4.5에 가깝고, 실제 처리량은 약 3 tokens per second입니다. channel 수가 더 많은 server platform은 사양상 훨씬 좋아 보일 수 있습니다. 그러나 host의 모든 tenant가 메모리 bandwidth를 공유하므로 ollama run qwen3.8:27b --verbose으로 직접 측정하고 eval rate 행을 확인해야 합니다.

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

거의 모든 경우에 Q4_K_M을 사용해야 합니다. Q8_0은 29 GB이고 Q4_K_M은 17 GB이므로, 가중치는 32 GB 안에 들어갑니다. 그러나 projector, cache, 운영 체제와 runtime이 차지하는 공간 때문에 여유가 거의 없습니다. 64 GB를 사용하면 긴 context를 사용할 수 있습니다. Q8_0은 token마다 거의 2배 많은 메모리를 이동시키므로 초당 tokens가 대략 절반으로 줄어듭니다. 27B 모델에서 대부분의 작업은 Q4_K_M과 Q8_0 사이의 품질 차이가 작습니다. RAM은 더 긴 context에 사용하는 편이 낫습니다. 긴 context는 모델의 표현 방식보다 수행할 수 있는 작업의 범위를 바꾸기 때문입니다.

대형 RAM VPS보다 GPU를 임대하는 편이 저렴한 경우는 언제입니까?

사용률이 낮거나 사람이 결과를 기다리는 경우입니다. 24 GB 메모리의 GPU는 이 가중치에서 이론적으로 초당 약 59 tokens를 처리할 수 있습니다. 일반적인 VPS의 예상 처리량은 초당 2 또는 3 tokens입니다. 시간 단위 GPU compute 요금은 instance가 중지되면 더 이상 부과되지 않지만, persistent storage에는 계속 비용이 발생할 수 있습니다. 64 GB VPS는 모델이 load된 상태인지와 관계없이 한 달 내내 요금이 부과됩니다. 실제로 하루에 몇 시간 동안 token을 생성하는지 계산해야 합니다. 손익분기점은 rental rate, runtime 및 persistent storage 요금에 따라 달라집니다. 낮은 우선순위로 계속 실행하는 batch 작업에서는 항상 켜져 있는 VPS가 유리합니다.