vLLM에서 Qwen3.6 27B가 llama.cpp에 비해 더 멍청하게 작동함

안녕하세요, 최근에 이미 보유하고 있던 RTX 5060Ti와 함께 사용할 새로운 RTX 5060Ti를 구매하여, 이제 32GB의 VRAM을 보유하게 되었습니다.

지금까지는 편의상 llama.cpp를 사용해 왔습니다. 정말이지 사용자 1명만 사용할 때는 훌륭하게 작동하지만, 이제는 저희 두 명이 사용하고 있어서 llama.cpp가 따라오지 못합니다. 사용자 2가 글을 쓰면 사용자 1의 캐시(cache)가 무효화되거나 그 반대의 상황이 자주 발생합니다.

지금까지 저는 llama.cpp를 시작하기 위해 항상 이 명령어를 사용해 왔습니다:

"Qwen3.6-27B": ttl: 0 filters: strip_params: "top_p, top_k, presence_penalty, frequency_penalty, temperature, min_p" setParamsByID: "${MODEL_ID}:coding": temperature: 0.6 top_p: 0.95 top_k: 20 min_p: 0.0 presence_penalty: 0.0 "${MODEL_ID}:general": temperature: 1.0 top_p: 0.95 top_k: 20 min_p: 0.0 presence_penalty: 0.0 "${MODEL_ID}:instruct": chat_template_kwargs: enable_thinking: false temperature: 0.7 top_p: 0.8 top_k: 20 min_p: 0.0 presence_penalty: 1.5 cmd: | ${llama-server} --model /home/daniele/models/Qwen3.6-27B-UD-Q5_K_XL.gguf \ --threads 9 --ctx-size 120000 -fa 1 --jinja -np 2 -ngl 99 --spec-type draft-mtp --spec-draft-n-max 3 --chat-template-kwargs '{"preserve_thinking": true}' --cache-ram 24000 --mmproj /home/daniele/models/mmproj-BF16.gguf --no-mmproj-offload -kvu --ctx-checkpoints 6 -b 8192 -ub 512 -mg 0 -ctv q8_0 -ts 0.5,0.5

설정된 것으로 보이는 이 파라미터(parameters)들은 제가 수많은 시도 끝에 하나씩 튜닝한 것이며, 제 하드웨어에서 찾은 최선의 설정입니다.

그래서 저는 vLLM으로 전환하기로 결정했고, Qwen3.6-27B-UD-Q5_K_XL.gguf와 (가중치 기준) 거의 비슷한 크기를 가진 cyankiwi/Qwen3.6-27B-AWQ-INT4 모델을 사용했습니다.

저는 다음과 같이 vLLM을 실행합니다:

docker run --rm --gpus all \ --name vllm \ -v /mnt/fast_data/huggingface_cache:/root/.cache/huggingface \ -v /mnt/fast_data/vllm_cache:/root/.cache/vllm \ -v /mnt/fast_data/models/chat_template.jinja:/templates/chat.jinja \ -v /home/daniele/Desktop/qwen36_27b_parser:/plugins \ -v /mnt/fast_data/vllm_ec_cache:/ec_cache \ -e PYTORCH_CUDA_ALLOC_CONF=max_split_size_mb:512 -p 8002:8000 \ -e QWEN36_PARSER_DEBUG=1 \ --ipc=host \ vllm/vllm-openai:v0.23.0 \ cyankiwi/Qwen3.6-27B-AWQ-INT4 \ --served-model-name qwen3.6-27b \ --trust-remote-code \ --max-model-len 100000 \ --max-num-seqs 4 \ --kv-cache-dtype fp8 \ --gpu-memory-utilization 0.79 \ --reasoning-parser qwen3 \ --speculative-config '{"method":"mtp","num_speculative_tokens":3}' \ -tp 2 \ --enable-auto-tool-choice \ --tool-call-parser qwen36_27b \ --tool-parser-plugin /plugins/qwen36_27b_parser.py \ --enable-prefix-caching \ --override-generation-config '{"temperature":0.6,"top_p":0.95,"top_k":20,"min_p":0.0,"presence_penalty":0.0,"repetition_penalty":1.0}' \ --enable-prompt-tokens-details \ --default-chat-template-kwargs '{"preserve_thinking": true}' --kv-offloading-size 16 --kv-offloading-backend native --chat-template /templates/chat.jinja --enable-request-id-headers

솔직히 말씀드리면... 정말 악몽 같았습니다. 말도 안 될 정도로 많은 문제들이 발생했고, 어떤 경우에는 모델이 완전히 뇌가 절제된(lobotomized) 것처럼 작동했습니다 (QuantTrio/Qwen3.6-27B-AWQ로 시도했을 때). 그 후 sakamakismile/Qwen3.6-27B-Text-NVFP4-MTP와 Lorbus/Qwen3.6-27B-int4-AutoRound도 시도해 보았습니다.

