AesCode-32B：微軟悄然推出的 33B 模型，能將簡報寫成可編輯的 HTML

AesCode-32B 上的時間戳彼此互相矛盾，而這個矛盾本身就是大部分可供報導的內容。Hugging Face 儲存庫 microsoft/AesCode-32B 建立於 2026 年 9 月 29 日，但其中的所有內容都是在 2026 年 10 月 7 日的一次單一提交中一併出現，提交訊息僅為「Release AesCode-32B」——而讓這項成果得以重現的訓練堆疊則是在 10 月 8 日被推送到 github.com/microsoft/AesCode。微軟什麼都沒宣布：沒有部落格文章、沒有 arXiv 預印本、沒有排行榜提交、自家網站上也沒有模型頁面。實際存在的是：一個 330 億參數的視覺語言模型，接收提示後會輸出一份完整、自成一體的 HTML 文件——一張簡報、一張海報、一個儀表板——外加一個較小的搭配模型，microsoft/AesCode-8B。兩者都是從 Qwen3-VL 視覺模型微調而來——分別是 Qwen3-VL-32B-Instruct 與 Qwen3-VL-8B-Instruct——兩者皆採 Apache 2.0，而且今天就能下載。

這個儲存庫 ID 寫的是microsoft/AesCode-32B，而模型卡一開頭就點出訣竅：AesCode 會把你的提示詞與一張由同一個提示詞生成的圖像配成一對，以該圖像作為美感參照，並依照文字來決定實際內容。圖像生成器能構築出漂亮的頁面，卻會把頁面上的數字畫錯；程式碼模型能把數字弄對，卻看不見頁面長什麼樣子。AesCode 試圖兩者兼得；而截至 2026 年 10 月 11 日，對它最誠實的總結是：權重是真實且可查核的，基準測試數字是該實驗室用自己撰寫的測試框架跑出來的自家數據，而且微軟以外還沒有人發表過它的任何數字。本文從頭到尾都把這三個類別涇渭分明地區分開來。

儲存庫裡實際上究竟有什麼，逐位元組來看

先從不需相信模型卡任何一句話就能驗證的內容開始。這個 32B 儲存庫包含十四個 safetensors 分片，總計 66,714,912,704 位元組，以 BF16 計算約為 334 億個參數——這與模型卡上的「33B 參數」及其警告「光是權重本身就需要約 65 GB 的加速器記憶體」相符。設定檔宣告 Qwen3VLForConditionalGeneration 為架構qwen3_vl 為模型類型，所以這不是新架構，也不需要新架構：它可透過 transformers=4.57 載入，而模型卡附帶一個 vLLM 指令，能讓它以四個張量平行方式提供服務，允許兩張圖片，並有 24,576 個 token 的上限。

這次發布中最安靜的部分，就是互動計數。在撰寫本文時，這個 32B 儲存庫有兩次下載和一個讚。Hugging Face 的推論供應商對應表中沒有它的條目，意味著儲存庫頁面背後沒有接上任何託管端點，而且各處也都沒有宣傳 GGUF、MLX 或 llama.cpp 版本。對於一個掛著微軟名號、且在該廠商自家表格上打敗 GPT-5.5 的模型來說，這樣的足跡小得驚人——而這也是現有最有力的證據，顯示它是在背後沒有發布活動的情況下上線的。

配套的程式碼儲存庫補上了時間軸的另一半，而發布日期問題真正變得模稜兩可的地方就在這裡。microsoft/AesCode建立於 2026 年 7 月 23 日——比權重早十週——共有十四次提交，每一筆都由同一位貢獻者撰寫，而且每一筆的時間戳都落在 2026 年 10 月 8 日彼此相差二十秒之內，介於 UTC 23:14:04 與 23:14:24 之間。內容包括用於產生提示與可驗證需求的規格、建構設計圖與評分規準問題的資料管線、冷啟動 SFT 階段、GDPO 強化學習迴圈、以 Playwright 為基礎的渲染驗證器、測試，以及記錄上述一切的 README。該儲存庫沒有發布版本，也沒有標籤，描述欄位是空的，而且只有一顆星。

