Fibo 2.0 Dev llega a ModelScope: el checkpoint que Bria realmente creó para el ajuste fino

La ficha de Fibo 2.0 Dev en el sitio de ModelScope en China se creó a las 17:03 UTC del 20 de octubre de 2026 —el mismo día en que Bria publicó el modelo—, y una copia en el sitio internacional apareció dos días después, a las 09:55 UTC del 22 de octubre. Desde entonces, ninguno de los dos espejos ha cambiado mucho: la ficha china tenía 691 descargas y la internacional 59 cuando se consultaron esta semana, y ambas tienen un campo de licencia que dice, de manera poco útil, «other». Las cifras de descargas no son lo importante. Lo importante es lo que el propio stack de ingeniería de ModelScope dice sobre los checkpoints, porque la documentación de Fibo de DiffSynth-Studio ahora lo afirma claramente: solo Fibo 2.0 Dev es entrenable.

Eso merece una pausa para analizarlo. Bria (la empresa detrás del modelo) lanzó Fibo 2.0 el 20 de octubre de 2026 como un modelo de pesos abiertos de 8,13 mil millones de parámetros que hace generación de texto a imagen y edición mediante instrucciones con un único conjunto de pesos, y publicó dos checkpoints con ese nombre: la base completa y un editor destilado. ModelScope, el hub de modelos chino cuyo proyecto DiffSynth-Studio proporciona los scripts de entrenamiento, ahora ha integrado ambos y ha trazado la línea que los desarrolladores esperaban ver: el checkpoint destilado es un artefacto de despliegue, el no destilado es lo que se puede enseñar.

¿Qué hay realmente en ModelScope y qué no?

Existen dos listados, y son espejos de los mismos pesos, no una reconstrucción. El sitio chino lista briaai/Fibo-2.0-dev bajo la tarea text-to-image-synthesis con las bibliotecas pytorch, lora, safetensors y diffusers; la presencia de lora en esa lista es una pequeña señal sobre la intención. El sitio internacional lleva el mismo ID de modelo con su propio contador de descargas, mucho menor. Ambos remiten al repositorio restringido de Hugging Face en lugar de alojar una copia separada, así que cualquiera que necesite los archivos reales todavía pasa por el formulario de acceso no comercial de Bria.

Dos detalles conviene señalar porque confundirán a cualquiera que lea la ficha de forma aislada. La etiqueta de tarea indica solo texto a imagen, lo que subestima el checkpoint: Fibo 2.0 Dev hace generación y edición con los mismos pesos, y la ruta de edición es la que más interesa a la mayoría de los equipos. Y el campo de licencia dice «other» en lugar de «CC BY-NC 4.0», lo cual es una laguna de metadatos, no una concesión distinta: la concesión sigue siendo la licencia no comercial de Bria, y es la mayor restricción para cualquier cosa que ajustes finamente sobre este checkpoint.

El momento también importa para cómo debe interpretarse la noticia. Los pesos se publicaron en el Hub el 18 y 19 de octubre, Artificial Analysis ya disponía de una instantánea al 20 de octubre, ComfyUI integró compatibilidad nativa el 21 de octubre y el espejo internacional de ModelScope se completó el 22 de octubre. Fibo 2.0 Dev es un checkpoint de nueve días en una fase de distribución que todavía está en movimiento, no un lanzamiento antiguo que se está reviviendo.

Dev versus Edit Turbo es un fork real, no una rareza de nombres.

Bria publicó dos checkpoints bajo un mismo nombre de lanzamiento, y la diferencia decide todo lo que viene después:

Muestreo — Fibo 2.0 Dev ejecuta 50 pasos con guía libre de clasificador en 5.0; Fibo 2.0 Edit Turbo ejecuta 4 pasos con la guía fijada en 1.0, es decir, sin guía alguna.

• Cobertura de tareas — Dev hace texto a imagen y edición; Turbo solo hace edición, así que un prompt de texto a imagen con Turbo es la herramienta equivocada, no una respuesta más lenta.

• Prompts negativos — funcionan en Dev porque CFG está activado; en Turbo no hay CFG que dirigir, así que un prompt negativo no tiene palanca que accionar.

• Entrenabilidad — esta es la bifurcación que importa aquí. La página de Fibo de DiffSynth-Studio es explícita en que solo Fibo-2.0-dev es un objetivo de entrenamiento; Turbo se describe como no destinado al ajuste fino.

• Coste por imagen en inferencia — Turbo es aproximadamente un orden de magnitud más económico de ejecutar para la función concreta que cumple, y es exactamente por eso por lo que nadie debería ajustarlo con fine-tuning para perseguir esa diferencia.

