Flux 2 Klein 純粋Cベースの推論

 (github.com/antirez)
1 ポイント 投稿者 GN⁺ 2026-01-19 | 1件のコメント | WhatsAppで共有
  • FLUX.2-klein-4B モデルを用いて、テキストまたは画像を入力として画像を生成する純粋C実装
  • 外部依存なしで動作し、オプションでBLAS または Metal アクセラレーションにより最大30倍の高速化が可能
  • Qwen3-4B テキストエンコーダを内蔵しており、別途埋め込み計算を行う必要がない
  • テキストから画像および画像から画像への変換の両方をサポートし、コマンドラインインターフェースとCライブラリAPIを提供
  • Python ランタイムや PyTorch なしでも実行可能で、軽量な推論環境とオープンソースAIへのアクセス拡大という点で意義がある

プロジェクト概要

  • FLUX.2-klein-4Bは Black Forest Labs の画像生成モデルで、テキストプロンプトや既存画像を入力として新しい画像を生成
  • コード全体が標準Cライブラリのみで記述されており、MPS(Apple Metal) および BLAS(OpenBLAS) アクセラレーションをオプションでサポート
  • モデルは HuggingFace から約16GBでダウンロード可能で、構成要素はVAE(300MB)、Transformer(4GB)、Qwen3-4B エンコーダ(8GB)、Tokenizerで構成

主な機能

  • Zero dependencies: 外部ライブラリなしで単独実行可能
    • BLAS 使用時は約30倍高速化し、macOS では Apple Accelerate、Linux では OpenBLAS を利用可能
  • Metal GPU acceleration: Apple Silicon 環境で自動有効化
  • Text-to-image: テキストプロンプトから画像を生成
  • Image-to-image: 既存画像をプロンプトに応じて変換
  • Integrated text encoder: Qwen3-4B エンコーダを内蔵し、外部埋め込みは不要
  • Memory efficient: エンコード後に自動でエンコーダのメモリを解放し、約8GB削減

使用例

  • テキストから画像生成 
    ./flux -d flux-klein-model -p "A fluffy orange cat sitting on a windowsill" -o cat.png
  • 画像変換 
    ./flux -d flux-klein-model -i photo.png -o painting.png -p "oil painting style" -t 0.7
    • -t の値は変換強度を制御し、0.0 は元画像を維持、1.0 は完全に再生成

モデル構造と性能

  • Transformer: 5つのダブルブロックと20のシングルブロック、3072 隠れ次元、24 Attention Head
  • VAE: AutoencoderKL、128 潜在チャネル、8倍の空間圧縮
  • Text Encoder: Qwen3-4B、36層、2560 隠れ次元
  • 推論ステップ: 4ステップのサンプリングで高品質な結果を生成
  • メモリ要件
    • テキストエンコード: 約8GB
    • Diffusion: 約8GB
    • 最大ピーク: 16GB（エンコーダ解放前）
  • 性能ベンチマーク (Apple M3 Max, 128GB RAM)
    • 512×512: MPS 49.6秒、BLAS 51.9秒、PyTorch MPS 5.4秒
    • 256×256: MPS 32.4秒、BLAS 29.7秒、PyTorch MPS 3.0秒
    • 64×64: MPS 25.0秒、BLAS 23.5秒、PyTorch MPS 2.2秒
    • 純粋Cバックエンドは非常に遅く、テスト用途にのみ適している

ビルドと実行

  • バックエンド選択
    • make mps: macOS Apple Silicon（最速）
    • make blas: Intel Mac または Linux（OpenBLAS が必要）
    • make generic: 純粋C、依存性なし（低速）
  • モデルのダウンロード 
    pip install huggingface_hub
python download_model.py
  • 出力解像度は最大1024×1024、最小64×64、16の倍数を推奨

