AesCode-8B vs Qwen3-8B：它們看起來像親子，但實際上並非如此

這些名稱很容易引人犯錯。AesCode-8B是一個以 Qwen3-VL-8B-Instruct 為骨幹的 8B 模型，Qwen3-8B則是廠商自家的 8B 模型，而最直覺的解讀就是前者是後者的微調版本。事實並非如此。AesCode-8B 所公布的設定檔宣告以 Qwen3-VL-8B-Instruct 為基礎——那是視覺語言的同系模型，是另一個檢查點、擔負不同的任務——而 Hugging Face 上的中介資料將它列為該模型的微調版本，而非純文字的 Qwen3-8B。這個權重等級中的兩個 AesCode 模型是表親，而非親子關係，而這項區別正是本頁之所以有用的全部原因：它告訴你微軟從一個視覺語言檢查點出發時究竟買到了什麼、這在文字方面付出了什麼代價，以及為什麼與該家族中普通的 8B 通用模型相比，最終衡量的其實是一次分支，而非一次升級。

兩者皆採用 Apache 2.0 授權，且皆可下載，但兩者的發布紀錄卻天差地別。Qwen3-8B 於 2025 年 4 月推出，屬於該廠商 Qwen3 世代產品線的一員，背後有文件、生態系整合，以及其他人長達十八個月的部署經驗。AesCode-8B 的檔案裡則完全找不到任何發布日期。微軟於 2026 年 9 月 29 日在 Hugging Face 建立該儲存庫，並於 2026 年 10 月 7 日 03:35 UTC 以「Release AesCode-8B」為提交訊息提交權重，隔天再將訓練程式碼放上 GitHub。沒有 Microsoft Research 的貼文、沒有發布說明、沒有產品頁面，也沒有論文——模型卡的引用資訊寫著「審查中」，年份則以 2027 作為預留位置，而截至本文撰寫時，該儲存庫顯示的下載次數為兩次。下文所有關於 AesCode-8B 的量化資訊都出自微軟本身，且未經任何人重現。

名字所隱藏的家譜

Qwen3 世代包含數個 8B 級檢查點，它們共享同一血統，除此之外就沒太多共同點。Qwen3-8B 是純文字通用模型：總參數量約 82 億，其中約 70 億為非嵌入參數，採用分組查詢注意力，原生 32K token 上下文可透過 YaRN 擴展至 131K，並在 119 種語言和方言上進行訓練。它能推理、對話、寫程式與呼叫工具，正因為這些原因，它是開放生態系中最廣泛被自行架設的 8B 模型之一。Qwen3-VL-8B-Instruct 則是多模態成員：屬於同一家族世代，上層配備專用視覺塔，輸入影像與文字，輸出文字。

微軟是從第二個開始的。AesCode-8B 的設定內容為 Qwen3VLForConditionalGeneration，具有 36 個隱藏層、隱藏維度 4,096、32 個注意力頭與 8 個鍵值頭、151,936 個 token 的詞彙表，以及交錯式 mrope 位置，而且它需要 transformers 4.57 或更新版本。分片總計 17,543,339,408 位元組，約 88 億個 bf16 參數，這就是為什麼 Hugging Face 四捨五入後的尺寸欄位顯示 9B，而廠商則說是 8B。那是四捨五入，而不是差異，且參數量並不是真正重要的分歧點——輸入模態與 24,576 個 token 的服務上下文才是。

所以，誠實的說法並不是「通才對上它的微調版本」，而是：一個具備長上下文與十八個月生產實績的文本通才，對上一個會輸出文件、且從未經過獨立評估的多模態研究檢查點。

微軟把訓練預算花在什麼上

設計簡報被引用在模型卡上，並解釋了這個分歧：程式碼模型「無法看見版面配置、階層與色彩如何在畫布上融合在一起」，而圖像生成器「能構成視覺上引人入勝的頁面，卻經常錯誤呈現文字、數字與邏輯關係」。AesCode 是試圖從前者取得構圖感、從後者取得可驗證性的嘗試，而這套配方在某個特定方面很不尋常。

每個訓練提示都搭配一張由同一個提示生成的參考圖像——微軟自家的實驗用 GPT-Image-2 生成圖像，並用 GPT-5.5 把簡短摘要擴展成詳細的內容提示。參考圖像只承載版面與風格；文字提示在內容上仍具權威性。接著，在推論時，模型幾乎不太需要它：把參考圖像從 AesCode-8B 抽掉，它的 Visual 分數在一百分中只下降 1.00 分，而主幹模型為 19.55、GPT-5.5 為 10.04。一個相關結果是，基於參考圖像的獎勵把僅用提示的 Visual 從 25.17 提升到 69.71，因此視覺先驗移入了權重之中，而不是留在輸入裡。

