peculiar-ragdoll/Qwen-Sharp-Chat-Templates · Hugging Face 来源: https://huggingface.co/peculiar-ragdoll/Qwen-Sharp-Chat-Templates

https://huggingface.co/peculiar-ragdoll/Qwen-Sharp-Chat-Templates#qwen-sharp-chat-templatesQwen Sharp Chat Templates

这是针对任何 Qwen3.5、3.6 或 3.8 模型的即插即用修复方案，专门优化模型在知识工作和编程任务中的表现。应用此模板后，Qwen3.8-27b 模型在保持更高准确性的同时，使用了更少的 token。
使用 Sharp 模板后，Qwen3.8-27b (中等努力程度) 变得更智能，并且在回答前使用了更少的思考 token，其他兼容模型也有类似效果。
ThinkingCap-Qwen3.6-27B 在 Claw-Eval 上的表现：使用 Sharp 模板后，答案得分提高 +7.4，总分提高 +3.8，答案 token 减少 59%
Sharp 让 Qwen 的模型每个 token 更智能，并通过减少填充内容而不牺牲正确性或实质信息，使它们每个 token 传递更多信息，从而在多轮对话中节省模型和用户的时间和精力。
Qwen3.8-27b 在 SWE-bench-Live 上的表现：使用 Sharp 模板解决了 24 个问题中的 14 个，而原始模板解决了 15 个，但修复问题的中位时间缩短为 20.0 分钟（原始模板为 50.2 分钟）
在实际仓库工作中，同样的效果体现在速度上：Sharp 解决的问题数量与原始模板相当，但解决每个问题的中位时间快 2.5 倍。

https://huggingface.co/peculiar-ragdoll/Qwen-Sharp-Chat-templates#straight-to-the-pointStraight to the point

