CogView4-6Bとは？diffusersでの使い方・必要VRAMと2048×2048が仕様外になる理由

CogView4-6Bは、智譜AI（Z.ai）が2025年3月に公開したオープンな画像生成モデルです。Hugging Faceのdiffusersから数行で呼び出せますが、実際に動かすとVRAM、解像度、プロンプトの言語の3点でつまずきやすいモデルでもあります。この記事では、インストールから最小コード、テキストエンコーダーを4bit化してVRAMを13GB台まで下げる方法、モデルの構成、そして「2048×2048対応」という広く出回った説明が公式仕様と合わない理由までを、公式モデルカード・GitHub・diffusersのソースで確かめた数字だけで整理します。

まとめ

• 動かす手順：pip install diffusers transformers accelerateのあと、CogView4PipelineをBF16で読み込みます。diffusersは2025年4月のv0.33.0から正式に同梱しており、2026年10月27日公開の0.42.1にも残っています。ソースからのインストールはもう不要です。
• 必要VRAM：CPUオフロードなしで33〜39GB、オフロードありで20GB、さらにテキストエンコーダーを4bit量子化すると13〜14GBです（公式計測・BF16・バッチ4）。FP16は真っ黒な画像になるので使えません。
• 「6B」はDiT（画像生成側）だけの値で、テキストエンコーダーのGLM-4-9Bは別勘定です。ダウンロードは全体で約31GBあります。
• 2048×2048は仕様外です。公式の制約は「各辺512〜2048px・32の倍数・総画素数2の21乗以下」で、正方形なら1440×1440が上限です。公式は2025年3月11日にREADMEから2048×2048の行を削除しています。
• プロンプトは英語か中国語で書きます。日本語は公式の対応言語に入っていません。
• 2026年11月時点では新規採用の第一候補ではありません。公式リポジトリの更新は2025年3月で止まり、Z.aiのAPIでも主役はGLM-Imageに移りました。CogView4-6Bを選ぶのは、手元のGPUが16GB級で、Apache-2.0のモデルをローカルで回したい場合です。

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系のモデルでは重みファイルの実サイズを先に確かめてください。

DiT・GLM-4エンコーダー・Flow Matchingの構成

CogView4-6Bは、Stable Diffusion 1.x／SDXLのようなU-Netではなく、Transformerでノイズを取り除くDiT（Diffusion Transformer）を採用しています。transformerのconfig.jsonによると、DiTは28層・32ヘッド×128次元（隠れ次元4,096）で、潜在画像を2×2のパッチに切ってトークン化します。

VAEは画像を縦横1/8の潜在表現に圧縮し、DiTはそれを2×2ずつまとめて扱います。1024×1024の画像なら潜在は128×128、トークンは64×64＝4,096個です。1440×1440では8,100個と約2倍になり、注意計算の一部はトークン数の2乗に応じて増えますが、生成全体の所要時間はGPUや実装、オフロード条件にも左右されます。スケジューラーは拡散のノイズ予測ではなくFlow Matching系で、use_dynamic_shiftingが有効なため、画像のトークン数に応じてノイズの刻みが自動で調整されます。

テキスト側は、前世代CogView3-Plus-3BのT5-XXL（英語のみ・224トークン）から、GLM-4-9B（中国語と英語・1024トークン）に置き換わりました。長いプロンプトを読めるのはこのエンコーダーのおかげで、VRAMの大半を食うのも同じエンコーダーです。

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

公式GitHubの比較表では、Prompt Languageは中国語と英語、Prompt Length Limitは1024トークンです。diffusersのCogView4Pipelineもmax_sequence_lengthの既定値を1024にしています。日本語は対応言語に挙がっていませんが、公式資料は日本語を学習に含めないとまでは書いておらず、日本語での品質を測った評価結果もありません。判断材料が無いので、英語か中国語に翻訳して渡すのが確実です。

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

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

モデル重みはHugging FaceのモデルカードでApache License 2.0と明記されています。商用利用・改変・再配布ができ、再配布時はライセンスの添付、変更ファイルへの変更表示、著作権表示やNOTICEの保持が条件です。Stability AIのCommunity Licenseのような年間収益による商用可否の切り替えはありません。生成AIを社内業務へ組み込むときのライセンス確認や運用ルールづくりは、当社の生成AI導入支援でも扱っています。

diffusersでCogView4-6Bを動かす手順

インストールと最小コード

モデルカードのQuick Startはdiffusersをソースからインストールする手順のままですが、これは公開直後の暫定措置です。CogView4Pipelineはdiffusers v0.33.0（2025年4月9日）から正式リリースに入り、PyPIの最新版0.42.1（2026年10月27日）でも同じ場所にあります。PyPI版で足ります。