其餘部分則是獎勵設計的故事。監督訊號是一張由節點與邊構成的「設計圖」——文字、圖表、表格、卡片、區域、圖片插槽，而以包含、對齊、順序與連結作為邊——如此選擇，是為了讓畫布上的每一項屬性都歸屬於某個具名元素，因而能各自單獨評分。七個通道為結果評分：六個確定性驗證器分別檢核執行、文字、邊界、表格與圖表資料、語意版面與留白，再加上一個由視覺語言模型評判、因樣本而異的「視覺圖譜評分規準」。候選輸出會在封鎖外部請求的沙箱化 Playwright 瀏覽器中渲染，而測試框架會回讀 DOM、計算後樣式、邊界框與螢幕截圖，這正是為什麼表格必須是 HTML 表格，圖表必須是 ECharts 規格。訓練先是對 3,000 個示範進行冷啟動監督式微調，接著在單一節點、八張 NVIDIA B200 上，對 7,408 個提示執行 400 步的 GDPO，其中每個獎勵通道都在其所屬的 rollout 群組內正規化，以免密集的規則式訊號淹沒稀疏的視覺訊號。微軟測得這項正規化相較於純量 GRPO 帶來 5.12 個視覺分數的增益。

那套機制並不是為了讓 AesCode-8B 成為更好的通用助理而存在。它的存在是為了讓輸出可以被檢核，而這也是為什麼該模型的上下文會是現在這個樣子。

並排，並標示數字

• 基礎 — AesCode-8B：Qwen3-VL-8B-Instruct，一款視覺語言檢查點。Qwen3-8B：同世代的純文字通用模型。

• 參數 — AesCode-8B：約 8.8B bf16，分佈於四個分片。Qwen3-8B：總計約 8.2B，其中約 7B 為非嵌入。

• 輸入 — AesCode-8B：文字加上可選的參考圖像。Qwen3-8B：文字。

• 輸出 — AesCode-8B：完整的 HTML 與 CSS 文件。Qwen3-8B：文字、工具呼叫、程式碼。

• 上下文——AesCode-8B：在報告的配置中為 24,576 tokens。Qwen3-8B：原生 32K，透過 YaRN 擴展至 131K。

• 語言 — AesCode-8B：其卡片標籤僅為「en」。Qwen3-8B：支援 119 種語言和方言。

• 證據 — AesCode-8B：微軟自家的 300 個樣本資訊圖表評分標準，每個提示詞生成三次，無外部複製。Qwen3-8B：十八個月的獨立基準測試、量化工作與正式環境部署。

• 授權條款 — 兩者皆為 Apache 2.0，且不設門檻。平手，並非人們以為的差異點。

真正的比較，在於證據落差。

微軟報告 AesCode-8B 在其評分標準上整體得分 82.94，領先參考條件化的 GPT-5.5 的 81.28 與 Claude Opus 4.8 的 80.39，並在其自身參考條件化主幹模型之上高出 31.1 個視覺分。那張表中有三個數字比標題數字更值得注意。第一個是 Style，AesCode-8B 落在 53.21，而比較中沒有任何模型突破 60——而微軟對 Style 的定義是無需在交付前再做任何視覺修訂的設計，因此在唯一一個探問人類是否會原封不動地交付該頁面的維度上，該模型並非領先者。第二個是邊界失效：嚴重的畫布溢出在 300 個樣本中有 4.3% 重複出現，而 GPT-5.5 為 34.7%。第三個是分數中的視覺部分來自一位未具名的視覺語言評審，這意味著決定性的一半可由外部人士重現，而另一半則否。

Qwen3-8B 的數字來自完全不同的地方，而這比哪一組數字較高更重要。十八個月的獨立評估、社群量化、服務基準測試和生產部署，是一種不同類型的證據：它不是宣稱，而是實績。你可以查到 Qwen3-8B 在特定顯示卡上以四位元量化運作時的表現，因為有人已經發表了。但對 AesCode-8B，你做不到，因為截至本週，Microsoft 以外沒有人在任何硬體上運行過它。

而且，這兩張表之間沒有共通的指標。Qwen3-8B 沒有資訊圖表版面分數；AesCode-8B 則完全沒有已發布的通用推理基準。這項比較不是接近，也不是不接近——而是無從比較。

實際執行每一個需要什麼

Qwen3-8B 是最容易上手的那個。一個 8.2B 的文字模型可以量化到單張消費級顯示卡上，背後有十八個月的工具鏈支援，涵蓋所有服務框架與本地執行環境，而且行為可預測。上下文擴展到 131K 是有文件記載的，而非口耳相傳，而 119 種語言的涵蓋範圍，正是它出現在這麼多多語言管線中的原因。

