「AesCode 32B vs Qoder Cantus」のヒーロータイトルカード。サブタイトルは「一方を検査し、もう一方を実行する。両方は決してしない」。左右二分割で描かれ、左側には「AesCode 32B — 重み、検証器、レシピを公開」とラベル付けされたオープンなリポジトリカードがあり、「誰も提供していない」と記された南京錠型の隙間がある。右側には「Qoder Cantus — 公開された一行」とラベル付けされた単一の閉じた文カードがあり、「今日動く」と記されたライブIDEピッカーが付いている。OrcaRouterのロゴは右下隅にある。
Guides & Insights

AesCode 32B vs Qoder Cantus:一方を検査し、もう一方を実行することはできるが、両方は決してできない

著者

Magnus Corvin

公開日

最新モデル · 20すべてのモデルを見る →
ベンチマーク:Artificial Analysis · 毎日更新
すべての記事に戻る

ここには、じっくり噛みしめる価値のある逆転がある。AesCode 32Bは、MicrosoftのHTMLおよびCSS生成チェックポイントであり、同クラスの中で最も検証可能なモデルだ。Hugging Face上にApache 2.0の重み、報酬検証器・ルーブリックビルダー・トレーニングループを含むオープンなリポジトリ、全300サンプルの評価結果が完全公開、そして学習率やロールアウトのステップ数に至るまで詳細に記されたトレーニングレシピ。そのHugging Faceリポジトリの日付は2026年9月29日、コミット「Release AesCode-32B」が着地したのは2026年10月7日で、Microsoftはそのいずれについても一切発表していない。しかもほとんど誰もこれを動かせない。33Bのチェックポイントがおよそ65 GBのアクセラレータメモリを要求するのに、それを提供するプロバイダーが存在しないからだ。Qoder Cantusは、まさにその正反対だ。これは今すぐ、Qoderの中で、サブスクリプションを持つ誰もが動かせる——そして、あなたはそれをまったく検証できない。Qoderによるこのモデルに関する公開説明はたった一文だけで、パラメータも、コンテキストウィンドウも、ベンチマーク表も、重みもなく、APIが存在しない以上、サードパーティの数値が現れることも永遠にない。一方のモデルはすべてを教えてくれるが、何もさせてくれない。もう一方は何もかもさせてくれるが、何も教えてくれない。興味深い問いは、どちらの失敗の仕方のほうがあなたにとって高くつくのか、ということだ。

ドキュメントの内容、全文

非対称性は、存在するものをそのまま引用するのが最も分かりやすい。

AesCode 32Bでは、公開記録に以下が含まれている:ベースモデル(Qwen3-VL-32B-Instruct)、パラメータ数、ライセンス、想定用途、学習データ量、SFT学習率、RLオプティマイザ設定、報酬チャネル名、プロンプト数とステップ数、評価サンプルサイズ、プロンプトあたりの生成回数、デコード温度とtop-p、スコアリングに使用したコンテキスト長、別々に公開された3つの結果表、そして査読中と記載された論文の引用。ただし、リリース日と2桁のダウンロード数までは含まれていない—そして、モデルカードがtransformers>=4.57を必要としているという注記、およびページ上の自動生成された使用スニペットがカード自身の例と一致しないという注記は、成果物が本物であるときにだけ残る種類の細部である。

Qoder Cantusについて、公開されている記録は次のとおりだ。「Qoder内蔵のトップティア知能モデルで、長時間の自律的なタスク実行を得意とする」。それが説明である。モデルカードは存在しない。ダウンロードできるモデルがないからだ。ベンチマーク表も存在しない。Qoderがローンチ記事や技術レポートを公開していないからだ。アリーナの掲載もない。アリーナには呼び出すためのエンドポイントが必要だからだ。ほかにわかっていることは、技術的というより構造的である。CantusはQoder Desktop、JetBrainsプラグイン、CLI、Cloud Agents、Webクライアントのモデルピッカーに表示され、Qoderのクレジットシステムを通じて、モデルの使用量に係数を適用して課金される。

それはモデルへの非難ではない。何が検証できるかを述べたものであり、Cantus に関して言えば、答えは何もない。

それぞれが本当に強いのはどこか

AesCode 32Bの強みは検証可能性にあり、断言するよりも説明する価値があるほど珍しい。訓練シグナルは単一のスコアではなく、7つのチャネルだ。そのうち6つは決定論的検証器で、出力されたコードとそのレンダリングから特性を読み取る。さらに視覚言語ジャッジが、サンプルごとの設計グラフに紐づいたルーブリックに照らして、パース不能な特性を採点する。各候補は、外部リクエストをブロックしたサンドボックス化されたPlaywrightブラウザでレンダリングされ、DOM、計算済みスタイル、バウンディングボックス、コンソールステータス、スクリーンショットをエクスポートする。各特性が帰属可能であるため、ラボは自身のQwen3-VL-32Bバックボーンと比べてVisualコンポーネントを22.4ポイント改善したと報告でき、訓練終了時にどのチャネルがまだ伸びていたかを示せる。これは、議論し、再現し、拡張できるリリースである。

