การอนุมาน Flux 2 Klein ที่เขียนด้วย C ล้วน

 (github.com/antirez)
1 คะแนน โดย GN⁺ 2026-01-19 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • อิมพลีเมนเทชัน C ล้วนสำหรับ สร้างภาพ จากข้อความหรือรูปภาพอินพุตโดยใช้โมเดล FLUX.2-klein-4B
  • ทำงานได้โดยไม่มี dependency ภายนอก และสามารถเร่งความเร็วได้สูงสุด 30 เท่าผ่าน BLAS หรือ Metal แบบเลือกใช้ได้
  • มี ตัวเข้ารหัสข้อความ Qwen3-4B ฝังมาในตัว จึงไม่ต้องมีขั้นตอนคำนวณ embedding แยกต่างหาก
  • รองรับทั้ง text-to-image และ image-to-image พร้อมอินเทอร์เฟซบรรทัดคำสั่งและ C library API
  • รันได้โดยไม่ต้องใช้ Python runtime หรือ PyTorch จึงมีความหมายต่อสภาพแวดล้อมการอนุมานแบบเบาและการขยายการเข้าถึง AI โอเพนซอร์ส

ภาพรวมโครงการ

  • FLUX.2-klein-4B เป็นโมเดลสร้างภาพของ Black Forest Labs ที่รับ text prompt หรือรูปภาพเดิมเป็นอินพุตเพื่อสร้างภาพใหม่
  • โค้ดทั้งหมด เขียนด้วย standard C library เท่านั้น และรองรับการเร่งความเร็วด้วย MPS (Apple Metal) และ BLAS (OpenBLAS) แบบเลือกใช้ได้
  • สามารถดาวน์โหลดโมเดลจาก HuggingFace ได้ขนาดประมาณ 16GB โดยองค์ประกอบมี VAE (300MB), Transformer (4GB), Qwen3-4B encoder (8GB) และ Tokenizer

ความสามารถหลัก

  • Zero dependencies: รันแบบสแตนด์อโลนได้โดยไม่ต้องใช้ไลบรารีภายนอก
    • เมื่อใช้ BLAS จะเร็วขึ้นประมาณ 30 เท่า โดยบน macOS ใช้ Apple Accelerate และบน Linux ใช้ OpenBLAS ได้
  • Metal GPU acceleration: เปิดใช้งานอัตโนมัติบน Apple Silicon
  • Text-to-image: สร้างภาพจาก text prompt
  • Image-to-image: แปลงรูปภาพเดิมตาม prompt
  • Integrated text encoder: มีตัวเข้ารหัส Qwen3-4B ในตัว ไม่ต้องใช้งาน embedding ภายนอก
  • Memory efficient: หลังเข้ารหัสแล้วจะคืนหน่วยความจำของ encoder อัตโนมัติ ช่วยประหยัดได้ประมาณ 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 double blocks และ 20 single blocks, hidden dimension 3072, 24 attention heads
  • VAE: AutoencoderKL, 128 latent channels, บีบอัดเชิงพื้นที่ 8 เท่า
  • Text Encoder: Qwen3-4B, 36 ชั้น, hidden dimension 2560
  • ขั้นตอนการอนุมาน: ใช้การสุ่มตัวอย่าง 4 ขั้นตอนเพื่อสร้างผลลัพธ์คุณภาพสูง
  • ความต้องการหน่วยความจำ
    • การเข้ารหัสข้อความ: ประมาณ 8GB
    • Diffusion: ประมาณ 8GB
    • จุดพีกสูงสุด: 16GB (ก่อนปล่อย encoder)
  • เบนช์มาร์กประสิทธิภาพ (Apple M3 Max, RAM 128GB)
    • 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 ล้วน ไม่มี dependency (ช้า)
  • ดาวน์โหลดโมเดล 
    pip install huggingface_hub
python download_model.py
  • ความละเอียดเอาต์พุตสูงสุด 1024×1024, ต่ำสุด 64×64 และแนะนำให้ใช้ค่าที่เป็นพหุคูณของ 16

