GLM-Imageアーキテクチャ：AR＋Diffusionハイブリッドの仕組み
GLM-Imageのアーキテクチャは、プロンプトを読み取って画像を計画する自己回帰（AR）ステージと、それを描画するDiffusionステージを組み合わせ、さらにテキストの可読性を保つ専用のGlyph Encoderを備えています。Z.aiのモデルは総パラメータ数が約160億で、テキストから画像および画像から画像の生成に対応し、MITライセンスで公開されています。このハイブリッド設計こそが、純粋なDiffusionモデルではほとんどできない、画像内への中国語・英語テキストの描画を可能にしている直接の理由です。
このページでは、実際に検証可能なレベルで各要素を解説します。捏造したレイヤー数、偽の処理時間表、でっち上げのバージョン履歴はここにはありません。以前の草稿にはそうした記述が含まれていましたが、ファクトチェックで削除しました。残っているのは本物のアーキテクチャの話であり、飾り気がなくても十分に興味深い内容です。
<!--IMG: Diagram showing a text prompt flowing into an autoregressive planning stage, then into a diffusion rendering stage, producing a finished bilingual poster-->
テキストレンダリングにおいてアーキテクチャが重要である理由は？
テキストは、画像モデルに描かせる最も難しいものです。一つの単語は正確に正しい形のグループでなければなりません——1つの変形したストロークが「fresh」を「fregh」に変えてしまう——そして、それは表面に置かれ、曲線に従い、レイアウトを尊重しなければなりません。ほとんどの画像モデルはテキストをテクスチャとして扱います：書き写しのように見えるもの。書き写しのように見えることと、本当に書き物であることは異なるスキルです。
その失敗はアーキテクチャ的なもので、もっと訓練すれば解決するものではありません。拡散モデルは画像全体を並行して生成し、各ピクセルの粗い文字を同時に決定します。これは一貫したテクスチャには優れていますが、言語の逐次的な象徴的精度には悪いです。言語モデルは反対の問題を抱えています：シンボルをネイティブに扱いますが、連続したイメージを生成しません。
GLMImageの答えは、1つのメカニズムに両方の仕事をさせ続けるのを止めることです。結果、CVTG-2Kでは——生成された画像が要求されたテキストをどれだけ正確に再現するかを測定するベンチマークでは——テキストレンダリング精度が91.16%です。アーキテクチャが原因です；ベンチマークは症状です。
自己回帰ステージは何をするのか？
自己回帰モデルは、トークンを1つずつ生成します。各トークンは、それ以前のすべての内容を条件として生成されます。大規模言語モデルも同じ仕組みで動いており、画像生成にも活かせる特性をもたらします。モデルはプロンプトをキーワードの羅列ではなく言語として読み取り、計画を順次組み立てていくのです。
ハイブリッド画像モデルでは、この計画はピクセルが存在する前に行われます。「メニューボード、濃い緑の黒板、ヘッダーに本日特选、その下に英語のサブタイトル Today's Specials」とプロンプトを入力すると、ARステージがそのリクエストの解析に適したコンポーネントとして機能します——両言語、ヘッダーとサブタイトルの階層、テキストと表面の関係性です。シーケンス単位の生成は、まさにこうした順序立てられた構造的な出力を得意とします。
これが、バイリンガルプロンプトが翻訳ロスなしで機能する理由でもあります。モデルは中国語を英語に、あるいはその逆に翻訳しているわけではありません。混在したプロンプトをひとつの入力として処理し、両方の文字体系を前提に画像を計画します。実際にどのようなことが可能になるか、詳しくはGLM-Imageによるバイリンガルテキストレンダリングをご覧ください。
拡散ステージは何をするのか？
拡散モデルは破壊と再構築によって学習する。画像にノイズを加えていき、砂嵐のような状態になるまで壊したうえで、その過程を一歩ずつ逆にたどるようネットワークを訓練する。生成時には純粋なノイズから出発し、ノイズを除去しながら一枚の絵へとたどり着く。各ステップで画像全体が一気に洗練されるため、拡散モデルは言語モデルにはできないこと——一貫した照明、自然な材質の質感、シーン全体で調和した色彩——に優れている。
現代の拡散モデルでは、古典的なU-Netバックボーンをトランスフォーマーベースの設計に置き換える動きが進んでいる。その転換の標準的な参考文献が Scalable Diffusion Models with Transformers 論文（arXiv:2212.09748）であり、以降この分野が進んできた方向でもある。実務上の効果は、より優れた大域的な一貫性だ。ノイズ除去の過程で、画像のあらゆる領域が他のあらゆる領域にアテンションできるため、高解像度でも構図がしっかりとまとまる。
GLM-Imageでは、拡散ステージがARステージの計画を受け取り、最終的なレンダリングへと仕上げる——黒板の表面、チョークの粉、文字のセリフ体の形状。連続的な世界を扱うのが拡散ステージであり、記号的な世界を扱ったのがARステージだ。
Glyph Encoderとは？
Glyph Encoderは、GLM-Image専用のテキスト描画コンポーネントです。その役割は、モデルにグリフ——文字の視覚的な形状——を条件として与えることです。これにより、画像に「龙井茶」という単語を含めるべきとき、モデルは「ここに中国風の文字がある」という曖昧な印象ではなく、それら3文字が実際にどのように見えるかという、強く明確な信号を受け取れます。
「上品な手書き文字を描いて」と指示されるのと、再現すべき正確な字形を手渡されるのとの違いを想像してみてください。前者では書道風のなぐり書きが生まれ、後者では実際の単語を描き出せます。グリフ情報を直接エンコードすることが、このギャップを埋める方法です。そして中国語ではその重要性が倍増します。何千もの異なる文字があり、いずれも密な筆画構造を持つため、近似では必ず違和感が見えてしまうのです。
ARステージの言語理解と組み合わせることで、これがモデルの目玉機能——実際に読める画像内テキスト——を支える仕組みです。この技術が最も意味を持つのは、バイリンガルのクリエイティブを制作する人々です。実務面についてはAIテキスト描画のベストプラクティスで解説しています。
2つを組み合わせる理由 — どちらか一方を選ぶのではなく
純粋なアプローチはすべて既知のコストを伴います。純粋な拡散モデル：強力なテクスチャ、弱い綴字 — 業界標準の溶けた文字の体験。純粋な自己回帰画像モデル（画像トークンを1つずつ予測）：象徴的な能力があるものの、しばしば柔らかくワックス状のテクスチャになりやすい。これは、画像が本当に逐次的なものではなく、トークン単位の生成がグローバルな視覚的整合性に苦戦するためです。
ハイブリッドは強みの領域で作業を分割します：ARは意味論、レイアウト、言語的な要素すべてに；拡散は表面、光、詳細に。Glyph Encoderはタイポグラフィのためにそれらを橋渡しします。トレードオフは現実的で、はっきりと述べる価値があります：2つのステージと~16Bパラメータは、小さな単一ステージモデルより1画像あたり多くの計算を意味し、自己ホスティングでは約12GBのVRAM以上のGPUを必要とし、特定のカードでの1画像生成はより軽い拡散モデルより遅くなります。計算能力のために計算を支払っているのです。完全なハードウェア像については、GLM-Image specs: what's verified を参照してください。
私たちが知らないことは何ですか？
これは技術的な読者には正直であるべきセクションです。検証可能な形で公開されていないのは、ステージ間の正確なパラメータ分割、レイヤー数、トレーニングデータの構成と規模、内部のレイテンシターゲットです。GLM-Imageについてそれらを事実として引用しているページは、沈黙を創作で埋めているだけです。私たちが知っていること——アーキテクチャクラス、概算総サイズ、ライセンス、ベンチマークスコア、VRAMのガイドライン——は、自己ホストするかどうか、ハードウェアを購入するかどうか、モデルがテキスト中心のワークフローに適合するかどうかについて、実際に意思決定するための十分なものです。
GLM-Imageをクローズドモデルと比較する場合、比較はオープン性 versus 完成度といった異なる基準で行われ、それはGLM-Image vs DALL-E 3: 率直なアーキテクチャ比較で扱っています。検証されたベンチマーク数値やそれ以外も、GLM-Imageベンチマーク: 実際の数値が示すもので明確にされています。
よくある質問
GLM-Imageは拡散モデルですか、それとも言語モデルですか？
両方です。ハイブリッド構成で、自己回帰ステージがプロンプトの理解とプランニングを担当し、拡散ステージが画像を描画します。テキスト専用のGlyph Encoderも備えています。約160億パラメータはシステム全体をカバーしています。
なぜGLM-Imageは他の画像モデルと違い、正確にスペルを書けるのですか？
スペルは記号的なタスクであり、アーキテクチャはそれを記号処理向けのコンポーネント——ARステージとGlyph Encoder——に割り当てているからです。純粋な拡散プロセスが文字の形状を暗記することに頼っているわけではありません。
このアーキテクチャをローカルで動かすには、どのようなハードウェアが必要ですか？
VRAMがおよそ12GB以上のGPUを想定してください。ハイブリッドパイプラインは小型の拡散モデルより重いため、同じカードでも1枚あたりの生成時間は長めに見積もっておく必要があります。
GLM-Imageの性能について、何が検証されていますか？
当サイトで検証済みのベンチマーク数値は1つだけです。CVTG-2Kにおけるテキスト描画精度91.16%です。それ以外——FIDスコア、処理時間の表、ユーザー選好のパーセンテージ——は確認されておらず、どこで見かけても未検証として扱うべきです。
ご自身のプロンプトでアーキテクチャの動作を確認する: バイリンガル画像を生成する →