pip install "diffusers>=0.33.0" transformers accelerate torch

次のコードは公式サンプルを基に、解像度を仕様内の正方形の上限である1440×1440にしたものです。本文で参照するdiffusers 0.42.1にはPython 3.11以上が必要です。掲載コードの構文は確認していますが、GPU環境で画像生成の完走までは検証していません。

import torch
from diffusers import CogView4Pipeline

pipe = CogView4Pipeline.from_pretrained(
    "zai-org/CogView4-6B", torch_dtype=torch.bfloat16
)
pipe.enable_model_cpu_offload()  # VRAMを約20GBに抑える
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")

パラメータの既定値には注意が要ります。diffusersの__call__はguidance_scaleの既定が5.0ですが、公式サンプルと公式CLI（cli_demo_cogview4.py）は3.5を指定しています。公式の画作りに合わせるなら3.5を明示してください。公式CLIの解像度の既定は1280×720ですが、720は32で割り切れないため、モデルカードの条件に沿うなら1280×704などに直して使います。

テキストエンコーダーの4bit量子化とVRAM削減手順

公式VRAM表の「13GB」は、テキストエンコーダーだけをbitsandbytesで4bitに量子化し、CPUオフロードを併用した値です。手順は公式CLIスクリプトにコメントとして残っています。このコメント例を基にしたコードを以下に示します。構文は確認していますが、4bit量子化とCPUオフロードを併用した画像生成の完走は未確認です。

pip install bitsandbytes

import torch
from diffusers import CogView4Pipeline
from transformers import BitsAndBytesConfig, GlmModel

model_id = "zai-org/CogView4-6B"
text_encoder = GlmModel.from_pretrained(
    model_id,
    subfolder="text_encoder",
    quantization_config=BitsAndBytesConfig(load_in_4bit=True),
    torch_dtype=torch.bfloat16,
)
pipe = CogView4Pipeline.from_pretrained(
    model_id, text_encoder=text_encoder, torch_dtype=torch.bfloat16
)
pipe.enable_model_cpu_offload()
pipe.vae.enable_slicing()
pipe.vae.enable_tiling()

image = pipe(
    prompt="A watercolor illustration of a lighthouse at dawn",
    guidance_scale=3.5,
    width=1024,
    height=1024,
).images[0]
image.save("cogview4_4bit.png")

公式スクリプトはローカルパスに"/text_encoder"を連結していますが、Hugging FaceのリポジトリIDを直接渡すならsubfolder引数を使います。量子化するのはテキストエンコーダーだけで、DiTはBF16のままです。DiT側も削りたい場合は、公式のcli_demo_cogview4_int8.pyにTorchAOのint8_weight_onlyで両方を量子化する例があります。量子化そのものの考え方はQLoRAとは？4bit量子化＋LoRAの仕組み・VRAM目安・実装手順と採用判断を解説【2026年版】で詳しく扱っています。

LLMによるプロンプト書き換え（prompt_optimize.py）

CogView4は長く具体的な説明文で学習されているため、公式は生成前にLLMでプロンプトを膨らませることを強く推奨しています。リポジトリのinference/prompt_optimize.pyがその道具で、OpenAI互換APIを呼び、短い指示を「主題・画材・スタイル・色・光」まで書き込んだ説明文に変換します。既定の接続先はhttps://open.bigmodel.cn/api/paas/v4、モデルはglm-4-plusで、--base_urlと--modelで別のOpenAI互換APIにも向けられます。

スクリプト内のCogView4用システムプロンプトは「入力が英語なら英語、中国語なら中国語で出力する」と定めており、日本語の入力は想定していません。日本語で考えた指示は、先に英語へ訳してから--promptに渡してください。

LoRA・ControlNetを学習するときの選択肢

公式リポジトリに学習コードはなく、READMEは3つの経路を案内しています。2026年11月時点で更新が続いているのはfinetrainers（2026年9月23日更新）で、2025年3月7日にCogView4対応、同年4月12日にCogView4向けの制御条件付き学習が入りました。公式のCogKitは2025年5月14日で更新が止まっています。ControlNetを自前で学習するなら、diffusersのexamples/cogview4-controlに学習スクリプトがあります。

学習済みLoRAはCogView4PipelineがLoRAローダーを継承しているので、pipe.load_lora_weights(...)で読み込めます。Hugging Face上の公開例はfinetrainersが作ったタロット画風のLoRAなど少数で、SDXLやFLUXのような豊富な配布資産は期待できません。

