FLUX 3 Image Klein 対 FLUX 3 Image Klein Pup：自らのプロンプトライターと対決するモデル

リポジトリの名前は、実際には存在しない比較を連想させる。FLUX 3 Image Klein と FLUX 3 Image Klein Pup は、このブログの他のすべての「vs」ページが、異なる強みを持つ2つの生成モデルを組み合わせて比較しているのと同じように、同じファミリーに属する2つのモデルのように見える。しかし、そうではない。FLUX 3 Image Klein は、2026年10月15日にリリースされた5.6Bの画像モデルだ。FLUX 3 Image Klein Pup は、モデルカードで「Prompt Upsampler」と題されている9Bの言語モデルであり、その唯一の役割は、短いプロンプトを、画像モデルが受け取るように学習された長く詳細なキャプションに書き換えることだ。

つまり本当の問いは、どちらが優れているかではない。二つ目が任意なのかどうかだ。Black Forest Labs は任意ではないと言う。モデルカードには、Klein は「前にプロンプト・アップサンプラーを置かずに動かすことは想定されていない」と明記され、入力どおりに送った短いプロンプトでは一般的な出力しか得られないとある。検討に値するのはこの主張だ。なぜなら、それを受け入れるかどうかで、メモリ予算、レイテンシ、ライセンス上の義務、そして——ある特定のケースでは——編集の精度が変わるからだ。

その2つがそれぞれ実際に何なのか

この分割は、その命名が示すよりもすっきりしている。一方のモデルには視覚があり、もう一方にはない。そして、ピクセルに触れるのは常にそのうちの一方だけだ。

• 役割 — Klein は画像を生成・編集し、Pup はテキストを出力し、決して何もレンダリングしない

• パラメータ — ジェネレーターが5.6B、アップサンプラーが9Bなので、ヘルパーの方が大きなモデルです

• 系譜 — Klein は FLUX 3 系譜の画像モデルです。Pup は Qwen/Qwen3.5-9B のフルファインチューンであり、Qwen/Qwen3.5-9B 自体は Qwen3.5-9B-Base に由来します。

• ディスク上の重み — Klein は BF16 で 11.2 GB、FP8 で 5.6 GB、Pup の safetensors は BF16 で 18.8 GB

• ライセンス — KleinにはFLUX Kommunity License（$5Mの収益ライン付き）、PupにはApache 2.0

• 入力 — Klein はテキスト、参照画像、バウンディングボックスを受け取ります。Pup は同じリクエストに最大 10 枚の参照画像を加えたものを受け取り、1 つのプロンプトを返します

• 出力 — ピクセルと英語テキストの比較

最後の行は、多くの人が見落とすものです。Pup の出力言語は常に英語で、入力リクエストが別の言語であっても変わりません。パイプラインがレビュー用にプロンプトをログに記録する場合、レビュー担当者が目にするプロンプトは、ユーザーが入力したプロンプトではありません。

8 GB という数値は、デフォルトのパイプラインでは保持されません

Kleinに関する主要なハードウェア上の主張は、INT8ビルドがわずか8 GBのVRAMを搭載したRTXカードで動作するというものだ。その主張は生成器に関するものであり、それ単体の条件においては成り立つように見える——量子化チェックポイントはそのために構築されており、併せて公開された計測時間はNVIDIAによって測定されたものである。

次に、デフォルトのパイプラインを追加します。Pup の重みは、ランタイムのオーバーヘッドを除いても BF16 で 18.8 GB あります。18.8 GB の重みを 8 GB の VRAM に収めることはできません。この2つの数字は別々のものを表しており、リリース資料では両者がかなり近くに並んでいるため、読者は全体が旧型カードで動くと合理的に結論づけてしまいかねません。しかし、BFL がモデルに期待している構成では、それは動きません。

正直な出口は3つあり、それぞれ異なる代償を伴います：

• アップサンプラーを量子化する — Pup には、別個のビジョンプロジェクター付きの Q8_0、Q5_K_M、IQ4_XS、IQ3_S 各バリアント向けにコミュニティ製 GGUF ビルドが存在し、プロンプト品質をいくらか犠牲にする代わりにヘルパーを大幅に小さくできます

