Inferencia de Flux 2 Klein en C puro

 (github.com/antirez)
1 puntos por GN⁺ 2026-01-19 | 1 comentarios | Compartir por WhatsApp
  • Implementación en C puro que usa el modelo FLUX.2-klein-4B para generar imágenes a partir de texto o imágenes de entrada
  • Funciona sin dependencias externas y, opcionalmente, puede lograr hasta 30 veces más velocidad mediante aceleración con BLAS o Metal
  • Incluye el codificador de texto Qwen3-4B, por lo que no se requiere un proceso separado de cálculo de embeddings
  • Soporta tanto texto a imagen como imagen a imagen, y ofrece una interfaz de línea de comandos y una API de biblioteca en C
  • Puede ejecutarse sin Python runtime ni PyTorch, lo que lo vuelve relevante para entornos de inferencia livianos y para ampliar el acceso al AI de código abierto

Resumen del proyecto

  • FLUX.2-klein-4B es un modelo de generación de imágenes de Black Forest Labs que recibe prompts de texto o imágenes existentes como entrada para generar nuevas imágenes
  • Todo el código está escrito solo con la biblioteca estándar de C, y soporta de forma opcional aceleración con MPS (Apple Metal) y BLAS (OpenBLAS)
  • El modelo puede descargarse desde HuggingFace con un tamaño aproximado de 16GB, y sus componentes son VAE (300MB), Transformer (4GB), codificador Qwen3-4B (8GB) y Tokenizer

Funciones principales

  • Zero dependencies: puede ejecutarse de forma independiente sin bibliotecas externas
    • Al usar BLAS, obtiene una mejora de velocidad de unas 30 veces; en macOS puede usar Apple Accelerate y en Linux OpenBLAS
  • Metal GPU acceleration: se activa automáticamente en entornos Apple Silicon
  • Text-to-image: genera imágenes a partir de prompts de texto
  • Image-to-image: transforma imágenes existentes según el prompt
  • Integrated text encoder: incluye el codificador Qwen3-4B, sin necesidad de embeddings externos
  • Memory efficient: tras la codificación libera automáticamente la memoria del codificador, ahorrando unos 8GB

Ejemplos de uso

  • Generación de imagen desde texto 
    ./flux -d flux-klein-model -p "A fluffy orange cat sitting on a windowsill" -o cat.png
  • Transformación de imagen 
    ./flux -d flux-klein-model -i photo.png -o painting.png -p "oil painting style" -t 0.7
    • El valor de -t controla la intensidad de la transformación: 0.0 mantiene el original y 1.0 lo regenera por completo

Estructura del modelo y rendimiento

  • Transformer: 5 bloques dobles y 20 bloques simples, dimensión oculta de 3072 y 24 cabezas de atención
  • VAE: AutoencoderKL, 128 canales latentes, compresión espacial de 8 veces
  • Text Encoder: Qwen3-4B, 36 capas, dimensión oculta de 2560
  • Pasos de inferencia: genera resultados de alta calidad con muestreo de 4 pasos
  • Requisitos de memoria
    • Codificación de texto: aprox. 8GB
    • Difusión: aprox. 8GB
    • Pico máximo: 16GB (antes de liberar el codificador)
  • Benchmark de rendimiento (Apple M3 Max, 128GB RAM)
    • 512×512: MPS 49.6 s, BLAS 51.9 s, PyTorch MPS 5.4 s
    • 256×256: MPS 32.4 s, BLAS 29.7 s, PyTorch MPS 3.0 s
    • 64×64: MPS 25.0 s, BLAS 23.5 s, PyTorch MPS 2.2 s
    • El backend en C puro es muy lento y solo es adecuado para pruebas

Compilación y ejecución

  • Selección de backend
    • make mps: macOS Apple Silicon (el más rápido)
    • make blas: Intel Mac o Linux (requiere OpenBLAS)
    • make generic: C puro, sin dependencias (lento)
  • Descarga del modelo 
    pip install huggingface_hub
python download_model.py
  • La resolución de salida puede ser de hasta 1024×1024, mínimo 64×64, y se recomiendan múltiplos de 16

