Flux 2 Klein के लिए शुद्ध C-आधारित inference

 (github.com/antirez)
1 पॉइंट द्वारा GN⁺ 2026-01-19 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • FLUX.2-klein-4B मॉडल का उपयोग करके टेक्स्ट या इमेज इनपुट से इमेज जनरेट करने वाला शुद्ध C implementation
  • बिना किसी external dependency के चलता है, और वैकल्पिक BLAS या Metal acceleration के जरिए अधिकतम 30 गुना तक speed-up संभव
  • Qwen3-4B text encoder built-in है, इसलिए अलग embedding calculation process की ज़रूरत नहीं
  • Text-to-image और image-to-image transformation दोनों को support करता है, साथ ही command-line interface और C library API भी देता है
  • Python runtime या PyTorch के बिना भी चल सकता है, इसलिए lightweight inference environments और open source AI accessibility बढ़ाने के लिहाज़ से महत्वपूर्ण

प्रोजेक्ट अवलोकन

  • FLUX.2-klein-4B Black Forest Labs का एक image generation model है, जो text prompt या existing image को input लेकर नई image बनाता है
  • पूरा code केवल standard C library से लिखा गया है, और वैकल्पिक रूप से MPS(Apple Metal) तथा BLAS(OpenBLAS) acceleration को support करता है
  • मॉडल को HuggingFace से लगभग 16GB आकार में डाउनलोड किया जा सकता है, और इसके components हैं VAE(300MB), Transformer(4GB), Qwen3-4B encoder(8GB), और Tokenizer

मुख्य फीचर्स

  • Zero dependencies: बाहरी libraries के बिना standalone execution संभव
    • BLAS उपयोग करने पर लगभग 30 गुना speed-up, macOS पर Apple Accelerate और Linux पर OpenBLAS उपलब्ध
  • Metal GPU acceleration: Apple Silicon environment में अपने-आप सक्रिय
  • Text-to-image: text prompt से image generation
  • Image-to-image: existing image को prompt के अनुसार transform करना
  • Integrated text encoder: Qwen3-4B encoder built-in, external embedding की ज़रूरत नहीं
  • Memory efficient: encoding के बाद encoder memory अपने-आप release हो जाती है, लगभग 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 मान transformation strength को control करता है; 0.0 पर मूल image बनी रहती है, 1.0 पर पूरी तरह से regenerate होती है

मॉडल संरचना और प्रदर्शन

  • Transformer: 5 double blocks और 20 single blocks, 3072 hidden dimensions, 24 attention heads
  • VAE: AutoencoderKL, 128 latent channels, 8x spatial compression
  • Text Encoder: Qwen3-4B, 36 layers, 2560 hidden dimensions
  • Inference steps: 4-step sampling से high-quality results
  • Memory requirements
    • text encoding: लगभग 8GB
    • diffusion: लगभग 8GB
    • peak maximum: 16GB (encoder release होने से पहले)
  • Performance benchmark (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 backend बहुत धीमा है और केवल testing के लिए उपयुक्त है

बिल्ड और रन

  • backend चयन
    • make mps: macOS Apple Silicon (सबसे तेज)
    • make blas: Intel Mac या Linux (OpenBLAS आवश्यक)
    • make generic: शुद्ध C, बिना dependency (धीमा)
  • मॉडल डाउनलोड 
    pip install huggingface_hub
python download_model.py
  • output resolution अधिकतम 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)
  • इमेज input/output
    • flux_image_load(path) / flux_image_save(img, path)
  • यूटिलिटी
    • flux_set_seed(seed) से reproducibility सुनिश्चित
    • flux_get_error() से error message की जाँच
    • flux_release_text_encoder(ctx) से memory को manually release किया जा सकता है