Cライブラリ API

  • モデルの読み込みと解放
    • flux_load_dir(path) / flux_free(ctx)
  • 画像生成と変換
    • flux_generate(ctx, prompt, params)
    • flux_img2img(ctx, prompt, input, params)
  • 画像入出力
    • flux_image_load(path) / flux_image_save(img, path)
  • ユーティリティ
    • flux_set_seed(seed) による再現性の確保
    • flux_get_error() でエラーメッセージを確認
    • flux_release_text_encoder(ctx) によりメモリを手動解放可能

ライセンスおよびその他の情報

  • MIT ライセンスで公開
  • リポジトリの言語構成: C 93.9%、Objective-C 3.5%、Makefile 1.7%、Python 0.9%
  • スター446件、フォーク20件でコミュニティから高い関心を集めている

関連記事

1件のコメント

 
GN⁺ 2026-01-19
Hacker Newsのコメント

  • このプロジェクトが可能だった理由は、Opus に IMPLEMENTATION_NOTES.md ファイルを必ず使うよう指示したからだとのこと
    開発中に見つかったすべての事項をこのファイルに蓄積し、常に最新の状態に保ち、コンテキスト圧縮後にすぐ処理するよう明記していた
    このやり方のおかげで、大規模なコーディング作業を効率よく進めつつ、流れを見失わずに済んだという
    詳細は GitHub の IMPLEMENTATION_NOTES.md ファイルを参照

    • すばらしい。継続的に更新される 仕様書(spec) が核心だ
      私も vibe-speccing の記事でこのアプローチを扱った
      また、仕様書の末尾に「実験ログ」を置いて、予想外の変化が起きるたびに記録するようにするのも有用だった
    • Steve Yegge の Beads を使えば、Markdown ファイルの不要な部分を減らせる
      ところでベンチマークは回したのだろうか。Python スタックが C ベースの推論ツールより速いのか遅いのかも興味深い
    • README で触れられていた他の教訓についても、文章としてまとめる予定があるのか気になる
      長年のファンとして、こうしたツールを活用するあなたの 視点 を聞いてみたい
    • 使ったプロンプトログや実装ノート以外の資料も共有できるのか気になる
      あなたの 作業プロセス を学びたい
    • Claude や他の LLM でも、作業定義、実装ノートの追加、サブタスクと依存関係の管理 ができるソリューションがある
      私は Beads を使っているが、特に大規模プロジェクトでは結果の質が確実に良くなる

  • README にあった動機を興味深く読んだ
    私も同じように PROMPTS.md ファイルを含めようと試している
    共有や教育目的なら、熟練した開発者がどんなアプローチを取るのかを示すのは役に立つ
    Claude hook を使えば、これを 決定論的に維持 できる。AGENTS.md には読み取り専用と明記していた
    LLM 間を切り替える際にも、作業の背景を伝えるのに役立った

    • 今回はプロンプトの代わりに仕様書を書いたが、その後もモデルを何時間も調整する必要があった
      結局のところ、プロンプトはこうした相互作用の総和なので、意味のある形で再構成するのは非常に難しい

  • LLM を使って別の言語へ トランスパイル する実験について、結果と過程がどうだったのか気になる
    私も最近、プロジェクトのボトルネック部分を Claude に「Rust で書き直して」と頼んだところ、大きく高速化した
    ただし、成果物は実験室の外で信頼できるレベルではなかった

    • ケースによる。今回は Flux の Black Forest Labs が提供した 参照コード だけを使って作業した
      重要なのは、エージェントがフィードバックを通じて進捗を理解し、参照実装と比較しながらデバッグできることだ
      すべてのコードは、私が望む結果を明示した 実装ヒント に基づいて書かれた
      今日、誰かが私の HNSW ベクターセット実装を Swift に移植 してくれたが、ライセンスが同じなのでうれしい
    • 私は「現在のコード変更を 論理エラー の観点から監査せよ」というプロンプト群を使っている
      Claude が生成したコードを GPT-5.x-Codex で再チェックしている
      Opus 4.5 でもなお off-by-one のようなミスをするので、別のモデルを ピアレビュー担当 として使うと効果的だ
      私の検証手順は lint → test → 別モデル → 自分 の順で進めている

  • 元の FLUX.2 [klein] モデルと Python コードは、わずか 3 日前に公開された
    関連する議論は こちら を参照

    • Opus なしだと antirez にどれくらい時間がかかったのか気になる

  • C で書かれているからといって、必ずしも C レベルの性能 が出るわけではない
    ベンチマークを見ると PyTorch より 8 倍遅い。LLM がこのレベルの高性能コードを生成するにはまだ限界がある

    • PyTorch 版は GPU(Metal Performance Shaders) を使っているが、C 版は単一の CPU コアしか使っていない
      遅い理由は LLM のコード品質ではなく、ハードウェアの違い だ
      実際の中核演算は PyTorch と同じカーネルライブラリを呼び出している
    • 私は CUDA カーネル と 8bit オプティマイザを書いたことがあるが、LLM は速度最適化がかなり得意だ
      複数回の試行とベンチマークを繰り返して素早く改善し、torch の強力なベースラインを上回ったこともある

  • Salvatore が ML 分野で初の OSS プロジェクトを進めたと認識しているが、関連する 背景知識 をどう身につけたのか気になる
    Claude がドメイン専門性を補うのに役立ったのかも知りたい

    • 以前から AI は楽しんで扱っていた。たとえば gguf-tools を作ったことがある
      イタリア語で進める AI YouTube チャンネル も運営しており、論文を読んで解説している
      2003 年に最初のニューラルネットワーク実装を作り、その後も PyTorch や C で小型 GPT モデルを継続的に試してきた
      Redis Vector Sets の作業を通じて、さまざまな埋め込みモデルを扱ってきた
      Claude のおかげで実装速度は上がったが、基本概念はすでに理解していた
      プログラミングの背景しかなく AI 経験がほとんどない場合でも可能だろうが、より多くの 往復フィードバック が必要になりそうだ

  • 先月、似た実験として Qwen 3 Omni を llama.cpp に移植した
    GGUF 変換、量子化、入出力モダリティを 1 週間で実装したが、PR は却下された
    関連リンク: PR #18404, Hugging Face モデル

    • AI が書いた GGML カーネルが 未最適化 だからという理由で却下されたのは奇妙だ
      手動でカーネルを書く人がモデルをうまく誘導すれば、すばらしい結果を出せる
      この流れが続けば、より高速で優れた llama.cpp フォーク が登場するだろう

  • OpenBLAS と MPS がほぼ同じ速度を出している点が興味深い
    README には GPU を使うのは MPS だけだと書かれている

  • Claude に同じ作業をさせた場合、MIT ライセンスで自分の名前を付けてもよいのか気になる
    参考までに Flux2 は Apache License を採用している
    大きな違いはないが、こうした ライセンスの細部 は気になる

    • 参照コードは推論パイプラインの設定しか示しておらず、実際の 中核実装(カーネル、トランスフォーマーなど) は含まれていない
    • Claude に C/C++ で推論を再実装するよう指示し、MIT ライセンスを付けられるなら本当にすごい
      ただし、実際に 正常に動作 してこそ意味がある

  • 私は C に詳しくなく、普段は SQL ベースの分析をしているのだが、このコードが プロダクション品質 なのか気になる
    LLM が作ったコードは保守しにくいという話をよく聞く

    • コードをざっと見た感じ、アマチュアレベルではなく、エンタープライズ級ではないにせよ、かなり良い
    • そういう評価は古い。Opus 4.5 と CLAUDE.md の明確なルールを組み合わせれば、かなり 寛容で整ったコード が出てくる
      データサイエンス作業では性能にばらつきがあるが、問題定義と入力情報を明確に与えれば良い結果が得られる