FLUX.3 Image Klein が開放ウェイトとして公開、初日から Diffusers に対応：レイアウト枠制御と開発者の取捨選択
Hugging Face が 2026 年 10 月 15 日に公開したブログによると、Black Forest Labs の FLUX.3 Image Klein は 2 つのオープンチェックポイントとして公開され、初日から Diffusers で利用可能になった。同モデルは同一の重みでテキストからの画像生成、複数の参照画像からの画像生成、バウンディングボックスによるレイアウト制御をサポートする。蒸留チェックポイントは H100 上で約 2 秒で 1024×1024 画像を生成し、NVFP4 と FP8 の単一ファイル重み、および LoRA 学習スクリプトも提供される。
主な変更
Hugging Face の 2026 年 10 月 15 日付の公式ブログによると、Black Forest Labs は FLUX.3 Image Klein を発表し、初日から Diffusers で動作するとしている。ブログは 2 つのオープンチェックポイントを挙げている。black-forest-labs/flux-3-image-klein はタイムステップ蒸留版で、デフォルトは 16 ステップ、分類器不要ガイダンス（CFG）を使用しない。flux-3-image-klein-base はベースモデルで、デフォルトは 50 ステップでガイダンスを併用し、ブログはファインチューニングに適するとしている。機能的には、同一モデルがテキストからの画像生成、1 枚または複数の参照画像を渡す画像生成、プロンプトに JSON の領域リストを書くレイアウト制御をカバーする。領域は id、bbox、desc フィールドを使用し、座標は [y_min, x_min, y_max, x_max] と書き、0 から 1000 の正規化スケール上で、ブログは同じ枠が任意の画像サイズに適用されるとしている。編集シナリオでは領域を src_bbox と tgt_bbox で記述し、内容が参照画像のどこから来て出力のどこへ移動するかを表す。ブログは distilled チェックポイントが H100 上で約 1.93 秒で 1024×1024 画像を 1 枚生成し、1024×1024 の参照画像 1 枚で所要時間が約 2 倍の 3.87 秒になるとしている。これは transformer 呼び出しごとに 4096 個の参照トークンが追加されるためである。ブログはさらに NVFP4 と行単位 FP8 の単一ファイル重み、DreamBooth LoRA 学習スクリプト、Modular Diffusers のモジュール化パイプラインの説明も示している。テキストエンコーダは Qwen3-VL である。上記の性能と機能はすべてブログ筆者の記述であり、本誌は独立に再現していない。
開発者への影響
自前で推論を構築するチームにとって最も注目すべき点は、単一モデルがさらに 1 つ増えたことではなく、レイアウト制御が「位置」をプログラマブルな入力に変えたことである。領域座標は正規化スケールであり、同じフロントエンドのアノテーションを異なる出力解像度にそのまま再利用できる。これは EC 画像、ポスターのレイアウト、素材の二次編集など、構図を固定する必要があるパイプラインにとって、単なるプロンプトのテクニックではなく構造的な変化である。次に VRAM の階層が明確である。ブログが示すピーク割り当てでは、bf16 はロード後約 18.8 GiB、推論後約 20.7 GiB、FP8 と NVFP4 はそれぞれ約 14.35 GiB と 13.4 GiB に下がる。これはコンシューマー向けカードとデータセンター向けカードの役割分担を決める。第三にコストモデルが参照画像によって変わる。1024×1024 の参照画像 1 枚ごとに transformer 呼び出しあたり 4096 トークンが増えるため、複数参照の編集では遅延と VRAM 使用量が参照数におおむね線形に増加し、容量計画をテキストからの画像生成の数値で外挿することはできない。第四にエンジニアリングインターフェースの面では、モデルは Modular Diffusers の形式で公開され、ブログはテキストエンコーダを切り出して「一度符号化、複数回生成」する方法や、デノイズループにカスタムステップを挿入する方法を実演している。これによりキャッシュ、計測、品質監視をパイプライン内部に置くことができ、外側を包むブラックボックス呼び出しに留まらない。ただしこれらの利点が適用される前提は自己ホスト型の重みであり、ブログはホスト型 API の可用性、レート制限、課金方法について何も述べていない。したがってレイアウト制御を本番に組み込む前に、チームは重みの配布、VRAM、同時実行のスケジューリングを自ら負担する必要がある。
導入と評価の提案
以下はソースに基づく判断と提案であり、実証済みの事実ではない。第一の決定はチェックポイント選択に関する。ブログは蒸留版はデフォルト 16 ステップで CFG を使わず、ベース版はデフォルト 50 ステップでガイダンスを併用し、ベース版がファインチューニングに適するとしている。バッチ出図が中心でスタイル一貫性の要求が一般的なら、まず蒸留版で遅延を抑えるとよい。LoRA ファインチューニングが必要、またはガイダンス強度に敏感な場合は、ベース版の重みから始めるべきである。前提条件は学習データと VRAM の予算である。ブログの例では 1024 解像度、batch size 1、rank 16 で 1500 ステップ学習し、VRAM を下げるためにグラディエントチェックポイント、潜在変数のキャッシュ、8bit Adam の併用を勧めている。測定可能な評価基準は、固定プロンプト集合で蒸留版 16 ステップとベース版 50 ステップの人手によるブラインド評価での可用率の差、および同一バッチでの 1 枚あたりのエンドツーエンド所要時間である。第二の決定は量子化形式に関する。ブログは fp8r が計算能力 8.9 以上（Ada、Hopper、Blackwell）で高速カーネルを使え、それ以外の GPU では重みを毎ステップ逆量子化するため VRAM はより低いが高速化はないとしている。NVFP4 は Blackwell が必要で、flashinfer-python と flashinfer-cubin のバージョン一致が求められる。したがって量子化は無条件の高速化ではなく、選択はカードの型番に依存する。Ada/Hopper では VRAM 削減のために fp8r を優先し、Blackwell ではさらに NVFP4 を検討し、旧カードでは量子化で主に得られるのは「載る」ことであって「速い」ことではない。測定基準は同解像度・同プロンプトでの 1 枚あたりの遅延、および逆量子化による知覚可能な画質劣化が生じるかどうかである。第三の決定はレイアウト制御を組み込む価値があるかに関する。ブログは参照画像と出力が同じ (h, w) 座標を共有し、同じ位置がモデルにとって正確な意味を持つとしている。これが枠編集が機能する基礎である。しかしこの仕組みは同時に、参照画像が増えるほど呼び出しあたりのトークンが増えることも意味する。まず固定の評価セットで、レイアウト指示の枠内への落点の一致率と、シーン全体の不変部分のずれの程度を測定し、そのうえでスケッチのアノテーションを製品フローに書き込むか決めるとよい。期待に合わなければ、純粋なテキストからの画像生成と後処理レイアウトに戻す方がコスト構造は予測しやすい。
制限と未確認事項
重要な制限：今回のカタログ確認時点で、FLUX.3 Image Klein および flux-3-image-klein-base というこのバージョンは KimiSeek の現在の掲載モデルカタログには存在せず、本誌は同プラットフォームでのホスト計画も把握していない。本記事の重み、スクリプト、性能に関するすべての記述は Hugging Face ブログの原文に由来し、ソース側の説明であって本誌が独立に再現したものではない。ブログが公表した遅延と VRAM の数値は、単一の H100 80GB、offloading なし、デフォルトのアテンションバックエンドでの 3 つのワークフローの 3 回平均によるものであり、他の GPU、他のアテンションバックエンド、または CPU offload を有効にした場合はそのまま適用できない。ブログも offloading シナリオをベンチマークしていないと明言している。参照画像数が遅延に与える影響は参照 1 枚の実測のみが示されており、複数参照、超高解像度、長いバッチでの挙動は自ら負荷試験する必要がある。重みが利用可能であることは寛容なライセンスを意味しない。ブログは全体を通じて「オープンチェックポイント」という表現を使っており、この記事では具体的なライセンス条項や商用条件を説明していない。チームは重みを商用製品に使う前にモデルカードとライセンス原文を確認すべきである。LoRA 学習の例は単一データセット・単一スタイルのデモにすぎず、収束ステップ数、rank、オプティマイザの組み合わせが自前データに移行できる保証はない。さらにブログは、パイプラインが呼び出しごとにプロンプトを 1 つだけ受け付け、プロンプトは 80 トークンの倍数にパディングされてアテンションで注目されるとしている。バッチ処理とプロンプト連結の書き方はその規約に合わせて改造する必要がある。価格とホスト可用性は変わり得るため、今後その API 提供の価格を注視する場合はサービス提供者の価格ページを基準とされたい。
元の報道の図版
