diffusers

Glitch-Img-1.0: RGBA Image Generation & Editing with Qwen-Image-2.1 Glitch-Img-1.0: RGBA Image Generation & Editing with Qwen-Image-2.1 > Try it: huggingface.co · image-gen demo Space Image generation has moved past "pretty pictures" toward controllable, editable, transparent assets. Glitch-Img-1.0 is my re-upload of Qwen/Qwen-Image-2.1 under the name ISLAM-PO/Glitch-Img-1.0, aimed at making a strong unified text-to-image + editing model easy to discover and use from a single, well-documented repository. All weights and configs are unchanged from the original; only the README and repo IDs were updated, and the model is Built with Qwen under the Qwen Research License (non-commercial). This report covers what the model does, its key capabilities, a quick-start, memory tips, and licensing notes. --- 1. What It Is - Base model: Qwen/Qwen-Image-2.1 - Visual generation component: ~7B parameters (32 Single-Stream DiT layers) - Pipeline tag: text-to-image (diffusers: QwenImage21Pipeline) - License: Qwen Research License Agreement (non-commercial) - Modifications in this re-upload: README renaming, repo-ID updates, attribution notes. Weights/configs unchanged. Four headline improvements define the Qwen-Image-2.1 family this build inherits: 1. Compact & efficient — mixed-granularity attention + prefix KV-cache reuse for strong quality at low cost. 2. Native transparency (RGBA) — generate regular or transparent images, edit transparent layers, extract subjects from photos — all in one model. 3. Versatile editing — up to 10 reference images, local edits via circles/painted annotations/masks, identity preservation for people and products. 4. Realistic textures & refined aesthetics — improved typography, portrait lighting, and fine details. 2. Capabilities in Practice | Capability | Details | |---|---| | Text-to-image | Prompts up to 2048×2048 and beyond; strong text rendering | | Image editing | Inpainting-style edits, background swaps, style transfer | | RGBA transparency | Native alpha channel generation with a documented prompt format | | Multi-reference | Up to 10 reference images for identity/subject consistency | | Local edits | Circles, painted annotations, separate masks | | Aspect ratios | 1:1, 4:3, 3:4, 3:2, 2:3, 16:9, 9:16 presets | 3. Quick Start Install: pip install torch>=2.4.0 pip install transformers>=5.17 pip install git+https://github.com/huggingface/diffusers pip install accelerate pillow Text-to-image: import torch from diffusers import QwenImage21Pipeline pipe = QwenImage21Pipeline.from_pretrained( "ISLAM-PO/Glitch-Img-1.0", torch_dtype=torch.bfloat16 ).to("cuda") image = pipe( prompt='A neon shop sign that reads "GLITCH IMG 1.0", rainy night, reflections on wet pavement', width=2048, height=2048, num_inference_steps=40, generator=torch.Generator("cuda").manual_seed(42), ).images[0] image.save("t2i_example.png") Image editing: import torch from PIL import Image from diffusers import QwenImage21Pipeline pipe = QwenImage21Pipeline.from_pretrained( "ISLAM-PO/Glitch-Img-1.0", torch_dtype=torch.bfloat16 ).to("cuda") input_image = Image.open("input.png") image = pipe( prompt="Change the background to a sunset beach", image=input_image, num_inference_steps=40, generator=torch.Generator("cuda").manual_seed(42), ).images[0] image.save("edit_example.png") Transparent (RGBA) generation — use the recommended prompt format: image = pipe( prompt="This is an RGBA image with transparency. A cute cartoon dragon sticker. " "The image has alpha channel and the background is transparent.", width=2048, height=2048, num_inference_steps=40, generator=torch.Generator("cuda").manual_seed(42), ).images[0] image.save("transparent_example.png") Aspect ratios: aspect_ratios = { "1:1": (2048, 2048), "4:3": (2400, 1792), "3:4": (1792, 2400), "3:2": (2528, 1696), "2:3": (1696, 2528), "16:9": (2752, 1536), "9:16": (1536, 2752), } 4. Memory Optimization pipe = QwenImage21Pipeline.from_pretrained( "ISLAM-PO/Glitch-Img-1.0", torch_dtype=torch.bfloat16 ) pipe.enable_model_cpu_offload() This offloads model parts to CPU between steps, letting you run on smaller GPUs at the cost of speed. 5. Where It Fits in My Stack I use Glitch-Img as the visual layer behind my portfolio and product work: - Generating marketing assets and transparent stickers/logos for client sites. - Editing product photos (background swap, identity-preserving edits). - Producing RGBA assets that drop straight into web UIs without manual masking. It complements MasryGPT (text) as the two halves of an Arabic-first AI product stack: one generates the words, the other the visuals. 6. Licensing & Attribution - Licensed under the Qwen Research License Agreement — non-commercial use only. - Original work © 2026 Hangzhou Tongyi Laboratory Technology Co., Ltd. - This re-upload is Built with Qwen and based on Qwen/Qwen-Image-2.1. - For commercial use, request a license at model-business@notice.qwencloud.com. - See NOTICE and LICENSE in the repo for required attribution. 7. Links - Model: huggingface.co - Demo Space: huggingface.co - Original: huggingface.co - Upstream GitHub: QwenLM/Qwen-Image-2.1 --- Author: Islam Al-Nashar — Full-Stack Developer & AI builder. GitHub · Hugging Face · Portfolio

⚠️ تستخدم مكتبة Diffusers لتوليد الصور؟ حدّثها الآن! أصدرت Hugging Face التحديث الأمني 0.42.1 لسد ثغرة كانت تسمح بتجاوز حماية trust_remote_code عند تحميل النماذج عبر from_pretrained، وتوصي به كل مستخدمي 0.42.0: pip install diffusers==0.42.1 github.com/huggingface/diffusers/releases/tag/v0.…

想用 Python 跑 AI 生图模型？🎨 Hugging Face Diffusers 提供现成的扩散模型管线，能做图像生成和模型实验。显存需求取决于模型。🧪 huggingface/diffusers #ImageGen #浇朋友 #蓝朋友 #互关 #fo

🔥 [1 Repo Every Developer Should Know] diffusers: The Free Tool Taking Over GitHub! #shorts Discover huggingface/diffusers: Diffusers: State-of-the-art diffusion models for image, video, and audio generation in PyTorch. 💬 Comment "DIFFUSERS" below for the direct link, or grab it from the links below: 👉 Interactive Star History & Live Analysis: githubrepo.cloud ⭐ Embed Live Verified Badges in your README: githubrepo.cloud 🔗 Direct GitHub Repository: huggingface/diffusers 📊 Repository Specs: ⭐ Stars: 34,753 🍴 Forks: 7,403 💻 Language: Python 📜 License: Apache-2.0 #shorts #diffusers #deeplearning #diffusion #flux #imagegeneration #musicproducer #audioengineer #stems

