MoE on KnightLi Blog

Evolución de la arquitectura de los LLM entre 2023 y 2026: tokenizadores, codificación posicional, atención, MoE, normalización y funciones de activación

Sun, 17 May 2026 08:53:29 +0800

Entre 2023 y 2026, la arquitectura de los LLM pareció cambiar en muchas direcciones: los tokenizadores se hicieron más grandes, la codificación posicional se desplazó hacia RoPE, la atención pasó de MHA a GQA, ventanas deslizantes y MLA, MoE volvió a ser una opción dominante, y la normalización y las funciones de activación se movieron hacia combinaciones como RMSNorm y SwiGLU.

Pero la idea principal no es que Transformer haya sido reemplazado. La idea central es que el núcleo Transformer siguió vigente, mientras casi todos sus componentes se optimizaron para contextos más largos, menor coste de inferencia, mayor eficiencia de entrenamiento y mejor capacidad multilingüe.

Primero, la vista general

Un LLM puede dividirse aproximadamente en varias partes:

Tokenizador: convierte texto en tokens que el modelo puede entender.
Codificación posicional: indica al modelo dónde está cada token en la secuencia.
Mecanismo de atención: decide qué contexto debe mirar cada token.
Red feed-forward: aplica transformaciones no lineales más complejas en cada posición.
Normalización: estabiliza el entrenamiento.
Función de activación: da capacidad no lineal a la red.
MoE: divide parte de la red feed-forward en varios expertos y activa solo algunos cada vez.

La evolución de 2023 a 2026 puede entenderse como la optimización sucesiva de estas piezas.

Tokenizadores: de “dividir texto” a “ahorrar tokens”

El tokenizador convierte lenguaje natural en secuencias de tokens. El modelo no ve el texto directamente; ve IDs de tokens.

Los tokenizadores anteriores solían ser más eficientes en inglés y menos eficientes para chino, código y texto multilingüe. Si una misma frase se divide en demasiadas piezas pequeñas, consume más ventana de contexto y aumenta tanto el coste de entrenamiento como el de inferencia.

Una tendencia clara de los últimos años es tener vocabularios más grandes y mejor soporte multilingüe. Llama 3 usa un vocabulario de 128K tokens, y Meta explicó que esto codifica el lenguaje de forma más eficiente y mejora el rendimiento del modelo. Qwen, DeepSeek y otros modelos también prestan mucha atención a la eficiencia de tokens en chino, código y escenarios multilingües.

Para principiantes: cuanto mejor es el tokenizador, menos fragmentado queda el mismo texto y más información útil cabe en la misma longitud de contexto.

Codificación posicional: RoPE se volvió dominante

El lenguaje tiene orden. Las mismas palabras pueden cambiar por completo de significado si se reordenan. La codificación posicional introduce esa información de orden en el modelo.

Los primeros Transformers usaban codificación posicional absoluta, donde la posición 1, la posición 2 y la posición 3 tenían vectores propios. Los LLM posteriores adoptaron con frecuencia RoPE, o Rotary Positional Embedding. RoPE integra la información de posición dentro del cálculo de atención y es más amigable para extender el contexto.

Desde la familia Llama hasta muchos modelos abiertos, RoPE se ha convertido en un estándar de facto. Para soportar contextos más largos, los modelos también pueden ajustar la base frequency de RoPE, aplicar RoPE scaling o combinarlo con atención de ventana deslizante o atención por bloques.

En pocas palabras, RoPE no hace que un modelo sea “mágicamente más inteligente”; ayuda a que el modelo maneje mejor relaciones de posición relativa en textos largos.

Atención: de MHA a GQA, ventanas deslizantes y MLA

La atención es el núcleo de Transformer. Permite que cada token mire los tokens más relevantes del contexto para la tarea actual.

La versión clásica es MHA, o Multi-Head Attention. Tiene múltiples cabezas de atención, cada una aprendiendo una forma distinta de enfocar. El problema es que, a medida que crecen el modelo y el contexto, el KV cache se vuelve costoso y sube el coste de inferencia.

Después de 2023, la principal dirección de optimización de la atención fue reducir el coste de inferencia.

GQA, o Grouped-Query Attention, fue un paso importante. Permite que varias query heads compartan menos key/value heads, reduciendo la presión del KV cache. Meta adoptó explícitamente GQA en Llama 3 para mejorar la eficiencia de inferencia.

Mistral 7B representa otra dirección: atención de ventana deslizante. En lugar de hacer que cada token mire todo el historial, se centra principalmente en una ventana cercana, reduciendo la presión computacional de secuencias largas. Para muchas tareas, el contexto local ya es muy útil.

