Flux 2 Klein saf C tabanlı çıkarım

 (github.com/antirez)
1 puan yazan GN⁺ 2026-01-19 | 1 yorum | WhatsApp'ta paylaş
  • FLUX.2-klein-4B modeli ile metin veya görseli girdi olarak alıp görsel üreten saf C uygulaması
  • Harici bağımlılık olmadan çalışır; isteğe bağlı BLAS veya Metal hızlandırması ile 30 kata kadar hız artışı sağlanabilir
  • Qwen3-4B metin kodlayıcısı yerleşik gelir; ayrı bir embedding hesaplama süreci gerekmez
  • Hem metinden görsele hem de görselden görsele dönüşümü destekler; komut satırı arayüzü ve C kütüphanesi API'si sunar
  • Python çalışma zamanı veya PyTorch olmadan da çalışabildiği için hafif çıkarım ortamları ve açık kaynak yapay zekaya erişimin genişlemesi açısından anlamlı

Projeye genel bakış

  • FLUX.2-klein-4B, Black Forest Labs'ın bir görsel üretim modeli; metin istemlerini veya mevcut görselleri girdi alarak yeni görseller üretir
  • Tüm kod yalnızca standart C kütüphanesiyle yazılmıştır ve isteğe bağlı olarak MPS(Apple Metal) ile BLAS(OpenBLAS) hızlandırmasını destekler
  • Model HuggingFace üzerinden yaklaşık 16GB boyutunda indirilebilir; bileşenleri VAE(300MB), Transformer(4GB), Qwen3-4B kodlayıcı(8GB) ve Tokenizer'dan oluşur

Başlıca özellikler

  • Zero dependencies: Harici kütüphane olmadan bağımsız şekilde çalışabilir
    • BLAS kullanıldığında yaklaşık 30 kat hızlanma sağlanır; macOS'ta Apple Accelerate, Linux'ta OpenBLAS kullanılabilir
  • Metal GPU acceleration: Apple Silicon ortamında otomatik etkinleşir
  • Text-to-image: Metin isteminden görsel üretimi
  • Image-to-image: Mevcut görseli isteme göre dönüştürme
  • Integrated text encoder: Qwen3-4B kodlayıcısı yerleşik olduğundan harici embedding gerekmez
  • Memory efficient: Kodlama sonrası kodlayıcı belleği otomatik serbest bırakılır, yaklaşık 8GB tasarruf sağlar

Kullanım örnekleri

  • Metinden görsel üretme 
    ./flux -d flux-klein-model -p "A fluffy orange cat sitting on a windowsill" -o cat.png
  • Görsel dönüştürme 
    ./flux -d flux-klein-model -i photo.png -o painting.png -p "oil painting style" -t 0.7
    • -t değeri dönüşüm gücünü kontrol eder; 0.0 orijinali korur, 1.0 ise tamamen yeniden üretir

Model yapısı ve performans

  • Transformer: 5 çift blok ve 20 tek blok, 3072 gizli boyut, 24 attention head
  • VAE: AutoencoderKL, 128 latent kanal, 8 kat uzamsal sıkıştırma
  • Text Encoder: Qwen3-4B, 36 katman, 2560 gizli boyut
  • Çıkarım adımları: 4 adımlı örnekleme ile yüksek kaliteli sonuç üretimi
  • Bellek gereksinimi
    • Metin kodlama: yaklaşık 8GB
    • Diffusion: yaklaşık 8GB
    • En yüksek tepe: 16GB (kodlayıcı serbest bırakılmadan önce)
  • Performans kıyaslamaları (Apple M3 Max, 128GB RAM)
    • 512×512: MPS 49.6 sn, BLAS 51.9 sn, PyTorch MPS 5.4 sn
    • 256×256: MPS 32.4 sn, BLAS 29.7 sn, PyTorch MPS 3.0 sn
    • 64×64: MPS 25.0 sn, BLAS 23.5 sn, PyTorch MPS 2.2 sn
    • Saf C backend çok yavaştır ve yalnızca test amaçlı uygundur

Derleme ve çalıştırma

  • Backend seçimi
    • make mps: macOS Apple Silicon (en hızlı)
    • make blas: Intel Mac veya Linux (OpenBLAS gerekir)
    • make generic: saf C, bağımlılık yok (yavaş)
  • Model indirme 
    pip install huggingface_hub
python download_model.py
  • Çıktı çözünürlüğü en fazla 1024×1024, en az 64×64; 16'nın katları önerilir

C kütüphanesi API'si

  • Model yükleme ve serbest bırakma
    • flux_load_dir(path) / flux_free(ctx)
  • Görsel üretimi ve dönüştürme
    • flux_generate(ctx, prompt, params)
    • flux_img2img(ctx, prompt, input, params)
  • Görsel giriş/çıkışı
    • flux_image_load(path) / flux_image_save(img, path)
  • Yardımcı araçlar
    • flux_set_seed(seed) ile yeniden üretilebilirlik sağlama
    • flux_get_error() ile hata mesajını kontrol etme
    • flux_release_text_encoder(ctx) ile belleği elle serbest bırakabilme