FLUX.3 Image Klein は GPT Image 2.5 の代わりになる？ 座標で配置できる無料モデルを Mac で比べた !FLUX.3 Image Klein は GPT Image 2.5 の代わりになる？ 座標で配置できる無料モデルを Mac で比べた はじめに 「人物は左、商品は右、背景の建物は真ん中に」。画像生成 AI にこう頼んでも、出てくる画像はたいてい「だいたい合っている」止まりです。ブログのアイキャッチのように文字とイラストの位置が決まっている画像を作りたいときは、何度も作り直すことになりがちです。 2026年10月15日、Black Forest Labs（BFL）が公開した FLUX.3 Image Klein（以下 FLUX.3 Klein）は、この悩みに正面から答えるモデルです。文章から画像を作る機能、参照画像を使った編集、そして座標の枠（バウンディングボックス）で「どこに何を置くか」を指定する機能を、5.6B（56億パラメーター）の1つのモデルにまとめています。重みは公開されていて、条件付きで無料で使えます。 一方、ChatGPT で多くの人が使っている画像生成は、OpenAI が2026年9月に出した最新モデル GPT Image 2.5（ChatGPT では「Images 2.5」）です。そこで気になるのは次の点です。 - 手元の Mac で動く無料のモデルは、ChatGPT の画像生成とどこまで張り合えるのか - 「座標で置ける」ことは、文章で位置を伝える GPT Image 2.5 に比べて本当に有利なのか - アイキャッチ（16:9）と X 用バナー（5:2）を、同じ構成で作り分けられるのか この記事では、同じ8種類のお題を ChatGPT（Images 2.5） と Mac 上の FLUX.3 Klein の両方に出し、画質・文字・配置・編集・速さ・費用・ライセンスを並べて比べます。FLUX.3 Klein を Mac で動かす手順とコードも載せます。 想定している読者は、画像生成 AI を ChatGPT などで使ったことがあり、「ローカルで動く画像モデルはどのくらい使えるのか」が気になっている方です。Python の基本が分かれば、手順はそのまま再現できます。 !同じ日本語のお題を、ChatGPT（Images 2.5）と、Mac 上の pup→FLUX.3 Klein の2つの経路で画像にし、画質・文字・配置・縦横比・編集・速さと費用で比べる流れ図 図1：比較の全体像。お題は共通で、違うのは画像になるまでの経路 この記事の確認範囲 - 確認日：2026年10月16日（日本時間） - FLUX.3 Image Klein：蒸留版 black-forest-labs/flux-3-image-klein（16ステップ）を、Mac（Apple M5 Max・メモリ128GB）で Diffusers（0.41.0.dev0、GitHub の main）から実行。公式のプロンプト拡張モデル（pup）も同じ Mac で実行 - GPT Image 2.5：chatgpt.com（Chat モード）で生成。API では試していません。ChatGPT では Flare と Sunburst のどちらが使われたかは表示されません - 出典：Hugging Face 公式ブログ「Welcome FLUX.3 Image Klein in Diffusers」（2026-10-15）、BFL のブログとモデルカード・推論コード、OpenAI の発表と API ドキュメント - 画像の良し悪しの判定は筆者の目視です。配置は指定した枠を画像に重ねて確認しました。各お題は FLUX が3シード（0〜2）、ChatGPT が1回です FLUX.3 Image Klein とは 3つの仕事を1つのモデルで FLUX.3 Image Klein は、BFL の新しい世代「FLUX 3」の2つ目のオープン重みモデルです（1つ目はロボット制御用の FLUX 3 Action）。「Klein」はドイツ語で「小さい」という意味で、FLUX 3 の上位モデルと同じ機能を、小さな体格に収めた版という位置づけです。 1つのモデルで、次の3つをこなします。 | 仕事 | 入力 | できること | |---|---|---| | 文章から画像（Text-to-Image） | 文章 | 1枚の画像を新しく作る | | 参照画像からの生成・編集（Image-to-Image） | 文章＋画像（最大10枚） | 夜に変える、別の写真の物を合成する、など | | 配置の指定（Layout Control） | 文章＋座標の枠 | 「この枠にカメラ、この枠に見出し」と置き場所を指定する | 公開されたのは2種類のチェックポイント（学習済みの重みのファイル）です。 | チェックポイント | ステップ数 | CFG | 向いている用途 | |---|---|---|---| | flux-3-image-klein（蒸留版） | 16 | なし | 普段の生成・編集。BFL の API もこれ | | flux-3-image-klein-base（Base 版） | 50 | あり（3.5） | LoRA などの追加学習、研究 | 蒸留（distillation）は、大きく手間のかかる手順を、少ない手順でまねできるように学習し直すことです。Base 版が50回かけてノイズを取り除くところを、蒸留版は16回で済ませます。CFG（Classifier-Free Guidance）は、プロンプトありとなしの2回分を計算して差を強める仕組みで、なくせば1回分の計算で済みます。BFL の README では、H200 で 1MP（約100万画素）の画像を作る時間が蒸留版で約3秒、Base 版で約12秒と書かれています。 Hugging Face の H100 での計測では、蒸留版が 1024×1024 を 1.93秒 で作り、参照画像を1枚入れた編集は 3.87秒でした。参照画像はそのぶんトークン（モデルが扱う単位）が増えるため、時間がほぼ倍になります。 中身は「4つの部品」と「2段階の本体」 図2で、短い依頼が画像になるまでの流れを見てください。紫の pup から始まり、本体の前段・後段を経て、右端の VAE で画像に戻ります。 !FLUX.3 Klein の構成図。pup が短い依頼を詳しいキャプションに広げ、Qwen3-VL-4B が読み、本体の前段5ブロックで文章・生成中の画像・参照画像を別々に処理し、後段28ブロックで1列につないで処理し、VAE で画像に戻す 図2：FLUX.3 Klein の中身（HF ブログとモデルカードをもとに作図） 部品は次の4つです。 1. pup（プロンプト拡張モデル）：Qwen3.5-9B を BFL が調整した 9B のモデル。「午後の光の商品写真」程度の短い依頼を、被写体・光・構図・色まで決めた英語の長いキャプションに書き直します。依頼は日本語でもかまいませんが、出力は英語です 2. テキストエンコーダー（Qwen3-VL-4B）：キャプションを読み、数値の列に変えます。最終層だけでなく、36層のうち8層の途中結果を束ねて渡すのが特徴です 3. 本体（5.6B のトランスフォーマー）：ここで画像を描きます。前段の5ブロックでは「文章」「生成中の画像」「参照画像」がそれぞれ別の重みで下ごしらえされ、後段の28ブロックでは全部を1列につないで、お互いを参照しながら仕上げます 4. VAE：画像を小さな潜在表現（16×16 画素を1トークンにまとめたもの）に変えたり、戻したりする部品です。FLUX.2 と同じものです pup は「付けたほうがよい」ではなく「付ける前提」 ここは使う前に必ず知っておきたい点です。BFL のモデルカードと推論コードの README には、太字で 「プロンプト拡張なしでモデルを使わないこと」 と書かれています。本体は pup が書く長いキャプションで学習されているため、短い文章をそのまま渡すと、ありきたりな画像になるそうです。 ところが、Diffusers のパイプラインは pup を自動では呼びません。Diffusers の例のように pipe(prompt="a red fox") と書くだけでは、本来の力を出せない使い方になります。この記事では、公式の推論コードと同じシステムプロンプト・同じデコードの設定で pup を Mac 上で動かし、そのキャプションを本体に渡しました（公式との細かな違いと手順は後半で紹介します）。pup を通さなかった場合の画像も、比較のために作っています。 座標で配置する仕組み 枠は [上, 左, 下, 右] を 0〜1000 で書く 配置の指定では、プロンプトの最後に JSON の配列で「枠の表」を付けます。1行が1つの物で、id（名前）、bbox（枠）、desc（説明）を持ちます。キャプションの本文では、その物を <camera_1> のように id で呼びます。 枠の数字は [y_min, x_min, y_max, x_max]、つまり「上・左・下・右」の順で、画像の大きさに関係なく 0〜1000 の目盛りで書きます。図3でこの読み方と、同じ枠を別の縦横比に使い回す様子を確認してください。 !枠の座標を上・左・下・右の順に 0〜1000 で書く例。16:9 の画面に見出し・カメラ・植木鉢・ロボットの枠を置き、同じ数字のまま 5:2 の画面にも当てはめた図 図3：枠の座標の読み方。同じ数字が縦横比の違う画面にもそのまま使える ふだん目にする座標は (x, y) の順が多いので、縦が先という点はつまずきやすいところです。x を先に書くと、縦長の枠が横長になってしまいます。なお、公式の推論コードに渡す boxes.json は 0〜1 の小数で書き、内部で 0〜1000 に変換されます。Diffusers に直接キャプションを渡すときは 0〜1000 です。 目盛りが画像の大きさに依存しないので、16:9 のアイキャッチで決めた枠を、そのまま 5:2 のバナーにも使えます。今回の検証でも、この性質を試しました。 なぜ枠が効くのか FLUX.3 では、トランスフォーマーの中で各トークンに「どこにあるか」を教える位置の情報（RoPE と呼ばれる回転式の位置埋め込み）を、時刻・縦・横・並び順の4つの軸で持たせています。参照画像も出力画像と同じ縦横の座標を使うため、「参照画像のこの場所」と「出力のこの場所」が対応します。編集で src_bbox（元の場所）から tgt_bbox（移動先）へ物を動かせるのは、この仕組みのおかげです。 また、文章と参照画像のトークンは常に「時刻0＝もう完成している文脈」として扱われ、生成中の画像だけが現在の時刻で処理されます。参照画像が出力とほとんど同じに見えても、モデルは「描き直す対象」ではなく「手がかり」として読むわけです。 ただし、モデルカードには 「枠は置き場所と大きさの目安で、ピクセル単位のマスクではない」 とも書かれています。枠からのはみ出しや少しのずれは起こりうる、という前提で使うのが正確です。 比べる相手：GPT Image 2.5 OpenAI は2026年9月8日に ChatGPT Images 2.5 を発表しました。ChatGPT・ChatGPT Work・Codex のすべてのプランで使え、Images 2.0 と比べて待ち時間を最大50%短くしたとしています。参照写真の人物や物の特徴を保つ力、狙った箇所だけを直す編集、何度も直したときの一貫性が改善点として挙げられています。 API では2つのモデルに分かれています。 | モデル | 位置づけ（OpenAI の説明） | |---|---| | gpt-image-2.5-flare | ほとんどの用途の標準。GPT-Image-2 より高品質で、待ち時間は50%短い | | gpt-image-2.5-sunburst | 時間をかけて、編集をより精密に制御する用途向け | 料金は2つとも同じで、100万トークンあたり文章入力 5ドル、画像入力 8ドル、画像出力 30ドル です。1枚あたりの値段は品質（low〜max）と大きさで変わります。参考までに、1つ前の GPT Image 2 の 1024×1024 は low 0.006ドル、medium 0.053ドル、high 0.211ドルです。 FLUX.3 Klein と比べるうえで大事なのは、API ドキュメントにバウンディングボックスで配置を指定する機能の記載がない点です。編集用のマスク（変えてよい範囲を塗った画像）は使えますが、ドキュメント自身が「形に厳密に従うとは限らない」「レイアウトが重要な構図は正確に置くのが難しいことがある」と書いています。つまり GPT Image 2.5 で位置を指定する手段は、基本的に文章です。 そこで今回は、FLUX.3 Klein には枠を、ChatGPT には同じ枠を「横40〜60%・縦0〜60%」のような文章に直して伝え、どこまで位置が合うかを比べました。 | 項目 | FLUX.3 Image Klein（蒸留版） | GPT Image 2.5 | |---|---|---| | 提供のかたち | 重みを公開（Hugging Face で規約に同意） | ChatGPT・API のみ | | 大きさ | 本体 5.6B（テキストエンコーダー別） | 非公開 | | 位置の指定 | 座標の枠（0〜1000） | 文章、編集はマスク | | 参照画像 | 最大10枚 | 複数可（ドキュメントの例は4枚） | | 最大サイズ | 4K まで（BFL） | 1辺3840px・約830万画素まで | | 料金 | 自分の PC なら電気代のみ。BFL API は1枚 約0.9セント〜 | ChatGPT はプランの範囲、API は従量課金 | | 生成画像の印 | 推論コードは EXIF に「AI generated」 | C2PA メタデータと見えない電子透かし | 検証のやり方 8つのお題 お題はすべて日本語で書き、ChatGPT にも FLUX.3 Klein の pup にも同じ文章を渡しました。ChatGPT には頭に「画像を生成してください。」だけを足しています。 | # | お題 | 見たいこと | |---|---|---| | 1 | 午後の光が差す木のデスクに置いた、黒いワイヤレスイヤホンケースの商品写真（正方形） | 写真としての質感 | | 2 | 英字の見出し「OPEN WEIGHTS NIGHT」と日時・3語の副題が入った縦長ポスター | 英字の正確さ | | 3 | 左に日本語の見出し「画像生成を座標で操る」と小見出し、右に枠で囲んだカメラ・植木鉢・ロボット（16:9） | 日本語の文字と、アイキャッチの構成 | | 3b | 3 と同じ構成の 5:2 バナー | 縦横比を変えても構成を保てるか | | 4 | 街角の写真。女性は左、エスプレッソの屋台は右、時計塔は中央の上半分（16:9） | ふつうの配置指定 | | 5 | 白地の 3×3 マスに、指定した9つの物を1つずつ | 多数の物の並び | | 8 | 部屋の写真。小さな風船は右下の隅、大きな観葉植物は左、黄色い椅子は中央下、青い時計は右上、本の山は左下（16:9） | 不自然な位置・大きさの指定 | | 6・7 | 1 の画像を「夜に変える」「ケースだけ右へ動かす」 | 編集で他の部分を残せるか | （番号の 6・7 は編集、8 はあとから追加した難しい配置のお題です。） 配置のお題では、FLUX.3 Klein には座標の枠を渡し、ChatGPT には同じ枠を「横40〜60%・縦0〜60%」のような文章で伝えました。さらに FLUX.3 Klein には、ChatGPT と同じ文章だけを渡す回（枠なし）も用意して、「枠そのものの効果」と「モデルの違い」を分けて見られるようにしました。 進め方 1. ChatGPT：お題ごとに新しいチャットを開いて1回だけ生成（5:2 バナーと編集は、元の画像と同じチャットで続けて依頼） 2. FLUX.3 Klein：pup でキャプションを作り、本体でシード 0・1・2 の3枚を生成。記事に並べるのは、事前に決めたとおりシード0の画像です 3. 配置は2つの方法で確認しました。1つは指定した枠を画像に重ねて目で見る方法、もう1つは物体検出モデル OWLv2 で各物の位置を自動で検出し、指定した枠との重なり具合（IoU）と「物の中心が枠の中にあるか」を数える方法です IoU（Intersection over Union）は、2つの四角形の重なった面積を、両方を合わせた面積で割った値です。完全に一致すれば1、まったく重ならなければ0になります。 環境 | 項目 | 内容 | |---|---| | Mac | Apple M5 Max（メモリ128GB）、macOS 26 | | Python | 3.12（uv で作った仮想環境） | | PyTorch | 2.14.1（MPS バックエンド） | | Diffusers | 0.41.0.dev0（GitHub の main） | | Transformers | 5.20.0 | | FLUX.3 Klein | 蒸留版、bf16（VAE は fp32）、16ステップ | | pup | bf16、貪欲デコード、presence penalty 1.5（公式と同じ値） | | ChatGPT | chatgpt.com（Chat モード）、2026-10-16 10:50〜11:10 | 結果：先に結論 8つのお題の結果を、先に表でまとめます。○△× は筆者の判定です。 | 比べたこと | GPT Image 2.5（ChatGPT） | FLUX.3 Klein（Mac） | |---|---|---| | 写真の質感（お題1） | ◎ 光・木目・小物まで自然 | ○ 自然。小物は少なめで素直な構図 | | 英字（お題2） | ◎ 正確 | ◎ 正確 | | 日本語（お題3） | ◎ 見出し・小見出しとも正確 | △ 遠目には読めるが「操」が13枚すべてで崩れた | | ふつうの配置（お題4・5） | ◎ 文章の指示でほぼ正しい位置 | ◎ 枠ありで全部の物が枠内。3×3 は文章だけでも全問正解 | | 不自然な配置（お題8） | ○ 5つ中4つが枠内（重なり 0.54） | ◎ 枠ありで15/15が枠内（重なり 0.81） | | 16:9 → 5:2（お題3b） | ◎ 会話で頼むだけでほぼ同じデザイン | ○ 同じ枠で配置は保てる。絵柄は別の1枚 | | 夜にする編集（お題6） | ◎ 卓上ライトまで描き足した。画像の縦横比が変わった | ○ 夜らしくなるかはシード次第（3枚中2枚は十分） | | 1つだけ動かす編集（お題7） | ◎ 文章だけで右へ移動、ほかはほぼそのまま | × 文章だけでは動かず ／ ◎ 枠を付けると指定どおり移動 | | 1枚の時間 | 約26秒 | 約28〜48秒（pup 込み、休ませた場合）。連続生成では約44〜66秒 | | 費用 | ChatGPT のプランの範囲 | 電気代のみ（Mac がある前提） | ひとことで言うと、完成度と日本語は GPT Image 2.5、位置を数字どおりに決める力は FLUX.3 Klein です。以下、お題ごとに見ていきます。 お題1：写真の質感 まずは基本の商品写真です。左が ChatGPT、中央が pup を通した FLUX.3 Klein、右が pup を通さず日本語の依頼をそのまま渡した FLUX.3 Klein です。 !黒いイヤホンケースの商品写真を3枚並べた比較。左がChatGPT、中央がpupありのFLUX、右がpupなしのFLUXで、pupなしはふたが開いている お題1。左から ChatGPT、FLUX（pup あり）、FLUX（pup なし） ChatGPT は、木目に落ちる葉の影、植木鉢・本・木の器といった小物まで描き込み、雑誌の商品写真のような仕上がりです。FLUX.3 Klein（pup あり）は小物を減らした素直な構図で、ケースの質感や窓からの光は十分に自然です。pup はキャプションに「小さな白い表示ランプ」「左から差す午後の光と右へ伸びる影」などの細部を書き足していて、実際に画像にも反映されています。 右の pup なしは、依頼にないのにケースのふたが開いた状態で描かれました。日本語の短い依頼でもそれらしい写真にはなりますが、細部はモデルまかせになる、というのが pup の有無の違いです。 お題2：英字ポスター !OPEN WEIGHTS NIGHT と書かれた縦長ポスター2枚の比較。どちらも英字は正確 お題2。英字はどちらも正確 英字は両者とも完璧でした。見出し「OPEN WEIGHTS NIGHT」、日時の「OCT 24 · TOKYO · 19:00」、「Talks / Demos / Drinks」の3行すべてで、つづりの誤りはありません。ChatGPT は見出しの「WEIGHTS」だけ色を変えるなどデザインの工夫まで入れてきます。FLUX.3 Klein は文字をそのまま素直に置いた印象で、立方体の光り方はこちらのほうが控えめです。 お題3：日本語のアイキャッチ ここが一番はっきり差が出たところです。 !画像生成を座標で操る という日本語見出しのアイキャッチ2枚の比較。左がChatGPT、右が枠を指定したFLUX お題3。左が ChatGPT、右が FLUX（枠あり・seed 0） 遠目には、どちらも「画像生成を座標で操る」「FLUX.3 Image Klein 検証」と読めます。構図は FLUX.3 Klein のほうが指定に忠実で、見出しは左、3つの物は右の枠の中に収まりました（枠ありの3枚で、カメラ・植木鉢・ロボットの重なりは平均 0.80）。ChatGPT には座標を伝えていないので、3つの物はそれぞれ別の立方体の枠に入る、ChatGPT なりの解釈になっています。 ところが拡大すると、FLUX.3 Klein の「操」は正しい字形ではありませんでした。 !見出しの「操」の字を拡大して並べた比較。正しい字形とChatGPTの2枚は右上が口3つの品だが、FLUXの4枚は口が2つや探に近い形に崩れている 「操」の拡大。ChatGPT は正しく、FLUX は13枚すべてで崩れた（うち4枚を掲載） 「操」の右上は「品」（口が3つ）ですが、FLUX.3 Klein は口が2つになったり、「探」に近い形になったりしています。枠あり・なし、16:9・5:2、3つのシードの計12枚に pup なしの1枚を足した 13枚すべてで崩れていました。ほかの文字（画像生成を座標で・る・検証）はおおむね正しく、pup なしの1枚では「標」も崩れていました。ChatGPT は 16:9 と 5:2 の両方で「操」まで正確です。 アイキャッチに日本語の見出しを焼き込むなら、現時点では GPT Image 2.5 のほうが安心です。FLUX.3 Klein を使うなら、絵の部分だけを作り、文字は画像編集ソフトで重ねるのが確実です。 お題3b：同じ構成で 5:2 のバナーにする !同じ構成の5対2バナー2枚を上下に並べた比較。上がChatGPT、下がFLUX お題3b。上が ChatGPT、下が FLUX（16:9 と同じ枠） ChatGPT は、16:9 を作った同じチャットで「同じデザインで 5:2 に」と頼むだけで、見出し・3つの物・背景の模様まで、ほぼ同じデザインのバナーを作りました。1983×793 で、X のヘッダー用にそのまま使える比率です。 FLUX.3 Klein は 16:9 と同じ枠を 1600×640 で使いました。配置はきちんと保たれ（見出しは左、物は右の枠内）、文字も読めます。ただし、カメラやロボットの絵柄は 16:9 版とは別物です。FLUX.3 Klein にとっては「同じ設計図で描いた別の1枚」なので、16:9 版そのものを横に伸ばしたいなら、16:9 の画像を参照画像として渡す編集にするのがよさそうです（今回は試していません）。 お題4・5：ふつうの配置 !街角の写真3枚に指定位置の色枠を重ねた比較。ChatGPT、FLUX枠あり、FLUX文章だけ お題4。色の枠が指定した位置 色の枠が指定した位置です。街角のお題では、ChatGPT も「横0〜30%」などの文章の指示をよく守り、3つとも物の中心が枠の中に入りました。FLUX.3 Klein の枠ありは、女性・時計塔・屋台が枠にぴったり収まっています。一方、FLUX.3 Klein に ChatGPT と同じ文章だけを渡すと、女性が中央寄りに立ち、時計塔が左にずれるなどの乱れが出ました（3シード中1枚で時計塔の中心が枠外）。 !白地の3×3マスに果物や小物を並べた画像3枚の比較。どれも9マスとも正しい位置 お題5。どれも9マス全問正解 3×3 のマス目は、ChatGPT、FLUX.3 Klein の枠あり、文章だけ、pup なしのすべてで9マス全問正解でした。マス目のように規則正しい並びは、文章だけでもどのモデルも正確に描けます。 お題8：不自然な位置・大きさの配置 位置の指定がはっきり効いたのが、このお題です。「小さな風船は右下の隅」「時計は右上」といった、ふつうの写真ならそこに置かない配置を指定しました。 !部屋の写真3枚に指定位置の色枠を重ねた比較。FLUX枠ありは5つの物がほぼ枠内、ChatGPTは風船が枠より上、FLUX文章だけは植物が大きく時計が左にずれる お題8。FLUX（枠あり）だけが5つとも枠に収まった ChatGPT は全体としてよく指示に従っていますが、風船が枠より上に浮かび、植物は枠からはみ出しています。FLUX.3 Klein の枠ありは、5つの物が枠の中にほぼ収まりました。同じ文章だけを渡した FLUX.3 Klein は、植物が大きすぎ、時計が左にずれています。 物体検出モデル OWLv2 で測った「指定した枠との重なり（IoU）」をグラフにすると、次のようになります。 !配置の正確さの棒グラフ。お題4ではGPT 0.40、FLUX枠あり 0.46、FLUX文章だけ 0.29。お題8ではGPT 0.54、FLUX枠あり 0.81、FLUX文章だけ 0.53 図4：指定した枠と、検出した物の重なり（IoU）。FLUX は3シードの平均 お題8では FLUX.3 Klein（枠あり）が 0.81、ChatGPT が 0.54、FLUX.3 Klein（文章だけ）が 0.53 でした。ChatGPT と FLUX.3 Klein の文章だけがほぼ同じ値なので、差を生んだのはモデルの地力というより枠という入力手段そのものだと考えられます。お題4は、全身の人物に対して指定した枠が横に広めだったため、どの方法でも値は低めに出ていますが、順位は同じでした。 なお、OWLv2 の検出枠は人物では体の一部しか囲まないことがあり、数値は目安です。比較画像の目視でも、同じ傾向であることを確認しています。 お題6・7：編集 !昼の商品写真を夜に変えた編集結果の比較。ChatGPTは卓上ライトを描き足し、FLUXは構図を保って暗くした お題6。左2枚が ChatGPT（元・編集後）、右3枚が FLUX（元・seed 0・seed 1） 「夜に変える」は、ChatGPT が卓上ライトを描き足し、窓の外を夜景にするなど、気の利いた変え方をしました。ただし、画像の大きさが 1254×1254 から 1312×1199 に変わり、正方形ではなくなっています。FLUX.3 Klein は構図と大きさを保ったまま暗くしましたが、シード0は「夕方」程度で、夜らしさが十分だったのは3枚中2枚でした。 !イヤホンケースだけを右へ動かす編集の比較。ChatGPTは文章だけで右へ移動、FLUXは文章だけでは動かず、枠を付けると指定どおり右へ移動 お題7。上が ChatGPT、下が FLUX（元・文章だけ・枠あり） 「ケースだけ右へ」は、FLUX.3 Klein の弱点と強みが同時に出ました。文章だけで頼むと、3シードともケースはほとんど動きませんでした（中心の移動は 0〜3%）。pup はキャプションに「右へ動かす」と正しく書いているので、本体が文章の「移動」を絵に反映できていないことになります。ところが src_bbox→tgt_bbox の枠を付けると、3シードとも中心が指定どおり 15% 右へ動きました。 ChatGPT は文章だけで中心を 22% 右へ動かし、ケースの外側の画素の平均差は 2.4（0〜255 の目盛り）と、ほぼ元のままでした。FLUX.3 Klein の枠ありは 4.0〜6.3 で、窓の外の木や机の木目がわずかに描き直されています。BFL の API には、編集していない部分を元の画素に戻す「pixel restoration」という機能がありますが、Diffusers の手順には含まれていません。 速さ !1枚にかかる時間の横棒グラフ。ChatGPT 26秒。Mac の FLUX は pup 込みで、休ませた場合 1024×1024 が28秒・16:9 が48秒・編集が76秒、休まず連続だと44秒・66秒・95秒。参考の H100 は1.9秒 図5：1枚にかかる時間（中央値）。FLUX は pup と画像生成の合計で、休ませた場合と連続で作った場合 ChatGPT は、送信から完成画像のファイルができるまでの中央値が 約26秒（20〜41秒）でした。会話モデルが依頼を読んで画像ツールを呼ぶ時間も含んでいます。 Mac の FLUX.3 Klein は、条件によって速さが大きく変わりました。最初の一括生成（約50枚を休まず連続）では、画像生成の中央値が 1024×1024 で 33.6秒、16:9（1536×864）で 46.5秒、参照画像1枚の編集で 80.1秒 でした。ところが、あとで1枚ごとに30秒休ませて測り直すと、それぞれ 18.5秒・28.0秒・60.9秒 まで縮みました。休まずに測り直したときも 20→24→31秒と1枚ごとに遅くなっていったので、Mac が熱を持って GPU の速度が落ちたためとみられます。 ここに pup の約10〜25秒（1秒あたり約22トークン）が加わります。1024×1024 なら、冷えた状態では pup 込みで約28秒と ChatGPT とほぼ同じ、連続で作ると約44秒です。H100 での 1.93秒と比べると、Mac の GPU では約10〜17倍かかる計算です。 それでも、手元の Mac で通信なしに30秒〜1分ほどで1枚できるのは、試行錯誤には十分な速さです。何十枚作っても追加料金はかかりません。 どちらを使うか 結果をふまえた使い分けを、図6にまとめました。左から GPT Image 2.5 が向く場面、FLUX.3 Klein が向く場面、両方を組み合わせる方法の順に見てください。 !使い分けの図。日本語の文字や速さを重視するなら GPT Image 2.5、位置の正確さや大量生成・オフラインなら FLUX.3 Klein、構図は FLUX で作り文字は後から重ねる組み合わせも有効 図6：今回の結果から見た使い分け 判断の軸は2つです。 - 文字の正確さが大事なら GPT Image 2.5。特に日本語の見出しを画像に焼き込むなら、今回の結果では差がはっきりしていました - 位置と大きさの正確さが大事なら FLUX.3 Klein。文章で伝えにくい「右下の隅に小さく」のような指定も、枠ならそのまま守られます もとのニュースで触れられていた「技術ブログのアイキャッチを 16:9 と 5:2 で作り分ける」用途で言えば、次のような分担が現実的です。 1. FLUX.3 Klein に、見出しの場所を空けた構図を枠で指定して、16:9 と 5:2 の絵を作る（同じ枠の表を使い回せる） 2. 見出しの文字は、Figma や Canva などで後から重ねる 3. 見出しまで含めて1回で仕上げたいときは、ChatGPT で 16:9 を作り、同じチャットで「5:2 に」と頼む ChatGPT だけで完結させるほうが手軽ですが、毎回の構図が少しずつ変わります。記事ごとに同じレイアウトのアイキャッチをそろえたい場合は、枠の表を保存しておける FLUX.3 Klein の方式が向いています。 ライセンスと商用利用 FLUX.3 Klein の重みは FLUX Kommunity License v1.0 で配布されています。オープンソースのライセンスではなく、年商と用途で条件が変わる独自のライセンスです。判断の流れを図7で確認してください。 !FLUX Kommunity License の判断フロー。年商500万ドル未満なら生成画像の商用利用可（フィルターか公開前の確認、AI 生成の表示が条件）、それ以上は非商用のみで商用は有償ライセンスか API、生成画像で似たモデルを改良することは誰でも禁止 図7：FLUX.3 Klein の画像は仕事やブログで使ってよいか（法的助言ではありません） 条文から読み取れる要点は次のとおりです（2026年10月16日にモデルリポジトリの LICENSE.md で確認）。 | 項目 | 内容 | |---|---| | 無償で使える範囲 | 非商用（研究・評価・趣味、企業の本番以外での検証） | | 年商500万ドル未満（関連会社を含む） | 生成した画像（Output）を商用に使ってよい。そのための本番運用も可 | | その条件（2.e） | コンテンツフィルターを入れるか、公開前に違法・権利侵害の内容がないか確認する。法律が求める範囲で AI 生成と表示する | | 禁止されていること（例） | 生成画像を使って似た画像モデルを改良・蒸留する、軍事・監視・生体情報の処理、権利侵害 | | 生成画像の権利 | BFL は所有権を主張しない。使い方の責任は利用者 | | それ以外の商用 | BFL の有償ライセンス（自前ホスト）か BFL API | 個人ブログのアイキャッチであれば、多くの個人は「年商500万ドル未満」に当たるので、生成画像を使うこと自体はできます。ただし「公開前に内容を確認する」という条件があるので、生成したものを確認せずに自動で公開する使い方は避けたほうがよいでしょう。 pup（Apache 2.0）と公式の推論コード（Apache 2.0）は、本体とは別のライセンスです。また、Hugging Face で同意するとき、メールアドレスとユーザー名が BFL に共有されます。 GPT Image 2.5 は OpenAI の利用規約の範囲で使います。年商による線引きはありませんが、手元で動かす選択肢はなく、API では1枚ごとに課金されます。 ※ライセンスの説明は条文の整理であり、法的助言ではありません。仕事で使う場合は原文を確認してください。 Mac で FLUX.3 Klein を動かす手順 ここからは、今回の検証と同じ構成（pup → FLUX.3 Klein）を Mac で再現する手順です。重みは pup が 18.8GB、本体とテキストエンコーダーなどが約20GB あり、両方を同時に読み込むとモデルだけで約40GB になります。筆者はメモリ128GB の Mac でしか試していません。下のコードは pup を使い終えて解放してから本体を読み込むので、同時に載るのは片方ずつですが、どこまで少ないメモリで動くかは確認していません。 !Mac で FLUX.3 Klein を動かす4ステップ。規約に同意してログイン、Python 3.12 の仮想環境、約39GB の重みのダウンロード、pup から本体の順に実行。実測時間とメモリの目安つき 図8：Mac で動かす手順の全体像 1. Hugging Face で規約に同意してログインする 本体の重みは、Hugging Face のモデルページで規約に同意しないとダウンロードできません。 1. huggingface.co をログインした状態で開く 2. 「You need to agree to share your contact information…」の枠にある 「Agree and access repository」 を押す（メールアドレスとユーザー名が BFL に共有されます。承認は自動です） 3. Hugging Face の設定画面で read 権限のアクセストークンを作り、ターミナルでログインする # uv が入っていれば、インストールせずに hf コマンドを使える uvx --from huggingface_hub hf auth login pup（flux-3-image-klein-pup）は Apache 2.0 で、同意なしでダウンロードできます。 2. 仮想環境を作る FLUX.3 のパイプラインは Diffusers の main ブランチにしか入っていないので、GitHub から入れます。 mkdir flux3-lab && cd flux3-lab uv venv -p 3.12 .venv # Diffusers は GitHub の main から。transformers は Qwen3.5 / Qwen3-VL に対応した新しい版が必要 uv pip install -p .venv/bin/python torch torchvision \ "git+https://github.com/huggingface/diffusers.git" transformers accelerate safetensors pillow source .venv/bin/activate python -c "from diffusers import Flux3AutoBlocks; print(Flux3AutoBlocks().available_workflows)" # ['text2image', 'image_conditioned'] と出れば OK 3. 重みをダウンロードする（約39GB） 本体のリポジトリには、FP8・NVFP4 の量子化版（NVIDIA の新しい GPU 向け）や見本画像も入っていて、全部で43GB あります。Mac では使わないので外します。 # FLUX.3 Klein 本体（bf16）＋テキストエンコーダー＋VAE、約20GB hf download black-forest-labs/flux-3-image-klein --local-dir weights/flux-3-image-klein \ --exclude "variants/*" --exclude "assets/*" --exclude "*.jpg" \ --exclude "model.safetensors" --exclude "ae.safetensors" # pup（プロンプト拡張）、約18.8GB hf download black-forest-labs/flux-3-image-klein-pup --local-dir weights/pup model.safetensors（本体を1ファイルにまとめた版、11GB）と ae.safetensors（VAE の1ファイル版）は公式の推論コード・ComfyUI 用で、Diffusers は transformer/・vae/ フォルダのほうを読むので不要です。筆者の回線では hf download が 10MB/s 前後で頭打ちになったため、ファイルを範囲に分けて curl で並列に取得しました（約 7〜9MB/s。回線が細い場合は数時間かかることもあります）。 4. 生成する pup と本体をつなぐスクリプト flux3_mac.py と、公式の bbox.py のコピー（flux3_bbox.py）を同じフォルダに置いて実行します。 # 公式の枠の処理（Apache 2.0）を取ってくる curl -sL https://raw.githubusercontent.com/black-forest-labs/flux-3-image-klein/main/src/flux3/bbox.py -o flux3_bbox.py # 文章だけで python flux3_mac.py "午後の窓辺の光が差し込む木のデスクに置かれた、黒いワイヤレスイヤホンケースの商品写真" \ --out product.png --size 1024x1024 # 枠を付けて（boxes_eyecatch.json は 0〜1 の [上, 左, 下, 右]） python flux3_mac.py "技術ブログのアイキャッチ画像。左に大きな白い日本語の見出し「画像生成を座標で操る」…" \ --out eyecatch.png --size 1536x864 --boxes boxes_eyecatch.json flux3_mac.py の中心部分は次のとおりです。pup の出力をそのまま prompt に渡しているだけで、Diffusers 側は公式ブログの例と同じです。 import torch from diffusers import ModularPipeline # pup が書いたキャプション（枠があれば末尾に JSON の枠の表が付いている） caption = upsample(request, size=(1536, 864), boxes=boxes) pipe = ModularPipeline.from_pretrained("weights/flux-3-image-klein") # VAE は fp32、それ以外は bf16（公式の Base 版の例と同じ指定） pipe.load_components(dtype={"vae": torch.float32, "default": torch.bfloat16}) pipe.to("mps") # CUDA の "cuda" の代わりに Apple Silicon の GPU を指定 image = pipe(prompt=caption, width=1536, height=864, generator=torch.Generator().manual_seed(0), output="images")[0] image.save("eyecatch.png") pup の部分で公式と違うのは、vLLM の代わりに transformers で動かしている点です（vLLM は Mac の GPU に対応していないため）。公式は「一度出た単語の点数を一律に下げる」presence penalty（1.5）を使っていますが、transformers の generate にはこの引数がないので、同じ計算をする小さなクラスを足しています。 from transformers import LogitsProcessor class PresencePenalty(LogitsProcessor): """vLLM の presence_penalty と同じ：すでに出力したトークンの点数から一律に penalty を引く""" def __init__(self, penalty, prompt_len): self.penalty, self.prompt_len = penalty, prompt_len def __call__(self, input_ids, scores): seen = torch.zeros_like(scores, dtype=torch.bool).scatter_(1, input_ids[:, self.prompt_len:], True) return scores - self.penalty * seen.to(scores.dtype) もう1つ、pup のシステムプロンプトは先頭行の TARGET CANVAS: 16:9 のような指定を受け付けるように書かれています。公式の推論コードはこれを付けていませんが、16:9 や 5:2 の画像では構図を縦横比に合わせてもらうために付けました。 編集するとき 参照画像を渡すときは、pup にも同じ画像を見せて i2i（枠があれば i2i_bbox）のシステムプロンプトでキャプションを書かせ、本体には image= で参照画像を渡します。物を動かすときの枠は、from（どの参照画像か）、src_bbox（元の位置）、tgt_bbox（移動先）を持ちます。 [{"id": "case_1", "from": "ref_image_0", "src_bbox": [0.398, 0.427, 0.769, 0.842], "tgt_bbox": [0.398, 0.575, 0.769, 0.990], "desc": "matte black wireless earbud charging case"}] トラブルシューティング 今回の検証で実際に出たつまずきを、止まった段階ごとにまとめます。図9で確認する順番を追ってから、下の表で対処を確かめてください。 !つまずきの確認順。ダウンロードできない、実行でエラー、画像が期待と違う、の3段階ごとに原因と対処を並べた図 図9：うまくいかないときの確認順 | 症状・メッセージ | 原因 | 対処 | |---|---|---| | Access to model … is restricted and you are not in the authorized list | ログインはしたが、モデルページで規約に同意していない | ログインしたアカウントでモデルページを開き「Agree and access repository」を押す | | hf download が 10MB/s 前後で頭打ち・途中で止まる | 回線や配信側の都合 | variants/ などを除外して量を減らす。ファイルを範囲に分けて並列に取る | | The following model_kwargs are not used by the model: ['presence_penalty'] | transformers の generate に presence penalty の引数がない | 記事中の PresencePenalty を logits_processor で渡す | | tokenizer … with an incorrect regex pattern の警告 | transformers の判定 | 今回は無害だった（fix_mistral_regex=True の有無でトークン列が完全に一致） | | 画像がありきたり・細部の指示が抜ける | pup を通さず短い文を渡している | pup のキャプションを prompt に渡す | | 枠と違う場所に出る・縦横が入れ替わる | 座標の順番や目盛りの間違い | [上, 左, 下, 右] の順か確認。Diffusers は 0〜1000、推論コードの boxes.json は 0〜1 | | 文章で「右へ動かして」と頼んでも動かない | 本体が文章の「移動」を反映しにくい | src_bbox と tgt_bbox の枠を付けた i2i_bbox で頼む | | 難しい漢字が別の字になる | 文字の描画の限界（今回は「操」） | 拡大して確認。見出しは後から重ねる | メモリが足りないときは、pup を使い終えたら解放してから本体を読み込みます（flux3_mac.py はそうしています）。HF ブログには、テキストエンコーダーを先に動かして解放する方法や、CPU オフロードの例も載っています。 まとめ FLUX.3 Image Klein と GPT Image 2.5 を、同じ8つのお題で比べました。 - 完成度と日本語は GPT Image 2.5。写真の作り込み、日本語の見出し（難しい漢字まで）、会話での編集のしやすさで上回った - 位置の正確さは FLUX.3 Klein。枠を付けると、不自然な配置でも指定との重なりが 0.81（ChatGPT は 0.54）。差を生んだのはモデルより「枠で渡せること」だった - FLUX.3 Klein は pup とセットで使う。Diffusers だけでは pup が呼ばれないので、自分でつなぐ必要がある - Mac でも実用的な速さ。M5 Max で pup 込み1枚約28〜48秒（連続で作ると約44〜66秒）。ChatGPT（約26秒）と同じか2倍程度で、追加料金なしで何枚でも作れる - 商用は年商500万ドル未満なら生成画像を使える。ただし公開前の確認などの条件付き 「ChatGPT の代わりになるか」への答えは、全部の代わりにはならないが、位置を決める仕事は FLUX.3 Klein のほうが得意です。アイキャッチのように構図を毎回そろえたい用途では、枠の表を使い回せる FLUX.3 Klein と、文字に強い GPT Image 2.5 を組み合わせるのが今のところいちばん確実だと感じました。 次に試すなら、Base 版（50ステップ）で画質と文字がどこまで良くなるか、ブログのアイキャッチの絵柄を LoRA で覚えさせられるか、が気になるところです。 参考リソース - Hugging Face 公式ブログ「Welcome FLUX.3 Image Klein in Diffusers」（2026-10-15）：huggingface.co - Black Forest Labs「FLUX 3 Image Klein」：bfl.ai - モデルカード（蒸留版）：huggingface.co - モデルカード（Base 版）：huggingface.co - プロンプト拡張モデル pup：huggingface.co - 公式の推論コード：black-forest-labs/flux-3-image-klein - 公式デモ（Hugging Face Spaces）：huggingface.co - OpenAI「ChatGPT Images 2.5 のご紹介」（2026-09-08）：openai.com - OpenAI API ドキュメント「Image generation」：developers.openai.com - OpenAI API 料金：developers.openai.com