DeepSeek-V2/V3 llevó esta optimización más lejos con MLA, o Multi-head Latent Attention. Su objetivo es comprimir el KV cache y reducir la presión de memoria durante la inferencia. El informe técnico de DeepSeek-V3 lista MLA y DeepSeekMoE como elementos centrales de su arquitectura.

Estas técnicas pueden resumirse así:

MHA: enfoque clásico, fuerte pero caro.
GQA: reduce mucho el coste de KV cache con poca pérdida de expresividad.
Atención de ventana deslizante: reduce el coste de atención global en contextos largos.
MLA: comprime aún más la caché de atención para una inferencia eficiente.

MoE: muchos parámetros, pero solo algunos se usan cada vez

MoE significa Mixture of Experts.

Un modelo denso activa todos sus parámetros para cada token. MoE coloca muchos expertos dentro del modelo, pero enruta cada token solo a unos pocos. Así, el número total de parámetros puede ser muy grande, mientras que los parámetros activos por paso de inferencia siguen siendo más reducidos.

Mixtral 8x7B, lanzado a finales de 2023, fue un momento importante para que MoE volviera al centro de la conversación. El artículo de Mistral explica que Mixtral 8x7B sigue en gran parte la arquitectura de Mistral 7B, pero reemplaza cada bloque feed-forward por 8 expertos y usa enrutamiento disperso para seleccionar parte de ellos durante el cálculo.

Después, DeepSeek-V3 convirtió MoE en una ruta central. Tiene una cantidad total de parámetros muy grande, pero cada token activa solo una parte, usando DeepSeekMoE para reducir coste de entrenamiento e inferencia. Qwen3 y otras familias también ofrecen variantes densas y MoE, lo que muestra que MoE pasó de ser una técnica de investigación a una opción de ingeniería dominante.

Para principiantes: un modelo denso es como una empresa donde todos asisten a cada reunión. MoE es como dividir la empresa en equipos expertos y llamar solo a los equipos relevantes para cada problema.

MoE también tiene dificultades claras:

El router debe aprender a enviar tokens a expertos adecuados.
La carga debe equilibrarse para que no todos los tokens caigan en pocos expertos.
El entrenamiento y la inferencia distribuidos son más complejos.
Tener muchos parámetros totales no hace automáticamente barato el despliegue.

Normalización: RMSNorm se volvió común

La normalización estabiliza la distribución de valores intermedios dentro de la red neuronal. Al entrenar modelos grandes, valores inestables dificultan la convergencia y pueden volver el entrenamiento menos fiable.

Los primeros Transformers solían usar LayerNorm. Muchos modelos de estilo Llama pasaron después a RMSNorm. RMSNorm es más simple que LayerNorm: no calcula la media y se centra en la escala de raíz cuadrática media. Es más ligero y suficientemente estable en la práctica.

No hace falta memorizar la fórmula. Basta con recordar que RMSNorm es un estabilizador más ligero. No determina por sí solo la capacidad del modelo, pero afecta a la estabilidad, la velocidad y la implementación.

Funciones de activación: de ReLU/GELU a SwiGLU

Las funciones de activación añaden capacidad no lineal a las redes neuronales. Sin ellas, una red profunda se parecería demasiado a una transformación lineal.

Los Transformers anteriores usaban a menudo GELU. En Llama, Mistral, Qwen, DeepSeek y otros LLM modernos, es más común ver SwiGLU o variantes similares de GLU. SwiGLU suele aparecer dentro de la red feed-forward y controla el flujo de información mediante compuertas.

Una analogía sencilla: una función de activación normal es como un interruptor fijo, mientras que SwiGLU se parece más a una válvula aprendible. No solo decide si pasa información; también aprende qué información debe amplificarse.

SwiGLU hace que la capa feed-forward sea algo más compleja, pero en la práctica de modelos grandes se ha vuelto un componente común de alto rendimiento.

Tendencia general de 2023 a 2026

La línea temporal puede resumirse así:

2023: Llama, Mistral 7B, Mixtral y otros modelos abiertos popularizaron combinaciones como RoPE, RMSNorm, SwiGLU, GQA, atención de ventana deslizante y MoE.
2024: Llama 3, Qwen2.5, DeepSeek-V2/V3 y otros ampliaron vocabularios, mejoraron contexto largo, reforzaron la eficiencia de inferencia y pusieron MoE y atención eficiente en el centro.
2025: DeepSeek-V3/R1 hizo que más personas prestaran atención a MLA, DeepSeekMoE, FP8, MTP y a la conexión profunda entre optimización arquitectónica e ingeniería de sistemas.
2026: la tendencia sigue siendo eficiencia y madurez de ingeniería: los modelos densos buscan capacidad general estable, los MoE amplían capacidad y la atención eficiente reduce el coste del contexto largo.