하지만 이 경우에도 모델은 (이전보다는 조금 덜하지만) 여전히 뇌가 절제된 듯한 모습을 보였으며, 수많은 도구 호출(tool calls) 오류를 범하고 스스로 멈춰버리곤 했습니다. 이는 일시적인 현상이 아니었습니다. 특별한 확장 기능이 없는 순정 Pi(stock Pi) 상태에서도, 대화의 첫 번째 메시지부터 도구 호출이 최소 60%의 확률로 깨졌습니다.

그래서 약간의 노력을 기울여 llama.cpp의 Gemma31B UD5XL을 사용하여 모델의 오류를 가로채는 Python 기반의 커스텀 파서 (custom parser)를 직접 만들었습니다. 제가 관찰한 가장 흔한 오류들은 다음과 같습니다:

• 꺾쇠괄호 (angle brackets)를 누락함
• 구문 (syntax)을 망가뜨림, 예를 들어 <function=edit><parameter=content> 대신 <parameter=edit>... completely baked...와 같이 작성함

lama.cpp를 사용할 때는 이런 문제들을 전혀 겪지 않았습니다. qwen3_coder가 포함된 공식 템플릿부터 qwen3_xml, 그리고 froggeric의 템플릿(https://huggingface.co/froggeric/Qwen-Fixed-Chat-Templates)까지 3~4가지 채팅 템플릿 (chat templates)을 시도해 보았지만, 모두 정도의 차이만 있을 뿐 동일한 문제를 보였습니다.

현재 제가 찾은 가장 안정적인 방법은 위 시작 명령에서 보시는 것처럼 cyankiwi/Qwen3.6-27B-AWQ-INT4 모델과 저의 커스텀 파서를 사용하는 것입니다. 이를 통해 꽤 괜찮게 실행하고는 있지만, llama.cpp에서 프로그래밍 용도(단순한 vibe coding이 아닌 보조 용도)로 27b UD 5 XL을 많이 사용해 본 입장에서 볼 때, 모델의 지능적 예리함 (sharpness of intelligence)이 떨어졌음을 느낍니다.

하지만 현재 가장 눈에 띄는 문제는, 모델이 말 그대로 가끔 특정 메시지를 완전히 보지 못하는 것처럼 보인다는 점입니다!

기본적으로 저는 "X를 구현해 보자"라고 초기 프롬프트 (initial prompt)를 작성합니다.
그러면 모델은 "물론이죠! 파일을 확인해 보겠습니다..."라고 답합니다.
그리고 2/3개의 파일을 읽습니다.
그다음 "현재 작업할 구체적인 작업이 없습니다. pi-coding-agent 구조를 탐색 중이었지만 명확한 목표가 없었습니다. 무엇을 하고 싶으신가요?"라고 말합니다.

그래서 제가 "이 대화에서 보이는 내용을 메시지별로, 도구 (tool)별로 단계별로 말해줘"라고 물었습니다.
그러자 모델은 자신의 도구들을 첫 번째 메시지로 인식합니다! 다른 어떤 모델을 사용하면서도 살면서 이런 일은 단 한 번도 겪어본 적이 없습니다. 문제가 어디서 발생하는지 도무지 이해할 수 없습니다. 요청 (requests)을 로깅해 보기도 했고, vLLM 콘솔에서도 채팅 템플릿이 적용된 프롬프트가 출력되며 제 입력값이 명확히 보이는 것을 확인했습니다...

아니면 파일을 쓴 직후에 "잠깐, 파일이 존재하지 않아요, 다시 써야 해요"라고 말하기도 합니다. 아니, 진짜 이게 무슨 일인가요? 도구 호출 (tool call)은 성공했고 LiteLLM을 통해 로깅된 HTTP 요청에서도 확인할 수 있는데 말이죠...

제가 무언가 잘못하고 있는 걸까요? vLLM에서 양자화된 모델 (quantized models)이 llama.cpp에 비해 이렇게 훨씬 더 지능이 낮아지는 (lobotomized) 것이 정상인가요? vLLM은 llama.cpp보다 빠르고 동시 요청 (concurrent requests)을 훌륭하게 처리하기 때문에 정말 좋아하지만, 이런 식이라면 불가능합니다... 이 문제로 이틀 동안 머리를 싸매고 고민한 끝에, 여러분의 의견을 묻고 논의해보고자 이곳에 글을 쓰기로 결심했습니다.

추신: 이 글은 너무 답답한 나머지 한 번에 직접 손으로 작성했습니다. 실수가 있더라도 양해 부탁드리며, 여러분과의 대화는 언제나 환영합니다 :)
제출자: /u/DanielusGamer26
[링크] [댓글]