PyTorch on a Mac: why memory looks freed after .to("cpu") --- title: "PyTorch on a Mac: why memory looks freed after .to(\"cpu\")" published: true description: "On Apple Silicon, moving a tensor from mps to the CPU drops the process footprint to almost zero, yet the copy still takes the same memory. A 4 GiB example, what it means for model CPU offload, and how to check a run." tags: pytorch, python, macos, machinelearning series: Big models on a 48 GB Mac canonical_url: allkeep.org --- On a Mac, a tensor moved from mps to the CPU seems to disappear from memory. The process footprint, the number Activity Monitor shows in its Memory column, drops to almost nothing, and so does the MPS driver count. The copy is still there and still takes the same memory. This is the minimal example I put together for a diffusers discussion about offloading, with a 4 GiB tensor standing in for a model's weights (torch 2.14.0, macOS 26.5.2, M5 Pro with 48 GB): import ctypes, os, time import torch # rusage_info_v2 from <libproc.h>; phys_footprint is the Memory column of Activity Monitor FIELDS = ("user_time", "system_time", "pkg_idle_wkups", "interrupt_wkups", "pageins", "wired_size", "resident_size", "phys_footprint") class RUsageInfoV2(ctypes.Structure): _fields_ = [("uuid", ctypes.c_uint8 * 16)] + [(f, ctypes.c_uint64) for f in FIELDS] \ + [(f"rest{i}", ctypes.c_uint64) for i in range(10)] libproc = ctypes.CDLL("/usr/lib/libproc.dylib") def show(step): torch.mps.synchronize() info = RUsageInfoV2() libproc.proc_pid_rusage(os.getpid(), 2, ctypes.byref(info)) print(f"{step:<14} footprint {info.phys_footprint / 2**30:4.1f} GiB, " f"mps driver {torch.mps.driver_allocated_memory() / 2**30:4.1f} GiB") show("start") w = torch.randn(2**30, device="mps") # 4 GiB of float32, standing in for a model's weights show("on mps") w = w.to("cpu") # what model CPU offload does when a model's turn ends torch.mps.empty_cache(); time.sleep(2) show("moved to cpu") float(w.sum()) # read every page of the cpu copy show("cpu copy read") start footprint 0.1 GiB, mps driver 0.0 GiB on mps footprint 4.2 GiB, mps driver 4.0 GiB moved to cpu footprint 0.1 GiB, mps driver 0.0 GiB cpu copy read footprint 4.2 GiB, mps driver 0.0 GiB I ran it three times and got the same output each time. What the numbers say Right after the move, both counters are back near zero, but w holds all 4 GiB of its values. Once the CPU reads every page of the copy, the footprint is 4.2 GiB again. So a footprint taken between .to("cpu") and the next time the CPU touches those weights does not show them. The reason the move frees nothing in the first place is the hardware. On Apple Silicon the CPU and the GPU use one pool of physical memory. On a PC, moving weights from the GPU to the CPU frees VRAM for the next model. On a Mac, the weights "on the CPU" sit in the same RAM the GPU needs. Why it matters for model CPU offload diffusers' enable_model_cpu_offload() keeps each model on the CPU and moves it to the GPU only while it runs. I ran Qwen-Image-2.1 at 1024 × 1024 that way on the same Mac (trace and write-up). The process footprint never went above 18.5 GB, which would fit on a 48 GB Mac with room to spare. Swap grew by 3.5 GB during denoising and had grown by 9.6 GB by the VAE decode, and my memory guard stopped the run before it wrote an image. A chart of the footprint alone would have called that run a fit. The example above shows one way the footprint can stay low while the weights are still in memory. I didn't measure which pages went to swap in the offload run. How to check your own run Look at swap, not only at the footprint: sysctl vm.swapusage # compare "used" before and after the run sysctl kern.memorystatus_level # system-wide free memory, in percent If swap grows while the job runs, it doesn't fit, whatever the footprint says. stageload (pip install stageload), a small library I wrote for this, records both in a trace every 0.5 s with MemoryMeter, and stageload guard stops a command once swap grows past a budget: stageload guard --wait-free 40 --swap-budget 8G -- python generate.py What does free the memory For a pipeline that runs its models one after another, the fix is to load a model when its stage starts and release it when the stage ends, instead of parking it on the CPU. stageload's release(module) moves every parameter and buffer to PyTorch's meta device, collects garbage and empties the MPS cache; a tensor on meta has no storage, so the memory goes back even while other code still holds a reference to the module. With the text encoder (16.3 GB) and the transformer (13.3 GB) loaded one at a time this way, Qwen-Image-2.1 peaked at 19.0 GB on the same Mac, and swap did not grow in either of two runs. The full setup is in How to run Qwen-Image-2.1 on a 48 GB Mac without swap. What I did not measure - The free memory of the whole system during the example: other jobs on this Mac move it by several GiB between runs, so I couldn't get a clean number. - Whether del plus torch.mps.empty_cache() gives the memory back as fully as moving to meta, and how quickly. - Other macOS and torch versions, and Macs with more memory.

