AesCode 32B 對決 Qwen3.8 27B：Microsoft 以 Qwen 為基礎打造它，而其中一個可呼叫

重新組織這整個比較的細節，就在模型卡的第二行：AesCode 32B 是從 Qwen3-VL-32B-Instruct 開始的。微軟這個針對設計領域的程式碼模型是 Qwen3-VL 的微調版本，採用 Apache 2.0，放在一個建立於 2026 年 9 月 29 日的 Hugging Face 儲存庫上，其提交標題為「Release AesCode-32B」，日期為 2026 年 10 月 7 日，而微軟在任何地方都沒有發布公告。Qwen3.8 27B 是那條血脈的另一端：該廠商自家的開放權重 27B 稠密多模態模型，於 2026 年 8 月 14 日在 Apache 2.0 下釋出，是微軟所微調之 VL 檢查點的後繼架構。所以這不是兩家廠商旗艦成果之間的對決。這是一個實驗室的通用開放權重模型，與競爭對手對該家族所做的研究微調之間的對決，而兩者之間的實際差異，到頭來幾乎完全取決於你取得檔案後被允許對它做什麼。

相同的授權，相同的系列，不同的模型數量

兩者皆為 Apache 2.0，兩者都接受圖像與文字，也都回傳文字。在那之後就各走各的路，而部署這一列的分歧最大。

• 參數 — AesCode 32B：33B 稠密模型，基於 Qwen3-VL-32B-Instruct。Qwen3.8 27B：27B 稠密，計入視覺編碼器後為 28B，64 層，隱藏大小為 5120。

• 執行所需的記憶體——AesCode 32B：這張卡建議光是 bf16 參數就要規劃約 65 GB 的加速器記憶體，而且它自家的serving範例採用四路張量平行。Qwen3.8 27B：bf16 下約 55.6 GB。

• 上下文 — AesCode 32B：在所報告的配置中為 24,576 個 token，訓練時的提示與回應上限為 8,192。Qwen3.8 27B：原生支援 262,144 個 token，可透過 YaRN 擴展至 1,000,000。

• 注意力 — AesCode 32B：繼承自 Qwen3-VL 主幹。Qwen3.8 27B：混合式，48 層 Gated DeltaNet 線性注意力層對 16 層全注意力層，比例為 3:1，這使得 262K 視窗的服務成本變得可負擔。

• 用途 — AesCode 32B：生成資訊豐富的視覺成品，成為可編輯的 HTML 與 CSS，以及多模態程式碼生成的研究。Qwen3.8 27B：通用的代理式與多模態工作 — 程式編寫、電腦操作、文件與影片理解、工具呼叫。

• 取得方式 — AesCode 32B：從 Hugging Face 下載；沒有推論服務供應商部署它。Qwen3.8 27B：權重，或代管端點。

兩倍的上下文、略小的佔用空間、新了一代的骨幹，以及完全相同的授權條款。AesCode 32B 唯一徹底勝出的那一列就是第一列，而它是在特定任務的微調上勝出。

每一項實際上是依據什麼來衡量的

這兩套評估制度互不相干，而假裝並非如此，正是像這一頁這類頁面上常犯的典型錯誤。

Qwen3.8 27B 的模型卡既全面又具體。程式編寫：Terminal-Bench 2.1 為 73.0，SWE-bench Pro 為 61.7，QwenSWEBench 為 79.0，LiveCodeBench v6 為 90.3。推理：GPQA Diamond 89.2，Humanity's Last Exam 30.8。電腦操作：OSWorld-Verified 84.3，WebArena-Verified 64.8，AndroidWorld 81.9。視覺：在廠商的推論時增強下，MathVision 為 94.6，未使用時為 90.0，OmniDocBench 1.5 為 91.1。這些全都是廠商在自家測試框架上得出的自家數據——但有個值得一讀的註腳：SWE-bench Pro 與 QwenSWEBench 的測試使用了 Claude Code 測試框架，因此無法與採用不同框架評分的模型直接比較。

AesCode 32B 只有一項基準測試，而且是單一用途的：300 個資訊圖表樣本，每個提示進行三次生成且不進行挑選，在七個通道上渲染並評分。在提供參考圖片的情況下，其主要結果是總體 85.89，相較於相同測試框架下 GPT-5.5 的 81.28 與 Claude Opus 4.8 的 80.39——此外還宣稱 AesCode 32B 在視覺維度上以 22.4 分、總體上以 24.8 分擊敗其自身的 Qwen3-VL-32B 主幹模型。

把它們並排放在一起，根本什麼都對不上。Terminal-Bench 衡量的是 shell 任務是否完成；AesCode 評估衡量的則是資訊圖表的文字是否清晰可讀、版面是否不會超出畫布，以及它的表格是否為真正的 HTML 表格。沒有共用的指標，沒有共用的測試框架，也沒有共用的任務。唯一誠實的說法是：AesCode 32B 在設計產出方面遠比它自己的骨幹模型優秀，而 Qwen3.8 27B 是一個強大的通用模型——而這兩種說法都無法告訴你關於另一者的任何事。

這次的證據是真的，而且是單向的

在這產業裡，廠商基準測試是常態，因此這兩者在「其廠商宣稱有多少已由其他人查核」這一點上有所不同，而這很重要。