Lisans ve diğer bilgiler

  • MIT lisansı ile yayımlanıyor
  • Depodaki dil dağılımı: C 93.9%, Objective-C 3.5%, Makefile 1.7%, Python 0.9%
  • 446 yıldız ve 20 fork ile topluluktan güçlü ilgi görüyor

İlgili okumalar

1 yorum

 
GN⁺ 2026-01-19
Hacker News yorumları

  • Bu projenin mümkün olmasının nedeni, Opus'a IMPLEMENTATION_NOTES.md dosyasını mutlaka kullanmasını söylemiş olmalarıydı
    Geliştirme sırasında fark edilen her şeyi bu dosyada biriktirmesi, her zaman güncel tutması ve bağlam sıkıştırmasından sonra hemen işlemesi açıkça belirtilmişti
    Bu yaklaşım sayesinde büyük ölçekli kodlama işlerini verimli biçimde ilerletirken akışı kaybetmemek mümkün olmuş
    Daha fazla ayrıntı için GitHub’daki IMPLEMENTATION_NOTES.md dosyasına bakın

    • Harika. Sürekli güncellenen bir spec bunun anahtarı
      Ben bu yaklaşımı vibe-speccing yazısında ele aldım
      Ayrıca spec’in altına bir “deney günlüğü” koyup beklenmedik bir değişiklik olduğunda oraya not düşmek de faydalı oldu
    • Steve Yegge’nin Beads aracını kullanmak, markdown dosyasındaki gereksiz kısımları azaltabilir
      Benchmark çalıştırıp çalıştırmadığınızı da merak ediyorum. Python stack’inin C tabanlı çıkarım aracından daha hızlı mı daha yavaş mı olduğu da ilginç olurdu
    • README’de bahsedilen diğer dersleri de yazı haline getirmeyi planlayıp planlamadığınızı merak ediyorum
      Uzun süredir bir hayranınız olarak, bu araçları kullanırken sizin bakış açınızı duymak isterim
    • Kullandığınız prompt kayıtları ya da implementasyon notları dışında başka materyaller paylaşabilir misiniz diye merak ediyorum
      Sizin çalışma sürecinizi öğrenmek isterim
    • Claude ya da başka LLM’lerde iş tanımı yapma, implementasyon notları ekleme ve alt görevler ile bağımlılık yönetimi için çözüm sunan araçlar da var
      Ben Beads kullanıyorum ve özellikle büyük projelerde çıktı kalitesi belirgin biçimde artıyor

  • README’deki motivasyonu ilgiyle okudum
    Ben de benzer şekilde bir PROMPTS.md dosyası eklemeyi deniyorum
    Amaç paylaşım ve eğitimse, deneyimli bir geliştiricinin nasıl bir yaklaşım kullandığını göstermek faydalı oluyor
    Claude hook kullanarak bunu deterministik biçimde koruyabilirsiniz. AGENTS.md içinde bunun yalnızca okunabilir olduğunu belirttim
    Bu, LLM’ler arasında geçiş yaparken işin arka planını aktarmakta da faydalı oldu

    • Bu kez prompt yerine bir spec yazdım ama sonrasında modeli saatlerce ayarlamam gerekti
      Sonuçta prompt, bu tür etkileşimlerin toplamı oluyor; bu yüzden onu anlamlı biçimde yeniden yapılandırmak çok zor

  • LLM kullanarak başka dillere transpile etme deneyiyle ilgili olarak, sonuçlar ve süreç nasıldı diye merak ediyorum
    Ben de yakın zamanda bir projedeki darboğaz kısmı için Claude’a “bunu Rust ile yeniden yaz” dedim ve hız ciddi biçimde arttı
    Yine de ortaya çıkan sonuç laboratuvar dışındaki kullanım için yeterince güvenilir değildi

    • Duruma göre değişir. Bu kez sadece Black Forest Labs’in Flux için sağladığı referans kod ile çalıştım
      Asıl nokta, ajanın geri bildirim üzerinden ilerleme durumunu anlayabilmesi ve referans implementasyonla karşılaştırarak debug yapabilmesiydi
      Tüm kod, istediğim sonucu tanımlayan uygulama ipuçları temelinde yazıldı
      Bugün biri benim HNSW vector set implementasyonumu Swift’e port etti; lisansı da aynı olduğu için hoşuma gitti
    • Ben “mevcut kod değişikliğini mantık hataları açısından denetle” şeklinde bir prompt seti kullanıyorum
      Claude’un ürettiği kodu GPT-5.x-Codex ile tekrar kontrol ediyorum
      Opus 4.5 hâlâ off-by-one türü hatalar yapabildiği için başka bir modeli akran değerlendiricisi olarak kullanmak etkili oluyor
      Benim doğrulama sıram lint → test → başka model → ben şeklinde ilerliyor

  • Orijinal FLUX.2 [klein] modeli ve Python kodu sadece 3 gün önce yayımlandı
    İlgili tartışma için buraya bakabilirsiniz

    • Antirez’in Opus olmadan ne kadar süreceğini merak ediyorum

  • C ile yazılmış olması mutlaka C düzeyinde performans verdiği anlamına gelmiyor
    Benchmark’lara bakınca PyTorch’tan 8 kat daha yavaş. LLM’lerin bu seviyede yüksek performanslı kod üretmesinde hâlâ sınırlar var

    • PyTorch sürümü GPU (Metal Performance Shaders) kullanıyor ama C sürümü yalnızca tek bir CPU çekirdeği kullanıyor
      Yavaşlığın nedeni LLM kod kalitesi değil, donanım farkı
      Gerçek çekirdek işlemler aslında PyTorch ile aynı kernel kütüphanesini çağırıyor
    • Ben CUDA kernel’leri ve 8bit optimizer yazdım; LLM’ler hız optimizasyonunda epey yetenekli olabiliyor
      Birden fazla deneme ve benchmark döngüsüyle hızlı iyileştirme yapabiliyorlar, hatta bazen torch’un güçlü başlangıç çizgisini bile geçebiliyorlar

  • Salvatore’un ML alanındaki ilk OSS projesini yaptığını sanıyordum; bunun için gerekli arka plan bilgisini nasıl edindiğini merak ediyorum
    Claude’un alan uzmanlığı sağlamada yardımcı olup olmadığını da öğrenmek isterim

    • Eskiden beri AI ile uğraşmayı seviyorum. Mesela gguf-tools yapmıştım
      Ayrıca İtalyanca yayın yapan bir AI YouTube kanalı da yürütüyorum; makaleleri okuyup açıklıyorum
      2003’te ilk sinir ağı implementasyonumu yazdım ve sonrasında da PyTorch ya da C ile küçük GPT modelleri üzerinde denemeler yapmayı sürdürdüm
      Redis Vector Sets üzerinde çalışırken çeşitli embedding modelleriyle uğraştım
      Claude sayesinde implementasyon hızı arttı ama temel kavramları zaten biliyordum
      Sadece programlama geçmişi olup AI deneyimi çok az olan biri için de mümkün olabilir, ama muhtemelen daha fazla geri bildirim döngüsü gerekir

  • Geçen ay benzer bir deney olarak Qwen 3 Omni’yi llama.cpp’ye port ettim
    GGUF dönüştürme, quantization ve giriş/çıkış modalitelerini bir haftada uyguladım ama PR reddedildi
    İlgili bağlantılar: PR #18404, Hugging Face modeli

    • AI’ın yazdığı GGML kernel’lerinin optimize edilmemiş olduğu için reddedilmesi tuhaf
      Kernel’leri elle yazan biri modeli iyi yönlendirebilirse harika sonuçlar elde edebilir
      Bu akış böyle devam ederse daha hızlı ve daha iyi llama.cpp fork’ları ortaya çıkacaktır

  • OpenBLAS ile MPS’nin neredeyse aynı hızı vermesi ilginç
    README’de GPU kullanan tek şeyin MPS olduğu yazıyor

  • Claude’a aynı işi yaptırsam ve üstüne MIT lisansı koyup kendi adımı yazsam sorun olur mu diye merak ediyorum
    Bu arada Flux2 Apache License kullanıyor
    Aradaki fark çok büyük değil ama bu tür lisans ayrıntıları insanın aklına takılıyor

    • Referans kod yalnızca çıkarım pipeline’ının kurulumunu gösteriyor; gerçek çekirdek implementasyonları (kernel’ler, transformer vb.) bunun içinde yer almıyor
    • Claude’a C/C++ ile çıkarımı yeniden uygulamasını söyleyip üstüne MIT lisansı koymak gerçekten etkileyici olurdu
      Tabii bunun anlamlı olması için gerçekten doğru çalışması gerekir

  • Ben C’yi pek bilmiyorum, daha çok SQL tabanlı analiz yapıyorum; bu kodun production seviyesi olup olmadığını merak ediyorum
    LLM’in ürettiği kodun bakımının zor olduğu sık söyleniyor

    • Koda hızlıca baktım; amatör işi değil, kurumsal seviye de değil ama oldukça iyi görünüyor
    • Bu değerlendirme artık biraz eski kaldı. Opus 4.5 ile birlikte CLAUDE.md içindeki net kurallar kullanıldığında oldukça deyimsel ve temiz kod çıkabiliyor
      Data science işlerinde performans tutarsız olabiliyor ama problem tanımını ve girdi bilgilerini net verirseniz iyi sonuç alınabiliyor