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ではなく、そのモデルのファインチューニングとして記載している。この重量クラスにある2つのAesCodeモデルは親子ではなくいとこ同士であり、その区別こそがこのページが役立つ理由のすべてだ。つまり、マイクロソフトが視覚言語チェックポイントから始めたときに何を手に入れたのか、それがテキスト側でどれほどの代償を伴ったのか、そしてファミリーの素の8B汎用モデルと比較するとアップグレードではなくフォークを測ることになる理由を教えてくれる。

両方とも Apache 2.0 で、どちらもダウンロード可能だが、その公開の経緯はこれ以上ないほど対照的だ。Qwen3-8B は2025年4月に、ベンダーの Qwen3 世代ラインの一部として提供開始され、ドキュメント、エコシステム統合、そして他者による18か月分のデプロイ実績を伴っている。AesCode-8B のファイルには、どこにもリリース日が記載されていない。Microsoft は2026年9月29日に Hugging Face リポジトリを作成し、2026年10月7日 03:35 UTC に「Release AesCode-8B」というメッセージで重みをコミットし、翌日に学習コードを GitHub に公開した。Microsoft Research の投稿も、リリースノートも、製品ページも、論文もない――モデルカードの引用は「Under review」で、プレースホルダーの年は2027年となっており、本稿執筆時点でリポジトリのダウンロード数は2件だった。以下に示す AesCode-8B に関する量的な事柄はすべて Microsoft 自身によるもので、誰によっても再現されていない。

名前が隠す家系図

Qwen3世代のラインには、8Bクラスのチェックポイントがいくつか含まれており、それらは系統を共有しているが、それ以外にほとんど共通点はない。Qwen3-8Bはテキスト専用の汎用モデルである。総パラメータ数は約82億で、非埋め込みパラメータは約70億、グループ化クエリ注意、ネイティブコンテキストは32KトークンでYaRNにより131Kまで拡張可能、119の言語と方言にわたって学習されている。推論、チャット、コーディング、ツール呼び出しが可能であり、まさにこれらの理由から、オープンエコシステムで最も広くセルフホストされている8Bモデルの1つである。Qwen3-VL-8B-Instructはマルチモーダルなメンバーである。同じファミリー世代で、専用のビジョンタワーを上に持ち、画像とテキストを入力として、テキストを出力する。

Microsoft は2つ目から始めました。AesCode-8B の設定はQwen3VLForConditionalGenerationを読み込み、隠れ層36、隠れサイズ4,096、アテンションヘッド32、キー・バリューヘッド8、語彙数151,936トークン、インターリーブされた mrope 位置を持ち、transformers4.57 以降が必要です。シャードの合計は17,543,339,408バイトで、約88億 bf16 パラメータです。そのため Hugging Face の丸められたサイズ欄は9Bと表示し、ベンダーは8Bと言います。これは不一致ではなく丸めであり、重要なフォークはパラメータ数ではありません — 入力モダリティと24,576トークンのサービングコンテキストです。

だから、正直な位置づけは「汎用モデル 対 そのファインチューニング版」ではない。そうではなく、長いコンテキストと18か月の本番運用実績を備えたテキスト汎用モデル 対 文書を出力し、一度も独立した評価を受けたことのないマルチモーダル研究チェックポイント、という構図だ。

マイクロソフトがトレーニング予算を何に使ったか

デザインブリーフはモデルカードに引用されており、そこではこの分岐が説明されている。コードモデルは「レイアウト、階層、色がキャンバス上でどのように一体となるかを理解できない」のに対し、画像生成器は「視覚的に魅力的なページを構成するが、テキスト、数値、論理関係をしばしば誤って描画する」。AesCode は、一方から構成感覚を、他方から検証可能性を取り入れようとする試みであり、そのレシピはある特定の点で異例である。

すべての学習プロンプトは、その同じプロンプトから生成された参照画像とペアになっている——マイクロソフト自身の実行では、画像にGPT-Image-2を使い、短い概要を詳細なコンテンツプロンプトに展開するためにGPT-5.5を使った。参照画像が担うのはレイアウトとスタイルだけで、内容についてはテキストプロンプトが引き続き権威を持つ。すると、推論時にはモデルはほとんどそれを必要としない。AesCode-8Bから参照画像を除くと、そのVisualスコアは100点満点中1.00ポイントしか下がらないが、バックボーンでは19.55ポイント、GPT-5.5では10.04ポイント下がる。関連する結果として、参照画像ベースの報酬はプロンプトのみのVisualを25.17から69.71に引き上げた。つまり、視覚的プライアは入力に留まるのではなく、重みへと移ったのである。

