AesCode 32B 對比 North Mini Code：權重檔案並非承諾

這兩個模型都是 Apache 2.0、兩者皆可下載，且兩者都是為某項狹窄工作而打造——而相似之處也正是在此失去用處。AesCode 32B 是 Microsoft 用於生成可編輯 HTML 與 CSS 的研究檢查點：簡報、海報、儀表板與報告。其 Hugging Face 儲存庫建立於 2026 年 9 月 29 日，而名為「Release AesCode-32B」的提交於 2026 年 10 月 7 日進入版本庫；Microsoft 並未發布任何公告，而模型卡完全沒有載明發布日期。North Mini Code 則是 Cohere 的開放權重代理式編碼模型，為 30B 混合專家模型、3B 活躍參數，於 2026 年 6 月發布，鎖定軟體工程與終端機作業。比較兩者最顯而易見的方式是用基準測試，但這行不通，因為兩者從未在同一項任務上受測，而且其中只有一個曾被自家實驗室以外的人測過。真正行得通的比較——也就是決定你實際上能否跑起其中任何一個的比較——是權重檔。

兩個檢查站，兩張截然不同的帳單

這是大多數比較會略過的軸線，而對兩個自行託管的模型而言，這正是最關鍵的軸線。

• 參數 — AesCode 32B：33B，稠密。North Mini Code：總計 30B，3B 啟用，專家混合。

• 執行所需的記憶體 — AesCode 32B：建議僅針對 bf16 參數就規劃約 65 GB 的加速器記憶體。North Mini Code：經過量化後，約 20–24 GB 即足夠，且參考部署中包含一台 Mac Studio。

• 服務形態 — AesCode 32B：一個視覺語言模型，因此服務路徑同時承載圖像與文字，而其自身範例採用四路張量平行。North Mini Code：文字輸入、文字輸出；基準測試使用了單一終端工具。

• 授權 — 兩者皆為 Apache 2.0，且包含權重。這一列是平手，並不是大家以為的差異化因素。

• 上下文 — AesCode 32B：在報告的配置中為 24,576 個 token，訓練時的提示與回應上限為 8,192。North Mini Code：輸入 256K，輸出 64K。

• 它會輸出什麼——AesCode 32B：一份完整的 HTML 文件，表格以 HTML 表格呈現，圖表以 ECharts 規格呈現。North Mini Code：測試框架要求什麼，就輸出什麼文字或工具呼叫。

• 獨立評估 — AesCode 32B：未有任何公開評測；所有數據均來自 Microsoft。North Mini Code：於 Artificial Analysis 獲得評分，該平台亦指出其行文冗長。

第二列讀兩次。一個需要 65 GB 和四路平行處理的 32B 稠密視覺語言模型，和一個量化後能塞進單一工作站的 3B 活躍參數 MoE，是截然不同的採購決策。如果你考慮開放權重的理由是「我們想把它跑在自己的硬體上」，那麼在你送出第一個提示之前，那一列就已經是大部分的答案了。

授權條款並不是選擇其中任何一個的理由

幾乎每一項開放權重（open-weights）的比較都會從授權條款談起，但在這裡這是條死路：兩者都是 Apache 2.0，兩者都發布完整權重，且兩者都沒有會阻礙商業部署的使用限制。沒有可拿來與折扣衡量的資料共享條款，沒有貢獻者分級，也沒有用途領域的除外條款。無論你在這兩者之間做選擇的依據是什麼，都不會是許可授權。

把授權問題排除不談之後，剩下的就是模型被訓練去做的事——而這兩者被訓練的方向恰恰相反。

一個是在終端機上訓練的，另一個則是在畫布上訓練的

North Mini Code 的模型卡直接點明其目標：程式碼生成、代理式軟體工程與終端機任務。Cohere 在多個代理框架上訓練它——SWE-Agent、mini-SWE-Agent、OpenCode、Terminus 2——正是為了讓它能在你已經在用的任一框架中運作，並在 SWE-Bench Verified、SWE-Bench Pro、Terminal-Bench v2 與 Terminal-Bench Hard 上對其進行評估。它對外公開的弱點確實存在，而且是由外部評估者發現，而非供應商主動揭露：它產生的輸出 token 量約為同尺寸級距中位數的三倍。冗長的模型會寫出很長的代理軌跡，而一旦促銷定價結束，長軌跡正是你要付費的部分。

AesCode 32B 是以截然不同的資料訓練而成，而模型卡異常清楚地指出，目標就是產出物本身。這項設計的重點在於，程式碼模型無法看見版面配置、階層與色彩如何在畫布上結合，因此 AesCode 會使用由同一提示詞生成的圖像作為美學參考，同時以提示詞作為內容的真實依據。監督訊號是一張由節點與邊構成的「設計圖」，七個獎勵通道——執行、文字、邊界、表格／圖表、版面、留白、設計——其中六個是確定性驗證器，一個是依據每個樣本評分規準運作的視覺語言評判器。候選項目會在沙箱化的 Playwright 瀏覽器中渲染，外部請求會遭到封鎖，並依據 DOM、計算樣式、邊界框與螢幕截圖進行評分。

那套機制存在的目的，是要讓一件事成真：輸出是一個供人類開啟並編輯的渲染後頁面，而不是套用到儲存庫的修補程式。AesCode 32B 從未受過使用 shell 的訓練，而獎勵設計中沒有任何部分會因為它嘗試使用 shell 而給予獎勵。

證據的不對稱，誠實地說

