AesCode-8B 悄然推出：微軟的 8B 模型以 HTML 撰寫簡報與儀表板

微軟這次新發布中最有意思的數字是 1.00。若不提供參考圖像給 AesCode-8B——這是一個 80 億參數的模型，能把投影片、海報和儀表板寫成可編輯的 HTML 與 CSS——它的視覺分數就會下降百分之ㄧ。同樣不提供參考圖像給 Qwen3-VL-8B-Instruct——AesCode-8B 正是從這個開放權重模型微調而來的——降幅則是 19.55 分。至於 GPT-5.5，降幅是 10.04 分。真正的研究成果就藏在這一組比較裡，而它位於微軟同時發布的另一項標題之下：在其自家 300 個樣本的評分標準上，AesCode-8B 的整體得分 82.94 微幅勝過有參考圖像輔助的 GPT-5.5（81.28）與 Claude Opus 4.8（80.39），而體型更大的同門模型 AesCode-32B則拿下 85.89 分。

這次發布完全沒有對外公告。微軟在 2026-10-07 以 Apache 2.0 授權把權重提交到 Hugging Face——AesCode-8B 以及一個以相同方式從 Qwen3-VL-32B-Instruct 建構而成的 32B 伴生模型——並在隔天把訓練與評估程式碼推上 GitHub。沒有微軟研究院的部落格文章，沒有發布說明，沒有產品頁面，也沒有預印本：模型卡中的引用寫著「審查中」，年份 2027，那是佔位符，而非日期。截至 2026-10-11，8B 儲存庫顯示兩次下載與一個讚；GitHub 儲存庫顯示一顆星。以下凡是帶有數字的內容，要嘛是你可以自行查證的時間戳記，要嘛是微軟就其自家評估集所報告的數字——而這個區別在這裡比平常更重要，因為這個模型的任何部分都還沒有被其他人測量過。

出貨內容，以及盒中未包含的物品

三個日期定義了這次發布，而它們是其中僅有的日期。Hugging Face 上用於 microsoft/AesCode-8B 的儲存庫建立於 2026-09-29，權重於 2026-10-07 03:35 UTC 以「Release AesCode-8B」這則訊息提交，而 microsoft/AesCode 程式碼儲存庫則於隔天，2026-10-08 23:14 UTC 公開。32B 權重也在同一個提交時間區間內到位。在這之間，沒有任何事項曾在任何地方宣布。

• 權重 — 四個 safetensors 分片，總計 17,543,339,408 位元組，換算約為 88 億個 bf16 參數。Microsoft 將該模型標示為 8B；Hugging Face 的大小欄位則四捨五入為 9B。那是四捨五入，並非不一致。

• 架構 — 直接微調 Qwen3-VL 配方的成果：Qwen3VLForConditionalGeneration，36 個隱藏層、隱藏大小 4,096、32 個注意力頭搭配 8 個鍵值頭、151,936 個詞彙單元，以及交錯的 mrope 位置。它需要 transformers 4.57 或更新版本。

• 上下文與輸出 — 所報告的執行使用了 24,576 個 token 的上下文，輸出 token 最多可達 12,000 個，並以 temperature 0.8 和 top-p 0.95 生成，每個提示進行三次 rollout，且未經挑選。vLLM 服務指令允許每個提示有兩張圖片：參考圖，以及別無其他，因為輸出是文字。

• 授權 — Apache 2.0，據稱沿用 Qwen3-VL 主幹架構。完全寬鬆授權，無存取審核，亦無可接受使用附加條款。

• 不在盒子裡——訓練與評估資料。該儲存庫隨附了流程，並記錄了預期的輸入與輸出，也提及它預期的分割檔案，但無論是模型卡或程式碼儲存庫，都沒有列出任何資料集發布。你拿到的是食譜，不是食材。

• 同樣不在內建項目中——任何託管的端點。我們到處都找不到提供 AesCode-8B 服務的 API，而且它也不在我們自己的目錄中。在有供應商接手之前，評估它就意味著要將權重載入到你自己的 GPU 上。

