English · Español

03 — Estrategias de Fusion: Late, Early, Unified-Token¶

🇪🇸 Fusionar modalidades es el problema central: cómo combinar señales de visión, audio y texto dentro del mismo modelo. Hay tres familias: late fusion (CLIP — dos encoders, alineados por contraste), early fusion (Flamingo — cross-attention con gates aprendibles), y unified-token fusion (Chameleon, Gemini — todo es un token en el mismo vocabulario). Esta sección compara las tres en arquitectura, datos, y cuándo elegir cuál.

Este fichero responde: una vez que tenemos un encoder de visión y un encoder de texto, ¿cuáles son las formas de combinarlos en un único modelo, y cuáles son los trade-offs?

Referencias: - Radford et al., CLIP (late fusion), 2021. (arXiv:2103.00020) - Alayrac et al., Flamingo: a Visual Language Model for Few-Shot Learning (early fusion / gated cross-attn), DeepMind, 2022. (arXiv:2204.14198) - Team Chameleon, Chameleon: Mixed-Modal Early-Fusion Foundation Models (unified-token), Meta, 2024. (arXiv:2405.09818) - Gemini Team, Gemini: A Family of Highly Capable Multimodal Models, Google, 2023. (arXiv:2312.11805)

La taxonomía¶

Tres familias, distinguidas por dónde se combinan las modalidades en el modelo:

Familia	Dónde se encuentran las modalidades	Ejemplo	Datos de entrenamiento	Coste de inferencia
Late fusion	En la salida, vía espacios alineados	CLIP, SigLIP	100M+ pares (imagen, texto)	barato (encodear cada modalidad una vez)
Early fusion (cross-attn)	Dentro del LLM, vía cross-attention	Flamingo, LLaVA	1M–10M pares de instrucción	medio (cross-attn en cada capa del LLM)
Unified-token fusion	En el vocabulario de entrada	Chameleon, Gemini, AnyGPT, GPT-4o	1B+ tokens multimodal	alto (los tokens de imagen ocupan muchos slots)

Debajo: cada familia en detalle.

Late fusion (estilo CLIP)¶

Arquitectura: dos encoders independientes. Tras el entrenamiento, tienes dos funciones $f_I: \text{imagen} \to \mathbb{R}^d$ y $f_T: \text{texto} \to \mathbb{R}^d$, con un alineamiento aprendido tal que los embeddings de pares (imagen, texto) están cerca en coseno.

Entrenamiento: InfoNCE simétrico sobre pares (imagen, texto) (ver 01-vision-transformers.md).

Inferencia: para comparar una imagen y un texto, computa $f_I(\text{imagen})$ y $f_T(\text{texto})$ una vez cada uno, después toma similitud coseno. Esto es coste constante en el número de comparaciones (cachea los embeddings).

Para qué sirve: - Retrieval de imagen ("encuéntrame imágenes que casen con este caption"). - Clasificación zero-shot. - Como extractor de features para modelos downstream multi-modal (LLaVA congela el encoder de imagen de CLIP; el MLP proyector aprende a mapear features de CLIP al stream residual del LLM).

Lo que no puede hacer: - Generación. Sin decoder. No puedes pedirle a CLIP "describe esta imagen". - Razonamiento de grano fino. Un único embedding-por-modalidad pierde detalle espacial. CLIP sabe que hay "un perro" en la imagen pero no puede responder "¿cuántos perros?" de forma fiable. - Diálogo multi-turno. Sin mecanismo de memoria más allá del único forward pass.

Por qué CLIP sigue siendo importante: el encoder de imagen pre-entrenado por pérdida contrastiva sobre datos a escala web es la mejor inicialización disponible para LLMs multi-modal downstream. A día de 2026, casi todo modelo open-source de visión-lenguaje usa CLIP-ViT o SigLIP-ViT como backbone visual congelado.

Early fusion (cross-attention, estilo Flamingo)¶

