Proyecciones en transformers: ¿hacen falta 3?

¿Los transformers necesitan de verdad tres proyecciones separadas para Query, Key y Value? Según un estudio sistemático publicado en arXiv en 2026, no siempre. La variante que comparte proyecciones (Q-K=V) recorta la caché KV a la mitad con apenas 3,1% de degradación en perplejidad. Acá te cuento cuándo conviene y cuándo no.

Las proyecciones en transformers son las tres transformaciones lineales (Query, Key y Value) que cada capa de atención aplica a la entrada para decidir a qué tokens mirar. El estudio Do transformers need three projections? Systematic study of QKV variants analiza qué pasa cuando compartís o eliminás algunas de esas matrices para bajar memoria e inferencia, sin tirar a la basura la arquitectura estándar ni reentrenar todo desde cero.

En 30 segundos

El estudio probó tres formas de compartir proyecciones: Q-K=V, Q=K-V y Q=K=V, sobre modelos de 300M y 1.200M de parámetros.
Q-K=V baja la caché KV un 50% con solo 3,1% de degradación en perplejidad (la métrica que mide qué tan bien predice el modelo).
Combinando proyecciones compartidas con MQA, la reducción de caché trepa hasta el 96,9%.
GQA y MQA ya están en modelos de producción como Llama 2 70B, Mistral 7B y DeepSeek-V2.
No es magia: en algunas tareas la calidad cae más, así que conviene medir antes de mandarlo a producción.

¿Para qué sirven Query, Key y Value en la atención?

Ponele que el modelo está leyendo una oración y llega a la palabra “banco”. ¿Habla de un asiento o de una entidad financiera? Para resolverlo, la capa de atención compara cada token con todos los demás. Ahí entran las tres proyecciones.

La Query es la “pregunta” que lanza el token actual. La Key es la “etiqueta” con la que cada otro token se ofrece como respuesta. El Value es la información que se devuelve cuando hay match. El modelo multiplica Query por Key, saca un puntaje de atención, lo normaliza y con eso pondera los Values. Simple en la idea, costoso en la práctica. Te puede servir nuestro artículo sobre seguridad en sistemas IA.

El problema aparece en inferencia. Para no recalcular todo en cada paso, los modelos guardan las Keys y Values ya proyectadas en la famosa caché KV. Esa caché crece con la longitud del contexto y se come la RAM de la GPU. Cualquiera que haya intentado correr un modelo de 70B con contexto largo en una placa modesta sabe de qué hablo.

¿Qué variantes de QKV probó el estudio?

Históricamente, hasta los papers de GQA (2023), se asumió que tener tres matrices distintas era “la forma correcta” de hacer atención. El estudio sobre proyecciones en transformers cuestiona ese dogma y mide qué se pierde al compartir matrices. Estas son las configuraciones que comparó:

Variante	Qué comparte	Implicación principal
QKV estándar	Nada (tres matrices)	Máxima expresividad, máximo costo de memoria
Q-K=V	Key y Value usan la misma matriz	Caché KV cae ~50% con degradación mínima
Q=K-V	Query y Key comparten matriz	Atención más simétrica, menos parámetros
Q=K=V	Las tres comparten una matriz	Máximo ahorro, mayor riesgo de perder calidad

proyecciones en transformers diagrama explicativo

Algo interesante: algunas de estas variantes usan atención asimétrica con codificaciones posicionales 2D para compensar la pérdida de grados de libertad. O sea, no es solo borrar matrices y rezar. Hay ingeniería atrás para que el modelo siga distinguiendo bien quién atiende a quién.

¿Cuánto se reduce la caché KV sin perder calidad?

Acá viene lo bueno. La variante Q-K=V logra un 50% de reducción en la caché KV con un 3,1% de degradación en perplejidad. ¿Y por qué 3,1% se considera aceptable? Porque la perplejidad mide cuánto “se sorprende” el modelo al predecir el siguiente token, y una diferencia de tres puntos porcentuales, en la práctica, casi no se nota en la salida final para muchas tareas.

Pensá en el trade-off. Estás cambiando la mitad de la memoria de tu caché por una caída de calidad que, en muchos casos de uso, ni vas a percibir leyendo las respuestas. Para un servicio que atiende miles de pedidos en simultáneo, esa mitad de memoria liberada significa más usuarios por GPU o contextos más largos sin cambiar el hardware. Para más detalles técnicos, mirá cómo ChatGPT procesa información.

Eso sí: el 3,1% es un promedio. En tareas donde el modelo necesita distinguir relaciones finas entre tokens, la degradación puede ser mayor. Por eso la recomendación honesta es medir en tu propio dataset antes de comprometerte.

¿Cómo se combina esto con GQA y MQA?

GQA (Grouped-Query Attention) y MQA (Multi-Query Attention) atacan el mismo problema desde otro ángulo. En vez de tocar las matrices de proyección, reducen cuántas cabezas de atención comparten las mismas Keys y Values. MQA es el extremo: todas las cabezas de Query comparten una sola Key y un solo Value. GQA es el punto medio, con grupos de cabezas que comparten.

Lo bueno es que las dos técnicas son compatibles. Combinando proyecciones compartidas con MQA, el estudio reporta hasta un 96,9% de reducción de caché. Leído de otra forma: te quedás con apenas el 3% de la memoria original de la caché KV. Para inferencia en tiempo real o en dispositivos periféricos, eso cambia el juego (y no lo digo como muletilla, lo digo con el número adelante).

Estas ideas no son teóricas. El paper original de GQA ya alimentó modelos que usás hoy: Llama 2 70B, Mistral 7B y DeepSeek-V2 implementan variantes de atención agrupada justamente para sostener contextos largos sin reventar la memoria.

¿Funciona igual en todos los tamaños y tareas?

