AesCode-8B 與 North Mini Code：相同授權，相同下載按鈕，問題卻截然相反

這場對比中最有用的數字是 150,000。那是 Cohere 為 North Mini Code 於 2026-08-14 標示的下載次數，也就是該模型於 2026-06-09 推出兩個月之後，而正是這個數字讓與 AesCode-8B 的比較變得清晰可讀。AesCode-8B 是 Microsoft 對 Qwen3-VL-8B-Instruct 的微調版本，在其 Hugging Face 儲存庫上顯示兩次下載。兩者皆為 Apache 2.0，皆無閘門限制，今天下午都能下載，而其中一個已在生產環境中實際使用了一季，另一個則尚未離開實驗室。這個差距並非品質評斷——沒有人獨立評測過 AesCode-8B，所以雙方都沒什麼好得意的——但它是誠實的起點，因為它告訴你哪一個擁有你可以提問的社群。

這兩者的問世方式截然不同，而這也影響了你能驗證什麼。North Mini Code 是 Cohere 與 Cohere Labs 的開放權重發布，附有模型卡、背後的一篇部落格文章、一連串關於測試框架選擇的書面紀錄，以及一個隨附的 API，在發布期間以每百萬個 token 0.00 美元的價格提供服務。AesCode-8B 則完全沒有任何公告：Microsoft 在 2026-09-29 建立了該儲存庫，於 2026-10-07 03:35 UTC 以「Release AesCode-8B」的訊息提交權重，並在 2026-10-08 將訓練程式碼推送至 GitHub。沒有 Microsoft Research 的貼文、沒有發行說明、沒有產品頁面，而引用資訊行寫著「審查中」，年份則是佔位用的 2027。這個 8B 模型以 HTML 和 CSS 輸出簡報、海報和儀表板；North Mini Code 則是在代理框架內撰寫程式碼。與其說它們是競爭對手，不如說是型錄中的鄰居，而這本身就是一種發現。

每一個被訓練來輸出的內容

要看出這兩者並非做同樣的工作，最清楚的方法就是看看它們會產出什麼。

• 輸出 — AesCode-8B：一份完整的 HTML 與 CSS 文件，每次請求產生一個渲染完成的頁面。North Mini Code：文字與工具呼叫，實務上即是修補檔、shell 指令與代理軌跡。

• 大小 — AesCode-8B：8.8B bf16 稠密模型，分為四個 safetensors 分片，總計 17,543,339,408 位元組。North Mini Code：總參數量 30B，啟用參數 3B，為稀疏混合專家模型，擁有 128 個專家，每個 token 啟用 8 個專家。

• 上下文 — AesCode-8B：在所報告的配置中為 24,576 個詞元，訓練時的提示與回應各自上限為 8,192。North Mini Code：輸入 256K，最大生成 64K。

• 輸入 — AesCode-8B：文字加上一張可選的參考圖像。North Mini Code：僅文字，其餘一切由測試框架提供。

• 訓練於 — AesCode-8B：3,000 個冷啟動示範，接著對 7,408 個提示進行 GDPO 強化學習、共 400 步，並在沙箱瀏覽器中渲染每個候選後，由六個確定性驗證器加上視覺評分標準評分。North Mini Code：代理框架 — SWE-Agent、mini-SWE-Agent、OpenCode 與 Terminus 2 — 因此它能在你已經使用的任一個框架內運作，而不是把你綁死在單一框架上。

• 授權—— 兩者皆為 Apache 2.0，包含權重，沒有使用領域限制條款，也沒有貢獻者分級。在這個面向上，兩者完全相同，無法據此做出決定。

• 證據 — AesCode-8B：Microsoft 自家的 300 個樣本資訊圖表評分標準，未經重現。Long Mini Code：廠商數據加上一項獨立測量。

證據的不對稱性，其實比表面上看起來更窄