En el fondo, tienen la misma forma: un transformer de difusión con flow-matching que opera en el espacio latente del VAE de FLUX.2, un DiT BF16 de 8.127.342.213 parámetros con 44 bloques de flujo único, cinco de los cuales llevan atención cruzada hacia un codificador de texto Qwen3-VL-4B-Instruct cuya salida se comprime en 256–512 tokens "gist" mediante un remuestreador Perceiver de dos capas. El repositorio ocupa unos 25,5 GB en total —un transformer de 16,3 GB, un codificador de texto de 8,9 GB y un VAE de 0,34 GB—, que es la cifra que hay que presupuestar, no el titular de 8B.

La receta de entrenamiento: codificadores congelados, un DiT entrenable

La contribución de ModelScope no es otro espejo, sino un conjunto de scripts, y su estructura es convencional de un modo que lo hace utilizable. El entrenamiento reutiliza el mismo FiboPipeline que se usa para la inferencia y se ejecuta mediante examples/fibo/model_training/train.py. El VAE y el codificador de texto están congelados; el DiT se entrena con flow matching. Esa elección es la sensata —el ajuste fino de un codificador Qwen3-VL-4B junto con un transformer de 16 GB en un solo nodo es un proyecto distinto—, pero también implica que un ajuste fino puede redirigir el estilo, la composición y el comportamiento de edición sin enseñarle al modelo un lenguaje de prompts genuinamente nuevo.

Se admiten dos niveles, y ambos son exclusivos de DiT:

• Ajuste fino completo — pasa --trainable_models "dit" y deja que Accelerate gestione la configuración distribuida; se mueve todo el transformer, nada más.

• LoRA — adjunta adaptadores al DiT con --lora_base_model "dit", configura los módulos objetivo y el rank, y opcionalmente reanuda desde un checkpoint; los scripts de LoRA incluidos utilizan una sola GPU de forma predeterminada.

La edición es un objetivo de entrenamiento de primera clase en lugar de una idea de última hora. Las ejecuciones de edición inyectan edit_image y una máscara opcional a través de --extra_inputs, y UnifiedDataset lee esas columnas de los metadatos; las filas sin máscaras se entrenan como muestras de edición ordinarias en lugar de descartarse. Dado que la generación y la edición comparten pesos, un único ajuste fino puede enseñar un nuevo dominio y cómo editar dentro de él: la propia ficha del modelo de Bria presenta esa propuesta para LoRAs de marca y estilo, especialistas verticales y editores de tareas específicas, e incluye un entrenador LoRA para una sola GPU con una guía de preparación de datos en la carpeta fine_tuning/ del repositorio.

Los dos conjuntos de datos de ejemplo muestran el esquema que se espera que produzcas: DiffSynth-Studio/diffsynth_example_dataset, con una división fibo/Fibo-2.0-dev que contiene un CSV de metadatos de imagen y prompt, y una división fibo/Fibo-2.0-dev-Edit que contiene un JSON de metadatos de image, prompt, edit_image y una máscara opcional. Nada en ese esquema es exótico; el trabajo está en producir los subtítulos.

VRAM: la parte que la ficha del modelo no cuantifica

No hay un mínimo publicado. La documentación de DiffSynth recomienda configuraciones de VRAM baja y una gestión automática de la VRAM en función de la memoria restante en lugar de fijar un mínimo, y la configuración de ejemplo indica lo que esperan: cargar y preparar en FP8 E4M3, calcular en BF16, descargar a disco y limitar el uso total a la memoria CUDA total menos 0,5 GB. Es una receta escrita por gente que sabe que la respuesta depende de tu tarjeta, tu resolución y de si el checkpointing de gradientes está activado, y es honesta al respecto. Planifica la descarga a disco y acepta que un ajuste fino a un megapíxel será lento antes de dar buenos resultados.

El JSON estructurado es la interfaz, así que tu conjunto de datos tiene que hablarlo.

La superficie de control de Fibo no es un campo de prompt. El modelo se entrenó con descripciones de Visual GenAI Language (VGL) —JSON estructurado en el que la iluminación, la composición, el estilo, la cámara y los objetos son campos direccionables de forma independiente— y el pipeline de inferencia devuelve la descripción junto con la imagen que generó. El helper bria-vgl expone create() para la generación y modify() para las ediciones, así que no se espera que escribas el JSON a mano; un VLM alojado realiza la expansión a menos que lo redactes tú mismo.

Eso tiene una consecuencia directa para el ajuste fino que la cobertura del lanzamiento pasó por alto en su mayoría. Si entrenas con prompts de texto libre, estás entrenando el DiT con un formato de caption para el que no fue concebido, y el control que esperabas obtener es lo primero que se pierde. Almacenar captions VGL en tus metadatos —ya sean generados por el pipeline y luego editados, o escritos deliberadamente— mantiene intacto el comportamiento del campo direccionable, y es la diferencia entre un LoRA que cambia un estilo y un LoRA que cambia un estilo sin destrozar el resto del encuadre. Si tu conjunto de entrenamiento son imágenes sin captions, la pasada de captioning es el paso costoso, y es una tarea de modelo de lenguaje.