残りは報酬設計の話である。教師信号はノードとエッジからなる「設計グラフ」であり、テキスト、チャート、表、カード、領域、画像スロットをノードとし、包含、整列、順序、接続をエッジとする。これは、キャンバス上のあらゆるプロパティが名前付き要素に属し、したがって個別に採点できるように選ばれている。7つのチャネルが結果を採点する。実行、テキスト、境界、表とチャートのデータ、意味的レイアウトとホワイトスペースのための6つの決定論的検証器に加え、視覚言語モデルによって判定されるサンプル固有のVisual Graph Rubricが1つある。候補は、外部リクエストがブロックされたサンドボックス化されたPlaywrightブラウザでレンダリングされ、ハーネスはDOM、計算済みスタイル、バウンディングボックス、スクリーンショットを読み戻す。そのため、表はHTMLテーブルでなければならず、チャートはECharts仕様でなければならない。トレーニングは、3,000件のデモンストレーションによるコールドスタート教師ありファインチューニングを行い、その後、8台のNVIDIA B200の単一ノード上で、7,408件のプロンプトに対して400ステップのGDPOを行った。各報酬チャネルはそのロールアウトグループ内で正規化され、密なルールベース信号が疎な視覚信号を圧倒しないようにしている。Microsoftは、その正規化が通常のスカラーGRPOを5.12 Visualポイント上回ると測定している。

そうした仕組みは、AesCode-8B をより優れた汎用アシスタントにするために存在しているわけではない。それは出力を検証可能にするために存在しており、モデルのコンテキストが今のような形になっているのはそのためだ。

横並びで、番号にラベルを付けて

• ベース — AesCode-8B: Qwen3-VL-8B-Instruct（視覚言語モデルのチェックポイント）。Qwen3-8B: 同じ世代のテキスト専用汎用モデル。

• パラメータ — AesCode-8B: bf16で約8.8B、4つのシャードに分散。Qwen3-8B: 合計約8.2B、非埋め込みはおよそ7B。

• 入力 — AesCode-8B: テキストと任意の参照画像。Qwen3-8B: テキスト。

• 出力 — AesCode-8B: 完全なHTMLおよびCSSドキュメント。Qwen3-8B: テキスト、ツール呼び出し、コード。

• コンテキスト — AesCode-8B: 報告されている構成で 24,576 トークン。Qwen3-8B: ネイティブ 32K、YaRN による拡張で 131K。

• 言語 — AesCode-8B: カードのタグは「en」のみ。Qwen3-8B: 119 の言語と方言。

• 根拠 — AesCode-8B：Microsoft自身による300サンプルのインフォグラフィック評価基準、プロンプトごとに3回生成、外部による再現はなし。Qwen3-8B：18か月にわたる独立したベンチマーク、量子化の取り組み、および本番環境への展開。

• ライセンス — どちらも Apache 2.0、ゲートなし。互角であり、人が想定するような差別化要因ではない。

証拠のギャップこそが本当の比較対象だ

Microsoftは、自社のルーブリックでAesCode-8Bが総合82.94を記録し、参照条件付きGPT-5.5の81.28、Claude Opus 4.8の80.39を上回り、また自身の参照条件付きバックボーンをVisualポイントで31.1上回ると報告している。その表にある3つの数字は、見出しの数字よりも重要だ。第一はStyleで、AesCode-8Bは53.21に位置し、比較対象のどのモデルも60を超えていない——そしてMicrosoftによるStyleの定義は、納品前にこれ以上視覚的な修正を必要としないデザインである。つまり、人間がそのページを未編集のまま出荷するかどうかを問う唯一の次元で、このモデルは首位ではない。第二は境界での失敗で、深刻なキャンバスオーバーフローが300サンプルの4.3%で再発し、GPT-5.5では34.7%だった。第三は、スコアの視覚的な半分が名称不明の視覚言語ジャッジに由来すること、つまり決定論的な半分は外部者にも再現できるが、もう半分は再現できないということだ。

Qwen3-8Bの数値はまったく別のところから来ており、どちらの数値セットが高いかよりも、そのことのほうが重要だ。18か月にわたる独立した評価、コミュニティによる量子化、サービングベンチマーク、本番環境でのデプロイは、種類の異なる証拠だ。それは主張ではなく、実績である。Qwen3-8Bが特定のカードで4ビット量子化のもとでどう振る舞うかを知ることができるのは、誰かがそれを公開しているからだ。AesCode-8Bについてはそれができない。今週時点で、Microsoftの外部でそれを何らかの環境で動かした者は誰もいないからだ。

そして、2つの表の間には共通の指標が存在しない。Qwen3-8Bにはインフォグラフィックのレイアウトスコアがなく、AesCode-8Bには公開された汎用推論ベンチマークが一切ない。この比較は、接戦かそうでないかという話ではない——そもそも比較不能なのだ。

それぞれを実行するのに実際に必要なもの

Qwen3-8Bは簡単な方だ。8.2Bのテキストモデルは単一のコンシューマー向けカードに量子化して収まり、あらゆるサービングフレームワークとローカルランタイムにわたって18か月分のツール整備があり、予測可能に動作する。131Kへのコンテキスト拡張は伝聞ではなく文書化されており、119言語対応は、多くの多言語パイプラインでこれが使われる理由になっている。

