> ## Content Index > Fetch the complete content index at: https://www.hubwiz.com/blog/llms.txt > Use this file to discover other available public pages before exploring further. # JetBrains Mellum2 - URL: https://www.hubwiz.com/blog/jetbrains-mellum2/ - Published: 2026-06-17T16:33:08.000Z - Updated: 2026-06-17T16:33:08.000Z - Description: 本地AI的模型速度：什么才真正重要？测试不同模型并理解如何为你的任务选择最佳模型。 - Author: admin - Tags: MODEL-ZOO, MELLUM2, #Import 2026-10-14 14:41 并非所有模型生而平等。也并非所有生成式AI LLM都适合某项任务。 过去几个月，每个人都在谈论AI代理及其框架（我也是），所以我决定根据任务给你一个关于哪些模型最适合本地运行的诚实评测。 你可以将AI代理用于编程或知识库处理（如LLM维基风格项目）。但同一个LLM不能自动擅长两者。 让我们先理解框架到底是什么。 ## 1、代理框架 在进一步讨论之前，让我们确保在同一页面上。你一直听到"框架"这个词，但它到底是什么意思？ 这样理解：**模型**（Claude、GPT-4、Llama等）是大脑。它可以思考、推理、编写代码。但它不能自己*做*任何事情。它不能读取你的文件。它不能运行终端命令。它不能记住五分钟前发生了什么。 **框架**是身体。它是赋予模型能力的脚手架： - **文件访问** ➡️ 在你需要的地方读写 - **终端执行** ➡️ 运行命令、测试、构建 - **上下文管理** ➡️ 提示中包含什么、忽略什么 - **记忆** ➡️ 在会话之间保持状态 - **安全性** ➡️ 阻止它做蠢事（或恶意行为）的权限 2026年每个人都在使用的公式很简单： > ***代理 = 模型 + 框架*** 这是一个真正的转变。这意味着你不再被锁定在某一家供应商的"完整解决方案"中。你可以在保持身体的同时更换大脑。你可以在本地运行模型以保证隐私，然后切换到API以获得性能，而无需学习新工具。 ## 2、使用OpenCode进行编程的最佳LLM 本节适用于每个框架，而不仅仅是OpenCode。我在之前的文章中写过关于框架工程的内容。 如果你使用AI代理进行编程，你需要一个擅长遵循指令、调用子代理、调用工具和理解计划的AI。提示处理速度比生成速度更重要：事实上代码token很昂贵，而且数量很多。 在继续之前，这里有一组黄金法则： - 使用你将使用的同一个模型来规划代理仓库（AGENTS.md） - 如果你计划使用某个系列（Qwen、Gemma…）的开源模型，你可以在故障排除时升级到更高层级的模型 - 将整个项目规划得尽可能简单。如果有确定性操作（如PDF转markdown），请编写好的HOWTO.md并手动完成 我测试了Qwen系列（从2B到MoE Qwen3.6-35B-A3B）、Prism-ML Bonsai 8B、新的Gemma-4模型系列、Liquid AI LFM2.5-8B-A1B以及最新的JetBrains Mellum2-12B-A2.5B-Instruct。 ### 2.1 测试结果 如果看消费级硬件上的原始吞吐效率，Mellum 2远超其重量级别。 - 在纯CPU上（我的迷你PC），Mellum 2实现了舒适的**4.17 t/s**生成速度，超过了较小的Gemma-4配置。 - 一旦卸载到AMD显卡上（`-ngl 99`），它绝对飞起来了：**152.26 t/s摄入**和**15.11 t/s生成**。对于本地设置，在一个高能力模型上突破15 t/s的交互舒适底线，使其成为极其流畅的交互体验。 Qwen MoE模型在启用多token预测时可以表现出色，但内存需求对于普通消费级硬件来说太大了。 Gemma-4系列从最新的Gemma-4-12b开始才对编程生成有用。MoE很好，但你可以想象开始使用26B模型需要多少RAM——尽管只有4B活跃参数时性能并不差。 Qwen-3.5用于编程且与AI代理配合使用时，至少需要从9B模型开始才可接受。其密集架构显著降低了处理速度。Qwen3.6-35B-A3B需要过多的起始内存，即使只有3B活跃参数时处理速度不错。 Prism-ML Bonsai 8B和Liquid AI LFM2.5-8B-A1B在工具调用时会中断，在我看来不适合AI编程任务。 ## 3、本地代码之王：JetBrains Mellum2 如果你想要一个从头为软件工程设计的本地模型，**JetBrains Mellum2-12B-A2.5B-Instruct**是消费级硬件上无可争议的冠军。 ``` JetBrains Mellum2 MoE 架构 ┌────────────────────────────────────────────────────────────────────────┐ │ 总参数量：12B（舒适地适配约6GB VRAM/RAM） │ ├────────────────────────────────────────────────────────────────────────┤ │ 活跃路径：每token 2.5B参数（64个总专家 / 8个活跃专家） │ └───────────────────────────────────┬────────────────────────────────────┘ ▼ ┌─────────────────────────────────────────────────────────┐ │ 摄入：152.26 t/s ⚡ 生成：15.11 t/s (Vulkan) │ └─────────────────────────────────────────────────────────┘ ``` Mellum2采用了高度专业化的稀疏混合专家布局，拥有**64个独立专家**，每token精确激活**8个专家**。这种架构使得整个12B模型可以打包成一个轻量级的**Q3\_K\_S GGUF**，舒适地适配在6GB RAM内，为其庞大的**131,072 token上下文窗口**留下充足的余量。 由于每个执行循环只计算**2.5B活跃参数**，提示预填充和生成速度极快，即使在GPU受限的硬件上也是如此。它通过可验证奖励的强化学习（RLVR）在可执行编程、工具使用和指令遵循方面进行了专门的后训练，可以直接通信，无需显式、缓慢的外部化思维链。 在集成的AMD Radeon 780M（`-ngl 99`）上，Mellum2完全超越了其重量级别，提供无与伦比的**152.26 t/s提示摄入**，并干净地突破交互舒适底线，达到**15.11 t/s生成**。 ## 4、量化悬崖：为什么代理承受更重的Q4税 在优化本地堆栈时，标准聊天模型的普遍共识是`Q4_K_M`是最佳平衡点，在大幅削减内存占用的同时保留了约97%到99%的`FP16`困惑度。 但困惑度是一个通用指标，衡量模型预测句子中下一个词的流畅度。**AI代理不是聊天专家，而是高精度数据分析师。** 代理的核心工作是在快速扩展的上下文窗口中，一轮接一轮地发出完美结构的语法（如有效的JSON负载）并严格遵守指令。当你通过工具调用和结构化输出规范的视角来看待本地模型时，数学计算完全变了。 ### 4.1 指令遵循的崩溃 最近的按任务保留研究表明，激进的量化并不会同等程度地降低所有能力。性能下降最急剧的部分恰恰集中在编程代理最依赖的领域： - **指令遵循（IFEval）：** 低比特量化在从Q5跨越到Q4时引入了高达**20%的性能下降**。 - **数学推理与规划：** 编程准确率在Q4时下降**5%到15%**，引入了频繁的尾随逗号、未加引号的键或幻觉参数，这些会立即破坏严格的解析器。 ``` 结构化输出准确率（JSON / 工具调用） ▲ 100% | ┌─────────────── 无损区 (Q8 / FP16) | │ 80% | ┌────────┘ ◄─── Q5_K_M：代理最佳平衡点 | │ 60% | ┌─────┘ ◄─── 量化悬崖（大量IFEval下降） | │ 40% |────┘ ◄─── Q3 / Q4 标准量化（解析器频繁出错） └─────────────────────────────────────────────────────────────► 精度 ``` ## 5、消费级硬件上的最佳平衡点 这在集成的iGPU（如Radeon 780M）上运行本地工作流时，创造了一个迷人的架构张力： - **对于超轻量堆栈：** 我选择基线**Q3\_K\_S的Mellum2 Instruct**仍然是一个令人难以置信的工程奇迹。因为它从零开始就通过可验证奖励的强化学习（RLVR）在可执行代码和工具利用方面进行了训练，其原生的"填表"规范被烘焙进了权重中，超越了传统的量化惩罚。 - **对于扩展精度：** 但如果我们要扩展框架以处理复杂的嵌套工具，或者扩展到更强大的模型如**Qwen3 32B**，我们不能默认使用Q4。 > **主权代理的新黄金法则：** 不要仅仅为了将大型模型塞入RAM而将模型权重压缩到Q4。相反，查看你的服务层：使用`llama.cpp`中的`-ctk`和`-ctv`标志将KV缓存量化为`q4_0`。 我们可以节省上下文缓存上的内存而不是模型权重，这样我们就可以释放必要的VRAM余量来部署**Q5\_K\_M**或**Q6\_K**权重。那多出的10%内存支出保护了20%的指令遵循差距，确保我们的代理循环不会在第三轮因为缺少括号而窒息。 ## 6、本地部署分步指南 要将Mellum2作为编程代理框架的本地替代品，你可以使用最新的`llama.cpp`二进制文件（`llama-b9553`或更新版本，支持Vulkan）。我们将服务器端点暴露在端口`11434`上，以原生对接期望Ollama风格API钩子的代理框架。 Llama.cpp二进制文件： - [llama-b9553-bin-win-vulkan-x64.zip](https://github.com/ggml-org/llama.cpp/releases/download/b9553/llama-b9553-bin-win-vulkan-x64.zip?ref=hubwiz.com) 你可以在这里下载量化模型（我推荐Q3\_K\_S）： - [Mellum2-12B-A2.5B-Instruct.Q3\_K\_S.gguf](https://huggingface.co/mradermacher/Mellum2-12B-A2.5B-Instruct-GGUF/resolve/main/Mellum2-12B-A2.5B-Instruct.Q3%5FK%5FS.gguf?download=true&ref=hubwiz.com) 要运行模型使其被OpenCode识别，我们将伪造Ollama端点端口如下。 #### 配置A：纯CPU执行（适用于低功耗迷你PC） ``` .\llama-server.exe -m Mellum2-12B-A2.5B-Instruct.i1-Q3_K_S.gguf \ -ctk q4_0 -ctv q4_0 --jinja --mmap -ngl 0 -np 1 \ -t 4 -fa on --port 11434 -a Mellum2 \ --temp 0.6 --top-p 0.95 --top-k 20 --ctx-size 131072 ``` #### 配置B：硬件加速（完全iGPU Vulkan卸载） ``` .\llama-server.exe -m Mellum2-12B-A2.5B-Instruct.i1-Q3_K_S.gguf \ -ctk q4_0 -ctv q4_0 --jinja --mmap -ngl 99 -np 1 \ -t 4 -fa on --port 11434 -a Mellum2 \ --temp 0.6 --top-p 0.95 --top-k 20 --ctx-size 131072 ``` 如果你想尝试Q5\_K\_M并验证工具调用精度的提升： - 下载模型GGUF文件 [Mellum2-12B-A2.5B-Instruct.Q5\_K\_M.gguf](https://huggingface.co/mradermacher/Mellum2-12B-A2.5B-Instruct-GGUF/resolve/main/Mellum2-12B-A2.5B-Instruct.Q5%5FK%5FM.gguf?download=true&ref=hubwiz.com) 在终端中尝试： ``` .\llama-server.exe -m Mellum2-12B-A2.5B-Instruct.Q5_K_M.gguf \ -ctk q4_0 -ctv q4_0 --jinja --mmap -ngl 99 -np 1 \ -t 4 -fa on --port 11434 -a Mellum2 \ --temp 0.6 --top-p 0.95 --top-k 20 --ctx-size 131072 ``` ## 7、用于非编程任务的LLM代理 对于LLM维基风格的项目，4B模型就很好用了。 王者是gemma-4-E4B-it-qat，一个总参数量8B但推理时有效参数为4B的模型。该模型善于理解指令和处理文本。适合生成知识图谱。 在同一范围内，Qwen3.5-4B也是一个不错的模型，其内存占用比Google模型更小。 ### 7.1 用于聊天的LLM 如果你不受代理和工具的约束，上述许多模型都是不错的选择。我通常运行llama.cpp服务器并直接与之聊天，结果准确。这也适用于： - Prism-ML Bonsai 8B - Liquid AI LFM2.5-8B-A1B - IBM granite-4.1-3b - Huihui-MoE-5B-A1.7B 你可以使用如下命令运行： ``` .\llama-server.exe -m .\Bonsai-8B-Q1_0.gguf --mmap -ngl 0 \ -t 4 -c 32000 --port 11434 -fa on \ -ctk q4_0 -ctv q4_0 -a Bonsai8b --reasoning on --jinja \ --temperature 0.5 --top-p 0.9 --top-k 20 --repeat-penalty 1.0 ``` ## 8、最终蓝图：选择合适的工具 在管理你的主权本地硬件堆栈时，将底层模型架构直接匹配到项目的操作概况： - **对于编程代理和工具集成：** 运行**JetBrains Mellum2 Instruct (Q3\_K\_S)**。它在闪电般快速的token预填充速度和坚如磐石的工具调用精度之间提供了绝对最佳的平衡，适合本地消费级设置。 - **对于本地知识库（LLM维基/图谱）：** 依靠**Gemma-4 E4B IT QAT**或**Qwen3.5-4B**模型。这些4B有效参数系统需要极低的内存占用，同时为非结构化文本文档提供卓越的语义解析能力。 - **对于直接交互式聊天：** 如果你不需要复杂的代理工具调用框架，可以寻找稀疏替代品如**LFM2.5-8B**（以轻松的**24.7 t/s生成**速度运行），或使用带有`--reasoning on`的密集选项如**Bonsai-8B**以最大化直接对话智能。 ## 9、结束语 我们在2026年见证的范式转变既涉及模型变得更大，也涉及架构变得更智能。长久以来，运行本地AI编程代理感觉像是一种妥协：在自己硬件的铁定隐私与云端API的流畅快速执行之间的权衡。 如果我们使用OpenCode等模块化框架将大脑与身体分离，我们就可以自由地为不同任务选择专门的引擎。数据让选择变得清晰：对于日常知识映射和文档解析，轻量级4B有效参数系统如Gemma-4 E4B QAT提供了令人难以置信的效率。但当涉及主动软件工程的重活（工具调用精度、大规模上下文处理和即时提示预填充速度决定成败）时，**JetBrains Mellum2 Instruct**改变了游戏规则。 其独特的64专家稀疏布局证明，本地消费级硬件——如标准AMD或迷你PC——可以提供优质、近乎即时的开发体验，而无需耗尽资金或泄露专有代码。"GPU贫乏"开发者在本地构建上停滞的时代正式结束了。 在优化你的工作空间时，我们不再追逐最高的总参数数量：我们希望将正确的活跃计算足迹匹配到我们的特定任务。部署Mellum2，将其挂接到你的代理框架，并完全掌控你的数字环境。 --- 原文链接：[Jetbrains' Mellum2 is the best low resources local coding agent LLM](https://freedium-mirror.cfd/https://medium.com/artificial-intel-ligence-playground/jetbrains-mellum2-is-the-best-low-resources-local-coding-agent-llm-e7ead8d02b4e?ref=hubwiz.com) 汇智网翻译整理，转载请标明出处