够快、够省，也足够忠于上下文

转载说明：本文经作者授权转载自 abn.is 上的原文，原文发表于 2026 年 8 月 3 日。文中的测量结果、硬件和结论均来自作者本人；Nowledge Labs 未运行其中任何基准测试。原文中的提示框在这里以引用块呈现，流程图则根据作者自己的 Mermaid 源码渲染。

个人记忆系统有两种截然不同的需求。大多数时候，它都在读取那些持续从后台进入系统的笔记、摘录和文字记录。这些内容需要先经过分类和筛选，再被纳入索引，而这时还没有人向它提出任何问题。偶尔，它也需要回答问题：从迄今为止保存的所有内容中找回正确的段落，并基于这些内容给出真实的回答。这个回答必须忠于实际检索到的内容，而不是只求听起来合理。这是两类不同的工作，也有着不同的瓶颈。本文讨论的，就是如何为其中负责回答问题的一侧选择一个模型。

这里讨论的系统是 Nowledge Mem：一个持续接收内容，并基于这些内容回答问题的个人知识与记忆服务。这条流程中的检索部分，也就是将笔记和查询转换为向量的 Embedding 模型，已经在之前的文章 Too Long, Didn’t Embed 中介绍过。本文关注的是另一半：当检索返回正确的段落后，需要有一个模型读懂这些内容并生成答案，同时不能偏离实际检索到的信息。

JetBrains 的第二代模型家族 Mellum-2，主要面向 Agentic 软件开发工作流打造。最初的评估也从这一场景开始，包括编程基准、工具使用和 Agentic 门控决策。但在早期评估中，Mellum-2 展现出的 prefill 吞吐量，让我们开始考虑把它用作 Nowledge Mem 的答案生成模型。

虽然交互式问答才是最终目标，但任务分类和 Agentic 门控可以作为具有较强区分度的质量代理指标：它们能够检验模型是否严格遵循检索到的上下文，既不虚构标签，也不做缺乏依据的推断。

模型评估卡

如果你只想看数据，可以直接在这里查看。

Mellum-2 并没有直接拿下主力答案生成模型的位置。但从下面的数据来看，它确实非常适合承担一个更聚焦的角色。

为什么 Granite-4.0-H-Small 仍然担任生成模型

Granite-4.0-H-Small 采用混合架构：大部分层是 Mamba-2 状态空间层，只混入了少量标准注意力层。这个差异看似不大，实际上却很关键，因为它会直接影响文字记录不断变长时的内存占用。在普通 Transformer 中，每个注意力层的 KV cache 都会随序列长度增长：上下文增加一倍，cache 也增加一倍。而在 Granite-4.0-H-Small 中，只有注意力层的 cache 会随之增长。Mamba-2 层保存的是固定大小的循环状态，而不是不断累积的 cache，因此无论输入有多长，模型每个 token 的大部分计算成本都基本保持不变。对于一个需要处理大量冗长、杂乱真实内容的记忆系统来说，这样的成本结构可以说是理想：真正会随输入长度增长的部分，只占整个模型的一小部分。

Granite 能担任生成模型，靠的不只是成本优势，也包括质量，不过在两个真正检验忠于上下文生成能力的工作负载中，它只在其中一个上胜出。在两款模型均采用 4-bit 量化、temperature 设为 0 并使用贪心解码的正面对比中，Granite 在笔记分类任务上确实领先：0.767，对比 Mellum-2 的 0.700。这个任务考察模型能否正确判断新进入内容的类型，共包含 60 个不同任务、180 次观测，也是两组测试中样本量更大的一组。在第二个具有区分度的工作负载，也就是 Agent 工作流中的决策判断，共有 30 个任务、90 次观测，两款模型在单张 32 GB 显卡上都得到 0.667，完全打平。

随着输入的变长，这套架构的优势还会进一步显现：由于只有少数几层的 cache 会持续增长，长输入对 Granite 来说依然成本很低，不像普通 Transformer 那样迅速变得昂贵。因此，内存通常不会成为限制其上下文长度的瓶颈。

