大型纪录片：Qwen 3.8 27B 优化思考-> 拯救工具调用 【欢迎指正】

[KoKoQ]

为什么"分档思考"对你收益很低
思考档位这个旋钮，只在你被"算力成本"卡住、又需要一点质量的时候才有意义。而你的情况是：

能力天花板才是瓶颈，不是思考档位。 27B 再怎么"多想"，也变不成 671B。thinking 只是让同一个弱模型多花几倍 token 去硬挤那点正确率，收益被天花板死死压住。这正好印证你说的"压缩收益率很低"。
你有云端大模型。 既然难的、要质量的任务可以甩给云端，本地模型就没必要为了"多几分"去调档位、付延迟和 token 成本——要质量直接上云，更简单、更准。
工程成本不划算。 在 new-api 里维护 3 个渠道 + 一套路由逻辑 + 反复调参，换来的是本地模型 88 分→91 分这种边际提升。性价比趋近于零。
所以：别在本地模型上做"思考档位"路由。 这个方向基本可以砍掉。

那本地模型到底该干什么（定位）
本地的价值从来不是"质量上打平云端"，而是这几件事：

场景 本地模型合适吗
高频、简单、重复（摘要、格式化、闲聊、模板） 便宜、快、不占云额度
隐私/敏感（不离开局域网） 唯一选择
离线/断网可用
复杂推理、写代码、长链 agent 直接上云
而这些场景里，你根本不需要"思考档位"——简单任务直接不思考、越快越好。

正确的架构：是"模型级路由"，不是"思考档位路由"
真正值钱的旋钮是**"这个任务派给本地还是云端"**，而不是"本地开几档思考"。
本地模型：开思考都别开，就一个档位，快就完了。它的定位是"便宜量大管饱"。
云端：要什么质量、什么 effort 都有，天然就是"分档"的，不用你操心。
你那个 agent 网格里，Hermes 本来就支持 fallback 链——让每个 agent 默认走本地，本地搞不定/需要深度时自动升到云端。这才是主架构，思考档位是旁枝末节。

[kop wang]

思考档位应该直接限制的是thinking输出的长度。和模型输出长度最大值类似的原理。

总输出长度越短，模型能够遍历的统计学最优区间就越少。找到最优解的可能性就会降低一些。

[stxpnet]

@KoKoQ 我目前做的并不是想提升模型的智商，

根据使用量化模型的经验，被量化过的模型，使用时可能会有意无意的忽视
或者弄错一些工具调用。这就导致它可能无法完成任务，或者能完成任务，但是步骤和TOKEN数会增加。

我做 这个的意义是：在模型被量化，换了配置的情况下，尝试给我当前配置制作一套思考提示词，让模型的工具调用分数更高，更适配我所需要用的Hermes,Cluade code,Trae等客户端 。

[neo]

我发现用codex的时候，3.8 思维会敏捷些，理论上应该跟DSH是一样的，不知道这是不是我的错觉。而且codex的kv缓存命中也非常高，只是它没有像DSH那样展示出来而已，说明它的system prompt优化得很好，怪不得@terry 说好用。

[stxpnet]

感觉工具调用 确实有进步，忘记记录耗时了，不过这个调查结果和整个过程我很满意！

[用户名违规]

现在sglang最大的问题prefill很严重，一个用户对话，sglang最大上下文256k时候，超过70k后就开始频繁prefill。特别浪费时间，你有这个问题吗？解决没有？

[stxpnet]

我不用了，sglang开了两天，cpu和gpu功耗下不来，以后有时间再研究了，现在这个vllm跑着比较舒适。

[iamvirus]

该jinja模板为默认中等思考等级是最佳配置

[joker_chang]

@iamvirus 我已经在在抄大佬的作业，准备在我本机尝试了。

等我当前的任务跑完，我验证以下结果，来交作业

[applejuice]

@用户名违规 我想问
你们怎样发现 prefill问题

我本身部署成功 测了 performance，满意后基本不再看后端
除非重大问题 不然也不会看后端数据了

[用户名违规]

@applejuice 看日志啊，因为hermes 会10轮工具调用后，就要提取，就会抢占kvcache就出现了prefill的情况。因为慢。。所以会变慢，我是256K，200K做压缩，时间就比较长，就特别明显。。所以就曲线救国了，压缩就交给其他模型做了，丝滑得很。