AesCode 32B 對決 Qoder Cantus：一個能檢視，一個能運行，兩者無法兼得

這裡有個值得玩味的反轉。AesCode 32B是微軟的 HTML 與 CSS 生成檢查點，也是同類模型中可檢視程度最高的一個：權重以 Apache 2.0 授權放在 Hugging Face 上，公開的儲存庫裡包含獎勵驗證器、評分標準建構工具與訓練迴圈，一份完整刊出的 300 筆樣本評估，以及一份詳細到學習率與 rollout 步數的訓練配方。它的 Hugging Face 儲存庫可追溯至 2026 年 9 月 29 日；名為「Release AesCode-32B」的提交於 2026 年 10 月 7 日落地；微軟對此隻字未提。而且幾乎沒有人跑得動它，因為它是個 33B 的檢查點，需要約 65 GB 的加速器記憶體，而沒有任何服務供應商提供它。Qoder Cantus則恰恰相反。它今天就能在 Qoder 內運行，只要你有訂閱——而你完全無法檢視它。Qoder 對這個模型所發布的全部說明就只有一句話：沒有參數、沒有上下文視窗、沒有基準測試表，也沒有權重；而且由於沒有 API，永遠不會有第三方數字。一個模型什麼都告訴你，卻什麼都不讓你做。另一個讓你什麼都能做，卻什麼都不告訴你。有趣的問題是：哪一種失敗模式讓你付出更多代價。

文件所說的內容，全文

要看出這種不對稱，最簡單的方式就是直接引用現有的內容。

在 AesCode 32B 上，公開紀錄包含：基礎模型（Qwen3-VL-32B-Instruct）、參數量、授權條款、預期用途、訓練資料量、SFT 學習率、RL 優化器設定、獎勵通道名稱、提示數與步數、評估樣本數、每個提示的生成次數、解碼溫度與 top-p、評分所用的上下文長度、三份各自發布的結果表，以及對一篇列為審查中的論文的引用。它未包含發布日期與達到兩位數的下載次數——而模型卡註明它需要 transformers>=4.57，且頁面上自動產生的使用片段與模型卡自身範例不一致，這種細節只有在成品真實存在時才會存續。

關於 Qoder Cantus，公開記錄是：「Qoder 內建的頂級智慧模型，擅長執行長時間的自主任務。」這就是描述。沒有模型卡，因為沒有模型可下載；沒有基準測試表，因為 Qoder 並未發布任何發布貼文或技術報告；也沒有競技場收錄，因為競技場需要有可呼叫的端點。其他已知資訊屬於結構性而非技術性：Cantus 出現在 Qoder Desktop、JetBrains 外掛、CLI、Cloud Agents 與網頁用戶端的模型選擇器中，並透過 Qoder 的點數系統計費，且會對該模型的使用量套用係數。

那不是對模型的批評。那是在描述能被查核的內容，而對 Cantus 而言，答案是什麼也沒有。

各自真正強大之處

AesCode 32B 的優勢在於可驗證性，而這一點非同尋常，值得解釋，而不是只是斷言。訓練訊號不是單一分數——而是七個通道，其中六個是確定性驗證器，會從輸出的程式碼及其渲染結果中讀取屬性，再加上一個視覺語言評判器，依據與每個樣本設計圖綁定的評分標準，為無法解析的屬性評分。每個候選項都會在封鎖外部請求的沙箱化 Playwright 瀏覽器中渲染，並匯出 DOM、計算樣式、邊界框、主控台狀態與螢幕截圖。由於每個屬性都可歸因，實驗室可以回報：它相較於自身的 Qwen3-VL-32B 主幹模型，將 Visual 元件提升了 22.4 分，並告訴你訓練結束時哪些通道仍在攀升。這是一個你可以質疑、重現或擴充的發布。

