Qwen3.8-27B 本地部署与 reasoning_effort 测评报告

01结论摘要

1. 部署可行。 27B 稠密多模态模型在单张 48 GB 工作站卡上全量 GPU 卸载运行，峰值 33.9 tok/s。
2. MTP 投机解码是最大性能杠杆，实测提速 1.59×（20.17 → 32.10 tok/s），代价仅 3.16 GB 显存。
3. 产物体量随 reasoning_effort 呈 U 形，medium 位于谷底。 两任务独立复现，low 产物稳定为 medium 的约 2 倍。这是本报告置信度最高的发现。
4. MTP 接受率随思考深度单调下降（85% → 65–75% → 57–59%），是速度梯度的完整解释。
5. xhigh 代价极高：比 medium 慢一个数量级，换来约 3 倍产物体量，且纯思考阶段长达 26–31 分钟无任何输出。

02环境配置

硬件

软件

模型

服务配置（本报告全部数据的统一配置）

llama-server \
  -m Qwen3.8-27B-UD-Q8_K_XL.gguf \
  --mmproj mmproj-BF16.gguf \
  --spec-type draft-mtp  -md mtp-Qwen3.8-27B-Q8_0.gguf \
  -ngl 99  -ngld 99 \
  -c 262144 \
  -ctk q8_0  -ctv q8_0  -ctkd q8_0  -ctvd q8_0 \
  -fa on \
  -b 4096  -ub 1024  -t 32  --parallel 1 \
  --jinja  --reasoning-preserve

显存占用 47.17 / 51.52 GB（91.5%）。KV cache 量化为 q8_0 是为了在同一张卡上容纳 256K 上下文——f16 KV 在该长度需 17.2 GB，加模型会超显存。

03部署性能基线

带宽参考：864 GB/s ÷ 31.46 GB ≈ 27.5 tok/s 是无投机解码时的理论上限。MTP 通过把权重读取摊薄到多个 token 上突破了该上限。视觉能力实测通过——颜色、数量、几何关系识别全部正确。

04测试方法

• 无 system prompt、无 harness、无历史上下文，单轮请求
• 采样参数用官方 thinking 模式推荐值：temperature=1.0, top_p=0.95, top_k=20, min_p=0.0, presence_penalty=0.0
• max_tokens=160000，确保 xhigh 不被截断
• 两任务各跑 low / medium / xhigh 三档，串行执行以避免并发争抢显存带宽

任务 1：创建一个HTML,内容是SVG绘制一个鹈鹕骑自行车的2D动画
任务 2：创建一个HTML,内容是SVG绘制一个秦始皇骑北极熊的2D动画

05结果

完整数据表

06产物画廊

下列为六次生成的实际产物，实时渲染。全部经校验：<!DOCTYPE> 至 </html> 结构闭合完整，含合法 <svg> 元素。

07分析

7.1 速度：MTP 接受率是唯一驱动因素

三档接受率严格单调（85.0/84.6% → 75.0/64.8% → 59.4/57.0%），两任务数值高度一致。思考文本越深入越发散，草稿模型越难预测，接受率下降直接转化为速度下降。速度差异全部可由此解释，无需引入其他因素。

7.2 产物：U 形曲线，medium 在谷底

low / medium 产物比在三次独立测量中稳定落在 1.90× — 2.05×（含配置修正前 f16 KV 下的一次）。medium 是三档中唯一没有任何维度优势的档位：比 low 慢且产物小一半，比 xhigh 快十倍但细节差一个数量级。

7.3 机制假说：思考阶段的过早简化

medium 的 reasoning 中反复出现简化决策，且这些决策在产物中被忠实执行：

对比 low 的产物动画列表——walkFrontLeft / walkFrontRight / walkBackLeft / walkBackRight（四腿独立）、snowFall1–snowFall5（五层雪）、breathe、blink——它在生成过程中自然铺开，没有经过“先规划再执行”的收缩环节。简化措辞统计支持该方向：low 两任务均为 0 次，medium 均为 3 次，xhigh 为 20–21 次。

7.4 思考语言随深度切换

两个 prompt 均为中文，但 reasoning 中文占比为 low 16.2% / 67.2%，medium 0.0% / 0.0%，xhigh 0.2% / 0.4%。深度思考几乎全程切换到英文。该现象稳定复现，成因未探究。

7.5 xhigh 的收敛行为

xhigh 在两任务分别消耗 51,268 和 59,586 token 后自然收敛，未触及 160K 上限。reasoning 经重复率检测（>25 字符行去重）：两任务均为 0.0% 重复，803 行全部唯一——不存在退化或死循环，是真实的逐坐标推演。代价是纯思考阶段 26.3 / 31.2 分钟内用户看不到任何输出。

08局限性

1. 每格 n=1，运行间方差很大。 同一 prompt、同档位、同配置下 low 两次跑出 8,853 与 12,285 token（差 39%），reasoning 长度差 277%，动画方案从纯 CSS 变为 CSS+SMIL 混用。本报告所有单项数值应视为量级参考而非精确值。
2. 仅 1.90–2.05× 的产物比值经三次独立测量确认，其余结论均为单次观测。
3. 任务类型单一。 两任务同属 SVG 动画生成。medium 的简化倾向在逻辑推理、代码调试、需求分析类任务上可能反而是优点——那类场景需要收敛而非铺开。
4. 产物质量以结构复杂度代理（字节数、元素数、动画数），未做视觉正确性或美学评分。元素多不必然等于效果好。
5. 单卡环境，未测多卡张量并行。
6. q8_0 KV 对输出内容的影响未做受控测量。 对照实验显示速度差异在噪声范围内（low −2.2%，medium +3.0%，方向相反）。

09建议

部署侧

• UD-Q8_K_XL 是 48 GB 单卡的最优量化档。 BF16 需 55.6 GB 装不下；Q8_0（28.6 GB）质量略低于 UD 变体；Q6 以下无必要。
• MTP 投机解码必开——1.59× 提速，成本仅 3.16 GB 显存。
• q8_0 KV 近乎白拿：换来 128K → 256K 上下文翻倍，速度代价在噪声范围内。
• 若能争取到第 2 张卡（96 GB），可直接跑 BF16 原版并改用 vLLM 走高吞吐路线。

使用侧

生产注意事项

• xhigh 单次请求可达 6 万 token / 40 分钟，必须配置足够的 max_tokens 与超时，否则会在中途被截断并丢失全部产出（本测试初期即在 32K 处踩过该坑）。
• 多轮 agent 场景下 preserve_thinking 默认开启，历史 reasoning 会累积。单轮仅占上下文 4.7%，十余轮后 256K 窗口可能吃紧。