AesCode-8B 與 Gemma 4 12B：兩個小型視覺模型，兩種截然不同的輸出

AesCode-8B與Gemma 4 12B兩者都接收一張圖片和一句話，而且都是 Apache-2.0 檢查點，供你下載而非租用，這也是為什麼搜尋引擎會樂於把它們並列在一起。相似之處確實存在，但也很表面。Gemma 4 12B 回傳的是一個答案——一段描述、一份轉錄、一段程式碼片段、一條推理軌跡。AesCode-8B 回傳的則是一個渲染完成的頁面：一張投影片、一張海報或一個儀表板，形式是完整的 HTML 與 CSS 文件，你可以在瀏覽器中開啟並手動編輯。輸入形式相同，大致權重等級也相同，但輸出卻幾乎毫無共通之處。這個單一差異決定了底下幾乎每一個實務問題，包括明天你能把哪一個端到使用者面前。

必須先講清楚，因為這決定了這些數字能承載多少份量：Gemma 4 12B 由 DeepMind 於 2026-06-03 發布，附有模型卡、文件與生態系，此後也經過獨立測試。AesCode-8B 則根本未曾發布。微軟為它設立的儲存庫建立於 2026-09-29，權重則在 2026-10-07 03:35 UTC 以標題為「Release AesCode-8B」的提交落地，訓練與評估程式碼隔天出現在 GitHub 上。沒有 Microsoft Research 的貼文、沒有產品頁面、沒有發行說明，也沒有預印本——模型卡上的引用寫著「Under review」，年份還是佔位用的 2027。截至本文撰寫時，這個 8B 儲存庫顯示兩次下載與一個讚。因此，關於 AesCode-8B 的一切量化數據都出自微軟自己，沒有任何一項被其他人重現過。

這兩個模型，以其自身的方式

Gemma 4 12B 是一款中型開放模型，一個 119.5 億參數的稠密檢查點，其決定性的設計選擇在於它沒有獨立的視覺或音訊編碼器：影像區塊與音訊波形直接進入 transformer。它具備 256K 個 token 的上下文，並需要約 16 GB 的 VRAM，BF16 權重約 27 GB，量化版本則低於 7 GB。廠商自家的模型卡——由廠商自行報告，本文也如此標示——列出 DocVQA 94.9、InfoVQA 88.4、MMLU-Pro 77.2、GPQA Diamond 78.8、AIME 2026 77.5，以及 LiveCodeBench v6 72.0（思考模式）。獨立評估才是更重要的部分：Artificial Analysis 將推理配置的 Intelligence Index 評為 14，測得每秒約 114 個 token，並將典型服務呼叫的價格定在每百萬輸入 token 約 $0.10、每百萬輸出 token 約 $0.30。它背後已有三個半月的部署歷程。

AesCode-8B 是Qwen3-VL-8B-Instruct的微調版本，以四個 safetensors 分片發布，總計 17,543,339,408 位元組——約 88 億個 bf16 參數，這就是為什麼 Hugging Face 四捨五入後的大小欄位顯示 9B，而廠商說是 8B。已發布的設定是直接沿用 Qwen3-VL 的配方：36 個隱藏層、隱藏層大小 4,096、32 個注意力頭搭配 8 個鍵值頭、151,936 個詞元的詞彙表，以及需要 transformers 4.57 或更新版本。微軟回報的執行使用了 24,576 個詞元的上下文，輸出最多 12,000 個詞元、temperature 0.8、top-p 0.95，且每個提示詞生成三次但不進行挑選。授權為 Apache 2.0，無需申請存取權，沒有可接受使用附錄。未包含在套件內的是訓練與評估資料，以及任何託管端點——我們找不到任何地方有提供 AesCode-8B 服務，且它不在我們自己的目錄中。

模型實際上被訓練來做什麼

設計簡報在模型卡中被引用，值得完整讀過，因為它就是整篇論點：程式碼模型「看不見版面、階層與色彩如何在畫布上結合」，而圖像生成器「能構成視覺上引人入勝的頁面，卻經常錯誤呈現文字、數字與邏輯關係」。AesCode 正是試圖同時保有構圖感與可驗證性的嘗試。

