让本地 AI 更聪明、更快

我们希望本地编码代理既智能又高效，能够理解代码库、完成有用的工作，并且无需长时间等待即可结束任务。此次 Junie Local 更新让在您的设备上使用更强大的模型变得切实可行。

在 首次发行 中，我们不得不在同一模型的两个版本之间做出选择。在禁用推理的情况下，Qwen3.6 的速度足以在笔记本电脑上流畅运行。

而 Qwen3.8 能完成更多任务，但必须启用推理才能稳定工作，这使得每项任务的耗时大约延长了四倍。我们最终选择了速度优先。

本次更新旨在消除这种取舍的必要性。我们通过等比例融合这两个版本，构建了 Qwen3.8-3.6-27B-混合。在我们的编码评测中，它完成的任务数量超过了 Qwen3.6，同时生成的输出 token 数量仅为 Qwen3.8 的 71%。

在这篇文章中，我们将展示新模型在哪些方面提升了编码效果，如何使其高效运行，以及我们在测试过程中获得的经验。此外，我们还通过在 Windows 系统上提供实验性的 NVIDIA 支持，将 Junie Local 推广到更多机型。

更智能但思考更少的模型

在我们的内部百题编码基准测试中，新模型完成了 37 道题目，而禁用推理的 Qwen3.6 完成了 34 道。它的表现接近于 Qwen3.8 的 39 道正确解，同时生成的输出 token 数量减少了 71%。

我们真的节省了 token 吗？

对于 token 节省的一种可能解释是：混合模型在陷入困境时确实会消耗更少的 token。为了验证这一假设，我们比较了 Qwen3.8 和混合模型都成功完成的 30 道题目的 token 使用情况。

在这些题目上，混合模型生成的 token 大约少了 70%——混合模型为 27.9 万，而 Qwen3.8 为 93.5 万。在其中 29 道题目上，混合模型的 token 消耗均更少，进一步证明了其 token 效率。

一次值得尝试的简单合并

我们从一个简单的实验开始。由于 Qwen3.8-27B 基于 Qwen3.6-27B，且两者架构相同，我们便将它们的权重按相同比例直接合并，得到一个无需额外后训练的单一 27B 模型。

然而，这个简单的混合模型已经带来了令人惊喜的提升。早期结果超出预期，因此我们集中精力在更多基准和任务上评估该模型。基于这些评估结果，我们有信心将其作为本次发布的主模型，同时继续开展其他实验。

降低推理时间的方法有很多，包括蒸馏、强化学习，以及更复杂的模型融合技术。我们仍在进行更广泛的模型与运行时实验，相关成果将在未来的 Junie Local 版本中陆续发布。

多基准、多次运行

为了考察新模型在代理式编码任务之外的表现，我们在多个公开基准上对其进行了评测。重复运行评测有助于我们观察哪些任务能被稳定解决，不同运行之间的差异有多大，以及某个结果是否依赖于某次偶然的有利采样。

在四轮 LiveCodeBench 测试中，混合模型的平均正确率为 85.47%，与 Qwen3.8 的 83.29% 相当，且输出成本相近。Qwen3.6 的四次完整运行平均正确率为 67.87%，每次消耗约 2410 万输出 token；而混合模型约为 614 万。

视觉类基准则揭示了另一种权衡：混合模型使用的 token 显著少于启用了思考功能的 Qwen3.6，但多于 Qwen3.8。我们在问题、图像和生成设置完全一致的情况下发现，额外的 token 消耗几乎全部源于混合模型在推理上花费了更多时间。

后续工作

当混合模型难以找到解决方案时，仍有可能过度思考。如果 Junie 一直反复尝试同一种方法，却未获得新的证据或有用的工具结果，我们建议中断并以更明确的目标重新启动它。

此外，提高成功推理的效率仍有空间。在四次相同的基准测试中，思维链（CoT）的长度变化很大。如果仅保留较短的正确路径，token 消耗可减少 24.5%，这表明存在更短的成功路径，我们或许可以教会模型在不损失性能的前提下选择这些路径。

让模型高效运行

模型决定了 Junie 生成多少文本，而运行时则决定了这些文本到达您手中的速度以及所需的内存容量。我们的目标是同时优化这两者。

关于推测解码的猜想

Junie Local 已经采用了多 token 预测（MTP）。一个名为 MTP 头的小子网络会提出多个候选 token，由主模型并行校验。正确的预测会带来每轮更多的输出 token。

我们希望增加正确预测的数量，但这也会增加 GPU 的计算负担，因此并不总是意味着更快的生成速度。

MTP 应该预测多少个 token？

在搭载 M5 芯片的 MacBook Pro 上，每轮预测两个 token 使解码速度比不使用 MTP 时快了 60%。若增至四个，提速效果降至 36%，因为草案与校验带来的额外 GPU 计算量抵消了接受更多 token 所带来的收益。

MTP 的准确性重要吗？

我们比较了四位 MTP 头（Q4）与八位 MTP 头（Q8）在真实编码场景中的表现，分别在五个上下文长度下进行测试，范围从 1.6 万到 12.8 万 token，每个长度设置三个随机种子。

Q4 的预测接受率为 63.0%，Q8 为 63.6%：

接受率反映了猜测的有效性，而解码速度则衡量其是否真正节省时间。

我们并未发现 Q8 MTP 头在速度上有明显优势，因此为了节省内存，我们仍采用 Q4 配置。

为了解释为何较长上下文会拖慢 MTP，我们对 token 校验过程中的 GPU 负载进行了剖析。注意力机制的计算贡献了大部分增长：其单轮耗时从 8.4 毫秒上升至 40.2 毫秒，而前馈与 Gated DeltaNet 的计算时间基本保持不变。

这一 MTP 限制导致在长时间的编码会话中，即使预测依然准确，Junie 的响应也会变慢。我们正在研究如何降低这种校验开销，以确保会话持续时 Junie 仍能保持灵敏的响应。

一个隐藏的瓶颈

在开发初期，我们的内部评测显示性能有所下降，但在实际使用 Junie Local 时却无法复现。原因是我们为了使评测可重现而引入的一个设置：每次请求都使用相同的随机种子。

这造成了数值上的不稳定——重复使用同一种子会让同一个 token 在每次采样时获得相同的随机优势。当模型的预测趋于相似时，即便提示已改变，也可能被引导回失败的操作。

值得注意的是，Qwen3.8 受到这种不稳定性的影响尤为显著。

我们通过在每个代理步骤和反思尝试时递增种子来修正这一设置，从而在保证测试可重现的同时，允许后续尝试走向不同的路径。

立即体验升级

搭载 Apple M5 芯片的用户现在可以通过 Junie 尝试新模型：

junie

运行 /local 并安装 Qwen3.8-3.6-27B-blend，即可切换到该模型。请确保 Junie 已更新至最新版本。

对于 Windows 用户，Junie 的夜间版现已提供实验性的 RTX 支持，覆盖所有基于 Ampere 或更新架构、显存至少 24 GB 的 NVIDIA RTX 显卡。

junie --channel=nightly

这一早期预览让您可以在 Windows 上试用 Junie Local，并通过反馈助力其开发完善。

您可以找到 Qwen 3.8-3.6-27B-混合在拥抱脸上。

Qwen3.8-3.6-27B-blend 只是我们更广泛模型与运行时研究的一项成果。我们仍在持续推进相关工作，未来更多成果将在后续的 Junie Local 版本中呈现。

试试六月本地