所以，發布日期到底是哪一天？儲存庫紀錄說是 9 月 29 日。承載該模型的提交紀錄說是 10 月 7 日。說明該模型如何製作的程式碼說是 10 月 8 日。三個時間戳記落在同一個兩週區間內，卻沒有任何一個附上 Microsoft 說「我們要發布這個」的一句話。對於大多數人實際上會下載的產出物，請把 10 月 7–8 日當作生效日期，並把 9 月 29 日當作該儲存庫被保留的日期。任何告訴你 AesCode-32B 在某個特定日子「推出」的人，都是在替你從那些時間戳記中選一個。

機制：圖像作為美學引導，圖表作為獎勵

該卡片的技術主張範圍狹窄且具體，這是對它有利的一點。該模型先以冷啟動監督式微調在 3,000 個示範上進行訓練，學習率為 1e-5，然後使用 GDPO——一種群組相對策略優化變體——在 7,408 個提示上訓練 520 步。8B 模型使用了相同的配方，並在 400 步時停止。RL 運行使用了 verl 的 FSDP-vLLM 混合引擎，沒有 critic 也沒有單獨訓練的獎勵模型，AdamW 以恆定的 5e-6 且無預熱，每步 128 個提示，每個提示八次 rollout，提示和回應各自上限為 8,192 個 token。

這項獎勵與眾不同之處在於，它不是單一純量。每個訓練目標都被描述成涵蓋整個畫布的設計圖，因此個別屬性可以被分別歸因。從該圖產生七個通道——執行、文字、邊界、表格圖表、版面、留白與設計——每個通道在聚合前都會先在其 rollout 群組內正規化，以免某個主導訊號淹沒其他訊號。確定性驗證器會為可從程式碼及其呈現中解析出的部分評分；視覺語言評審則使用與該圖自身元素和關係綁定的評分規準，為無法解析的部分評分。候選 HTML 的評分方式，是在封鎖外部請求的沙箱 Playwright 瀏覽器中渲染它，並匯出 DOM、計算樣式、邊界框、主控台狀態與螢幕截圖。

這項工程後果值得說明，因為它會顯現在你所收到的輸出中：該模型被訓練成將表格輸出為真正的 HTML 表格結構，並將圖表輸出為 ECharts 規格，因此兩者都可直接檢視，而非被烘焙進像素之中。這正是你能交給設計師的簡報，與你能交給 linter 的簡報之間的差別。相應地，重現要求也相當沉重——README 要求 Python 3.10、CUDA 12.6，以及一個配備八張 B200 GPU 的節點，並鎖定特定的 verl commit，且明白指出必須對其套用修補程式，因為原版 verl 缺乏 Qwen3-VL 支援；同時警告若缺少 Playwright 系統函式庫，瀏覽器會在啟動時失敗，頁面將得零分；若缺少所鎖定的 OCR 堆疊，對應的獎勵通道會回傳零而非棄權，並在無聲無息中汙染訊號。

基準表，以及寬鬆看待它的四個理由

AesCode-32B 的主要數據來自 300 個資訊圖表樣本，每個提示詞在 temperature 0.8 與 top-p 0.95 下生成三次，每次最多輸出 12,000 個 token，且不從這些生成結果中進行挑選。分數以百分比表示。在有參考條件下，32B 模型回報文字 95.34、邊界 97.27、表格/圖表 90.37，以及規則平均 94.33；在視覺方面，內容 85.76、版面 90.58、風格 55.99，視覺平均為 77.44，整體為 85.89。在同一張表中，有參考的 GPT-5.5 整體得分 81.28，有參考的 Claude Opus 4.8 整體得分 80.39，而該模型訓練所依據的 Qwen3-VL-32B-Instruct 骨幹則得分 61.10。

