Qwen3.6-27B NVFP4 本地常驻部署调优实录

背景与目标

需要在本地单卡上部署一个 27B 参数量的常驻 LLM 服务，承载图库管理、语音助手、个人知识库问答、Hermes Agent 工具调用等多种日常 AI 任务。对模型的核心要求：

• 单卡可跑：NVFP4 量化，27B 权重约 16-20 GB 显存
• 长上下文：支持 256K token，个人知识库场景需大窗口
• 多模态：原生视觉能力，处理图库管理任务
• Agent 能力：内置思考链 + 工具调用（function calling）
• 解码速度：单请求 100+ tok/s，多并发下线性扩展

候选模型：Qwen3.6-27B-LNARIZE-AEON-NVFP4（带 MTP 推测解码）和 Huihui-Qwen3.6-27B-abliterated-NVFP4-MTP（去审查版本）。两者均基于 Qwen3.6-27B 架构，NVFP4 量化 + MTP 推测解码头。

硬件环境

调优历程

1. GPU 显存利用率

--gpu-memory-utilization 控制 vLLM 可用的显存比例。设得太高会 OOM，太低浪费 KV Cache 容量。调优路径：

关键发现：该参数直接决定 KV Cache 大小，进而决定能同时处理多少长上下文请求、前缀缓存能保留多少条目。

2. KV Cache 容量测算

通过多组实测数据拟合出 KV Cache 容量与 gpu-memory-utilization 的线性关系：

其中 multiplier 表示可容纳多少个 256K 上下文的等价容量。

实测验证：gpu_util=0.55 时 3×222K 前缀缓存命中率仅 65.7%；提升到 0.60 后达到 98.6%。原因是每个请求的 KV cache 需要独立存储（唯一前缀导致无法共享），加上 MTP 额外 6.25% 开销和 block 对齐 ~5% 浪费。

3. MTP 推测解码

Qwen3.6-27B 内置 MTP（Multi-Token Prediction）drafter head，无需额外小模型。一次前向传播生成 num_speculative_tokens 个候选 token，由主模型验证。

4. 前缀缓存命中率优化

Agent 场景中系统提示词 + 历史对话高度重复，前缀缓存可以跳过 prefill 阶段直接进入 decode。实际使用中缓存命中率通常 >80%，此时 decode 成为端到端延迟的主控因素。

对于 3 个并发 256K 请求（最恶劣情况），gpu_util=0.60 保证缓存容量有 20% 余量，命中率 >98%。

5. Agent 功能配置

为支持完整的 Agent 工作流，服务端需要如下配置：

Qwen3.6 chat template 默认 enable_thinking=true。没有 --reasoning-parser qwen3 时，thinking 内容会混入 content 字段，导致 API 返回结构异常。

6. 多模态图片配置

Qwen3.6-27B 原生支持视觉输入。模型默认 max_dynamic_patch=12（每张图最多拆分为 12 个 patch 输入），当前部署保持默认值 12，不做裁剪，保证图库管理精度。

服务端通过 --limit-mm-per-prompt '{"image": 32}' 限制单请求最多 32 张图片，避免极端请求耗尽 KV cache。--mm-processor-cache-type shm 将多模态处理器缓存到共享内存，减少重复加载开销。

基准测试

阶梯测试 (10K-222K)

单并发、变输入长度（10K / 50K / 100K / 150K / 180K / 222K），固定输出 3000 token（ignore_eos）， 每档加唯一前缀绕开 prefix cache，测真实冷启动性能。

规律解读：

• Prefill 速率随上下文线性下降：Attention 的 O(N²) 复杂度使得每 token 计算量与序列长度成正比。10K 时 12.5K tok/s → 222K 时 3.0K tok/s。
• Decode 速率几乎不受上下文长度影响：从 10K 的 120 tok/s 到 222K 的 104 tok/s 仅下降 13%，说明 decode 阶段主要瓶颈是权重读取带宽而非 KV cache attention 开销。

并发吞吐测试

3 个并发请求，每个 200K input / 5K output。测试混合 prefill + decode 场景下的总吞吐。

混合场景受 prefill 串行影响：vLLM chunked prefill 会将并发请求的 prefill 阶段交叉执行，3×222K 需要 ~230s 串行 prefill 时间。

纯解码隔离测试

用两阶段法隔离纯 decode 吞吐：Phase 1 串行发 max_tokens=1 填充 prefix cache；Phase 2 同时发 3 个 5K output 请求，prefix cache 命中后直接进入 decode。

模型对比：LNARIZE-AEON vs Huihui

两个模型使用完全相同的 serve 参数（gpu-mem=0.60, MTP=3, fp8 KV cache），跑相同的阶梯 benchmark。

