CogView4-6Bとは？2048×2048が仕様外となる理由とVRAM要件・料金

CogView4-6Bは、智譜AI（Z.ai）が2025年3月に公開したテキスト画像生成モデルです。配布元の組織名は公開当時THUDMで、現在はzai-orgに変わっています。日本語の解説記事では「2048×2048ピクセル対応」という説明が広く出回っていますが、公式モデルカードが定める画素数の上限は2の21乗（2,097,152ピクセル）で、2048×2048＝4,194,304ピクセルはその倍です。つまり2048×2048は公式の対応範囲から外れます。この記事では上限の正しい読み方、公式が記載を取り下げた経緯、2026年9月時点での入手と使い分けを、一次情報だけで整理します。

まとめ

• 2048×2048は仕様外。公式の制約は「幅・高さとも512px以上2048px以下、32の倍数、かつ総画素数が2の21乗以下」で、正方形なら1440×1440が上限です。2048pxを使えるのは長辺だけで、そのとき短辺は1024pxまでです。
• 公式リポジトリは2025年3月11日のコミット504ee09aで、README（英・日・中の3言語すべて）から「2048 * 2048」のVRAM計測行を削除しています。日本語記事に残る2048×2048という数字は、削除前のREADMEを引いたものです。
• モデル名の「6B」はDiT（画像生成側）だけの値です。テキストエンコーダーのGLM-4-9Bは別勘定で、リポジトリ全体のダウンロードは約31GBになります。
• 推論はBF16またはFP32のみ。FP16はオーバーフローして真っ黒な画像になると公式が明記しています。CPUオフロードなしで33〜39GB、オフロード有効で20GB、テキストエンコーダーを4bit量子化すると13〜14GBです。
• ベンチマークで公式が並べている比較対象はSD3.5ではなくSD3-Mediumです。DPG-Benchのoverallは85.13で表中最高ですが、GenEvalは0.73でSD3-Medium（0.74）とJanus-Pro-7B（0.80）に届いていません。
• 2026年9月時点でリポジトリ群の更新は2025年春で止まっています。ローカル実行に強いこだわりがなければ、Z.ai APIで1枚0.01ドルで叩くか、2026年1月公開のGLM-Imageを選ぶほうが実務的です。

根拠はすべて公式モデルカード・GitHubのコミット履歴・Z.aiの公式料金表にあります。以下で順に確認します。

CogView4-6Bの基本仕様とライセンス

「6B」が指す範囲と実際のダウンロード容量

Hugging Face APIが返すパラメータ数は6,369,118,272（BF16）です。この値はtransformerフォルダのインデックスファイルが持つtotal_size（12,738,236,544バイト）の正確に半分と一致します。BF16は1パラメータ2バイトなので、公称6BはDiT本体のみを数えた値だと確認できます。

実際にダウンロードされるのはそれだけではありません。テキストエンコーダーのGLM-4-9Bが17,558,388,736バイト、VAEが812,234,342バイトあり、全ファイルの合計は31,129,025,003バイト、およそ31GBです。「6Bだから軽い」という前提でディスクとVRAMを見積もると足りません。モデル名と実体がずれる構図は、同じZ.aiのGLM-OCRとは？0.9Bの実体と日本語精度・vLLM/Ollama導入手順とAPI料金でも起きているので、Z.ai系のモデルを扱うときは重みファイルの実サイズを先に確認してください。

対応言語・プロンプト長・精度の制約

公式リポジトリの比較表では、CogView4のPrompt Languageは中国語と英語、Prompt Length Limitは1024トークンと書かれています。前世代のCogView3-Plus-3BはT5-XXLを使い英語のみ・224トークンだったので、扱えるプロンプト長は4倍以上に伸びました。diffusers側のCogView4Pipelineもmax_sequence_lengthの既定値を1024に置いており、ドキュメントと実装が一致しています。

一方で日本語は対応言語に挙がっていません。ただし公式資料は、日本語が学習データに含まれないとまでは書いておらず、日本語での品質を判断できる評価結果も示していません。判断材料が無い以上、まず英語か中国語に翻訳して出力を確認するのが無難です。公式も、生成前にLLMでプロンプトを書き直すことを強く推奨し、そのためのprompt_optimize.pyを同梱しています。

精度の制約はもっと厳格です。モデルカードは対応精度をBF16とFP32に限定したうえで、FP16はオーバーフローを起こして完全に黒い画像になると明記しています。VRAMを削る目的でFP16を選ぶ余地はありません。

Apache-2.0ライセンスで許される範囲