不过，这些优势并不意味着 Granite 是更便宜的选择。在这个工作负载下，它大约占用 25.5 GB VRAM，prefill 吞吐量也相对有限。由于两个模型的测试都采用了 Q4_K_M 量化，因此 25.5 GB 与约 11 GB 的 VRAM 差距，反映的是纯粹的架构差异，而不是量化等级不同。Granite 用更高的 VRAM 占用，换来了在基于检索上下文进行分类时持续稳定的优势；在单卡环境下，这项能力的价值并不小。单凭自身表现，Granite 依然是一个扎实且经得起推敲的选择。

Granite 4.1 模型家族

本文提到并用于比较的 Granite 模型是 Granite 4.0。此后，IBM 发布了采用更灵活 Dense 架构的 Granite 4.1 模型家族。虽然其中没有可以直接替代 Granite-4.0-H-Small 的模型，但 Granite-4.1-8B 是我们之后准备重点评估的对象。

Mellum-2 不是 Mellum-1

JetBrains 以 Apache-2.0 许可证发布 Mellum 家族。这个家族分为两代，而它们承担的工作内容并不一样。Mellum-1 是一个 4B 稠密模型，采用类 Llama 架构，上下文长度为 8,192 token。它确实名副其实：这是一个为 IDE 行内建议打造、采用 fill-in-the-middle 方式的代码补全模型。本文并没有在显卡上对 Mellum-1 进行评估；之所以在这里提到它，只是为了与它的后继模型划清界线，因为这两代模型很容易被混为一谈，而这种混淆会影响判断。

Mellum-2 则完全不同。它是一个混合专家模型，总参数量为 12.15B，每个 token 约激活 2.4B 参数；共有 64 个专家，每个 token 会激活其中 8 个，原生上下文窗口为 131,072 token。它提供 Instruct/Chat 和推理（“Thinking”）两种变体。它并不是 fill-in-the-middle 模型。它的 tokenizer 中确实仍然保留着用于 FIM 的特殊 token，这是从原有词表中继承下来的，但本文既没有测试，也没有声称它具备代码补全能力。如果期待 Mellum-2 承担 Mellum-1 的工作，那就是选错了模型代际。

Mellum-2 架构中最值得重点关注的是它的注意力布局，因为下面表现最好和最弱的那些数据，都直接源于这一设计。在它的 28 层中，21 层采用固定 1,024 token 窗口的滑动窗口注意力（SWA），只有 7 层会对整个序列执行完整、不受限制的注意力。上下文扩展，也就是 16 倍 YaRN 缩放，只应用于这 7 个完整注意力层；无论整体上下文长度扩展到多少，滑动窗口层始终保持原生的缩放方式。

设计原理

为什么这种布局一方面带来了极高的 prefill 吞吐量，另一方面也让检索能力更早衰减

无论序列有多长，滑动窗口注意力的计算成本都是固定的：输入长度无论是 4K 还是 128K token，一个 1,024-token 窗口的成本都不会变化。28 层中有 21 层采用这种方式，因此面对长输入时，prefill 的大部分计算成本都只会随输入长度线性增长，只有少数几层的计算量会按平方增长。这也正是 Mellum-2 能达到如此高 prefill 吞吐量的原因。

同样的布局，也解释了为什么它的多事实检索能力在实际使用中，会比规格参数给人的预期更早开始下降：只有 7 层能够关联输入中相距较远的两个事实，也只有这 7 层应用了上下文扩展。

测量结果

除特别说明外，以下所有结果均在单张 32 GB 显卡、ROCm 后端和 llama.cpp（build b10143）上测得。Granite 的对照测试还使用同一 build，在 Strix Halo APU 上重复进行了一次。

Granite 对比中的质量、速度和资源占用数据，都是在完全相同的设置下，对两个模型进行同场测试后得到的，并不是分别引用不同时间运行的历史结果。两个模型均采用 Q4_K_M 量化，各使用单张显卡，设置一个并发请求槽位，启用 flash attention 和 continuous batching，使用相同的语料库，每个工作负载重复三次，并在 temperature 设为 0 的情况下进行贪心解码。

除特别说明外，所有检索和编程测试数据均来自 Mellum-2 的 Instruct 版本。

质量、速度与资源占用

