Flux 2 Klein: Reine C-basierte Inferenz

 (github.com/antirez)
1 Punkte von GN⁺ 2026-01-19 | 1 Kommentare | Auf WhatsApp teilen
  • Reine C-Implementierung zur Bildgenerierung mit dem FLUX.2-klein-4B-Modell auf Basis von Text- oder Bildeingaben
  • Läuft ohne externe Abhängigkeiten und kann optional per BLAS- oder Metal-Beschleunigung um bis zu das 30-Fache schneller werden
  • Qwen3-4B-Text-Encoder ist integriert, sodass kein separater Embedding-Berechnungsschritt nötig ist
  • Unterstützt sowohl Text-zu-Bild als auch Bild-zu-Bild-Transformation und bietet eine Kommandozeilenoberfläche sowie eine C-Bibliotheks-API
  • Kann ohne Python-Runtime oder PyTorch ausgeführt werden und ist damit relevant für leichtgewichtige Inferenzumgebungen und einen breiteren Zugang zu Open-Source-AI

Projektüberblick

  • FLUX.2-klein-4B ist ein Bildgenerierungsmodell von Black Forest Labs, das aus Text-Prompts oder vorhandenen Bildern neue Bilder erzeugt
  • Der gesamte Code ist ausschließlich mit der Standard-C-Bibliothek geschrieben, mit optionaler Unterstützung für MPS (Apple Metal) und BLAS (OpenBLAS)
  • Das Modell kann von HuggingFace mit einer Größe von rund 16GB heruntergeladen werden und besteht aus VAE (300MB), Transformer (4GB), Qwen3-4B-Encoder (8GB) und Tokenizer

Hauptfunktionen

  • Zero dependencies: Kann ohne externe Bibliotheken eigenständig ausgeführt werden
    • Bei Nutzung von BLAS etwa 30-fache Beschleunigung, unter macOS mit Apple Accelerate, unter Linux mit OpenBLAS
  • Metal GPU acceleration: Wird in Apple-Silicon-Umgebungen automatisch aktiviert
  • Text-to-image: Bildgenerierung aus Text-Prompts
  • Image-to-image: Transformation vorhandener Bilder anhand eines Prompts
  • Integrated text encoder: Qwen3-4B-Encoder integriert, keine externen Embeddings erforderlich
  • Memory efficient: Nach dem Encoding wird der Encoder-Speicher automatisch freigegeben, was rund 8GB spart

Nutzungsbeispiele

  • Bild aus Text erzeugen 
    ./flux -d flux-klein-model -p "A fluffy orange cat sitting on a windowsill" -o cat.png
  • Bild transformieren 
    ./flux -d flux-klein-model -i photo.png -o painting.png -p "oil painting style" -t 0.7
    • Der Wert -t steuert die Transformationsstärke; 0.0 erhält das Original, 1.0 erzeugt eine vollständige Neugenerierung

Modellarchitektur und Leistung

  • Transformer: 5 Double-Blöcke und 20 Single-Blöcke, 3072 Hidden-Dimensionen, 24 Attention-Head
  • VAE: AutoencoderKL, 128 latente Kanäle, 8-fache räumliche Kompression
  • Text Encoder: Qwen3-4B, 36 Schichten, 2560 Hidden-Dimensionen
  • Inferenzschritte: Hochwertige Ergebnisse mit 4 Sampling-Schritten
  • Speicherbedarf
    • Text-Encoding: etwa 8GB
    • Diffusion: etwa 8GB
    • Maximaler Peak: 16GB (vor Freigabe des Encoders)
  • Leistungsbenchmarks (Apple M3 Max, 128GB RAM)
    • 512×512: MPS 49,6 Sekunden, BLAS 51,9 Sekunden, PyTorch MPS 5,4 Sekunden
    • 256×256: MPS 32,4 Sekunden, BLAS 29,7 Sekunden, PyTorch MPS 3,0 Sekunden
    • 64×64: MPS 25,0 Sekunden, BLAS 23,5 Sekunden, PyTorch MPS 2,2 Sekunden
    • Das reine C-Backend ist sehr langsam und nur für Tests geeignet

Build und Ausführung

  • Backend-Auswahl
    • make mps: macOS Apple Silicon (am schnellsten)
    • make blas: Intel Mac oder Linux (OpenBLAS erforderlich)
    • make generic: reines C, ohne Abhängigkeiten (langsam)
  • Modell herunterladen 
    pip install huggingface_hub
python download_model.py
  • Die Ausgaberesolution beträgt maximal 1024×1024, minimal 64×64; empfohlen werden Vielfache von 16

C-Bibliotheks-API

  • Modell laden und freigeben
    • flux_load_dir(path) / flux_free(ctx)
  • Bildgenerierung und -transformation
    • flux_generate(ctx, prompt, params)
    • flux_img2img(ctx, prompt, input, params)
  • Bild-Ein-/Ausgabe
    • flux_image_load(path) / flux_image_save(img, path)
  • Hilfsfunktionen
    • Reproduzierbarkeit mit flux_set_seed(seed)
    • Fehlermeldungen mit flux_get_error() prüfen
    • Manuelle Speicherfreigabe mit flux_release_text_encoder(ctx) möglich