モデル重みはApache License 2.0で公開されています。商用利用・改変・再配布が認められますが、再配布時はライセンスの添付、変更したファイルへの変更表示、著作権表示やNOTICEの保持といった条件に従う必要があります。逆に言えば、Stability AIのCommunity Licenseのような年間収益による商用可否の切り替えや、Midjourneyのような利用規約上の縛りはありません。画像生成モデルのライセンス比較はFLUX.2の全5モデル比較｜Flex・Max・Pro・Dev・Kleinの違いと選び方【2026年最新】も併せて確認すると、Dev系とPro系で条件が割れる他社の事情がつかめます。

2048×2048が仕様外となる理由と公式対応範囲

公式対応範囲の総画素数上限と解像度例

モデルカードの推論要件は次の一文です。Width and height must be between 512px and 2048px, divisible by 32, and ensure the maximum number of pixels does not exceed 2^21 px. 条件は3つあり、「512px以上2048px以下」「32の倍数」に加えて総画素数が2の21乗以下という制約が重なります。

2の21乗は2,097,152です。2048×2048は4,194,304ピクセル、つまり2の22乗なので、3つ目の条件をちょうど2倍超過します。「2048pxまで対応」という部分だけを読むと2048×2048が作れそうに見えますが、それは辺の長さの上限であって、面積の上限ではありません。

32の倍数という条件も効いています。2,097,152の平方根は約1448.2ですが、1448は32で割り切れないため、正方形で取れる最大は1440×1440です。長辺に2048pxを使う場合、短辺は2,097,152÷2048＝1024pxまでに制限されます。

公式が2025年3月11日に削除した記載

2048×2048という説明の出所の一つは、公開直後の公式READMEにあったVRAM計測表です。この表には最終行として「2048 * 2048 / 43GB / 21GB / 14G」が載っていました。その行は2025年3月11日のコミット504ee09aで削除されています。コミットメッセージは remove 2048*2948 test（2048の打ち間違い）で、変更ファイルはREADME.md・README_ja.md・README_zh.mdの3つ、つまり英語版・日本語版・中国語版から同時に消えました。同じ削除はHugging Face側のモデルカードにも入っています。

当社がこの記事の旧版を公開したのは2025年3月6日、削除の5日前です。当時の公式表にあった数字を引いたまま、その後の訂正を反映できていませんでした。他社の日本語解説も、本文を取得して確認した限り2の21乗の制約に触れたものは無く、削除前のREADMEを引いた記述が流通しています。

diffusersの解像度チェックとモデル仕様との差

紛らわしいのは、diffusersが画素数上限をチェックしないことです。pipeline_cogview4.pyのcheck_inputsが検証するのは「高さと幅が16の倍数か」だけで、モデルカードが求める32の倍数も、2の21乗という面積上限も見ていません。2048×2048を渡しても例外は飛ばず、そのまま推論に入ります。エラーが出ないことを「対応している」と読み替えないでください。

次のコードは公式モデルカードのサンプルを基に、解像度だけ仕様内の1440×1440へ変えたものです。構文は検証していますが、当社ではGPU環境での画像生成の完走までは検証していません。

pip install "diffusers>=0.33.0" transformers accelerate torch

import torch
from diffusers import CogView4Pipeline

pipe = CogView4Pipeline.from_pretrained(
    "zai-org/CogView4-6B", torch_dtype=torch.bfloat16
)
pipe.enable_model_cpu_offload()
pipe.vae.enable_slicing()
pipe.vae.enable_tiling()

image = pipe(
    prompt="A vibrant cherry red sports car under the gleaming sun",
    guidance_scale=3.5,
    num_inference_steps=50,
    width=1440,   # 1440 * 1440 = 2073600, under 2**21
    height=1440,
).images[0]
image.save("cogview4.png")

モデルカードのQuick Startはdiffusersをソースからインストールする手順になっていますが、これは公開当時の暫定措置です。CogView4PipelineとCogView4ControlPipelineはdiffusers v0.33.0（2025年4月9日）から正式リリースに含まれており、2026年8月のv0.40.0にも残っています。いまはPyPI版で足ります。リポジトリのIDもTHUDMからzai-orgへ移管済みで、旧IDはリダイレクトされます。

VRAM要件と現実的な実行構成

公式のVRAM計測はBF16・バッチサイズ4での参考値です。ただし、表の1280×720は高さが32の倍数ではなく、1920×1280は2,457,600画素で2の21乗を超えるため、モデルカードの解像度条件と整合しません。以下は公式掲載値の転載であり、対応解像度を保証する表ではありません。GLM-4-9Bを丸ごと載せる構成が重く、全部をVRAMに置くとコンシューマー向けGPUでは収まりません。