成本同樣明確。這張模型卡建議光是 bf16 參數就要規劃大約 65 GB；其服務範例採用四路張量平行；所報告的數字使用 24,576 個 token 的上下文；在強化學習期間，提示與回應的上限為 8,192 個 token。把這一點對照以下事實：沒有任何推論供應商部署該檢查點，而障礙並非哲學層面的。你要嘛自己擁有硬體，要嘛租用硬體，而且多模態服務路徑得由你自己打造。

Cantus 的優勢恰恰相反：它就是在那裡。無需下載、無需 GPU、無需推論服務堆疊，也無需挑選執行框架。它會出現在你已經在使用的 IDE 模型選擇器中，而且它的定位正是代理式編碼工具所標榜的賣點——長時間自主執行任務。無論它還有什麼其他不確定之處，部署問題已經替你解決了，而 Qoder 想必對自己所打造的模型了解得比已公開的更多。

關於 Cantus，你無法回答的三個問題

值得精確地說明缺少文件所付出的代價，因為「沒有基準測試」這種說法低估了實際情況。

• 它有多大——未知。參數數量並未公開。在以點數計費的模型上，這可不是無關緊要的小事：它是判斷一項在其他地方花你 2 美元就能完成的任務，是否在這裡只能以 6 美元完成的主要依據。

• 它能容納多少上下文——未公開，第三方討論暗示可能在 200K 左右，且沒有來源。長時程代理式工作的存亡取決於這個數字，而它並未公開。

• 它到底好不好——嚴格來說，無法回答。Qoder 的論點隱含在其定位之中：長時間自主執行，最好用模型如何處理上下文、復原，以及數百次工具呼叫來衡量，而不是用單輪程式編寫分數來衡量。這是個合理的論點。如果這個模型可以被測試，這個論點會更有力；但它無法被測試，因為 Qoder 之外的任何東西都無法呼叫它。

把這與第三題在 AesCode 這一側的鏡像對照相比：數字確實存在且詳盡，但那些是微軟的數字，由微軟的測試框架在微軟的 300 個樣本上產生，且沒有任何外部實驗室重現過其中任何一項。AesCode 32B 在其自身的風格維度上有 55.99 的文件記載上限，以及 4.3% 的嚴重畫布邊界失敗率——兩者皆由廠商公布——且沒有獨立確認可證明這兩個數字中任何一個是正確的。所以這兩種失效模式是：無法信任的數字，以及沒有數字。這比「一個好、一個壞」更糟，而這正是這場對決實際呈現的選擇。

每一方各自要你付出的代價

Cantus 是透過 Qoder 的點數系統計費，而非依公告的每 token 費率。Qoder 會對模型的使用量套用一個係數，而 Cantus 上線時的倍率為 3.2 倍，之後在持續至 2026 年 7 月 31 日的五折優惠下調降為 1.6 倍。若依 Qoder 本身公告的點數估算（而非任何每 token 的數字——Qoder 從未針對 Cantus 公布過這樣的數字）來重建，這相當於編輯模式下每回合約 $0.38、每個 Quest 任務 $1.60，以及 Experts 模式下每個 Quest $2.40。這些都是重建推算的數字，之所以如此標示，是因為沒有第一手來源能提出不同說法。

AesCode 32B 的成本是一筆資本支出數字，而非按單位計價的費用。權重在 Apache 2.0 下是免費的，而帳單則以 GPU 小時的形式到來——需要 65 GB 的加速器記憶體來容納參數，再加上視覺塔，再加上你所需的任何吞吐量。如果你本來就已經為了其他工作運行 B200 等級的節點，那麼邊際成本幾乎為零。如果你沒有，那麼誠實的比較並不是「每百萬詞元 0 美元」對上 Qoder 的額度；而是硬體決策對上訂閱方案。

可組合性的差異

存取模型還有一個後果，而這是路由平台最先注意到的那一個。

