Qwen-Image-2.1-Turbo vs Qwen-Image-2.1：ベースチェックポイントと高速化版の間で実際に何が変わったのか

同じ7Bの視覚生成コンポーネント。同じ32のシングルストリームDiT層。同じ7つの解像度プリセット、同じ統合された生成・編集サーフェス、同じ非商用ライセンス、そしてそれをロードする同じパイプラインクラス。 Qwen-Image-2.1-TurboとQwen-Image-2.1は、能力で選び分ける2つのモデルではない — Turboチェックポイントはベースモデルのファインチューンであり、リポジトリも自身のメタデータでそう明言している。両者を分けるのは、単一のサンプリング軌跡と、その軌跡がどのように保存されるかだ。一方は40ステップ実行する。もう一方は8ステップで、呼び出し時に別の指定を受け付けない。このペアに関する興味深い点はすべて、その2番目の文に集約されている。

同じ部分から始めてください

違いの前に、共通点を把握しておく価値がある。それは「Turbo」というラベルが示唆するよりも広範で、入れ替えを魅力的にしているものだからだ。

• アーキテクチャ。 Turboカードには、Qwen-Image-2.1と「同じ7Bの視覚生成アーキテクチャ」を使用していると記載されています。プロジェクトはこのコンポーネントを、32のSingle-Stream DiT層にわたる7Bパラメータとして説明しています。Turboリポジトリには、より小規模な、プルーニングされた、あるいはアーキテクチャを変更したバックボーンについての発表は一切ありません。

• 機能。どちらのチェックポイントも、テキストから画像の生成と画像編集を実行するものとして説明されています。Turbo はベースモデルのサーフェスを再記述するのではなく、そのまま引き継いでいます。ベースモデルのカードには、ネイティブの RGBA 透過、最大 10 枚の参照画像、円・ペイント注釈・個別のマスクで指定するローカル編集、そして人物と製品の同一性保持が記載されています。

• 解像度。Turbo のカードには「Qwen-Image-2.1 と同じ解像度プリセットを使用する」と書かれており、その後それらが列挙されています：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。ベースモデルのカードにも同一の表が記載されています。どちらのカードも例に 2048 解像度レベルを使用しています。

• ロードパス。どちらも Diffusers の QwenImage21Pipeline を通じてロードされます。Turbo カードのクイックスタートは、ベースカードのクイックスタートに対してチェックポイント名を変更し、bfloat16 を torch_dtype ではなく dtype と表記したものです。

• 書類関係です。どちらも Qwen-Image-2.1 Research License Agreement の下でライセンスされており、どちらも license: other と license_name: qwen-research を持ち、どちらも重みの隣のリポジトリに LICENSE ファイルが置かれています。

すでにQwen-Image-2.1を組み込み済みなら、移行の対象範囲は本当に小さい。まさにそれだからこそ、期待どおりに振る舞わないただ一つの引数について、じっくり考えてみる価値がある。

スケジュールはコードの外へ出て、チェックポイントへと移りました

ベースモデルでは、ステップ数は自分で設定するものです。Qwen-Image-2.1 のカードにある text-to-image の例、編集の例、RGBA 透明性の例は、いずれも num_inference_steps=40 を渡しており、この数値は通常の Diffusers のやり方で呼び出し時の引数です。そのカードには、このチェックポイントがスケジュールについて一家言あるとはどこにも書かれていません。

Turbo では、スケジュールはチェックポイントのメタデータです。カードには、チェックポイントが「推奨されるサンプリングスケジュールを含んでいるため、スケジューラを手動で設定しなくてもすぐに使用できる」と記載されており、その後サンプリングのセクションで、実際に何を意味するのかが明示されています。「推奨される8ステップのサンプリングスケジュールはチェックポイントとともに保存され、自動的に読み込まれます。num_inference_steps を設定するだけでは、これを上書きしません。」

続いて二つのことがあるが、どちらも正反対の方向に間違えやすい。

第一に、8は上方向に調整できるデフォルトではない。Turbo が12ステップや20ステップでどのようなものになるかを知りたければ、カードには、唯一の方法は呼び出し時に明示的に sigmas 引数を渡すことだと書かれている——そして、他のスケジュールは「このチェックポイントでは評価されていない」と注記して、実験への扉を閉ざす。それは、8ステップ構成こそがベンダーの支持するものであり、それ以外はあなたが一人で足を踏み入れる未踏の領域だと告げているようなものだ。これは異例なほど正直な一文であり、招待ではなく境界線として読むべきだ。