必要VRAMと実行構成の選び方

公式のVRAM計測はBF16・バッチサイズ4での参考値です。表の1280×720は高さが32の倍数ではなく、1920×1280は2,457,600画素で2の21乗を超えるため、モデルカード自身の解像度条件と合いません。公式掲載値の転載として読んでください。

512×512まで落としてもオフロードなしで33GBかかり、解像度による差は最大6GBしかありません。テキストエンコーダーの重みだけで約17.6GB、DiTが約12.7GBあり、常駐する重みが消費の大部分を占めるからです。そのためenable_model_cpu_offloadの効果が大きく、20GBまで一気に下がります。

手持ちのGPUで構成を決めるなら、次の目安になります。

• VRAM 40GB以上（A100 40GB・H100など）：オフロードなしで、生成の待ち時間を最短にできます。
• VRAM 24GB（RTX 4090など）：公式計測ではCPUオフロード時に20GBです。実際の消費量は実行条件によって変わり、重みの転送による待ち時間も発生します。
• VRAM 16GB：テキストエンコーダーの4bit化とオフロードの併用が前提です。
• 12GB以下：掲載された公式計測値は容量を超えます。ローカル実行の可否は別途検証が必要なため、APIや別モデルも検討します。

どの構成でも、公式はシステムRAMを32GB以上にするよう推奨しています。オフロードした重みはRAMに置かれるため、不足するとプロセスが強制終了されるおそれがあります。

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

総画素数2の21乗という上限と解像度の例

モデルカードの推論要件は次の一文です。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. 条件は「512px以上2048px以下」「32の倍数」に加えて、総画素数が2の21乗（2,097,152）以下の3つです。2048×2048は4,194,304画素、つまり2の22乗なので、3つ目の条件をちょうど2倍超えます。「2048pxまで」は辺の長さの上限で、面積の上限ではありません。

2,097,152の平方根は約1448.2ですが、1448は32で割り切れないため、正方形の最大は1440×1440です。長辺に2048pxを使うなら、短辺は2,097,152÷2048＝1024pxまでです。

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

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言語から同時に消えています。

当社がこの記事の初版を公開したのは2025年3月6日で、削除の5日前でした。当時の表の数字を引いたまま訂正を反映できていなかったため、2026年9月に改めています。日本語の解説記事には、いまも削除前の表を引いた記述が残っています。

diffusersの解像度検査とモデルカードの制約との差

紛らわしいのは、diffusersが画素数の上限を見ないことです。0.42.1のpipeline_cogview4.pyでも、check_inputsが検証するのは「高さと幅が16の倍数か」だけで、32の倍数も2の21乗の上限も確かめていません。2048×2048を渡しても解像度の検査では例外が出ず、推論に進みます。ただし検査を通ることと、メモリ不足なども含めて生成が最後まで成功することは別です。エラーが出ないことを公式の対応範囲と読み替えないでください。

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

公式がベンチマーク表に並べている比較対象は、SD3.5ではなくSD3-Mediumです。SD3とSD3.5の違いはStable Diffusion 3とは？SD3.5との違い・API料金・ローカル環境と開発状況【2026年11月】で整理しています。

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で表中2位ですが、1位のJanus-Pro-7B（0.79）とは開きがあり、T2I-CompBenchの2D-Spatialも0.3075とSD3-Mediumの0.3200に届きません。T2I-CompBenchのNumeracyでは表中最高ですが、GenEvalのCountingではSD3-MediumやFlux.1-devを下回るため、数の正確さは用途別に比較が必要です。また、配置の正確さが最優先ならJanus-Pro-7BやSD3-Mediumも比べる価値があります。

中国語の文字描画では差がはっきり出ます。Kolorsとの比較でF1が0.6168対0.2880、Pick@4が0.3265対0.1633です。ただし評価対象は中国語の文字だけで、比較相手もKolors 1本です。日本語の漢字や仮名の描画品質はこの数字から読み取れません。いずれも2025年3月時点の公式自己申告値で、2026年に出た後発モデルとの比較ではない点にも注意してください。

2026年11月時点の入手性・API・保守状況

関連リポジトリの更新状況

以下は2026年11月4日時点の取得記録です。GitHubの日付は最終プッシュ、Hugging Faceの日付はリポジトリの最終変更を示し、保守終了日や重みの更新日とは限りません。