這項比較的東側有一位外來者，而這比基準差距更有價值。Artificial Analysis 親自跑過 North Mini Code，在其 Coding Index 上給出 33.4 分，在 Intelligence Index 上給出 27.6 分——與同尺寸的開源模型相比具有競爭力，甚至更高。Cohere 回報在 SWE-Bench Verified 上 pass@1 達 61.0%，輸出吞吐量最高可達 Mistral 的 Devstral Small 2 的 2.8 倍，兩者皆為廠商數據。獨立進行的跑分才發現了當中的問題：North Mini Code 為了完成同一套基準測試，產生的輸出 token 約為其同尺寸級別中位數的三倍，約 7,500 萬至 7,700 萬個輸出 token，而中位數為 2,500 萬至 3,800 萬個。在推出期間價格為零時，這不花任何現金。但它耗費延遲，也預示了優惠價結束後的帳單。

AesCode-8B 在量測之外沒有對等者。Microsoft 報告其自家 300 個樣本的資訊圖表評估中，整體得分為 82.94，每個提示生成三次且不進行挑選，領先參考條件化的 GPT-5.5 的 81.28 與 Claude Opus 4.8 的 80.39，並比自身的骨幹模型高出 31.1 個視覺分。它還報告指出，參考條件化獎勵將僅提示的視覺分從 25.17 提升到 69.71，並且在推論時不提供參考圖像，僅使該模型損失 1.00 個視覺分，而骨幹模型則損失 19.55 個。這些是異常具體的主張，而且測試框架是開源的，這比大多數廠商表格所提供的還要多。其中沒有一項已被任何人重現。沒有競技場列表、沒有排行榜排名、沒有吞吐量測量，也沒有第三方對評分標準的審查。

請注意這對這項比較具體意味著什麼：兩者並沒有共通的數字。一個模型是根據軟體工程任務是否通過，以及耗費多少 token 來評分；另一個模型則是根據資訊圖表的文字是否保持清晰易讀、版面是否維持在畫布內來評分。把 33.4 和 82.94 並列，等於是拿程式編寫指標和資訊圖表整體分數相比。

每一個各自部署在何處，以及那要花多少成本

North Mini Code 的部署故事，正是它突破 15 萬次下載的原因。一個 3B 活躍參數的 MoE 量化後約佔 20–24 GB 記憶體，Cohere 團隊透過 MLX 在 Mac Studio 上展示了這一點，而 3B 的活躍參數量正是讓本地推論具經濟效益的關鍵。在全精度下，它只需單張 H100 就能運行。Cohere 在發布期間以每百萬輸入與輸出 token 0.00 美元的價格提供服務，並為生產規模提供受管理的逐執行個體部署途徑。這個數字本身是 Cohere 自家的數據，彙整了所有散布管道，並未提供逐平台的細分；而 Hugging Face 上公開的每月數字則小了一個數量級，這與該彙總數據涵蓋 API、託管閘道、套件管理員與本地下載的情況相符。把它解讀為動能，而非遙測數據。

AesCode-8B 的部署方式就是一道命令列指令。這張卡直接給了出來——vllm serve microsoft/AesCode-8B --limit-mm-per-prompt image=2 --max-model-len 24576，搭配 transformers 4.57 或更新版本，用於非 vLLM 路徑。17.5 GB 的 bf16 權重，再加上 24,576 個 token 與最多兩張影像的 KV 快取，所以單張 24 GB 的卡在技術上足夠，實務上則很吃緊；40–48 GB 才是現實的下限。如果你想用作者的方式為輸出評分，還得加上一套渲染堆疊，因為這款模型的每一項品質宣稱，都是透過在瀏覽器中渲染其 HTML、並封鎖外部請求而得出的。我們找不到任何託管端點，而且它也不在我們的目錄中。

最後一點對任何比較這兩者在可用性上的人來說，是最實際的一點。North Mini Code 存在於廠商自家的 API 和幾個第三方平台，以及權重本身。AesCode-8B 只存在於 Hugging Face 和 GitHub。如果你的限制條件是「我明天就需要從某個服務呼叫它」，這兩者中只有一個會回答可以。

兩個模型都無法解決的作文題

