8GB 显存跑 Qwen3.6 35B MoE 的 llama-server 配置 + 我踩的 max_tokens / thinking 陷阱

大家好，我这套 **Qwen3.6-35B-A3B** 在笔记本 **RTX 4060（8GB 显存）+ 96GB 内存** 上跑通了。注意，这不是交互式聊天，而是作为 **编码子代理** 塞进智能体流水线，所以下面部分参数只针对该场景。TL;DR * \- Qwen3.6 35B A3B 能在 8GB 显存 + 大内存下当编码子代理 * \- 我真正的 bug 不是崩溃：无限制 thinking 把 max\_tokens 全吃光了 * \- 关 thinking 可解决 * \- 更好方案：用 per-request thinking\_budget\_tokens * \- 开放问题：8GB 上 n-cpu-moe 怎么分最佳 # 硬件 / 运行时 * GPU：RTX 4060 笔记本，8GB 显存 * 内存：96GB DDR5 * 运行时：llama-server * 模型：Qwen3.6-35B-A3B GGUF * 用途：编码子代理 / 结构化流水线 # 现用 server 命令 llama-server \ -m Qwen3.6-35B-A3B-Q4_K_M.gguf \ -ngl 99 \ --n-cpu-moe 99 \ -c 50000 \ -np 1 \ -fa on \ --cache-type-k q8_0 \ --cache-type-v turbo2 \ --no-mmap \ --mlock \ --ctx-checkpoints 1 \ --cache-ram 0 \ --jinja \ --reasoning on \ --reasoning-budget -1 \ -b 2048 \ -ub 2048 **PowerShell 环境：** $env:LLAMA_SET_ROWS = "1" $env:LLAMA_CHAT_TEMPLATE_KWARGS = '{"preserve_thinking":true}' # 非直观参数说明 * `--n-cpu-moe 99`：8GB 显存下我把 MoE 层全扔 CPU，部分出于自己限制，部分来自社区调参，非官方建议。 * `-np 1`：单用户 / 单代理，不浪费内存开多余槽位。 * `-b 2048 -ub 2048`：实测在 2K+ token 提示下，prefill 明显比默认小 batch 快。 * `LLAMA_SET_ROWS=1`：社区小技巧，一试见效。 * `preserve_thinking: true`：Qwen3.6 官方支持，代理工作流里可把先前推理留在缓存，避免每轮重算。 # 重要区分：官方 vs 实测 下面几点是 **官方文档** 提到的： * `enable_thinking` * `preserve_thinking` * 默认开启 thinking 模式 * 针对编码 / thinking / 非 thinking 的推荐采样预设 其余参数纯属 **我目前最稳的实测值** 或 **社区调参**，特别是 MoE 放置、KV 配置、batch/ubatch 选项。因此本文定位是 **“可用配置 + 观察”**，非普世最佳。 # 我踩的坑：thinking 能把输出预算全吃掉 最初看似诡异 bug，其实是预算问题。我通过 OpenAI 兼容 API 调 `chat.completions.create`，每请求设 `max_tokens`。当： * `--reasoning on` * `--reasoning-budget -1` * 提示略长 * 编码任务诱使模型长篇内部推理 …模型可把全部输出额度花在 thinking 上，结果返回可见内容为空。实测如下： |max\_tokens|thinking|finish\_reason|可见代码输出|耗时| |:-|:-|:-|:-|:-| |6000|ON|`length`|空 / 不可用|\~190s| |10000|ON|`length`|空 / 不可用|\~330s| |5000|OFF|`stop`|\~3750 token 干净代码|\~126s| 所以某些编码任务里，模型并非“崩溃”，而是把预算烧在推理上。 # 重点：支持 per-request 控制 我原以为推理预算只能服务端硬编码，结果 llama-server 支持请求级字段： { "thinking_budget_tokens": 1500 } 只要 **CLI 没把 reasoning budget 写死**，这个字段就能生效。因此更干净的方案是： * 如需请求级控制，就别在 CLI 硬编码全局推理预算 * 简单重构任务直接关 thinking * 真正需要推理的任务再用 bounded thinking # 我现在的经验法则 |任务类型|Thinking|当前看法| |:-|:-|:-| |明确规格的重构|OFF|吞吐高，省 token| |中等模糊编码|ON，但限额|请求级预算最佳| |架构 / 设计权衡|ON|值得花成本| |固定模式抽取 / 结构化转换|OFF|schema 已搞定大部分| # 补充：别用 prompt hack 关 thinking 对 Qwen3.6，别指望 `/think` 或 `/nothink` 那种提示词当官方开关。文档路径是 `chat_template_kwargs`，尤其要非 thinking 模式就写 `enable_thinking: false`。所以我打算靠改模板参数切模式，而不是拼提示词。 # 想征求反馈 1. `--n-cpu-moe` **在 8GB 显存上** 有人找到比“全扔 CPU”更好的切分吗？ 2. `-b` **/** `-ub` **在长提示下的调优** 2048 目前对我够用，但常跑 50K+ 上下文的欢迎给数据。 3. **Qwen3.6 实测 KV 配置** 我现在按社区结果用 `turbo2`，好奇大家都定在哪档。 4. **代理编码的 thinking 策略** 如果你本地用 Qwen3.6 当编码工人，什么任务开 / 关 thinking？ 需要更多细节可留言。这是本地知识编译器 / 项目记忆流水线的一环，我更看重可靠结构化输出，而非聊天体验。