API de la biblioteca en C

  • Carga y liberación del modelo
    • flux_load_dir(path) / flux_free(ctx)
  • Generación y transformación de imágenes
    • flux_generate(ctx, prompt, params)
    • flux_img2img(ctx, prompt, input, params)
  • Entrada/salida de imágenes
    • flux_image_load(path) / flux_image_save(img, path)
  • Utilidades
    • flux_set_seed(seed) para asegurar reproducibilidad
    • flux_get_error() para revisar mensajes de error
    • flux_release_text_encoder(ctx) permite liberar memoria manualmente

Licencia y otra información

  • Publicado bajo licencia MIT
  • Composición de lenguajes del repositorio: C 93.9%, Objective-C 3.5%, Makefile 1.7%, Python 0.9%
  • Con 446 estrellas y 20 forks, ha captado un activo interés de la comunidad

Lecturas relacionadas

1 comentarios

 
GN⁺ 2026-01-19
Comentarios en Hacker News

  • Este proyecto fue posible porque se le indicó a Opus que usara obligatoriamente el archivo IMPLEMENTATION_NOTES.md
    Se especificó que todo lo descubierto durante el desarrollo debía acumularse en ese archivo, mantenerse siempre actualizado y procesarse de inmediato tras la compresión de contexto
    Gracias a este método, fue posible avanzar de forma eficiente en una tarea de programación grande sin perder el hilo
    Para más detalles, ver el archivo IMPLEMENTATION_NOTES.md en GitHub

    • Genial. La clave es una spec que se actualice continuamente
      Yo hablé de este enfoque en el artículo sobre vibe-speccing
      También me resultó útil poner un “registro de experimentos” al final de la spec, para anotar cualquier cambio inesperado a medida que surgía
    • Con Beads de Steve Yegge se puede reducir la parte innecesaria de los archivos markdown
      Me pregunto si corriste benchmarks. También sería interesante saber si el stack de Python es más rápido o más lento que una herramienta de inferencia basada en C
    • Me pregunto si planeas escribir también sobre las otras lecciones mencionadas en el README
      Como fan desde hace mucho tiempo, me gustaría conocer tu perspectiva usando este tipo de herramientas
    • Me pregunto si podrías compartir materiales además del log de prompts o las notas de implementación
      Me gustaría aprender de tu proceso de trabajo
    • También hay soluciones en Claude u otros LLM para definir tareas, agregar notas de implementación y gestionar subtareas y dependencias
      Yo uso Beads y la calidad de los resultados mejora claramente, especialmente en proyectos grandes

  • Me pareció interesante la motivación explicada en el README
    Yo también estoy intentando incluir un archivo PROMPTS.md
    Si es con fines de compartir y enseñar, ayuda mostrar qué enfoque usa un desarrollador experimentado
    Con un hook de Claude se puede mantener esto de forma determinista. En AGENTS.md indiqué que solo puede leerse
    También me resultó útil para transmitir el contexto de una tarea al cambiar entre distintos LLM

    • Esta vez escribí una spec en lugar de prompts, pero luego tuve que ajustar el modelo durante varias horas
      Al final, los prompts son la suma de todas esas interacciones, así que es muy difícil reconstruirlos de una forma que tenga sentido

  • Sobre los experimentos usando LLM para transpilar a otros lenguajes, me da curiosidad cómo fueron el resultado y el proceso
    Yo también le pedí hace poco a Claude que “lo reescribiera en Rust” para un cuello de botella de un proyecto, y la velocidad mejoró bastante
    Pero el resultado todavía no era lo bastante confiable como para usarlo fuera del laboratorio

    • Depende del caso. Esta vez se trabajó solo con el código de referencia proporcionado por Black Forest Labs para Flux
      La clave es que el agente pueda entender si está avanzando mediante feedback y depurar comparando con la implementación de referencia
      Todo el código fue escrito a partir de pistas de implementación que especificaban el resultado que yo quería
      Hoy alguien porteó a Swift mi implementación de conjuntos de vectores HNSW, y me alegró ver que usa la misma licencia
    • Yo uso un conjunto de prompts del tipo “audita el cambio actual de código desde la perspectiva de errores lógicos”
      Vuelvo a revisar el código generado por Claude con GPT-5.x-Codex
      Incluso Opus 4.5 sigue cometiendo errores tipo off-by-one, así que usar otro modelo como peer reviewer funciona bien
      Mi orden de validación es: lint → test → otro modelo → yo

  • El modelo FLUX.2 [klein] original y el código en Python se publicaron hace apenas 3 días
    La discusión relacionada está aquí

    • Me pregunto cuánto le habría tomado a antirez sin Opus

  • Que esté escrito en C no significa necesariamente que tenga rendimiento de nivel C
    Los benchmarks muestran que es 8 veces más lento que PyTorch. Los LLM todavía tienen límites para generar código de tan alto rendimiento

    • La versión en PyTorch usa GPU (Metal Performance Shaders), pero la versión en C usa solo un núcleo de CPU
      La razón de la lentitud no es la calidad del código del LLM, sino la diferencia de hardware
      De hecho, las operaciones centrales llaman a la misma biblioteca de kernels que PyTorch
    • Yo he escrito kernels CUDA y optimizadores de 8 bits, y los LLM son bastante buenos para optimizar velocidad
      Mejoran rápido tras varios intentos y benchmarks repetidos, e incluso alguna vez superaron la sólida línea base de torch

  • Entiendo que es el primer proyecto OSS de Salvatore en el área de ML, y me da curiosidad cómo construyó ese conocimiento de base
    También quiero saber si Claude ayudó aportando especialización en el dominio

    • Desde hace tiempo disfruto trabajar con IA. Por ejemplo, hice gguf-tools
      También llevo un canal de YouTube sobre IA en italiano, donde leo papers y los explico
      En 2003 hice mi primera implementación de una red neuronal, y desde entonces seguí experimentando con modelos GPT pequeños en PyTorch o en C
      Al trabajar en Redis Vector Sets, traté con varios modelos de embeddings
      Claude aceleró la velocidad de implementación, pero los conceptos básicos ya los conocía
      Probablemente también sea posible si solo tienes experiencia en programación y casi nada de IA, pero haría falta mucho más ida y vuelta de feedback

  • El mes pasado hice un experimento parecido portando Qwen 3 Omni a llama.cpp
    Implementé en una semana la conversión a GGUF, la cuantización y las modalidades de entrada/salida, pero rechazaron el PR
    Enlaces relacionados: PR #18404, modelo en Hugging Face

    • Es raro que lo hayan rechazado porque los kernels de GGML escritos por IA estaban sin optimizar
      Si alguien que escribe kernels manualmente guía bien al modelo, puede lograr resultados excelentes
      Si esta tendencia sigue, van a aparecer forks de llama.cpp más rápidos y mejores

  • Es interesante que OpenBLAS y MPS den velocidades casi iguales
    En el README dice que MPS es lo único que usa GPU

  • Me pregunto si, si le pido la misma tarea a Claude, puedo ponerle licencia MIT con mi nombre
    Como referencia, Flux2 usa licencia Apache License
    No es una diferencia enorme, pero este tipo de detalles de licencia sí me importan

    • El código de referencia solo muestra cómo configurar el pipeline de inferencia, y no incluye la implementación central real (kernels, transformer, etc.)
    • Si le indicas a Claude que reimplemente la inferencia en C/C++ y le pones licencia MIT, sería realmente impresionante
      Pero solo tendría sentido si de verdad funciona correctamente

  • No sé mucho de C y me dedico más que nada al análisis basado en SQL, así que me pregunto si este código es de nivel producción
    A menudo se dice que el código hecho por LLM es difícil de mantener

    • Viendo el código por encima, no parece de nivel amateur; no llega a nivel corporativo, pero está bastante bien
    • Esa evaluación ya está algo anticuada. Si usas Opus 4.5 junto con reglas claras en CLAUDE.md, puede salir código bastante idiomático y limpio
      En tareas de ciencia de datos el rendimiento es irregular, pero si defines bien el problema y das información de entrada clara, se pueden obtener buenos resultados