Qwen-Image-2.1-Turbo は従来版より何倍速い？ 8ステップ化の仕組みと商用利用の条件 !Qwen-Image-2.1-Turbo は従来版より何倍速い？ 8ステップ化の仕組みと商用利用の条件 はじめに 手元のパソコンで画像生成 AI を動かすと、1枚ごとの待ち時間が気になります。プロンプトを少し直しては数分待つ、を繰り返すと、試行錯誤のテンポがどうしても落ちます。 2026年10月9日、Alibaba の Qwen チームが Qwen-Image-2.1-Turbo の重みを公開しました。9月20日に出た Qwen-Image-2.1 の高速版で、画像生成部の大きさ（7B）はそのままに、ノイズを取り除く工程を40ステップから8ステップに減らしたモデルです。 !従来版とTurboの1枚あたりの時間を、文章の読み取り・ノイズ除去・画像への変換に分けて並べた棒グラフ。ノイズ除去だけが大きく短くなっている 図1：1枚にかかる時間の内訳（1024px 級・16組の中央値）。短くなったのはノイズ除去の部分だけ 「工程が5分の1なら、5倍速いのか」「画質や日本語の文字は崩れないのか」「仕事で使ってよいのか」。この記事では、この3つを手元の Mac で確かめます。 - 速さ：従来版と Turbo を同じプロンプト・同じ seed で動かし、1枚にかかる時間を「文章の読み取り」「ノイズ除去」「画像への変換」に分けて測りました - 仕組み：何を変えて速くしたのか（ステップ数、予定表、重み）と、よく一緒に語られる「プレフィックス KV キャッシュ」が Turbo と関係あるのかを、公式資料と実装・設定ファイルから整理します - 画質：日本語の看板・メニュー、人物、商品写真、解説図、透過ステッカー、編集の作例を並べ、文字の正確さは OCR で数えます - ライセンス：Qwen Research License の条文を読み、商用で使えるのか、使いたいときはどうするのかをまとめます 想定読者は、画像生成 AI をローカルで動かしてみたい方、ブログや資料の画像づくりに使えるか判断したい方です。拡散モデルの細かい数式は扱いませんが、仕組みの章では「なぜ8回で止めても絵になるのか」を図で説明します。 この記事の確認範囲 | 項目 | 内容 | |---|---| | 確認日 | 2026年10月10日 | | モデル | Qwen/Qwen-Image-2.1（9月20日公開）、Qwen/Qwen-Image-2.1-Turbo（10月9日公開）。いずれも Hugging Face の公式重みを bf16 で実行 | | 実行環境 | MacBook Pro（Apple M5 Max・メモリ 128GB）、PyTorch 2.14.1（MPS）、diffusers 0.41.0.dev0（コミット 1d5d056）、transformers 5.19.0 | | 生成条件 | 従来版は公式サンプルどおり 40 ステップ、Turbo は同梱の 8 ステップ。どちらも CFG=1、KV キャッシュ有効（既定値） | | 情報源 | 両モデルのモデルカード、GitHub の README、Qwen 公式ブログ、diffusers の実装、ライセンス原文、PC Watch の報道（10月9日） | 先に結論 細かい数字は後の章で示しますが、確かめた結果を先にまとめます。 | 知りたいこと | 結果 | |---|---| | どれくらい速い？ | 1024px 級で 従来版 3分56秒 → Turbo 50秒、約4.7倍（16組の中央値）。ノイズ除去だけなら約5倍 | | なぜ速い？ | ノイズ除去の回数を40→8に減らし、その少ない回数で仕上がるように画像生成部（DiT）の重みを学習し直したから。1回あたりの計算は同じ | | KV キャッシュは？ | 2.1 に最初からある仕組みで、Turbo だけの高速化ではない。CFG も両方なし | | 画質は？ | 同じ seed ならほぼ同じ構図。文字の正確さは大差なし（指定した42個中、従来版40個・Turbo 38個）。背景や質感の描き込みは従来版が上 | | 何が変わった？ | テキストエンコーダーと VAE は従来版と値まで同一。違うのは DiT の重み（変化量は約0.24%）と、8回分の予定表だけ | | Mac で編集すると？ | MPS の VAE エンコーダーが約100万画素以上の入力画像を壊すため、そのままでは編集が失敗する。入力画像の変換だけ CPU で行えば直る | | 商用で使える？ | どちらも無償では不可。Qwen Research License で、無償なのは研究・評価だけ。商用は申請か Alibaba Cloud の API を検討 | Qwen-Image-2.1-Turbo とは Qwen-Image-2.1-Turbo は、2026年10月9日に Hugging Face と ModelScope で重みが公開された、Qwen-Image-2.1 の高速版です。公式のモデルカードは、次のように説明しています。 - Qwen-Image-2.1 の加速版のチェックポイントで、文章からの画像生成と画像編集を8ステップでこなす - 7B の画像生成アーキテクチャは同じで、diffusers の QwenImage21Pipeline でそのまま読み込める - 推奨の予定表（サンプリングのスケジュール）がチェックポイントに入っているので、設定なしで使える - 生成は CFG=1 が既定で、プレフィックス KV キャッシュで文章と参照画像の情報をステップ間で使い回す 対応する解像度（2048×2048 など7種類の縦横比）、透過画像、最大10枚の参照画像を使った編集といった 2.1 の機能は、そのまま引き継いでいます。同じ日に、Alibaba Cloud Model Studio で Qwen-Image-2.1 の Pro と Turbo の API も提供が始まりました。 Turbo で何が変わったのか：重みを1つずつ比べた 「同じアーキテクチャ」と言われても、どこまで同じなのかは気になります。そこで、両モデルの重みファイルを Hugging Face から取得し、テンソル（重みの配列）を1つずつ比べました。 !Qwen-Image-2.1の3つの部品（Qwen3-VL、DiT、VAE）の流れ図。Turboで値が変わったのはDiTの重みだけで、テキストエンコーダーとVAEは同一 図2：Qwen-Image-2.1 の構成と、Turbo で変わったところ（重みを1つずつ比べた実測） | 部品 | 役割 | 従来版と Turbo の比較結果 | |---|---|---| | テキストエンコーダー（Qwen3-VL 8B） | プロンプトと参照画像を読む | 750個の重み、87.7億パラメータが1ビットも違わない | | VAE | 潜在表現と画像（RGBA）を行き来する | 従来版は fp32、Turbo は bf16 で保存されているが、bf16 にそろえると値は同一 | | DiT（Diffusion Transformer） | ノイズを取り除く本体（7B・32層） | 297個中234個の重み、71.2億パラメータのほぼ全部が変化。ただし変化量は重み全体の大きさの約0.24% | | 設定ファイル | 層の数・次元など | 同じ（並び順と diffusers の版の表記だけ違う） | | 予定表 | 各ステップでノイズをどれだけ減らすか | Turbo だけ8回分を sample_sigmas として同梱。スケジューラーの「動的シフト」も切ってある | つまり Turbo は、従来版の DiT を出発点に、少しだけ重みを調整したモデルです。変化量が小さいことは、ComfyUI 向けの配布元（Comfy-Org）が、Turbo の差分を従来版に足す LoRA（0.91GB）としても配っていることとも合っています。 この結果から、実用上のヒントも2つ出てきます。 - ディスクを節約できる：すでに従来版を持っているなら、テキストエンコーダー（17.5GB）と VAE は使い回せる - 2つを同時に動かすなら、メモリも節約できる（下の手順の章で、実際に共有して同じ画像が出ることを確かめています） どういう仕組みで速くなったのか 「8ステップになったから速い」と一言で済ませると、大事なところが抜け落ちます。ここでは、①そもそもステップとは何か、②なぜ従来版をただ8回で止めてはだめなのか、③よく一緒に語られる KV キャッシュや CFG は Turbo と関係があるのか、の順に整理します。 拡散モデルの「ステップ」とは Qwen-Image-2.1 のような拡散モデル（diffusion model）は、ノイズだけの画像から少しずつノイズを取り除いて、最終的な画像に仕上げます。この「少し取り除く」1回がステップ（デノイジングの1工程）で、1回ごとに 7B の画像生成部（DiT：Diffusion Transformer）を丸ごと1回計算します。 つまり生成時間の大部分は「DiT の計算1回あたりの時間 × ステップ数」で決まります。従来版の公式サンプルは40ステップ、Turbo は8ステップなので、DiT の計算回数は5分の1になります。 !夜の商店街のプロンプトで、従来版40ステップとTurboの8ステップの途中経過を、進み具合をそろえて並べたアニメーション 図3：実際の途中経過。各ステップでモデルが予想している完成図（ノイズを除いた推定）を、従来版は5回ごと、Turbo は毎回表示 予定表（シグマ）を短くするだけでは足りない ステップ数を減らすだけなら、従来版にも num_inference_steps=8 と指定できます。それなのに、なぜ別のモデル（Turbo）が必要なのでしょうか。 鍵は、各ステップでどれだけノイズを減らすかという予定表（シグマのスケジュール）と、それに合わせて学習された重みです。図4は、2つのモデルの予定表を並べたものです。 !従来版40ステップ、Turbo 8ステップ、従来版を8ステップにした場合の、ノイズの割合（シグマ）の下げ方を比べた折れ線グラフ 図4：ノイズの減らし方の予定表。Turbo は前半を構図づくりに使い、最後に大きく仕上げる 従来版の予定表は、1から0までをほぼ均等な歩幅で下げていきます。歩幅が小さいので、1回ごとの予測が多少ずれても次のステップで修正できます。 Turbo の予定表は、モデルと一緒に model_index.json の sample_sigmas として配布されていて、値は 1.0, 0.978, 0.954, 0.927, 0.895, 0.845, 0.705, 0.415 です。8回のうち5回を「ノイズが9割近く残っている段階」に使い、最後の1回で残り約4割のノイズを一気に消します。大きな歩幅で外さないように、重みそのものを「少ない回数で仕上げる」用に学習し直したのが Turbo です。 実際に、従来版にそのまま num_inference_steps=8 を指定して動かしてみました。 !従来版の40ステップ、従来版の8ステップ、Turbo の8ステップを3題材で並べた比較 従来版を8ステップで止めると（中央）、時間は Turbo とほぼ同じになるが、白っぽくぼやけ、文字の線が細く崩れる（「円」「餃」など）。右の Turbo は同じ8ステップでも仕上がっている 時間は Turbo とほぼ同じなのに、画像は明らかに仕上がっていません。メニュー板では「円」の形が崩れ、頼んでいない「ら」まで入りました。同じ回数でも、少ない回数用に学習された重みかどうかで結果がまったく違うことが分かります。 公式は、どういう方法で学習したか（いわゆる蒸留の手法名や学習データ）を公開していません。ただ、次の3つの事実から、「速さの正体はステップ数を減らすための再学習」だと分かります。 - DiT の設定ファイル（層の数・次元など）は従来版と同じ。違うのは重みの値（前の章の比較で確認） - サンプリングの予定表が専用のものに置き換わっている（従来版は40ステップ・動的シフトあり、Turbo は8ステップ固定） - 従来版を同じ8ステップで動かすと、画像が崩れる（上の実験） 一般に、多くのステップで動く「先生」モデルの出力を、少ないステップで再現するように「生徒」モデルを学習させる手法をステップ蒸留（step distillation）と呼びます。Turbo もこの系統の高速化と考えられますが、具体的な手法は公表されていない点に注意してください。 CFG は関係ない（もともと1） 画像生成の高速版では、「CFG（Classifier-Free Guidance）をやめて計算を半分にした」という説明がよく出てきます。CFG は、プロンプトありとなしの2通りで予測して差を強調する手法で、使うと1ステップあたりの計算が2倍になります。 ところが Qwen-Image-2.1 は、従来版も CFG=1（ガイダンスなし）が既定です。diffusers の実装の説明にも「Qwen-Image 2.1 はガイダンスなしでサンプリングする前提」とあります。したがって、Turbo の速さに CFG は関係しません。 プレフィックス KV キャッシュは「2.1 共通」の仕組み Turbo の紹介記事では「プレフィックス KV キャッシュで高速化」という説明も見かけます。これは正しいのですが、Turbo だけの新機能ではありません。9月20日公開の従来版の時点で入っていた、2.1 の設計そのものです（diffusers の use_kv_cache は両モデルとも既定で True）。 !1回目は指示文・参照画像・生成中の画像をすべて計算してK/Vを保存し、2回目以降は生成中の画像だけを計算する様子 図5：プレフィックス KV キャッシュ。2.1 の設計に組み込まれた仕組みで、従来版と Turbo の両方で働く Qwen-Image-2.1 の DiT は、指示文・参照画像・生成中の画像を1本の列に並べて計算します。このとき、 1. 前にある指示文や参照画像は、後ろの生成中の画像を見ない（ブロック因果アテンション） 2. 指示文や参照画像は、ノイズの量に関係なく常に「完成時点（t=0）」として扱う という2つの約束があるので、指示文と参照画像の部分の計算結果（アテンションで使う K と V）は、どのステップでも同じになります。そこで1回目に計算して保存し、2回目以降は読むだけにします。公式ブログが「混合粒度アテンション」と呼んでいるのが、この「文章は1トークンずつの因果、画像はかたまり単位」の作りです。 この仕組みは、参照画像が多い編集ほど効き、短いプロンプトだけの生成ではあまり効きません。Turbo ではステップ数が減ったぶん、キャッシュを使い回す回数も減るので、効き目はむしろ小さくなります（実測は後述）。 まとめ：Turbo で変わったもの・変わっていないもの | 項目 | 従来版（2.1） | Turbo | |---|---|---| | 画像生成部（DiT） | 7B・32層 | 同じ構造、重みは別物 | | 文章・画像の理解（テキストエンコーダー） | Qwen3-VL 8B（87.7億パラメータ） | 値まで同一（750個の重みすべて一致） | | VAE（画像との変換） | 64チャンネル・RGBA（fp32 で保存） | 値は同一（bf16 で保存し直しただけ） | | ステップ数 | 40（公式サンプル） | 8（固定の予定表を同梱） | | CFG | 1（なし） | 1（なし） | | プレフィックス KV キャッシュ | あり（既定で有効） | あり（既定で有効） | | ライセンス | Qwen Research License | 同じ | 従来版と比べた①：生成時間 比較の条件 同じ Mac で、従来版（40ステップ）と Turbo（8ステップ）に同じプロンプト・同じ seed・同じ解像度を渡し、1枚ずつ交互に生成しました。ほかのアプリが GPU を使うと速度が揺れるため、片方をまとめて測るのではなく、従来版→Turbo→従来版…と交互に動かし、16組の中央値で比べています。モデルの読み込み時間（初回だけ約10〜21秒）は含めていません。 用意したプロンプトは8種類で、それぞれ seed 1 と seed 2 の2枚ずつ生成しました。日本語の文字を多めにしたのは、ブログや資料の画像に使うなら、そこが一番の関心事だからです。 | 名前 | 内容 | 見たいところ | |---|---|---| | アイキャッチ | 濃紺の背景に「画像生成を8ステップで」の見出しと英字の副題、GPU とカメラの立体イラスト（1376×768） | 大きな日本語の見出し | | メニュー板 | ラーメン店の木の札に「お品書き」と5品・5つの価格 | 小さめの日本語と数字の並び | | ポートレート | 窓辺で本を読む30代の女性（85mm・浅い被写界深度） | 肌・手・光の自然さ | | 商品写真 | クラフト紙のコーヒー袋。ラベルに「深煎りブレンド」「KYOTO ROASTERS」「200g」 | 商品写真の質感とラベル | | 夜の商店街 | 雨上がりの石畳に「居酒屋 とり吉」「くすり」「営業中」の看板 | 暗い場面の小さな文字・反射 | | 解説図 | 「RAGのしくみ」と「①質問→②検索→③回答」の3つの箱 | 図の構造と短いラベル | | 透過ステッカー | 「よろしく！」の吹き出しを持つ柴犬（RGBA） | 透過と文字 | | 英語ポスター | 「VISIT KYOTO」「Autumn Leaves Festival 2026」の旅行ポスター | 英語の文字・版画風の質感 | 解像度は 1024×1024 級にそろえました（アイキャッチだけ 16:9 の 1376×768）。公式の既定は 2048×2048 ですが、40ステップを16回まわすと Mac では時間がかかりすぎるため、2048×2048 は別に1組だけ測っています。 結果：中央値で約4.7倍速い 16組の結果をまとめると、次のとおりです。 | 項目（中央値） | 従来版（40ステップ） | Turbo（8ステップ） | 差 | |---|---|---|---| | 1枚の合計時間 | 3分56秒（235.9秒） | 50秒（50.1秒） | 約4.7倍速い（組ごとの倍率の中央値 4.65倍、範囲 4.0〜5.3倍） | | 文章の読み取り（Qwen3-VL） | 0.7秒 | 0.7秒 | 同じ | | ノイズ除去（DiT） | 3分51秒 | 46秒 | 約5.0倍 | | 1ステップあたり（2回目以降） | 5.78秒 | 5.74秒 | 同じ | | 画像に戻す（VAE） | 4.6秒 | 3.5秒 | ほぼ同じ（ばらつきの範囲） | | メモリ（1モデルだけ読み込んだとき） | 読み込み後 30.3GB・ピーク 31.5GB | 読み込み後 30.3GB・ピーク 31.5GB | 同じ | ポイントは3つです。 1. 1ステップの重さは変わらない：従来版も Turbo も1回のノイズ除去に約5.8秒かかります。速くなったのは、回数が40から8に減ったからです。 2. 5倍には少し届かない：文章の読み取りと画像への変換は Turbo でも同じ時間がかかるため、合計では約4.7倍になります。 3. どの題材でも傾向は同じ：8種類×2枚のすべてで、Turbo は4.0〜5.3倍速くなりました。 なお、計測中は同じ Mac で別の処理（ローカル LLM）が GPU を使う時間帯がありました。ほかの処理が少ない時間帯に、メニュー板を1モデルずつ読み込んで測り直すと、従来版 3分24秒 → Turbo 42秒（約4.9倍）でした。絶対的な時間は Mac の混み具合で変わりますが、倍率はほぼ同じです。 !1024px級の画像生成、2048×2048の画像生成、スケッチからの編集の3条件で、従来版の所要時間とTurboの所要時間を並べた棒グラフ。どれも約4.5〜4.7倍速い 図6：条件を変えても Turbo は速いか（実測） 解像度や使い方を変えても、Turbo の速さは保たれました。 | 条件 | 従来版 | Turbo | 倍率 | メモ | |---|---|---|---|---| | 文章から画像（1024px 級） | 3分56秒 | 50秒 | 約4.7倍 | 16組の中央値 | | 文章から画像（2048×2048、公式の既定） | 20分49秒 | 4分36秒 | 約4.5倍 | 1ステップ約30秒。画像への変換（VAE）だけで Turbo でも22秒 | | 編集（スケッチ→写真、参照画像1枚） | 3分44秒 | 49秒 | 約4.6倍 | 入力画像の変換は CPU。参照画像の読み取りと1回目のステップは両モデル共通 | 公式の既定である 2048×2048 では、画像のトークン数が 1024px 級の4倍（4096→16384）になり、1ステップが約30秒まで重くなります。従来版の40ステップでは1枚20分を超えるので、Mac で 2048px を試行錯誤に使うのは現実的ではありません。Turbo なら4分半なので、「高解像度で作るなら Turbo」という選択は、時間の面ではっきり意味があります。 編集の倍率が文章からの生成より少しだけ下がるのは、参照画像を読み取る時間と、1回目のステップで参照画像の部分をまとめて計算する時間（合わせて十数秒）が、ステップ数に関係なく両モデルに同じだけかかるからです（次の節で詳しく見ます）。 KV キャッシュはどれだけ効いているか 仕組みの章で、プレフィックス KV キャッシュは「参照画像がある編集ほど効く」と書きました。use_kv_cache=False にして、実際にどれだけ変わるかを測りました（編集は入力画像の変換を CPU で実行）。 | 条件 | モデル | キャッシュあり | キャッシュなし | 1ステップ（2回目以降） | |---|---|---|---|---| | 編集（スケッチ→写真、参照画像1枚） | 従来版 | 3分44秒 | 8分12秒 | 5.2秒 → 12.1秒 | | 編集（同上） | Turbo | 49秒 | 1分42秒 | 4.9秒 → 12.1秒 | | 文章からの生成（メニュー板） | Turbo | 46秒 | 46秒 | 4.4秒 → 4.9秒 | 参照画像がある編集では、キャッシュによって2回目以降のステップが半分以下の時間になっていました。1回目のステップで指示文と参照画像をまとめて計算し、あとは生成中の画像の部分だけを計算しているためです。一方、文章だけの生成では、指示文のトークン数が画像（1024px 級で4096トークン）に比べて少ないので、差はほとんど出ませんでした。 キャッシュで短くなる時間は「1ステップあたりの節約 × ステップ数」なので、40ステップの従来版では約4分30秒、8ステップの Turbo では約53秒の節約です。Turbo のほうが KV キャッシュの恩恵（の絶対量）は小さいことも分かります。普段使うときは、既定値（True）のままで問題ありません。 従来版と比べた②：できあがる画像 ここからは、同じ条件で作った画像を並べて見ていきます。左が従来版（40ステップ）、右が Turbo（8ステップ）、上の段が seed 1、下の段が seed 2 です。画像の下には、その1枚にかかった時間を書いています。 まず全体の印象：構図はほぼ同じ、質感は従来版が上 並べてみて最初に気づくのは、同じ seed なら、Turbo は従来版とほとんど同じ構図になることです。Turbo が従来版から追加学習して作られたモデルだからだと考えられます。 これを数字でも確かめました。画像を 32×32 の白黒に縮めて、明るさの配置がどれだけ似ているか（相関係数。1 に近いほど同じ配置）を比べています。 | 比べた組み合わせ | 配置の近さ（8種類の中央値） | |---|---| | 従来版と Turbo、同じ seed | 0.86 | | 従来版と Turbo、違う seed | 0.48 | | 従来版どうし、違う seed | 0.50 | 同じ seed の組だけが飛び抜けて近い、という結果です。これは実用上の利点になります。Turbo で seed とプロンプトを何十通りも試して当たりを見つけ、最後の1枚だけ従来版で作り直す、という使い方ができるからです（最終版は構図がほぼ保たれたまま、質感が増します）。 一方で、細部の描き込みは従来版のほうが多めでした。画像の細かい凹凸（輪郭や質感）の量を、ラプラシアン（隣の画素との明るさの差）の平均で測ると、Turbo は従来版の約0.91倍（8種類の中央値）。差が大きかったのは英語ポスター（0.79倍）と夜の商店街（0.80倍）で、解説図・ステッカー・商品写真はほぼ同じでした。少ないステップで仕上げるぶん、版画風のざらつきや濡れた路面の細かな反射が、やや滑らかになる傾向です。 日本語の見出し・メニュー板・商品ラベル !従来版と Turbo のアイキャッチ。4枚とも「画像生成を8ステップで」「Qwen-Image-2.1-Turbo 検証レポート」が正しく描かれている アイキャッチ。見出しと副題は4枚とも正確。従来版の seed 1 は、チップに頼んでいない「GRIIDI」という文字を入れた 大きな見出しは、両モデルとも完璧でした。構図も seed ごとにほぼ同じで、Turbo を使っても困る場面はありません。 !メニュー板。従来版・Turbo とも「お品書き」と5品の名前・価格が正しい メニュー板。「お品書き」と5品の名前・価格が4枚とも正確。従来版は木目や店内の照明の描き込みが多い 「醤油らーめん 850円」のような、漢字・ひらがな・数字が混ざった行が5行あっても、両モデルとも1文字も間違えませんでした。Qwen-Image-2.1 の日本語の強さは、Turbo でもそのまま残っています。 !商品写真。ラベルの「深煎りブレンド」「KYOTO ROASTERS」「200g」が4枚とも正しい 商品写真。ラベルの文字は4枚とも正確。構図もほぼ同じで、この題材では差を見つけにくい 小さな文字が多い場面：夜の商店街と解説図 !夜の商店街。従来版・Turbo とも看板の文字の一部が崩れる 夜の商店街。小さな看板の文字はどちらも完全ではない。seed 1 では従来版が「営業中」「くすり」を描けた一方、Turbo の緑の看板は崩れた。seed 2 では Turbo も「くすり」「営業中」「とり吉」を描けた 暗い場面に小さな看板が並ぶと、両モデルとも取りこぼしが出ます。どちらが上とは言い切れず、seed によって入れ替わりました。濡れた石畳の反射は、従来版のほうが細かく描かれています。 !解説図。seed 1 は両モデルとも箱が4つに増え、従来版は「②検索」が重複、Turbo は「②ボ索」と誤字。seed 2 は両方とも正しい 解説図。seed 1 は両モデルとも「3つの箱」の指示を守れず4つに増えた（構図を受け継ぐため、失敗の仕方も似る）。文字の誤り（ボ索）は Turbo だけ この例は、Turbo の性質をよく表しています。構図は従来版から受け継ぐので、従来版が失敗する seed では Turbo も同じ形で失敗します。そのうえで、細かい文字が1文字崩れるのは Turbo のほうでした。 人物写真 !ポートレート。構図は同じで、従来版は背景の植物やマグカップ、窓からの光の描き込みが多い ポートレート。顔立ちと手は両モデルとも自然。従来版は背景（植物・マグカップ）や窓からの光と影が豊かで、Turbo は背景が簡素で光が平板になりやすい 人物の顔や手の破綻は、どちらにも見られませんでした。差が出たのは背景と光で、従来版のほうが「写真らしい情報量」があります。広告や作品の最終版に使うなら従来版、ラフや構図検討なら Turbo で十分、という印象です。 透過ステッカーと英語のポスター !透過ステッカー。4枚とも背景が透明。Turbo の seed 2 だけ吹き出しの文字が消えた 透過ステッカー（背景の市松模様は透明な部分）。4枚とも透過は正しく出た。Turbo の seed 2 は吹き出しの中の「よろしく！」が消えて空白になった 透過（RGBA）画像は、定型文をプロンプトに入れるだけで4枚とも正しく出ました。ただし Turbo の seed 2 では、吹き出しの文字が丸ごと消えています。 !英語のポスター。4枚とも文字は正確。従来版は版画風のざらつきが強い 英語のポスター。文字は4枚とも正確。プロンプトの「screen-print texture（版画の質感）」は従来版のほうがよく出ている 文字の正確さを数える プロンプトで「この文字を描いて」と指定した文字列（8種類で計21個、seed 2つで42個）が、そのとおり描けたかを数えました。まず macOS の OCR（Vision フレームワーク）で読み取り、OCR が読み違えやすい縦書きの看板や装飾の強い文字は、画像を拡大して目視で確かめています。 | 題材 | 指定した文字列 | 従来版 | Turbo | 気づいたこと | |---|---|---|---|---| | アイキャッチ | 見出し・副題（2個×2枚） | 4/4 | 4/4 | 従来版 seed 1 は頼んでいない「GRIIDI」を追加 | | メニュー板 | 「お品書き」と5行（6個×2枚） | 12/12 | 12/12 | 両方とも完璧 | | 商品写真 | ラベル3か所（3個×2枚） | 6/6 | 6/6 | 両方とも完璧 | | 解説図 | タイトルと3つの箱（4個×2枚） | 8/8 | 8/8 | seed 1 は両方とも箱が4つに。Turbo は増えた箱が「②ボ索」 | | 透過ステッカー | 「よろしく！」（1個×2枚） | 2/2 | 1/2 | Turbo seed 2 は吹き出しが空白 | | 英語ポスター | 2行（2個×2枚） | 4/4 | 4/4 | 両方とも完璧 | | 夜の商店街 | 看板3つ（3個×2枚） | 4/6 | 3/6 | 両方とも取りこぼしあり。縦書きの小さな看板が苦手 | | 合計 | 42個 | 40（95%） | 38（90%） | | 大きな見出し、メニュー、ラベル、英語の見出しでは差がありませんでした。差が出たのは、小さな文字が画面に散らばる場面と、文字が丸ごと抜け落ちた1件です。ブログのアイキャッチや資料の見出しのように「大きな文字が数か所」なら、Turbo で困ることは少ないでしょう。 > OCR だけで数えると、両モデルとも点数が下がりました（筆文字の「醤」や、紅葉が重なった「VISIT KYOTO」を読み違えるため）。画像生成の文字の評価に OCR を使うときは、読み違いを目視で確かめる手順を入れたほうが安全です。 従来版と比べた③：画像の編集 Qwen-Image-2.1 は、画像を入力して指示文で直す「編集」も1つのモデルでこなします。Turbo も同じです。2つの例で比べました。 > 先に注意：Mac（MPS）で編集を試すと、最初は両モデルとも浮き彫りのような灰色の画像や、真っ黒な画像が出ました。調べると、入力画像を潜在表現に変える VAE エンコーダーが、MPS では約100万画素以上の画像を正しく変換できていなかったのが原因でした（詳しくは手順の章の7）。以下の結果は、入力画像の変換だけ CPU で行ったものです。 スケッチから写真を作る（公式の作例） 公式のモデルカードに載っている、鉛筆のヨットのスケッチを写真にする例を、指示文もそのまま使って試しました（出力は 1024px 級の 1728×608）。 !公式サンプルの鉛筆スケッチと、従来版・Turbo が作った写真。どちらもスケッチの構造を正しく再現している スケッチ→写真。両モデルとも、前のマストと見張り台、4つ窓の甲板室と救命ボート、黄色い煙突、上段5個・下段9個の丸窓、船首の四角い窓まで、指示どおりに再現した 両モデルとも、指示文に書かれた細かな構造（丸窓の数まで）を正しく再現しました。従来版はマストの索具や手すりなど細い線の描き込みが多く、Turbo はマストの形がやや単純です。時間は 従来版 3分44秒、Turbo 49秒（約4.6倍） でした。入力画像の CPU での変換は約4秒で、両モデルに同じだけかかります。 ラベルの文字だけを書き換える 次に、Turbo で作った商品写真を入力に、「ラベルの『深煎りブレンド』を『浅煎りシングルオリジン』に書き換え、ほかは変えない」と指示しました。 !商品写真のラベルの書き換え。従来版は文字を変えず、Turbo は「深煎り オルルン」と崩れた。袋・豆・マグカップは両方とも保たれている ラベルの書き換え。袋・豆・マグカップの配置はどちらも保たれたが、文字の差し替えは両方とも失敗。従来版は元の文字のまま、Turbo は「深煎り オルルン」と崩れた。壁や木目のざらつきも両方で強くなった こちらは、どちらも指示どおりにはなりませんでした。物の配置を保つ力は両モデルともありますが、壁や木目の質感は入力よりざらついています。そして、画像の中の日本語を別の日本語に差し替える編集は、今回の1例では成功していません（英語や短い指示文でも試しましたが、MPS の不具合を避ける前だったため判定に使えず、言語による違いは確かめられていません）。文字を差し替えたいときは、文章から作り直すほうが確実です。生成なら、日本語の文字はかなり正確に描けるからです。 従来版と Turbo、どちらを使うか ここまでの結果をもとに、使い分けの目安をまとめます。 !用途ごとに従来版とTurboのどちらを選ぶかを示した図。試行錯誤はTurbo、文字中心もTurbo、質感重視の最終版は従来版、商用はどちらも無償では不可 図8：従来版と Turbo の使い分け（今回の実測にもとづく目安） - アイデア出し・プロンプト調整・seed 探し：Turbo。1枚約50秒なので、従来版1枚の時間で4〜5案を見られます - 見出しやラベルなど、大きな文字が主役の画像：Turbo で十分。今回の題材では大きな文字の誤りはゼロでした。小さな文字が多い場面では、数枚作って良いものを選びます - 写真の質感や背景の情報量を最大にしたい最終版：従来版。Turbo で当たりの seed を見つけてから、同じ seed とプロンプトで従来版に切り替えると、構図をほぼ保ったまま描き込みを増やせます - 仕事や収益につながる用途：どちらも無償では使えません（次の章） 商用利用はできる？ ライセンスを条文で確認する 速さと同じくらい大事なのが、このモデルを仕事に使ってよいかです。結論から書くと、従来版も Turbo も、無償で使えるのは「研究・評価」だけで、商用で使うには別のライセンスが必要です。 2つのモデルは同じライセンス Hugging Face の2つのリポジトリにある LICENSE を取得して比べたところ、中身は1文字も違いませんでした。どちらも Qwen RESEARCH LICENSE AGREEMENT（2026年9月20日版） です。モデルカードの license 欄も両方 other（名前は qwen-research）になっています。 条文のうち、使い方に直接かかわる部分を日本語で要約します（原文は英語です。正確な文言は必ず原文で確認してください）。 | 条項 | 書かれていること（要約） | 実務での意味 | |---|---|---| | 1-i 定義 | 「Non-Commercial（非商用）」とは研究または評価の目的に限ること | 「商用でなければ何でも可」ではない。個人の趣味の利用がどちらに入るかは明記がない | | 2-a 許諾 | 利用・複製・配布・改変・派生物の作成を、非商用の目的に限り無償で許諾 | 試す・比べる・検証記事を書く、は OK | | 2-b 商用 | 別途の商用ライセンスなしに商用目的で使ってはならない。窓口は model-business@notice.qwencloud.com | 業務・販売・広告収益につながる利用は申請が必要 | | 3 再配布 | ライセンスの写しを渡す、変更したファイルにその旨を書く、所定の帰属表示（Notice）を残す | 重みを配る・改変版を公開するときの条件 | | 4-b | 出力などを使って AI モデルを作り公開するなら「Built with Qwen」などと表示 | 生成画像で別のモデルを学習させる場合 | | 4-c | 派生物の主な名前に「Qwen」を使わない（説明的な使い方は可） | ファインチューン版の命名 | | 8 準拠法 | 中国法、杭州の人民法院が専属管轄 | 紛争になったときの場所 | 生成した画像そのものの扱いを個別に定めた条文はありません。ただ、許諾されているのは「非商用の目的での利用」なので、商用の目的でモデルを動かして画像を作ること自体が許諾の外と読むのが自然です。たとえば次のような使い方は、「研究・評価」とは言いにくいでしょう。 - 広告やアフィリエイトで収益を得ているブログ・サイトのアイキャッチやバナー - 会社の業務資料、広告、商品ページの画像 - クライアントに納品するデザインやイラスト - 自社サービスに組み込んで、利用者に画像生成を提供すること 一方、性能を試す、ほかのモデルと比べる、その結果を検証記事として公開する、といった使い方は「評価」にあたります。この記事の作例も、モデルの評価として生成したものです（記事のアイキャッチには使っていません）。 以前の Qwen-Image は Apache 2.0 だった ここは誤解しやすい点です。2025年8月の初代 Qwen-Image や、12月の Qwen-Image-2512・Qwen-Image-Edit-2511・Qwen-Image-Layered は、Hugging Face 上のライセンスが Apache 2.0 で、商用利用も認められていました。2.1 から研究用ライセンスに変わったため、「Qwen の画像モデルは商用 OK」という以前の感覚のまま使うと危険です。 商用で使いたいときの3つの道 !使う目的が研究・評価なら無償で利用でき、商用なら別途ライセンスの申請・Alibaba CloudのAPI・Apache 2.0の旧モデルの3つの道があることを示す判断フロー 図7：その使い方は無償で OK？（Qwen Research License の判断フロー） 1. Qwen に商用ライセンスを申請する：ライセンス第2条bの窓口（model-business@notice.qwencloud.com）に問い合わせます。条件や費用は公開されていません。 2. Alibaba Cloud の API を使う：Turbo の発表と同時に、Alibaba Cloud Model Studio で Qwen-Image-2.1 の Pro と Turbo の API が提供されました。公式ドキュメントの料金は Turbo が 1枚 0.1 元、Pro が 1枚 0.25 元（2026年10月10日に確認、キャンペーン価格を除く）です。公式も「アプリケーションにはホスティング済みの API を」と案内しています。これは重みのライセンスとは別の、Alibaba Cloud のサービス契約で使う形です。ただし注意点があります。Model Studio の固有条項（Service-Specific Terms）では、コンソールの「試用（Trial）」で生成したコンテンツは性能評価にしか使えず、商用を含むほかの目的には使えないと明記されています。一方、API 呼び出しで生成した画像の権利や商用利用について、固有条項ははっきり書いていません。商用で使う前に、サービス契約（Service Agreement）を読むか、Alibaba Cloud に確認してください。 3. Apache 2.0 の旧モデルを使う：2.1 で加わった機能や改善は使えませんが、ライセンス上は商用で使えます。 > この節はライセンス文書を読んだうえでの整理で、法的な助言ではありません。仕事で使う場合は、原文と、必要なら専門家の確認をおすすめします。 手元で動かす手順（Mac の例） ここからは、この記事の比較を再現する手順です。Apple Silicon の Mac（メモリ 64GB 以上を推奨）を前提にしています。NVIDIA GPU の環境では "mps" を "cuda" に、計測用の torch.mps.synchronize() を torch.cuda.synchronize() に読み替えてください（今回確かめたのは Mac だけです）。 1. 必要なもの | 項目 | 目安 | |---|---| | メモリ | 1モデルあたり読み込み後 30.3GB、1024px 級の生成中のピーク 31.5GB（今回の実測）。2048px の生成や2モデル同時ではさらに増える | | ディスク | Turbo 約 32.5GB、従来版 約 33.1GB（両方なら約 66GB） | | Python | 3.12（今回は uv で仮想環境を作成） | | diffusers | GitHub の最新版。Turbo には、パイプラインに予定表（sample_sigmas）を持たせる変更（PR 14950、10月5日マージ）が必要 | | transformers | 5.17.0 以上 | 2. 環境を作る 作業用のフォルダで、次のコマンドを実行します。 # 作業フォルダと Python 3.12 の仮想環境を作る mkdir -p qwen-image-turbo-lab && cd qwen-image-turbo-lab uv venv -p 3.12 .venv # PyTorch（Mac では MPS 対応版が入る）と、最新の diffusers などを入れる uv pip install -p .venv/bin/python torch torchvision "transformers>=5.17.0" accelerate pillow \ "huggingface_hub[hf_xet]" "git+https://github.com/huggingface/diffusers.git" 3. 重みをダウンロードする hf download で取得できます。ファイルが大きいので、時間に余裕を見てください。 # Turbo（約 32.5GB） .venv/bin/hf download Qwen/Qwen-Image-2.1-Turbo --local-dir models/Qwen-Image-2.1-Turbo --exclude "assets/*" # 比較用の従来版（約 33.1GB） .venv/bin/hf download Qwen/Qwen-Image-2.1 --local-dir models/Qwen-Image-2.1 > 今回の環境では、hf download が途中で止まって進まなくなりました。その場合は curl -L -r 開始位置-終了位置 で範囲を分けて並列に取得してつなぎ合わせ、最後にファイルの SHA-256 を Hugging Face の API（/api/models/Qwen/モデル名?blobs=true の lfs.sha256）と照合すると確実です。 4. Turbo で1枚生成する Turbo は、同梱の8ステップの予定表が自動で使われます。num_inference_steps を指定しても上書きされない点に注意してください。 import torch from diffusers import QwenImage21Pipeline # Turbo を読み込む（bf16、Mac なら "mps"、NVIDIA なら "cuda"） pipe = QwenImage21Pipeline.from_pretrained( "models/Qwen-Image-2.1-Turbo", torch_dtype=torch.bfloat16 ).to("mps") prompt = ( "日本のラーメン店の壁に掛かった木製のメニュー板を正面から撮った写真。一番上に赤い文字で「お品書き」。" "その下に黒い横書きの文字で、上から順に「醤油らーめん 850円」「味噌らーめん 900円」と並ぶ。写実的な写真。" ) image = pipe( prompt=prompt, width=1024, height=1024, # 公式の既定は 2048x2048。速さを優先するなら 1024 級 use_kv_cache=True, # 既定値。プレフィックス KV キャッシュ generator=torch.Generator("cpu").manual_seed(1), ).images[0] image.save("turbo.png") 5. 従来版で同じ条件の1枚を作る 従来版は、公式サンプルと同じ40ステップを指定します。 base = QwenImage21Pipeline.from_pretrained( "models/Qwen-Image-2.1", torch_dtype=torch.bfloat16 ).to("mps") image = base( prompt=prompt, width=1024, height=1024, num_inference_steps=40, # 公式サンプルの値 generator=torch.Generator("cpu").manual_seed(1), ).images[0] image.save("base.png") 6. 透過画像（RGBA）を作る プロンプトの最初と最後に、公式が推奨する定型文を入れると、背景が透明な PNG が出てきます。 image = pipe( prompt="This is an RGBA image with transparency. 「よろしく！」と書かれた吹き出しを持つ柴犬のステッカー。" "The image has alpha channel and the background is transparent.", width=1024, height=1024, generator=torch.Generator("cpu").manual_seed(1), ).images[0] image.save("sticker.png") # mode は RGBA 7. Mac で編集するなら、入力画像の変換は CPU で行う 今回いちばん時間を取られた落とし穴です。Mac の GPU（MPS）で VAE のエンコーダーを動かすと、約100万画素（1024×1024 前後）以上の入力画像を正しく潜在表現に変換できませんでした。同じ画像を CPU で変換した結果と比べると、潜在表現が相対誤差で約71%ずれ、画像に戻したときの誤差も CPU の 0.3〜0.5% に対して MPS は 34〜46% でした（512×512 や 1152×864 では 2% 前後）。 この状態で編集すると、浮き彫りのような灰色の画像や、真っ黒な画像（NaN）が出ます。画像の生成（文章から）は入力画像を使わないので影響を受けません。対策として、入力画像の変換だけ CPU（float32）で行うようにパイプラインを包みます。 import copy, torch def encode_condition_on_cpu(pipe): """編集の入力画像だけ CPU の VAE で潜在表現にする（MPS の VAE エンコーダー対策）""" cpu_vae = copy.deepcopy(pipe.vae).to("cpu", torch.float32) orig = pipe._encode_vae_image def encode(image, generator): dev, dt = image.device, pipe.vae.dtype gpu_vae, pipe.vae = pipe.vae, cpu_vae # 一時的に CPU の VAE に差し替える try: latents = orig(image.to("cpu", torch.float32), generator) finally: pipe.vae = gpu_vae return latents.to(dev, dt) pipe._encode_vae_image = encode return pipe pipe = encode_condition_on_cpu(pipe) # 以後の編集はこの pipe で行う _encode_vae_image は diffusers の内部メソッドなので、将来の版で名前が変わる可能性があります。MPS 側が直れば不要になる回避策として使ってください。 8. 両方を使うなら、テキストエンコーダーと VAE を共有する 重みの比較で分かったとおり、従来版と Turbo のテキストエンコーダーと VAE は同じ値です。両方を1つのプログラムで使うなら、Turbo を読み込むときに従来版の部品を渡すと、メモリとディスクの読み込みを節約できます。 base = QwenImage21Pipeline.from_pretrained( "models/Qwen-Image-2.1", torch_dtype=torch.bfloat16 ).to("mps") # Turbo は DiT（transformer）と予定表だけを読み込み、ほかは従来版のものを使い回す turbo = QwenImage21Pipeline.from_pretrained( "models/Qwen-Image-2.1-Turbo", torch_dtype=torch.bfloat16, text_encoder=base.text_encoder, vae=base.vae, ).to("mps") 今回の Mac では、2つを別々に読み込むと約61GB だったのに対し、共有すると 44.3GB で収まりました。共有した Turbo で作った画像は、単独で読み込んだ Turbo の画像とピクセル単位で完全に一致しています。 9. 生成時間を段階別に測る 今回の計測では、パイプラインの encode_prompt（文章の読み取り）と vae.decode（画像への変換）を時刻を記録する関数で包み、各ステップの終わりは callback_on_step_end で記録しました。MPS（Apple Silicon の GPU）は処理が非同期に進むので、記録の前に torch.mps.synchronize() を呼ばないと正しい時間になりません。最小限の形は次のとおりです。 import time, torch def timed(pipe, **kwargs): """1枚を生成し、文章の読み取り・ノイズ除去・画像への変換の秒数を返す""" rec = {"encode": 0.0, "decode": 0.0, "steps": []} enc, dec = pipe.encode_prompt, pipe.vae.decode def encode_prompt(*a, **k): # 文章（と参照画像）の読み取り torch.mps.synchronize(); t = time.perf_counter() out = enc(*a, **k) torch.mps.synchronize(); rec["encode"] += time.perf_counter() - t return out def decode(*a, **k): # 潜在表現から画像へ torch.mps.synchronize(); t = time.perf_counter() out = dec(*a, **k) torch.mps.synchronize(); rec["decode"] = time.perf_counter() - t return out def on_step_end(p, i, t, kw): # 各ステップの終わりの時刻 torch.mps.synchronize(); rec["steps"].append(time.perf_counter()) return {} pipe.encode_prompt, pipe.vae.decode = encode_prompt, decode try: torch.mps.synchronize(); t0 = time.perf_counter() image = pipe(callback_on_step_end=on_step_end, **kwargs).images[0] torch.mps.synchronize(); total = time.perf_counter() - t0 finally: pipe.encode_prompt, pipe.vae.decode = enc, dec denoise = rec["steps"][-1] - t0 - rec["encode"] return image, {"total": total, "encode": rec["encode"], "denoise": denoise, "decode": rec["decode"]} 比べるときは、従来版と Turbo を交互に動かしてください。同じ Mac でほかのアプリが GPU を使うと速度が揺れるため、片方をまとめて測ると条件がずれます。 つまずきやすい点と対処 今回の検証で実際に引っかかった点と、公式資料に書かれている注意点をまとめます。 | 症状 | 原因 | 対処 | |---|---|---| | QwenImage21Pipeline が見つからない、Turbo が8ステップにならない | diffusers が古い。モデルカードによると、Turbo の予定表（sample_sigmas）を読む処理は PR 14950（10月5日マージ）が必要 | pip install git+https://github.com/huggingface/diffusers.git で最新版を入れる | | Turbo で num_inference_steps を変えても回数が変わらない | 仕様（モデルカードに明記）。同梱の予定表が優先される | 実験したいときは sigmas=[...] を明示する（公式は8ステップ以外を評価していない） | | JPEG で保存すると cannot write mode RGBA as JPEG | 2.1 は透過を頼まない画像も RGBA で返す | image.convert("RGB").save("a.jpg")。今回の普通の画像でも、画素の最大約2.6%がわずかに透けていた（不透明度 193〜254） | | hf download が途中で止まる | 大きなファイルの取得が詰まる（今回は 200MB 台で停止） | 範囲指定（curl -r）の並列取得に切り替え、SHA-256 で照合する | | メモリが足りない | 1モデルで約 31GB。両方を別々に読むと約 61GB | 片方ずつ動かす。両方使うなら、テキストエンコーダーと VAE を共有すると 44.3GB（手順8） | | 生成時間を測ると、ステップの時間がばらつく | MPS（Apple Silicon の GPU）は非同期に動く。ほかのアプリが GPU を使うと遅くなる | 測る前後で torch.mps.synchronize()。比べたい2つを交互に動かし、中央値で比べる | | 透過画像を作りたい | 2.1 はプロンプトの内容で透過にするかを決める | 公式推奨の定型文を入れる。最初に This is an RGBA image with transparency.、最後に The image has alpha channel and the background is transparent.（今回は4枚とも透過で出た） | | Mac で編集すると浮き彫りのような灰色の画像や、真っ黒な画像になる | MPS の VAE エンコーダーが、約100万画素以上の入力画像を正しく変換できない（今回の環境で確認） | 入力画像の変換だけ CPU で行う（手順7）。または入力を小さくする | まとめ Qwen-Image-2.1-Turbo を、従来版と同じ条件で動かして比べました。 - 速さ：1024px 級で 3分56秒 → 50秒、約4.7倍。1ステップの重さは同じで、ノイズ除去の回数が40→8に減った分だけ速くなる。文章の読み取りと画像への変換は短くならないため、ちょうど5倍にはならない - 仕組み：テキストエンコーダーと VAE は従来版と値まで同じで、変わったのは DiT の重み（約0.24%）と8回分の予定表。従来版をただ8回で止めると画像が崩れるので、「少ない回数で仕上げる」ための再学習こそが Turbo の中身。プレフィックス KV キャッシュと CFG なしは、2.1 共通の設計 - 画質：同じ seed ならほぼ同じ構図。大きな見出し・メニュー・ラベルの文字は両方とも正確で、差が出たのは小さな文字が散らばる場面と、背景・質感の描き込み（Turbo は約0.9倍） - Mac での注意：MPS で VAE エンコーダーを動かすと、約100万画素以上の入力画像を正しく変換できず、編集が壊れる。入力画像の変換だけ CPU で行えば直る（文章からの生成は影響なし） - ライセンス：従来版と同じ Qwen Research License。無償で使えるのは研究・評価だけで、商用には別途ライセンスか API の検討が必要 使い分けとしては、Turbo でプロンプトと seed を素早く探し、最後の1枚だけ従来版で仕上げるのが、今回の結果からいちばん効率のよい使い方だと感じました。同じ seed で構図が保たれるので、探した結果がそのまま最終版に生きます。 次に試すなら、Mac 向けに量子化した MLX 版（コミュニティが公開した 4bit・8bit など）でどこまで速くなるか、そして公式の Turbo API と手元の生成を、品質と1枚あたりの費用で比べてみたいところです。 参考リソース - Qwen/Qwen-Image-2.1-Turbo（Hugging Face のモデルカード） - Qwen/Qwen-Image-2.1（Hugging Face のモデルカード） - QwenLM/Qwen-Image-2.1（GitHub。Turbo の使い方、アーキテクチャ、ライセンス） - Qwen-Image-2.1 公式ブログ（混合粒度アテンションと KV キャッシュの説明） - Qwen RESEARCH LICENSE AGREEMENT（ライセンス原文） - diffusers PR 14950：QwenImage21Pipeline に固定の予定表を持たせる変更 - Alibaba Cloud Model Studio：qwen-image-2.1-turbo の料金 - Alibaba Cloud Model Studio：Service-Specific Terms（試用で生成したコンテンツの扱い） - Comfy-Org/Qwen-Image-2.1（ComfyUI 用の再パッケージ。Turbo と差分 LoRA） - vLLM-Omni のレシピ：Qwen-Image-2.1（プレフィックス KV キャッシュの効果） - PC Watch「高速版『Qwen-Image-2.1-Turbo』重み公開、画像生成8ステップで完了」（2026年10月9日）

