Moondream 3.1 9B A2B 與 North Micro Vision Instruct：哪家廠商才真正讓你查看數字

兩個開放視覺模型，相隔四個月推出，對於它們希望被如何評判，幾乎沒有共通之處。 M​oondream 3.1 9B A2B於 2026 年 7 月 7 日發布，附有一張基準測試表、一段指明使用單一 H100 SXM5 與批次大小 16 的方法註腳，並且同一篇文章中貫串著一個論點：基準測試並不能衡量其客戶真正需要的事物。 North Micro Vision Instruct於 2026 年 8 月 12 日由 C​ohere Labs 推出，以 2.4B 參數、Apache 2.0 授權發布，其發布文章通篇著重於訓練課程與其評估設定——所使用的測試框架，以及產出這些數字時的確切取樣參數。

那是本質上的真正差異，而且對買家來說，比任一款模型的參數量都更有用。一家廠商是在告訴你如何重現它的表格。另一家則是在告訴你不要相信表格，然後自己印出一份表格。就我們所能查到，兩者都沒有經過獨立評估，所以真正決定該倚重哪一組數字的問題，在於兩家廠商各自給了你多少可供查核的內容。

每一項是什麼

M​oondream 3.1 9B A2B 是一款稀疏混合專家視覺語言模型：總參數量 9B，每個 token 有 2B 活躍參數，64 個專家中有 8 個活躍，搭載 SigLIP 視覺編碼器並具備多裁切通道串接、32K token 上下文，以及 SuperBPE 分詞器。它的四項技能——查詢、偵測、指向與描述——是透過訓練而非提示詞得來，且偵測與指向路徑會回傳結構化幾何資訊，而非描述。它可在 Photon 上執行，這是該廠商的推論引擎，目標是從 Ampere 世代起的 N​VIDIA GPU 與 Apple Silicon。

North Micro Vision Instruct 是一個 2.4B 稠密模型，由三個部分組成：一個 400M 原生解析度視覺編碼器，進一步從 Google 的 SigLIP 2 SO400M 檢查點預訓練而來；一個投影器，遵循 DeepStack 模式，將來自多個編碼器層的 patch embeddings 注入早期語言模型層；以及一個名為 North Micro LLM 的 2B 語言模型，遵循 Cohere 的 Command A+ 架構。它接收交錯的文字與圖像——一張或多張——並輸出文字。分詞器詞彙量為 262,144，所列語言達到十一種，外加「以及更多」。

輸出類型的差異值得直說，因為它會形塑後續內容：M​oondream 是一個以邊界框與座標作答的感知模型，North Micro Vision 則是一個以語言作答的理解模型。這兩家廠商所發布的一切，都是對這兩項任務其中之一的衡量，而它們並非同一項任務。

那個並非模型上下文視窗的 8K 數字

先從陷阱談起，因為它就擺在 North Micro Vision 模型卡的正中間，而這種東西往往會在無意間被納入架構決策。

• North Micro Vision Instruct — 語言主幹上下文視窗為 128,000 個 token；已驗證的多模態運作範圍最高可達 8,000 個 token。該卡片明確指出，更長的多模態上下文可能依賴外推，且尚未經過基準測試。

• Moondream 3.1 9B A2B — 32,000 個 token，一個數字，未公布任何模態例外劃分。

所以，頭條數字讓 North Micro Vision 以四倍勝出，而真正會套用到你影像工作負載的數字，則讓 Moondream 以四倍勝出。如果你在估算單次呼叫能容納多少頁掃描文件，128K 是錯的數字，8K 才是對的；而一旦原生解析度編碼器開始依像素面積比例輸出 token，8K 的圖像與文字交錯 token 其實並不算多頁。廠商願意公布這項但書值得讚許——大多數規格卡都不會這麼做——但這項但書被埋在規格表下方，而會被複製的正是那張表。

兩個供應商的報告方式並列比較

這是比較中與模型無關，而完全取決於哪一個可供稽核的部分。