第三个工作负载的持平并没有太大参考价值：在这套语料中，它的 prompt 平均只有约 130 token，因此根本没有覆盖到原本想测试的长文本场景。第二个工作负载的持平则是实打实的：在完全相同的解码设置下，两款模型取得了完全相同的决策准确率。因此，第一行可以看作两款模型在独立显卡环境下真正存在质量差距的一项测试，而第二行则基本不分高下。

在速度和资源占用方面，每一项指标都明显偏向 Mellum-2：面对完全相同的 prompt，它的 prefill 吞吐量达到 Granite 的 2.7 倍；分类任务的延迟中位数约降低一半，决策任务则降低了四倍以上；VRAM 占用也不到 Granite 的一半。

把两张表结合起来看，这里的取舍其实比乍看之下更明确：在所有运行指标上，Mellum-2 都更快、资源成本也更低，而它付出的质量代价，只出现在两个真正检验忠于上下文生成能力的工作负载中的一个。

相同模型，换到 Strix Halo APU

随后，我们把同样的两个模型、同样的语料库，使用同一个 llama.cpp build，在 Strix Halo APU 上重新跑了一遍；两者依然都在 temperature 0 下采用贪心解码。Strix Halo 是一款采用统一内存、没有独立 VRAM 池的芯片，其内存子系统与前面的 32 GB 独立显卡有很大不同。

不同硬件下，质量分数会有一些变化：

Granite 在两个平台上的类型分类分数完全相同，都是 0.767，而且两次都采用贪心、确定性解码。Mellum-2 在 Strix 上则略有下降，从 0.700 降到 0.678，因此笔记分类准确率的差距也会随硬件不同，从 0.067 扩大到 0.089。

Granite 的 Agent 工作流决策分数出现了一个意外变化：在独立显卡上是 0.667，到了 APU 上降至 0.589，而这个工作负载在两个平台上都使用 temperature 0。Mellum-2 则朝相反方向变化，从 0.667 上升到 0.711。无论 Granite 出现这种波动的具体原因是什么，它都更像是由硬件差异造成的，而不是采样带来的偏差，因为两个模型在两个平台上采用的都是贪心解码。

从部署角度来看，这意味着在 APU 上进行 Agent 工作流决策时，Mellum-2 领先 0.122，也因此完全改变了在独立显卡上得出的结论。

更明显、也更直观的差异出现在速度上：

从独立显卡换到 APU 后，Granite 的 prefill 性能下降了 3.9 倍，从 1,505 tok/s 降到 387 tok/s；Mellum-2 则只下降了 2.9 倍，从 4,096 tok/s 降到 1,414 tok/s。两款模型之间的 prefill 性能差距也从 2.7 倍扩大到了 3.7 倍。

这与通常的直觉恰好相反：拿掉高性能独立显卡之后，大模型原本的优势似乎应该缩小，但这里的差距反而进一步扩大。原因在于架构。无论序列有多长，固定的 1,024-token 滑动窗口都只需要访问 KV cache 中固定大小的一部分。在以计算能力为瓶颈的独立显卡上，这能减少计算量；而在以带宽为瓶颈的统一内存架构上，则能减少内存访问。

Granite 面临的是另一种成本：它的 Mamba-2 层只需维持固定大小的循环状态，但其中少数注意力层仍然会不断累积 cache，而性能较弱的内存子系统对这一部分的影响最为明显。硬件越受限，Mellum-2 在这一架构维度上的优势反而越容易显现出来。

测量条件

在这块芯片上，llama.cpp 的 build 版本带来的影响甚至比硬件本身还大。 在同一块 Strix Halo APU 上，使用相同的模型、prompt 和上下文，一版 llama.cpp 的 prefill 速度为 316 tok/s，另一版则达到 1,414 tok/s，仅仅更换 build 就带来了 4.5 倍的差距。

在速度更快的 build 上，这块 APU 使用 ROCm 时的性能也优于 Vulkan（1,414 tok/s 对 1,187 tok/s）。本节所有 Strix 数据都来自速度更快的 build（b10143）；因此，跨 build 比较实际上是在比较两种不同的运行环境。

编程能力与量化选择