這個機制在某個特定方面並不尋常。每一個訓練提示詞都搭配一張由同一個提示詞生成的參考圖像，這張圖像提供版面配置與風格，而文字提示詞仍是內容的權威依據。接著，在推論時，模型幾乎不太需要這張圖片：不給 AesCode-8B 參考圖，它的 Visual 分數會下降一百分中的 1.00 分。不給 Qwen3-VL-8B-Instruct 參考圖，降幅則是 19.55。不給在相同測試框架下評估的 GPT-5.5 參考圖，降幅是 10.04。視覺先驗最終落在權重裡，而不是在輸入中，而這才是標題底下真正的研究成果。

Gemma 4 12B 的訓練目標是一般多模態模型的那種目標，而這樣說並不是批評：讀取圖像、回答問題、遵循指令、呼叫工具。它的模型卡中沒有任何內容顯示它曾被設定來產出渲染成品，而且沒有任何已發表的 Gemma 4 12B 評估會衡量文件版面品質、畫布溢出或設計一致性，因為那些並不是該模型的指標。

記分板，以及那是誰的評分標準

• 參數 — AesCode-8B：8.8B bf16，稠密。Gemma 4 12B：11.95B 稠密。

• 輸入 — AesCode-8B：文字加上可選的參考圖像。Gemma 4 12B：文字、圖像、音訊與影片。

• 輸出 — AesCode-8B：完整的 HTML 與 CSS 文件。Gemma 4 12B：文字，包含工具呼叫。

• 上下文 — AesCode-8B：在回報的配置中為 24,576 個 token。Gemma 4 12B：256K 個 token。

• 授權 — Apache 2.0，不受限制，包含權重。

• 證據 — AesCode-8B：微軟自家的 300 筆樣本資訊圖表評分標準，每個提示詞生成三次，無獨立重現。Gemma 4 12B：一張廠商提供的評分卡，加上獨立的情報指數 14 分，以及在 Artificial Analysis 上實測的輸送量。

現在來談記分板無法承載的部分。微軟報告 AesCode-8B 在那組 300 個樣本上取得 82.94 的 Overall 成績，領先以參考條件驅動的 GPT-5.5（81.28）與 Claude Opus 4.8（80.39），並在 Visual 分數上比自家的 Qwen3-VL-8B 主幹模型高出 31.1 分。這一切都要理解為廠商自行報告、未經重現的結果，且評分標準由廠商自訂、樣本由廠商自選、計分工具更是廠商訓練該模型時所針對的同一套評估框架。這份評分卡還算誠實，公布了比較中沒有任何模型能突破 60 分的維度——Style：AesCode-8B 為 53.21，GPT-5.5 以 57.91 領先——而微軟自己對該維度的定義是：交付前不需再進行任何視覺修改的設計。而在唯一一個追問人類是否會未經編輯就直接發布該頁面的軸線上，這個 8B 模型並非領先者。當有人引用 82.94 時，這才是你該牢牢記住的數字。

在它們真正重疊的地方

只有一個共用貨架，而它比看起來更窄。如果你正在為文件密集的流程評估小型開源視覺模型，兩者都是候選——一個用來讀取文件，另一個用來產出文件。一個以 HTML 產生內部儀表板、又需要從上傳的 PDF 擷取圖表的團隊，會在同一週內接觸到這兩款產品。

那個重疊之中的區分很清楚。Gemma 4 12B 是你用來處理收到文件的模型。當交付成果是一頁時，AesCode-8B 是你用來處理需求簡報的模型。兩者無法互相替代，而想要兩者兼具的管線會是雙模型管線，而不是二選一的抉擇。

部署，這正是不對稱真正造成影響的地方。

Gemma 4 12B 的部署方案已經底定。你把它下載下來，想量化的話就量化，在 16 GB 的 VRAM 上跑起來，而且已經有龐大的工具生態系在做這件事。如果你根本不想自己跑，透過服務呼叫既便宜，定價也是各自獨立的。

