Junie 本地化：Qwen3.6-27B 推理优化全栈实践

JetBrains 近日发布了 Junie Local 的首个可用版本，可在 MacBook M5 上通过本地推理运行 Qwen3.6-27B 模型。官方博客详细披露了从 Junie 代理本身到推理引擎、再到模型参数的全栈优化思路，并解释了为何选择 Qwen3.6-27B 而非 Qwen3.8-27B。

项目背景

Junie 是 JetBrains 推出的编程助手代理，其云端版本依赖大型云模型完成复杂代码任务。为了让用户能在不同硬件配置下完全本地化运行 Junie，团队启动了长期项目 Junie Local。首个里程碑版本在 MacBook M5 上跑通了 Qwen3.6-27B，整套优化围绕「让本地推理足够快」这一目标展开。

Junie 代理层面的优化

扩展滚动上下文

与多数编程代理一样，Junie 的主循环是「用户提出任务 → 交给大模型 → 大模型返回工具调用 → 执行并回传结果」的循环。云端场景下，每次请求都会把所有上下文重新发给模型做 prefill，速度很快；但本地推理的 prefill 成本显著，重新读取文件耗时严重。

团队的解决办法是：让后续请求直接拼接到既有滚动上下文中，而非重新构建上下文窗口。这样可以复用上一轮任务的 KV 缓存——模型已读过的内容保留在窗口里，无需再次「读取」。

最大化初始可复用前缀

启动新会话时，Junie 实际上会向模型发送系统提示、项目初始化信息、文件树等多组内容，这些数据每次都要处理一次。团队调整了发送顺序，并在推理引擎中加入特殊逻辑，把用户请求之前的所有前缀都缓存起来。同一项目内的后续任务可以直接复用这一前缀，仅项目内上下文（顶层文件等变动频繁的小数据）保持每次重发。

进度提示适配

云端大模型会按特定 XML 风格输出进度更新块，但 Qwen 3.6 几乎不响应这种请求。好在 Qwen 3.6 会把动作说明写在工具调用的伴随文本里，团队顺势把这部分文本直接呈现为用户进度提示。这种适配具有模型特异性——其他模型要么完全不输出，要么输出过多。

精简非必要调用

团队关闭了所有可选的 LLM 请求，包括生成简短任务描述的逻辑，以及多代理模式。M5 上的本地推理是串行处理最有效率，多代理反而会被推理瓶颈拖慢。代价是损失了一部分用户体验，但团队认为换来的执行效率更值得。

模型参数优化

关闭推理

内部测试云端版 Qwen3.6-27B 时，团队发现开启推理模式并未带来明显质量提升，因此本地版直接禁用 reasoning_effort。由于推理 token 与生成主回答的 token 共用算力，关闭推理后所需生成 token 数下降 2–3 倍，任务执行速度提升约 2 倍，质量损失可以忽略。

选择 4-bit 量化

4-bit 版本在基准上只比 8-bit 版本略差，但生成环节是显存瓶颈，4-bit 比 8-bit 快约 2 倍。团队还注意到两者在 prefill 速度上几乎一致——这与离散 GPU 上「prefill 是计算瓶颈、速度快」的直觉相左，说明在 M5 这一统一内存架构上，prefill 仍有进一步优化空间（原文该部分探讨在摘录中被截断）。

整体思路小结

本次优化的核心可以归纳为三点：第一，让代理逻辑主动配合本地推理特性，最大限度地复用 KV 缓存与前缀；第二，关闭一切非必要的 token 生成，缩减每轮请求的工作量；第三，按硬件瓶颈特性选择量化精度，让生成阶段跑到内存带宽上限。整套方案在 27B 模型和 M5 这类消费级硬件上跑通了完整的代理工作流，为后续支持更多模型与硬件奠定了基础。