▲

Flux 2 Klein 순수 C 기반 추론

 (github.com/antirez)
1P by GN⁺ 2일전 | ★ favorite | 댓글 1개
  • FLUX.2-klein-4B 모델을 이용해 텍스트나 이미지를 입력으로 이미지를 생성하는 순수 C 구현체
  • 외부 의존성 없이 동작하며, 선택적으로 BLAS 또는 Metal 가속을 통해 최대 30배 속도 향상 가능
  • Qwen3-4B 텍스트 인코더가 내장되어 별도의 임베딩 계산 과정이 필요 없음
  • 텍스트-이미지 및 이미지-이미지 변환을 모두 지원하며, 명령행 인터페이스와 C 라이브러리 API 제공
  • Python 런타임이나 PyTorch 없이도 실행 가능해, 경량 추론 환경과 오픈소스 AI 접근성 확대에 의미

프로젝트 개요

  • FLUX.2-klein-4B는 Black Forest Labs의 이미지 생성 모델로, 텍스트 프롬프트나 기존 이미지를 입력받아 새로운 이미지를 생성
  • 전체 코드가 표준 C 라이브러리만으로 작성되어 있으며, MPS(Apple Metal) 및 BLAS(OpenBLAS) 가속을 선택적으로 지원
  • 모델은 HuggingFace에서 약 16GB 용량으로 다운로드 가능하며, 구성 요소는 VAE(300MB) , Transformer(4GB) , Qwen3-4B 인코더(8GB) , Tokenizer로 구성

주요 기능

  • Zero dependencies: 외부 라이브러리 없이 독립 실행 가능
    • BLAS 사용 시 약 30배 속도 향상, macOS에서는 Apple Accelerate, Linux에서는 OpenBLAS 사용 가능
  • Metal GPU acceleration: Apple Silicon 환경에서 자동 활성화
  • Text-to-image: 텍스트 프롬프트로 이미지 생성
  • Image-to-image: 기존 이미지를 프롬프트에 따라 변환
  • Integrated text encoder: Qwen3-4B 인코더 내장, 외부 임베딩 불필요
  • Memory efficient: 인코딩 후 자동으로 인코더 메모리 해제, 약 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개의 더블 블록과 20개의 싱글 블록, 3072 히든 차원, 24 어텐션 헤드
  • VAE: AutoencoderKL, 128 잠재 채널, 8배 공간 압축
  • Text Encoder: Qwen3-4B, 36층, 2560 히든 차원
  • 추론 단계: 4단계 샘플링으로 고품질 결과 생성
  • 메모리 요구량
    • 텍스트 인코딩: 약 8GB
    • 디퓨전: 약 8GB
    • 최대 피크: 16GB (인코더 해제 전)
  • 성능 벤치마크 (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 백엔드는 매우 느리며 테스트용으로만 적합

빌드 및 실행

  • 백엔드 선택
    • make mps: macOS Apple Silicon (가장 빠름)
    • make blas: Intel Mac 또는 Linux (OpenBLAS 필요)
    • make generic: 순수 C, 의존성 없음 (느림)
  • 모델 다운로드 
    pip install huggingface_hub
python download_model.py
  • 출력 해상도는 최대 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)
  • 이미지 입출력
    • flux_image_load(path) / flux_image_save(img, path)
  • 유틸리티
    • flux_set_seed(seed)로 재현성 확보
    • flux_get_error()로 오류 메시지 확인
    • flux_release_text_encoder(ctx)로 메모리 수동 해제 가능

라이선스 및 기타 정보

  • MIT 라이선스로 공개
  • 저장소 언어 구성: C 93.9% , Objective-C 3.5% , Makefile 1.7% , Python 0.9%
  • 별점 446개, 포크 20개로 활발한 커뮤니티 관심 확보