AesCode-8B はサービング用プロジェクトです。このカード自身のコマンドは vllm serve microsoft/AesCode-8B --limit-mm-per-prompt image=2 --max-model-len 24576 で、非 vLLM 経路には transformers 4.57 以降が必要です。bf16 の重み 17.5 GB は、24,576 トークンおよび最大 2 枚の画像分の KV キャッシュと並べて収める必要があるため、単体の 24 GB カードでも技術的には足りますが、かなり際どく、現実的な最低ラインは 40～48 GB、あるいは 24 GB カード 2 枚です。レンダラーも予算に入れておいてください。このモデルの品質に関するあらゆる主張は、その HTML 出力をサンドボックス化されたブラウザでレンダリングしてなされたものだからです。自分の出力が良いかどうかを知りたいなら、それが立ち上げなければならない検証環境です。また、24,576 トークンのコンテキストが試されたのは単一のインフォグラフィックページであり、このモデルが想定している複数スライドのデッキではないため、実際のデッキにおけるコンテキストの負荷は未検証の領域です。

可用性は、同じ論点のもう半分です。AesCode-8BはOrcaRouterがルーティングする対象ではなく、他のどこかで提供されているのを見つけることもできませんでした。今日評価するとなれば、自分のハードウェア上でウェイトを動かすことを意味します。その祖先となると話は別です——Qwen3-VL-8B-Instructは今すぐOrcaRouter経由で呼び出し可能で、131,072トークンのコンテキストで入力100万トークンあたり$0.18、出力100万トークンあたり$0.70です。これにより、このまったく同じアーキテクチャの未チューニング版が、あなた自身のインフォグラフィック用プロンプトで何をするのかを確かめる最も安価な方法になります。同じ系列をもう少し上に行くと、Qwen3.8-27Bが$0.33と$2.40でルーティング可能です。プロバイダーの定価がマークアップなしでそのまま適用され、プロバイダー間のフェイルオーバーは自動です。そのため、ホストされたバックボーンに対してプロンプトを試作するには、GPUを1週間回すのではなく1つのキーで済み、実際にうまく描画されるプロンプトだけが再現作業に値します。

どちらが必要かは、そのアーティファクト次第です。

成果物がページで、編集可能でなければならないときは、AesCode-8B を選ぼう。Git で差分が取れる構造化 HTML 出力、本物の表としてのテーブル、ECharts 仕様としてのグラフは、テキストの段落とは根本的に異なる成果物であり、どれだけ汎用能力があってもそれに代わることはできない。このトレードオフは承知のうえで受け入れよう：ダウンロード数が2桁の未告知の研究チェックポイント、24K コンテキスト、英語のみ、独立した評価なし、ベンダー自身が公表する Style の上限、そして数十ギガバイト単位で測られるサービング費用。

それ以外のすべてには Qwen3-8B を選べ — ほとんどのチームにとって、それはすべてだ。この規模で実証済みの汎用モデルであり、より長いコンテキストを持ち、119 の言語を話し、すでに所有しているハードウェアで動作し、これから下す決断の背後には他の人々の 18 ヶ月にわたる本番運用の経験がある。レンダリングされたページを出力する特別な必要がないなら、この比較の答えは一つだ。

両方を求める理由は現実にあり、それはタイブレークではない。文書を読み取ってデッキを生成するパイプラインは、出力タイプが本当に異なる2つのモデルを使う。有用な構えは、ページレンダラーをそれを保持できるハードウェア上に置き、読み取りと推論の作業を、他のすべてと同じエンドポイントの背後でホストされている何かへルーティングすることだ。

このページをよりクロージングにつながるページにするには、何が必要でしょうか

三つのこと、そのうちベンチマークに関わるのは一つだけだ。82.94というスコアと、参照値からの1.00ポイント低下を独立に再現できれば、AesCode-8Bをベンダーの主張から実証結果へと押し上げ、8B対8Bのサイズという問いにも実力で答えられるようになる。プロバイダーがこのチェックポイントを採用すれば、デプロイメントの列をたたみ、「GPU一週間」を「API呼び出し」に変える。そして、カードが査読中として引用する論文——「AesCode: Aesthetic Code Generation with Decoupled Cross-Modal Rewards」——は、モデルカードには答えられない問いに答えるだろう。すなわち、視覚ルーブリックが、採点の基準とするデザイングラフ自体が誤っているとき、どう振る舞うかという問いだ。

それらのうちのどれかが実現するまでは、擁護できる解釈は狭い方だ。AesCode-8B は、これら2つのモデルのうちより興味深い方であり、より使いにくい方でもある。機械が確認できる視覚デザインの部分はとても得意だが、自動化できない部分はそこそこであり、比較対象のモデルと同じ Qwen3 世代のファミリーに属しているが、そのモデルから派生したものではない。Qwen3-8B は、今日の午後にもパイプラインに組み込める方だ。