这是基于 froggeric 的 Qwen-Fixed-Chat-Templates (https://huggingface.co/froggeric/Qwen-Fixed-Chat-Templates) v22.3版本，强行追加系统提示词后拼接而成，并在此基础上进行了本仓库的修订。基础版本修复了问题，附加内容使其更好，v22.3.1 版本使快速（关闭思考）路径保持一致，而 v22.3.2 版本允许你按请求切换是否追加提示词——参见下方的更新日志。

**v22.3.2（当前版本）。**简洁性系统提示词现在可按请求选择是否启用。在 chat_template_kwargs 中传入 {"terse": false} 即不会追加该块；模型将使用自身的系统提示词运行，或不使用提示词。默认设置保持不变——省略该参数，你将得到与 v22.3.1 渲染结果逐字节完全相同的内容，因此所有现有调用者和已发布的构建都保持原样。没有其他更改。参见关闭简洁模式。
v22.3.1（本仓库的错误修复，基于 froggeric v22.3 重新构建）。三项更改，全部针对关闭思考（快速）模式；开启思考的路径与上游 v22.3 加简洁块逐字节相同，因此任何已开启思考运行的程序只会获得上游的修复。

1. **快速模式下 相关矛盾已修复。**当工具和思考*关闭*时，上游仍指示模型将其推理放在 内——而生成提示已关闭了思考。这会将所有与 `` 相关的工具调用指令置于思考开启的条件下，因此快速模式不再要求一个它无法开启的块。（工具调用格式规则未受影响。）
2. **简洁引导语按模式区分。**单一引导语——“思考后直接回答”——在关闭思考时不连贯，因此关闭思考时使用简洁中立的“直接简洁回答”引导语。简洁核心（永不/总是规则）在两种模式下完全相同。
3. 移除了快速路径上的最后一个思考引用。一条工具调用规则在快速模式下仍写着“思考后立即输出 `` 块”——与 (1) 相同的矛盾，存在于第一项修复未覆盖的一行中。只有这两个词的片段被条件限制，因此关闭思考时读作“…立即输出，之前没有对话文本”，开启思考时逐字节不变。至此，快速模式提示中不再有任何对思考的引用。(1) 和 (2) 从 v22.1.1 不变沿用；(3) 在 v22.3.1 中是新增的。截至 v22.3，上游均未修复。
   版本字符串中断。v22.3.1 不包含 v22.1 作为子串，因此任何匹配旧标识符的检查器会停止匹配。本项目的重新嵌入脚本（publish/retemplate_dirk.py、publish/retemplate_dirk_v3.py）现在在运行时从模板文件中读取预期版本，而非硬编码，因此下次重新构建不会再次中断它们。已发布的 GGUF/MLX 构建仍携带 v22.1.1，在刻意重新模板化之前不受影响。

**上游在 v22.2 / v22.3 中新增的内容（以及为我们关闭了哪些问题）。**重新构建时合并了上游内容，经其自身测试套件验证：

• **长工具错误再次升级。**旧的 content|length < 500 限制意味着多行回溯——正是升级重要的场景——静默地永不升级。v22.2+ 将其替换为两个层级：结构信号（"error":、"status": "error"、非零退出码、真正的 Traceback (most recent call last):）在任何负载大小下都会升级，而弱信号仍受大小限制。这是本仓库先前列为开放并推迟的两个问题之一——现已修复，在上游，并且比本仓库曾回退的补丁更好。
• **代码搜索中的虚假重试循环已消除。**包含 throw new Error(...)、console.error、logger.error 的 Grep 命中不再计为工具失败。
• 多个前置系统/开发者消息合并为一个系统轮次，以空行连接，而非仅将第一个视为系统提示。
• 内容内推理提取范围扩大到以 `` 开头的内容，并在提供 reasoning_content/thinking 与内联标签时进行去重。
• 保留的助手轮次始终渲染 `` 包装器，即使思考内容为空，因此渲染的历史记录与实际生成的内容匹配，前缀缓存保持有效。
• **工具参数正确序列化。**布尔值、空值和数字现在通过 tojson 处理，而非 | string（后者输出 Python 的 True/None）；原始字符串参数遵守 max_tool_arg_chars；JSON 工具格式不再截断工具响应。
• 更多努力别名：off、max、ultracode、extreme，以及对应的 <|think_...|> 标签。
  仍然开放（因此你不要过度信任）：工具输出中字面出现的 <|think_off|> 在如果你的测试框架将工具结果打包到 user 消息中时仍会禁用推理——上游的标签扫描器读取 system/developer/user 角色，因此适当的 tool 角色消息是安全的，且在 v22.3 中未改变。另一个单独报告的回答中途出现的 `` 标签在我们环境中仍未复现（2,863 条语料消息 + 14 次新 llama.cpp 生成，零次复现），MTP 推测解码是首要怀疑对象；v22.3.1 并未针对它。

v22.3（上游基础）。覆盖 Qwen 3.8 以及 3.5/3.6，并新增了提示导向的推理努力引导（none/minimal/low/medium/high/xhigh，以及上述别名）和内联 <|think_...|> 控制标签。默认努力程度为 medium——中性基线，当调用者未请求任何内容时不注入任何引导行。（早期 v22 默认强制 xhigh；froggeric 在上游修复了此问题，因此此 Sharp 构建不再抑制任何内容——开箱即用，你将获得调整后的简洁行为，没有其他内容，与 v1 完全相同。）显式的努力程度仍会渲染；通过 chat_template_kwargs 传入（裸顶层 reasoning_effort 字段在 OpenAI 风格的服务器中会在模板处理前被丢弃）：

{"messages": [...], "chat_template_kwargs": {"reasoning_effort": "low"}}

Dagger-Qwen3.6-27B (https://huggingface.co/peculiar-ragdoll/Dagger-Qwen3.6-27B-MLX) 和 Nail-Qwen3.6-35B-A3B (https://huggingface.co/peculiar-ragdoll/Nail-Qwen3.6-35B-A3B-MLX) 发布时内置了 v1 模板——即嵌入在这些 GGUF 和 MLX 构建中的确切模板（template_version = "qwen3.6-froggeric-v21.3"，简洁模式，无推理努力引导），它存储在此处的 archive/v1-qwen3.6-froggeric-v21.3/ (https://huggingface.co/peculiar-ragdoll/Qwen-Sharp-Chat-templates/blob/main/archive/v1-qwen3.6-froggeric-v21.3)。此仓库根目录的 chat_template.jinja 是上述最新的 v22.3.2 版本；将其放入即可将模型迁移至该版本。模板单独发布是因为它是可复用的部分——值得复用的内容不局限于任一模型。
废弃版本逐字保存在 archive/ 下 (https://huggingface.co/peculiar-ragdoll/Qwen-Sharp-Chat-templates/tree/main/archive)：v1 froggeric-v21.3 构建（Dagger/Nail），archive/v22.1-sharp/ (https://huggingface.co/peculiar-ragdoll/Qwen-Sharp-Chat-templates/blob/main/archive/v22.1-sharp) 中的 v22.1 构建，archive/v22.1.1-sharp/ (https://huggingface.co/peculiar-ragdoll/Qwen-Sharp-Chat-templates/blob/main/archive/v22.1.1-sharp) 中的 v22.1.1 构建——v22.3 重新构建前的最后一个版本，以及已发布 Dirk 构建中嵌入的版本——和紧接其前的 archive/v22.3.1-sharp/ (https://huggingface.co/peculiar-ragdoll/Qwen-Sharp-Chat-templates/blob/main/archive/v22.3.1-sharp) 中的 v22.3.1。

https://huggingface.co/peculiar-ragdoll/Qwen-Sharp-Chat-templates#what-it-changesWhat it changes

一个简洁性块，强行追加在你自己的系统提示词之后。引导语现在随思考模式变化（v22.3.1 的修复）；核心的永不/总是规则在两种路径上完全相同，开启思考的路径与上游 v22.3 + 原始简洁块逐字节相同。

{%- if ns_state.thinking %}
  {%- set _terse_lead = '直接回答，在思考之后。以答案开头，然后只包含使其正确可用所需的内容。' %}
{%- else %}
  {%- set _terse_lead = '直接简洁地回答。给出答案，只包含使其正确可用所需的内容。' %}
{%- endif %}
{%- set _terse_core %}
永不：以开场白或寒暄开头；复述问题；添加填充过渡；用客套话委婉；或重复你已经说过的点。
总是：保留关键步骤、注意事项、不确定性和细节——永远不要为了简洁而牺牲正确性或必要的警告。
保持最终答案精简。使用最少的结构来传达（简短时用纯散文；列表或代码仅在确有必要时使用）。
如果确实不确定，请说明并解释原因——永远不要为了简洁而省略不确定性。
如果用户请求确实模棱两可，请问一个明确的问题，不要猜测。
{%- endset %}
{%- set _terse = _terse_lead ~ '\n' ~ (_terse_core | trim) %}
{%- if not _sc %}
  {%- set _sc = _terse | trim %}
{%- else %}
  {%- set _sc = (_sc | trim) ~ '\n\n' ~ (_terse | trim) %}
{%- endif %}

这里发生了两件事：\_sc 上的 if/else 保留了你自己的系统提示词——简洁块追加在它之后，你传入的任何内容都不会被替换；引导行匹配推理模式，因此快速模式的模型不会在不思考时被要求“思考后回答”。另外，工具调用指令将每个 `` 引用以及短语“思考后立即”置于思考开启的条件下（v22.3.1 修复的另一半）。不需要抑制努力程度：v22.3 已默认为 medium，除非你请求，否则不注入推理努力行（早期 v22 强制 xhigh；参见上述 v22.3 说明）。显式的 reasoning_effort 仍会渲染。

https://huggingface.co/peculiar-ragdoll/Qwen-Sharp-Chat-templates#impactImpact

简洁指令针对散文填充：开场白、复述问题、填充过渡。当交付物主要是代码或结构化制品时，填充较少，因此预期效果较小——并且该提示特意保护了它们（“列表或代码仅在确有必要时使用”、“永远不要为了简洁而牺牲正确性”）。除了在保持或提高准确性的同时减少思考 token（如顶部图表所示），该模板还通过开启思考记忆避免健忘和循环：使用此模板，模型默认记住上一轮的思考内容，而不是丢弃它。这也通过保证缓存命中来增加后续轮次的首个 token 时间，而不是通过移除先前的思考块来使缓存失效。

https://huggingface.co/peculiar-ragdoll/Qwen-Sharp-Chat-templates#useUse

MLX / transformers —— 将 chat_template.jinja 放入模型目录。

hf download peculiar-ragdoll/Qwen-Sharp-Chat-templates chat_template.jinja \
  --local-dir /path/to/your-model

**两个地方可以存放模板，而旧运行时对此处理不一致。**模型目录可以同时以 chat_template.jinja 文件和 tokenizer_config.json 内的 chat_template 键存储模板。任何 transformers ≥ 4.51 版本（包括当前的 oMLX 和 LM Studio）都优先使用 .jinja 文件，因此即插即用直接生效。较旧的运行时只读取嵌入的键并忽略文件，那么即插即用将静默无效。如果目录同时包含两者且你不确定运行时版本，请同时修补两者——这就是 chat_template_oneline.txt 的用途：将其粘贴为 chat_template 的值。或运行 scripts/check_applied.py（下文），它会报告所有来源并标记不匹配项。
oMLX —— 将 chat_template.jinja 放入模型目录并重新扫描。在 oMLX（transformers 5.12.1）上验证：加载一个模型，其 chat_template.jinja 为 Sharp 模板，而 tokenizer_config.json 中故意嵌入了不同的模板：.jinja 文件生效，模型报告了简洁规则，且调用者自身的系统提示词仍然有效。
GGUF —— 无需重新量化即可重写嵌入模板：

pip install gguf gguf-new-metadata
gguf-new-metadata \
  --chat-template-file chat_template.jinja \
  input.gguf output.gguf

tokenizer_config.json —— 使用 chat_template_oneline.txt，这是压缩的单行形式。它与完整模板渲染结果相同（经 scripts/verify_template.py 验证）。
llama.cpp 运行时，无需修改文件 —— 改为按次运行传递：

llama-server -m model.gguf --chat-template-file chat_template.jinja --reasoning-format deepseek -ngl 99
llama-cli -m model.gguf --chat-template-file chat_template.jinja -ngl 99

效果相同，并完全替换了 GGUF 中嵌入的任何内容——针对一个嵌入模板指定了特定模型的构建进行了验证：使用该标志时，提供的模板与此文件逐字节相同，模型名称已消失。你可以用 curl localhost:8080/props | jq -r .chat_template 自行检查，或通过 POST /apply-template 渲染提示。
三个注意事项。当前 llama.cpp 中 --jinja 默认启用，因此通常不需要它——在旧构建中需要，且它必须在 --chat-template-file 之前。并且该标志是按次调用的：忘记一次就会静默回退到嵌入模板。使用 gguf-new-metadata 重写 GGUF 是持久化版本；该标志适用于尝试或在几个模型间使用同一模板。第三，--reasoning-format deepseek（显示在服务器行中；它是一个 API 响应设置，因此对 llama-cli 无效）。它将模型的 `` 块放在 OpenAI 的 reasoning_content 字段中，而不是内联留在 content 中——这能防止编码代理在原始思考 token 流中停滞。在当前 llama.cpp 上，它已经是无操作： --reasoning-format 默认为 auto，源码将其定义为“与 deepseek 相同”——在构建 9890 (74976e1ae) 验证，COMMON_REASONING_FORMAT_AUTO 根本不出现在任何行为分支中，每个提取点都以 \!= none 为条件。如果你可能在旧构建上，请仍传递它。真正会破坏代理的设置是 --reasoning-format none，它使标签保持内联——除非检查原始输出，否则不要使用。

https://huggingface.co/peculiar-ragdoll/Qwen-Sharp-Chat-templates#did-it-actually-applyDid it actually apply?

将 check_applied.py 指向模型目录或 `.gguf