Qwen3 Coder Next：首个对我而言“可用”的60GB以下编程模型

过去我尝试过许多小于60GB的“小型”模型，包括GLM 4.5 Air、GLM 4.7 Flash、GPT OSS 20B和120B、Magistral、Devstral、Apriel Thinker、之前的Qwen编程模型、Seed OSS、QwQ、DeepCoder、DeepSeekCoder等。那么，Qwen3 Coder Next在OpenCode或VSCodium的Roo Code中有什么不同呢？

• 速度：推理模型通常（但并非总是）能产生相当不错的结果。然而，它们偶尔会陷入推理循环，即使采样设置正确，也可能导致在长时间运行中完全没有结果。此外，OpenCode或Roo会诱导的有时冗长的多步骤推理过程会耗费大量时间，极大地减慢了交互式工作。相比之下，Q3CN是一个指令型MoE模型，没有内部思考循环，生成token的速度相对较快。
• 质量：其他模型偶尔会在工具调用上出错。而Q3CN似乎工作可靠。我终于觉得它能够处理一个中等复杂的代码库，包括自定义客户端和服务器、不同的编程语言、protobuf以及一些特殊情况。它对极端的“多跳”问题提供了很好的答案，并能可靠地进行全栈更改。嗯，几乎是这样。在Roo Code中，它有时有点“懒惰”，需要提醒才能真正深入以获得正确结果。其他模型则经常迷失方向。
• 上下文大小：在大型项目上编码需要上下文。大多数采用标准注意力机制的模型会迅速耗尽你的显存。而Q3CN轻松支持100k+的上下文。少数其他模型也支持这一点，但在前两点（速度和质量）上存在不足。

我这样运行模型： set GGML_CUDA_GRAPH_OPT=1 llama-server -m Qwen3-Coder-Next-UD-Q4_K_XL.gguf -ngl 99 -fa on -c 120000 --n-cpu-moe 29 --temp 0 --cache-ram 0 在GPU上几乎没有其他负载的情况下，这在24 GB显存和64 GB系统内存的配置下运行良好。对我来说，它能达到大约180 TPS的提示处理速度和30 TPS的生成速度。

• temp 0？是的，对我来说，这对于指令型模型效果很好，不需要更高的温度来增加“创造力”。它能防止在编码时偶尔输出不太可能（且不正确）的token的问题。
• cache-ram 0？缓存本应很快（30毫秒），但我看到每次请求后查询/更新时间长达3秒。所以我没有进一步调查就禁用了它，反正它只是一个槽位中的一个长对话历史。
• GGML_CUDA_GRAPH_OPT？这是一个实验性选项，用于提高TPS。通常有效，但会破坏某些模型的处理。

OpenCode vs. Roo Code：

两者都能用模型解决问题，但在OpenCode中我看到了稍微更正确的答案和解决方案。但是：Roo默认会询问每一个细节，即使是像通过命令行运行语法检查这样无害的事情。这可以通过简单的权限列表进行配置，以避免频繁中断自动化流程。另一方面，OpenCode在代码模式下默认允许一切。有一次，它遇到了一个问题，尝试通过卸载和重新安装包来解决，结果删除了文件，并破坏了开发环境，把自己逼入了绝境。它在“完成任务”方面过于自主，这对于训练集中没有的尖端技术来说效果不佳。权限当然也可以配置，但默认是“YOLO”（你只活一次）。

除此之外：尽管只运行本地托管模型，并禁用了更新检查和新闻下载，OpenCode（桌面版）在启动时仍会尝试联系大量IP地址。