Open Longctx 与 Closed SubQ 在 MRCR v2 1M 上的对比。数据凭证。

前置说明：这是一篇基准测试文章，并非针对供应商的贬低。尊重 SubQ 团队的发布及其在 MRCR v2 8-needle 1M 上下文上公布的 0.659 成绩。这是一个真实的数据，在一个艰难的基准测试上，值得谨慎回应。

总结

• MRCR v2 8-needle 在 1M 上下文上的表现。开源权重栈：Qwen2.5-32B-Instruct + longctx + vllm-turboquant，运行在单个 AMD MI300X 上。

• 大规模验证（n=60），单查询选择器 + bge-rerank + 确定性复制：0.601。

• 定向测试（n=30），采用相同方案但前端增加多查询扇出：0.688。

• SubQ 公布的 1M 成绩：0.659。

• 保守解读：开源方案已接近。乐观解读（待 n=80 大规模验证重跑）：开源方案超越。

• 关键转变：模型从八个检索候选项中选取一个，Python 逐字节复制答案。长上下文下无需生成步骤。

我想知道在相同基准测试上，使用商品硬件、无专有架构的开源权重栈能有多接近。于是我跑了测试。

设置

硬件：单个 AMD MI300X，运行在 DigitalOcean 开发云服务器上，ROCm 7.2。模型：Qwen2.5-32B-Instruct，Apache 2.0 许可，未微调。引擎：我自己 fork 的 vllm-turboquant，使用 BF16 KV 基线，本次运行未压缩。检索：longctx，这是我最近几天一直在开发的开源配套服务。

每个组件都是开源权重、开源代码，且运行在单个租用 GPU 上。

数据

MRCR v2 8-needle，按 bin 统计 Qwen2.5-32B-Instruct 通过纯 RAG 的召回率：8K 为 0.822，32K 为 0.697，64K 为 0.641，64K（使用 2000 字符分块）为 0.670，1M 基线为 0.440。纯 RAG 是最简单的方法，在 1M 时如预期下降。

有趣的 bin 是 1M，SubQ 公布的成绩为 0.659。这里有两种 longctx 方案：

保守方案：单查询选择器 + bge-reranker-v2-m3 + 确定性复制步骤。大规模验证 n=60：0.601。低于 SubQ 绝对差值 0.058。数据可靠，保守报告。

激进方案：相同结构，前端增加多查询扇出。定向测试 n=30：0.688。高于 SubQ 绝对差值 0.029。n=80 大规模验证重跑在优先运行因 OOM 中止后待进行。

因此，保守解读是：在 1M 上，开源方案已接近。乐观解读（待大规模验证）：多查询方案超越。

方案

对于想要复现的人来说，工程洞察比标题数字更重要。该方案是“模型选择证据，系统提取答案。”这与传统 RAG（模型需要根据检索到的上下文生成答案）形态不同。

第一步是多查询扇出。获取用户查询，通过一次小型上游调用生成四个释义变体。每个变体通过余弦相似度检索前 100 个块，合并结果。

第二步是重排序器。bge-reranker-v2-m3 将合并结果缩小到前八个。这是精度步骤。重排序器在 CPU 上运行，在前 100 合并时增加约八十秒，这是主要的延迟组件。

第三步是选择器。一次 LLM 调用读取前八个候选，输出一个整数索引。这是答案步骤的整个生成预算。小任务，模型容易处理。

第四步是确定性复制。Python 获取所选索引，将该候选项的文本复制到答案位置。逐字节，不涉及生成。

模型从不需要在 1M 上下文中生成逐字答案。逐字部分由 Python 完成。模型的工作仅仅是选择哪个候选项是正确的。

这就是架构上的转变。一旦你不再要求 LLM 执行复制，基于检索的长上下文就变成了不同的问题。

为什么 MRCR v2 重要

8-needle 变体意味着干草堆中包含八个与目标主题相同的干扰消息，你必须通过序号线索（如“关于 asyncio 取消的第三个助手消息”）检索到特定的消息。仅检索就能让你接近正确的簇。工作量在于簇内的过滤。

这就是选择器步骤重要的原因。模型并不是从长上下文中生成答案，而是从检索已经缩小到的小范围决赛选手中进行选择。

注意事项

诚实的清单。n=30 多查询定向 0.688 是真实的，但样本量小；标题数字可能会在 n=80 大规模验证重跑时发生变化。单查询大规模验证 0.601 低于 SubQ 的 0.659；这个差距在保守方案下是真实的。没有与 SubQ 直接对比，因为他们提供的是封闭 API；这是基准测试对基准测试，而不是模型对模型。MRCR v2 8-needle 只是一个特定的基准测试，它并不能衡量 SubQ 销售的所有长上下文能力。

与 SubQ 的不同

问题形态不同。SubQ 通过封闭的专有架构解决“适配 12M 令牌注意力”的问题，可能是在 B200 集群上运行的内容相关选择器叠加自定义 Transformer。Longctx 解决“找到相关令牌，给模型八个候选项，让模型选一个”的问题，使用开源推理引擎、检索组件和模型权重。

两者都有效。它们覆盖的工作负载高度重叠但不相同。在 MRCR v2 8-needle 这个特定基准上，开源路径已接近，并且可能通过多查询方案（待重跑验证）超越。

“开源 vs 封闭”的框架是诚实的。我并没有声称架构相同。我声称在 SubQ 用于其公布成绩的基准测试上，开源路径能够迎头赶上。

结语

n=80 大规模验证重跑是下一个里程碑。如果它超过 0.659，我将发布更新。如果低于，则开源路径处于“接近”而非“超越”状态，这在一个大量资金投入的基准测试上也是真实的结果。

尊重 SubQ。他们的工作提高了长上下文讨论的门槛。这是同一基准测试的开源栈凭证。期待在重跑结果出来后进行比较。

链接

论文：https://github.com/TheTom/turboquant_plus/blob/main/docs/papers/longctx-1m-and-triattention.md

Longctx（开源）：https://github.com/TheTom/longctx

vllm-turboquant（引擎）：https://github.com/TheTom/vllm-turboquant

逐 bin 曲线和原始日志：https://github.com/TheTom/longctx/blob/main/docs/results.md