コストも同じくらい具体的だ。モデルカードは、bf16パラメータだけでおよそ65 GBを見込むよう勧めている。サービング例では4-wayテンソル並列を使用し、報告されている数値は24,576トークンのコンテキストを用いており、強化学習中はプロンプトと応答が8,192トークンに制限されていた。これを、どの推論プロバイダーもこのチェックポイントをデプロイしていないという事実と突き合わせて考えてみよう。障壁は哲学的なものではない。ハードウェアを自前で所有するか借りるかのどちらかであり、マルチモーダルのサービング経路は自分で構築することになる。

Cantusの強みは正反対だ。それはただそこにある。ダウンロード不要、GPU不要、サービングスタック不要、選ぶべきハーネスもない。それは、あなたがすでに使っているIDEのモデルピッカーに現れ、エージェント型コーディングツールが売りにしているまさにそのもの——長い自律的タスク実行——に向けて位置づけられている。それについて他に何が不確かであれ、デプロイの問題はあなたのために解決済みであり、Qoderは自分が構築したモデルについて、公開している以上に多くを知っているはずだ。

Cantusについてあなたが答えられない3つの質問

不足しているドキュメントが何の代償をもたらすかについては、正確に述べておく価値がある。というのも、「ベンチマークがない」という言葉では、その実態を過小評価してしまうからだ。

• どれくらいの規模なのか — 不明。パラメータ数は公開されていない。クレジット課金制のモデルでは、これは些細な話ではない。他所なら2ドルで済むタスクが、ここでは6ドル払わなければ実行できないかどうかを左右する主要な判断材料だからだ。

• どれだけのコンテキストを保持するのか — 非公開で、第三者による議論が200K前後の何かを示唆しているが、その根拠はない。長期的なエージェント作業の成否はこの数字にかかっており、しかもそれは公表されていない。

• それは優れているのか——厳密な意味では答えられない。ポジショニングに暗黙的に込められたQoderの主張は、長期的な自律実行は、単一ターンのコーディングスコアよりも、モデルがコンテキスト、復旧、そして何百回ものツール呼び出しをどう扱うかで測るべきだというものだ。それはもっともな主張だ。モデルがテスト可能であれば、この主張はより強く響いただろう。しかしそれは不可能だ。なぜなら、Qoderの外側からはモデルを呼び出せないからだ。

それを、AesCode 側にある第 3 の問いの鏡像と比べてみよう。数値は存在し、詳細でもあるが、それは Microsoft の数値であり、Microsoft のハーネスが Microsoft の 300 サンプル上で出したもので、外部のラボがそのどれかを再現したことはない。AesCode 32B には、独自のスタイル次元における文書化された上限 55.99 と、4.3% という深刻なキャンバス境界障害率がある——どちらもベンダーによって公表されている——そして、どちらの数値が正しいかについて独立した確認はない。つまり二つの失敗モードとは、信頼できない数値と、数値がないことだ。それは「一方が良く、一方が悪い」よりも悪い選択であり、そしてこの対戦が実際に提示する選択なのだ。

A two-column comparison scoreboard for AesCode 32B and Qoder Cantus: the AesCode 32B column reads 'Published record: weights, verifiers, full recipe', 'Parameter count: 33B dense', 'Context: 24,576 tokens', 'How you get it: a Hugging Face download', 'Cost shape: GPU hours', 'External evaluation: none - no provider serves it'; the Qoder Cantus column reads 'Published record: one sentence', 'Parameter count: not disclosed', 'Context: not disclosed', 'How you get it: built into Qoder', 'Cost shape: Qoder credits (1.6x-3.2x coefficient)', 'External evaluation: impossible - no endpoint'; a footer line reads 'AesCode 32B figures Microsoft-reported; Qoder has published no parameter count, context window or benchmark for Cantus.' and the OrcaRouter logo sits in the bottom-right corner.

それぞれの側であなたが払うコスト

Cantusは、公開されたトークン単価ではなく、Qoderのクレジットシステムを通じて課金する。Qoderはモデルの使用量に係数を適用し、Cantusは3.2倍の乗数で稼働を開始したが、2026年7月31日まで実施された50%オフのプロモーションにより1.6倍に引き下げられた。Qoder自身が公開したクレジット見積もりから再構成すると(トークンあたりの数値ではなく、QoderはCantusについてそのような数値を一度も公開していない)、編集者モードの1ターンあたりおよそ0.38ドル、Questタスクあたり1.60ドル、ExpertsモードでのQuestあたり2.40ドルに相当する。これらは再構成であり、別のことを示す一次情報源が存在しないため、そのようにラベル付けされている。

AesCode 32B のコストは、単価ではなく設備投資額だ。重みは Apache 2.0 の下で無料で、請求書は GPU 時間として届く — パラメータを保持するための 65 GB のアクセラレータメモリ、加えてビジョンタワー、さらに必要なスループット分。すでに別の作業で B200 クラスのノードを運用しているなら、限界費用はほぼゼロだ。そうでなければ、正直な比較は Qoder のクレジットに対する「100万トークンあたり $0」ではなく、サブスクリプションに対するハードウェアの判断である。

コンポーザビリティの違い

