はじめに

手元のパソコンで画像生成 AI を動かすと、1枚ごとの待ち時間が気になります。プロンプトを少し直しては数分待つ、を繰り返すと、試行錯誤のテンポがどうしても落ちます。

2026年10月9日、Alibaba の Qwen チームが Qwen-Image-2.1-Turbo の重みを公開しました。9月20日に出た Qwen-Image-2.1 の高速版で、画像生成部の大きさ（7B）はそのままに、ノイズを取り除く工程を40ステップから8ステップに減らしたモデルです。

図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つずつ比べました。

図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になります。

図3：実際の途中経過。各ステップでモデルが予想している完成図（ノイズを除いた推定）を、従来版は5回ごと、Turbo は毎回表示

予定表（シグマ）を短くするだけでは足りない

ステップ数を減らすだけなら、従来版にも num_inference_steps=8 と指定できます。それなのに、なぜ別のモデル（Turbo）が必要なのでしょうか。

鍵は、各ステップでどれだけノイズを減らすかという予定表（シグマのスケジュール）と、それに合わせて学習された重みです。図4は、2つのモデルの予定表を並べたものです。

図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 を指定して動かしてみました。

従来版を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）。

図5：プレフィックス KV キャッシュ。2.1 の設計に組み込まれた仕組みで、従来版と Turbo の両方で働く

Qwen-Image-2.1 の DiT は、指示文・参照画像・生成中の画像を1本の列に並べて計算します。このとき、

前にある指示文や参照画像は、後ろの生成中の画像を見ない（ブロック因果アテンション）
指示文や参照画像は、ノイズの量に関係なく常に「完成時点（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ステップの重さは変わらない：従来版も Turbo も1回のノイズ除去に約5.8秒かかります。速くなったのは、回数が40から8に減ったからです。
5倍には少し届かない：文章の読み取りと画像への変換は Turbo でも同じ時間がかかるため、合計では約4.7倍になります。
どの題材でも傾向は同じ：8種類×2枚のすべてで、Turbo は4.0〜5.3倍速くなりました。

なお、計測中は同じ Mac で別の処理（ローカル LLM）が GPU を使う時間帯がありました。ほかの処理が少ない時間帯に、メニュー板を1モデルずつ読み込んで測り直すと、**従来版 3分24秒 → Turbo 42秒（約4.9倍）**でした。絶対的な時間は Mac の混み具合で変わりますが、倍率はほぼ同じです。

図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倍）で、解説図・ステッカー・商品写真はほぼ同じでした。少ないステップで仕上げるぶん、版画風のざらつきや濡れた路面の細かな反射が、やや滑らかになる傾向です。

日本語の見出し・メニュー板・商品ラベル

アイキャッチ。見出しと副題は4枚とも正確。従来版の seed 1 は、チップに頼んでいない「GRIIDI」という文字を入れた

大きな見出しは、両モデルとも完璧でした。構図も seed ごとにほぼ同じで、Turbo を使っても困る場面はありません。

メニュー板。「お品書き」と5品の名前・価格が4枚とも正確。従来版は木目や店内の照明の描き込みが多い

「醤油らーめん 850円」のような、漢字・ひらがな・数字が混ざった行が5行あっても、両モデルとも1文字も間違えませんでした。Qwen-Image-2.1 の日本語の強さは、Turbo でもそのまま残っています。

商品写真。ラベルの文字は4枚とも正確。構図もほぼ同じで、この題材では差を見つけにくい

小さな文字が多い場面：夜の商店街と解説図

夜の商店街。小さな看板の文字はどちらも完全ではない。seed 1 では従来版が「営業中」「くすり」を描けた一方、Turbo の緑の看板は崩れた。seed 2 では Turbo も「くすり」「営業中」「とり吉」を描けた

暗い場面に小さな看板が並ぶと、両モデルとも取りこぼしが出ます。どちらが上とは言い切れず、seed によって入れ替わりました。濡れた石畳の反射は、従来版のほうが細かく描かれています。

解説図。seed 1 は両モデルとも「3つの箱」の指示を守れず4つに増えた（構図を受け継ぐため、失敗の仕方も似る）。文字の誤り（ボ索）は Turbo だけ

この例は、Turbo の性質をよく表しています。構図は従来版から受け継ぐので、従来版が失敗する seed では Turbo も同じ形で失敗します。そのうえで、細かい文字が1文字崩れるのは Turbo のほうでした。

人物写真

ポートレート。顔立ちと手は両モデルとも自然。従来版は背景（植物・マグカップ）や窓からの光と影が豊かで、Turbo は背景が簡素で光が平板になりやすい

人物の顔や手の破綻は、どちらにも見られませんでした。差が出たのは背景と光で、従来版のほうが「写真らしい情報量」があります。広告や作品の最終版に使うなら従来版、ラフや構図検討なら Turbo で十分、という印象です。

透過ステッカーと英語のポスター

透過ステッカー（背景の市松模様は透明な部分）。4枚とも透過は正しく出た。Turbo の seed 2 は吹き出しの中の「よろしく！」が消えて空白になった

透過（RGBA）画像は、定型文をプロンプトに入れるだけで4枚とも正しく出ました。ただし Turbo の seed 2 では、吹き出しの文字が丸ごと消えています。

英語のポスター。文字は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）。

スケッチ→写真。両モデルとも、前のマストと見張り台、4つ窓の甲板室と救命ボート、黄色い煙突、上段5個・下段9個の丸窓、船首の四角い窓まで、指示どおりに再現した

両モデルとも、指示文に書かれた細かな構造（丸窓の数まで）を正しく再現しました。従来版はマストの索具や手すりなど細い線の描き込みが多く、Turbo はマストの形がやや単純です。時間は 従来版 3分44秒、Turbo 49秒（約4.6倍） でした。入力画像の CPU での変換は約4秒で、両モデルに同じだけかかります。

ラベルの文字だけを書き換える

次に、Turbo で作った商品写真を入力に、「ラベルの『深煎りブレンド』を『浅煎りシングルオリジン』に書き換え、ほかは変えない」と指示しました。

ラベルの書き換え。袋・豆・マグカップの配置はどちらも保たれたが、文字の差し替えは両方とも失敗。従来版は元の文字のまま、Turbo は「深煎りオルルン」と崩れた。壁や木目のざらつきも両方で強くなった

こちらは、どちらも指示どおりにはなりませんでした。物の配置を保つ力は両モデルともありますが、壁や木目の質感は入力よりざらついています。そして、画像の中の日本語を別の日本語に差し替える編集は、今回の1例では成功していません（英語や短い指示文でも試しましたが、MPS の不具合を避ける前だったため判定に使えず、言語による違いは確かめられていません）。文字を差し替えたいときは、文章から作り直すほうが確実です。生成なら、日本語の文字はかなり正確に描けるからです。

従来版と 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つの道

図7：その使い方は無償で OK？（Qwen Research License の判断フロー）

Qwen に商用ライセンスを申請する：ライセンス第2条bの窓口（model-business@notice.qwencloud.com）に問い合わせます。条件や費用は公開されていません。
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 に確認してください。
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枚あたりの費用で比べてみたいところです。