READMEのProject Planに残る「ControlNet models and training code」は、公開から1年8か月たっても未チェックのままです。Hugging Faceの累計ダウンロードは1,751,056件ありますが、直近30日は5,698件にとどまります。ComfyUIで使う経路もコミュニティ製ラッパーだけで、2025年3月から更新されていません。「コミュニティがこれから育てる」前提で採用を決めるのは、2026年時点では現実に合いません。

Z.ai APIでのCogView-4の扱い

ローカルにGPUを用意しないなら、Z.aiのAPIでCogView-4を呼べます。ただし扱いは縮小しています。公式料金表の画像生成モデルの本表に載るのはGLM-Image（1枚0.015ドル）だけで、CogView-4（1枚0.01ドル）は「Other Pricing」の折りたたみ欄へ移りました。画像生成APIのリファレンスでも、modelの列挙値はglm-imageだけです。一方、CogView-4のガイドには次の呼び出し例が残っています。

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"
  }'

リファレンスに残るGLM-Image以外のモデルのsize条件は、512px以上2048px以下・16の倍数・総画素数2の21乗以下です。倍数の条件だけローカルより緩く、面積の上限は同じなので、APIでも2048×2048は通りません。qualityはstandard（5〜10秒）が既定で、hdは約20秒です。リファレンスの主対象から外れた以上、これから新しく組み込むシステムの呼び出し先には選ばないほうが安全です。

GLM-Imageとの使い分けと、CogView4-6Bを選ばない場面

Z.aiが2026年1月14日に発表したGLM-Image（Hugging Faceのリポジトリ作成は1月8日）が、同社の画像生成の主軸です。likesは1,127とCogView4-6Bの4倍を超え、diffusers 0.42.1には専用のglm_imageパイプラインも入りました。構成は自己回帰生成器（GLM-4-9B-0414から初期化した9B）と、Glyph Encoderを備えた7BのDiTデコーダの組み合わせです。ライセンスは全体がMITですが、組み込まれたVQ tokenizerとViTの重みにはApache-2.0が残ります。

解像度の差がいちばん実務に効きます。GLM-ImageのAPI制約は1024〜2048px・32の倍数・総画素数2の22乗以下なので、2048×2048の正方形がちょうど上限に収まります。2048×2048を出したいなら、選ぶべきはGLM-Imageです。Z.aiのモデル系譜全体はGLM（Z.ai）とは？最新GLM-5.3までの世代一覧と料金・使い方にまとめています。

CogView4-6Bを選ぶ理由が残るのは、すでにCogView4で動いている環境を維持する場合と、手元のGPUが16GB級の場合です。GLM-Imageの公式手順はCPUオフロードでも約23GBが目安とされ、13GB台まで落とせるCogView4-6Bのほうが収まります。逆に、ComfyUIのノードとして使いたい、更新が続くモデルにワークフローを載せたい、配布LoRAの多さで選びたい、日本語のプロンプトを直接投げたい、のどれかに当てはまるなら候補から外して構いません。ローカルで動く画像生成モデルの選択肢はFLUX.2の全5モデル比較｜Flex・Max・Pro・Dev・Kleinの料金と違い、FLUX 3 Imageとの選び方【2026年10月】で比べられます。

よくある質問

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

公式モデルカードの対応範囲外です。総画素数の上限は2の21乗（2,097,152ピクセル）で、2048×2048は4,194,304ピクセルとその2倍です。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のダウンロードになります。

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

公式が対応言語として挙げているのは中国語と英語だけです。日本語を学習から外したとする公式記述も、日本語での品質を測った評価結果もありません。公式のプロンプト最適化スクリプトも英語と中国語の入力しか想定していないので、英語か中国語に訳してから渡してください。

商用利用はできますか？

できます。モデル重みはApache License 2.0で、収益規模による制限や別途の登録はありません。再配布する場合はライセンスの添付・変更ファイルの変更表示・著作権表示やNOTICEの保持に従います。Hugging Face上の第三者LoRAは配布元ごとにライセンスが違うため、個別に確認が必要です。

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

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

関連記事

• GLM（Z.ai）とは？最新GLM-5.3までの世代一覧と料金・使い方
• Stable Diffusion 3とは？SD3.5との違い・API料金・ローカル環境と開発状況【2026年11月】
• FLUX.2の全5モデル比較｜Flex・Max・Pro・Dev・Kleinの料金と違い、FLUX 3 Imageとの選び方【2026年10月】
• Qwen-Image-Edit-2509とは？使い方・必要VRAM・ComfyUI・2511/2.1との違い【2026年10月】
• Muse Imageとは？Metaの画像生成AIの使い方・API料金（1枚0.01ドル）と日本での提供状況【2026年10月】