注目すべきは、解像度を512×512まで落としてもオフロードなしで33GB必要な点です。解像度による差は最大でも6GBしかありません。テキストエンコーダーの重みだけで約17.6GB、DiTが約12.7GBあり、重みの常駐分が消費の大きな部分を占めているためです。だからこそenable_model_cpu_offloadの効きが大きく、20GBまで一気に下がります。テキストエンコーダーを4bit量子化すれば13GB前後、つまり16GBクラスのGPUでも動く範囲に入ります。公式は加えて、プロセスが強制終了されないようシステムRAMを32GB以上用意するよう推奨しています。

リポジトリにはbitsandbytesのint4でテキストエンコーダーを読む例、TorchAOのint8／int4で両方を量子化する例、Gradioデモが同梱されています。なお、ComfyUI本体のsupported_models.pyにcogviewの記述はなく、公式リポジトリもComfyUI対応をコミュニティ製ラッパーとして紹介しています。ComfyUIのワークフローに組み込む前提なら、後述する別モデルを検討したほうが早いです。

ベンチマークの実測値とSD3-Medium・DALL-E 3との差

旧版の当記事は「SD3.5やDALL-E 3に匹敵」と書いていましたが、公式が表に並べている比較対象はSD3.5ではなくSD3-Mediumです。SD3とSD3.5の関係はStable Diffusion 3とは？SD3.5との違いと2026年時点の入手・動作環境で整理しているとおり別物なので、ここは正確に読む必要があります。

DPG-Benchのoverall 85.13は表中で最高値です。内訳でもAttribute 91.17とRelation 91.14が最高で、属性の指定や物体同士の位置関係といった長文プロンプトの解釈で強さが出ています。なお、この比較表だけでは、対応トークン長がスコア差にどれだけ寄与したかまでは分かりません。

ただし全勝ではありません。GenEvalのoverallは0.73で、SD3-Medium（0.74）にわずかに及ばず、Janus-Pro-7B（0.80）には大きく離されています。特にPositionは0.48で、Janus-Pro-7Bの0.79とは開きがあります。T2I-CompBenchでも2D-Spatialは0.3075とSD3-Mediumの0.3200に届きません。「数を正しく描く」用途（Numeracy 0.6626は表中最高）では有利ですが、配置精度を優先する場合は、GenEvalのPositionで上回るJanus-Pro-7Bや、T2I-CompBenchの2D-Spatialで上回るSD3-Mediumも比較対象にしてください。

明確な差がつくのは中国語の文字描画です。Kolorsとの比較でF1が0.6168対0.2880、Pick@4が0.3265対0.1633と2倍前後の差があります。ただしこの評価は中国語の文字だけを対象にしたもので、比較相手もKolors 1本です。日本語の漢字や仮名を含む文字列の品質や、2026年のモデルに対する優位性までは読み取れません。

2026年9月時点の入手性・料金・メンテナンス状況

関連リポジトリの更新履歴と保守状況

旧版の当記事は「今後の開発ロードマップ」として解像度の向上やマルチモーダル対応を挙げていましたが、そのどれも実現していません。実際の状態は次のとおりです。

リポジトリのProject Planに残る「ControlNet models and training code」は、1年半を経ても未チェックのままです。Hugging Faceの累計ダウンロードは174万件を超えていますが、この数値から新規採用と既存環境での再取得の割合は判断できません。「オープンソースコミュニティが今後さらに育てる」という前提で採用を決めるのは、2026年時点では現実に合いません。

Z.ai APIの料金・モデルID・サイズ制約

ローカル実行の環境を用意しない場合は、Z.aiのAPIでCogView-4を利用できます。エンドポイントはPOST https://api.z.ai/api/paas/v4/images/generationsで、モデルIDはcogview-4-250304です。料金は公式の価格表で1枚あたり0.01ドル、同じ表に並ぶGLM-Imageは0.015ドルです。ローカル実行のVRAM使用量はオフロードや量子化の構成で変わりますが、約31GBのモデル取得とGPU環境の用意そのものを省けるので、まず試すだけならAPIが手軽です。

curl -X POST "https://api.z.ai/api/paas/v4/images/generations" \
  -H "Authorization: Bearer $ZAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "cogview-4-250304",
    "prompt": "A red sports car on a coastal road",
    "size": "1024x1024",
    "quality": "standard"
  }'