2つ目は、エラーメッセージが一切添えられていない再現の罠です。ベースモデルの例を使い、リポジトリ文字列をTurboチェックポイントに変更し、num_inference_steps=40をそのままにしておくと、コードは実行されます。警告は出ません。保存された8ステップのスケジュールを使って画像を生成しますが、Turboショーケースが表示する出力にはなりません。40は決して読み取られなかったからです。これは、何も壊れているようには見えない失敗モードです — レンダリングは完了し、画像はもっともらしく、気づく唯一の方法は、違いを探しに行く場合だけです。そこには、それと並んで埋もれている2つ目の依存関係があります。チェックポイントには、パイプラインで設定されたサンプリングシグマを理解するDiffusersビルドが必要で、これはPR #14950で追加されましたが、執筆時点では、タグ付きリリースではなくDiffusersのソースツリーにあります。記載されているインストール内容は、CUDA対応のPyTorchビルドに加えて、Diffusersソース、transformers>=5.17.0、accelerate、pillowです。

あなたが踏まなかった32歩の代償を払うのは何か

このカードは2つの仕組みを挙げています。どちらも知っておく価値があります。なぜなら、それらはTurboチェックポイントが、あなたがそれをどのように呼び出すかについて何を前提としているのかを説明しているからです。

• デフォルトではCFG 1。「生成ではデフォルトでCFG=1が使用されます。」分類器フリーガイダンスのスケールが1の場合、モデルはCFGが通常必要とする2回目の無条件パスを実行していません — これは、軌跡が単に切り詰められるのではなく短縮される仕組みの大部分を占めています。またこれは、ベースモデルがガイダンススケールを調整する習慣が引き継がれないことも意味します。ここでは調整すべきものは何もなく、カードには調整の対象となるガイダンスの推奨値も示されていません。

• プレフィックスKVキャッシュ。Turboのモデルカードには「プレフィックスKVキャッシュは、デノイジングの各ステップにわたってテキストと参照画像のコンテキストを再利用する」と記されている。これは高速化されたチェックポイントのための新しい仕組みではなく、既存の機構だ。Qwen-Image-2.1の発表では、プレフィックスKVキャッシュの再利用が、mixed-granularity attention（混合粒度アテンション）と並んで、ベースモデルの4つの主要な改善点の一つとして挙げられている。また、ベースモデル向けのデイゼロ提供統合——プロジェクトのニュース一覧にあるvLLM-OmniとSGLangの項目——では、プレフィックスKVキャッシュがサポート対象の機能として明示的に挙げられている。40ステップのループでは、この再利用は最適化の一つにすぎない。8ステップのループでは、相対的に重要性が増す。キャッシュされた各ステップが総作業量に占める割合が大きくなるからだ。

カードが一切名指ししていないのは、蒸留手法である。ベースモデルのQwen-Image-2.1カードとプロジェクトREADMEはアーキテクチャと能力について説明しており、Turboカードは仕組みについて説明している。8ステップが品質の観点でどれほどの代償を伴うかを推論しようとしても、リポジトリにはそこから推論するための方法が何もない——あるのはスケジュールと一連のショーケース画像だけだ。

歩数は指標ではない

これが比較のこの部分で、正直な答えは比較にならないというものであり、なぜそうなのかを率直に言う価値がある。

• Turboチェックポイントには公表されたスコアがありません。そのカードには、いかなる種類の評価数値も記載されていません。Turbo向けのQwen-Image-Bench結果はなく、ベースチェックポイントとの比較も、ステップ数に関するアブレーションも、品質がどこで頭打ちになるかを示す表もありません。

• ベースチェックポイントのスコアはベンダーによる報告です。 Qwen-Image-2.1ラインで唯一の目立った数値は、ベースモデル自身のQwen-Image-Bench結果であり、ベンダーがベースチェックポイントに対して報告したものです。これはTurboチェックポイントの測定値ではなく、それをTurboに当てはめるべきでもありません。高速化こそがまさにそうした数値を動かすと予想される要因そのものであり、ベンダーはどれほど動くのかを明らかにしていません。

• どちらのカードも、時間やメモリについて報告していない。どちらのチェックポイントにもレイテンシの数値もスループットの数値もメモリフットプリントもなく、どちらのカードも、その例が動作したハードウェアを明記していない。ベースモデルのカードは少なくともメモリ最適化のセクションを記載しているが、Turboのカードはインストール、生成、編集、サンプリング、アスペクト比について記載しているだけで、そこで終わっている。

つまり、ベースチェックポイントよりもTurboを選ぶ根拠は、現時点では測定された結果ではなく、設計意図に関する話だ。同じアーキテクチャと同じ2048解像度レベルで8ステップなら、画像1枚あたりのコストはかなり低くなるはずだ。「かなり」はその文で実際に重要な役割を担っている。それを数値に置き換える唯一の方法は、自分のワークロードで両方のチェックポイントを実行することであり、それはまた、短縮されたトラジェクトリが、あなたが気にかけている特定の画像にどのような影響を与えるのかを知る唯一の方法でもある。

ライセンスを含め、他には何も動かなかった

読者が当然変わったと思っても不思議ではないのに、変わっていなかった2つのこと。

