Inferensi Flux 2 Klein berbasis C murni

 (github.com/antirez)
1 poin oleh GN⁺ 2026-01-19 | 1 komentar | Bagikan ke WhatsApp
  • Implementasi C murni untuk menghasilkan gambar dari input teks atau gambar menggunakan model FLUX.2-klein-4B
  • Berjalan tanpa dependensi eksternal, dengan opsi akselerasi BLAS atau Metal yang dapat meningkatkan kecepatan hingga 30x
  • Encoder teks Qwen3-4B sudah terintegrasi sehingga tidak memerlukan proses perhitungan embedding terpisah
  • Mendukung text-to-image dan image-to-image, serta menyediakan antarmuka command line dan API library C
  • Dapat dijalankan tanpa Python runtime atau PyTorch, sehingga bermakna bagi lingkungan inferensi ringan dan perluasan aksesibilitas AI open source

Gambaran proyek

  • FLUX.2-klein-4B adalah model pembuat gambar dari Black Forest Labs yang menerima prompt teks atau gambar yang sudah ada untuk menghasilkan gambar baru
  • Seluruh kode ditulis hanya dengan standard C library, dengan dukungan akselerasi MPS (Apple Metal) dan BLAS (OpenBLAS) secara opsional
  • Model dapat diunduh dari HuggingFace dengan ukuran sekitar 16GB, dan komponennya terdiri dari VAE (300MB), Transformer (4GB), encoder Qwen3-4B (8GB), dan Tokenizer

Fitur utama

  • Zero dependencies: dapat dijalankan secara mandiri tanpa library eksternal
    • Saat menggunakan BLAS, kecepatannya bisa meningkat sekitar 30x, dengan Apple Accelerate di macOS dan OpenBLAS di Linux
  • Metal GPU acceleration: aktif otomatis di lingkungan Apple Silicon
  • Text-to-image: menghasilkan gambar dari prompt teks
  • Image-to-image: mengubah gambar yang sudah ada sesuai prompt
  • Integrated text encoder: encoder Qwen3-4B terintegrasi, tanpa embedding eksternal
  • Memory efficient: memori encoder dibebaskan otomatis setelah encoding, menghemat sekitar 8GB

Contoh penggunaan

  • Menghasilkan gambar dari teks 
    ./flux -d flux-klein-model -p "A fluffy orange cat sitting on a windowsill" -o cat.png
  • Transformasi gambar 
    ./flux -d flux-klein-model -i photo.png -o painting.png -p "oil painting style" -t 0.7
    • Nilai -t mengontrol kekuatan transformasi; 0.0 mempertahankan gambar asli, 1.0 membuat ulang sepenuhnya

Struktur model dan performa

  • Transformer: 5 double block dan 20 single block, dimensi hidden 3072, 24 attention head
  • VAE: AutoencoderKL, 128 latent channel, kompresi spasial 8x
  • Text Encoder: Qwen3-4B, 36 layer, dimensi hidden 2560
  • Tahap inferensi: sampling 4 langkah untuk menghasilkan output berkualitas tinggi
  • Kebutuhan memori
    • Encoding teks: sekitar 8GB
    • Diffusion: sekitar 8GB
    • Puncak maksimum: 16GB (sebelum encoder dilepas)
  • Benchmark performa (Apple M3 Max, RAM 128GB)
    • 512×512: MPS 49.6 detik, BLAS 51.9 detik, PyTorch MPS 5.4 detik
    • 256×256: MPS 32.4 detik, BLAS 29.7 detik, PyTorch MPS 3.0 detik
    • 64×64: MPS 25.0 detik, BLAS 23.5 detik, PyTorch MPS 2.2 detik
    • Backend C murni sangat lambat dan hanya cocok untuk pengujian

Build dan eksekusi

  • Pemilihan backend
    • make mps: macOS Apple Silicon (paling cepat)
    • make blas: Intel Mac atau Linux (memerlukan OpenBLAS)
    • make generic: C murni, tanpa dependensi (lambat)
  • Unduh model 
    pip install huggingface_hub
python download_model.py
  • Resolusi output maksimum 1024×1024, minimum 64×64, disarankan kelipatan 16

API library C

  • Muat dan bebaskan model
    • flux_load_dir(path) / flux_free(ctx)
  • Pembuatan dan transformasi gambar
    • flux_generate(ctx, prompt, params)
    • flux_img2img(ctx, prompt, input, params)
  • I/O gambar
    • flux_image_load(path) / flux_image_save(img, path)
  • Utilitas
    • flux_set_seed(seed) untuk memastikan reproduksibilitas
    • flux_get_error() untuk memeriksa pesan error
    • flux_release_text_encoder(ctx) untuk membebaskan memori secara manual

