Ivan Fioravanti 在 DGX Spark 上跑了一组 Qwen3.6-35B-A3B-UD-Q8_K_XL 的 llama.cpp 基准测试。结果很直白：

- 2k 上下文：prompt 1573 t/s，gen 79 t/s

- 8k：gen 79 t/s

- 64k：gen 58 t/s

- 256k：gen 31 t/s



速度从 79 t/s 滑到 31 t/s，斜率不算陡，但 256K 上下文下 TTFT（首 token 延迟）飙到 97 秒，TPOT 也涨到 29 秒。长上下文推理的代价依然肉眼可见。

MiaAI Lab 为这个模型准备了一键启动脚本，专为 DGX Spark 和 96-128GB VRAM 机器设计。自动下载 GGUF 文件、健康检查、后台运行、OpenAI 兼容 API，一个 `./start.sh` 搞定。GitHub 仓库里还贴心地给了 stop.sh 和详细的环境变量配置。

> 有网友问为什么不用 vLLM？Mia 回复：GGUF 在 llama.cpp 上跑得更好，这个 35B 的 GGUF 版本比其他格式强。

更有意思的是另一个编码测试。Topi Santakivi 做了一个 11 模型对比，用两个非 trivial 的编码任务（可恢复同步 + 可插拔组件）来测架构判断力和歧义处理能力。结果：

- **Qwen 3.6-27B-8bit (本地)**：66.5/80

- **Claude Sonnet 4.5**：65/80

- **Qwen 3.6-35B-A3B-8bit (agent-pair)**：64/80

- **DeepSeek-V4-Flash-REAP-180B**：62/80

本地 8-bit 量化的 27B 模型，总分压过了 Sonnet 4.5。35B-A3B 的 agent-pair 模式（一个模型写代码，另一个实时 review）也拿到了 64 分，比 solo 4-bit 版本高了 5 分。

反常识的点在于：量化精度和推理框架对实际编码能力的影响，可能比参数数量更关键。27B-8bit 本地 > 35B-4bit 云端，而 35B-A3B-8bit 加上 agent-pair 协作，几乎追平 Sonnet。

当然，显存门槛是现实的。DGX Spark 128GB 统一内存刚好塞下 Q8_K_XL 的 39GB 权重 + 256K KV cache + mmproj + MTP 草稿上下文。48GB 的 RTX 6000 得降上下文或换小量化。

Mia 的回复里有个动图，一个金发女巫在施法——配文是“你将会被它的表现震惊”。目前看，确实有点东西。

如果你手头有 DGX Spark 或者 96GB+ 显存的机器，可以试试这个启动脚本。GitHub: [MiaAI-Lab/Qwen3.6-35B-A3B-UD-Q8_K_XL_DGX-Spark-Recipe](https://github.com/MiaAI-Lab/Qwen3.6-35B-A3B-UD-Q8_K_XL_DGX-Spark-Recipe)