关掉 Qwen3.6-35B 思考链，速度暴涨 8 倍

上周我在双 RTX 3090 工作站上跑了几个月的 SGLang + Qwen3.6-35B-A3B MoE 出了两个问题：
1. 容器跑了几天后 sglang::scheduler 进程 CPU 一直是 100%
2. 用这个模型做多智能体辩论（6 个分析师来回吵），单只股票需要 20 多分钟
第一个问题让我怀疑是不是显卡坏了。第二个问题直接让整个系统不可用——18 只股票跑完需要 6 小时。
排查了几天，发现两个问题的根因都藏在 SGLang 的启动参数里。

---

一、CPU 100% 的元凶

先看问题 1。nvidia-smi 显示 GPU 利用率 0%（空闲），但 htop 里 sglang::scheduler 吃满一个核。
排查过程：
| 状态 | CPU | 说明 |
|:—|:—:|:—|
| 原始配置（带 4 个冗余参数） | 100% | 基线 |
| 移除 4 个冗余参数 | ~45% | ↓ 55% |
| 再加 --sleep-on-idle | ~17% | ↓ 28% |
两个因素叠加导致 CPU 100%：
因素 1：--enable-dynamic-chunking
这个参数是留给多机流水线并行场景的。官方源码 server_args.py 的定义是：
python
enable_dynamic_chunking: A[bool,
“Enable dynamic chunk size adjustment for pipeline parallelism.”,
] = False
默认就是 False。单卡场景加上它，调度器会做大量无意义的计算。贡献了约 55% 的 CPU。
因素 2：sleep_on_idle=False（默认）
SGLang 空闲时默认持续轮询请求队列，不会休眠。加上 --sleep-on-idle 后，空闲 CPU 从 45% 降到 17%。
修复很简单，去掉 --enable-dynamic-chunking，加上 --sleep-on-idle。

---

二、8 倍速度差距的源头

再看问题 2。分析日志发现一个诡异的现象：16 轮 LLM 调用中，有 8.5 分钟的空隙，期间没有任何日志输出。
![调用时序图]
| 阶段 | 调用数 | 耗时 |
|:—|:—:|:—:|
| 6 个分析师 | 6 轮 | 1.5 分钟 |
| 投资辩论（Bull/Bear/Judge） | 4 轮 | 8.5 分钟空隙 |
| 风险辩论 + PM 裁决 | 6 轮 | 1 分钟 |
那 8.5 分钟就是 Bull 辩手在”思考”——Qwen3.6 默认在回答前会生成 <think>...</think> 推理块，长度从几百到几千 token 不等。
实测对比：
| 指标 | 有思考 | 无思考 | 提升 |
|:—|:—:|:—:|:—:|
| 单只股票 | ~20 分钟 | ~2.5 分钟 | 8 倍 |
| 18 只股票 | ~6 小时 | ~45 分钟 | 从不可行到可行 |
| LLM 调用全部 | HTTP 200 | HTTP 200 | ✅ |
| 辩论内容质量 | 完整推理链 | 直接结论 | 差别可忽略 |

---

三、关闭思考的正确方法

Qwen3.6 标准版（非 Thinking 专用版）的 chat template 支持 enable_thinking 参数。设为 false 就直接跳过思考阶段。

踩坑记录

错误做法：自己写一个简化的 chat template。
我一开始写了个只有 message 格式的模板：
jinja
{%- for message in messages %}
{{- ‘