Microsoft 所採用的這個框架值得引用，因為它就是完整的設計綱要：程式碼模型「看不見版面配置、階層與色彩如何在畫布上結合」，而圖像生成器「能構成視覺上引人入勝的頁面，卻往往錯誤呈現文字、數字與邏輯關係」。AesCode 正是試圖從前者取來構圖感，並從後者取來可驗證性。

1.00 分結果的說明

以下是第一段中那個數字背後的機制。在訓練期間，每個提示詞都會搭配一張由同一個提示詞生成的參考圖像——Microsoft 自家的訓練運行使用 GPT-Image-2 生成圖像，並用 GPT-5.5 將簡短構想擴展成詳細的內容提示詞。參考圖像不具備內容權威性；文字提示詞仍是唯一的真實來源。參考圖像所提供的是版面配置與風格，而獎勵函數的設計就是要讓這兩者保持分離。

結果是，視覺先驗最終落在策略中，而不是落在輸入中。當推論時移除參考，AesCode-8B 會損失 1.00 點 Visual 分數。它自身的主幹模型在以參考為條件、評估為 44.72 Visual 時，若少了參考就會損失 19.55 分。GPT-5.5 則損失 10.04 分。這件事的濃縮版是：模型不再需要那張圖片。

結果的後半部分正是容易被忽略的那一半。Microsoft 報告指出，基於參考的獎勵將僅提示的 Visual 從 25.17 提升到 69.71——即使在推論時從未看到參考的模型，仍舊因為訓練時曾以這些參考為依據而受益。如果你原本打算在自己的流程中略過參考生成步驟，這個數字說明的就是：在訓練時也同樣不該略過它。

針對上述一切，有個誠實的但書：這是 Microsoft 的評分標準，套用在 Microsoft 的 300 個資訊圖表樣本上，每個提示詞評分三次，且沒有經過挑選。分數有一半來自確定性驗證器，任何人都能重現；另一半——檢核表向度——則由一個文件未載明其身分的視覺語言模型來評判。若不知道後半部分是哪個評審所產生的，就無法重現它。

品味滲入權重之處

訓練方法是本次發布中蘊含最多可移轉構想的部分，而且它比輸出所暗示的更加機械化。

• 一切首先是圖。 每個目標都會以設計圖形來表示：文字、圖表、表格、卡片、區域和圖片插槽是節點，而包含、對齊、順序和連接是邊。這張圖的重點在於歸屬——畫布上的每個屬性都屬於某個具名元素，因此每個屬性都能各自評分。

• 七個獎勵通道。六個確定性驗證器負責檢查可解析的事項——執行、精確文字、邊界、表格與圖表資料、語意版面、空白——而一份針對特定樣本打造的視覺圖形評分規準（Visual Graph Rubric），以關於幾何與位置的圖形綁定是／否問題構成，負責為其餘部分評分。這些通道為執行、文字、邊界、表格圖表、版面、空白與設計。

• 這些通道在合併之前會先經過正規化。GDPO 會在其 rollout 群組內對每個通道進行正規化，因此密集的規則式訊號不會淹沒稀疏的視覺訊號。微軟在相同設定下測得，相較於單純的純量 GRPO，其視覺分數高出 5.12 分——此為廠商自行報告的數據，但這是一項具體的消融實驗，而非空泛的斷言。

• 評分是透過渲染進行的。候選 HTML 會在沙箱化的 Playwright 瀏覽器中渲染，並封鎖外部請求，而測試框架會讀回 DOM、計算樣式、邊界框、主控台狀態與螢幕截圖。表格必須是 HTML 表格；圖表必須是 ECharts 規格。這項限制確實發揮了實際作用——它迫使輸出符合驗證器能解析的形式。

• 配方本身。冷啟動監督式微調，在 3,000 個示範上以 1e-5 的學習率進行，接著在 verl 的 FSDP-vLLM 混合引擎上，針對 7,408 個提示進行 GDPO 訓練 400 步，沒有評論模型，也沒有另行訓練的獎勵模型。AdamW 固定為 5e-6，無預熱，權重衰減 0.01，每步 128 個提示、每個提示 8 次 rollout，KL 與熵係數皆為 0.001，提示與回應各自上限為 8,192 個 token。發布的執行使用單一節點搭配八張 NVIDIA B200。AesCode-32B 使用相同配方訓練 520 步。