API側のsize制約はローカルとわずかに違い、512px以上2048px以下・16の倍数・総画素数2の21乗以下です。倍数の条件だけ緩く、面積の上限は同じです。ここでも2048×2048は通りません。qualityはcogview系の既定がstandardで5〜10秒、hdを指定すると約20秒かかります。

GLM-Imageとの使い分け

同じZ.aiが2026年1月にHugging Faceで公開したGLM-Imageが、いま同社の主軸にあたります。CogView4-6Bの重み更新が2025年3月で止まったまま後から登場し、価格表にも並んでいるので、新規に選ぶならこちらが起点です。アーキテクチャは自己回帰生成器と拡散デコーダのハイブリッドで、自己回帰側はGLM-4-9B-0414から初期化した9Bパラメータ、デコーダ側はGlyph Encoderを備えた7BのシングルストリームDiTです。モデル全体はMITライセンスですが、組み込まれたVQ tokenizerとViTの重みにはApache-2.0が適用されるため、利用する構成要素ごとに条件を確認する必要があります。

実務上の違いがいちばん出るのが解像度です。GLM-ImageのAPI制約は1024px以上2048px以下・32の倍数・総画素数2の22乗（4,194,304）以下なので、2048×2048がちょうど上限に収まります。旧記事が謳っていた2048×2048の正方形出力を実際にやりたいなら、選ぶべきはCogView4-6BではなくGLM-Imageです。Z.aiのモデル系譜全体はGLM（Z.ai）とは？最新バージョンGLM-5.2までの世代一覧と選び方・料金・使い方にまとめています。

では、いまCogView4-6Bを選ぶ理由は何か。すでにCogView4で動いている環境を維持する場合と、手元のGPUが小さい場合です。GLM-Imageの公式ローカル推論手順はCPUオフロードでも約23GBが目安とされており、13GB前後まで落とせるCogView4-6Bのほうが収まることがあります。逆に、更新が続くモデルを前提にワークフローを組みたい、ComfyUIのノードとして使いたい、日本語プロンプトを直接投げたいのいずれかに当てはまるなら、候補から外して構いません。

よくある質問

CogView4-6Bで2048×2048の画像は生成できますか？

公式モデルカードの対応範囲外です。記載された総画素数の上限は2の21乗（2,097,152ピクセル）で、2048×2048は4,194,304ピクセルと倍以上になります。2048pxを指定できるのは長辺だけで、その場合の短辺は1024pxまでです。正方形なら1440×1440が上限です。なお、diffusersは16の倍数かどうかしか検査しないため、2048×2048を渡してもエラーは出ません。

モデル名の「6B」は何のパラメータ数ですか？

画像を生成するDiT側だけの値で、6,369,118,272パラメータです。テキストエンコーダーのGLM-4-9Bはこれに含まれません。重みファイルの合計はDiTが約12.7GB、テキストエンコーダーが約17.6GB、VAEが約0.8GBで、リポジトリ全体では約31GBのダウンロードになります。

日本語のプロンプトは使えますか？

公式が対応言語として挙げているのは中国語と英語だけです。日本語が学習データに含まれないとする公式記述や、日本語での品質を判断できる評価結果は確認できません。公式も生成前にLLMでプロンプトを書き直すことを推奨しており、英語か中国語に整えてから渡すほうが安定します。

商用利用はできますか？

できます。モデル重みはApache License 2.0で公開されており、収益規模による制限や別途の登録要件は付いていません。ただし再配布する場合はライセンスの添付・変更ファイルの変更表示・著作権表示やNOTICEの保持といったApache-2.0の条件に従う必要があり、生成物の取り扱いは利用するAPI事業者の規約や各国の法令にも従います。

ローカル実行にはどれくらいのVRAMが必要ですか？

BF16・バッチサイズ4の公式計測で、CPUオフロードなしなら33〜39GB、オフロードを有効にすると20GB、さらにテキストエンコーダーを4bit量子化すると13〜14GBです。対応精度はBF16とFP32で、FP16は使えません（オーバーフローで真っ黒な画像になると公式が明記しています）。システムRAMは32GB以上が推奨されています。

関連記事

• GLM（Z.ai）とは？最新バージョンGLM-5.2までの世代一覧と選び方・料金・使い方
• Stable Diffusion 3とは？SD3.5との違いと2026年時点の入手・動作環境
• FLUX.2の全5モデル比較｜Flex・Max・Pro・Dev・Kleinの違いと選び方【2026年最新】
• Muse Imageとは？Metaの画像生成AIの仕組み・料金・API提供状況を実装目線で解説【2026年7月】
• GLM-OCRとは？0.9Bの実体と日本語精度・vLLM/Ollama導入手順とAPI料金