C library 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 License
  • สัดส่วนภาษาของคลังเก็บ: 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 เสมอ
    ทุกอย่างที่ค้นพบระหว่างพัฒนาจะถูกสะสมไว้ในไฟล์นี้ อัปเดตให้ล่าสุดอยู่ตลอด และกำหนดให้จัดการทันทีหลังการบีบอัดคอนเท็กซ์
    วิธีนี้ช่วยให้ทำงานโค้ดขนาดใหญ่ได้อย่างมีประสิทธิภาพโดยไม่หลุดจากโฟลว์
    รายละเอียดเพิ่มเติมดูได้ที่ไฟล์ IMPLEMENTATION_NOTES.md บน GitHub

    • เจ๋งมาก หัวใจสำคัญคือ สเปก (spec) ที่อัปเดตต่อเนื่อง
      ฉันเคยพูดถึงแนวทางนี้ไว้ในบทความ vibe-speccing
      อีกอย่างที่มีประโยชน์คือใส่ “บันทึกการทดลอง” ไว้ท้ายสเปก เพื่อจดทุกครั้งที่มีการเปลี่ยนแปลงที่ไม่คาดคิด
    • ถ้าใช้ Beads ของ Steve Yegge ก็ช่วยลดส่วนเกินที่ไม่จำเป็นในไฟล์ Markdown ได้
      อยากรู้ว่าได้ลองรันเบนช์มาร์กหรือยัง และก็น่าสนใจเหมือนกันว่า Python stack เร็วหรือช้ากว่าเครื่องมือ inference ที่ทำบน C
    • สงสัยว่ามีแผนจะเขียนสรุปบทเรียนอื่น ๆ ที่พูดถึงใน README ไหม
      ในฐานะแฟนมานาน ฉันอยากฟัง มุมมอง ของคุณเกี่ยวกับการใช้เครื่องมือแบบนี้
    • อยากรู้ว่าสามารถแชร์ล็อกพรอมป์หรือข้อมูลอื่นนอกจาก implementation notes ที่ใช้ได้ไหม
      ฉันอยากเรียนรู้ กระบวนการทำงาน ของคุณ
    • ใน Claude หรือ LLM ตัวอื่นก็มีโซลูชันที่ทำได้ทั้งการนิยามงาน เพิ่ม implementation notes และ จัดการงานย่อยกับ dependency
      ฉันใช้ Beads อยู่ และคุณภาพผลลัพธ์ดีขึ้นชัดเจน โดยเฉพาะกับโปรเจ็กต์ขนาดใหญ่

  • อ่านแรงจูงใจใน README แล้วน่าสนใจมาก
    ฉันเองก็กำลังลองใส่ไฟล์ PROMPTS.md แบบคล้ายกัน
    ถ้าจุดประสงค์คือการแชร์และการสอน การแสดงให้เห็นว่านักพัฒนาที่มีประสบการณ์ใช้วิธีไหนก็มีประโยชน์มาก
    สามารถใช้ Claude hook เพื่อทำให้สิ่งนี้ คงความเป็น deterministic ได้ ฉันระบุไว้ใน AGENTS.md ว่าให้อ่านได้อย่างเดียว
    มันยังมีประโยชน์ในการส่งต่อบริบทของงานเวลาสลับระหว่าง LLM ต่าง ๆ ด้วย

    • ครั้งนี้ฉันเขียนเอกสารสเปกแทนพรอมป์ แต่หลังจากนั้นก็ยังต้องปรับโมเดลอยู่อีกหลายชั่วโมง
      สุดท้ายแล้วพรอมป์ก็คือผลรวมของปฏิสัมพันธ์เหล่านี้ทั้งหมด จึงยากมากที่จะเรียบเรียงใหม่ให้มีความหมาย

  • เกี่ยวกับการทดลองใช้ LLM เพื่อ transpile ไปเป็นภาษาอื่น อยากรู้ว่าผลลัพธ์และกระบวนการเป็นอย่างไร
    เมื่อไม่นานมานี้ฉันให้ Claude “เขียนใหม่เป็น Rust” สำหรับคอขวดในโปรเจ็กต์หนึ่ง แล้วความเร็วดีขึ้นมาก
    แต่ผลงานที่ได้ยังไม่น่าเชื่อถือพอสำหรับใช้นอกห้องทดลอง

    • แล้วแต่สถานการณ์ ครั้งนี้ฉันทำงานโดยอ้างอิงแค่ โค้ดอ้างอิง ที่ Black Forest Labs ให้มาสำหรับ Flux
      หัวใจสำคัญคือเอเจนต์ต้องเข้าใจได้ว่ากำลังก้าวหน้าไหมผ่านฟีดแบ็ก และต้องดีบักได้โดยเทียบกับ implementation อ้างอิง
      โค้ดทั้งหมดเขียนขึ้นจาก คำใบ้ด้านการติดตั้งใช้งาน ที่ระบุผลลัพธ์ที่ฉันต้องการ
      วันนี้มีคนเอา implementation ของ HNSW vectorset ของฉันไป พอร์ตเป็น Swift แล้ว และรู้สึกดีเพราะใช้ไลเซนส์เดียวกัน
    • ฉันใช้ชุดพรอมป์แนว “ให้ตรวจสอบการเปลี่ยนแปลงโค้ดปัจจุบันจากมุมมองของ ข้อผิดพลาดเชิงตรรกะ”
      แล้วให้ GPT-5.x-Codex ตรวจโค้ดที่ Claude สร้างขึ้นอีกที
      แม้แต่ Opus 4.5 ก็ยังพลาดแบบ off-by-one อยู่ ดังนั้นการใช้โมเดลอื่นเป็น ผู้รีวิวแบบเพื่อนร่วมงาน จึงได้ผลดี
      ลำดับการตรวจสอบของฉันคือ lint → test → โมเดลอื่น → ตัวฉันเอง

  • โมเดล FLUX.2 [klein] ต้นฉบับและโค้ด Python เพิ่งถูกเปิดเผยเมื่อ 3 วันก่อนเท่านั้น
    ดูการพูดคุยที่เกี่ยวข้องได้ ที่นี่

    • สงสัยว่า antirez จะใช้เวลานานแค่ไหนถ้าไม่มี Opus

  • การเขียนด้วย C ไม่ได้แปลว่าจะได้ ประสิทธิภาพระดับ C เสมอไป
    ถ้าดูเบนช์มาร์กจะช้ากว่า PyTorch ถึง 8 เท่า แสดงว่า LLM ยังมีข้อจำกัดในการสร้างโค้ดสมรรถนะสูงระดับนี้

    • เวอร์ชัน PyTorch ใช้ GPU (Metal Performance Shaders) แต่เวอร์ชัน C ใช้เพียง CPU core เดียว
      สาเหตุที่ช้าไม่ได้มาจากคุณภาพโค้ดของ LLM แต่เป็นเพราะ ความต่างของฮาร์ดแวร์
      ตัวโอเปอเรชันแกนกลางจริง ๆ ก็เรียกใช้ไลบรารี kernel เดียวกับ PyTorch
    • ฉันเคยเขียนทั้ง CUDA kernel และ 8bit optimizer มาแล้ว และ LLM ก็เก่งเรื่องการปรับแต่งความเร็วพอสมควร
      มันสามารถลองหลายวิธีแล้ววนเบนช์มาร์กเพื่อปรับปรุงได้เร็ว และบางครั้งก็แซง baseline ที่แข็งแกร่งของ torch ได้ด้วย

  • เท่าที่ทราบ นี่เป็น OSS โปรเจ็กต์แรกของ Salvatore ในสาย ML เลย อยากรู้ว่าไปสร้าง ความรู้พื้นฐาน ด้านนี้มาอย่างไร
    แล้ว Claude ช่วยเติมความเชี่ยวชาญเฉพาะทางให้มากน้อยแค่ไหนก็น่าสนใจ

    • ฉันสนุกกับ AI มาตั้งแต่ก่อนแล้ว เช่น เคยทำ gguf-tools
      ฉันยังทำ ช่อง YouTube ด้าน AI เป็นภาษาอิตาลีด้วย โดยอ่านและอธิบายงานวิจัย
      ฉันสร้าง implementation ของ neural network ตัวแรกในปี 2003 และหลังจากนั้นก็ทดลองกับ GPT ขนาดเล็กด้วย PyTorch หรือ C มาเรื่อย ๆ
      ตอนทำ Redis Vector Sets ก็ได้ทำงานกับ embedding model หลายแบบ
      Claude ช่วยให้ implementation เร็วขึ้น แต่แนวคิดพื้นฐานฉันรู้อยู่แล้ว
      ถ้ามีพื้นฐานด้านโปรแกรมมิงแต่แทบไม่มีประสบการณ์ AI ก็อาจทำได้เหมือนกัน แต่คงต้องมี รอบป้อนกลับไปมา มากกว่านี้

  • เดือนที่แล้วฉันทำการทดลองคล้ายกัน โดยพอร์ต Qwen 3 Omni ไปเป็น llama.cpp
    ฉันทำทั้งการแปลงเป็น GGUF, quantization และโมดาลิตี input/output เสร็จในหนึ่งสัปดาห์ แต่ PR ถูกปฏิเสธ
    ลิงก์ที่เกี่ยวข้อง: PR #18404, โมเดลบน Hugging Face

    • แปลกดีที่ GGML kernel ที่ AI เขียนซึ่ง ยังไม่ได้ optimize เป็นเหตุให้ถูกปฏิเสธ
      ถ้าคนที่เขียน kernel ด้วยมือสามารถชี้นำโมเดลได้ดี ก็อาจได้ผลลัพธ์ที่ยอดเยี่ยม
      ถ้าแนวโน้มนี้ยังไปต่อ เราอาจได้เห็น fork ของ llama.cpp ที่เร็วกว่าและดีกว่าออกมา

  • น่าสนใจที่ OpenBLAS กับ MPS ทำความเร็วได้ใกล้เคียงกันมาก
    ใน README ระบุว่ามีเพียง MPS เท่านั้นที่ใช้ GPU

  • ถ้าฉันให้ Claude ทำงานแบบเดียวกัน จะสามารถติดชื่อฉันแล้วออกเป็นไลเซนส์ MIT ได้ไหม
    อ้างอิง: Flux2 ใช้ Apache License
    มันไม่ได้ต่างกันมาก แต่รายละเอียดเรื่อง ไลเซนส์ แบบนี้ก็ชวนให้กังวลอยู่

    • โค้ดอ้างอิงแสดงแค่การตั้งค่า inference pipeline โดยไม่ได้รวม implementation แกนหลักจริง ๆ (kernel, transformer ฯลฯ) ไว้
    • ถ้าสั่ง Claude ให้ reimplement inference เป็น C/C++ แล้วติด MIT License ก็คงสุดยอดมาก
      แต่จะมีความหมายก็ต่อเมื่อมัน ใช้งานได้จริง

  • ฉันไม่ค่อยรู้ C และทำงานสายวิเคราะห์ด้วย SQL เป็นหลัก เลยสงสัยว่าโค้ดนี้ถือว่า พร้อมใช้ระดับ production ไหม
    ได้ยินบ่อยว่าโค้ดที่ LLM สร้างดูแลรักษายาก

    • ลองไล่ดูโค้ดแล้ว มันไม่ถึงกับระดับมือสมัครเล่น และแม้จะยังไม่ใช่ระดับองค์กร แต่ก็ถือว่าดีทีเดียว
    • มุมมองแบบนั้นค่อนข้างล้าสมัยแล้ว ถ้าใช้ Opus 4.5 ร่วมกับกฎที่ชัดเจนใน CLAUDE.md ก็ได้โค้ดที่ค่อนข้าง ยืดหยุ่นและสะอาด
      งาน data science อาจยังมีความสม่ำเสมอของประสิทธิภาพไม่มากนัก แต่ถ้านิยามปัญหาและให้ข้อมูลนำเข้าชัดเจน ก็ได้ผลลัพธ์ที่ดี