Qwen3.8 27B 推出時附帶了供應商自家的表格，並在幾週內累積了外部結果。該模型的獨立紀錄包括由法律 AI 公司 Harvey 與記憶體新創公司 Engram 共同進行的一項法律代理研究，其中一款經過調適的 Qwen3.8 27B 在 250 項法律任務上領先該研究測試的每一個模型，包括 Claude Opus 4.8——但有一個重要但書：該調適版模型事先研讀了受測律師事務所的 1 億 token 語料庫，因此這項結果既是關於模型的，也同樣是關於調適的。它也包括在 Code Arena 的 WebDev 排行榜上的一個名次，以及在 Arena.ai 的 Image-to-WebDev 排行榜上的開放權重第一名，這兩者都是廠商轉述的排名說法，而非已發布的方法論。它還包括一個有公布分數的第三方排行榜：Artificial Analysis 在其 Intelligence Index 上將 Qwen3.8 27B 記錄為 33.70，每完成一項任務的成本約為 1.01 美元，並公布了其背後的 token 細目。

AesCode 32B 完全沒有這些。沒有競技場排名、沒有排行榜收錄、沒有第三方重現、沒有獨立的輸送量測試——而這並非因為有人查看後發現它有所不足，而是因為一個沒有任何供應商提供的檢查點，從一開始就無法由外部測試框架評估。它的數字來自廠商，由訓練該模型的同一套驗證器堆疊計算，使用廠商挑選的樣本，對照廠商自己跑出來的基準。這次發布在方法上異常透明——獎勵通道名稱、rollout 次數、解碼參數與失敗率全都公開了——但對某個數字如何產生的透明，並不等同於由別人產生出這個數字。

那個需要綁定信用卡的

這就是血統不再只是冷知識，而開始成為決策本身的地方。

AesCode 32B 要求你提供 65 GB 的加速器記憶體、一條多模態服務路徑，以及願意以早期採用者身分執行一個未公開的模型。它自身的服務範例需要四路張量平行處理，而該模型的文件記載支援 24,576 個 token 的上下文，且沒有託管選項可供退而求其次。如果你已經擁有硬體，而且你的流程確實需要針對特定設計進行微調，那這是合理的取捨。對大多數團隊而言，在產生第一個有用的輸出之前，這會是為期兩週的專案。

Qwen3.8 27B 自託管於 OrcaRouter 自家的基礎架構上，今日即可呼叫，每百萬輸入 token 收費 0.33 美元、每百萬輸出 token 收費 2.40 美元，具備 262,144 token 的上下文，並支援文字、圖像與影片輸入。這些都是牌價原樣轉傳，我們這端不加收任何加成，而且它與其他 200 多個模型共用同一把金鑰，因此要與目錄上任何替代方案比較，只需更動一個請求參數，而非另簽一份合約。這就是實務論據的全部，而且這論據分量十足：以家族系譜而言落後 AesCode 32B 主幹一個世代的那個模型，正是你今天下午就能用自家提示詞、以幾美分的代價實際評估的那一個。

這裡有一個第二層次的論點，而路由的角度讓它變得具體。因為 AesCode 32B 是 Qwen3-VL 檢查點的微調版本，這個家族提供你一個低成本的方法，在投入任何自架部署之前，先測試架構的代管端究竟能不能運作。Qwen3-VL 235B A22B Instruct 的價格是每百萬輸入權杖 $0.40、輸出 $1.60，而 Qwen3-VL 8B Instruct 則是 $0.18 與 $0.70。兩者都不是 AesCode 32B，也都沒有為了設計品質而訓練——但「視覺語言模型能不能讀取我們的螢幕截圖，並寫出我們需要的標記」這個問題，用它們花幾美分就能回答，而且同一個端點底下的自動容錯移轉，意味著供應商出狀況的一天不會讓整條管線掛掉。

誰應該選哪個

如果產出物本身就是交付項目，就選 AesCode 32B。你大量製作投影片、儀表板、海報或報告，需要維持可編輯與可 diff 的結構化輸出——該模型會輸出完整的 HTML 文件，使用真正的 HTML 表格結構與 ECharts 規格，讓兩者都保持可檢視——而且你有硬體或預算可以租用它。採用前要接受三件事：任何數字都無法獨立驗證、權重約 65 GB，以及 24K 上下文長度會限制長文件。模型卡回報的 4.3% 嚴重畫布邊界失敗率，對比 GPT-5.5 的 34.7%，是這次發布中最令人振奮的單一數字，而且它也是 Microsoft 的。

如果你需要一個真正跑得動、也真正能提供服務的通用開放權重多模態模型，就選 Qwen3.8 27B。262K 上下文，可擴展到一百萬；部署佔用能適用於 AesCode 32B 無法勝任的環境；授權條件並無不同；其品質與每完成一項任務的成本都有一些獨立評測；還有託管方案，意味著你今天就能開始使用，之後再自行託管，而不必改寫整合。它分階段、逐層的注意力設計，正是長上下文得以負擔的原因，而長上下文正是設計與文件流程最常需要的東西。

而如果你兩者都需要——一個設計產物生成器和一個通用主力——合理的分工並不是在你自己的設備上跑兩個 30B 級的視覺語言模型。將一般流量導向託管端，並讓專業模型維持自架，置於同一把金鑰之後；如此一來，任一路徑的供應商中斷都會是容錯移轉事件，而不是事故。

值得關注的事情

AesCode 32B 的地位，一旦它變得可供呼叫，就會徹底改變。目前這個模型唯一真正的弱點在於取用管道，而那是暫時性的狀況——只要有推論服務供應商採用這個檢查點，或微軟發布端點，就能把一樁 65 GB 的採購案轉變成單純的模型選擇。在那之前，對這場對決最誠實的總結是：這個微調版本在某單一任務上表現更好，通用模型則更擅長「可用」這件事，而通用模型恰好是它的祖先：微軟選擇以 Qwen3-VL 檢查點為基礎來打造，是因為它是當時可取得最強大的開放多模態基礎模型——而這本身正是這場比較能給出關於 Qwen3.8 27B 最有用的結論。