由于 Mellum-2 本身就是为 Agentic 开发而设计的，因此我们也更仔细地考察了它的编程能力。Mellum-2 Instruct Q4_K_M 在 HumanEval+ 上取得了 0.884 的 pass@1（EvalPlus，n=164，贪心解码，并通过实际执行验证）。对于一个每个 token 约激活 2.4B 参数的模型来说，这样的编程表现相当有竞争力。在测试的两个量化等级下，它也都顺利通过了函数调用和结构化输出检查。

量化版本的选择很明确：Q8_0 在同一编程基准上的得分为 0.872，而 Q4_K_M 为 0.884。这个差异更可能来自测试噪声，并不意味着更小的量化版本质量更高，但至少说明，没有测试结果表明有必要为了质量使用更大的版本。Q4_K_M 在资源占用上则有明显优势：32K 上下文下，常驻占用约为 9.0 GB，而 Q8_0 约为 13.75 GB。既然质量基本没有差别，而 VRAM 占用差距明显，4-bit 版本自然更适合作为默认选择。

能耗

在持续解码负载下，Mellum-2 Instruct Q4_K_M 测得的能效约为每瓦 0.58 token。测试过程中，功耗和结温也在每张显卡上同步采样。再加上它在 64K 上下文下约 11 GB 的 VRAM 占用，使它能够以较低成本持续运行在后台内容接收流程中。

长上下文：实际能力逐渐触顶，而不是规格表上的数字

Mellum-2 标称的上下文长度为 131,072 token。实际采用类似 RULER 的“大海捞针”测试，并分别在 4K、32K 和 128K 上下文长度下运行，结果如下：

随着上下文变长，检索质量会逐渐下降。单一事实检索一直到 128K 都几乎保持完美，而需要组合、交叉关联多个事实时，可靠率则从 32K 时的 90% 降到 128K 时的 50%，已经接近随机猜测。

因此，对于多事实检索任务来说，这个模型实际可靠的上下文上限大约是 32K，而不是规格表标称的 131K。

同一轮测试中还有一项多步变量跟踪任务（variable_track）：在 4K 对照长度下得分为 0.225，32K 时为 0.175，128K 时为 0.25。输入长度扩大了 32 倍，分数却始终处于较低水平，几乎没有变化。这说明问题并不在上下文长度。如果一个任务无论输入长短都会以同样的方式失败，那么它反映的是模型本身的推理能力下限，而不是随着上下文变长而出现的性能衰减。

Mellum-2 最终适合什么位置

Mellum-2 主要面向 Agentic 软件开发工作流训练。以每个 token 约 2.4B 的激活参数量来看，它经过执行验证的编程能力和工具使用能力都相当扎实。但它采用的滑动窗口注意力布局，也让它意外成为 RAG 流水线中的有力候选，尤其适合那些主要受 prefill 吞吐量和内存占用限制的场景。

它并没有直接取代 Granite-4.0-H-Small Q4_K_M，成为默认生成模型。根据硬件不同，Mellum-2 在笔记分类上的准确率要低 0.067 到 0.089。这是真实存在的质量代价，无论在独立显卡还是 APU 上，这一项都更有利于 Granite。但在 Agent 工作流决策上，Mellum-2 并没有付出这样的代价：两者在独立显卡上完全打平，而在 APU 上，Mellum-2 反而领先 0.122。

而这项取舍换来的，是大约 14.5 GB 更低的 VRAM 占用，从 25.5 GB 降到约 11 GB；prefill 吞吐量在独立显卡上达到 2.7 倍，在 APU 上进一步扩大到 3.7 倍；单次请求延迟也降低了约 2 倍到 4 倍以上。更重要的是，这种运行优势并不会在硬件受限时缩小，反而会进一步放大。

如果首要目标是尽可能高的分类质量，而且 VRAM 充足，Granite-4.0-H-Small Q4_K_M 仍然是更稳妥的默认生成模型。而在内存空间紧张、prefill 延迟是主要瓶颈，或者硬件资源本身比较受限的情况下，Mellum-2 Q4_K_M 会是更合适的选择。

如果你对这篇文章有任何问题或评论，欢迎联系作者。如果你希望更深入地了解 Nowledge Mem 是如何工作的，可以阅读 Nowledge Mem 的相关文章。