El servicio de imágenes completo determina la capacidad
Un equipo de catálogo necesita recibir variantes de imagen aprobadas en su flujo de trabajo. El servicio combina codificación del prompt, eliminación de ruido, decodificación, gestión de API, codificación PNG y guardado. Una ejecución más rápida del modelo cambia la etapa que limita la entrega.
ProsGrow midió todo ese recorrido con FLUX.2 Klein 4B. NVFP4 nativo elevó el rendimiento un 32.5% en una comparación equivalente con una GPU. El siguiente reto fue la infraestructura compartida: el perfil más rápido en una GPU se volvió más lento al desplegarse en todo el nodo. El análisis de esa inversión llevó a una configuración con una tasa medida de 59,881 variantes de imagen/hora.
Una comparación controlada de precisión
| Métrica | Base BF16 | NVFP4 nativo |
|---|---|---|
| Tiempo medio por solicitud | 0.750 s | 0.566 s |
| Rendimiento | 1.333 imágenes/s | 1.766 imágenes/s · +32.5% |
| Memoria de dispositivo observada | Unos 18 GiB | Unos 11.6 GiB |
El checkpoint oficial NVFP4 procede de Black Forest Labs y ComfyUI aporta la ruta nativa de ejecución cuantizada. ProsGrow verificó que la precisión prevista estuviera activa, mantuvo fijo el flujo y midió hasta guardar el PNG. Además de mejorar el rendimiento, la latencia por solicitud cayó un 24.5%.
El menor uso de memoria permitió solapar trabajo, pero la precisión por sí sola no saturó el nodo. El primer despliegue NVFP4 registró solo un 52.5% de actividad en las unidades de cómputo de GPU. Eso motivó un análisis de la planificación y de las etapas del host entre operaciones GPU.
El óptimo local perdió al escalar al nodo
ComfyUI procesa secuencialmente una cola de trabajo. Solapar procesos residentes independientes permitió que la GPU siguiera trabajando mientras otras solicitudes gestionaban tráfico API, codificación PNG o escritura de archivos. En una GPU aislada, más solapamiento mejoró utilización y rendimiento.
La tendencia no se mantuvo en el nodo completo. El perfil más rápido en una GPU aislada produjo solo 46,759 imágenes/hora cuando todas competían por los mismos recursos del host. Una topología menos congestionada alcanzó 57,540 imágenes/hora en su repetición conservadora. Las mesetas de baja potencia eran coherentes con bloqueos en host, API, PNG o sistema de archivos; las trazas no aislaron un único componente como causa exclusiva.
La lección central es que el óptimo local no es el óptimo del nodo. Una mayor utilización de una GPU aislada puede generar contención en otros puntos. ProsGrow eligió la topología a partir de mediciones sincronizadas del nodo, considerando conjuntamente salidas completadas, memoria y variación entre ejecuciones.
Capacidad para un flujo creativo definido
Un flujo creativo suele requerir varias versiones de un recurso. Para ese contrato de servicio, ProsGrow evaluó generar dos variantes de un prompt por solicitud. El perfil elegido alcanzó 59,881 variantes/hora, tomando el mínimo de tres ejecuciones sincronizadas del nodo. Supuso un 4.07% más que la tasa conservadora anterior, con una variación entre ejecuciones del 1.61%.
La unidad importa: las variantes generadas no son prompts distintos. El cliente reutilizó un prompt controlado y cambió las semillas de ruido, con la caché de ComfyUI disponible. El resultado no mide un flujo diverso de prompts nuevos ni una nueva codificación del prompt en cada solicitud.
Se contabilizaron las 2,880 salidas medidas, sin coincidencias con los marcadores de error seleccionados. Cada ejecución duró unos 57 segundos. Esto ofrece un punto de partida medido para un piloto; la llegada sostenida de solicitudes, las colas y la aceptación del cliente siguen determinando la capacidad utilizable.
Qué implica la capacidad para el coste
La capacidad permite estudiar costes cuando la demanda y los requisitos están claros. En el escenario existente de un nodo de $100,000 con demanda de pago del 10%, la tasa medida equivale a 52.46 millones de variantes vendidas al año. Un coste anual de infraestructura modelado de unos $40,058 da $0.000764 por variante vendida.
El escenario supone amortización a tres años, mantenimiento anual del 5%, 8,760 horas al año, electricidad a $0.10/kWh, multiplicador de consumo de 1.30 y potencia del servidor de 1.016 kW en reposo y 6 kW activo. Excluye personal, operaciones comerciales, red, almacenamiento y reservas de servicio. Deben validarse demanda y tasa de aceptación antes de usarlo para decidir una compra.
El perfil seleccionado también midió 0.0571 Wh de energía de las placas GPU por imagen, excluyendo host y refrigeración. Ambas cifras corresponden al contrato de prompt repetido y dos variantes. No demuestran equivalencia de calidad ni coste con un servicio alojado.
Elegir un punto de operación para producción
En un flujo creativo por lotes, las variantes aceptadas por hora pueden ser el objetivo adecuado. Una herramienta interactiva también necesita baja latencia y margen para picos. El solapamiento consume memoria y capacidad compartida del host, por lo que la configuración debe reservar margen para entradas, almacenamiento, reintentos y la tasa prevista de llegada.
El proceso medido conecta la validación de precisión con el análisis del servicio y la verificación del nodo. Concreta la siguiente decisión del cliente: ¿una mezcla representativa de prompts conserva la mejora con la calidad y el plazo requeridos? Esa es la base para dimensionar un endpoint privado.
Metodología y limitaciones
- Hardware y software: un nodo con ocho GPU RTX PRO 6000 Blackwell, 96 GB nominales por GPU; ComfyUI 0.32.0, comfy-kitchen 0.2.30, PyTorch 2.11.0 y CUDA 13.0. La revisión del checkpoint NVFP4 fue
1db2b2f7. - Carga: FLUX.2 Klein 4B, salida 1024×1024, cuatro pasos Euler y un prompt controlado de fotografía de producto en estudio. La comparación de precisión produjo una imagen por solicitud; el perfil del nodo, dos variantes. Los prompts repetidos y la caché disponible limitan la extrapolación a tráfico diverso.
- Medición temporal: los modelos se cargaron y calentaron antes de medir. La comparación ComfyUI incluye cola y sondeo de API, codificación del prompt, eliminación de ruido, decodificación VAE, codificación PNG y guardado, con 30 solicitudes por precisión. Un resultado anterior de Diffusers excluye PNG y no es la base de precisión.
- Agregación y repetición: las tasas dividen el total de salidas por la ventana común desde el inicio del primer cliente medido hasta la última finalización. Se usa el mínimo de tres pruebas cortas de 960 salidas cada una, con 92.49% de eficiencia de escalado frente a ocho veces su tasa en una GPU aislada. Las tasas anteriores sumadas por proceso no se usan como base equivalente del nodo. Estas mediciones no establecen un SLA sostenido de producción.
- Calidad: se inspeccionaron visualmente ocho salidas. Todas eran fotos coherentes con la etiqueta solicitada legible; seis tenían la etiqueta exacta y limpia, una añadió texto pequeño y otra un artefacto de puntuación. Esta comprobación básica no establece calidad general de cuantización, fidelidad al prompt, tipografía, moderación ni aceptación del cliente.
Las mediciones se recogieron del 12 al 21 de agosto de 2026. No se probó equivalencia en calidad de API alojada, fiabilidad operativa ni coste total.
Generación privada de imágenes FLUX.2 con ComfyUI
Para los equipos que planifican generación privada de imágenes con FLUX.2 Klein y ComfyUI, este benchmark ayuda a definir la capacidad según la cantidad de variantes y el plazo del flujo creativo. Las variantes por hora y la latencia de solicitud responden a preguntas de planificación distintas. El despliegue debe confirmar el rendimiento con prompts representativos y contar las salidas que cumplen sus requisitos de calidad.
Optimiza el flujo de imágenes que usa tu equipo
Comparte un conjunto representativo de prompts, número de variantes, umbral de calidad y objetivo de entrega. Compararemos una base con un servicio privado optimizado bajo el mismo contrato de salida.
Hablar sobre un piloto