AesCode-8B 的部署故事就是一行命令加上一些算術。模型卡直接給出了做法——vllm serve microsoft/AesCode-8B --limit-mm-per-prompt image=2 --max-model-len 24576，並搭配 transformers 4.57 或更新版本，以供非 vLLM 路徑使用。17.5 GB 的 bf16 權重必須與 24,576 個 token、最多兩張圖片的 KV 快取並存，因此單張 24 GB 顯示卡技術上足夠，但緊繃得讓人不舒服；40-48 GB，或兩張 24 GB 顯示卡，才是現實中的最低門檻。也要把渲染器列入預算，因為這款模型的所有品質宣稱，都是透過在沙箱瀏覽器中渲染其 HTML 輸出而得出的，所以要為自己的結果評分，就意味著得架起一個 Playwright 形式的東西，並封鎖外部請求。

接著是關於實際可用性的誠實狀況。我們並不提供 AesCode-8B 的路由，而就我們所能查到的情況，其他任何人也都沒有；如今要進行評估，就意味著得把權重跑在你自己的硬體上。最接近、且可實際呼叫的，就是這個模型所微調自的架構。Qwen3-VL-8B-Instruct可透過 OrcaRouter 進行路由，目前每百萬輸入 token 收費 0.18 美元、每百萬輸出 token 收費 0.70 美元，上下文長度為 131,072 token，而我們確實提供的兩個檢查點也採用相同的計價方式——Gemma 4 26B-A4B 為 0.06 與 0.33 美元，Gemma 4 31B 為 0.13 與 0.38 美元。供應商的定價原樣傳遞，不額外加收費用，而且供應商之間會自動進行容錯切換，因此，想確認你的提示詞到底能不能好好呈現，最省錢的做法就是先測試未經微調的主幹模型，只把 GPU 週數花在那些通過考驗的提示詞上。

你真正想要哪一個？

如果交付物是一個頁面，就選 AesCode-8B。該模型會輸出結構化、可編輯的 HTML——表格以 HTML 表格呈現，圖表以 ECharts 規格呈現——這表示輸出可在 Git 中進行差異比對，設計師也能重新調整樣式，而不必重新生成。接受這個取捨：一個未經公告的研究檢查點，下載次數只有兩位數，沒有獨立評估，沒有託管端點，24K 脈絡僅在單一資訊圖頁面上驗證過，而且卡片上只有英語的語言標籤。

其他情況就選 Gemma 4 12B。它閱讀文件的能力勝過大多數體型是它兩倍的模型，它能處理音訊，能遵循工具指令，有 25 萬個詞元的上下文，而且背後有其他人三個半月的使用經驗。如果你要從這兩者中挑一個作為你的小型視覺模型，而且沒有人特別要求你以程式碼產生簡報，這就是答案。

而如果誠實地說需求是兩者兼具，就不要把它當成平手時的決勝。把讀取工作導向託管模型，並把渲染工作留在任何能容納權重的機器上。

什麼會改變這個頁面

三個訊號。若能獨立重現 82.94 這個分數，以及相對於參考基準的 1.00 分下滑，AesCode-8B 就會從廠商宣稱變成實測結果，而 8B 對上 12B 的規模問題也會真正有意思，而不只是名目上如此。若有推論服務供應商採用這個檢查點，就會使部署欄位的差距消失，而這正是目前全部的實務差異。至於微軟引用、標示為審查中的論文——「AesCode: Aesthetic Code Generation with Decoupled Cross-Modal Rewards」——將能回答模型卡無法回答的問題，首先就是當設計圖本身有誤時，視覺評分規準會如何表現。在這些事情有任何一項成真之前，站得住腳的解讀既狹窄又真實：AesCode-8B 在視覺設計中機器能檢查的部分非常出色，在機器無法檢查的部分則表現平平，而 Gemma 4 12B 則是做著不同工作的完成品。