第一はエコシステムだ。2026年9月20日に Qwen-Image-2.1 がリリースされたとき、プロジェクトのニュースリストには、同日に5件の別個のデイゼロ統合が記録されていた。すなわち、PR #14804 による Diffusers サポート、テキストtoイメージおよび編集用のワークフローテンプレートが公開されたネイティブ ComfyUI サポート、ステップワイズ実行と CUDA Graph デコード、FP8 量子化、テンソル並列を備えた vLLM-Omni サポート、Cache-DiT とコンポーネントオフロードを備えた SGLang サポート、そして LightX2V プロジェクトによる高速化である。Qwen-Image-2.1-Turbo を扱う2026年10月9日付の項目には、チェックポイント自体と、Pro および Turbo API が Alibaba Cloud Model Studio 上で稼働中であるという注記が記録されている。Turbo にはデイゼロのフレームワーク一覧がなく、ニュースリスト内のすべてのフレームワーク項目は依然としてベースモデルを参照している。Turbo チェックポイントは、すでに存在していたパイプラインクラスを通じて読み込まれる。その保存済みスケジュールへのサポートが唯一の新しい部分であり、それはタグ付きリリースではなく Diffusers のソースを通じて提供される。

二つ目はライセンスです。Turboは、ベースモデルとまったく同じように、Qwen Research License Agreementを伴っています。高速化に、商用利用の例外や別個のティア、条件の緩和が付いてきたわけではありません——非商用の制限は、ベースモデルに対するのと同じくらい、ファインチューニングにもかかっています。証拠となるのは、リポジトリ自身のメタデータと、重みの隣にあるライセンスファイルです。カードのライセンス欄は、同じ契約を指し示す一文にすぎません。8ステップがあなたにとって重要な理由が、モデルを製品に投入できるほど安価にできるという点にあるのなら、ライセンスはまさにその障害となります。そして、それについて責任を負うべきなのは、このリポジトリではなくベンダーです。

ホスト型エンドポイントと、OrcaRouterがどこに位置づけられるか

OrcaRouter は Qwen-Image-2.1-Turbo も Qwen-Image-2.1 もルーティングしません。どちらも当社のカタログにはなく、ここにあるものはどちらかを提供する申し出ではありません。それらを利用したい場合の経路は、ベンダー自身のホスト型 API、いくつかのサードパーティプラットフォーム、または Turbo チェックポイントの保存済みサンプリングスケジュールを扱えるほど新しい Diffusers ビルドで動かす重みです。

この比較においてOrcaRouterが関わってくるのは、セルフホスティングしたチェックポイントが正解ではなくなる瞬間に、あなたが行う差し替えです。自分で動かすオープンウェイトモデルからホスト型の画像エンドポイントへ移ることは、単なるモデルの変更ではなく、障害モードの変更です。ローカルプロセスの失敗は目に見える形で起きますが、ホスト型エンドポイントの失敗は、どのプロバイダーが応答したか、そしてそのうちの一つがリクエストの途中で劣化したときに何が起きるかに依存します。OrcaRouterは200以上のモデルを単一のOpenAI互換エンドポイントの背後に置き、プロバイダーの定価をマークアップなしでそのまま通しますそのため、ベンダーの値下げは再価格設定の処理を待たずに、当日中にこちら側へ反映されます。さらに、プロバイダー間の自動フェイルオーバー、リクエストが使用できるモデルとプロバイダーを指定するためのルーティングDSL、そして複数のモデルを1回の呼び出しに組み合わせるモデルフュージョンを追加します。私たちがフロントを提供している画像モデルは、OpenAIのGPT-Imageファミリー、fastおよびultraバリアントを含むGoogleのImagen 4の各ティア、GoogleのGemini画像プレビューエンドポイント、そしてxAIのGrok Imagine画像エンドポイントです。

具体的に言うと、2つのQwenチェックポイントのどちらを選ぶかというのはセルフホスティングの判断であり、一方を他方より好む理由はスケジュールの挙動とステップ数です。実際に必要なのが、GPUを自分で所有せずに本番環境で画像を生成することなら、それは私たちが支援できる立場にある判断であり、別の判断です。

短いバージョン

• Qwen-Image-2.1を選んでくださいサンプリング挙動がドキュメントと一致するチェックポイントを求める場合、ステップ数を変えたりスケジュールを試したりする必要がある場合、またはDiffusers、ComfyUI、vLLM-Omni、SGLang、LightX2Vにわたるday-zeroサポートとともに登場したリリースを求める場合は、

• 同じアーキテクチャと同じ機能を、大幅に短い軌道で手に入れたいなら Qwen-Image-2.1-Turbo を選んでください。ただし、8ステップを固定として扱い、それを読み込むために Diffusers をソースからインストールすることをいとわない場合に限ります。

• どちらの場合も同じライセンスになることを想定してください。また、高速化されたチェックポイントについて、ベースと比較できるような公開された品質数値は期待できません。ステップ削減は実際にあり、文書化されています。それが画像品質をどれだけ損なうかはどこにも文書化されておらず、2つのカードをどれだけ読んでも分かりません — その答えは、自分のハードウェア上で、自分のプロンプトに対してのみ存在します。