AesCode-8B 是一個模型服務專案。這張模型卡本身提供的指令是 vllm serve microsoft/AesCode-8B --limit-mm-per-prompt image=2 --max-model-len 24576，並搭配 transformers4.57 或更新版本，用於非 vLLM 路徑。17.5 GB 的 bf16 權重必須與 24,576 個 token 及最多兩張影像的 KV 快取並存，因此單張 24 GB 顯示卡在技術上足夠，但會緊湊得令人不安，而 40-48 GB 或兩張 24 GB 顯示卡才是現實中的最低門檻。也要為渲染器編列預算，因為關於這個模型品質的每一項說法，都是透過在沙箱瀏覽器中渲染其 HTML 輸出來得到的——如果你想了解自己的輸出是否夠好，那就是你必須架設的測試框架。另外請注意，24,576 個 token 的上下文是在單一資訊圖表頁面上驗證的，而不是該模型所主打的多張投影片簡報，因此真實簡報上的上下文壓力仍是未經測試的領域。

可用性是同一個重點的另一半。AesCode-8B 並不是 OrcaRouter 會路由的項目，我們也找不到其他地方有提供；今天若要評估，就意味著得把權重放在你自己的硬體上。它的前身則是另一回事——Qwen3-VL-8B-Instruct 現在就能透過 OrcaRouter 呼叫，在 131,072 個 token 的上下文下，每百萬個輸入 token 為 0.18 美元，每百萬個輸出 token 為 0.70 美元，這讓它成為最便宜的方式，能看看這個完全相同架構的未微調版本，在你自己的資訊圖表提示上表現如何。同一條產品線再往上，Qwen3.8-27B 可以用 0.33 美元與 2.40 美元路由。供應商的定價原樣傳遞，不額外加收費用，而且供應商之間的容錯移轉會自動進行，因此對著代管的骨幹模型打樣提示，只需一把金鑰，而不是一週的 GPU 時間，而且只有真正算圖效果好的提示，才值得投入重製工作。

你想要哪一個取決於該人工製品

當交付成果是一個頁面，而且必須可編輯時，就選 AesCode-8B。能在 Git 中產生差異的結構化 HTML 輸出、以真正的表格呈現表格、以 ECharts 規格呈現圖表，這與一段文字是截然不同的產物，再多的通用能力也無法取代。要明知故犯地接受這項取捨：一個未經公告的研究檢查點，下載次數只有兩位數、24K 上下文、僅支援英文、沒有獨立評估、自家廠商公布的 Style 上限，以及以數十 GB 計的推論服務費用。

其餘一切都選 Qwen3-8B——而對大多數團隊來說，那正是一切。在這個量級上，它是經過驗證的通用型模型，它擁有更長的上下文，它能說一百一十九種語言，它能在你已經擁有的硬體上運行，而且在你即將做出的決策背後，有著十八個月來自其他人的生產經驗。如果你沒有產生渲染頁面的特定需求，這個比較只有一個答案。

想要兩者兼具的理由是真實的，而且這並不是用來打破平局的考量。一條會讀取文件並產出簡報的管線，會用到兩個模型，而它們的輸出型態確實不同；有用的做法，是把頁面渲染器留在撐得住它的硬體上，並把閱讀與推理的工作導向某個與其他一切同樣託管在同一個端點之後的服務。

要怎麼做才能讓這個頁面更能促成成交？

三件事，而其中只有一件與基準測試有關。若能獨立重現 82.94 與 1.00 點的參考降幅，就能讓 AesCode-8B 從廠商宣稱變成實測結果，也將讓 8B 對 8B 的規模問題得以就事論事地獲得解答。若有服務供應商採用這個檢查點，就會讓部署欄的落差消失，並把「一個 GPU 週」變成「一次 API 呼叫」。而模型卡引用、標示為審查中的那篇論文——〈AesCode: Aesthetic Code Generation with Decoupled Cross-Modal Rewards〉——將能回答模型卡無法回答的問題：當它用來評分所依據的設計圖本身有誤時，視覺評分規準會怎麼運作。

在那些功能尚未落地之前，站得住腳的解讀是狹義的那一種。AesCode-8B 是這兩款模型中較有趣、卻也較不實用的一款。它在視覺設計中機器能檢查的部分表現很好，在無法自動化的部分則表現普通，而且它與被拿來比較的模型同屬 Qwen3 世代家族，卻並非由後者衍生而來。Qwen3-8B 才是你今天下午就能放進 pipeline 的模型。