Qwen-Image-2.1-Turbo Isn't 7B: The VRAM You Actually Need to Run It Locally Qwen-Image-2.1-Turbo gets called a "7B" model everywhere. Before you try to run it locally, know that the Hugging Face repo is 32.4 GB, the bundled text encoder is bigger than the image model, and the license rules out anything you get paid for. Qwen released Qwen-Image-2.1-Turbo on 2026-10-09, 19 days after the base Qwen-Image-2.1. It's an accelerated checkpoint that generates and edits images in 8 denoising steps. The base model's default is 40. I'll cover what changed, how much VRAM it really needs, how to run it with diffusers and ComfyUI, and two config gotchas, one of which has already started a "poor results in comfy" thread. What changed from Qwen-Image-2.1 Not much in the architecture. The model card says Turbo "uses the same 7B visual generation architecture" and loads with the same QwenImage21Pipeline. The differences: - 8 steps instead of the base default of 40 (GitHub README). - The schedule is baked in: model_index.json carries a fixed sample_sigmas list, 1.0, 0.978453, 0.95418, 0.926626, 0.89508, 0.845148, 0.704534, 0.414568. - CFG=1 by default, so there's one forward pass per step. - Features are unchanged: text-to-image, editing with reference images, RGBA transparency output, and the same 2K-level resolution presets (2048×2048 at 1:1, 2752×1536 at 16:9). So you're doing a fifth of the denoising work. Qwen publishes no Turbo speed numbers or quality benchmarks, either on the card or in the README, so everything you'll read about Turbo being "just as good" comes from showcase images Qwen picked themselves. For scale, here are base-model numbers from LightX2V's RTX 5090 table: 5.586 s at 1024×1024 and 30.333 s at 2048×2048, both at 40 steps with CFG disabled. Turbo should come in well under that, but I couldn't find a Turbo figure on NVIDIA hardware. The one real-hardware Turbo number I found comes from the author of a native Mac port (HF discussion #5): about 120 s at 1024² on an M1 Pro with 16 GB. The "7B" number hides most of the download My research machine has no GPU, so I couldn't time generations. I did read the safetensors headers of every component straight from the Hub (range requests, no full download) and added up the parameters: | Component | Params | BF16 file size | |---|---|---| | Transformer (DiT, 32 layers) | 7.115B | 14.23 GB | | Text encoder (Qwen3-VL 8B) | 8.767B | 17.53 GB | | VAE | 0.338B | 0.68 GB | | Total | 16.22B | 32.44 GB | The "7B" is the denoiser alone. The full pipeline has 16.2B parameters, and over half of them are a vision-language model that encodes your prompt and reference images. That's also why VRAM estimates for this model are all over the place. vLLM-Omni's recipe measured the base model, which has the same architecture, at 34.0 GB peak on a GB300 at 1024×1024 in BF16. That's more than a 32 GB RTX 5090 holds, unless you offload something. How much VRAM you need at each precision The text encoder runs once per prompt, while the DiT runs every step. So you can offload the encoder or quantize it hard and lose very little. Here are weight totals for the practical combinations, using file sizes from Comfy-Org/Qwen-Image-2.1 and unsloth/Qwen-Image-2.1-Turbo-GGUF: | Setup | DiT | Text encoder | VAE | Weights total | |---|---|---|---|---| | Full BF16 (diffusers default) | 14.23 GB | 17.53 GB | 0.68 GB | 32.44 GB | | ComfyUI INT8 DiT + INT8 encoder | 7.26 GB | 9.35 GB | 0.68 GB | 17.29 GB | | ComfyUI INT8 DiT + W4A8 encoder | 7.26 GB | 6.31 GB | 0.68 GB | 14.25 GB | | GGUF Q8_0 + W4A8 encoder | 7.64 GB | 6.31 GB | 0.68 GB | 14.63 GB | | GGUF Q4_K_M + W4A8 encoder | 4.20 GB | 6.31 GB | 0.68 GB | 11.19 GB | These are weight sizes, not measured peaks. Activations come on top, and at native 2K they get big. ComfyUI and diffusers offload both swap models in and out, so the number that matters on a small card is roughly DiT plus activations. My rough guide: - 40 GB+ cards: run everything in BF16 and keep it resident. - 24–32 GB: BF16 DiT with the text encoder offloaded, or the INT8 Comfy files. - 12–16 GB: GGUF Q4_K_M to Q8_0 for the DiT, a 4-bit encoder, and offloading. - Apple silicon, 16 GB: the Siliconed app (Swift/Metal) supports the full weights, Comfy's int8, or Q4_K_M. On quant quality: Unsloth published LPIPS against the BF16 Turbo transformer (lower is better). Q8_0 scores 0.036, Q4_K_M 0.153, and Q2_K 0.374. They recommend Q4_K_M for most GPUs and warn that the 2- and 3-bit files "drift visibly from bf16 at 8 steps." Few-step models have less room to absorb quantization error than a 40-step model does, so I'd treat Q4_K_M as the floor. How to run it with diffusers Turbo needs a diffusers build with pipeline-configured sigmas (PR #14950) and a recent transformers. The card tells you to install diffusers from source: pip install git+https://github.com/huggingface/diffusers.git pip install "transformers>=5.17.0" accelerate pillow That PR also shipped in the diffusers 0.41.0 release on PyPI (2026-10-06), so pip install "diffusers>=0.41.0" works too. This is the card's example with a shorter prompt, 1024×1024 instead of the card's 1680×2512, and CPU offload added, which is what most people on a single consumer GPU will want: import torch from diffusers import QwenImage21Pipeline pipe = QwenImage21Pipeline.from_pretrained( "Qwen/Qwen-Image-2.1-Turbo", dtype=torch.bfloat16, ) pipe.enable_model_cpu_offload() # drop this and use .to("cuda") if you have ~40 GB image = pipe( prompt="A hand-lettered chemistry study poster titled \"Chemical Reactions and Equations\"", width=1024, height=1024, use_kv_cache=True, generator=torch.Generator("cpu").manual_seed(42), ).images[0] image.save("t2i.png") Gotcha number one: num_inference_steps does nothing on its own here. The card is explicit: "Setting num_inference_steps alone does not override" the saved schedule. To try other step counts you have to pass sigmas= explicitly, and Qwen says other schedules "have not been evaluated." If you tried 4 steps and the output didn't change, that's why. For editing, pass image=load_image(...).convert("RGBA") to the same pipeline. The prefix KV cache (use_kv_cache=True) encodes the prompt and reference images once and reuses them across all 8 steps. How to run it in ComfyUI without getting mush ComfyUI has supported Qwen-Image-2.1 natively since day 0. Put these files from Comfy-Org/Qwen-Image-2.1 in your models/ folders: - diffusion_models/qwen_image_2.1_turbo_bf16.safetensors (or _int8_convrot) - text_encoders/qwen3vl_8b_bf16.safetensors (or _int8_convrot / _w4a8) - vae/qwen_image_2.1_vae_bf16.safetensors Start from the official text-to-image workflow. Gotcha number two: a plain KSampler at 8 steps doesn't reproduce Turbo's schedule. The fix in discussion #4 ("For anyone getting poor results in comfy") is to switch to SamplerCustomAdvanced with a ManualSigmas node set to: 1.0, 0.978453, 0.95418, 0.926626, 0.89508, 0.845148, 0.704534, 0.414568, 0.0 Use euler and CFG 1. Save that node as a subgraph so you don't have to retype it every time. If you already have the base model, Comfy-Org also ships qwen_image_2.1_turbo_lora_avg_rank_178_bf16.safetensors (0.91 GB), a LoRA extracted from Turbo. You can apply it to the base DiT instead of downloading a second 14 GB checkpoint. The license is the actual headline The original Qwen-Image from August 2025 was Apache-2.0. Qwen-Image-2.1 and Turbo use the Qwen Research License Agreement, which grants rights "FOR NON-COMMERCIAL PURPOSES ONLY" and defines non-commercial as "for research or evaluation purposes only." For commercial use you email model-business@notice.qwencloud.com and ask. Disputes go to courts in Hangzhou under Chinese law. On the same day the Turbo weights went up, Qwen also launched paid Pro and Turbo APIs on Alibaba Cloud Model Studio. Planned or not, that's how it works out: you can run it at home for free, and if you want to put it in a product you pay Alibaba. So, can it replace Midjourney? For personal work and experiments, an 8-step model with good text rendering, native transparency and multi-image references is a strong offer. For client work, read the license before you cancel anything. Is Qwen-Image-2.1-Turbo worth running locally? If you have 16 GB or more of VRAM and you want to try text-heavy posters, UI mockups or transparent assets, yes. Get Q8_0 or INT8 and set the sigmas correctly. If you need clean commercial rights, the Apache-licensed Qwen-Image from 2025 is still the one you're allowed to ship with. Has Turbo at 8 steps actually replaced a paid image service for you, or does the non-commercial license rule it out before image quality even matters? Post your GPU, quant and seconds per image in the comments. I haven't found proper Turbo benchmarks anywhere yet, so yours would be among the first. Sources - Qwen/Qwen-Image-2.1-Turbo model card and LICENSE - QwenLM/Qwen-Image-2.1 GitHub README - Comfy-Org/Qwen-Image-2.1 repackaged weights - unsloth/Qwen-Image-2.1-Turbo-GGUF - vLLM-Omni Qwen-Image-2.1 recipe - LightX2V Qwen-Image-2.1 scripts - HF discussion #4: ComfyUI sigmas fix - HF discussion #5: Siliconed Mac port