• アップサンプラーは別の場所で実行する — これはテキストモデルなので、生成器とGPUを共有する必要はなく、必要なのはネットワークを1ホップするだけです

• --no-pup でスキップ — 無料で即時、そして BFL が推奨しないオプション

メモリ計算は、この組み合わせを理解するうえで最も役立つ単一の事柄だ。これはある種の不満の説明にもなる。誰かがKleinは遅い、あるいは収まらないと報告するとき、実際に報告しているのは、簡素化版向けにサイズ設定されたハードウェア上で、文書化されたパイプラインを実行したということなのだ。

Pupがプロンプトに施すこと

それは拡張されます。「犬を連れて散歩する男性、午後の日差し」のようなリクエストが、被写体・舞台・ライティング・カメラ・構図を網羅するシーン全体のキャプションになるのです。モデルカードには、中程度の設定でおよそ200語の長いキャプションが出力されると説明されています。そして画像モデルは、あなたの一文ではなく、そのキャプションを条件として生成を行います。

これは実際の能力であり、ギミックではありません。拡散型画像モデルはプロンプトの具体性に敏感で、5語のプロンプトでは構図に関するほとんどすべての決定がモデルの事前分布に委ねられます。アップサンプラーはこれらの決定を明示的かつ一貫して行うため、デフォルトのパイプラインからの出力は、同じチェックポイントにそのままの文を入力した場合の出力よりも意図的に見えるのです。

また、それは制御の喪失でもあり、しかもその喪失は静かに起きる。あなたの文は注釈を付けられるのではなく、置き換えられる。アップサンプラーが午後の光をゴールデンアワーと判断し、犬をボーダーコリーと判断した場合、生成器には、あなたがそう意図していなかったことを知る術がない。探索的な作業にとっては、それは利点だ。ショットリストにとっては、それはあなたが求めていない変数だ。

4つのモード、そしてモードがプロンプトよりも重要である理由

Pup は単一の振る舞いを持つ単一のモデルではありません。タスクに基づいてシステムプロンプトを選択し、その種類は4つあります。テキスト→画像、画像→画像、バウンディングボックス付きテキスト→画像、バウンディングボックス付き画像→画像です。誤ったモードでは、間違ったタスク向けのよく書かれたプロンプトが生成されます。これはモデルの品質問題に見えますが、そうではない失敗です。

サンプリング設定もモードによって異なり、その違いは見た目だけのものではない。デコードは temperature 0 の貪欲法で、新規トークンは最大3,584、thinking は無効。presence penalty は text-to-image では1.5、編集では0。この0は意図的だ。繰り返しペナルティはモデルに新しい素材を導入するよう促すが、編集指示を忠実に言い直すことが仕事のときには、まさに望まないことだ。参照画像も、何枚提供するかによってリサイズのされ方が異なる — 1枚なら約1メガピクセル、2枚なら724²、3枚以上なら512² — そのため10枚参照のジョブは、1枚参照のジョブよりずっと小さい画像で条件付けされている。

ライセンスは真っ二つに分かれている

これはほとんど注目されていない部分ですが、おそらく注目されるべきところです。パイプラインの2つの部分は異なるライセンスの下にあります。KleinはFLUX Kommunity Licenseです。年間収益500万ドル未満なら商用利用は無料で、それを超える場合は有償ライセンスとなります。PupはApache 2.0で、収益条件はまったくありません。

つまり、閾値を超える企業はプロンプト・アップサンプラーを自由に使えますが、それがプロンプトを渡す生成器を使うには依然としてライセンスが必要です。また、閾値を下回る企業がプロンプト側をファインチューニングしたい場合、画像側をファインチューニングしたい場合よりもはるかに裁量が大きくなります。出荷を計画しているなら、「Kleinスタック」を一つのものとして扱うのではなく、二つのライセンスを別々に読んでください。見落としやすいのは、寛容な側の半分です。

オフにすると実際に何が変わるのか

Pup をオフにするのはフラグ1つだけですが、その影響はタスクによって非対称です。