Moondream 的 3.1 文章說明了其基準（Qwen3.5 9B、SAM 3、LocateAnything、Gemma 4 12B）、其指標（檢測的 F1@0.5）、其硬體（一張 H100 SXM5）、其批次大小（16），以及每個模型由自己的引擎提供服務——vLLM 用於 LocateAnything、Qwen3.5 和 Gemma 4；Photon 用於 Moondream；Hugging Face Transformers 用於 SAM 3。它還表示每個模型都選擇了最高的準確度和推理設定，並且 LocateAnything 以慢速模式運行以最大化準確度。它發布的結果是 81.46 F1@0.5 在 COCO val 上、93.94 在 ODinW-13 上、67.4 在 LVIS 上、74.61 在 Dense200 上、52.77 在 SKU-110K 上、74.5 在 CrowdHuman 上、87.1 在 RefCOCO-M 上、70.39 在 HumanRef 上、59.63 在 DOTA-v2 上、90.35 在 CountBench 上、74.86 在 TallyQA 上、88.68 在 PixMo-Count 上、86.01 在 ChartQA 上，以及 88.6 在 DocVQA 上，並在五個基準系列上宣稱達到最先進水準。

那個頁尾裡沒有的，是讓結果可重現的東西：提示詞。偵測是開放詞彙任務，而你用來查詢某物的詞句會改變回傳的結果。重新執行的人有指標、硬體和批次大小，卻仍無法在不知道每個框是由什麼文字產生的情況下重現那個數值。

Cohere Labs 的貼文則採取了另一種做法。它點名了所用的測試框架（VLMEvalKit），說明該模型是以內部的 vLLM 實作進行評估，列出每個能力群組的基準組成——General VQA 是 MMBench、MMStar、RealWorldQA 與 GQA 的平均值；圖表、文件與 OCR 群組涵蓋 ChartQA、DocVQA、InfoVQA、OCRBench、OCRBench v2 與 AI2D；grounding 與計數則是 RefCOCO 平均值與 CountBench——並公開這些數字產生時所用的取樣參數：temperature 0.7、top_p 0.8、top_k 20、min_p 0.0、presence_penalty 1.5、repetition_penalty 1.0。它同時指出公開版 vLLM 支援「即將推出」，而這正是對任何打算重現結果的人來說最重要的一項誠實揭露：該模型是在一個分支版本上測試的。

那篇文章沒有公布的是逐項基準測試表。它的結果是能力群組平均值與一項相對宣稱——在 Instruct 模式下，35B-A3B 以更少的推論時間取得比 Qwen3.6 35B-A3B 更高的分數，而 1B 變體在分數與效率上都勝過 Qwen3.5 0.8B——這種說法較不容易被直接引用，也更能抵禦挑選性引用。兩份文件都沒有讓你能重新計算另一家廠商的數字。但兩者都讓你看出它們隱藏了多少。

架構差異在實務中顯現在何處

原生解析度是 North Micro Vision 中唯一會改變日常工作的設計決策，值得在查看基準測試表之前先了解。大多數視覺編碼器會把你交給它們的任何內容調整成固定正方形，這就是為什麼一張寬幅試算表截圖送到語言模型時，其欄位會被壓扁。North Micro Vision 的編碼器經過訓練，會以影像自身的解析度和長寬比來接收影像，保留文件、表格、圖表與表單的細微細節。已公布的訓練課程從以 1000 萬個範例進行的固定 384×384 階段，發展到以 1300 萬個範例進行的 1024×1024 階段，甚至更多。

M​oondream 的編碼器則是以多裁切（multi-crop）為基礎：影像被視為一組裁切區域，而其特徵會被串接起來；這也是一種在大尺寸輸入上保留細節的方式，並與其偵測頭產生邊界框的方式相互耦合。兩者都是對同一問題的合理答案，而且沒有任何廠商在相同解析度下公布正面對決，因此能從架構討論中帶走的實用結論，比一個定論更狹隘：如果你的工作是密集文件與寬幅 UI 螢幕截圖，原生解析度才是該測試的屬性，而且測試要用你自己的螢幕截圖，而不是某個基準測試列。

另一項結構性差異在於多圖與影片。North Micro Vision Instruct 能處理交錯的多圖輸入，並在其評估的各組中列入多圖基準。Moondream 3.1 9B A2B 的範圍則是每次呼叫僅限一張影像——沒有影片路徑，也沒有多圖路徑。這與其設計一致：Moondream 自家關於即時影片的工程文章主張，問題出在推論的管線架構，而非模型能力，而該公司對時序性工作負載的答案，是一套能跟上串流的引擎，而不是一次只接收一張影像的檢查點。這是否比一次接收 128 個影格的模型更好，是個坦白而未解的問題，而且兩家廠商衡量的並不是同一件事。

快速部署與授權

• 規模 — 總參數 9B／啟用參數 2B，對比 2.4B 稠密。就儲存而言，差距比啟用參數比例所暗示的更大，因為稀疏模型的佔用空間取決於其總參數。