Lizenz und weitere Informationen

  • Veröffentlicht unter der MIT-Lizenz
  • Sprachverteilung im Repository: C 93.9%, Objective-C 3.5%, Makefile 1.7%, Python 0.9%
  • 446 Sterne und 20 Forks, was auf reges Interesse der Community hinweist

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2026-01-19
Hacker-News-Kommentare

  • Dieses Projekt war möglich, weil Opus ausdrücklich angewiesen wurde, die Datei IMPLEMENTATION_NOTES.md zwingend zu verwenden
    Alles, was während der Entwicklung entdeckt wurde, wurde fortlaufend in dieser Datei gesammelt, stets aktuell gehalten und nach einer Kontextkomprimierung sofort verarbeitet
    Dadurch ließ sich auch bei umfangreicher Codierarbeit effizient weiterarbeiten, ohne den Faden zu verlieren
    Mehr dazu in der Datei IMPLEMENTATION_NOTES.md auf GitHub

    • Großartig. Eine fortlaufend aktualisierte Spezifikation (spec) ist der Schlüssel
      Ich habe diesen Ansatz im Beitrag vibe-speccing behandelt
      Es war außerdem hilfreich, am Ende der Spezifikation ein „Experimentierprotokoll“ zu führen, in dem jede unerwartete Änderung festgehalten wird
    • Mit Steve Yegges Beads kann man die unnötigen Teile in Markdown-Dateien reduzieren
      Ich frage mich, ob du Benchmarks ausgeführt hast. Es wäre auch interessant, ob der Python-Stack schneller oder langsamer ist als das C-basierte Inferenz-Tool
    • Ich frage mich, ob du planst, die anderen im README erwähnten Erkenntnisse ebenfalls schriftlich festzuhalten
      Als langjähriger Fan würde ich gern deine Perspektive auf den Einsatz solcher Tools hören
    • Ich frage mich, ob du außer den verwendeten Prompt-Logs oder Implementierungsnotizen noch weiteres Material teilen kannst
      Ich würde gern deinen Arbeitsprozess kennenlernen
    • Es gibt auch für Claude oder andere LLMs Lösungen, mit denen sich Aufgaben definieren, Implementierungsnotizen ergänzen und Teilaufgaben sowie Abhängigkeiten verwalten lassen
      Ich nutze Beads, und besonders bei großen Projekten wird die Ergebnisqualität spürbar besser

  • Ich fand die Motivation im README interessant
    Ich versuche ebenfalls, eine Datei PROMPTS.md einzubinden
    Für Zwecke des Teilens und Lernens ist es hilfreich zu zeigen, welchen Ansatz erfahrene Entwickler verwenden
    Mit Claude hooks kann man das deterministisch beibehalten. In AGENTS.md habe ich festgelegt, dass die Datei nur lesbar ist
    Auch beim Wechsel zwischen LLMs war das hilfreich, um den Hintergrund einer Aufgabe zu übermitteln

    • Diesmal habe ich statt eines Prompts eine Spezifikation geschrieben, musste das Modell danach aber noch stundenlang nachjustieren
      Letztlich ist ein Prompt die Summe solcher Interaktionen, daher ist es sehr schwer, ihn sinnvoll zu rekonstruieren

  • Mich würde interessieren, wie Ergebnis und Prozess bei Experimenten aussahen, LLMs zum Transpilieren in andere Sprachen zu verwenden
    Ich habe Claude kürzlich bei einem Flaschenhals in einem Projekt gebeten: „Schreib das in Rust neu“, und die Geschwindigkeit hat sich stark verbessert
    Allerdings war das Ergebnis noch nicht so zuverlässig, dass ich ihm außerhalb des Labors trauen würde

    • Das hängt von der Situation ab. Diesmal habe ich nur mit dem von Black Forest Labs für Flux bereitgestellten Referenzcode gearbeitet
      Entscheidend ist, dass der Agent über Feedback versteht, ob Fortschritt erzielt wird, und beim Debuggen mit der Referenzimplementierung vergleichen kann
      Der gesamte Code wurde auf Basis von Implementierungshinweisen geschrieben, die das von mir gewünschte Ergebnis beschrieben
      Heute hat jemand mein HNSW-Vectorset-Implementierung nach Swift portiert, und weil die Lizenz identisch ist, freut mich das
    • Ich verwende einen Satz von Prompts wie: „Prüfe die aktuelle Codeänderung unter dem Gesichtspunkt von Logikfehlern“
      Den von Claude erzeugten Code prüfe ich dann erneut mit GPT-5.x-Codex
      Auch Opus 4.5 macht noch Fehler wie off-by-one, daher ist es effektiv, ein anderes Modell als Peer Reviewer einzusetzen
      Meine Prüfreihenfolge ist: lint → test → anderes Modell → ich

  • Das ursprüngliche Modell FLUX.2 [klein] und der Python-Code wurden erst vor 3 Tagen veröffentlicht
    Die dazugehörige Diskussion findet sich hier

    • Ich frage mich, wie lange antirez ohne Opus gebraucht hätte

  • Nur weil es in C geschrieben ist, heißt das nicht, dass es zwangsläufig Leistung auf C-Niveau liefert
    Den Benchmarks nach ist es 8-mal langsamer als PyTorch. Für LLMs gibt es offenbar noch Grenzen, wenn es darum geht, Code mit dieser Art von Höchstleistung zu erzeugen

    • Die PyTorch-Version nutzt die GPU (Metal Performance Shaders), die C-Version dagegen nur einen einzelnen CPU-Kern
      Der Grund für die geringere Geschwindigkeit ist also nicht die Codequalität des LLMs, sondern der Hardware-Unterschied
      Die eigentlichen Kernoperationen rufen dieselbe Kernel-Bibliothek auf wie PyTorch
    • Ich habe schon CUDA-Kernel und 8-Bit-Optimizer geschrieben, und LLMs sind bei der Geschwindigkeitsoptimierung ziemlich gut
      Mit mehreren Versuchen und wiederholten Benchmarks verbessern sie sich schnell und haben sogar schon die starke Baseline von torch übertroffen

  • Soweit ich weiß, ist das Salvatore erstes OSS-Projekt im ML-Bereich. Mich würde interessieren, wie er sich das nötige Hintergrundwissen angeeignet hat
    Ich würde auch gern wissen, ob Claude dabei geholfen hat, Domänenexpertise beizusteuern

    • Ich habe mich schon früher gern mit AI beschäftigt. Zum Beispiel habe ich gguf-tools erstellt
      Außerdem betreibe ich einen AI-YouTube-Kanal auf Italienisch, auf dem ich Papers lese und erkläre
      2003 habe ich meine erste Implementierung eines neuronalen Netzes gebaut und seitdem immer wieder mit kleinen GPT-Modellen in PyTorch oder C experimentiert
      Bei der Arbeit an Redis Vector Sets habe ich mit verschiedenen Embedding-Modellen gearbeitet
      Mit Claude ging die Implementierung zwar schneller, aber die grundlegenden Konzepte kannte ich bereits
      Es wäre wahrscheinlich auch mit reinem Programmierhintergrund und fast ohne AI-Erfahrung möglich, aber es würde wohl mehr Hin-und-her-Feedback erfordern

  • Letzten Monat habe ich in einem ähnlichen Experiment Qwen 3 Omni nach llama.cpp portiert
    GGUF-Konvertierung, Quantisierung und Ein-/Ausgabe-Modalitäten habe ich innerhalb einer Woche umgesetzt, aber der PR wurde abgelehnt
    Relevante Links: PR #18404, Hugging-Face-Modell

    • Es ist merkwürdig, dass von AI geschriebene GGML-Kernel wegen mangelnder Optimierung abgelehnt wurden
      Wer Kernel von Hand schreibt und das Modell gut steuert, kann hervorragende Ergebnisse erzielen
      Wenn sich dieser Trend fortsetzt, werden schnellere und bessere llama.cpp-Forks auftauchen

  • Ich finde interessant, dass OpenBLAS und MPS nahezu dieselbe Geschwindigkeit erreichen
    Im README steht, dass nur MPS die GPU verwendet

  • Ich frage mich, ob ich Claude dieselbe Aufgabe geben und dann meinen Namen unter die MIT-Lizenz setzen dürfte
    Zur Einordnung: Flux2 verwendet die Apache License
    Der Unterschied ist nicht groß, aber solche Lizenzdetails beschäftigen mich

    • Der Referenzcode zeigt nur die Einrichtung der Inferenz-Pipeline; die eigentliche Kernimplementierung (Kernel, Transformer usw.) ist nicht enthalten
    • Wenn man Claude anweisen würde, die Inferenz in C/C++ neu zu implementieren und dann eine MIT-Lizenz daraufzusetzen, wäre das wirklich beeindruckend
      Entscheidend ist allerdings, dass es auch tatsächlich funktioniert

  • Ich kenne mich mit C nicht gut aus und arbeite hauptsächlich mit SQL-basierter Analyse. Mich würde interessieren, ob dieser Code produktionsreif ist
    Oft hört man, von LLMs erzeugter Code sei schwer wartbar

    • Ich habe den Code überflogen; er wirkt nicht amateurhaft und ist zwar nicht auf Unternehmensniveau, aber durchaus ziemlich ordentlich
    • Diese Einschätzung ist veraltet. Mit Opus 4.5 und klaren Regeln in CLAUDE.md bekommt man oft recht idiomatischen und sauberen Code
      Bei Data-Science-Arbeiten schwankt die Leistung zwar, aber wenn Problemdefinition und Eingaben klar sind, kann man gute Ergebnisse erzielen