Cantus 無法與任何東西組合。沒有 API 就意味著沒有備援、無法針對同一項任務與另一個模型做 A/B 測試、無法在請求進行到一半時從便宜模型串接到昂貴模型，也無法將它納入你自己撰寫的評估框架之中。它就只是單一產品裡的一個選項，而你唯一握有的槓桿就是選擇器。這是 Qoder 刻意做出的設計選擇，若你想長居在 IDE 裡，這也完全合理——但這意味著你的架構會承襲 Qoder 的發展藍圖。

AesCode 32B 在理論上具有相反的性質，在實務上則有落差。權重意味著它可以部署到任何地方：你的叢集、租用的執行個體、你自己的工具、你自己的評估。它目前無法做到的是被呼叫，因為沒有供應商提供服務——微軟發布了檢查點後就止步於此。因此，結構上可組合的模型在實務上尚不可組合，而實務上可用的模型則在結構上被鎖定。

這樣一來，路由的論點就比平常更狹窄，值得誠實說明：這場對決中的兩個模型都不在我們的目錄中，而本頁也不會假裝不是如此。單一端點以供應商標價提供 200 多個模型，在這裡真正帶來的其實是周邊那一層——能夠打造取用 AesCode 32B 輸出的工作流程，並將其應由通用模型處理的部分進行路由，而不必為每一項另外簽訂第二份合約。若你想在投入自架的視覺語言部署前先測試那一層，最便宜的方式是使用同一系列中可呼叫的模型：AesCode 32B 是 Qwen3-VL-32B-Instruct 的微調版本，而Qwen3-VL 235B A22B Instruct 的價格為每百萬輸入 token 0.40 美元、輸出 1.60 美元，較小的Qwen3-VL 8B Instruct 則為 0.18 美元與 0.70 美元。那些是不同的模型，並非這個微調版本的替代品——但它們能以幾美分而非 65 GB 回答「託管的 VLM 能否讀取這張截圖並寫出足以供我們流程使用的程式碼」，而且若答案是肯定的、流量也變得真實，跨供應商的容錯移轉就位於同一把金鑰之下。

如何選擇

如果你已經身處 Qoder 之中、你重視不必做基礎設施工作，而且願意為此付出無法驗證的代價，那就選擇 Cantus。請清楚意識到，你買的是一項能力，而不是一個模型：你無法在採用前對它進行基準測試，無法以每 token 為基礎將它的價格與任何東西比較，而且如果 Qoder 改變其定價或路線圖，你也無法把它帶走。

如果你需要那個成品，而且負擔得起部署，就選擇 AesCode 32B——特別是當你需要一個能產生可編輯 HTML、讓你進行差異比對、審閱與交付的模型。也要同樣務實看清：它未經發布、未經重現、對大多數硬體而言太大，而且文件記載的是 24K 上下文，這將限制長篇文件。

如果你既不想被第一種方案綁死，也不想承擔第二種方案的資本支出，那麼最誠實的做法，就是從一個你隨時能呼叫的模型取得同樣的能力。一個藏在 API 金鑰後面的視覺語言模型，能讀懂螢幕截圖並寫出結構化標記。它不會用七條為設計品質調校過的獎勵通道來訓練，在 Microsoft 建置的資訊圖表基準測試上也比不上 AesCode 32B。但它要你付出的代價，是存檔的一張信用卡，而不是採購一顆 GPU；而且你能夠自己測量它——而這正是整場對決的重點所在。

看什麼

Cantus 要等到 Qoder 公開端點或釋出權重的那一天，才會成為一個正常的模型；在那之前，關於它的每一項說法，都是關於 Qoder 產品的說法，而不是關於某個模型的說法，而且證據落差是結構性的，不是文件疏漏。AesCode 32B 要等到推論供應商採用該檢查點，或外部實驗室重現 85.89 的那一天，才會成為一個正常的模型——而如果這件事與 Microsoft 真的宣布那個東西同時發生，那麼 65 GB 門檻就是唯一剩下的那一個。無論哪一個先落地，都能告訴你：這個產業已決定不再容忍這兩種失敗模式中的哪一種。