Qwen3.8-27B는 로컬 에이전트 코딩에 가장 좋은 LLM일까

Qwen3.8-27B는 로컬 코딩 에이전트용 27B 모델을 고를 때 가장 먼저 검증할 후보 중 하나입니다. 하지만 출시 직후의 벤치마크만으로 ‘가장 좋은 모델’이라고 부르기는 어렵습니다.

에이전트 코딩은 자동완성이나 한 번의 코드 생성이 아닙니다. 저장소 지침을 읽고, 정확한 도구를 호출하고, 여러 파일을 수정하고, 테스트 실패를 해석한 뒤 다시 고쳐서 리뷰 가능한 diff를 만드는 과정입니다. 그래서 핵심 질문은 모델이 로드되는지가 아니라, 현재 장비와 런타임에서 이 전체 루프를 허용 가능한 시간과 사람의 수정 비용으로 끝내는가입니다.

하드웨어별로 먼저 내릴 수 있는 판단

24GB 한 장에서 Q4를 실행할 수 있다는 말은 호환성 정보일 뿐입니다. 저장소를 읽은 뒤의 실제 컨텍스트, processor split, tokens per second를 봐야 합니다. Apple Silicon도 총 통합 메모리보다 운영체제와 개발 도구가 사용한 뒤 남는 용량이 중요합니다.

Qwen3.8-27B에서 확인된 사실

공식 모델 카드는 Qwen3.8-27B를 Apache-2.0의 27B dense causal language model로 설명합니다. vision encoder가 있어 이미지와 비디오를 이해하고, thinking이 기본으로 활성화되며 reasoning_effort와 preserve_thinking을 지원합니다. native context는 262,144 tokens이고 YaRN으로 1,000,000까지 확장할 수 있습니다.

Qwen이 공개한 코딩 결과는 Terminal-Bench 2.1 73.0, SWE-bench Pro 61.7, NL2Repo-Bench 42.3, DeepSWE 1.1 42.2, QwenSWEBench 79.0입니다. 이 수치는 모델을 테스트 목록에 넣을 근거가 됩니다. 다만 업체가 밝힌 harness와 설정에서 나온 결과이며, 로컬 GGUF 양자화에 대한 독립 실측은 아닙니다. 일부 benchmark는 수정된 task를 쓰거나 in-house이므로 다른 모델 점수와 단순 비교하면 안 됩니다.

또 Qwen3.8 세대 발표에서 소개된 Max의 장기 자율 프로젝트를 27B 모델의 성과로 옮겨 적을 수 없습니다. 같은 세대라는 사실은 같은 규모와 완주율을 의미하지 않습니다.

18.97GB Q4가 24GB 환경을 보장하지 않는 이유

현재 ggml-org의 GGUF 저장소에 있는 파일 크기는 다음과 같습니다.

• Qwen3.8-27B-Q4_K_M.gguf: 약 18.97GB
• Qwen3.8-27B-Q8_0.gguf: 약 28.60GB
• BF16 vision projector: 약 0.93GB

이 숫자는 디스크 파일 크기입니다. 실행할 때는 weights 외에도 KV cache, runtime buffer, 운영체제, 코딩 에이전트, 저장소 인덱스, 컴파일러와 test runner가 메모리를 사용합니다. 컨텍스트를 늘리면 KV cache도 커집니다. vision 입력이 필요하면 projector도 추가됩니다.

Ollama의 context length 문서는 agents와 coding tools에 최소 64K를 권장하면서, 긴 컨텍스트가 더 많은 메모리를 요구한다고 안내합니다. 자동 기본값은 24GiB 미만 4K, 24~48GiB 32K, 48GiB 이상 256K입니다. 24GB 제품에서 Q4가 로드돼도 agent에 필요한 64K가 자동으로 확보되는 구조가 아닙니다.

실행 뒤에는 ollama ps에서 CONTEXT와 PROCESSOR를 확인해야 합니다. CPU offload가 크면 짧은 답변은 그럭저럭 보여도, tool call과 테스트가 반복되는 동안 총시간이 크게 늘어납니다.

가장 작은 로컬 경로부터 확인하기

ggml-org는 최신 llama.cpp를 위한 간단한 실행 경로를 제공합니다.

bash
llama serve -hf ggml-org/Qwen3.8-27B-GGUF

Qwen3.8-27B는 2026년 8월 14일에 나온 신모델이므로 현재 llama.cpp build를 사용해야 합니다. 오래된 chat template나 thinking 처리 문제를 모델의 추론 능력으로 오해하지 않기 위해서입니다.

Ollama에서는 공식 GGUF import 방식으로 Modelfile을 만들 수 있습니다.

text
FROM ./Qwen3.8-27B-Q4_K_M.gguf
PARAMETER num_ctx 65536
PARAMETER temperature 1
PARAMETER top_p 0.95
PARAMETER top_k 20

bash
ollama create qwen3.8-27b-local -f ./Modelfile
ollama run qwen3.8-27b-local
ollama ps

Qwen Code를 붙일 때는 공식 provider 문서의 openai provider로 Ollama, LM Studio, vLLM의 local OpenAI-compatible endpoint를 연결할 수 있습니다. Ollama에는 http://your-ollama-host:11434/v1을 넣고 your-ollama-host를 agent process가 해석할 수 있는 실제 호스트명으로 바꿉니다. model id도 서버가 노출하는 이름과 일치해야 합니다.

도구 호출이 깨지면 먼저 runtime 버전, chat template, 컨텍스트 잘림, API schema를 확인합니다. 같은 조건에서 tool name이나 arguments가 반복적으로 잘못된다면, 그때는 unattended coding에 대한 실제 No-Go 신호입니다.

벤치마크 대신 저장소 작업으로 검증하기

팀이 정답을 판단할 수 있는 8~12개 작업을 준비합니다. 작은 bugfix, 여러 파일을 바꾸는 기능, 실패한 테스트에서 복구하는 작업, 저장소 지침을 따라야 하는 작업, 그럴듯하지만 잘못된 구현을 거부해야 하는 작업을 섞습니다.

각 작업에서는 다음을 남깁니다.

비교 모델마다 quantization, runtime, context, agent harness, task set을 같게 유지합니다. 가장 유용한 숫자는 생성 속도가 아니라 승인된 작업 한 건당 기계 시간과 사람의 수정 비용입니다. 느리지만 정확한 도구 호출로 끝내는 모델이, 빠르지만 세 번 반복하는 모델보다 생산적일 수 있습니다.

어떤 경우에 Go를 줄 수 있나

32GB 이상의 사용 가능한 메모리, 로컬 데이터 요구, 새 runtime을 유지할 운영 여력이 있다면 Qwen3.8-27B를 우선 평가해도 좋습니다. 24GB에서는 Q4와 제한된 text-only task로 시작하고, 결과를 조건부 Go로 보는 편이 안전합니다.

반대로 CPU offload가 크고, 거대한 monorepo 때문에 긴 컨텍스트가 항상 필요하거나, 무인 성공률이 로컬 통제보다 중요하다면 유일한 코딩 모델로 삼지 않는 것이 낫습니다. 작은 로컬 worker가 반복 작업을 맡고, 어려운 tail만 강한 hosted model로 넘기는 hybrid route가 승인된 작업 수를 더 많이 만들 수 있습니다.

Qwen3.8-27B가 가장 좋은 로컬 코딩 LLM인지는 출시일의 점수나 ‘단일 GPU 가능’이라는 문구가 정하지 않습니다. 여러분의 저장소에서 같은 작업을 반복해, 허용 가능한 메모리와 시간으로 검토 가능한 변경을 얼마나 자주 만드는지가 답입니다.