No. Y esto es clave para no comerte un cuento.

El estudio corrió experimentos en modelos de 300M y 1.200M de parámetros, sobre modelado de lenguaje, visión (con arquitecturas tipo ViT) y tareas sintéticas diseñadas para estresar el mecanismo de atención. El patrón general es que las proyecciones compartidas aguantan bien en modelado de lenguaje, pero en tareas sintéticas que exigen razonamiento posicional fino la cosa se pone más exigente. Cubrimos ese tema en detalle en nuestro artículo sobre arquitectura de modelos lenguaje.

Subís el modelo, lo probás en un benchmark de lenguaje, anda bárbaro, lo llevás a una tarea de visión con dependencias espaciales complejas y de repente la variante Q=K=V que tan bien te venía empieza a fallar porque ahí sí importaba tener proyecciones distintas. Por eso el “depende” no es una evasiva: es el resultado real del estudio.

¿Cuándo conviene usar proyecciones compartidas?

Bajemos a tierra con recomendaciones concretas:

Inferencia en tiempo real o dispositivos periféricos: si la memoria es tu cuello de botella, Q-K=V combinado con MQA es la apuesta más rentable. El 96,9% de ahorro de caché habilita correr modelos donde antes ni arrancaban.
Servicios con muchos pedidos en paralelo: liberar la mitad de la caché con Q-K=V te deja meter más usuarios por GPU sin tocar el hardware. Si alguna vez peleaste con una factura de cloud, esto te interesa.
Entrenamiento con presupuesto ajustado: menos parámetros de proyección significa menos memoria durante el entrenamiento, útil cuando no tenés un cluster gigante a mano.
Cuándo NO hacerlo: si tu aplicación depende de razonamiento posicional fino o relaciones sutiles entre tokens (ciertas tareas de visión, parsing estructurado), no sacrifiques calidad por eficiencia sin medir primero.

Si vas a montar la infraestructura para servir estos modelos, ya sea un VPS o un servidor dedicado con GPU, conviene tener el alojamiento bajo control desde el día uno; en donweb.com tenés opciones de hosting y cloud para armar el entorno sin depender de terceros para cada ajuste.

Errores comunes al optimizar las proyecciones

Asumir que el ahorro de caché es gratis: el 3,1% de degradación es un promedio, no una garantía. Mucha gente lee “50% menos memoria” y olvida medir el impacto en su tarea real. Corré tu propio benchmark antes de prometer nada.
Confundir reducir proyecciones con reducir cabezas: compartir matrices (Q-K=V) y agrupar cabezas (GQA/MQA) son cosas distintas que atacan la memoria por vías separadas. Se combinan, no se reemplazan.
Aplicar Q=K=V a ciegas: es la variante más agresiva y la que más riesgo tiene de tirar abajo la calidad en tareas exigentes. No la uses como default solo porque ahorra más.
Ignorar las codificaciones posicionales: varias de estas variantes funcionan porque compensan con atención asimétrica y posicionales 2D. Si copiás la idea sin esa parte, los resultados no van a coincidir con el paper.

Preguntas Frecuentes

¿Realmente necesitamos tres proyecciones en transformers?

No siempre. El estudio de 2026 muestra que compartir Key y Value en una sola matriz (Q-K=V) reduce la caché KV un 50% con apenas 3,1% de degradación. Las tres proyecciones separadas dan máxima expresividad, pero en muchos casos de uso ese costo de memoria no se justifica.

¿Qué es la perplejidad y por qué importa acá?

La perplejidad mide qué tan bien un modelo predice el siguiente token: cuanto más baja, mejor. En este estudio se usa como termómetro de calidad: una degradación de 3,1% indica que el modelo perdió poco poder predictivo a cambio de un gran ahorro de memoria.

¿Qué diferencia hay entre GQA y MQA?

MQA (Multi-Query Attention) hace que todas las cabezas de Query compartan una sola Key y un solo Value, el máximo ahorro de memoria. GQA (Grouped-Query Attention) es el punto medio: agrupa cabezas para que cada grupo comparta Keys y Values, equilibrando memoria y calidad. Sobre eso hablamos en nuestro artículo sobre búsqueda semántica de Google.

¿Cuánto se puede reducir la caché KV combinando técnicas?

Hasta un 96,9%, según el estudio, al combinar proyecciones compartidas con MQA. Eso deja la caché en cerca del 3% de su tamaño original, lo que habilita correr modelos grandes en hardware limitado o sostener contextos mucho más largos.

¿Qué modelos de producción ya usan estas ideas?

Llama 2 70B, Mistral 7B y DeepSeek-V2 implementan variantes de atención agrupada (GQA/MQA) para reducir el costo de la caché KV. Son modelos abiertos y ampliamente usados, lo que confirma que estas optimizaciones ya salieron del paper y están en el mundo real.

Conclusión

El mensaje del estudio es claro: las tres proyecciones del transformer no son sagradas. Compartir Key y Value (Q-K=V) te da la mitad de la caché KV a cambio de un 3,1% de calidad, y sumando MQA llegás a recortar casi el 97% de esa memoria. Para inferencia en tiempo real, dispositivos periféricos o servicios con mucha concurrencia, es de las optimizaciones con mejor relación esfuerzo-resultado que vas a encontrar.

Lo que tenés que hacer ahora es simple: si servís modelos y la memoria te aprieta, probá Q-K=V con MQA en tu propio dataset y medí la perplejidad antes y después. Si el número aguanta, ganaste capacidad gratis. Si tu tarea exige razonamiento posicional fino, frená y no sacrifiques calidad por ahorro. La decisión, como casi siempre en este rubro, depende de tus números, no de los del paper.

¿Los transformers necesitan tres proyecciones QKV?