• 微調規模 — 一個 2.4B 稠密模型小到足以在單一裝置上進行微調；而一個 9B 稀疏模型若要做任何超出 LoRA 的訓練，就需要一套真正的訓練環境，這也是為什麼 Moondream 自家的調校路徑得透過託管產品來進行。

• 執行環境 — North Micro Vision Instruct 要求使用 Transformers 5.16.0，並搭配 accelerate 與 Pillow；社群量化版本已存在於 MLX、LiteRT 以及 ONNX 周邊格式中。M​oondream 3.1 9B A2B 可在 Photon 上執行，而該檢查點首個第三方 GGUF 封裝於 2026 年 10 月 15 日出現。

• 授權 — Apache 2.0 適用於 North Micro Vision Instruct，無使用門檻，亦不限制為他人代管。M​oondream 3.1 9B A2B 適用 M​oondream Model License 1.0：允許商業使用、自行託管、微調、量化及再散布，惟有一項禁止 — 不得將通用型 M​oondream 推論或微調作為代管服務提供。

• 更迭 — North Micro Vision Instruct 自發布以來一直維持不變；近期值得注意的新增項目是第三方量化版本。Moondream 的條款在過去兩週內也有所變更：Prime Intellect 於 2026 年 10 月 13 日收購該公司，而 Moondream Cloud（包括 Lens 微調產品）將於 2026 年 11 月 13 日關閉。權重與 Photon 不受影響；託管路徑則不然。

管線中的第二個模型，以及由誰來路由它

這兩個檢查點都沒有在 OrcaRouter 上提供服務，所以請把這段內容當成一則整合說明。兩者都是單階段元件：一個回傳邊界框，另一個回傳文字，而正式環境的系統需要它們背後有一個模型來判斷這個觀察結果代表什麼，並把它記錄下來。那個階段是文字階段，每次呼叫的成本通常高於視覺階段，而且當更便宜或更好的推理模型出現時，你會最想優先替換的就是這個階段。一個相容於 OpenAI 的端點，涵蓋 200 多個模型——供應商定價表以 0% 加價直接轉嫁，並在上游出狀況時自動跨供應商容錯移轉——來完成這項替換，意味著只需更改模型識別碼，而不必重新配置攝影機的線路。當單一意見不足時，模型融合會在相同輸入上跑一組模型，而路由 DSL 則會將數個模型組合成單一次呼叫。

有一個地方我們可以講得更明確，而值得誠實面對的是它究竟對哪一方有利。North Micro Vision Instruct 採用 Apache 2.0，而且小到可在你自己擁有的硬體上執行，這意味著將視覺模型透過託管端點來路由的常見理由——也就是你無法自行託管它——並不適用。剩下的理由是再普通不過的那個：在流程中加入第二個模型，使用同一把金鑰、同一份帳單與同一組憑證。

該選哪一個，以及什麼會改變這個答案

如果你正在閱讀文件、表格、圖表或螢幕，若你在一次呼叫中需要多張影像，若 Apache 2.0 很重要，因為你打算為其他人代管這個模型，或者你想要一個能在自己的資料上微調的 2.4B 檢查點，就選擇 North Micro Vision Instruct。C​ohere 的模型卡指出微調是預期用途，而授權條款不會造成任何阻礙。

若你的輸出是幾何資訊——邊界框、座標、附帶實例的計數——而且你的部署環境是搭載 Photon 的 CUDA 機器，就選擇 Moondream 3.1 9B A2B。這個模型很專門，而它的速度宣稱正是針對這樣的工作負載。

能同時改變雙方答案的，會是一項獨立評測，而這正是值得持續關注的重點。兩家廠商的數字都沒有在廠商之外被重現，而且各自是在讓重現變得比必要更困難的條件下公布：一家不公開提示詞，另一家則是在某個框架的內部推論服務實作上執行，而該框架的公開支援仍待補上。當第三方在同一份文件集上執行任一個檢查點時，哪個模型的表格能在這次接觸後原封不動地站得住腳，哪個才值得相信——而在那之前，願意告訴你它如何測量的那家廠商，是比較容易與之爭辯的一方。

這樣的結果也提醒我們，模型錯誤早已有紀錄：這一類模型背後的 AI 事件與代理失效，都收錄在OrcaRouter AI Incident Archive，其中每一筆紀錄都附有自己的來源、嚴重程度、可信度等級與爭議標記。