有四點必須與這些數字同時說明，而它們沒有一點是在抹黑這項工作。第一，每一列——包括 GPT-5.5 與 Claude Opus 4.8 的那幾列——都是由微軟以自家測試框架、自家評分標準跑出來的；那些不是其他實驗室的數字，而是微軟對競爭對手模型的測量值，而且該評分卡本身便稱這套評分標準對每張設計圖而言是「個別樣本專屬」的。第二，這套評分標準是由產出訓練資料的同一條流程所製作，而這正是基準測試可能朝某個模型強項漂移的情境；評分卡對該評分標準的局限相當坦率——風格一項要求設計在交付前不需再做任何視覺修改，被稱為「每個系統的共同天花板」，而表中沒有任何模型突破 60。第三，這個模型在任何地方都沒有獨立測量：沒有第三方排行榜登錄、沒有複現，而且從下載次數僅兩次來看，實驗室外幾乎肯定還沒有人在跑它。第四，這項比較以一種值得注意的方式微妙地不對稱——AesCode-32B 的所有列都是有參考條件的，因此該模型是在它當初受訓所針對的配置下被測量，而評分卡也藉由顯示有提供參考時品質仍舊最高，承認了這一點。

表中唯一比標題更站得住腳的結果，是一項穩健性主張，而非品質主張。在推論時不提供參考圖，AesCode-8B 僅損失 1.00 個視覺分，相較之下，其 Qwen3-VL-8B-Instruct 主幹為 19.55，GPT-5.5 則為 10.04。該模型卡的主張是：以參考圖為條件的訓練會將視覺規劃內化到策略中，而不是教模型複製它所看到的內容。這一點由廠商報告且未經重現，而這也正是單一次獨立執行就能定論的那類主張——也是在生產環境中最要緊的那類主張，因為你不一定總能隨手取得參考圖。

運作成本是多少，以及這對比較有何意義

這個模型的自架成本一點都不便宜。單一產出成品的工作規模就是一萬到一萬二千個輸出 token，而一份含有 ECharts 規格的完整 HTML 文件，更是接近這個範圍的上限而非下限，因此每一次生成都是一段漫長的解碼過程。這張卡本身的推論部署配方要求用四張 GPU 做張量平行，才裝得下大約 65 GB 的 BF16 參數，而訓練配方則要求八張 B200。那是貨真價實的機器，不是業餘玩票的部署，而這也界定了比較的前提：AesCode-32B 被拿來對比的那些模型是按 token 計費租用的，而這個模型本身則是按 GPU 小時計費租用的——無論硬體是不是你自己的都一樣。

那個比較的實際形態，正是路由層存在的意義所在，而我們確切說明自己代管與不代管什麼，是值得的。AesCode-32B 不在 OrcaRouter 的目錄中，我們也不提供它——在我能查證的任何地方，都沒有它的代管端點，包括 Microsoft 在內。目錄上的是桌子的另一邊：你會用來對照自託管構件生成器的代管模型，包括 GPT-5.5 以及 較小的 Qwen3-VL 視覺模型，可透過單一 API 金鑰、以供應商定價且 0% 加成取得，這表示 供應商價格變動當天就會在我們這邊生效。將租用的端點與你自己執行的模型相比，不需要第二份合約或第二個 SDK，而路由 DSL 能讓自託管呼叫與託管呼叫並列於單一端點之後。如果 AesCode-32B 最後真的擅長它模型卡上宣稱的那一件事，弄清楚這件事的代價是一筆 GPU 帳單，而你拿來與它比較的替代方案，代價則是你大概早就擁有的一把金鑰。

你目前可以用它做什麼，以及什麼尚不存在

• 下載並執行它——權重採用 Apache 2.0 授權，並以 Qwen3-VL 為骨幹，內含十四個 BF16 分片，以及可在 transformers 4.57 版以上運作的路徑，還有模型卡中的 vLLM 配方。

• 重現這項訓練 —— 程式碼採用 MIT 授權，且完整到足以具有實質意義：獎勵驗證器、評分標準建構器、SFT 與 GDPO 階段、一個固定版本的 verl commit 以及加入 Qwen3-VL 支援的修補程式，還有一份列出各種失效模式、而非將其藏起來的 README。

• 以無參考方式評估它——模型可接受帶有或不帶參考圖片的提示，而這張卡片最可測試的主張正存在於該配置中。

