JetBrains Junie支持全离线运行

大多数 AI 编程工具默认使用云端托管模型，而本地模型运行时已经成为一种可行的替代方案，尤其适合希望将代码保留在本地、避免按请求计费的 API 成本，或需要在离线环境下工作的开发者。

Cline、Continue 和 Aider 等工具已经可以对接 Ollama 或 LM Studio 等运行时。与此同时，GitHub 也在 4 月为 Copilot CLI 添加了本地模型支持，包括用于完全物理隔离环境的离线模式。

但问题是，"本地"通常仍然需要开发者自行完成大量组装工作。你必须为硬件选择合适的模型和量化级别，配置运行时和上下文设置，并找出哪种组合能更好地配合 Agent 运行。

而最后这一点确实很关键：能够在笔记本电脑上流畅运行的小型模型，在面对编程 Agent 所要求的工具使用、推理和长时间运行任务时，仍然可能表现吃力。

正是因此，JetBrains 推出了 Junie Local——一款完全运行在开发者本地机器上的免费版编程 Agent。

简单回顾一下：JetBrains 是 IntelliJ IDEA、PyCharm 和 WebStorm 的开发商，于 2025 年 1 月推出了嵌入其 IDE 的 AI 编程 Agent Junie，能够规划任务、修改代码、运行测试和检查，并基于开发者的项目上下文工作。此后它已扩展为独立的 CLI 工具。

Junie 本身在本地模型方面并非全新尝试。JetBrains 市场负责人 Dmitry Savelev 在周一发布的博客文章中指出，开发者此前已经能够将 Agent 连接到 Ollama 和 LM Studio 等运行时，加载任意想要的模型，让 Junie 在本地运行。

不过，在 Junie Local 中，JetBrains 已经选定了模型、完成量化，并围绕该特定组合调优了推理引擎和 Agent 框架。设置在 Junie 内部完成：运行 /local 会下载模型和推理引擎、启动本地服务器，并自动切换 Agent。无需单独安装 Ollama 或 LM Studio，无需配置端点，也无需编写模型配置文件。

第一步只需从模型选择器中选择 Junie Local，它与常规的云端托管模型并列显示。

下载和设置完成后，Junie 切换到本地 Qwen 模型，此后它就像其他模型选项一样出现在 CLI 中。

从此推理完全在开发者的机器上完成。

底层解析：为什么是 Qwen3.6——又为什么是 M5 Mac

值得注意的是，JetBrains 在模型选择上非常明确，没有选择最新、最亮眼的开源权重版本。Junie Local 使用的是 Qwen3.6-27B，这是一款于 4 月发布的 270 亿参数开源权重模型，尽管较新的 Qwen3.8-27B 在 8 月早些时候已经推出并有改进。

"在如今的 Mac 上，3.6 胜出。"

Savelev 指出，选择依据是这两个模型在当前 Mac 上的 Junie 内部表现：Qwen3.8 需要启用推理模式才能与 Agent 可靠协作；开启推理后，任务耗时大约增加四倍。对于当前的 Junie Local，Qwen 3.6 提供了更好的可靠性和速度平衡。

"在如今的 Mac 上，3.6 胜出，" Savelev 写道。

JetBrains 使用基于 mlx-vlm 的推理引擎以 4-bit 量化运行 Qwen3.6-27B，而 mlx-vlm 底层使用了 Apple 的机器学习框架 MLX。这与 Ollama 在 3 月采用的方法类似——当时它将 Apple Silicon 引擎迁移到 MLX，以利用该芯片的统一内存架构。

不过硬件门槛相当高：JetBrains 确认 Junie Local 约有 20 GB 的下载量，需要 macOS 26、至少 64 GB 统一内存，以及 Apple M5 芯片或更新版本。实际上，64 GB 的要求将 MacBook Pro 用户推向 M5 Pro 或 M5 Max 的范畴——换句话说，这完全是高端 Mac 的方案。

JetBrains 承认这些要求会让许多本可能感兴趣的开发者无法使用 Junie Local。

"我们知道配备 64 GB 内存的 M5 Mac 是一个很高的要求，" Savelev 写道。"我们不会假装不是这样。在如今运行 27B 模型并运行良好，就需要这样的配置，这是我们正在努力降低的数字。"

"我们知道配备 64 GB 内存的 M5 Mac 是一个很高的要求。我们不会假装不是这样。"

目标是降低内存要求、支持更广泛的硬件范围，并持续优化底层技术栈。

"如果正是因为这些过高的要求你无法体验 Junie Local，请放心，我们正在努力降低它们，" Savelev 补充道。

归根结底，硬件要求与 JetBrains 识别到的本地编程 Agent 真正性能瓶颈密切相关。每秒 token 数（tokens-per-second）衡量的是模型生成输出的速度，但 Agent 在产生答案之前，可能需要大量时间摄取源文件、提示词和其他上下文——即预填充（prefill）阶段。

"每个人都在基准测试生成速度，" Savelev 写道。"但对于编程 Agent，这原来是一个错误的追逐目标，因为大部分时间都花在了预填充上，而模型正在读取文件以弄清楚发生了什么。优化预填充才是真正有收益的地方。"

免费且不限量也改变了开发者愿意交给 Agent 处理的工作类型。JetBrains 将 Junie Local 定位于特别适合长期、重复、机械性工作的场景——多文件重构和重命名、填补测试覆盖率空白、依赖升级和框架迁移——在这些场景下 Agent 可以持续工作和迭代，而开发者无需考虑它消耗了多少 token。

"长期、重复、机械性的工作正是 Agent 的用武之地，也正是当你盯着账户余额时会停止请求的工作，" Savelev 写道。

"长期、重复、机械性的工作正是 Agent 的用武之地，也正是当你盯着账户余额时会停止请求的工作。"

对于日常开发工作，Savelev 认为用户不太可能注意到与更强云端模型的显著差距。不过他确实承认，更复杂的架构推理仍然更适合那些云端模型。

当然，还有一个或许是最重要的原因——开发者对本地模型感兴趣的原因：隐私。完全在本地运行整个 Agent，意味着开发者和他们的代码之间没有外部模型提供商，也意味着源文件、提示词或生成的变更都不需要离开机器。对于在专有代码下工作的开发者、受客户 NDA 约束、或在向第三方发送源代码根本不可行的环境下工作的人来说，这是吸引力中很重要的一部分。

"下载之后的一切都在你的硬件上发生，所以你的提示词、源代码和 diff 都留在原地，" Savelev 写道。