Qwen3.6 27B 在 vLLM 中的表现比在 llama.cpp 中更差

你好，我最近买了一张新的 RTX 5060Ti 搭配我已有的 RTX 5060Ti，现在我有 32GB 显存。之前为了方便我一直用 llama.cpp，说实话，只有一个用户使用时它表现得非常好，但现在有两个人在用，llama.cpp 就跟不上了，经常用户 1 的缓存会在用户 2 写入时失效，反之亦然。之前我一直用这个命令启动 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 你看到的这些参数配置是我经过多次尝试后一个一个调试出来的，这是我在我的硬件上找到的最佳方案。所以我决定切换到 vLLM，我用的是模型：`cyankiwi/Qwen3.6-27B-AWQ-INT4`，它的大小（指权重）大致相当于 `Qwen3.6-27B-UD-Q5_K_XL.gguf`。我用以下命令启动 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 说实话……那简直是一场噩梦，我遇到了无数问题。在某些情况下，模型完全像被切了脑叶（试过 QuantTrio/Qwen3.6-27B-AWQ），然后我试了 sakamakismile/Qwen3.6-27B-Text-NVFP4-MTP，还有 Lorbus/Qwen3.6-27B-int4-AutoRound，但即使这样，模型也像是被切了脑叶——稍微好一点，但出现了大量工具调用错误，它会自己卡住，而且不是偶发性的。使用没有任何特殊扩展的原版 Pi，工具调用从对话的第一条消息开始就有至少60%的概率失败。于是，我花了些功夫，结合 llama.cpp 上的 Gemma31B UD5XL，自己用 Python 写了一个自定义解析器，用来拦截模型的错误。我注意到最常见的错误有： - 忘记尖括号 - 语法混乱，比如本该是 `<function=edit><parameter=content>`，它却写成 `<parameter=edit>……完全混乱……` 用 llama.cpp 时我从没遇到过这些问题。我试了3/4种聊天模板，从官方自带的 qwen3_coder 到 qwen3_xml，再到 froggeric 的（https://huggingface.co/froggeric/Qwen-Fixed-Chat-Templates），但都不行，所有模板都有同样的问题，只是程度不同。目前我找到的最稳定方案就是上面启动命令里那个，搭配 `cyankiwi/Qwen3.6-27B-AWQ-INT4` 和我自定义的解析器。运行得还算不错，但我之前在 llama.cpp 上重度使用 27b UD 5 XL 做编程（不是 vibe coding，而是辅助编程），我意识到 vLLM 上的模型失去了那种智能上的锐利感。 不过现在最明显的问题是：模型有时似乎完全对某些消息视而不见！大致情况是：我写了初始提示“让我们实现 X”，它回复“好的！我来检查文件……”读了两三个文件，然后说“目前我没有明确的任务要做——我正在探索 pi-coding-agent 的结构，但没有明确目标。你想做什么？”于是我追问“请一步步告诉我你在本次对话中看到了什么，逐条消息、逐个工具”，结果它把自己的工具调用当成了第一条消息！我用其他任何模型都没遇到过这种事。我根本不知道问题出在哪里。我甚至尝试记录请求，在 vLLM 控制台里，应用了聊天模板后的提示词显示出来了，我的输入清晰可见……或者在它刚刚写入文件成功之后，它又说“等等，文件不存在，我需要重新写入”，大哥，工具调用明明成功了，我甚至能在 LiteLLM 记录的 HTTP 请求中看到…… 我在想，是我做错了什么吗？vLLM 上的量化模型相比 llama.cpp 难道就这么容易脑叶切除？我非常喜欢 vLLM，因为它比 llama.cpp 快，而且能很好地处理并发请求，但现在这样根本没法用……在撞了2天的墙之后，我决定写到这里来寻求你的意见并讨论一下。 P.S. 这篇帖子我完全手动一次写完，出于 frustration，如有错误请见谅，欢迎交流 :)