• 想取得它的 API——你辦不到。它沒有託管端點，儲存庫上也沒有推論供應商對應設定，更沒有 GGUF 或 MLX 建置；要執行這個，就等於要跑硬體本身。

• 讀那篇論文——你目前還讀不到。這張卡片連結了一篇題為AesCode: Aesthetic Code Generation with Decoupled Cross-Modal Rewards的論文，而它自己的 BibTeX 條目把發表場合列為「Under review」、年份列為 2027。在 arXiv 上搜尋，找不到任何以此為標題的論文。另有一篇更早、名稱幾乎相同但並不相同嘅微軟論文——Code Aesthetics with Agentic Reward Feedback，發表於 2025 年 10 月，該論文釋出了 AesCoder-4B 模型與 AesCode-358K 資料集——而 AesCode-32B 的卡片中沒有任何內容引用它，也沒有說明與它的關係。如果你去找背景讀物，最後找到的卻是那一篇，那你讀到的是另一個由部分重疊的作者所打造的模型。

• 在公開排行榜上比較它——尚未。似乎沒有第三方索引評估過它，而對於一個只有兩次下載的儲存庫來說，這並不令人意外。

誰應該在意，而誰應該等待

這個模型的受眾比標題表格所暗示的更狹窄，也比「任何用模型來開發的人」更明確。如果你的產品是把提示詞變成簡報、海報、報告或儀表板，而之後還得有人去編輯它，那你早就發現了這個模型所瞄準的抉擇：圖像生成給你一個漂亮卻改不了的矩形，而程式碼生成給你一個可編輯、但看起來像是編譯器拼裝出來的東西。一個 33B 的開放權重模型，能輸出一份含有真實表格與 ECharts 規格的完整 HTML 文件，在你沒有參考素材可提供時仍能維持與其參考條件品質相差約一個百分點的水準，而且你可以在 Apache 2.0 之下用自己的品牌風格對它進行微調——這樣的東西存在，確實是件真正有用的事。在這個規模、這些條件下，沒有其他模型做得了這件確切的工作。

但話說回來：你所知道關於品質的一切，都來自供應商自己做出來的一張表；那張表背後的評分標準，是由產出訓練資料的同一條流程所製造；而這張模型卡唯一承認的天花板——所有受測系統的風格（Style）分數都低於 60——恰恰是設計敏感的產品最在意的那個維度。一個有合規理由要把生成留在自家內部、手上又有一台閒置八 GPU 節點的團隊，今天就有足夠條件開始。至於下週就要為正式環境挑選模型的團隊，則沒有任何獨立數字可據以選擇，也不該把 85.89 對上 81.28 解讀成已成定論的結果。

什麼能讓這變成一個故事？

四件事，而這些目前都還不存在。一則公告——微軟什麼都沒說，而這張卡所引用的論文明確標示為審查中，因此一份包含卡上摘要以外訓練細節的技術報告，隨時都可能出現。一次獨立測試——無參考基準的穩健性主張，以及 Boundary 分數（卡上說它在 4.3% 的樣本上跌至嚴重失敗，而 GPT-5.5 為 34.7%），兩者測試成本都低，也都值得測試。在供應商既有做法之外的部署支援——一個 GGUF 版本或主流執行環境的收錄，對硬體故事的影響會比任何基準測試都大。還有關於規模問題的第二個資料點：在同一張表上，8B 模型拿下 82.94 的 Overall，對比 32B 的 85.89，這是以四分之一參數換來的兩分差距，而這種事要不是被複現，就是悄悄不再被提起。

在其中一項成真之前，對 AesCode-32B 的準確描述是這樣：在寬鬆授權條款下釋出的真實權重、一套詳細到足以讓設備完善的實驗室重現的訓練堆疊、一張基準測試表——那是某家公司對自家模型與兩家競爭對手模型的測量結果——以及一段不會讓你將任何單一天稱為發布日的版本庫歷史。它是一件比其兩次下載計數器所暗示的更有趣的產物，也是一件比其 85.89 所暗示的更未經證實的產物。那句話的兩半都是對 2026 年的誠實解讀。