先看证据
长上下文成为能力主张，也成为评测考题
Mirendil是一家AI研发实验室，它发布了首个模型Fern 0.1：一款从头预训练、面向编码和AI研发工作的模型，支持最长1000万token的上下文。Mirendil把这一容量换算成约2300万字节代码，或约50万行代码，并以Megatron-LM规模的代码库作为直观参照。模型目前只提供托管式早期访问，尚未公布开放权重或量化版本。
这条发布信息真正提出的问题，不只是“能塞进多少文本”，而是更大的工作材料能否改变模型完成任务的方式。代码仓库、训练日志和多日的智能体轨迹如果能一次进入上下文，开发者或许可以减少切分与摘要的中间步骤。但容量是输入条件，不是任务能力的同义词，Fern公布的结果恰好展示了两者之间的落差。
长窗口确实延伸了，等长比较却不占优
Mirendil用自己的代码仓库检验窗口变长是否有用：它把多个仓库拼成42.9MB的数据流，比较不同上下文长度下的下一token预测损失，指标是bits per byte，数值越低越好。Fern的损失从32KB窗口下的0.246，下降到16MB和23MB窗口下的0.155。这个结果说明，给Fern更多上下文时，它在这项特定预测任务上的表现继续改善。
但同一实验也限制了“Fern预测得更好”的说法。在1MB窗口下，Kimi-K3的损失是0.140，Fern是0.165，前者更低。其他模型只测到约100万token，也就是它们公布的上下文上限附近，因此Fern的突出之处是曲线能延伸到更大的窗口，而不是在相同窗口下胜出。还要注意，这组窗口以字节计，不能把16MB或23MB直接当成16M或23M token。
检索能撑住，跨材料推理仍会掉分
Mirendil还用基础模型Mirendil-Base跑了RULER长上下文基准，模型当时尚未经过Fern 0.1的后训练。测试使用贪心解码、关闭思考模式并要求精确匹配，覆盖单线索检索、多线索检索、变量追踪和多跳问答等任务。单线索检索从32K到10M token都达到100%，说明模型在基准设定下可以从很长的输入中找回指定信息。
结果并非所有任务都同样稳定。多跳问答HotpotQA在10M token时降到45%，变量追踪在不同长度上的分数也有起伏。更重要的是，10M token这一列每个任务只有20个样本，其他长度通常有100个，因此极长上下文处的分数不宜被读成精确、稳定的能力刻画。检索到一条事实和把多条材料连成可靠结论，是两种不同的工作。
编码基准把容量与可交付性分开
Fern面向的不只是阅读仓库，也包括让智能体反复运行命令、直到测试通过的编码工作。现有材料对这类能力给出的信号弱得多：Mirendil自己的比较表中，Fern 0.1在Terminal Bench 4.0上的得分为6.1%，Claude Opus 5.5为66.4%。材料将Fern描述为相较开放权重模型处于中游、明显落后于前沿模型，但没有给出足以逐项复核的完整分数表。
这组反差提醒技术负责人不要把“模型看到整个仓库”直接等同于“智能体更可能交付可运行改动”。长日志和代码可以减少因上下文截断造成的信息损失，却不会自动解决命令选择、错误诊断、计划修正或工具调用等问题。尤其在任务要求持续操作直到测试通过时，最终成功率比单次检索是否准确更接近实际交付指标。现有材料证明了Fern的长上下文主张，却没有证明它已把这项优势转化为更强的端到端编码能力。
训练方式提供线索，部署条件仍限制判断
Fern建立在Mirendil-Base之上，后者据称由一名研究人员用3.5个月完成预训练，相关总计算支出低于1000万美元，包含实验、智能体token消耗和数据处理。Mirendil称超过99%的代码由AI智能体编写，研究人员负责决定尝试什么以及何时介入。训练数据来自GitHub、公开代码、网页和公开数据集，公司表示没有使用蒸馏、合成数据或授权数据，代码则从头以PyTorch和JAX编写。
这些信息说明了团队选择公开披露的训练路径，但不能单独证明模型质量、数据覆盖或成本优势可以被外部复现。Fern 0.1是三个计划模型中最小的一款，参数规模仅披露为0.1万亿到0.5万亿，精确参数量和激活参数量都未公布。更大的Base-Large和Base-XL仍在预训练中，材料称前者完成度超过80%，后者超过20%。
对工程团队来说，当前最实际的判断应当把Fern当作一个需要按任务分层评估的长上下文候选，而不是默认替换现有编码模型。若工作主要是检索大型代码库、查看训练日志或审阅长轨迹，可以关注它是否减少切片、摘要和人工拼接的成本。若目标是自主修改代码并通过测试，则应单独核验端到端成功率、失败模式、访问成本和数据处理边界；而在只有托管早期访问、没有开放权重的情况下，部署控制与可复现性仍是明确限制。