Fern 0.1 是什麼？Mirendil 宣稱可讀千萬 Token，長上下文測試與使用限制解析
Mirendil 宣布 Fern 0.1，整理千萬 Token 上下文、RULER 測試、編程能力、使用資格，以及導入前要確認的價格與資料限制。
Fern 0.1 宣稱能處理長篇程式碼與 AI 工作紀錄，目標是讓模型一次參考更多資料。
如果錯誤發生在某個設定檔，原因卻藏在很久以前的執行紀錄，使用者就得先挑選資料，再把片段交給模型。
AI 研究公司 Mirendil 在 2026 年 10 月 26 日公布 Fern 0.1，宣稱這個模型最多可處理 1,000 萬個 Token 的上下文，目標是分析程式碼、訓練紀錄與 AI 代理的工作軌跡。
上下文可以理解成模型在一次任務中可參考的內容範圍，但範圍變大，不代表模型一定找得到正確線索，也不代表所有資料都會被正確理解。
官方測試中，模型在超長文件的簡單尋找任務表現突出，多步驟問答的結果卻明顯較低。這些數字來自公司自己的測試，仍需要外部重現。
截至發布公告，這款模型的使用入口仍標示「即將推出」，價格和公開權重也沒有在公告中交代。先看清楚測試內容，才能判斷這個數字與實際工作有多大關係。
Fern 0.1 是什麼？先認識為什麼模型需要長上下文
Fern 是 Mirendil 公布的模型家族，第一個版本是 Fern 0.1。官方表示，它以自行預訓練的 Mirendil-Base 為基礎，再經過一段後訓練，主要面向高頻率的 AI 研發與代理工作。
預訓練是讓模型從大量資料學習文字和程式碼規律的階段。後訓練則進一步調整模型如何回應任務。公司沒有在這次公告中提供足以讓外部完整重現全部訓練流程的材料。
上下文是模型執行一次任務時能參考的輸入範圍。除了使用者現在輸入的問題，也可能包含先前對話、指令、文件、程式碼及工具回傳結果。模型可容納的最大上下文通常以 Token 計算。
Token 不是固定的一個字或一個英文單字。文字如何切分會依模型和內容不同，因此 1,000 萬 Token 不能直接換算成固定的繁體中文字數或固定頁數。
Mirendil 以程式碼舉例，表示約可容納 23 MB 程式碼，或約 50 萬行程式碼。這是公司在特定內容上的估算，不是任意類型檔案都能塞入相同資料量的保證。
對開發者來說，較大的窗口可能減少事前切分資料的工作。例如分析一次跨多個服務的錯誤，除了出問題的程式，也能把較長的錯誤紀錄和相關設定一起交給模型。
延伸閱讀：Kimi K3.1 Pro 發布：百萬 Token 與開放時間，完整權重仍要等到 11 月
但把資料放進去只是第一步。當資料越多，模型能否辨認真正相關的條件、忽略相似但不適用的訊息，會直接影響最後的診斷。這也是官方接著展示長上下文測試的原因。
千萬 Token 的測試怎麼看？找資料與推理是兩件事
Mirendil 公布一組 RULER 長上下文測試，評估模型能否從大量內容中找出資訊並完成不同形式的問答。官方表格顯示的是基礎模型 Mirendil-Base 的結果，不能不加區分地當成所有未來版本的表現。
在 1,000 萬 Token 的測試條件下，官方列出的單一線索搜尋正確率是 100%，多個指定線索搜尋中的一項是 90%，多步驟問答則是 45%。不同任務的差異提醒我們：找到一個明確字串，比整合多段資訊後回答問題容易得多。
例如讓模型在大量文字中找到一個指定代號，和要求它結合多個文件推斷故障原因，雖然都發生在長上下文裡，需要的能力並不相同。前者的高分不能自動證明後者也可靠。
樣本數也影響解讀。官方說一般測試格點使用 100 個例子，但 1,000 萬 Token 條件下每格使用 20 個。以這麼少的樣本估計表現，單一題目就可能對百分比造成明顯影響。
測試設定採用精確字串比對與指定的生成條件。這讓不同測試可以依相同規則計分，卻不能完全反映真實工作：程式專案可能有格式不一致、過期註解，以及根本沒有標準答案的問題。
因此，這組數字適合拿來觀察方向，不適合當成「千萬 Token 內的資訊都能正確找出」的承諾。等服務開放後，還要用實際的專案、日誌與預期結果驗證。
延伸閱讀：Subquadratic 發表 SubQ：1200 萬 Token 長上下文模型，挑戰 Transformer 成本瓶頸
官方如何比較模型？注意測試資料和版本差異
除了資訊搜尋，Mirendil 還展示模型在不同長度的程式內容下，對下一段文字的預測表現。公司把自家程式碼儲存庫合併成資料流，使用不同大小的滑動視窗進行比較，並以每個位元組的交叉熵呈現結果。
交叉熵在這裡可以理解為模型對接下來內容的不確定程度；在同一設定下，數字較低代表預測表現較好。公司使用位元組作比較，是為了減少不同模型切分 Token 的方式對比較造成影響。
官方圖表顯示，Fern 隨著上下文增加，這項指標持續下降。但比較資料來自 Mirendil 的儲存庫，能說明測試資料上的現象，不能直接代表所有公司的私有程式碼都會有一樣的收益。
圖表中其他模型的測試範圍也不同，有些只測到約百萬 Token 或其宣稱的窗口附近。當某一欄位沒有更長視窗的結果，就不能推論那個模型在該長度一定表現較差。
公司也提醒，圖表同時包含基礎模型與後訓練模型，兩類模型在這種預測指標上可能不同。因此，讀者看圖時應先對照模型類型、資料、上下文長度和評測設定，再討論差距。
這些資訊對需要理解大量內部程式碼的團隊有參考價值，但仍須追問成本。更長的上下文可能增加運算、等待和傳送資料的成本，官方此次沒有提供 1,000 萬 Token 實際延遲或完整計費資訊。
模型的程式能力如何？長窗口不等於全面領先
在代理程式與終端機測試方面，Mirendil 公布了多個模型的比較表。以公司所列的 Terminal Bench 4.0 為例，Fern 0.1 的通過率是 6.1%。同一表格中的 Claude Opus 5.5 為 66.4%，兩者差距提醒我們，容量大的模型不一定在每種任務都表現最好。
官方表格也列出 Fern 0.1 在 SWE-Bench Verified 的 73.4%。這些是公司整理的測試結果，其他模型的數值來自模型卡、排行榜或公司自行測試，來源和測試條件可能不完全相同。
這些指標不應跨表直接相加或平均。終端機任務、程式修改與程式庫問答考驗的能力不同，而且同一任務中使用的工具環境、推理設定和執行次數都可能影響結果。
更重要的是，官方的長上下文表格測試的是 Mirendil-Base，而代理基準比較表使用的是後訓練的 Fern 0.1。兩者有直接關聯，但不是同一個評測物件。看到基礎模型在某項搜尋測試拿到滿分，不能直接推論後訓練模型的每個編程流程都會成功。
若團隊希望用模型排查訓練失敗，應挑幾個原因已知的案例，把同一份日誌交給不同工具，再比對它們是否指出真正的失敗位置。只看答案流暢、沒有回頭驗證，容易把看似合理的猜測誤當成診斷。
對程式碼修改也一樣。模型提出的修復應回到版本控制、測試結果和人工審閱，確認它沒有破壞其他功能。長上下文能提供更多線索，不會自動替代這些驗證工作。
哪些工作可能受益？大型程式庫與代理紀錄是重點
Mirendil 將 Fern 的目標用途放在 AI 研發工作，包括檢查訓練資料、分析訓練紀錄、閱讀代理執行軌跡，以及在大型程式庫中處理問題。這些是官方設定的應用方向，並非本篇已完成的獨立實測。
分析大型程式專案
在大型程式專案中，一個功能可能跨越資料庫設定、介面、伺服器和測試。若只能提供單一檔案，模型可能不知道其他模組的限制；較長窗口讓團隊有機會把更多相關資料交給同一個任務。
但完整放入不等於所有檔案都有用。過時的程式碼、未採用的範例和不同版本的文件，也可能讓模型混淆。專案仍應標示目前版本與可信資料，並保留測試來檢查修改。
閱讀長日誌與代理執行軌跡
AI 代理執行任務時，可能反覆查資料、呼叫工具並修正錯誤。工作持續數小時後，完整紀錄會很長，單看最後一則失敗訊息可能漏掉前面已發生的錯誤。
如果模型能讀取較完整的軌跡，就可能協助使用者追溯某一步的前因後果。實際效果仍要檢查它引用的紀錄是否真的存在，以及時間順序和錯誤原因是否正確。
日誌也常包含網址、密鑰、客戶名稱或內部資料。使用外部模型前，團隊要先確認服務的資料處理條件，並依需求刪除或遮蔽敏感資訊。窗口更大，也代表一次可能送出更多資料。
檢查訓練資料
官方提到可用於檢查重複內容、測試資料污染和低品質資料。這類工作通常涉及大量記錄，因此長窗口在規劃上有吸引力，但公告沒有提供可讓讀者直接推算所有資料清理成效的完整獨立驗證。
例如模型標出可能重複的樣本後，團隊仍要定義什麼情況算重複，並確認刪除不會影響合法、必要的資料。對測試資料污染的判斷，也需要保留可追溯的比對依據。
如何使用？價格與權重是否已經公開
截至 2026 年 10 月 26 日的發布公告，Fern 0.1 的取得方式標示「即將推出」，公司提供早期使用申請資訊。這代表讀者可以關注後續進展，但不能假設申請後立即獲得服務。
公告沒有列出正式 API 價格、每次請求費用、推理速度或公開下載權重。第三方文章對使用形式可能有不同描述，實際採用仍應以官方正式開放後的文件與帳戶條件為準。
官方以範圍而非單一數字表示模型大小：Fern 0.1 約落在 1,000 億至 5,000 億參數。這個範圍沒有揭露精確總參數，也沒有給出每次推理啟用的參數數量。
公司另外列出兩個更大的基礎模型仍在預訓練中。它們的上下文、開放時間與用途仍有未填資訊，所以不能把現有版本的規格自動套用到這兩個未來模型。
如果你需要現在就部署長文件分析流程，應先比較目前真正可取得的模型、部署方式和價格。Fern 的公告可作為追蹤方向，但在權限和條款確定之前，還不足以構成採購或交付時程。
團隊應如何驗證長上下文工具？
第一步，選擇真正會遇到的任務，而不是只測試能否把一個檔案放進窗口。可以從已知原因的錯誤紀錄、已完成審查的程式修改，或有標準答案的文件問答開始。
第二步，確認輸入的內容與版本。若把舊版設定和新版程式一起提供，模型可能找到真實存在卻已經過時的資訊。保留檔案版本、日期和選取方式，才能追溯答案的依據。
第三步，要求結果標出引用位置，再由工程師回查。對數字、函式名稱或安全設定尤其如此：即使模型給出一份完整解釋，也應確認每個關鍵依據都來自原始資料。
第四步，計算完整成本。除了模型費用與等待時間，還要記錄整理資料、人工核對和重跑任務花費的時間。一次放入所有資料看似方便，但未必比分段搜尋再集中分析更省資源。
最後，保留失敗案例。若模型找得到明確字串，卻經常漏掉跨檔案的限制，就應把這類問題列為後續測試重點。團隊要找的是能穩定完成自己任務的方法，而不是只追逐最大的窗口數字。
這款模型提供了一個值得觀察的研究方向：把更多程式碼和代理紀錄放進同一個任務。但目前公開的是公司測試與尚未開放的服務，真正的品質、價格和資料條件，仍需要等實際使用後判斷。想比較其他長上下文方案，可參考本文的延伸閱讀。
常見問題
Fern 0.1 已經可以使用嗎？
官方公告將使用權標示為即將推出，並提供早期使用申請。開放範圍、時程與條款應以後續官方資訊為準。
1,000 萬 Token 代表能讀多少中文字？
沒有固定換算。Token 切分依模型和內容不同，官方的 23 MB、約 50 萬行是以程式碼為例的估算。
搜尋測試滿分代表它能理解全部資料嗎？
不能這樣推論。官方在不同任務上的結果有差異，而且 1,000 萬 Token 測試每格只有 20 個樣本，仍需要更多評測。
模型有公開價格或可下載權重嗎？
發布公告未提供完整 API 價格，也未列出可公開下載的權重。若服務推出後內容變動，應查最新官方文件。