लाइसेंस और अन्य जानकारी

  • MIT लाइसेंस के तहत जारी
  • repository language composition: C 93.9%, Objective-C 3.5%, Makefile 1.7%, Python 0.9%
  • 446 stars और 20 forks के साथ community की सक्रिय रुचि

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2026-01-19
Hacker News टिप्पणियाँ

  • यह प्रोजेक्ट संभव हो पाया क्योंकि Opus को IMPLEMENTATION_NOTES.md फ़ाइल का ज़रूर उपयोग करने के लिए कहा गया था
    डेवलपमेंट के दौरान मिली हर बात को इस फ़ाइल में जोड़ते रहना, इसे हमेशा up-to-date रखना, और context compression के बाद तुरंत प्रोसेस करना स्पष्ट रूप से तय किया गया था
    इस तरीके की वजह से बड़े coding काम को efficiently आगे बढ़ाते हुए भी flow नहीं टूटा
    अधिक जानकारी के लिए GitHub की IMPLEMENTATION_NOTES.md फ़ाइल देखें

    • शानदार। लगातार update होने वाली spec ही कुंजी है
      मैंने vibe-speccing लेख में इस approach पर बात की है
      spec के नीचे “experiment log” रखना भी उपयोगी रहा, ताकि हर unexpected बदलाव को दर्ज किया जा सके
    • Steve Yegge के Beads का उपयोग करने से markdown फ़ाइल के अनावश्यक हिस्सों को कम किया जा सकता है
      यह भी जानना दिलचस्प होगा कि benchmark चलाए गए या नहीं। Python stack, C-आधारित inference tool से तेज़ है या धीमा, यह भी रोचक है
    • क्या README में बताए गए दूसरे lessons को भी किसी लेख में संकलित करने की योजना है?
      लंबे समय से प्रशंसक होने के नाते, ऐसे tools के उपयोग पर आपका perspective सुनना चाहूँगा
    • क्या prompt logs या implementation notes के अलावा कोई और material साझा किया जा सकता है?
      मैं आपका workflow सीखना चाहता हूँ
    • Claude या दूसरे LLM में भी task definition, implementation notes जोड़ना, और subtasks तथा dependency management संभव बनाने वाले solutions हैं
      मैं Beads का उपयोग कर रहा हूँ, और खासकर बड़े projects में output quality निश्चित रूप से बेहतर होती है

  • README में motivation को दिलचस्पी से पढ़ा
    मैं भी इसी तरह PROMPTS.md फ़ाइल शामिल करने की कोशिश कर रहा हूँ
    sharing और education के उद्देश्य से, experienced developer कौन-सा approach अपनाता है यह दिखाना मददगार होता है
    Claude hook का उपयोग करके इसे deterministic रखा जा सकता है। AGENTS.md में मैंने इसे read-only बताया है
    अलग-अलग LLM के बीच switch करते समय task background पहुँचाने में भी यह उपयोगी रहा

    • इस बार prompt की जगह spec लिखी गई, लेकिन बाद में model को कई घंटों तक tune करना पड़ा
      आखिरकार prompt ऐसे interactions का कुल योग होता है, इसलिए उसे अर्थपूर्ण ढंग से फिर से बनाना बहुत कठिन है

  • LLM का उपयोग करके दूसरी भाषा में transpile करने वाले प्रयोग के बारे में, नतीजे और प्रक्रिया कैसी रही यह जानना चाहूँगा
    मैंने भी हाल में एक project bottleneck को Claude से “इसे Rust में फिर से लिखो” कहा था, और speed काफी बढ़ गई
    लेकिन output अभी भी lab के बाहर भरोसे लायक स्तर का नहीं था

    • यह situation पर निर्भर करता है। इस बार काम Flux के Black Forest Labs द्वारा दिए गए सिर्फ reference code के आधार पर किया गया था
      मुख्य बात यह है कि agent feedback के ज़रिए समझ सके कि प्रगति हो रही है या नहीं, और reference implementation से तुलना करते हुए debug कर सके
      सारा code उन implementation hints के आधार पर लिखा गया था जिनमें मैंने वांछित परिणाम स्पष्ट किए थे
      आज किसी ने मेरे HNSW vectorset implementation को Swift में port किया, और वही license होने से अच्छा लगा
    • मैं “मौजूदा code changes का logical errors के दृष्टिकोण से audit करो” जैसे prompt set का उपयोग करता हूँ
      Claude द्वारा generate किया गया code मैं GPT-5.x-Codex से फिर से check कराता हूँ
      Opus 4.5 अब भी off-by-one जैसी गलतियाँ करता है, इसलिए किसी दूसरे model को peer reviewer की तरह उपयोग करना प्रभावी है
      मेरा validation क्रम है: lint → test → दूसरा model → मैं

  • मूल FLUX.2 [klein] model और Python code सिर्फ 3 दिन पहले ही जारी किए गए थे
    संबंधित चर्चा यहाँ देखें

    • सोचता हूँ Opus के बिना antirez को इसमें कितना समय लगता

  • सिर्फ C में लिखा होने का मतलब यह नहीं कि वह ज़रूर C-level performance देगा
    benchmark के अनुसार यह PyTorch से 8 गुना धीमा है। इस स्तर का high-performance code LLM से बनवाने में अभी सीमाएँ हैं

    • PyTorch version GPU (Metal Performance Shaders) का उपयोग करता है, जबकि C version सिर्फ एक CPU core का उपयोग करता है
      धीमे होने का कारण LLM code quality नहीं बल्कि hardware difference है
      असली core operations वास्तव में PyTorch जैसी ही kernel libraries को call करते हैं
    • मैंने CUDA kernels और 8bit optimizer लिखे हैं, और LLM speed optimization में काफ़ी सक्षम है
      कई प्रयासों और benchmark को दोहराकर तेज़ी से सुधार किया जा सकता है, और कभी-कभी torch की मज़बूत baseline से भी आगे निकला जा सकता है

  • मेरी समझ से यह Salvatore का ML क्षेत्र में पहला OSS project है, तो जानना चाहूँगा कि उन्होंने संबंधित background knowledge कैसे बनाया
    यह भी जानना चाहता हूँ कि क्या Claude ने domain expertise देने में मदद की

    • मुझे पहले से AI के साथ काम करना पसंद रहा है। उदाहरण के लिए मैंने gguf-tools बनाया है
      मैं इतालवी भाषा में एक AI YouTube channel भी चलाता हूँ, जहाँ papers पढ़कर समझाता हूँ
      2003 में मैंने अपना पहला neural network implementation बनाया था, और उसके बाद भी PyTorch या C में छोटे GPT models के साथ प्रयोग करता रहा हूँ
      Redis Vector Sets पर काम करते समय मैंने कई embedding models के साथ काम किया
      Claude की वजह से implementation की रफ़्तार तेज़ हुई, लेकिन बुनियादी concepts पहले से पता थे
      सिर्फ programming background हो और AI का अनुभव बहुत कम हो, तब भी यह संभव हो सकता है, लेकिन ज़्यादा back-and-forth feedback की ज़रूरत पड़ेगी

  • पिछले महीने मैंने इसी तरह के प्रयोग में Qwen 3 Omni को llama.cpp में port किया था
    GGUF conversion, quantization, और input/output modalities को एक हफ्ते में implement किया, लेकिन PR reject हो गया
    संबंधित links: PR #18404, Hugging Face model

    • AI द्वारा लिखा गया unoptimized GGML kernel होने के कारण reject होना अजीब है
      जो लोग manually kernels लिखते हैं, वे अगर model को सही तरह guide करें तो शानदार नतीजे पा सकते हैं
      अगर यह रुझान जारी रहा, तो और तेज़ और बेहतर llama.cpp fork सामने आएँगे

  • यह दिलचस्प है कि OpenBLAS और MPS लगभग एक जैसी speed देते हैं
    README में लिखा है कि GPU का उपयोग सिर्फ MPS करता है

  • अगर मैं Claude से यही काम कराऊँ, तो क्या MIT license लगाकर उस पर अपना नाम लिख सकता हूँ?
    संदर्भ के लिए, Flux2 Apache License का उपयोग करता है
    बड़ा अंतर तो नहीं है, लेकिन ऐसी license details ध्यान खींचती हैं

    • reference code सिर्फ inference pipeline setup दिखाता है, असली core implementation (kernels, transformer आदि) उसमें शामिल नहीं है
    • Claude को C/C++ में inference फिर से implement करने को कहकर MIT license लगा देना सच में बड़ी बात होगी
      लेकिन उसका मतलब तभी है जब वह वास्तव में ठीक से काम भी करे

  • मैं C अच्छी तरह नहीं जानता और मुख्यतः SQL-आधारित analysis करता हूँ, तो जानना चाहता हूँ कि यह code production-grade है या नहीं
    अक्सर सुनता हूँ कि LLM द्वारा बनाया गया code maintain करना कठिन होता है

    • code को सरसरी नज़र से देखने पर यह amateur स्तर का नहीं लगता; enterprise स्तर का तो नहीं, लेकिन काफ़ी ठीक है
    • ऐसी राय अब पुरानी हो चुकी है। Opus 4.5 और CLAUDE.md के स्पष्ट rules को साथ में उपयोग करने पर काफ़ी idiomatic और साफ़-सुथरा code निकल सकता है
      data science tasks में performance कभी-कभी inconsistent रहती है, लेकिन अगर problem definition और input information साफ़ दी जाए, तो अच्छे नतीजे मिल सकते हैं