把整个 23MB 的代码库一次性塞进大模型对话框，听起来像是每个研发团队的终极梦想。太平洋时间 2026 年 10 月 26 日上午 8 点，初创公司 Mirendil 正式宣布推出首款大模型 Fern 0.1，主打 1000万token（10M）超长上下文窗口。不少技术媒体的标题直接将其称为正式上线，但截至 10 月 27 日，这款模型仍挂着即将推出的标签，仅开放早期访问申请，没有公开 API 端点、没有技术文档，甚至连最基础的定价和首字延迟数据都未公布。
这不仅是一次典型的期货式官宣，更是一份经不起细拆的成绩单。翻开 Mirendil 披露的评测细节就会发现，撑起千万级上下文门面的跑分其实是拿未经过后训练的基座模型代考出来的，且样本量极小；而在真正考验复杂逻辑的多跳推理和终端操作上，模型表现出了严重的偏科。
静态修补高分与动态终端溃败：Fern 0.1 的真实底色
从模型架构来看，Fern 0.1 建立在从头预训练的 Mirendil-Base 基座之上，仅经过了简短的后训练。官方将参数规模模糊地划定在 0.1T 至 0.5T（即 1000亿至5000亿 参数）之间，未透露确切数字，主要面向文本与代码输入场景。
在官方主打的代码能力上，Fern 0.1 确实交出了几项亮眼的静态测试成绩。它在 SWE-Bench Verified 上拿到 73.4%，在难度更高的 SWE-Bench Pro v2-Hard 上达到 76.5%，在 SWE Atlas Codebase QnA 和 DeepSWE v1.1 上也分别取得了 53.2% 与 44.2% 的得分。如果这些数据能被第三方复现，它在垂直代码修补领域确实具备与一线模型叫板的实力。
但诡异的反差出现在动态环境里。在考验命令行交互与实际环境执行能力的 Terminal-Bench 4.0 测试中，Fern 0.1 的得分断崖式跌到了 6.1%。这种极端的割裂说明，模型或许擅长在给定的静态代码树里做阅读理解和补丁生成，一旦进入需要连续试错、观察终端反馈的真实工程环境，其可用性便大打折扣。
拆解 10M 上下文成绩单：基座代考与小样本偏差
比偏科更值得推敲的，是那张支撑起 1000 万 token 宣传口径的 RULER 长文本测试表。仔细阅读官方注释会发现，下场跑 10M 上下文测试的根本不是最终发布的 Fern 0.1，而是未经后训练的 基座模型 Mirendil-Base。行业里后训练损伤长文检索能力的案例屡见不鲜，用基座模型的成绩为指令模型背书，显然规避了最关键的验证环节。
即便只看基座模型的数据，测试协议也极其单薄。在 1M 长度下，官方对每项任务测试了 100 个样本；而到了核心卖点 10M 长度下，每项任务居然只测了 20个样本，且全程采用贪婪解码并关闭了思考模式。在如此微小的样本量下，Mirendil-Base 拿到了单针检索、全针多键检索和变量追踪召回的 100% 满分，多键检索也达到 90%。
但大海捞针找得到，不代表读得懂。RULER 基准的设计者早就指出，简单检索与长上下文理解完全是两回事。Mirendil 自己的表格就戳破了这层窗户纸，在需要跨段落逻辑串联的 HotpotQA 多跳问答中，一旦上下文从 1M 拉长到 10M，模型准确率便从 65% 直接滑落至 45%。
能大海捞针不等于能长文推理，基座代考更撑不起商用承诺。
截至 10 月 27 日，Hacker News 和 Reddit 等开发者社区上没有任何针对 Fern 0.1 千万级上下文的独立实测。目前唯一的外部背书来自其推理合作伙伴 Baseten，而 Baseten 测试的其实是另一款名为 Mirendil-Base-Large 的模型在私有代码库上的每字节比特数（bits per byte）指标，与开发者关心的 10M 窗口真实问答表现根本不是一码事。
- 风险.Mirendil 用基座模型和 20 个样本跑出的 10M 检索满分存在显著的统计偏差，且 45% 的多跳问答准确率意味着直接用它做全量代码库跨文件复杂推理极易翻车。
算力与经济账：为什么实验室的 10M 很难变成公开 API
把视野放宽到整个大模型行业就会明白，1000 万 token 从来不是什么从零到一的技术新发明，真正的死穴在于 推理成本 与显存带宽。早在 2024 年，Google 就在 Gemini 1.5 的研究论文里展示过 10M token 下超过 99% 的检索率。但到了真正对外商业化交付时，大厂和算力平台无一例外都在给上下文窗口踩刹车。
| 模型名称 | 宣称最高窗口 | 实际 API 可用上限 | 输入/输出定价（每百万 tokens） | 核心长文指标表现 |
|---|---|---|---|---|
| Mirendil Fern 0.1 | 10M tokens | 暂未开放公开 API | 未公布 | 基座 10M 单针 100%，多跳问答 45% |
| Google Gemini 4 Argon | 1,048,576 tokens | 1,048,576 tokens | 促销 $2 / $10（缓存 $0.10） | 256K-1M GraphWalks BFS F1 84.2% |
| Meta Llama 4 Scout | 10M tokens | 327,680 tokens（DeepInfra） | $0.10 / $0.30（DeepInfra） | 256K 训练外推，缺乏第三方 10M 实测 |
看看眼下的市场标杆就清楚这笔经济账有多难算。Google 当前主推的 Gemini 4 Argon，在 256K 到 1M 的 GraphWalks BFS 复杂图遍历测试中拿到了 84.2% 的 F1 高分，但它的公开 API 上限依然牢牢控制在 1,048,576 tokens。即便在 2026 年 11 月 30 日前的半价促销期内，其输入和输出价格也要 2 美元和 10 美元每百万 tokens（12 月 1 日起恢复至 4美元和20美元，缓存命中为 0.10 美元）。这意味着如果不依赖缓存，哪怕只是把 10M 的窗口塞满一次，单次提问的硬成本就要几十美元。
开源阵营的境遇更能说明算力托管的残酷现实。Meta 的 Llama 4 Scout 同样高调宣传 10M token 窗口（在 256K 长度下训练并通过长度外推扩展），但在 DeepInfra 等主流第三方推理平台上，尽管输入输出价格压到了低廉的 0.10 美元和 0.30 美元每百万 tokens，平台实际允许调用的上下文上限却被硬生生砍到了 327,680 tokens。
千万级上下文对 KV Cache 显存占用和首字延迟（TTFT）的要求极为苛刻，算力商如果不截断长度，单次请求就足以拖垮整台推理服务器的并发吞吐。Mirendil 这次拉上推理基础设施厂商 Baseten 站台，核心悬念正在于他们能否打破 Llama 4 Scout 被迫截断的窘境。
对于正打算重构代码助手或文档分析管线的企业研发团队来说，现在显然不是抛弃现有检索增强生成（RAG）架构或 Gemini 4 Argon 等成熟 1M 管线的时候。在 Mirendil 真正敞开 API、亮出首字延迟和账单明细之前，那 23MB 代码一口吞下的宏大叙事，还只停留在纸面上。