Suy luận thuần C cho Flux 2 Klein

 (github.com/antirez)
1 điểm bởi GN⁺ 2026-01-19 | 1 bình luận | Chia sẻ qua WhatsApp
  • Bản triển khai thuần C sử dụng mô hình FLUX.2-klein-4B để tạo ảnh từ văn bản hoặc ảnh đầu vào
  • Hoạt động không cần phụ thuộc bên ngoài, và có thể tăng tốc lên tới 30 lần thông qua BLAS hoặc Metal tùy chọn
  • Bộ mã hóa văn bản Qwen3-4B được tích hợp sẵn nên không cần quy trình tính embedding riêng
  • Hỗ trợ cả text-to-image và image-to-image, đồng thời cung cấp giao diện dòng lệnh và API thư viện C
  • Có thể chạy mà không cần Python runtime hay PyTorch, mang ý nghĩa mở rộng khả năng tiếp cận AI mã nguồn mở và môi trường suy luận nhẹ

Tổng quan dự án

  • FLUX.2-klein-4B là mô hình tạo ảnh của Black Forest Labs, nhận prompt văn bản hoặc ảnh có sẵn làm đầu vào để tạo ảnh mới
  • Toàn bộ mã được viết chỉ bằng thư viện chuẩn C, đồng thời hỗ trợ tăng tốc MPS (Apple Metal) và BLAS (OpenBLAS) dưới dạng tùy chọn
  • Mô hình có thể tải từ HuggingFace với dung lượng khoảng 16GB, gồm các thành phần VAE(300MB), Transformer(4GB), bộ mã hóa Qwen3-4B(8GB) và Tokenizer

Tính năng chính

  • Zero dependencies: có thể chạy độc lập mà không cần thư viện ngoài
    • Khi dùng BLAS, tốc độ tăng khoảng 30 lần; trên macOS có thể dùng Apple Accelerate, trên Linux có thể dùng OpenBLAS
  • Metal GPU acceleration: tự động kích hoạt trong môi trường Apple Silicon
  • Text-to-image: tạo ảnh từ prompt văn bản
  • Image-to-image: biến đổi ảnh có sẵn theo prompt
  • Integrated text encoder: tích hợp bộ mã hóa Qwen3-4B, không cần embedding bên ngoài
  • Memory efficient: tự động giải phóng bộ nhớ của encoder sau khi mã hóa, tiết kiệm khoảng 8GB

Ví dụ sử dụng

  • Tạo ảnh từ văn bản 
    ./flux -d flux-klein-model -p "A fluffy orange cat sitting on a windowsill" -o cat.png
  • Biến đổi ảnh 
    ./flux -d flux-klein-model -i photo.png -o painting.png -p "oil painting style" -t 0.7
    • Giá trị -t điều khiển cường độ biến đổi; 0.0 giữ nguyên ảnh gốc, 1.0 là tái tạo hoàn toàn

Cấu trúc mô hình và hiệu năng

  • Transformer: 5 khối kép và 20 khối đơn, chiều ẩn 3072, 24 attention head
  • VAE: AutoencoderKL, 128 kênh latent, nén không gian 8 lần
  • Text Encoder: Qwen3-4B, 36 lớp, chiều ẩn 2560
  • Bước suy luận: lấy mẫu 4 bước để tạo kết quả chất lượng cao
  • Yêu cầu bộ nhớ
    • Mã hóa văn bản: khoảng 8GB
    • Diffusion: khoảng 8GB
    • Mức đỉnh tối đa: 16GB (trước khi giải phóng encoder)
  • Benchmark hiệu năng (Apple M3 Max, RAM 128GB)
    • 512×512: MPS 49.6 giây, BLAS 51.9 giây, PyTorch MPS 5.4 giây
    • 256×256: MPS 32.4 giây, BLAS 29.7 giây, PyTorch MPS 3.0 giây
    • 64×64: MPS 25.0 giây, BLAS 23.5 giây, PyTorch MPS 2.2 giây
    • Backend thuần C rất chậm và chỉ phù hợp để thử nghiệm

Build và chạy

  • Chọn backend
    • make mps: macOS Apple Silicon (nhanh nhất)
    • make blas: Intel Mac hoặc Linux (cần OpenBLAS)
    • make generic: thuần C, không phụ thuộc (chậm)
  • Tải mô hình 
    pip install huggingface_hub
python download_model.py
  • Độ phân giải đầu ra tối đa 1024×1024, tối thiểu 64×64, khuyến nghị là bội số của 16

API thư viện C

  • Tải và giải phóng mô hình
    • flux_load_dir(path) / flux_free(ctx)
  • Tạo và biến đổi ảnh
    • flux_generate(ctx, prompt, params)
    • flux_img2img(ctx, prompt, input, params)
  • Nhập/xuất ảnh
    • flux_image_load(path) / flux_image_save(img, path)
  • Tiện ích
    • flux_set_seed(seed) để đảm bảo khả năng tái lập
    • flux_get_error() để kiểm tra thông báo lỗi
    • flux_release_text_encoder(ctx) để giải phóng bộ nhớ thủ công