這個比較的兩半都藏著同一個陷阱，而且是同一個陷阱。採用其中任一個，都意味著要為某個專用模型維護一條自架服務路徑。AesCode-8B 需要多模態堆疊與渲染器，才能被妥善評估。North Mini Code 需要一個給 3B 激活量 MoE 的位置，外加圍繞它的 agent 框架，而它的冗長程度意味著軌跡成本比 token 數量所暗示的更高。一個想要兩種能力的團隊——一個頁面生成器和一個 repo agent——現在得跑兩套推論部署，而對於兩者皆非的一切，還得再跑第三套。

這就是「在眾多模型前面設置單一端點」確實能發揮實際作用，而不只是圖方便的情況。把專門模型留在你自己的硬體上，前提是經濟效益與資料處理方式足以證明這樣做合理，並把例行流量導向本週最適合處理它的託管模型，全部都在單一金鑰之後，以 0% 加成透傳供應商標價，並在供應商不穩時自動容錯移轉。Qwen3 系列骨幹正好說明了這條界線能變得多細：微軟以 Qwen3-VL-8B-Instruct 為基礎打造了 AesCode-8B，而該系列的視覺語言成員可透過 OrcaRouter 呼叫——Qwen3-VL-8B-Instruct 在 131,072 個 token 的上下文下，每百萬輸入 token 為 $0.18、輸出為 $0.70，而 Qwen3-VL 235B A22B 則是 $0.40 與 $1.60。這兩者都不是 AesCode-8B；這個微調版本屬於微軟，沒有供應商提供。但如果你想要的是能讀取螢幕截圖並寫程式的模型，而且你並不特別需要那個美學設計微調版本，那麼可呼叫的選項只需一小部分 GPU 成本，花一個下午就能試用，而不必經歷一整個採購週期。

如何在兩者皆非通用型的情況下做出決定

先把執照從談判桌上拿掉，因為這是平局，而且它不會決定任何事。

問你想要輸出的是什麼。如果答案是一個已渲染、可編輯的頁面——簡報、報告、儀表板——North Mini Code 幫不上你，而 AesCode-8B 是兩者中唯一針對這個問題的。務必看清現實：一個未事先公告的研究檢查點、兩次下載、僅在單一資訊圖頁面上驗證過的 24K 上下文、僅限英文的語言標籤，而且任何地方都沒有獨立評估。在微軟自己的表格中，Style 上限為 53.21，而該維度的定義是交付前不需再做任何視覺修訂——這等於供應商在告訴你，人類仍會編輯輸出。

如果答案是對儲存庫的一項變更——一次遷移、一個修正、一項多步驟的終端機工作——North Mini Code 正是具備 harness 訓練、256K 視窗、3B 活躍參數部署設定、可正常運作的供應商 API，以及對其品質與冗長程度皆有獨立量測的那一個。要為 token 數量編列預算，而不是看表面費率，因為獨立研究發現，它為了達到相同成果，寫出的內容約為同類工具的三倍。

如果你的季度同時包含設計產物和儲存庫遷移，不要將此視為雙模型決策。在專家模型能發揮其 GPU 價值的地方運行它，將其餘的導向其他模型，並停止維護你不需要的服務路徑。

比標竿更持久的差異

最後還有一件事讓這兩者高下立判，而這並非技術問題。North Mini Code 背後有廠商發布了模型卡、一篇文章、一個可以試用的 Space，以及一套你可以質疑的方法論，再加上 15 萬次下載所累積的他人經驗。AesCode-8B 則只有一個儲存庫、一份 README，以及一條標示為「審查中」的引用。

這改變了未解問題究竟是什麼。對於 North Mini Code，當前實際的問題是：一旦優惠費率結束，它的冗長程度是否會讓它在大規模使用下變得不划算——而你可以藉由實際運行來回答這個問題，因為許多人早已這麼做了。對於 AesCode-8B，當前實際的問題是 Microsoft 打算怎麼處理它：研究產物、產品線的首度發布，還是某個在六週內被悄悄取代的東西。儲存庫裡沒有任何內容能回答這點，再怎麼讀模型卡也無法回答。留意三個訊號——官方公告、對 82.94 的獨立重現，或有供應商採用這個檢查點——並把三者皆未出現視為目前的證據狀態，而不是這模型不值得關注的理由。它值得關注的原因是那 1.00 點的參考下降，而那個數字仍擺在那裡，等待 Microsoft 以外的人去查核。