Qwen3.8-27B：更慢的词元，更快更好的结果

# Qwen3.8-27B：更慢的 token，更快更好的结果 来源：https://overbring.com/blog/2026-08-17-qwen3-8-27b-wall-clock/ *使用 Qwen3.8-27B 时，获取正确结果的**实际耗时**比每秒处理的 token 数更为重要。一个能独立完成任务的“慢”模型，远胜于一个需要你时刻介入的更快模型。别理会当前关于 `xhigh` 设置浪费资源、聊天模板非最优、8 位量化远优于 4 位，以及永不量化 KV 缓存的流行观点了。这在家用环境下就是顶尖水平（SOTA），而 32GB 显存从未像现在这样物尽其用。* 备受期待的 Qwen3.8-27B (https://qwen.ai/blog?id=qwen3.6-27b) 已于上周五发布，今天已是周一。我花了整整三天时间，在多个实际代码库上测试了它，主要包括 Breek.gr (https://breek.gr/en) 这个成熟的 SaaS 平台，以及 OVERBRING Labs (https://overbring.com/) 即将推出产品的代码库、为我的另一品牌 ISATEK (https://overbring.com/projects/isatek/) 服务的内部业务工具，还有即将重新设计的 isatek.gr (https://isatek.gr/)。 正如我们许多 Qwen3.6-35B-A3B (https://huggingface.co/michaelw9999/Qwen3.6-35B-A3B-NVFP4-MTP-GGUF) 和 Qwen3.6-27B (https://huggingface.co/michaelw9999/Qwopus3.6-27B-v2-MTP-NVFP4-GGUF) 及其微调版本（如 KAT-Coder-V2.5-Dev (https://huggingface.co/mudler/KAT-Coder-V2.5-Dev-APEX-GGUF) 和 ThinkingCap-Qwen3.6-27B (https://huggingface.co/bottlecapai/ThinkingCap-Qwen3.6-27B-GGUF)）的热情用户一样，我过去一周一直在等待周五的“Qwen节”。在 HuggingFace 开源权重发布后的最初几个小时里，我一边在 `supra` 机器的 `llama-swap` (https://github.com/mostlygeek/llama-swap) 的 `config.yaml` (https://github.com/mostlygeek/llama-swap/blob/main/config.example.yaml) 中调整 `llama-server` (https://github.com/ggml-org/llama.cpp) 调用参数，一边聆听和观看关于该模型的各种早期评价，浏览 YouTube 评论和 HackerNews 评论，发现了*许多*与我过去 3 个月智能体编程体验不符的“热门观点”和看法。 > `supra` 配备了 X570 AORUS ELITE 主板、Ryzen 7 5700X、64GB DDR4-3200 内存、1000W 80 Plus Gold 电源以及两张 RTX 5060 Ti 16GB 显卡。 主要来说，我想探讨一个困扰许多人的问题，它揭示了 YouTube 视频中以及本地部署时对模型进行“基准测试”（一种委婉的说法）的方式所存在的问题。你看，模型发布时默认设置了超高（`xhigh`）推理强度。你经常会看到“太慢了”、“响应要花很长时间”、“它想太多了”之类的批评，也同样频繁地看到相反的观点，比如它令人难以置信、接近云端托管的“最先进”（“SOTA”）/前沿模型等。 两种观点都有道理，但与我们在本地能运行的其他模型相比，只有后者是*客观*正确的。主观上，就 `pp`/`tg` 指标而言，它确实不算快，而且在经历漫长的推理过程后，它*确实*需要较长时间才能响应。当然，在像我这样的预算硬件上运行，使用分层（`--split-mode layer`）并在只有 1x PCIe Gen 4.0 x8 和 1x PCIe Gen 4.0 x4（南桥连接）的 AM4 主板（X570）上运行时，它并非*最快*的模型。我们谈的是在启用 `--spec-type draft-mtp` 和 `--spec-draft-n-max 2` 的情况下，token 生成（`tg`）最高达到 45 tok/s（图表见下文）。 客观地说，它比当前任何你能用预算设备本地运行的模型都*智能得多得多*。而且这种智能不仅仅体现在实际基准测试上，尽管有些令人困惑的 YouTube 评论声称它“刷榜”了。我没看出来（实证稍后）。Qwen 3.5 和 3.6 也并非刷榜。 所以，让我们欢呼吧！Qwen3.8-27B 交付了 Qwen 团队甚至没有承诺过的东西：真正接近 2026 年 2 月时 SOTA/前沿水平的能力。它可以本地运行，理想情况下（用于最大或接近最大上下文窗口）需要 32GB 显存（但仍然没有 `mmproj` / “视觉塔”）。 ## 关于“过度思考”的说法，以及 YouTube 的“基准测试”问题 它“过度思考”了吗？用德国人的说法，*算是又不算*。**是的**，开箱即用时，它“思考”得*非常多*。它的推理过程最终会消耗掉大部分上下文窗口，尤其是在启用 `llama-server` 的 `--reasoning-preserve` 标志时。 但**也**不是，它并没有*过度*思考，即使 `xhigh` 设置既不是最佳默认值，对大多数任务也非必需。现在，许多严肃的 YouTuber 和 X 平台用户已经对此进行了更透彻的分析并得出了这个结论。 然而，这最终并非真正的衡量标准，`pp`/`tg` 指标也不是智能体编程的终极基准，因为你可以在两种极端的“模式”下成功完成任务（即达到你认为任务“完成且无需修改”的目标质量）： 1. **高平均 `pp`/`tg` 模式**：经过多轮交互，模型修正自身错误并由人工指导*重做*，直到最终完成整个任务，你全程参与。到目前为止，我在使用 Qwen3.6-35B-A3B 完成任务时大多处于这种情况，无论是作为单个智能体，还是作为主智能体按顺序编排 ThinkingCap 子智能体进行编码、对抗性审查、修正，以及在代码变更上使用阿里巴巴的 `open-code-review` (https://github.com/alibaba/open-code-review) 进行预提交检查。 2. **低平均 `pp`/`tg` 模式**：模型自主工作直至完成，而你去做其他事情。 对于给定的目标质量，真正重要的指标是**实际耗时**。对我们本地 AI 爱好者来说，这直接关系到我们每月的电费账单。如果你（像我一样）同时处理多件事（不一定是编码，还要经营业务并需要多次离开智能体工作台），模式（2）显然更可取，即使实际耗时更长。事实上，即使模式（2）的实际耗时是模式（1）的两倍，它也更可取，因为这减少了你的上下文切换频率。 与模式（1）的单智能体或多智能体方法相比，模式（2）的主要优势，除了 Qwen3.8-27B 本身的智能提升，还在于你可以在它工作时走开，回来时得到几乎“完美”的结果。 ### 附注：量化极致主义与设备优越感的幻象 我们这里不争论 Unsloth 的 `UD-Q4_K_XL` 量化版本能否达到这种“完美”程度，也不讨论你是否需要 `Q8_0` 甚至全精度 GGUF 才能达到这种“完美”。我的使用情况可能与使用两张 5090 或 DGX Spark 运行它的人不同。我们的资本支出（GPU）和运营支出（电费），即我们的投资回收期，也会不同。每个人都根据自己的经济状况和需求选择最适合的。对我来说可能显得浪费的东西，对你的用例可能是必要的。我不做评判。让我困扰的是那种盲目崇拜的教条主义。 就我的需求而言，`UD-Q4_K_XL` 在我交给它的第一个任务上就表现得*真正完美*，这就是为什么我将这个 GGUF 与 AtomicChat 的 `Q5_K_M` 和 `AD-Q6_K` 一并保留。这些量化版本当然无法让我使用完整的 262144 token 原生上下文窗口，但如果你考虑的是使用 Qwen3.8-27B 作为子智能体来实现模式（1），那就完全没问题了。也许有些任务，6 位量化无法完成，而 8 位量化甚至全精度 GGUF 可以，但我无从得知，因为我没有这样的案例，也没有运行它的硬件。作为一名经营业务的训练有素的工程师，我深深、真正地是一个*满足者*（satisficer）。 但正是在这里，我们需要仔细审视过去三天出现的热门观点、错误观点、误解和不完整的调查——这些主要来自那些急于在 YouTube 上发布内容以获取点击量的人。 ## 在 32GB 显存上运行 Qwen3.8-27B 8 月 14 日（周五）雅典时间 18:00，Qwen3.8-27B 权重在 HuggingFace 发布。Unsloth 照例上传了他们的量化版本阶梯。午夜时分，我回到键盘前，下载了 `UD-Q4_K_XL`。我太兴奋了，没去运行 `llama-bench` 或 `ggrun`，而是花了 30-45 分钟调整 `llama-server` 参数。到凌晨 01:00，我已设置好 Grok Build，将 `supra` 上运行的 `llama-swap` 所服务的模型列在 `/model` 下。经过一番试错，并观察 `nvtop` 的图表，我最终得到了以下配置，它在总共 32GB 显存的情况下应该对你同样适用： ```bash llama_server --port 8935 --host :: \ -m Qwen3.8-27B-UD-Q4_K_XL.gguf --no-mmproj --load-mode mmap \ -fa on -b 2048 -ub 256 -t 6 -tb 6 \ -ctk q8_0 -ctv q4_0 \ -ctkd q4_0 -ctvd q4_0 \ --jinja -ngl 999 \ --kv-offload --no-context-shift \ --reasoning on --reasoning-preserve \ --dry-multiplier 0.8 --dry-base 1.75 --dry-allowed-length 2 --dry-penalty-last-n 0 \ --presence_penalty 0.0 --repeat_penalty 1.0 \ --spec-type draft-mtp --spec-draft-n-max 2 \ --temp 1.0 --top_p 0.95 --top_k 20 --min-p 0.0 \ -c 262144 --parallel 1 --cont-batching ``` （注意 `--cont-batching` 对于 `--parallel 1` 并非必需，但我有时会尝试 `--parallel 2` 来同时处理多个会话。） 这个 `llama-server` 调用中有几点与网络上的流行教条和热门观点相悖：KV 缓存量化、投机解码草稿模型的 KV 缓存量化，以及采样参数。 一条 YouTube 评论说过：“*朋友不会让朋友量化 KV 缓存*”。到目前为止，我一直用对称的 `q8_0` KV 缓存运行所有其他模型。然而，在这里，我想看看如何才能获得最大上下文长度，所以用了 `-ctv q4_0`。事实是：KV 缓存的值（Values）比键（Keys）对量化更不敏感，但这可能会引起问题，尤其是随着上下文窗口利用率的增加。这个权衡和潜在的陷阱我已注意到。如果结果不尽如人意，我会恢复到对称的 `q8_0`，并接受更短的上下文窗口。 另一件事：网上许多视频声称投机解码是免费的。不，它不是。MTP 草稿模型需要显存和计算缓冲区。然而，由于 MTP 是防止随着 KV 缓存填充导致 `tg` 性能急剧下降的必备项，因此我们也尝试将 MTP 草稿模型的 KV 缓存量化为 `q4_0`。 *哦不！* `q4_0`？！**亵渎！** 管它呢... 能有多糟？（剧透：不糟。）稍微冒险一下吧。 还要注意 Qwen 团队推荐的采样设置。与 Qwen3.6 默认推荐的采样温度（`--temp 0.6`）相比，它设置得比较“热”（`--temp 1.0`）。现在很多人认为 Qwen3.8 倾向于“过度思考”，于是出现了一个新想法：使用 `--temp 0.6` 运行。得了吧。你真的比模型的创造者更懂吗？我表示怀疑。所以就是 `--temp 1.0`，存在惩罚和重复惩罚也采用 Qwen 团队的推荐值。DRY 参数则沿用了我为 Qwen3.6 设置的值。 其他“猎巫”行为还包括一些民间智慧，等同于*“相信我，问题就在聊天模板”*。也许吧；但让我们先建立一个基准。没有使用特殊的 `froggeric` 模板 (https://huggingface.co/froggeric/Qwen-Fixed-Chat-Templates/blob/main/chat_template.jinja)，也没有使用 Nail/Dagger GGUF 嵌入的模板 (https://huggingface.co/peculiar-ragdoll/Dagger-Qwen3.6-27B-MLX/blob/main/chat_template.jinja)。 顺便问一下，你知道吗？Nail/Dagger GGUF 的权重与 Qwen3.6 MoE 和 27B 分别相同，因此你可以在任何 Qwen3.5 或 3.6 上单独应用该模板，无需下载 GGUF。我对 Qwen3.6 MoE 和 27B 就是这样做的。 ## 用一次“脑力倾泻”、一点希望和祈祷来提示 `llama-swap` 启动并运行后，我需要一个用例。但不是随便什么用例。需要一个能真正告诉我这是否能作为日常主力使用的用例。我 `cd` 到 Breek v2 的三个 git 仓库根目录（明天会有更多细节），输入 `grok` 并选择模型。 我启动 Handy (https://github.com/cjpais/Handy)，使用 Parakeet Unified 0.6B 模型，对着网络摄像头的麦克风开始滔滔不绝地讲了几分钟，内容包括： * **产品范围和价值主张：** 产品是什么，做什么，为谁而做。 * **产品开发历史：** 我们从哪里来（更关注最近的 v2 版本而非 v1.0）。 * **软件架构：** 架构是什么样的，整个产品如何部署。 * **实体和关联：** 哪些关键实体/模式需要关注，以及它们如何相互关联。 * **当前状态和近期工作：** 3 个代码库的总体状态，包括关于最近实现的功能和修复的错误的简短脑力倾泻（*“但请务必检查仓库的 git 日志以了解情况”*）。 * **两个 REST API：** 为什么我们需要两个 REST API 来服务一个 web 应用，Phoenix 后端解决了什么问题，它如何与遗留的 PHP 后端协同工作。 * **正在进行的绞杀者模式：** 我们在将某些 API 路由从 PHP 迁移到 Phoenix 的 v2 内部绞杀者模式中处于什么阶段，下一步我们想做什么。 * **与 Bug 相关的功能：** 功能层级、订阅，以及前端和后端如何升级或续订物业的“许可证”；是概念性的、宽松的描述，涉及使用的实体，而非详细说明或引用代码。 * **错误报告：** 最后，原封不动地读出我们的“冠军客户”通过 WhatsApp 反馈的内容。 这就是不提交那些你从未审查过、因此永远无法理解的“氛围编程”产物的好处：你了解系统如何运作。因此，我也谈到了： * 一些关于 Bug 可能潜伏何处的**直觉/假设**，并带有一些保留：“*但别把这当真理，尽管我这么说了，还是要彻底调查，因为这些都是我未经验证的，所以请在探索后形成你自己的结论*”。 * 我们最近几个月解决过的**类似问题**。 * 我们过去因将 DTO 缓存到 Redis 中而产生的**历史问题**，这是可能产生 Bug 的一个潜在源头，我们正在逐步消除。 > 一年前我引入了 Redis，但这就像是在一头有糟糕、*非常*糟糕的 SQL 查询和缓慢的、深层嵌套 PHP 关联数组后过滤的 PHP/MySQL 猪头上涂上一层缓存口红。这是一个业务领域的问题：物业管理需要对具有多层级和非层级关联的实体进行建模，这使得不将所有事情都交给 SQL 处理变得更容易（但也更慢）。这在一段时间内有效，但缓存层的实现，我们可以说...“不是很好”（即，它是一个仓促的应对措施），随着功能集和实体数量的增长，彻底的缓存失效变成了噩梦。这是添加 Phoenix REST API 的原因之一；多亏了 Redis PubSub 和 SQLite，我们再也不必缓存任何东西了（但这完全是另一篇文章的内容）。 总之，我真的对着麦克风倾泻了大约 10 分钟的想法，就像 Karpathy 建议的那样 (https://x.com/karpathy/status/2079610838143623371)，也像我几周前发现 Handy 以来一直在做的那样。然后我等待 Handy 将转录文本插入 Grok Build 的输入框，然后按下回车。在上述列表中，现在增加： * 关于产品、项目代码库、问题、潜在根本原因和直觉的、丰富的、半结构化的思维流阐述。 ### “过度思考”？什么过度思考？它思考的量恰到好处。 还要记住，GGUF 发布才不到 7 小时，人们还没有探索 `xhigh` 推理强度的影响和（所谓的？）缺点，也没有产生任何“民间智慧”。即使他们有，我还没去看评论或 YouTube 视频呢。