Fern 0.1 支持千万上下文，编码能力仍有差距

把整个仓库一次塞给模型，能不能让 AI 更懂项目？Mirendil 发布的首个模型 Fern 0.1，把上下文窗口推到了 10M tokens，按其估算约能容纳 23 MB 代码、约 50 万行，规模接近 Megatron-LM 代码库。

但这篇报道最有价值的结论，并不是窗口有多大，而是两种能力的分离：Fern 很擅长从超长输入里找信息，执行编程任务却明显落后于领先模型。对程序员来说，判断它有没有用，要分清「装得下」「找得到」和「做得对」。

10M tokens，瞄准的是哪些工作？

Fern 面向 AI 研发，输入支持文本和代码。作者列出的用途包括跨大型代码库工作、运行命令直到测试通过、编写训练循环和数据管道、从长日志与堆栈中排错、通读完整 agent 轨迹，以及检查预训练数据中的重复、污染和垃圾内容。

这些场景的共同点，是相关信息可能散落在很远的位置。大窗口给出了一条直接路径：少做切分，一次读入更多材料。

Fern 0.1 基于 Mirendil-Base，经过一轮较短的后训练得到。参数规模只公布了 0.1 到 0.5T，准确总量和激活参数量未披露。目前只有托管早期访问，未发布权重或量化版本，许可证也没说清。

Mirendil 还称，一名研究员用 3.5 个月完成了基座预训练，总计算成本低于 $10M，包含实验、agent token 消耗和数据处理；AI agents 编写了超过 99% 的代码，研究员负责选择实验和决定何时干预。训练代码基于 PyTorch 和 JAX 从零编写，数据仅来自 GitHub、公开代码、网页和公开数据集，没有使用蒸馏、合成数据或授权数据。

这些都是团队披露的信息，不能据此推导普通团队也能复制同样的效率。

更长的上下文确实有帮助，但不是同长度下最强

Mirendil 把自有仓库拼成了一个 42.9 MB 的数据流，测试模型预测下一个 token 的能力。指标是每字节比特数（bits per byte），越低越好。

这里最容易看错的是单位：这组实验的窗口按 bytes 计量，不是 tokens。

Fern 的结果从 32K-byte 窗口下的 0.246，降到 16M 和 23M bytes 下的 0.155。这说明在这批仓库上，增加可见内容确实帮助了预测，并非只是扩大一个参数上限。

但在同样的 1M-byte 窗口下，Kimi-K3 是 0.140，Fern 是 0.165，GLM-5.3 是 0.170。Fern 没有赢过 Kimi-K3。它的优势在于还能继续扩大窗口，而其他模型在实验中最多测到各自宣称的约 1M tokens 上限。

这组结果支持「更长输入对 Fern 有用」，还不足以证明「整仓输入一定优于检索相关文件」。原文没有给出这样的对照。

找到信息和完成编程，是两张成绩单

RULER 测试使用的是后训练之前的 Mirendil-Base，采用贪心解码、关闭思考，并按字符串精确匹配评分。

RULER 任务	32K	1M	4M	10M
单针检索	100	100	100	100
多键检索	100	98	98	90
多键全部目标检索	100	100	100	100
变量追踪	100	95	75	100
多跳问答 HotpotQA	65	65	60	45

以上长度单位为 tokens，成绩为百分比。单针检索可以理解为：在大量内容中藏一条目标信息，看模型能否找出来。多跳问答则需要连接多处证据，难度不同。

Fern 在 10M tokens 下仍能保持单针检索 100%，但多跳问答降到 45%。而且，每个 10M 单元格只有 20 个样本，其余长度为 100 个。变量追踪从 4M 的 75% 回升到 10M 的 100%，也不宜脱离样本量解读。

真正执行编程任务时，Fern 0.1 的成绩如下：

基准，通过率 %	Fern 0.1	Kimi-K3	GLM-5.3	Claude Opus 5.5
DeepSWE v1.1	44.2	67.3	66.9	74.2
Terminal Bench 4.0	6.1	12.6	41.9	66.4
SWE Atlas QnA	53.2	66.1	59.4	66.4
SWE-Pro v2 Hard	76.5	88.2	84.3	100.0
SWE-Bench Verified	73.4	93.4	95.4	98.2

Fern 在五项中的四项超过 Inkling 和 Nemotron 3 Ultra；SWE-Pro v2 Hard 与 Beam 同为 76.5%，但 SWE-Bench Verified 落后于 Beam 的 81.6%。表中的前沿模型和大型开放权重模型都领先于它。

长上下文检索成绩，不能替代 agent 编程成绩。

对照分数来自模型卡、榜单或 Mirendil 自测，原文没有完整交代各项执行环境。因此可以看出差距，却不宜把每个分差都归因于模型本身。

我的判断

Fern 值得关注的地方，是它展示了超长代码输入仍能带来预测收益，也保留了较强的检索能力。对长训练日志、完整执行轨迹这类材料，这个方向有实际意义。

但「一次装下整个仓库」还不是开发体验的完整答案。读入后能否理解依赖、定位问题、正确修改并验证，仍要单独测。Terminal Bench 4.0 的 6.1%，就是目前不能忽略的短板。

常见替代做法是代码搜索、检索增强，再按任务选择文件。它们需要维护检索流程，但 Fern 的公告没有给出与这些方案在成本、延迟、准确率上的对照，也没有说明满窗口调用的价格和耗时。现在把它看成值得试验的研发模型更合适，尚不足以背书为日常主力。

能拿来做什么

• 评估 AI 编程工具时，把长输入检索和实际修复任务分开测试。例如先检查它能否找出仓库中的配置关联，再检查它能否修改代码并通过测试。
• 如果工作涉及训练日志或 agent 轨迹，可以用同一份材料比较全文输入与分段检索，记录定位准确率、耗时和调用成本。
• 为前端或 Node 项目选择工具时，保留代码搜索、类型检查和测试流程。模型读过完整仓库，仍需要执行结果证明修改有效。