Fine-Tune Qwen3-Coder-Next with Ertas

Overview

Qwen3-Coder-Next 由阿里巴巴于 2026 年 2 月 2-4 日发布,是当年架构最为激进的开放权重发布之一——一个 800 亿参数的专家混合模型,每 token 仅激活 30 亿参数。26:1 的总参数与活跃参数比率在开放权重生态中名列最激进之一,该模型证明了超稀疏 MoE 设计能够在每活跃参数性能上显著优于稀疏度较低的替代方案。

标志性基准结果引人注目。尽管活跃参数量比 DeepSeek V3.2(37B 活跃)少 10 倍,比 Kimi K2.5 / GLM-4.7(各 32B 活跃)少 10 倍,Qwen3-Coder-Next 在智能体编码基准上仍能与之匹敌甚至超越。SWE-Bench Verified 约 70.6% 的得分使其与推理成本大幅更高的模型展开有力竞争。对于 token 成本经济性至关重要的生产部署——高吞吐量编码代理、CI 集成的代码审查系统、规模化 AI 结对编程——Qwen3-Coder-Next 是当前最具成本效益的开放权重选项之一。

该架构专为智能体编码部署而设计。与更广泛的 Qwen3-Coder 系列一样,后训练注重可验证代码执行奖励和多步智能体轨迹。256K 上下文窗口对大多数项目而言足以支持完整代码库推理,得益于借鉴自 Qwen3-Next 研究线的架构改进,其有效上下文保留能力优于在相同标称长度下采用朴素 RoPE 扩展的模型。

Apache 2.0 许可与小巨人式的推理经济性相结合,使 Qwen3-Coder-Next 对自托管编码代理部署尤具吸引力。权重可在 Hugging Face 的 `Qwen/Qwen3-Coder-Next` 下获取。该模型可通过标准 MCP 与函数调用接口与 Qwen-Agent、Claude Code、Cline、Aider 及其他智能体编码 CLI 原生集成。

Key Features

26:1 总参数与活跃参数比的超稀疏 MoE 是 Qwen3-Coder-Next 标志性的架构选择。80B 的总参数容量提供广泛的知识覆盖,而 3B 的活跃参数量将推理经济性保持在消费级 GPU 范围内。在标准推理框架上的 token 生成吞吐量约为 3B 级速度,使该模型可部署于对延迟敏感的生产场景中——而活跃参数更多的替代方案在此类场景下会过慢。

以编码为重点的训练带来了真实可靠性。后训练流水线注重可验证的代码执行结果——模型因生成实际可运行并通过测试的代码而获得奖励,而不仅是看起来正确的代码。结合多步智能体轨迹训练(规划、工具使用、观察输出、迭代),这造就了一个在处理真实生产编码代理工作负载时比同等规模通用模型更加可靠的模型。

与智能体编码 CLI 生态的原生集成在运维上意义重大。Qwen3-Coder-Next 是专为接入 Claude Code、Cline、Aider 等工具而设计的——其提示格式、工具使用模式和多轮行为均与这些工具所期望的模式相匹配。对于从基于 Claude 或 GPT 的编码代理转向自托管替代方案的团队,集成摩擦显著低于从通用基座出发再做适配。

Apache 2.0 许可、256K 上下文与推理经济性的结合,使 Qwen3-Coder-Next 在生产自托管部署中尤具吸引力。256K 上下文可处理大多数代码库的完整仓库推理,而该许可消除了与限制性许可替代方案常伴的商业部署摩擦。

Fine-Tuning with Ertas

Qwen3-Coder-Next 3B 活跃参数的 MoE 架构使其在 Ertas Studio 中微调极为高效。QLoRA 微调可在单块 24GB GPU 上从容运行——活跃参数量驱动训练时计算,因此 80B 总参数量影响内存占用,但不影响每步训练成本。

在微调数据集方面,Qwen3-Coder-Next 从包含完整智能体编码轨迹(任务描述、规划、代码编辑、测试输出和迭代)的训练数据中获益良多。Ertas Studio 原生支持这些多步格式,包括来自 Claude Code、Cline 或 Aider 运行的工具使用轨迹。基于团队特定编码模式与代码库约定进行训练,可获得在你代码库内任务上以显著优势超越基座的领域专精模型。

训练完成后,Ertas Studio 会导出为 GGUF 格式,完整保留 Qwen3-Coder-Next 的聊天模板。Q4_K_M 量化约为 45GB——可在单块 48GB GPU 上运行,或通过模型并行拆分到两块 24GB GPU 上。尽管总参数量为 80B,推理仍以约 3B 级速度运行,使微调后的部署在高吞吐量智能体编码工作负载下切实可行。

Use Cases

自托管智能体编码代理是 Qwen3-Coder-Next 的核心目标。生产部署模式包括针对常规变更模式的自主 PR 生成、具备团队特定代码库理解的 AI 结对编程(通过微调实现)、CI 集成的代码审查与测试生成,以及大规模重构辅助。前沿级编码能力与小活跃参数推理经济性的结合,使自托管部署在远高于其他方案可承受的请求量下,仍能与基于 API 的方案相竞争。

对于考虑替代 Claude Code、Cursor 后端模型或 GitHub Copilot 的自托管方案的团队而言,Qwen3-Coder-Next 是 2026 年最具吸引力的选项之一。Apache 2.0 许可结合其推理经济性,在比 Kimi K2.6 或 DeepSeek V4 等更大 MoE 替代方案更低的请求量下即可达到收支平衡,使其对小型团队更可负担。

完整代码库推理工作流可受益于 256K 上下文。架构审查、跨整个代码库的安全审计、依赖升级影响分析以及大规模重构规划,对大多数真实代码库都能在 Qwen3-Coder-Next 的上下文窗口内完成。结合优于朴素长上下文模型的有效上下文保留能力,可实现更小上下文替代方案无法企及的整体性代码库推理模式。

Hardware Requirements

Qwen3-Coder-Next 在 Q4_K_M 量化下大约需要 45GB 内存(加载所有专家权重)。单块 48GB GPU 是部署的甜蜜点,可同时容纳模型与合理上下文,并为 KV 缓存留有余量。或者,64GB+ 的 Apple Silicon Mac(M2/M3/M4 Ultra Mac Studio)可通过 MLX 以完整质量部署该模型。

尽管总参数量为 80B,推理速度由 3B 的活跃参数量主导——在标准推理框架上的生成吞吐量约为 3B 级速度。这使 Qwen3-Coder-Next 在对延迟敏感的生产部署中切实可行,而 30B+ 活跃参数的替代方案则做不到。

关于在 Ertas Studio 中微调:得益于 3B 的活跃参数量,Qwen3-Coder-Next QLoRA 在典型序列长度下大约需要 22-30GB VRAM。借助梯度检查点,长上下文微调(32K-64K 序列)在 48GB GPU 上是可行的——比相同有效编码能力的同等质量模型微调具有显著更好的可访问性。