整體來看，這是一篇披著模型發布外衣的獎勵設計論文——而這與引用處寫的是「Under review」而非指向預印本，是一致的。

計分板，以及誰為它背書

以下全部都是 Microsoft 在模型卡中報告、針對 300 個資訊圖表樣本的自家評估。「Rule」是程式化「Text」、「Bound」與「Chart」檢查的平均值；「Visual」是「Content」、「Layout」與「Style」檢核表維度的平均值；「Overall」是兩者的平均數。分數是每個提示三次生成結果平均後的百分比，且未經挑選。「Ref.」標示模型是否在提示旁獲得生成的參考資料。

• AesCode-8B（含參考） — 文字 94.06，邊界 88.36，圖表 87.79，規則 90.07；內容 86.41，版面 87.80，樣式 53.21，視覺 75.80；整體 82.94。

• 與其自身骨幹模型相較 — 以參考條件驅動的 Qwen3-VL-8B-Instruct 在 Visual 項目拿下 44.72 分、Overall 拿下 51.93 分。這代表 Visual 提升了 31.1 分、Overall 提升了 31.0 分，而這也是整張表中最不令人意外的比較，因為這項訓練的重點本來就在視覺那一半。

• 對比 GPT-5.5，在參考條件下 — 整體 81.28，內容 82.44，版面 89.93，以及風格 57.91。

• 對比 Claude Opus 4.8，採用參考條件 — 整體 80.39，內容 86.42，版面 89.76。

• AesCode-32B，參考條件式 — 文字 95.34，邊界 97.27，圖表 90.37，規則 94.33，版面配置 90.58，視覺 77.44，整體 85.89。視覺比其自身的 32B 主幹高出 22.4 分。

• 風格天花板——表中沒有任何模型能突破 60 分，而 GPT-5.5 的 57.91 是其中最高的。AesCode-8B 則落在 53.21。微軟自家的定義毫不寬容：唯有當一項設計在交付前無需任何進一步的視覺修改時，Style 才會給予肯定。因此，在衡量人類是否真的會未經編輯就直接交付這個頁面的唯一維度上，8B 模型並非領先者。

• 邊界失敗——嚴重的畫布溢位失敗在 300 個樣本中有 4.3% 會重複發生，相較之下 GPT-5.5 為 34.7%。溢位是讓生成的 HTML 變得無法使用、而不只是難看的失效模式。

現在來說跟表格同樣重要的部分。上面每一個數字都是廠商自行回報、未經重現的。在我們能找到的任何獨立排行榜上，AesCode-8B 都沒有出現，而與 GPT-5.5 和 Claude Opus 4.8 的比較，是在微軟的評分標準上進行的，用的還是那些模型並未針對其調校的任務，而且其中「Layout」的定義只要產出一個頁面就能得分。94.06 的 Text 分數並不代表這個模型在文字方面勝過 GPT-5.5。它的意思是，這個模型在資訊圖表頁面上放置標籤時不會與提示相矛盾，這是個小得多的主張。Style 的結果正透露出，這套評分標準並沒有被做球給 AesCode——最大的計分板勝利，旁邊就緊挨著最不光彩的數字。

哪些已確認，哪些尚未確認

由於這是低調推出的，因此值得將兩者明確區分開來。

• 已確認 — 權重確實存在，並以 Apache 2.0 授權提供下載；兩個發布時間戳記都位於儲存庫中；架構、參數量、上下文長度與取樣設定全都載於已發布的設定檔與模型卡中；訓練配方與獎勵設計有足夠詳細的文件可供討論；程式碼、驗證器堆疊與評分標準建構器皆公開；另有一個 32B 伴生模型存在。

• 未經證實 — 任何基準測試數字，皆未經供應商以外的任何人確認。文件本身稱其正在審查中的那篇論文。分數中視覺部分背後的視覺語言評判者的身分。是否有任何供應商會託管它。24,576 個 token 的上下文在真實的多張投影片簡報上是否站得住腳，因為報告中的評估是針對單一資訊圖表頁面。以及任何關於英語以外行為的資訊——模型卡的語言標籤只有「en」。