アクセスモデルには、もうひとつ結果があります。そしてそれは、ルーティングプラットフォームが真っ先に気づくものです。

Cantusは何とも組み合わせることができない。APIがなければ、フォールバックも、同じタスクで別のモデルとA/B比較することも、リクエストの途中で安価なモデルから高価なモデルへカスケードすることも、自分で書いた評価ハーネスに組み込むこともできない。それは1つの製品の中の1つの選択肢であり、あなたが握れる唯一のレバーはピッカーだけだ。これはQoder側の意図的な設計判断であり、IDEを自分の主戦場にしたいなら完全に合理的な選択だ——しかしそれは、あなたのアーキテクチャがQoderのロードマップを引き継ぐことを意味する。

AesCode 32Bは理論上は逆の性質を持ち、実践上はギャップがある。ウェイトは、それがどこにでも置けることを意味する。あなたのクラスタ、レンタルしたインスタンス、自前のツール、自前の評価だ。今日それができないのは、呼び出されることだ。なぜなら、どのプロバイダーもそれを提供していないからだ — Microsoftはチェックポイントを公開して、そこで止まった。したがって、構造的に合成可能なモデルはまだ実践的に合成可能ではなく、実践的に利用可能なモデルは構造的にロックされている。

そうなると、ルーティングをめぐる議論はいつもより狭い範囲に落ち着く。そして正直に言っておく価値がある。この対決に登場するモデルはどちらも当社のカタログには載っておらず、このページはそうでないふりをするつもりはない。プロバイダーの定価で200以上のモデルを揃えた単一のエンドポイントがここで実際にもたらすのは、その周辺層だ——AesCode 32Bの出力を消費するワークフローを構築し、そのうち汎用モデルが扱うべき部分をルーティングする能力を、それぞれのために別契約を立てることなく実現できる。セルフホスト型の視覚言語デプロイメントに踏み切る前にその層をテストしたいなら、最も安上がりな方法は同じファミリーの呼び出し可能なモデルだ。AesCode 32BはQwen3-VL-32B-Instructのファインチューニングであり、Qwen3-VL 235B A22B Instructは100万入力トークンあたり0.40ドル、出力1.60ドルで利用でき、より小さいQwen3-VL 8B Instructは0.18ドルと0.70ドル。これらは別のモデルであり、ファインチューニングの代替ではない——しかし「ホスト型VLMはこのスクリーンショットを読み取り、我々のパイプラインに十分な品質でコードを書けるか」という問いに、65 GBではなく数セントで答えてくれる。そして答えがイエスでトラフィックが本格化するなら、プロバイダー間のフェイルオーバーは同じキーの下にある。

A screenshot of the Hugging Face model page for microsoft/AesCode-32B, showing the model card header, the Apache 2.0 licence tag and the start of the published evaluation tables and configuration detail (captured October 11, 2026).

選び方

すでにQoderの中にいて、インフラ作業が不要であることを重視し、その代償として検証不能性を受け入れる用意があるなら、Cantusを選びなさい。あなたが買っているのはモデルではなく能力であることを冷静に認識してください。導入前にベンチマークすることはできず、トークン単位でその価格を何かと比較することもできず、Qoderが価格やロードマップを変更しても、それを一緒に持ち出すことはできません。

成果物が必要で、そのデプロイを受け入れられるなら、特に、diff を取ってレビューし出荷できる編集可能な HTML を出力するモデルが必要なら、AesCode 32B を選べ。同じくらい冷静に見据えよ。それは未発表で、再現されておらず、ほとんどのハードウェアには大きすぎ、長い文書を制約することになる 24K コンテキスト向けに文書化されている。

最初の選択肢のロックインも、2番目の選択肢の設備投資コストも望まないなら、正直なところ、呼び出せるモデルから同じ能力を得るのが正解だ。APIキー越しの視覚言語モデルは、スクリーンショットを読み取り、構造化マークアップを書き出す。デザイン品質に合わせて調整された7つの報酬チャネルで訓練されるわけではないし、Microsoftが構築したインフォグラフィックベンチマークでAesCode 32Bに匹敵することもない。だが、GPUの調達ではなく登録済みのカードで済み、しかも自分で測定できる——この対決全体がかかっているのは、まさにその一点だ。

A screenshot of the companion GitHub repository for AesCode 32B, showing the repository name, the README opening and the directory listing that includes the reward verifiers, rubric builder and training loop (captured October 11, 2026).

何を観るべきか

Cantus は、Qoder がエンドポイントを公開するか重みを出荷した日から、普通のモデルになる。それまでは、Cantus に関するあらゆる主張は、モデルに関する主張ではなく Qoder の製品に関する主張であり、証拠の欠落は文書化の不備ではなく構造的なものだ。AesCode 32B は、推論プロバイダーがチェックポイントを採用するか、外部ラボが 85.89 を再現した日から、普通のモデルになる——そしてそれが Microsoft が実際に件のものを発表することと同時に起きれば、残る障壁は 65 GB の壁だけだ。どちらが先に実現するかによって、この業界が 2 つの失敗モードのうちどちらをもう容認しないと決めたのかが分かる。