La arquitectura definitoria del "vision-language model" (VLM) circa 2022–2024.

Estructura de Flamingo¶

Comienza con un LLM pre-entrenado y congelado (Chinchilla-70B en el paper) y un encoder visual pre-entrenado y congelado (NFNet). Añade nuevas capas entrenables que inyectan información visual en el LLM:

[image] → Vision encoder (frozen) → patch features (N_p × d_v)
                                       ↓
                            Perceiver Resampler (learnable, 64 outputs)
                                       ↓
                            64 fixed-size vision tokens
                                       │
                                       ├── injected as KV at each LLM layer via:
                                       ↓
[text tokens] → LLM layer with GATED CROSS-ATTENTION inserted before self-attention
                ↓
                ...repeat...
                ↓
                next-token logits

Los dos componentes nuevos:

Perceiver Resampler. Un transformer pequeño que coge un número variable de features de parche ($N_p \approx 200$ dependiendo del encoder visual) y produce un número fijo de 64 tokens latentes. Por qué: el LLM es caro por-token; no quieres 200 tokens de imagen por imagen. 64 son suficientes para el conjunto de tareas de Flamingo.
Capa de cross-attention con gates. Insertada entre cada bloque transformer del LLM. Lee de los 64 tokens visuales, escribe en el stream residual de texto.

El truco del gating¶

Cada salida de cross-attention se multiplica por tanh(α), donde α es un escalar aprendible inicializado a 0. Así que en la inicialización, tanh(0) = 0 → la salida de cross-attention es 0 → el modelo se comporta idénticamente al LLM congelado.

A medida que el entrenamiento progresa, α aprende a ser no-cero donde la cross-attention es útil. Esto es el "gated" en "gated cross-attention".

Por qué importa:

Preserva las capacidades del LLM base. Si la rama visual está pobremente entrenada o ausente al inicio, el modelo no regresiona en tareas solo-texto. El LLM congelado es el suelo.
Barato de entrenar. Solo el resampler + las capas de gated cross-attention son entrenables. Para Flamingo-80B, esto son ~10B params entrenables sobre el LLM congelado de 70B + el encoder visual congelado de 0.4B.
Recupera elegantemente. Si la cross-attention no aprende nada útil, el gate se queda cerca de cero y el modelo es solo un LLM. El modo de fallo es "sin capacidad visual" en vez de "modelo roto".

Este truco del gating es una de las ideas mecánicas más profundas en el diseño de modelos multi-modal. Se usa en muchos follow-ups (IDEFICS, OpenFlamingo, MM-CoT).

Mecánicamente, por qué early fusion bate a late fusion para VQA¶

Late fusion (CLIP) te da un embedding de imagen. Para responder "¿cuántos perros?", ese embedding tiene que codificar el conteo. Probablemente no lo hace, porque la pérdida contrastiva no preserva preferentemente el conteo sobre color/pose/raza.

Early fusion da al LLM acceso a los 64 tokens visuales vía cross-attention, con atención aprendida para enfocarse en los tokens relevantes para el token de texto actual que se está generando. El modelo puede atender a cada token de perro y "contar" atendiendo en secuencia. La capacidad es cualitativamente más alta.

LLaVA: early fusion barato¶

LLaVA (theory/04-llava-and-vision-language.md) es el primo más barato de early fusion:

Sin gated cross-attention.
En su lugar: las features de imagen se proyectan (MLP pequeño) a la dim de embedding del LLM, y se prependen a la entrada de texto como si fueran tokens extra.
El LLM se hace fine-tune (o se adapta con LoRA) sobre datos de instruction-tuning.

Cuesta menos entrenar que Flamingo (~$100 de tiempo GPU para LLaVA-1.5), a coste de tratar los tokens de imagen uniformemente a través de las capas del LLM (en vez de dejar a cada capa atender de forma diferente a los tokens de imagen).