如果你想執行它，以及那需要多少成本

Qwen3-VL-8B-Instruct —— AesCode-8B 微調所依據的模型，也是在有人發表獨立 AesCode 結果之前所能取得的最強單一比較對象 —— 則是另一回事：

AesCode-8B 本身的服務路徑很短，而模型卡直接提供了它：vllm serve microsoft/AesCode-8B --limit-mm-per-prompt image=2 --max-model-len 24576，搭配 transformers 4.57 或更新版本（用於非 vLLM 路線），以及一段 Python 程式碼片段，可在文字提示前接受一個可選的參考影像。

你得自己動手算的那筆帳，是記憶體。17.5 GB 的 bf16 權重，必須和 24,576 個 token 上下文、最多兩張影像的 KV 快取一起塞得下，所以單張 24 GB 的卡在技術上足以容納權重，但要把其他所有東西都放進去就緊得難受；40–48 GB，或兩張 24 GB 的卡，才是現實的下限。32B 的搭配模型則是另一個量級的問題——它的分片總計 66.7 GB，因此需要張量平行（tensor parallelism）與多 GPU 節點。另外也別忘了把渲染器編進預算：模型會輸出完整的 HTML 文件，而所有關於它的品質說法，都是靠渲染那份文件來判定的，所以若要為自己的輸出評分，就意味著要架起 Playwright，並封鎖外部請求。

您不需要在推論時生成參考影像——這正是 1.00 分結果為您帶來的好處——但文件清楚指出，若有提供參考影像，品質仍然最高，因此誠實的設定是「參考可選」而非「免參考」。

AesCode-8B 並不是 OrcaRouter 會路由的模型，我們也找不到其他任何地方有託管它，所以目前若要評估，就意味著權重得放在你自己的硬體上。它的主幹架構則是另一回事。Qwen3-VL-8B-Instruct 今天可透過 OrcaRouter 路由，每百萬個輸入詞元收費 $0.18，每百萬個輸出詞元收費 $0.70，並具備 131,072 個詞元的上下文——這使它成為便宜的方式，可以在你花費一週 GPU 時間重現別人的配方之前，先看看這個架構未經調校的版本在你自己的資訊圖表提示上會有什麼表現。OrcaRouter 以 0% 加成將供應商的定價原樣傳遞，並在供應商之間自動容錯移轉，所以那項比較只需一組金鑰，也不必再簽第二份合約；如果 AesCode-8B 有一天上架到我們有路由的供應商，它當天就會出現在目錄中。而如果你真的自行託管它，你在生產環境中會改用的備援模型，正是那個單一端點背後已經提供的那些模型——對於一個默默發布、沒有任何獨立評估的模型來說，這是合理的姿態。

看什麼

兩件事，而兩者都不是另一張基準測試表。

第一項是那篇論文。「AesCode: Aesthetic Code Generation with Decoupled Cross-Modal Rewards」被引用為 2027 年審稿中，這讀起來像是有人打進 BibTeX 條目裡的佔位符，而不是時程安排。在預印本或最終定稿版出現之前，上述的獎勵通道說明，只是一份實驗室外沒有人讀得到的摘要之概述——而有趣的問題，例如 Visual Graph Rubric 如何處理本身就有錯的設計圖，只有在全文裡才會得到解答。

第二個是代管。一個 8.8B、採用 Apache-2.0 授權的模型，能輸出結構化、可驗證的 HTML，正是平台會採用的形式，因為其輸出可被檢視的程度，是 JPEG 所不及的。一旦有人開始提供服務，這就不再是自架與否的決定，而會變成路由決策——而成本比較也不再是 GPU 小時的問題。

不該期待的是乾淨俐落的結論。Style 是那張表中每個系統的天花板，包括這一個；而 Style 是唯一會問人類是否會直接把頁面照原樣上線的維度。對 AesCode-8B 站得住腳的解讀既狹窄又真實：它在視覺設計中可被機器檢查的部分非常擅長，在無法被機器檢查的部分表現平平，而它是這個小眾領域中第一個開放權重模型，其中這兩者之間的落差正是這次發布的重點，而不是偶然的產物。