1. diffusers 画像や動画、音声を作る拡散モデルが数行のコードで動く部品集 pip install --upgrade diffusers[torch] huggingface/diffusers t.co

【研究用に重み公開】生成部7BのQwen-Image-2.1で背景除去は省ける？透過素材4候補の選び方 透過PNGを作る人は、Qwen-Image-2.1の「背景まで生成しなくていい」を見ておいてほしい。 画像を生成して、背景を消して、髪や輪郭を直す。その工程を、最初から透明度を持つ画像の生成にまとめる選択肢が出てきた。 Qwenが2026年9月20日に公開したQwen-Image-2.1は、画像生成部分が7B、約70億パラメータ。しかも、次の3つを同じモデルで扱う。 - RGBと透明度を持つRGBA画像を生成する。 - 最大10枚の参照画像を使って編集する。 - テキストと参照画像の計算を、複数のノイズ除去ステップで再利用する。 それが今回のQwen-Image-2.1だ。決定的なのは、公開VAE設定にあるこの2行である。 "in_channels": 4, "out_channels": 4 透明っぽい背景を描く話ではない。画像表現そのものに、4番目のチャンネルがある。 ただし、ここで「商品写真の背景削除も全部これでいい」と飛びつくと、別の問題にぶつかる。欲しいのは、新しい絵なのか。それとも、元の写真の色を残した切り抜きなのか。 :::note alert 結論から言うと 1. 「新しく描く」「元のRGBを残す」「複数レイヤーに分ける」のどれかを先に決めること。 同じ透過PNGでも、生成モデルとマスク推定モデルでは受け持つ仕事が違う。 2. Qwen-Image-2.1は、色と透明度を扱う生成モデルである。 RGBA対応VAEに加え、変化しない参照情報をキャッシュできるAttention設計を持つ。 3. 公開重みの利用条件は研究・評価用途で、7Bもパイプライン全体の規模ではない。 商用利用には別ライセンスが必要で、実行時にはテキストエンコーダやVAEのメモリも考える必要がある。 ::: !濃紺と生成りの背景をまたぐ半透明の羽の蛾と、色を持たない紙の輪郭で、RGBと透明度の分離を表したイラスト 色・透明度・輪郭の違いを表すAI生成イラスト。Qwen-Image-2.1の生成結果や性能実証ではない。 :::note info 確認日は2026年10月7日、主題の公開日は17日前の9月20日。仕様値はQwenの公式資料、実装は当日参照したDiffusersソースに基づく。比較対象は既存モデルも含む。コードは構文、算術、簡略化したマスク規則を確認した。GPU推論・Pillow画像処理・画質比較・VRAM計測は未実行だ。 ::: 数字で見るQwen-Image-2.1 公式リポジトリの仕様とモデルカードを突き合わせると、導入判断に必要な情報はこうなる。 | 項目 | 公開値・条件 | 実装での意味 | |---|---|---| | 画像生成Transformer | 7B | 全コンポーネントの合計ではない | | Transformerの深さ | 32層 | Single-Stream DiT | | テキスト・画像条件のエンコーダ | Qwen3-VL 8B | 生成Transformerとは別に読み込む | | VAEの入出力 | 4チャンネル | RGBとalphaを扱う | | VAEの潜在表現 | 64チャンネル、空間方向16倍圧縮 | ピクセル空間と潜在空間を区別する | | 既定の画像サイズ | 2048×2048 | 4,194,304画素。値は縦横から算出 | | 既定の推論ステップ | 40 | 参照情報を繰り返し使う場面がある | | 参照画像数 | 最大10枚 | 条件を増やせるが、順序も入力の一部 | | 公開重みのライセンス | Qwen Research License | Materialsの商用利用は別契約が必要 | ここまでは「透過画像を作れるモデル」の話。面白いのはその先だ。 何を生成し、何を残すのか。答えは4番目の値にある 透過生成と背景削除は、出力が同じでも処理が違う 1画素の色をRGB、透明度をalphaと呼ぶ。alphaが0なら完全透明、1なら不透明として、背景に重ねる基本形は次のように書ける。 C = alpha * F + (1 - alpha) * B Fは前景の色、Bは背景の色、Cは合成後の色で、各RGB成分に同じ式を適用する。これは共通の線形色空間で考えた非乗算済みalphaの式であり、PNGのsRGB値にそのまま適用する実装を推奨する式ではない。 QwenのVAE設定は、4チャンネルの入出力と64チャンネルの潜在表現を持つ。つまり、モデルに求めるのは色と透明度を含む画像の生成・編集だ。 一方、BiRefNetの公式例は、推定したマスクを元画像のサイズに戻し、image.putalpha(mask)で付ける。こちらは、読み込んだRGBの値を残して、どこを見せるかを変える処理である。 この差は、商品ラベルの1文字や、印刷物の色を残したいときに効く。 | 一次資料から確認できること | そこから選べる処理 | 保証されていないこと | |---|---|---| | QwenのVAEは4チャンネルを入出力する | 新しい色・形・透明度を生成する | 編集前後のRGBが全画素で一致すること | | BiRefNetの例は元画像にマスクを付ける | 元RGBを保持して前景を切り抜く | 推定境界が常に正しいこと | | Qwen-Image-Layeredは複数RGBA層を出す | 分解後に要素を別々に動かす | 分解時に元画像の全画素を厳密再現すること | 最後の行はQwen-Image-Layeredの説明に基づく。レイヤー分解後に他の層を触らず編集できることと、分解が元画像を完全保存することは、別の主張だ。 さらに、マスクだけの処理にも限界がある。写真の輪郭には、撮影時の背景色がすでに混ざっている場合がある。そのRGBを厳密に残せば、白い背景の名残も残り得る。RGB保存と、境界の色かぶり除去は、同時に無条件では要求できない。 キャッシュが使えるのは、参照側が「未来」を見ないから もう1つの仕掛けが、Mixed-Granularity Attentionだ。 Qwenの実装では、トークン列の前方には注意を向けられ、同じ画像ブロック内では双方向に注意を向けられる。テキストは因果的、画像の内部は双方向、ブロック間は順序を持つ。 条件を前、生成対象を後ろに置いた簡略図なら、こうなる。 | Query側 | 先行テキスト | 参照画像A | 後続の参照画像B | 生成対象 | |---|---|---|---|---| | 参照画像A | 見る | 内部は双方向 | 見ない | 見ない | | 参照画像B | 見る | 見る | 内部は双方向 | 見ない | | 生成対象 | 見る | 見る | 見る | 内部は双方向 | 生成対象が次のステップで変わっても、参照側はそれを見ない。だから参照側の計算を固定しやすい。 ただし、Attentionの向きだけでは足りない。 ノイズ除去モデルには「今どの時刻のノイズを処理しているか」という条件も入る。参照側まで毎回違う時刻で変調したら、そこも毎回変わってしまう。 そこで同じ実装のコメントには、こうある。 > Text and condition-image tokens take the t = 0 row テキストと参照画像には固定のt=0、生成対象には現在の時刻を使う。causal_condition=Trueが、この分離を成立させる。 未実行の概念用疑似コードで表すと、次の形だ。実APIではない。 # 概念用疑似コード・未実行。prefixの計算は各層で行う。 cache = None for t in denoising_times: if cache is None: target, cache = step_with_prefix( prefix, target, prefix_time=0, target_time=t ) else: target = step_with_cached_prefix(target, cache, target_time=t) 40ステップなら、初回に参照側のK/Vを保存し、残る39ステップで再利用する構造になる。ただし、生成対象側のQueryから参照K/Vを見る計算は残る。40回の生成を1回にする仕組みではない。 この設計から、参照画像を多く使う編集はキャッシュの効果を調べる有力な対象だと考えられるが、速度倍率は実測なしには出せない。 今すぐ試すべき2つの生成経路 あなたが欲しいのは、架空の新素材と、既存写真の忠実な切り抜きのどちらだろう。どちらの需要が大きいと思うか、あなたの予想もコメントで教えてほしい。 以下は研究・評価用の試行である。公式Quick StartのAPIとモデルカードの推奨プロンプト形式を使い、題材と保存名を変更した。CUDA環境を想定し、インストールと推論は未実行だ。 python -m pip install 'torch>=2.4.0' 'transformers>=5.17' accelerate pillow python -m pip install 'git+https://github.com/huggingface/diffusers' 比較実験に進む際は、動作確認したDiffusersのコミットとチェックポイントrevisionを記録すること。上の公式手順は開発版を取得するため、同じコマンドでも将来の中身は変わる。 1. 新規イラストを、最初から透過素材として作る（未実行） 背景を消すことより、背景なしで成立する構図を作ることが目的だ。次をPythonで実行する。 import torch from diffusers import QwenImage21Pipeline pipe = QwenImage21Pipeline.from_pretrained( "Qwen/Qwen-Image-2.1", torch_dtype=torch.bfloat16 ) pipe.enable_model_cpu_offload() def rgba_request(subject): return ( "This is an RGBA image with transparency. " + subject + ". The image has alpha channel and the background is transparent." ) result = pipe( prompt=rgba_request("A red origami crane sticker, complete silhouette"), width=2048, height=2048, num_inference_steps=40, generator=torch.Generator("cuda").manual_seed(42), ) result.images[0].save("new_asset.png") メモリ配置は公式のCPU offload例を採用した。CPU側への退避を使う構成であり、特定のGPU容量で必ず動くという意味ではない。 2. 参照画像の見た目を変え、透過素材として出す（未実行） たとえば、自分が利用できる参照イラストを、別の質感の素材に展開する。上と同じPythonセッションで、公式の画像編集APIにimageを渡す。 from PIL import Image reference = Image.open("reference.png") edited = pipe( image=reference, prompt=rgba_request( "Reimagine the subject from the reference as a felt ornament, " "keeping its overall silhouette, with no surrounding scene" ), num_inference_steps=40, generator=torch.Generator("cuda").manual_seed(42), ) edited.images[0].save("edited_asset.png") 参照は制作の条件として使う。ここで求めたのは質感の変更なので、RGBが変わることは目的に合っている。逆に、ラベルや図面の元画素を残す仕事なら、後述のマスク方式を先に試す方が要件に合う。 知らないと損する4つの罠 罠1：重みが公開されているので、そのまま商用工程に入れる LICENSEの1(i)は、Non-Commercialを次のように定義している。 > "Non-Commercial" shall mean for research or evaluation purposes only. 2(a)の利用許諾はこの範囲に限られ、2(b)はMaterialsの商用利用に別ライセンスを求める。無償でダウンロードできることだけでは、業務投入の条件を満たさない。 対策：評価と商用導入を分け、使う重みのLICENSEを確認すること。 ここで述べているのはモデル等のMaterialsの利用条件であり、生成物の所有権やあらゆる出力利用を一律に判定したものではない。 罠2：7Bだから14GBあれば全部載る Architecture欄は、7Bの生成Transformerとは別にQwen3-VL 8Bを挙げている。 7Bを1パラメータ2 byteで単純計算すると、7×10^9×2 = 14×10^9 byte、約13.0 GiBだ。これは丸めた7Bから計算した生成Transformerの重み相当量だけである。 テキストエンコーダ、VAE、活性値、Attention用バッファ、キャッシュを足していない。配布サイズや実際のピークVRAMとも一致するとは限らない。 対策：7Bを購入GPUの容量表に直接変換せず、全コンポーネントと解像度を含むピークメモリで判断すること。 罠3：RGBAに変換できたので、透過生成は成功した Pillowのconvertとputalphaの仕様を読むと、チャンネルを付ける操作と、その値を検証する操作は分かれている。 RGB画像をconvert("RGBA")しただけなら、全画素が不透明でもRGBAになる。PNG拡張子やチェッカーボード風の絵も、透明度の証拠にはならない。 対策：変換前の出力を調べ、alphaの分布と合成結果の両方を確認すること。 次は8bit RGBA出力専用の検査例だ。Pillowの公式APIに基づく独自コードで、未実行である。alpha_audit.pyとして保存し、python alpha_audit.py new_asset.pngで使う。 import json import sys from pathlib import Path from PIL import Image path = Path(sys.argv[1]) with Image.open(path) as source: if source.mode != "RGBA": raise SystemExit(f"RGBA専用検査の対象外: {source.mode}") image = source.copy() hist = image.getchannel("A").histogram() pixels = image.width * image.height used = [value for value, count in enumerate(hist) if count] print(json.dumps({ "alpha_min": min(used), "alpha_max": max(used), "transparent_fraction": hist[0] / pixels, "partial_fraction": sum(hist[1:255]) / pixels, "opaque_fraction": hist[255] / pixels, }, indent=2)) for name, color in [("white", "white"), ("black", "black")]: background = Image.new("RGBA", image.size, color) composite = Image.alpha_composite(background, image).convert("RGB") composite.save(path.with_name(f"{path.stem}-on-{name}.png")) これは合格判定器ではない。完全透明画素が1つあっても、残りの背景が消えているとは限らない。逆に、素材の意図によっては半透明ばかりでも正しい。 白と黒の両背景に重ねれば、片方だけでは見落とす輪郭の白残りや暗い縁を調べられる。この合成は輪郭点検用の簡易プレビューであり、sRGBの線形化や色管理の検証は含まない。パレット透過PNGなどはこのコードの対象外であり、エラーは「透過していない」という判定ではない。 罠4：別のモデルで使っていたCFG設定を、そのまま移植する DiffusersのQwen-Image-2.1用ドキュメントでは、既定は40ステップ、guidanceなしである。negative_promptとtrue_cfg_scale > 1を指定するとCFGが有効になり、1ステップあたりの仕事が倍になる。 キャッシュがあるからといって、この追加処理まで消えるわけではない。生成の所要時間が必ず2倍になるという意味でもないが、既定条件とは違う実験になる。 対策：最初は推奨既定値で比較し、CFGを追加した場合は画質と時間の差をセットで記録すること。 透過素材を作る4候補。選ぶ軸は「何を残したいか」 以下は2026年10月7日に、Qwen-Image-2.1、Qwen-Image-Layered、BiRefNet、RMBG-2.0の公式資料から組み立てた比較だ。処理方式と利用条件の比較であり、同条件の画質ランキングではない。 | 候補 | 主な入力と出力 | 元RGBを残す要件 | 公開重みの利用条件 | 選ぶ場面 | |---|---|---|---|---| | Qwen-Image-2.1 | 指示・任意の参照画像 → 生成・編集画像 | 厳密保存を前提にしない | Research License。商用は別ライセンス | 新規透過素材、質感や構図の変更 | | Qwen-Image-Layered | 画像 → 複数RGBAレイヤー | 分解時の厳密保存は前提にしない | Apache-2.0 | 要素を分けて移動・再配置する | | BiRefNet | 画像 → 前景マスク | 公式例のputalpha処理なら元RGBを保持 | MIT | 写真を描き直さず、マスクで切り抜く基準案 | | BRIA RMBG-2.0 | 画像 → 1チャンネルのalpha matte | 同じく元画像へのマスク付与が可能 | CC BY-NC 4.0。商用は別契約 | BRIAの学習モデル・提供条件で背景除去を評価する | 表から読み取れること： - 新規素材なら、色とalphaを一緒に生成できる点が価値になる。 元RGBを残す必要がないからだ。 - 既存商品の忠実な切り抜きなら、マスク方式から比較できる。 ただし輪郭の誤りや背景色の混入は別に評価する。 - Qwenという名前だけでライセンスを横展開できない。 Image-2.1とImage-Layeredでも条件が違う。 - RMBG-2.0とBiRefNetは、完全に独立した方式ではない。 BRIAはBiRefNetアーキテクチャを利用しており、モデルと学習の違いを比較する組み合わせである。 最後の選択をコードに落とすなら、まず要求を固定する。以下はアプリ側で使うための独自の設定例であり、各ライブラリに直接渡す設定ではない。 { "purpose": "evaluate_photo_cutout", "model_id": "ZhengPeng7/BiRefNet", "preserve_decoded_rgb": true, "allow_foreground_color_correction": false, "output_format": "PNG", "review_backgrounds": ["white", "black"] } preserve_decoded_rgbは、画像ファイルをデコードした後のRGB配列を残すという意味だ。元のJPEGバイト列、EXIF、色管理情報の保存まで含めない。 マスク推定後の処理は、公式例のputalphaを使って次のように書ける。未実行であり、mask.pngは別途推定済みの同サイズのグレースケール画像とする。 from PIL import Image original = Image.open("input.png").convert("RGB") mask = Image.open("mask.png").convert("L") if mask.size != original.size: raise ValueError("元画像とマスクの座標・サイズを一致させること") cutout = original.copy() cutout.putalpha(mask) assert cutout.convert("RGB").tobytes() == original.tobytes() cutout.save("cutout.png") このassertが確かめるのはRGBの保存だけだ。マスクの正解率ではない。色かぶりを消したくなったら、前景色補正を許可するかどうかを改めて決める必要がある。 教訓：透過PNGは、要件の名前として粗すぎる ✗ "透過PNGが出れば同じ処理" → 色を生成する方式と、元RGBにマスクを付ける方式がある ✗ "7Bなら14GBで全部動く" → その計算は生成Transformerの重み相当量だけだ ✗ "40ステップをキャッシュで1回にできる" → 更新する生成対象の計算は残る ✗ "RGBA変換に成功したから切り抜けた" → alphaが全画素255でもRGBAである ✗ "Qwenの重みは全部同じ条件" → チェックポイントごとにライセンスが違う Qwen-Image-2.1で試したいのは、背景除去ツールを一括で置き換えることではない。これまで「まず背景込みで描く」と決めていた素材制作を、最初から色と透明度を生成する工程に変えられるか、という問いだ。 一方、撮影済み商品の表示や正確な図版の切り抜きでは、変えてはいけない部分を先に決める。その条件さえ決まれば、モデル名で迷う時間は減らせる。今日扱う素材を1つ選び、「新しく描くのか、元のRGBを残すのか」を決めてから試してほしい。 参考資料 Qwen-Image-2.1：公式リポジトリ、Quick Start、Architecture QwenLM/Qwen-Image-2.1 Qwen-Image-2.1：公式モデルカード huggingface.co Qwen-Image-2.1：VAE設定 huggingface.co Qwen Research License Agreement（2026年9月20日） github.com/QwenLM/Qwen-Image-2.1/blob/main/LICENSE Diffusers：Qwen-Image-2.1 Transformer実装 raw.githubusercontent.com Diffusers：Qwen-Image-2.1 Pipelineドキュメント raw.githubusercontent.com Qwen-Image-Layered：公式モデルカード huggingface.co BiRefNet：公式モデルカード huggingface.co BRIA RMBG-2.0：公式モデルカード huggingface.co Pillow：Imageモジュール公式リファレンス pillow.readthedocs.io --- 透過素材の生成や商品画像の切り抜きを担当する人は、いいねと保存を。モデルを選んでいるチームにも、この4候補の比較をシェアしてほしい。 コメントで教えてほしい。 - 欲しいのは「新しい透過素材」と「元写真の忠実な切り抜き」、どちら？ - 背景除去で一番困るのは、髪・商品ラベル・ガラスのどれ？ - 生成とマスク推定を、用途別に分けて使う？