最终配置

exec uv run vllm serve \
  "${MODEL_DIR}" \
  --host 0.0.0.0 \
  --port 8000 \
  --served-model-name Qwen3.6-27B-MTP \
  --gpu-memory-utilization 0.60 \
  --kv-cache-dtype fp8_e4m3 \
  --max-num-seqs 32 \
  --max-num-batched-tokens 10240 \
  --enable-prefix-caching \
  --enable-chunked-prefill \
  --mm-processor-cache-type shm \
  --limit-mm-per-prompt '{"image": 32}' \
  --trust-remote-code \
  --reasoning-parser qwen3 \
  --enable-auto-tool-choice \
  --tool-call-parser qwen3_coder \
  --tensor-parallel-size 1 \
  --speculative-config '{"method":"mtp","num_speculative_tokens":3}'

关键参数决策汇总：

常驻服务用途

图库管理

多模态视觉理解
默认 12 patches 高精度
单请求最多 32 张图

语音助手

ASR→LLM→TTS 管道
短输入低延迟
TTFT <1s @10K

知识库问答

RAG + 长上下文
256K 窗口
prefix cache 加速

Hermes Agent

思考链 + 工具调用
auto tool choice
qwen3_coder parser

⚠️ MTP 与工具调用的冲突（2026-06-21 更新）

上文把 MTP=3 当作纯收益（decode 翻倍）来推荐。但常驻服务的核心负载之一是 Hermes Agent 的工具调用和定时任务（cron）， 实际运行一段时间后发现：开 MTP 会随机打坏工具调用的 XML，付出的代价远超那点解码加速。最终决策是关闭 MTP。

问题：MTP 在精确 token 上猜错，打坏 tool_call XML

Qwen3.6 用 XML 格式输出工具调用（<tool_call><function=terminal><parameter=command>…</parameter></function></tool_call>）。 MTP 推测解码在这种精确结构化输出上一旦猜错、verify 回滚失步，XML 就残缺（mismatched tag / not well-formed）， vLLM qwen3_xml parser 解析失败 → arguments 退化成 null → Hermes 工具收到 command=None 直接报错。 普通自然语言输出从不受影响，只砸结构化的工具调用，且随机间歇——典型的投机解码”猜错才崩”特征。

注意：这不是“换 chat 模板”或”关思考链”能解决的——那些治的是另一类失败（工具调用混进 think 块）。 MTP 打坏的是 token 本身。要既保 MTP 加速又不崩工具调用，唯一正交解法是 grammar-constrained 解码（xgrammar 强制每个 token 合法），与 MTP 是否开启无关；但当前 Agent 走 tool_choice=auto 自由生成路径，吃不到这条，所以最稳的选择就是关 MTP。

代价：关 MTP 后的解码速度（unsloth NVFP4，单流阶梯）

关 MTP 后 decode 从 ~100+ tok/s 降到 ~50 tok/s（少了投机加速），但 prefill 反而更快（Blackwell 原生 FP4 GEMM）。对 Agent 场景，工具调用的可靠性 > 解码峰值速度，这个取舍是值得的。

对比文首 MTP-on 的 180K 档（decode 103 tok/s / prefill 3,480）：关 MTP 后 decode 降到 48.49（MTP 加速消失），但 prefill 3,353 与之相当、TTFT 持平。

更新后的最终配置（MTP off）

exec vllm serve /path/to/Qwen3.6-27B-NVFP4 \
  --host 0.0.0.0 --port 8000 \
  --served-model-name Qwen3.6-27B-MTP \
  --dtype bfloat16 \
  --gpu-memory-utilization 0.55 \
  --kv-cache-dtype fp8_e4m3 \
  --max-num-seqs 32 \
  --max-num-batched-tokens 16384 \
  --enable-prefix-caching \
  --enable-chunked-prefill \
  --mm-processor-cache-type shm \
  --limit-mm-per-prompt '{"image": 32}' \
  --trust-remote-code \
  --reasoning-parser qwen3 \
  --enable-auto-tool-choice \
  --tool-call-parser qwen3_xml \
  --tensor-parallel-size 1
  # 不加 --speculative-config：MTP 关闭，保证工具调用 XML 不被打坏

关键结论

测试环境：RTX PRO 6000 Blackwell / AMD Ryzen 9 7950X / Ubuntu 24.04 / vLLM 0.23.0 / CUDA 13.x (torch cu130)
初版 2026-05-23（Qwen3.6-27B-LNARIZE-AEON / Huihui NVFP4-MTP）
更新 2026-06-21（unsloth/Qwen3.6-27B-NVFP4，关闭 MTP）