我们希望本地编码智能体既聪明又快速，能够理解代码库、完成有用的工作，并且无需长时间等待即可完成任务。本次 Junie Local 更新让在你自己的机器上使用能力更强的模型变得切实可行。

在首个版本中，我们不得不在同一模型的两个版本之间做选择。关闭推理时，Qwen3.6 的速度足以在笔记本上使用。Qwen3.8 能完成更多任务，但要稳定工作需要启用推理，这会让任务耗时大约增加四倍。我们选择了速度。

本次更新是我们为消除这种选择所做的尝试。我们通过按相同比例合并两者，构建了 Qwen3.8-3.6-27B-blend。在我们的编码评估中，它完成的任务比 Qwen3.6 更多，同时生成的输出 token 比 Qwen3.8 少 71%。

在本文中，我们将展示新模型在哪些方面改善了编码结果、我们如何让它高效运行，以及测试过程中学到了什么。我们还通过 Windows 上的实验性 NVIDIA 支持，将 Junie Local 带到更多机器上。

一个更聪明、思考更少的模型

在我们内部的 100 项编码基准测试中，新模型完成了 37 项任务，而关闭推理的 Qwen3.6 完成了 34 项。它接近 Qwen3.8 的 39 项解决数，同时生成的输出 token 少 71%。

[LOADING...]

我们真的节省了 token 吗？

token 节省的一种可能解释是，混合模型在卡住时会消耗更少 token。为了验证这一假设，我们比较了 Qwen3.8 和混合模型都完成的 30 项任务的 token 使用量。在这些任务上，混合模型生成的 token 大约少 70%——混合模型为 279K，而 Qwen3.8 为 935K。在这 30 项任务中的 29 项上，它使用了更少 token，进一步证明了其 token 效率。

[LOADING...]

一次值得测试的简单合并

我们从一个简单实验开始。由于 Qwen3.8-27B 基于 Qwen3.6-27B，且二者共享相同架构，我们只是按相同比例合并了它们的权重。这样无需任何额外后训练，就得到了单个 27B 模型。

然而，这个简单混合已经带来了出乎意料有用的改进。早期结果比我们预期更好，因此我们专注于在更多基准和任务上评估该模型。这次评估给了我们足够信心，使其成为本次发布所用的模型，同时其他实验仍在继续。

减少推理时间的方法有很多，包括蒸馏、强化学习以及更精细的模型合并方法。我们正在继续更广泛的模型和运行时实验，更多成果将出现在未来的 Junie Local 版本中。

多基准、多次运行

为了了解新模型在智能体编码任务之外的表现，我们在多个公开基准上进行了评估。重复运行评估让我们看到哪些任务能持续完成、不同运行之间的方差有多大，以及结果是否依赖于某个有利样本。

[LOADING...]

在四次 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 带来的收益。

[LOADING...]

MTP 准确率重要吗？

我们比较了 4 位 MTP 头（Q4）和 8 位 MTP 头（Q8）在真实编码轨迹上的表现，涵盖从 16K 到 128K 的五种上下文长度，每种使用三个随机种子。Q4 接受了 63.0% 的提议，Q8 接受了 63.6%：

[LOADING...]

接受率告诉我们猜测多大比例是有用的，而解码速度告诉我们它们是否节省时间。

[LOADING...]

我们发现 Q8 MTP 头没有一致的速度优势，因此保留 Q4 以节省内存。

为了理解 MTP 为何在更长上下文中变慢，我们在 token 验证过程中对 GPU 负载进行了分析。计算注意力占了大部分增长：其时间从每轮 8.4 ms 上升到 40.2 ms，而前馈和 Gated DeltaNet 计算几乎保持平稳。

[LOADING...]

这种 MTP 限制导致 Junie 在长时间编码会话中响应变慢，即使其预测仍然准确。我们正在研究如何降低这种验证成本，让 Junie 在会话进行时保持响应。

一个隐藏的卡点

在开发早期，我们的内部评估显示出性能下降，而实际使用 Junie Local 时却无法复现。原因是我们为了让评估可复现而引入的一项设置：每个请求都收到相同的随机种子。这导致数值不稳定，因为重复使用种子会让相同 token 在采样器每次生成 token 时获得相同的随机优势。当模型预测保持相似时，即使提示已经改变，它也可能被引导回不成功的动作。值得注意的是，Qwen3.8 受这种不稳定的影响比我们测试的其他模型更大。

[LOADING...]

我们通过在每个智能体步骤和反思尝试时推进随机种子来修正设置，让后续尝试可以走不同路径，同时保持测试可复现。

尝试升级

Apple M5 用户已经可以通过 Junie 试用新模型：

junie

运行 /model 并选择 Qwen3.8-3.6-27B-blend，即可将 Junie Local 切换到该模型。请确保 Junie 已更新到最新版本。

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

junie --channel=nightly

这个早期预览让你可以在 Windows 上试用 Junie Local，并通过反馈帮助塑造其开发。

你可以在 Hugging Face 上找到 Qwen3.8-3.6-27B-blend。

Qwen3.8-3.6-27B-blend 只是我们更广泛的模型和运行时研究的一项成果。我们正在继续这项工作，你将会在未来的 Junie Local 版本中看到更多成果。