El cambio más importante no fue que una pieza reemplazara a Transformer. Fue entender que sumar parámetros no basta: arquitectura, datos, sistema de entrenamiento y servicio de inferencia deben optimizarse juntos.

Cómo debería aprenderlo un principiante

Si empiezas desde cero, no conviene intentar leer todos los papers de entrada. Un mejor orden sería:

Entender la estructura básica de Transformer: token, embedding, attention y FFN.
Entender por qué RoPE, RMSNorm y SwiGLU se volvieron comunes.
Estudiar GQA y KV cache para comprender por qué la inferencia consume tanta memoria.
Aprender MoE, especialmente la diferencia entre parámetros totales y parámetros activos.
Finalmente, leer informes de modelos como DeepSeek-V3, Mixtral y Llama 3 para ubicar cada componente en modelos reales.

No trates estos términos como conceptos aislados. La mayoría responden a la misma pregunta: cómo hacer modelos más fuertes que todavía puedan entrenarse, desplegarse y servir respuestas con rapidez.

Resumen

La evolución de la arquitectura de LLM entre 2023 y 2026 puede verse como la maduración de ingeniería de Transformer. Los tokenizadores reducen desperdicio de tokens, RoPE representa mejor la posición, GQA, la atención de ventana deslizante y MLA reducen el coste de atención, MoE amplía capacidad controlando la computación activa, y RMSNorm junto con SwiGLU hacen que el entrenamiento y la representación sean más estables y eficientes.

Para principiantes, lo importante no es memorizar términos. Lo importante es captar la línea principal: casi todos los cambios modernos en arquitectura LLM tratan de equilibrar coste, eficiencia, longitud de contexto y escalabilidad.

Referencias:

Ejecutar DeepSeek V4 en local: estimaciones de VRAM para versiones Pro, Flash y Base

Fri, 01 May 2026 11:55:25 +0800

DeepSeek V4 y Gemma 4 no están en la misma categoría para despliegue local. Con Gemma 4 todavía tiene sentido hablar de ejecutar modelos 26B o 31B en GPUs de 24GB o 32GB. DeepSeek V4 es un modelo MoE enorme, y el despliegue local completo entra rápidamente en territorio de estaciones multi-GPU o servidores.

El lanzamiento oficial DeepSeek V4 Preview incluye principalmente dos modelos de inferencia:

DeepSeek-V4-Pro: 1.6T total / 49B active params
DeepSeek-V4-Flash: 284B total / 13B active params

La colección oficial de Hugging Face también incluye dos modelos Base:

DeepSeek-V4-Pro-Base
DeepSeek-V4-Flash-Base

Este artículo solo estima VRAM cuando se cargan los pesos completos. En modelos MoE, active params afecta sobre todo al cómputo por token. No significa que solo esos parámetros deban cargarse.

Resumen rápido

Escala de VRAM	Realista	No esperes
24GB	No puede cargar DeepSeek V4 completo; usa modelos destilados o API	V4-Flash / V4-Pro local completo
48GB	Aún no es adecuado para carga completa	V4-Flash Q4 estable
80GB	Pruebas V4-Flash Q2/Q3 u offload pesado	V4-Pro
128GB	V4-Flash Q4 empieza a ser más realista	V4-Pro Q4
192GB	V4-Flash FP8/Q6 más cómodo; Pro Q2 experimental	V4-Pro Q4
256GB	V4-Flash FP8 cómodo; Pro Q2/Q3 puede probarse	V4-Pro Q5+
512GB	V4-Pro Q4 empieza a discutirse	V4-Pro FP8
1TB+	V4-Pro FP8 y Pro-Base de bajo bit	Despliegue barato en una máquina
2TB+	Clase Pro-Base FP8	Estación común

Si tu objetivo es correr un modelo en un PC personal, DeepSeek V4 no es el objetivo adecuado. Es más realista usar API oficial, esperar cuantizaciones comunitarias maduras, usar modelos destilados o elegir modelos locales de 7B a 70B.

Tamaños oficiales de pesos

Las cifras vienen de model.safetensors.index.json en los repositorios oficiales de Hugging Face.

Model	Parameter Scale	Official Weight Size	Notes
`DeepSeek-V4-Flash`	284B total / 13B active	159.61GB	Inference model, smallest in this group
`DeepSeek-V4-Pro`	1.6T total / 49B active	864.70GB	Inference model, stronger but enormous
`DeepSeek-V4-Flash-Base`	284B total	294.67GB	Base model, closer to full FP8 weight size
`DeepSeek-V4-Pro-Base`	1.6T total	1606.03GB	Base model, about 1.6TB

Incluso el V4-Flash más pequeño se acerca a 160GB de pesos oficiales. No debe tratarse como un 13B solo por tener 13B active params.

Estimación de VRAM para DeepSeek V4 Flash