Giấy phép và thông tin khác

  • Phát hành theo giấy phép MIT
  • Cấu trúc ngôn ngữ của kho lưu trữ: C 93.9%, Objective-C 3.5%, Makefile 1.7%, Python 0.9%
  • 446 sao, 20 fork, cho thấy mức độ quan tâm tích cực từ cộng đồng

Bài viết liên quan

1 bình luận

 
GN⁺ 2026-01-19
Bình luận Hacker News

  • Dự án này khả thi là vì đã chỉ thị cho Opus bắt buộc phải dùng tệp IMPLEMENTATION_NOTES.md
    Mọi phát hiện trong quá trình phát triển đều được tích lũy vào tệp này, luôn giữ ở trạng thái mới nhất, và quy định phải xử lý ngay sau khi nén ngữ cảnh
    Nhờ cách làm này, có thể tiến hành các tác vụ lập trình quy mô lớn một cách hiệu quả mà vẫn không bị mất mạch
    Xem chi tiết trong tệp IMPLEMENTATION_NOTES.md trên GitHub

    • Tuyệt. Đặc tả (spec) được cập nhật liên tục mới là cốt lõi
      Tôi đã đề cập cách tiếp cận này trong bài vibe-speccing
      Ngoài ra, cũng hữu ích khi đặt một phần “nhật ký thử nghiệm” ở cuối đặc tả để ghi lại mỗi khi có thay đổi ngoài dự kiến
    • Dùng Beads của Steve Yegge thì có thể giảm bớt những phần không cần thiết trong tệp Markdown
      Cũng tò mò không biết đã chạy benchmark chưa. Việc stack Python nhanh hơn hay chậm hơn so với công cụ suy luận dựa trên C cũng rất đáng quan tâm
    • Tôi cũng muốn biết liệu có định viết thành bài về các bài học khác được nhắc trong README không
      Là fan lâu năm, tôi muốn nghe góc nhìn của bạn về việc sử dụng những công cụ như thế này
    • Tôi muốn biết liệu có thể chia sẻ log prompt hoặc tài liệu nào khác ngoài ghi chú triển khai không
      Tôi muốn học quy trình làm việc của bạn
    • Trong Claude hay các LLM khác cũng có các giải pháp cho việc xác định công việc, thêm ghi chú triển khai, và quản lý tác vụ con cùng phụ thuộc
      Tôi đang dùng Beads, và chất lượng kết quả thực sự tốt hơn hẳn, đặc biệt với các dự án lớn

  • Tôi thấy phần động cơ trong README rất thú vị
    Tôi cũng đang thử đưa tệp PROMPTS.md vào theo cách tương tự
    Nếu mục tiêu là chia sẻ và giáo dục, thì việc cho thấy một lập trình viên lành nghề dùng cách tiếp cận nào sẽ rất hữu ích
    Có thể dùng Claude hook để giữ điều này mang tính xác định. Trong AGENTS.md tôi đã ghi rõ là chỉ được đọc
    Nó cũng hữu ích để truyền đạt bối cảnh công việc khi chuyển đổi giữa các LLM

    • Lần này tôi viết đặc tả thay vì prompt, nhưng sau đó vẫn phải điều chỉnh mô hình trong nhiều giờ
      Cuối cùng thì prompt là tổng hòa của những tương tác như vậy, nên rất khó tái cấu trúc nó theo cách có ý nghĩa

  • Về các thử nghiệm dùng LLM để transpile sang ngôn ngữ khác, tôi muốn biết kết quả và quá trình ra sao
    Gần đây tôi cũng bảo Claude “viết lại bằng Rust” cho đoạn nghẽn của một dự án, và tốc độ đã tăng lên đáng kể
    Tuy nhiên, kết quả vẫn chưa đủ đáng tin để dùng ngoài môi trường phòng thí nghiệm

    • Còn tùy tình huống. Lần này tôi chỉ làm việc với mã tham chiếu do Black Forest Labs cung cấp cho Flux
      Điểm mấu chốt là agent phải có khả năng hiểu được tiến độ thông qua phản hồi, và có thể debug bằng cách so sánh với triển khai tham chiếu
      Toàn bộ mã được viết dựa trên gợi ý triển khai mô tả chính xác kết quả tôi muốn
      Hôm nay có người port phần triển khai vector set HNSW của tôi sang Swift, và tôi thấy rất vui vì giấy phép giống nhau
    • Tôi dùng một bộ prompt kiểu “hãy audit thay đổi mã hiện tại dưới góc độ lỗi logic”
      Mã do Claude sinh ra sẽ được kiểm tra lại bằng GPT-5.x-Codex
      Ngay cả Opus 4.5 vẫn mắc lỗi kiểu off-by-one, nên dùng mô hình khác làm người phản biện đồng cấp rất hiệu quả
      Trình tự xác minh của tôi là lint → test → mô hình khác → tôi

  • Mô hình FLUX.2 [klein] gốc và mã Python mới chỉ được công bố cách đây 3 ngày
    Thảo luận liên quan xem tại đây

    • Tôi tò mò nếu không có Opus thì antirez sẽ mất bao lâu

  • Viết bằng C không có nghĩa là chắc chắn đạt hiệu năng kiểu C
    Theo benchmark thì nó chậm hơn PyTorch 8 lần. LLM hiện vẫn còn giới hạn khi tạo ra mã hiệu năng cao ở mức này

    • Phiên bản PyTorch dùng GPU (Metal Performance Shaders), còn phiên bản C chỉ dùng một lõi CPU duy nhất
      Lý do chậm không phải do chất lượng mã của LLM mà là do khác biệt phần cứng
      Các phép toán cốt lõi thực tế vẫn gọi cùng thư viện kernel như PyTorch
    • Tôi từng viết CUDA kernel và optimizer 8bit, và LLM khá giỏi trong việc tối ưu tốc độ
      Nó cải thiện rất nhanh qua nhiều vòng thử và benchmark, thậm chí có lúc còn vượt cả baseline rất mạnh của torch

  • Tôi biết đây là dự án OSS đầu tiên của Salvatore trong lĩnh vực ML, nên muốn hỏi anh ấy đã xây dựng kiến thức nền liên quan như thế nào
    Tôi cũng muốn biết liệu Claude có giúp cung cấp chuyên môn miền hay không

    • Tôi vốn đã thích mày mò AI từ trước. Ví dụ tôi từng làm gguf-tools
      Tôi cũng đang vận hành một kênh YouTube về AI bằng tiếng Ý, nơi tôi đọc và giải thích các bài báo
      Năm 2003 tôi đã tạo bản triển khai mạng nơ-ron đầu tiên của mình, và từ đó đến nay vẫn liên tục thử nghiệm các mô hình GPT nhỏ bằng PyTorch hoặc C
      Khi làm Redis Vector Sets, tôi đã làm việc với nhiều mô hình embedding khác nhau
      Claude giúp tăng tốc triển khai, nhưng các khái niệm nền tảng thì tôi đã biết sẵn
      Có lẽ ngay cả người chỉ có nền tảng lập trình và gần như không có kinh nghiệm AI cũng làm được, nhưng sẽ cần nhiều vòng phản hồi qua lại hơn

  • Tháng trước tôi cũng làm một thử nghiệm tương tự, port Qwen 3 Omni sang llama.cpp
    Tôi đã triển khai chuyển đổi GGUF, lượng tử hóa, và các modality đầu vào/đầu ra chỉ trong một tuần, nhưng PR đã bị từ chối
    Liên kết liên quan: PR #18404, mô hình Hugging Face

    • Việc một GGML kernel do AI viết bị từ chối vì chưa tối ưu nghe khá lạ
      Một người tự viết kernel nếu hướng dẫn mô hình tốt thì vẫn có thể cho ra kết quả rất xuất sắc
      Nếu xu hướng này tiếp diễn, sẽ xuất hiện các fork llama.cpp nhanh hơn và tốt hơn

  • Điều thú vị là OpenBLAS và MPS cho tốc độ gần như ngang nhau
    README nói rằng chỉ có MPS là dùng GPU

  • Tôi tò mò nếu bảo Claude làm cùng tác vụ đó thì có được gắn tên tôi và phát hành dưới giấy phép MIT hay không
    Tham khảo thêm, Flux2 dùng Apache License
    Khác biệt không lớn lắm, nhưng những chi tiết giấy phép như vậy vẫn khiến tôi băn khoăn

    • Mã tham chiếu chỉ cho thấy cách thiết lập pipeline suy luận, chứ không bao gồm phần triển khai cốt lõi (kernel, transformer, v.v.)
    • Nếu bảo Claude tái triển khai suy luận bằng C/C++ rồi gắn giấy phép MIT thì đúng là rất ấn tượng
      Dĩ nhiên, chỉ có ý nghĩa nếu nó thực sự hoạt động đúng

  • Tôi không rành C, chủ yếu làm phân tích dựa trên SQL, nên muốn biết liệu đoạn mã này có đạt mức production hay không
    Tôi thường nghe nói mã do LLM tạo ra rất khó bảo trì

    • Tôi lướt qua mã rồi, không phải mức nghiệp dư, chưa đến mức doanh nghiệp, nhưng khá ổn
    • Cách đánh giá đó đã lỗi thời rồi. Nếu dùng Opus 4.5 cùng với các quy tắc rõ ràng trong CLAUDE.md thì có thể cho ra mã khá tự nhiên và gọn gàng
      Trong các tác vụ data science thì hiệu năng vẫn hơi thất thường, nhưng nếu mô tả vấn đề và cung cấp thông tin đầu vào rõ ràng thì vẫn có thể đạt kết quả tốt