▲
GN⁺ 2일전  [-]
Hacker News 의견들

  • 이 프로젝트가 가능했던 이유는 Opus에게 IMPLEMENTATION_NOTES.md 파일을 반드시 사용하도록 지시했기 때문임
    개발 중 발견한 모든 사항을 이 파일에 누적하고, 항상 최신 상태로 유지하며, 컨텍스트 압축 후 즉시 처리하도록 명시했음
    이런 방식 덕분에 대규모 코딩 작업을 효율적으로 진행하면서도 흐름을 잃지 않을 수 있었음
    자세한 내용은 GitHub의 IMPLEMENTATION_NOTES.md 파일 참고

    • 멋짐. 지속적으로 업데이트되는 명세(spec) 가 핵심임
      나는 vibe-speccing 글에서 이 접근법을 다뤘음
      또한 명세 하단에 “실험 로그”를 두어, 예상치 못한 변화가 생길 때마다 기록하도록 하는 것도 유용했음
    • Steve Yegge의 Beads를 사용하면 마크다운 파일의 불필요한 부분을 줄일 수 있음
      혹시 벤치마크를 돌려봤는지 궁금함. Python 스택이 C 기반 추론 도구보다 빠른지 느린지도 흥미로움
    • README에서 언급한 다른 교훈들도 글로 정리할 계획이 있는지 궁금함
      오랫동안 팬으로서, 이런 도구를 활용한 당신의 관점을 듣고 싶음
    • 사용한 프롬프트 로그나 구현 노트 외의 자료를 공유할 수 있는지 궁금함
      당신의 작업 과정을 배우고 싶음
    • Claude나 다른 LLM에서도 작업 정의, 구현 노트 추가, 하위 작업 및 의존성 관리가 가능한 솔루션이 있음
      나는 Beads를 쓰고 있는데, 특히 대형 프로젝트에서 결과 품질이 확실히 좋아짐

  • README에서의 동기를 흥미롭게 읽었음
    나도 비슷하게 PROMPTS.md 파일을 포함하려고 시도 중임
    공유와 교육 목적이라면, 숙련된 개발자가 어떤 접근을 쓰는지 보여주는 게 도움이 됨
    Claude hook을 이용해 이를 결정론적으로 유지할 수 있음. AGENTS.md에는 읽기만 가능하도록 명시했음
    LLM 간 전환 시에도 작업 배경을 전달하는 데 유용했음

    • 이번엔 프롬프트 대신 명세서를 작성했지만, 이후 모델을 수 시간 동안 조정해야 했음
      결국 프롬프트는 이런 상호작용의 총합이라, 의미 있게 재구성하기가 매우 어려움

  • LLM을 이용해 다른 언어로 트랜스파일하는 실험에 대해, 결과와 과정이 어땠는지 궁금함
    나도 최근 프로젝트 병목 구간을 Claude에게 “Rust로 다시 써줘”라고 요청했더니 속도가 크게 향상되었음
    다만 결과물이 실험실 외부에서 신뢰할 수준은 아니었음

    • 상황에 따라 다름. 이번엔 Flux의 Black Forest Labs가 제공한 참조 코드만으로 작업했음
      핵심은 에이전트가 피드백을 통해 진척 여부를 이해하고, 참조 구현과 비교하며 디버깅할 수 있어야 함
      모든 코드는 내가 원하는 결과를 명시한 구현 힌트를 기반으로 작성되었음
      오늘 누군가 내 HNSW 벡터셋 구현을 Swift로 포팅했는데, 라이선스가 동일해서 기분이 좋음
    • 나는 “현재 코드 변경을 논리 오류 관점에서 감사하라”는 프롬프트 세트를 사용함
      Claude가 생성한 코드를 GPT-5.x-Codex로 다시 검사함
      Opus 4.5도 여전히 off-by-one 같은 실수를 하므로, 다른 모델을 피어 리뷰어로 쓰면 효과적임
      내 검증 순서는 lint → test → 다른 모델 → 나 순서로 진행됨

  • 원본 FLUX.2 [klein] 모델과 Python 코드는 불과 3일 전에 공개되었음
    관련 논의는 이곳 참고

    • Opus 없이 antirez가 얼마나 걸렸을지 궁금함

  • C로 작성됐다고 해서 반드시 C 수준의 성능을 내는 건 아님
    벤치마크를 보면 PyTorch보다 8배 느림. LLM이 이런 수준의 고성능 코드를 생성하기엔 아직 한계가 있음

    • PyTorch 버전은 GPU(Metal Performance Shaders)를 사용하지만, C 버전은 단일 CPU 코어만 사용함
      느린 이유는 LLM 코드 품질이 아니라 하드웨어 차이 때문임
      실제 핵심 연산은 PyTorch와 동일한 커널 라이브러리를 호출함
    • 나는 CUDA 커널과 8bit 옵티마이저를 작성해봤는데, LLM이 속도 최적화에 꽤 능함
      여러 시도와 벤치마크를 반복해 빠르게 개선하며, torch의 강력한 기준선도 능가한 적이 있음

  • Salvatore가 ML 분야 첫 OSS 프로젝트를 진행한 걸로 아는데, 관련 배경 지식은 어떻게 쌓았는지 궁금함
    Claude가 도메인 전문성을 제공하는 데 도움이 되었는지도 알고 싶음

    • 예전부터 AI를 즐겨 다뤘음. 예를 들어 gguf-tools를 만든 적 있음
      이탈리아어로 진행하는 AI 유튜브 채널도 운영 중이며, 논문을 읽고 해설함
      2003년에 첫 신경망 구현을 만들었고, 이후에도 PyTorch나 C로 소형 GPT 모델을 계속 실험해왔음
      Redis Vector Sets 작업을 하며 다양한 임베딩 모델을 다뤘음
      Claude 덕분에 구현 속도는 빨랐지만, 기본 개념은 이미 알고 있었음
      프로그래밍 배경만 있고 AI 경험이 거의 없는 경우에도 가능하겠지만, 더 많은 왕복 피드백이 필요할 것 같음

  • 지난달 비슷한 실험으로 Qwen 3 Omni를 llama.cpp로 포팅했음
    GGUF 변환, 양자화, 입출력 모달리티를 일주일 만에 구현했지만, PR은 거절당했음
    관련 링크: PR #18404, Hugging Face 모델

    • AI가 작성한 GGML 커널이 비최적화되어 거절된 건 이상함
      수동으로 커널을 작성하는 사람이 모델을 잘 유도하면 훌륭한 결과를 낼 수 있음
      이런 흐름이 계속되면, 더 빠르고 나은 llama.cpp 포크가 등장할 것임

  • OpenBLAS와 MPS가 거의 같은 속도를 낸다는 점이 흥미로움
    README에는 GPU를 사용하는 건 MPS뿐이라고 되어 있음

  • Claude에게 같은 작업을 시키면 MIT 라이선스로 내 이름을 붙여도 되는지 궁금함
    참고로 Flux2는 Apache License를 사용함
    큰 차이는 없지만, 이런 라이선스 세부사항이 신경 쓰임

    • 참조 코드는 추론 파이프라인 설정만 보여주며, 실제 핵심 구현(커널, 트랜스포머 등) 은 포함되어 있지 않음
    • Claude에게 C/C++로 추론을 재구현하도록 지시하고 MIT 라이선스를 붙인다면 정말 대단할 것임
      단, 실제로 정상 작동해야 의미가 있음

  • 나는 C를 잘 모르고 주로 SQL 기반 분석을 하는데, 이 코드가 프로덕션급인지 궁금함
    LLM이 만든 코드는 유지보수하기 어렵다는 말을 자주 들었음

    • 코드를 훑어보니 아마추어 수준은 아니고, 기업용 수준은 아니지만 꽤 괜찮음
    • 그런 평가는 구식임. Opus 4.5와 CLAUDE.md의 명확한 규칙을 함께 쓰면 꽤 관용적이고 깔끔한 코드가 나옴
      데이터 사이언스 작업에서는 성능이 들쭉날쭉하지만, 문제 정의와 입력 정보를 명확히 주면 좋은 결과를 얻을 수 있음
답변달기