V4-Flash es la variante más abordable para experimentos locales, pero sigue sin ser un modelo de una sola GPU de consumo.

Version / Quantization	Estimated Weight Size	Minimum VRAM	Safer VRAM	Best For
`FP8 / official weights`	159.61GB	192GB	256GB	Multi-GPU servers, inference service
`Q6`	120GB	160GB	192GB	Quality-first quantization tests
`Q5`	100GB	128GB	160GB	Quality/size balance
`Q4`	80GB	96GB	128GB	More realistic starting point for Flash
`Q3`	60GB	80GB	96GB	Large-VRAM single GPU or multi-GPU tests
`Q2`	40GB	48GB	64GB	Extreme low-bit experiments with clear quality risk

Si aparecen builds maduros de V4-Flash Q4, probablemente seguirán sin ser modelos para 24GB. El punto de partida realista es 96GB a 128GB de VRAM total, o setups con offload que sacrifican velocidad por capacidad.

Estimación de VRAM para DeepSeek V4 Pro

V4-Pro es el modelo de inferencia insignia, con unos 864.70GB de pesos oficiales.

Version / Quantization	Estimated Weight Size	Minimum VRAM	Safer VRAM	Best For
`FP8 / official weights`	864.70GB	1TB	1.2TB+	Multi-node or multi-GPU inference service
`Q6`	648GB	768GB	1TB	High-quality quantized service
`Q5`	540GB	640GB	768GB	Quality/cost balance
`Q4`	432GB	512GB	640GB	Lowest practical quality line for Pro
`Q3`	324GB	384GB	512GB	Low-bit experiments
`Q2`	216GB	256GB	320GB	Extreme experiments with high risk

Para usuarios individuales, V4-Pro se consume mejor por API. Para despliegue local completo, trátalo como modelo de servidor multi-GPU.

Estimación de VRAM para Flash-Base y Pro-Base

Los modelos Base suelen ser para investigación, fine-tuning o entrenamiento continuo, no para chat común.

V4-Flash-Base pesa unos 294.67GB:

Version / Quantization	Estimated Weight Size	Minimum VRAM	Safer VRAM	Best For
`FP8 / official weights`	294.67GB	384GB	512GB	Research, preprocessing, evaluation
`Q6`	221GB	256GB	320GB	High-quality quantization research
`Q5`	184GB	224GB	256GB	Quality/size balance
`Q4`	147GB	192GB	224GB	Lower-cost Base experiments
`Q3`	111GB	128GB	160GB	Low-bit experiments
`Q2`	74GB	96GB	128GB	Extreme experiments

V4-Pro-Base pesa unos 1606.03GB:

Version / Quantization	Estimated Weight Size	Minimum VRAM	Safer VRAM	Best For
`FP8 / official weights`	1606.03GB	2TB	2.4TB+	Large-scale research clusters
`Q6`	1205GB	1.5TB	2TB	High-quality quantization research
`Q5`	1004GB	1.2TB	1.5TB	Research and evaluation
`Q4`	803GB	1TB	1.2TB	Low-bit research
`Q3`	602GB	768GB	1TB	Extreme low-bit research
`Q2`	402GB	512GB	640GB	Extreme experiments

Este tipo de modelo no debe evaluarse con la pregunta “¿lo corre una GPU doméstica?”. Incluso Q4 queda fuera de la comodidad de la mayoría de estaciones.

Por qué active params no basta

MoE activa solo parte de los expertos por token, por eso el cómputo puede ser mucho menor que el total de parámetros. Pero eso no significa que la VRAM solo tenga que cargar los parámetros activos.

El despliegue local completo depende de:

si todos los expertos deben residir en GPU;
si hay carga bajo demanda de expertos;
coste de transferencia CPU-GPU;
latencia de offload a NVMe;
crecimiento de KV cache con contexto largo;
sobrecarga de runtime en contexto muy largo;
coste de comunicación multi-GPU o multinodo.

V4-Pro con 49B active no se despliega como un 49B. V4-Flash con 13B active tampoco debe tratarse como un 13B pequeño.

Cómo elegir

Si eres usuario individual:

no intentes alojar DeepSeek V4 completo;
usa la API oficial cuando necesites sus capacidades;
para despliegue privado, revisa primero tu infraestructura multi-GPU;
con 24GB a 48GB, los modelos cuantizados 7B, 14B, 32B o 70B son más prácticos.

Con 128GB a 256GB de VRAM total, observa implementaciones estables de V4-Flash Q4/Q5. Con 512GB+, V4-Pro Q4 empieza a ser un objetivo de validación de ingeniería.

La pregunta clave no es “qué archivo cuantizado descargo”, sino “si tengo capacidad de inferencia de sistema para este modelo”.