Unified-token fusion¶

La visión "todo es un token": no tener un encoder de imagen separado; en su lugar, discretizar la imagen en tokens (vía VQ-VAE), poner esos tokens en el mismo vocabulario que los tokens de texto, y entrenar un único transformer con predicción de siguiente-token.

Chameleon (Meta, 2024)¶

El ejemplo publicado más limpio.

Vocabulario: 65\,536 tokens BPE para texto + 8192 tokens de imagen (de un VQ-VAE) = ~73 k vocabulario unificado.
Tokenizer de imagen: un VQ-VAE que codifica una imagen $512 \times 512$ en una rejilla $32 \times 32 = 1024$ de códigos discretos. Cada código es un entero en $[0, 8191]$ — mapeado a un embedding aprendible idénticamente a los tokens de texto.
Entrenamiento: predicción de siguiente-token sobre documentos intercalados de texto + imagen. Una muestra podría ser: <text> <image_tokens × 1024> <text> <image_tokens × 1024>.
Resultado: un único decoder transformer que puede generar tanto texto como imágenes, hacer preguntas visuales, y razonar a través de modalidades.

Gemini 1.5 / 2 (Google, 2023–2024)¶

Filosofía similar pero extendida a audio y vídeo del mismo modo: discretizar cada modalidad en tokens, vocabulario unificado, entrenar un transformer. La naturaleza de código cerrado significa que el detalle arquitectónico es difuso, pero la ventana de contexto de 1-M-tokens de Gemini 1.5 está construida sobre la asunción de unified-token.

Por qué unified-token es el paradigma frontera dominante (2025–2026)¶

Elegancia conceptual. Un modelo, una pérdida, una arquitectura. Sin componentes especiales por modalidad.
Generación. Puede generar imágenes, audio, texto — mismo mecanismo.
Grounding cross-modal. Más fuerte, porque cada capa ve cada modalidad.
Scaling laws unificadas. Las scaling laws de texto se traducen a multi-modal — puedes predecir rendimiento desde cómputo + conteo de tokens, punto.

Por qué unified-token es caro¶

Explosión de tokens. Una imagen $512 \times 512$ a parches $16 \times 16$ = 1024 tokens de imagen. Un clip de audio de 30-s discretizado a 50 Hz con un codebook de 1024 = 1500 tokens. Las ventanas de contexto multi-modal crecen rápido.
Datos de pretraining. Necesitas documentos multi-modal intercalados. El texto web-scraped es abundante; el multi-modal web-scraped (intercalado) es raro y ruidoso. La ingeniería de datos es el cuello de botella.
Entrenamiento de VQ-VAE. El tokenizer de imagen es a su vez un modelo que hay que entrenar bien; su colapso de codebook es un modo de fallo conocido (códigos quedan sin usar; el vocabulario efectivo se encoge).
Cómputo. El pretraining clase Gemini es ~$10^{25}$ FLOPs. Fuera de alcance para labs no-frontera.

Para un ingeniero de IA aplicada (X2 está en el hiring path "Applied AI"): no vas a pre-entrenar un modelo unified-token. Usarás uno pre-entrenado (GPT-4o, Gemini, Claude, posiblemente Chameleon si es open-weight). Entender el paradigma es para elegir el modelo correcto y saber lo que puede y no puede hacer.

Escalado de datos de entrenamiento para fusion¶

Una pregunta frecuente: ¿cuántos datos necesita cada estrategia de fusion?

Estrategia	Datos de pretraining	Datos de instruction-tune	Coste total de entrenamiento
Late fusion (CLIP)	400M pares (imagen, texto)	N/A	~$10^{22}$ FLOPs
Early fusion con encoder + LLM congelados (Flamingo)	reuso — 0	~1.5M muestras intercaladas	~$10^{22}$ FLOPs (mayormente amortizado en encoder + LLM)
Early fusion barato (LLaVA)	reuso — 0	~600k pares	~$10^{20}$ FLOPs
Unified-token (Chameleon, Gemini)	1B–10B tokens multi-modal (intercalados)	varía	$10^{24}$–$10^{25}$ FLOPs