North Mini Code 已由第三方運行。Artificial Analysis 在其 Coding Index 上給它 33.4 分，在其 Intelligence Index 上給它 27.6 分，並公布了冗長度發現。Cohere 自家公布的主要數字——SWE-Bench Verified 上 61.0% pass@1——是由供應商報告的，但可對照任何人都能下載的模型來查核，而且該模型卡對其測試框架的選擇相當坦誠，甚至指出在 Terminal-Bench Hard 上，它遵循了 Artificial Analysis 自己的方法論，以保持比較公平。

AesCode 32B 沒有對等模型。其 300 個樣本的資訊圖表評估，每個提示詞進行三次生成且不做選擇，得出整體 85.89，而 GPT-5.5 為 81.28，Claude Opus 4.8 為 80.39——全部都是在 Microsoft 的測試框架內、以 Microsoft 的樣本測量，並使用 Microsoft 訓練該模型時所依據的評分管道。這些數字確實有可能是公平的；其設計比大多數廠商表格更透明，驗證器堆疊與評分規準建構器都已開源，而且該模型卡公開了以下事實：比較中沒有任何模型在其風格維度上超過 60。但沒有任何外部實驗室重現過其中任何一項，也沒有競技場收錄、沒有排行榜名次，也沒有獨立的吞吐量測試。如果一個廠商基準——恰好有利於該廠商自家的基準（一項資訊圖表任務）——在你的決策中佔了很大分量，那麼你被要求的，就是接受唯一可得的解讀。

特別留意這對這場對決意味著什麼：兩者沒有共用的數字。完全沒有。其中一個模型的評分依據是軟體工程任務是否通過，另一個則是文字是否清晰易讀、版面是否不會超出畫布。任何把 33.4 放在 85.89 旁邊的頁面，都是在拿 Coding Index 與資訊圖表的 Overall 分數互相比較，而這兩個模型都不知道對方實際受測的是什麼。

兩者都不是通用型模型，而這正是真正的代價

這就是這個比較的兩半各自埋藏的陷阱。採用任一個模型，都意味著要為一名專才維護一條自架服務路徑：負責渲染頁面的那個需要 65 GB 的 VRAM 與一套多模態堆疊；負責處理終端任務的那個，則需要一個 3B 有效參數 MoE 的槽位。兩者都擅長各自的工作，而誰也做不了對方的，這意味著想要同時具備這兩種能力的團隊，如今得跑兩套推論部署——而對於介於兩者之間的一切，也就是那個既非頁面渲染器、也非終端代理的模型，他們還得再跑第三套。

這正是路由層憑實力掙得一席之地、而非被硬生生附加上的情況。用一把金鑰就能以供應商定價取用 200 多個模型、不加價，意味著專業性工作會留在你自己的硬體上，因為在那裡經濟效益與資料處理都說得通，而例行性工作則交給當週最適合的託管模型。Qwen3-VL 主幹系列正好說明了這條界線能變得多細：微軟以 Qwen3-VL-32B-Instruct 為基礎打造了 AesCode 32B，而 該系列的視覺語言成員可在 OrcaRouter 目錄中呼叫 — Qwen3-VL 235B A22B Instruct 每百萬輸入符元為 $0.40、輸出為 $1.60，或較小的 Qwen3-VL 8B Instruct 為 $0.18 與 $0.70。這兩者都不是 Aes 32B：這個微調版本是微軟的，沒有供應商提供。但如果你想要 AesCode 32B 的原因，是它是一個能讀取螢幕截圖並寫程式的模型，而你並不需要特別針對美學設計的微調版本，那麼可呼叫的選項確實存在，成本卻只是 GPU 的一小部分。在同一端點底下自動容錯移轉，正是「試試看」與「把正式生產路徑押在上面」之間的差別。

如何真正做出決定

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

接著問你希望輸出是什麼。如果答案是已算繪、可編輯的頁面——一份簡報、一份報告、一個儀表板——North Mini Code 幫不上忙，而 AesCode 32B 是兩者中唯一針對這個問題而來的。進場前請睜大眼睛看清楚：65 GB、24K 上下文、缺乏獨立評估，以及這是一個未公開、下載次數只有兩位數的模型。這是研究性質的發布，而研究性質的發布會獎勵那些有本錢好奇的團隊。

如果答案是要對儲存庫做出變更——無論是遷移、修正，還是多步驟的終端機作業——North Mini Code 就是具備 harness 訓練、256K 視窗、3B 活躍參數部署設定檔，以及對其品質與冗長程度都有外部量測的那一個。要為 token 數量編列預算，而不是只看表面費率。

而如果你本季的代辦清單同時包含一項設計產出物和一次儲存庫移轉，別把它當成雙模型決策來買單，因為它其實是六模型決策。在划算的地方執行專門模型，其餘的則分流處理。

未公佈模型的問題

最後還有一點將這兩者區隔開來，而這並非技術層面的差異。North Mini Code 背後有廠商，發布了模型卡、部落格文章、可供試用的 Hugging Face Space，以及一套可供你質疑的基準測試方法書面紀錄。AesCode 32B 則只有一個儲存庫、一份 README，以及一行寫著「審查中，2027」的引用註記。微軟並未表示它存在。

當你能採用它時，情況就會改變。以 North Mini Code 而言，未解的問題在於它的冗長程度是否會讓它在大規模應用時變得不划算——這個問題你可以透過實際運行它來回答。以 AesCode 32B 而言，未解的問題在於 Microsoft 打算怎麼處理它：這究竟是一項研究產物、一條產品線的首度發布，還是會在六週內被 70B 版本悄悄取代的東西。儲存庫中沒有任何內容能回答這點，再怎麼讀模型卡也無法回答。留意三個訊號——官方公告、對 85.89 的獨立重現，或推論服務供應商採用該檢查點——並將三者皆未出現視為目前的證據狀態，而不是這款模型不值得關注的理由。