El tooling llegó más rápido de lo que llegan la mayoría de los nuevos checkpoints.

Para un modelo de nueve días, el stack que lo rodea es inusualmente completo, lo que en parte explica por qué la integración con ModelScope es menos relevante de lo que parece y más útil que un simple espejo.

• diffusers — un BriaFibo2Pipeline se incorporó como PR #14991, que es la ruta que tomará la mayor parte del código de inferencia.

• ComfyUI — soporte nativo integrado el 21 de octubre como PR #17240 y publicado en v0.43.0, añadiendo un tipo de codificador de texto fibo2 que carga el Qwen3-VL-4B oficial y un nodo TextEncodeFibo2 que gestiona prompts VGL e imágenes de referencia. Los repacks BF16 e INT8 siguen ese esquema del cargador, y existe soporte de arquitectura GGUF para ejecuciones locales cuantizadas.

• ModelScope / DiffSynth-Studio — scripts de inferencia y entrenamiento en un solo lugar, que es la pieza que un equipo que está estandarizando en DiffSynth realmente necesita antes de poder planificar un ajuste fino.

El muro que nadie menciona: CC BY-NC 4.0

Fibo 2.0 es de pesos abiertos, no de código abierto, y la diferencia entre esas dos expresiones es toda la cuestión comercial. Los checkpoints están bajo CC BY-NC 4.0: solo uso no comercial, y el despliegue comercial requiere un acuerdo aparte con Bria, y los repositorios de Hugging Face están restringidos detrás de una empresa y un formulario de uso previsto. Una LoRA de marca entrenada con Fibo 2.0 Dev es un artefacto de investigación hasta que exista ese acuerdo, lo cual es un lugar extraño para poner "exactamente aquello sobre lo que los desarrolladores quieren construir", pero es el lugar preciso. Compare las alternativas de pesos abiertos que permiten el uso comercial sin más, y la licencia, no el Elo, se convierte en la línea decisiva para cualquiera que vaya a lanzar un producto.

El panorama de la calidad también es menos favorable de lo que sugiere el titular. En AA-Image-Editing v2.1 de Artificial Analysis, Fibo 2.0 registra 1.088 Elo con un intervalo de ±14 sobre 5.009 votos ciegos — vigésimo tercero en general y primero entre los editores de pesos abiertos, aunque ha bajado uno o dos puestos desde la instantánea de lanzamiento. Qwen-Image-2.1 se sitúa en 1.081 ±13, y los intervalos se solapan casi por completo, así que la ventaja en pesos abiertos es un desempate, no una prueba. En AA-Image-T2I v2.1 el orden se invierte: 1.039 ±12 para Fibo 2.0 frente a los 1.042 ±12 de Qwen-Image-2.1. La propia ficha de modelo de Bria es aún menos halagüeña en las categorías concretas: sitúa el renderizado de texto y la maquetación en los puestos que van de los 18 altos a los 22 bajos, y la anatomía humana en el decimoctavo. Un ajuste fino puede atacar esas debilidades, pero no puede superar lo que entiende el codificador.

Dónde encaja el enrutamiento y dónde no

El desglose honesto: Fibo 2.0 en sí no está en el catálogo de OrcaRouter, así que nada de esto es una propuesta de «llamar a Fibo a través de nosotros». Lo que aporta el enrutamiento es la otra mitad del pipeline. Los dos trabajos de modelos de lenguaje en torno a este checkpoint —escribir leyendas VGL para un conjunto de entrenamiento y expandir prompts cortos en JSON estructurado durante la inferencia— son cargas de trabajo de texto ordinarias, y son las que deciden si un ajuste fino es posible siquiera. OrcaRouter ofrece una API para 200+ modelos con 0 % de margen, así que los precios de lista de los proveedores pasan directamente y un recorte del proveedor llega a tu factura el mismo día; la conmutación automática entre proveedores significa que una ejecución de generación de leyendas para unos cuantos miles de imágenes no se cae por un único upstream; y el DSL de enrutamiento puede fijar un modelo barato para la generación masiva de leyendas mientras envía los casos difíciles a algo más potente, con fusión de modelos disponible cuando un único generador de leyendas sigue omitiendo un campo. El modelo de imagen se queda donde está; el texto que lo rodea se puede enrutar.

Lo próximo a lo que hay que prestar atención es la propia hoja de ruta de Bria, que la ficha del modelo enumera como edición local multiturno, eliminación de fondos, un LoRA para tomas de producto, borrado de máscaras y outpainting; todo lo cual llegaría primero al checkpoint Dev, porque Dev es el que tiene un bucle de entrenamiento. Los espejos de ModelScope son la mitad aburrida de esta historia. La frase de DiffSynth «solo Fibo-2.0-dev es entrenable» es la mitad útil, y es la razón para descargar el repositorio de 25,5 GB en lugar de llamar a la API.