Imágenes caseras con ComfyUI
Generar una imagen con un servicio en línea cuesta poco, pero cuesta cada vez. Se paga en créditos que se agotan a mitad de mes, en planes gratuitos que se recargan cuando deciden ellos, en reglas sobre qué se puede pedir y qué no establecidas por un tercero. Midjourney, DALL-E y Firefly son herramientas extraordinarias, pero comparten la naturaleza del alquiler: la casa es espléndida, pero no es mía. De ahí partió este experimento, nacido como prueba personal y convertido en artículo por el camino. Quería entender si se pueden producir imágenes sin coste por disparo, sin contadores que bajen y sin límites de crédito, utilizando únicamente el ordenador que tengo sobre la mesa.
Había oído hablar de ComfyUI hace tiempo, luego el nombre se deslizó fuera del radar, como ocurre con las cosas leídas una sola vez. Me lo volví a encontrar en los últimos días consultando, en busca de ideas, la wiki de LLM que actualizo con Matteo Baccan, un archivo donde incorporamos a diario noticias sobre el mundo de la IA, en el repositorio AINews. Un archivo bien hecho sirve para esto: os devuelve lo que habíais olvidado que habíais olvidado. La promesa era seductora: un control granular sobre cada paso de la generación, sin suscripciones y sin créditos mensuales. La verdadera pregunta, sin embargo, era otra: ¿mi máquina podrá con ello?
La máquina es la misma descrita en la primera entrega sobre la IA en casa: un Ryzen 7700, 32 GB de RAM DDR5 y una Radeon RX 9060 XT con 16 GB de memoria de vídeo. Nada exótico, un hardware que muchos aficionados reconocerían como propio. Tiene, sin embargo, una característica que en las próximas páginas pesa bastante: la tarjeta es AMD, no NVIDIA, y quien siga este mundo sabe que la diferencia no es un detalle de fanboy sino una variable técnica.
Nodos, errores y SD 1.5
Instalé ComfyUI Desktop en Windows, atraído por la sencillez respecto a la versión portable. La documentación oficial lo indica para Windows 10 o posterior con GPU NVIDIA o AMD, y ver a AMD citada de forma natural ya fue una buena noticia. La primera impresión con la interfaz fue de una curiosa familiaridad: un lienzo lleno de bloques conectados por cables es la gramática exacta de n8n, la herramienta de automatización que conozco y utilizo para algunos procesos. Cambia el contenido de los bloques, no la idea de fondo, porque cada nodo recibe algo, lo transforma y lo pasa al siguiente.
ComfyUI, para quien no lo conozca, es un programa de código abierto que transforma la generación de imágenes en una cadena de montaje: cada fase del proceso es un bloque, y depende de quien lo usa decidir cuáles conectar y en qué orden.
Para no empezar a ciegas le pedí a la versión gratuita de DeepSeek una guía paso a paso, desde la instalación hasta el primer flujo de trabajo. Me resultó útil pero un poco confusa, porque llegó toda de golpe en lugar de paso a paso, y describía los bloques con nombres en inglés mientras mi ComfyUI los mostraba en italiano. Cuánto de lo que ocurrió después fue culpa de la guía y cuánto mía por intercambiar nodos con nombres parecidos, no sabría decirlo con honestidad. Probablemente haya un poco de ambas cosas.
El primer tropiezo concreto estuvo relacionado con los modelos. ¿Dónde hay que ponerlos? Busqué en la carpeta de instalación dentro de Program Files, la que parecía obvia, y la encontré vacía. Los modelos viven en otro lugar, en una carpeta compartida dentro del perfil de usuario (en mi caso bajo LOCAL/APPDATA, en Comfy-Desktop y luego ComfyUI-Shared, dentro de models). Un detalle lógico a posteriori e invisible a priori. El segundo tropiezo fue más psicológico: ante los miles de modelos en Hugging Face y Civitai sentí la sensación de entrar en una biblioteca sin catálogo. Decidí empezar por el más ligero y directo, Stable Diffusion 1.5, en el archivo v1-5-pruned-emaonly-fp16.safetensors. Es un modelo de 2022 y se nota. La ficha oficial del modelo lo sitúa bajo licencia CreativeML OpenRAIL-M, y la organización que lo aloja se presenta hoy básicamente como custodia de modelos legados de Stable Diffusion.
Construí el primer flujo bloque a bloque para entender su lógica. Load Checkpoint carga el modelo. CLIP Text Encode traduce mi texto a números comprensibles para la máquina, una especie de intérprete simultáneo. Empty Latent Image es el lienzo de partida, que no es blanco sino que está lleno de ruido, con las dimensiones de la imagen final. KSampler es el núcleo, porque parte del ruido y lo limpia paso a paso hasta que emerge algo reconocible, el principio de la difusión sobre el que ya he escrito. VAE Decode traduce del lenguaje interno del modelo a píxeles reales y Save Image los guarda en el disco.
El error de principiante llegó puntual: KeyError: 'g'. El mensaje citaba un campo, tokens["g"], que existe únicamente en los modelos SDXL. Había colocado CLIPTextEncodeSDXL en lugar de CLIPTextEncode, dos nodos con nombres casi gemelos. Me vino a la memoria Primer, la película de 2004 de Shane Carruth donde dos ingenieros construyen una máquina del tiempo en un garaje y basta una conexión fuera de sitio para descarrilarlo todo. Mi garaje era más modesto, pero la lección idéntica: sustituido el nodo por el correcto, todo empezó a funcionar. Fue el momento en que comprendí la lógica modular del software y la importancia de emparejar el nodo correcto con el modelo correcto.
Luego llegó la primera imagen, a partir de mi prompt más que banal: "a cat on a windowsill, sunlight", a 1024x1024. Un desastre: triple cabeza superpuesta, detalles confusos, colores extraños. La causa estaba en la ficha del modelo, que indica un entrenamiento a 512x512. De vuelta a esa resolución, añadí al prompt las palabras de rigor (masterpiece, best quality, detailed fur, soft lighting, photorealistic) y retoqué los parámetros del KSampler: pasos de 20 a 30, CFG de 8 a 7, scheduler de simple a karras. No sabría decir qué ingrediente hizo más efecto, como en todo ritual, pero el resultado mejoró muchísimo.
Flux cambia las reglas
El gran avance llegó con Flux.1 schnell, elegido tras leer sobre su calidad superior. Descargué la versión FP8 en un solo archivo, un llamado checkpoint all-in-one que reúne modelo, codificador de texto y decodificador en un único paquete. Pesa unos 17 GB y tiene una ventaja decisiva para quien experimenta: la licencia Apache 2.0, a diferencia de su hermano dev que está limitado al uso no comercial.
La sorpresa fue descubrir que los parámetros aprendidos a duras penas con SD 1.5 había que desecharlos. Con Flux schnell el CFG se queda en 1.0 y no en 7, los pasos son 4 y no 25-30, y la resolución de partida es 1024x1024. La versión schnell está destilada, es decir, entrenada para obtener en muy pocos pasos lo que otros modelos hacen en muchos, y para ella se aplica una horquilla de uno a cuatro pasos. Primera prueba con el mismo prompt exacto del desastre anterior: calidad muy buena.
Puestas una al lado de la otra, la diferencia entre SD 1.5 y Flux con el gato al sol es evidente. Flux entiende el lenguaje natural mucho mejor, no necesita palabras mágicas y produce una imagen mucho más grande, coherente incluso con una frase escrita como la diría una persona.
Existe, sin embargo, una contraindicación estética. Flux tiende a un aspecto pulido, casi de render tridimensional o de fotografía de stock, demasiado limpio para parecer real. Intenté reducir el efecto con términos como film grain, raw photo y unedited, con resultados variables. No soy el único que se plantea el problema. Krea centró la presentación de Krea 2 en versión abierta precisamente en la estética, ofreciendo el modelo como el más cuidado entre los de pesos abiertos. Es una afirmación de marketing que hay que tomar como tal, pero demuestra que la competición hoy se juega también en el gusto y no solo en la fidelidad al prompt.
Tras unas veinte pruebas, las limitaciones de Flux Schnell resultaron ser menos aleatorias de lo que había pensado inicialmente. El modelo maneja excepcionalmente bien las escenas estáticas y tampoco se le resiste el movimiento: un guepardo, un coche derrapando y un pato gigante salieron estupendamente. El problema surge con el cuerpo humano en acciones dinámicas; al correr, patear o esquiar, las extremidades tienden a fusionarse o a multiplicarse. Otra debilidad es la representación de texto, algo típico de los modelos basados en difusión. Estas son solo mis observaciones, basadas en un único modelo y sistema.
El muro de la VRAM
Luego hice lo que hace cualquiera que acaba de descubrir un juguete nuevo: subir la resolución. A 1500 píxeles la generación requería aproximadamente un minuto. A 2048 píxeles tardaba cinco o seis minutos. El salto no es proporcional: para una imagen cuadrada los píxeles totales aumentan poco menos del doble, pero el tiempo se multiplica por cinco o seis. La explicación más plausible, y subrayo plausible porque es una hipótesis y no un diagnóstico, es que a partir de cierto umbral la memoria de la tarjeta no basta y ComfyUI se ve obligado a desplazar fragmentos del modelo de un lado a otro entre la VRAM y la RAM del sistema. La sospecha se refuerza con un dato sencillo: el archivo de Flux schnell FP8 pesa más de los 16 GB de mi tarjeta, y una wiki no oficial indica 12 GB como mínimo y 16 GB como valor recomendado para este modelo. Traducido: estoy al límite, y el límite se nota. Los 32 GB de RAM sirven de colchón, pero un colchón lento.
Es la toma de conciencia más concreta de toda la prueba. Mi Radeon es potente, pero no ilimitada, y con los modelos locales la elección de la arquitectura se hace en función de la memoria disponible antes incluso que del gusto personal. El resto lo hacen las versiones cuantizadas, copias del modelo con números menos precisos y por tanto más ligeras, como el formato FP8 que usé o los GGUF de los que hablaré en breve. Cada reducción de precisión es un compromiso entre espacio, velocidad y calidad, que debe evaluarse a ojo caso por caso.
Me llamó la atención, por contraste, otra experiencia reciente mía. Con OmniVoice Studio, en este mismo PC, la tarjeta AMD en Windows se quedó al margen y la síntesis de voz recayó en la CPU, tardando unos 200 segundos para diez segundos de audio. Con ComfyUI fue mucho mejor: la documentación oficial enumera paquetes ROCm para AMD en Windows y cita explícitamente la arquitectura RDNA 4 de mi tarjeta, y utilicé ROCm sin drama alguno. Hay que decir que la citada wiki no oficial califica de experimental el soporte de AMD en Windows, por lo que se trata de un territorio en rápida mejora pero aún no pacificado. Una misma GPU, dos destinos diferentes, lo que confirma que en la IA local cuenta enormemente lo bien que el software sepa comunicarse con el silicio.
Esto es aún más cierto para el vídeo, que por ahora solo he observado desde fuera. En mis artículos anteriores, Ovi pedía al menos 24 GB de VRAM y LongCat-Video requería unos 60 GB, o 18 GB con cuantización de 8 bits en una RTX 4090. El panorama se mueve. La documentación de ComfyUI sostiene que Wan 2.2 en su versión de 5.000 millones de parámetros cabe en unos 8 GB con descarga nativa, mientras que el repositorio oficial habla de 24 GB; su hermano de 14.000 millones, para funcionar en 16 GB, exige según reportes de la comunidad versiones cuantizadas. Y el 12 de agosto de 2026 llegó a ComfyUI LTX-2.5, con pesos abiertos, audio y vídeo sincronizados y la promesa declarada por sus autores de gran velocidad en hardware de consumo. Promesa que conviene verificar en la propia tarjeta, como siempre.
Modificar es otro oficio
Satisfecho con la generación desde cero, intenté modificar una imagen existente: un coche amarillo que debía transformarse en rojo, manteniendo todo lo demás inalterado. El parámetro que regula este asunto es el denoise del KSampler. Según la documentación, el sistema añade ruido a los datos de la imagen original en función de ese valor y luego deja que el modelo la repinte; por tanto, con valores bajos cambia poco y con valores altos cambia todo. Con SD funciona como un deslizador progresivo. Con Flux schnell observé un comportamiento de tipo escalón: por debajo de 0,8 la imagen no cambiaba en absoluto; a 0,81 el modelo reescribía todo y perdía el coche original. Cero control, mucha frustración.
No tengo una explicación segura. Una pista proviene de un hilo en el foro de FLUX.2 klein 9B, otro modelo destilado a cuatro pasos, donde un usuario describe artefactos crecientes con valores bajos de denoise y los atribuye al muestreo en muy pocos pasos. No es el mismo escenario ni el mismo modelo, por lo que lo tomo como sospecha y no como veredicto. Mi hipótesis de trabajo es que un modelo construido para hacer todo en cuatro movimientos carece del grano fino necesario para regular un deslizador, y que en cualquier caso img2img actúa sobre toda la imagen y no sobre una parte. Para modificaciones quirúrgicas existen herramientas diseñadas a tal efecto.
La más prometedora es FLUX.1 Kontext dev, un modelo de 12.000 millones de parámetros dedicado exclusivamente a la edición guiada por instrucciones de texto, bajo la misma licencia no comercial de Flux dev. Afirma poder funcionar en hardware de consumo, pero las cuentas se hacen rápido. Un modelo de 12B ocupa del orden de 24 GB en precisión completa, similar a Flux dev con 23,8 GB, unos 12 GB en FP8 y unos 7 GB en una cuantización GGUF de 4 bits (estimaciones mías a ojo). En mi tarjeta la versión FP8 sería lenta y la GGUF un compromiso interesante. Ambas quedan como pruebas pendientes.
Mientras tanto, ha aparecido un camino más cómodo. Black Forest Labs lanzó a principios de 2026 la familia FLUX.2 klein, modelos pequeños de 4 y 9 mil millones de parámetros, diseñados para funcionar en hardware de consumo y capaces de generar y editar imágenes. La versión de 4 mil millones está bajo licencia Apache 2.0, y la de 9 mil millones bajo licencia no comercial. La memoria que requieren varía según la fuente: el repositorio habla de unos 8 GB y la documentación oficial de unos 13 GB. En ambos casos mi tarjeta encaja con comodidad, y el próximo experimento ya está decidido.
Libertad con factura de la luz
Antes de hacer balance conviene definir qué es realmente ComfyUI, porque mi prueba apenas ha tocado la superficie. El sistema de bloques no es un capricho de la interfaz sino su razón de ser: la misma forma de trabajar que me sirvió para generar un gato sirve para modificar una imagen existente, como intenté con el coche amarillo, y también para vídeo, cuyo desarrollo respaldan los creadores con actualizaciones dedicadas para cada nuevo modelo importante. Se cambia la tarea cambiando los bloques, no la herramienta. Un flujo se guarda, se repite idéntico, se comparte y se modifica a partir de modelos listos para usar. Es la diferencia entre un electrodoméstico y un banco de trabajo: el primero hace bien una cosa, el segundo exige aprender a usarlo pero permite construir lo que haga falta. El precio, como se verá, es la paciencia.
Si este experimento me ha enseñado algo, es que "gratis" es una palabra que conviene manejar con cautela. Las ventajas del entorno local son reales y las he tocado con la mano. Cada imagen adicional no cuesta nada a nivel marginal, por lo que experimentar se convierte en un gesto ligero y se prueba sin pensarlo, como solo se hace cuando no hay contadores corriendo. Los datos y las imágenes permanecen en mi máquina. Y el control es total, en el sentido de que cada parámetro está al alcance de la mano y se aprende haciendo, incluso equivocándose.
También la arquitectura ayuda. ComfyUI separa claramente el motor, los modelos y las extensiones, por lo que se puede cambiar de modelo sin rehacer el flujo o añadir funciones sin tocar el núcleo. Existe una comunidad que produce nodos personalizados, recopilados en un registro público y gestionados mediante ComfyUI-Manager, que en la versión Desktop viene incluido (la documentación oficial, en este caso, está disponible en coreano). Abundan los flujos de trabajo listos para modificar, y un truco que me pareció elegante: las imágenes guardadas llevan consigo el flujo que las generó, por lo que basta con arrastrar un PNG al lienzo para reproducir el trabajo. La reproducibilidad, para quien quiere entender y no solo consumir, es un tesoro.
La otra cara de la moneda consta de tres aspectos. El primero es el hardware, del que ya he hablado. El segundo es el coste oculto: la tarjeta, la corriente eléctrica, el espacio en disco y, sobre todo, el tiempo, que en mi caso se fue en carpetas equivocadas, nodos intercambiados y pruebas en vano. El tercero es la fragmentación de licencias. Cada modelo tiene sus reglas de uso y su licencia: SD 1.5 con OpenRAIL-M, Flux dev y Kontext dev con licencias no comerciales, Flux schnell y klein 4B con Apache 2.0, klein 9B de nuevo no comercial. Las licencias cambian, y quien quiera hacer un uso profesional debe leerlas con atención sin fiarse de un resumen.
Existe además una cuestión de perspectiva. Las empresas que publican modelos abiertos a menudo los acompañan con servicios de pago: Black Forest Labs ofrece klein también a través de API, por unos pocos céntimos por imagen, y los mismos pesos que descargamos gratis alimentan una tarifa comercial. Para quien experimenta es una buena noticia, porque el ámbito local sigue siendo una puerta abierta. Quienes más ganan son las empresas, que usan la comunidad como banco de pruebas, y los fabricantes de GPU, en particular NVIDIA, que en la misma wiki figura aún como referencia de rendimiento y compatibilidad. Quienes corren el riesgo de quedarse atrás son los usuarios con máquinas antiguas, para quienes la libertad de lo local es accesible solo en teoría. Una pregunta abierta se refiere a la comparación con la nube: no hice pruebas directas, pero está claro que los modelos propietarios de frontera siguen siendo superiores, en particular con la generación de figuras humanas. Ambos frentes representan dos formas distintas de poseer y concebir una herramienta.
Quién debería probarlo
Recomendaría esta aventura a quien busque control y privacidad y no tema perder una tarde detrás de un mensaje de error. Quien disponga de al menos 12 GB de VRAM parte en condiciones razonables, y con 16 GB como en mi caso se trabaja bien mientras no se suba demasiado el listón. El perfil ideal es el del curioso dispuesto a mancharse las manos, alguien que aprecie el momento en que un nodo encuentra su sitio. Lo desaconsejo a quien busque una solución llave en mano, de esas en las que se escribe una frase y se obtiene una imagen sin tropezar jamás con una variable, y a quien tenga un hardware limitado y pocas ganas de esperar.
El balance personal es positivo, con algunas reservas. Aprendí que el nodo correcto debe ir con el modelo correcto, que cada familia de modelos tiene su propio vocabulario de parámetros y que los números de una ficha técnica cuentan solo la mitad de la historia. Obtuve imágenes de buena calidad con Flux partiendo de cero. Medí los límites: la memoria, la complejidad, modelos aún demasiado pesados para ciertos usos. El img2img y el vídeo quedan como evoluciones futuras, porque la parte que me interesaba hoy era la creación "text to image" desde cero en local, y esa funcionó.
Me viene a la mente Dungeon Meshi, el manga de Ryoko Kui en el que un grupo de aventureros atraviesa una mazmorra cocinando los monstruos que encuentra, con lo que halla y aprendiendo las recetas a sus expensas. La IA en local comparte ese mismo espíritu de autosuficiencia, junto con una buena dosis de riesgo de intoxicación. No es una alternativa gratuita a los servicios en la nube; es otra cosa: un ecosistema donde la personalización y el aprendizaje son posibles de una manera impensable con una suscripción. El próximo paso será probar klein 4B y un Kontext cuantizado, con el gato en el alféizar esperando a cambiar de color.
Nota técnica: Los datos sobre dimensiones, licencias y requisitos se han verificado en las fuentes enlazadas a fecha de octubre de 2026 y pueden cambiar. Los tiempos de generación son observaciones personales sobre un sistema individual (Ryzen 7700, 32 GB DDR5, RX 9060 XT 16 GB, Windows, ComfyUI Desktop con ROCm), no análisis comparativos oficiales.