Notas: - Late fusion necesita los datos pareados más por param. La pérdida contrastiva es hambrienta de datos: cada batch necesita negativos, cada par necesita un positivo. - Early fusion con componentes congelados es el camino más barato a un VLM funcionando. LLaVA-1.5 se reprodujo por ~$100 de tiempo GPU. - Unified-token necesita más datos totales que los otros, pero la mayoría puede ser no-pareados (el modelo entrena sobre una mezcla de solo-texto, solo-imagen, e intercalado). Ingeniería de datos > conteo total de parámetros.

Escogiendo una estrategia para un proyecto real¶

Este es el contenido relevante-para-entrevista.

P: "Quiero construir un modelo que, dada una foto, genere una descripción y responda preguntas de seguimiento."

R: Early fusion barato (estilo LLaVA). Encoder CLIP pre-entrenado + LLaMA pre-entrenado + MLP proyector + datos de instruction-tuning. Funciona en una sola GPU. Calidad de producción.

P: "Quiero construir un modelo que, dado un vídeo de 1 minuto, responda preguntas sobre él."

R: Unified-token, usando Gemini 1.5 / GPT-4o / Claude con visión vía API. No vas a entrenar esto. La infraestructura para entrenar un modelo unified-token de contexto 1-M es solo-laboratorio-frontera.

P: "Quiero retrieval de imagen zero-shot sobre un catálogo de 1M imágenes."

R: Late fusion (CLIP o SigLIP, de fábrica). Encodea cada imagen una vez en la ingesta, guarda el embedding. La query es un embedding de texto + búsqueda ANN. Barato y rápido.

P: "Quiero un tutor de gramática multi-modal (Fase 32 + X2): el usuario sube una foto de una frase de libro de texto; el tutor marca errores de forma verbal."

R: Pipeline OCR + LLM de texto. No hagas fusion multi-modal. Usa un modelo OCR dedicado (Tesseract o TrOCR pre-entrenado) para extraer la frase, después el tutor solo-texto de la Fase 32. La fusion de modalidad es overkill — el contenido de información de la foto es enteramente textual.

(Esa última respuesta es la que te presionaría en una entrevista. La tentación de usar modelos visión-lenguaje en todas partes es fuerte; la respuesta correcta a menudo es "OCR + texto".)

Resumen¶

Late fusion (CLIP): dos encoders + pérdida contrastiva. Inferencia barata. No puede generar.
Early fusion (Flamingo / LLaVA): encoder visual + LLM + cross-attention o proyección. Puede generar. Barato de entrenar si reusas componentes pre-entrenados. La gated cross-attention inicializada a cero preserva el LLM base.
Unified-token fusion (Chameleon / Gemini): un vocabulario, un transformer, una pérdida. Lo más potente. Lo más caro. Entrenamiento solo-laboratorio-frontera.

Siguiente: theory/04-llava-and-vision-language.md hace zoom en LLaVA — la arquitectura VLM en producción más accesible — en detalle.

Estrategia	Datos de pretraining	Datos de instruction-tune	Coste total de entrenamiento
Late fusion (CLIP)	400M pares (imagen, texto)	N/A	~\(10^{22}\) FLOPs
Early fusion con encoder + LLM congelados (Flamingo)	reuso — 0	~1.5M muestras intercaladas	~\(10^{22}\) FLOPs (mayormente amortizado en encoder + LLM)
Early fusion barato (LLaVA)	reuso — 0	~600k pares	~\(10^{20}\) FLOPs
Unified-token (Chameleon, Gemini)	1B–10B tokens multi-modal (intercalados)	varía	\(10^{24}\)–\(10^{25}\) FLOPs