• テキストから画像生成 — 最大の後退。短いプロンプトは汎用的な結果になりがちで、これはまさにBFLが警告している失敗であり、プロンプトが短ければ短いほどその差は広がる

• マルチリファレンス — 「この3人を同じ部屋に配置して」という指示を、3つの参照すべてを反映した記述に変えるのがアップサンプラーです。これがないと、参照への忠実度が明らかに緩くなります。

バウンディングボックスレイアウト — このモードは空間的な意図を、それを保持するキャプションへ変換するために存在するため、これを削除すると、その負担は再びあなたの言葉遣いに戻ります

• 精密な編集 — 最も明確でないケースであり、オフにすることで役立つ場合がある

最後の箇条書きは直感に反するものですが、ゼロ・プレゼンス・ペナルティと同じところから来ています。編集指示は通常、狭い範囲にとどまります。このオブジェクトを変更する、この要素を移動する、これを削除する、といった具合です。アップサンプラーの役割は拡張することなので、指示そのものだけでなく、指示の周囲のシーンも拡張します。編集が本当に局所的である場合、その周囲の拡張はせいぜいノイズです。フレーム内の何かと矛盾する場合、それはノイズより悪いものになります。

局所的な編集——1つのオブジェクトを変更する、要素を境界のある領域内へ移動する、フレームの残りをそのまま保つ——でKleinを動かした私たち自身の経験では、モデルが最も説得力を持つのはまさにこの狭いモードです。これはアップサンプラーの問いを和らげるどころか、より鋭くします。生成器が最も強いタスクは、ヘルパーの拡張が最も歓迎されないタスクでもあるからです。判断する前に、両方の設定を自分の編集プロンプトで試してください。これは、ベンダーの一律の助言とあなたの具体的なワークロードが正当に食い違うケースです。

実際の運用における決定

ベンダーのAPIを呼び出していて、何もダウンロードしていないなら、この話の大半は意味をなしません。ホスト型エンドポイントはサーバー側で独自のプロンプト・アップサンプリングとピクセル復元を適用するため、意識するかどうかにかかわらず、拡張プロンプトの挙動はすでに得られています。この選択が現実になるのは、重みを取得したときだけです。

そうする場合の判断は、おおよそ次のとおりです。プロンプトが短い場合、作業が探索的な場合、または編集ではなく生成を行っている場合は、Pup を維持してください。グラフィックカードが小さい場合、編集が狭く Literal な場合、またはプロンプトがすでに長く具体的で、拡張しても主に創作が加わるだけの場合は、Pup を外すか、量子化ビルドを実行してください。両方を望み、パイプライン全体を1台のデバイスに収めることと引き換えに、プロンプト品質の多少の低下を受け入れられるなら、Pup を量子化してください。

安く試す際の実用的な注意点として、二つの半分は独立して失敗し、ルーティング層は本番経路を単一のエンドポイントに賭けるのを避ける通常の方法です。OrcaRouter は 200 以上のモデルに対して、0% のマークアップ — プロバイダーの定価を変更せずにそのまま適用 — で単一の OpenAI 互換 API を提供し、プロバイダー間の自動フェイルオーバーも行うため、劣化したエンドポイントが失敗したジョブになることはありません。ただし、これは Klein 自体には役立ちません。Klein は当社の 210 モデルのカタログにはなく、当社が提供しているものでもありません。このパイプラインでは、重みとベンダー API が経路であり、ルーティングの議論はその周囲に置くモデルに対して重要です。

何が答えを変えるだろうか

公表されたアブレーション。同じプロンプトでPupありとなしのKleinを並べ、ラボ以外の誰かが採点した比較を公開した者はまだいない。そして、そのたった一つ欠けている表こそが、これを判断の分かれる問題にとどめている。それが存在するまでは、弁護できる立場は地味なものだ。すなわち、アップサンプラーは設計どおりシステムの一部であり、8 GBという主張はそれをカバーしておらず、デフォルトを合理的に上書きしてよい唯一のワークロードは、このモデルが最も強いワークロードである。