Lisensi dan informasi lain

  • Dirilis dengan lisensi MIT
  • Komposisi bahasa repositori: C 93.9%, Objective-C 3.5%, Makefile 1.7%, Python 0.9%
  • Dengan 446 bintang dan 20 fork, proyek ini menarik minat komunitas yang aktif

Bacaan terkait

1 komentar

 
GN⁺ 2026-01-19
Komentar Hacker News

  • Proyek ini bisa terwujud karena Opus diwajibkan menggunakan file IMPLEMENTATION_NOTES.md
    Semua hal yang ditemukan selama pengembangan ditambahkan terus ke file ini, selalu dijaga agar tetap mutakhir, dan ditetapkan untuk segera ditangani setelah kompresi konteks
    Pendekatan ini memungkinkan pekerjaan coding skala besar berjalan efisien tanpa kehilangan alur
    Detail lebih lanjut lihat file IMPLEMENTATION_NOTES.md di GitHub

    • Keren. Kuncinya adalah spesifikasi (spec) yang terus diperbarui
      Saya membahas pendekatan ini dalam tulisan vibe-speccing
      Menaruh “log eksperimen” di bagian bawah spesifikasi juga berguna, agar setiap perubahan tak terduga bisa langsung dicatat
    • Dengan Beads milik Steve Yegge, bagian yang tidak perlu di file markdown bisa dikurangi
      Saya penasaran apakah Anda sempat menjalankan benchmark. Menarik juga mengetahui apakah stack Python lebih cepat atau lebih lambat dibanding alat inferensi berbasis C
    • Saya penasaran apakah Anda berencana menuliskan pelajaran lain yang disebutkan di README
      Sebagai penggemar lama, saya ingin mendengar sudut pandang Anda tentang penggunaan alat semacam ini
    • Saya penasaran apakah Anda bisa membagikan log prompt yang digunakan atau materi lain selain catatan implementasi
      Saya ingin mempelajari proses kerja Anda
    • Ada solusi di Claude maupun LLM lain yang memungkinkan definisi tugas, penambahan catatan implementasi, serta pengelolaan subtugas dan dependensi
      Saya menggunakan Beads, dan hasilnya memang terasa lebih baik terutama untuk proyek besar

  • Saya membaca motivasi di README dengan tertarik
    Saya juga sedang mencoba menyertakan file PROMPTS.md
    Untuk tujuan berbagi dan edukasi, akan membantu jika terlihat pendekatan apa yang digunakan pengembang berpengalaman
    Dengan Claude hook, ini bisa dipertahankan secara deterministik. Di AGENTS.md saya menuliskan bahwa file itu hanya boleh dibaca
    Ini juga berguna untuk meneruskan latar belakang tugas saat berpindah antar LLM

    • Kali ini saya menulis spesifikasi alih-alih prompt, tetapi setelah itu saya tetap harus menyetel model selama berjam-jam
      Pada akhirnya prompt adalah akumulasi dari interaksi semacam ini, jadi sangat sulit untuk menyusunnya kembali secara bermakna

  • Saya penasaran bagaimana hasil dan proses eksperimen transpile ke bahasa lain dengan bantuan LLM
    Saya juga baru-baru ini meminta Claude untuk “tulis ulang ke Rust” pada bagian bottleneck sebuah proyek, dan kecepatannya meningkat drastis
    Namun hasilnya belum cukup andal untuk dipercaya di luar lingkungan lab

    • Tergantung situasinya. Kali ini saya bekerja hanya dengan kode referensi yang disediakan Black Forest Labs untuk Flux
      Yang penting adalah agen harus bisa memahami progres melalui umpan balik, serta bisa membandingkan dengan implementasi referensi saat melakukan debug
      Semua kode ditulis berdasarkan petunjuk implementasi yang menjelaskan hasil yang saya inginkan
      Hari ini seseorang mem-port implementasi vector set HNSW saya ke Swift, dan saya senang karena lisensinya sama
    • Saya menggunakan serangkaian prompt seperti “audit perubahan kode saat ini dari sudut pandang kesalahan logika”
      Kode yang dibuat Claude saya periksa lagi dengan GPT-5.x-Codex
      Opus 4.5 pun masih membuat kesalahan seperti off-by-one, jadi menggunakan model lain sebagai peer reviewer cukup efektif
      Urutan verifikasi saya adalah lint → test → model lain → saya

  • Model FLUX.2 [klein] asli dan kode Python-nya baru dirilis 3 hari lalu
    Diskusi terkait bisa dilihat di sini

    • Saya penasaran berapa lama yang dibutuhkan antirez tanpa Opus

  • Ditulis dalam C tidak otomatis berarti memberi performa setara C
    Dari benchmark, ini 8 kali lebih lambat daripada PyTorch. LLM masih punya keterbatasan untuk menghasilkan kode berperforma tinggi pada level ini

    • Versi PyTorch menggunakan GPU (Metal Performance Shaders), sedangkan versi C hanya memakai satu inti CPU
      Penyebab lambatnya bukan kualitas kode LLM, melainkan perbedaan hardware
      Operasi inti yang sebenarnya tetap memanggil library kernel yang sama dengan PyTorch
    • Saya pernah menulis kernel CUDA dan optimizer 8bit, dan LLM ternyata cukup piawai dalam optimasi kecepatan
      Dengan mengulang berbagai percobaan dan benchmark, peningkatannya bisa cepat, dan bahkan pernah melampaui baseline kuat dari torch

  • Setahu saya ini proyek OSS pertama Salvatore di bidang ML, jadi saya penasaran bagaimana dia membangun pengetahuan latar terkait
    Saya juga ingin tahu apakah Claude membantu menyediakan keahlian domain

    • Saya memang sudah lama suka bermain-main dengan AI. Misalnya, saya pernah membuat gguf-tools
      Saya juga menjalankan kanal YouTube AI berbahasa Italia, membaca paper dan menjelaskannya
      Pada 2003 saya membuat implementasi jaringan saraf pertama saya, dan setelah itu terus bereksperimen dengan model GPT kecil menggunakan PyTorch maupun C
      Saat mengerjakan Redis Vector Sets, saya juga menangani berbagai model embedding
      Claude mempercepat implementasi, tetapi konsep dasarnya sudah saya pahami
      Meski mungkin tetap bisa dilakukan hanya dengan latar belakang pemrograman dan hampir tanpa pengalaman AI, kemungkinan akan butuh lebih banyak umpan balik bolak-balik

  • Bulan lalu saya melakukan eksperimen serupa dengan mem-port Qwen 3 Omni ke llama.cpp
    Konversi GGUF, kuantisasi, serta modalitas input-output saya implementasikan hanya dalam seminggu, tetapi PR-nya ditolak
    Tautan terkait: PR #18404, model Hugging Face

    • Aneh kalau kernel GGML yang ditulis AI ditolak hanya karena tidak teroptimasi
      Orang yang menulis kernel secara manual bisa mendapatkan hasil luar biasa jika mampu mengarahkan model dengan baik
      Jika tren ini berlanjut, akan muncul fork llama.cpp yang lebih cepat dan lebih baik

  • Menarik bahwa OpenBLAS dan MPS menghasilkan kecepatan yang hampir sama
    Di README tertulis bahwa hanya MPS yang menggunakan GPU

  • Saya penasaran apakah kalau saya meminta Claude melakukan tugas yang sama, saya boleh menaruh nama saya sendiri dengan lisensi MIT
    Sebagai referensi, Flux2 menggunakan Apache License
    Perbedaannya memang tidak besar, tetapi detail lisensi seperti ini tetap terasa penting

    • Kode referensi hanya menunjukkan cara menyiapkan pipeline inferensi, dan tidak menyertakan implementasi inti yang sebenarnya (kernel, transformer, dll.)
    • Jika Anda menyuruh Claude mengimplementasikan ulang inferensi dalam C/C++ dan memberinya lisensi MIT, itu benar-benar mengesankan
      Tentu saja, itu baru berarti kalau hasilnya benar-benar berfungsi

  • Saya tidak terlalu paham C dan biasanya bekerja di analitik berbasis SQL, jadi saya penasaran apakah kode ini sudah layak produksi
    Saya sering mendengar bahwa kode buatan LLM sulit dirawat

    • Setelah melihat sekilas kodenya, ini bukan level amatir, memang belum level enterprise, tetapi cukup bagus
    • Penilaian seperti itu sudah ketinggalan zaman. Jika memakai Opus 4.5 bersama aturan yang jelas di CLAUDE.md, hasilnya bisa berupa kode yang cukup toleran dan rapi
      Untuk pekerjaan data science, performanya masih naik turun, tetapi jika definisi masalah dan informasi input diberikan dengan jelas, hasilnya bisa bagus