Mezcla de expertos: qué revelan los parámetros activos y totales

Un modelo de mezcla de expertos puede hacer menos trabajo por token y, aun así, ser enorme a la hora de alojarlo. El modelo de lenguaje Kimi K3.1 Pro de Moonshot AI tiene 2.8T parámetros totales, pero activa 104B por token, según su anuncio oficial. La cifra menor ayuda a entender el cómputo; la mayor sigue siendo decisiva cuando hay que almacenar los pesos.

Las cifras de parámetros y las afirmaciones de las fuentes se verificaron el 24 de octubre de 2026. Los porcentajes de parámetros activos que aparecen a continuación son cálculos propios; no son mediciones de velocidad, ahorro de memoria ni calidad.

¿Qué es una mezcla de expertos?

La mezcla de expertos, o MoE por sus siglas en inglés, dota a un modelo de varias redes internas de procesamiento y selecciona solo algunas para cada entrada. Un parámetro es un valor numérico que el modelo aprende durante el entrenamiento. Los parámetros almacenados suelen denominarse pesos. Un token es una pequeña unidad de entrada o salida, a menudo un fragmento de palabra.

Imagina un edificio de consultas con muchas salas. En recepción, cada visitante recibe indicaciones para acudir a las salas que necesita. Solo algunas trabajan para atender esa visita, pero el edificio sigue teniendo todas las salas. En una capa MoE, el enrutador cumple la función de recepción y los expertos son las salas.

La comparación tiene un límite: hablamos de redes numéricas entrenadas, no de una plantilla de profesionales. No se puede dar por hecho que haya un experto jurídico, otro en programación y otro en contabilidad esperando su turno.

¿Cómo funciona la arquitectura MoE?

El enrutador elige rutas dentro del modelo y después se combinan sus resultados. Un transformer procesa las relaciones de contexto entre tokens. En los transformers MoE más habituales, varias redes expertas sustituyen a un bloque de propagación hacia delante, o feed-forward. Ese bloque transforma la representación numérica interna de un token; la atención es otro mecanismo, que le permite aprovechar el contexto que lo rodea.

El proceso es el siguiente:

1. La representación actual de un token llega a una capa MoE.
2. Un enrutador entrenado, también llamado compuerta, asigna una puntuación a cada experto.
3. Selecciona un subconjunto, a menudo los expertos con mayor puntuación. Es el enrutamiento top-k, donde k indica cuántos se eligen.
4. Los expertos seleccionados procesan esa representación. Sus salidas se ponderan y se combinan antes de continuar el procesamiento.

Esto ocurre en las capas MoE del modelo, de modo que la selección de expertos puede variar de un token a otro y de una capa a otra. La explicación de la arquitectura de PyTorch describe esa combinación ponderada; el artículo de Mistral sobre su modelo muestra cómo varían las elecciones entre capas.

¿Qué significa que una mezcla de expertos sea dispersa?

Dispersa significa que, para cada token, solo se ejecuta un subconjunto de expertos. Esta es la modalidad a la que se refieren las cifras de parámetros totales y activos de las fichas de modelos actuales. Los demás expertos pueden intervenir en otros tokens, incluidos los que se procesan en el mismo lote.

Un bloque feed-forward denso aplica toda su red a cada token. Las capas de expertos dispersas permiten almacenar más capacidad sin obligar a cada token a pasar por todos los expertos. Los componentes compartidos, incluida la atención en estos ejemplos, siguen trabajando.

Un modelo MoE sigue siendo un solo modelo

El enrutamiento MoE es distinto de elegir entre modelos de una API o pedir a varios chatbots que voten. El enrutador y los expertos se entrenan como partes de una misma red. Normalmente, la aplicación envía una solicitud a esa red; no selecciona un experto como quien elige un producto de un menú.

Para quien desarrolla una aplicación, esta distinción evita partir de una idea equivocada: elegir un modelo MoE no pone a su disposición un equipo de agentes especialistas que pueda controlar.

Modelos MoE: hay que leer juntas las cifras totales y activas

Los parámetros totales indican el tamaño del modelo almacenado; los activos, la ruta de cómputo por token que declara el fabricante. Ninguna de las dos cifras constituye una especificación completa de hardware. B significa mil millones; T, un millón de millones.

La última columna resulta de dividir los parámetros activos entre los totales y redondear. Describe las cifras publicadas por cada fabricante; no clasifica la eficiencia de los modelos. Tanto las arquitecturas como los criterios para contabilizar parámetros pueden variar.

Kimi K3.1 Pro: una pequeña parte de un modelo enorme

Kimi K3.1 Pro muestra por qué la cifra de parámetros «activos» no sirve como tamaño del modelo que hay que alojar. Al expresar el total de Moonshot en las mismas unidades, obtenemos 2,800B. El cálculo es 104 ÷ 2,800 × 100 = 3.7%, redondeado.

Eso significa que la cantidad declarada de parámetros activos es una pequeña parte del total. No significa que un sistema de inferencia pueda descartar los demás pesos, ni que la latencia de la API sea esa misma fracción de la de un modelo denso. La ruta cambia entre tokens y entre capas.

En su publicación de lanzamiento, Moonshot describe Pro como un K3 sometido a posentrenamiento y usa la etiqueta redondeada «3T-class». El anuncio oficial da la pareja exacta: 2.8T / 104B. Conviene usar esa especificación explícita para interpretar el tamaño del modelo.

Para quien desarrolla con una API, el modelo es un candidato que vale la pena evaluar. Para quien lo va a alojar, antes hay que comprobar la disponibilidad: en la fecha de verificación, Moonshot había prometido publicar los pesos completos para el 4 de noviembre de 2026. Una publicación prometida todavía no es un archivo disponible para desplegar. La guía de Kimi K3.1 Pro aborda las decisiones propias de ese lanzamiento.

Qwen3-235B-A22B: los parámetros activos no sustituyen a los totales

Qwen3-235B-A22B hace visible la distinción en su propio nombre. La ficha original del modelo de Qwen declara 235B parámetros totales y 22B activados, con 128 expertos, de los que se activan 8.

El cálculo es 22 ÷ 235 × 100 = 9.4%, redondeado. Para un asistente privado de documentos, esa cifra da una pista de cómo el modelo limita el cómputo por token. La planificación de memoria debe seguir contemplando el checkpoint completo elegido y el estado de las solicitudes que atiende.

No conviertas «22B activos» en «cabe en la misma memoria que un modelo denso de 22B». Mantén también cada cifra vinculada a su checkpoint: el nombre de una familia no basta para elegir los archivos de pesos, la precisión y la configuración de inferencia.

Mixtral 8x7B: por qué multiplicar las cifras del nombre lleva a un error

Mixtral 8x7B tiene componentes compartidos, así que su nombre no es una instrucción para multiplicar. La publicación de lanzamiento de Mistral declara 46.7B parámetros totales y 12.9B utilizados por token. Multiplicar las cifras del nombre equivale a contar los componentes compartidos como si pertenecieran a modelos completos separados.

El artículo de Mistral describe redes expertas feed-forward junto con un mecanismo de atención compartido. En cada capa, el enrutador elige 2 de 8 expertos. No son ocho modelos completos e independientes.

Con las cifras publicadas, el cálculo es 12.9 ÷ 46.7 × 100 = 27.6%, redondeado. Elegir 2 de 8 expertos representa el 25% de los expertos: el denominador es distinto. Los componentes compartidos son una de las razones por las que el porcentaje de expertos y el de parámetros no coinciden.

Para planificar el despliegue, usa el total indicado en la ficha y los archivos reales del checkpoint. Ni el nombre del producto ni la cantidad de expertos seleccionados revelan cuánto ocupan todos los pesos.

¿Por qué menos cómputo no garantiza menos latencia?

El enrutamiento disperso reduce el cómputo de los expertos frente a ejecutar una red densa de tamaño comparable; no promete el tiempo de respuesta de un modelo denso más pequeño. Así, MoE puede abaratar la inferencia por token de modelos con gran capacidad, aunque siga habiendo exigencias considerables de memoria y comunicación.

Las operaciones aritméticas son solo una parte de la inferencia, el proceso de ejecutar un modelo entrenado. El servidor también lee pesos, ejecuta componentes compartidos, enruta representaciones de tokens y, en ocasiones, las transfiere entre dispositivos. Una cifra menor de parámetros activos no elimina esas operaciones. Shazeer y sus colaboradores identifican los lotes pequeños por experto y el ancho de banda de red como limitaciones de rendimiento en el artículo original sobre MoE dispersa.

La capacidad de procesamiento y la latencia responden a preguntas de negocio distintas. La capacidad de procesamiento, o throughput, indica cuánto trabajo completa el servicio a lo largo del tiempo. La latencia indica cuánto espera una solicitud individual. Una cola nocturna de procesamiento de documentos puede beneficiarse de una configuración eficiente con lotes grandes; un asistente de soporte interactivo necesita ofrecer pronto la primera respuesta útil.

Procesar varios tokens o solicitudes en lotes puede mejorar el aprovechamiento del hardware. Sin embargo, cada token puede seleccionar expertos distintos, de modo que un lote puede utilizar una parte mucho mayor del modelo que un solo token. La cifra de parámetros activos no indica cuántos pesos consulta el servidor en todo un lote.

El procesamiento del prompt y la generación de tokens también exigen cosas distintas al sistema. El prefill procesa la entrada; el decode genera los tokens posteriores. vLLM, un software de inferencia para modelos de lenguaje, documenta opciones distintas de comunicación entre expertos para el prefill de alta capacidad de procesamiento y el decode de baja latencia. Nuestra guía de inferencia de LLM explica estas etapas y las mediciones que conviene separar.

Para elegir una API, compara el comportamiento observado con tus propias solicitudes. Una pareja de cifras de parámetros no revela hasta qué punto el proveedor agrupa el tráfico en lotes, qué longitud tiene su cola ni qué tan adecuado es su hardware para ese modelo.

Las contrapartidas que afectan al negocio

MoE desplaza parte de la carga de infraestructura: reduce el cómputo repetido a cambio de almacenar y coordinar un modelo más grande. La pregunta operativa es si ese intercambio conviene para tu carga de trabajo.

Memoria: todos los expertos necesitan espacio

Que un experto esté inactivo para este token no significa que se pueda eliminar del despliegue. En una configuración habitual de inferencia con pesos residentes, todos los pesos permanecen cargados en el conjunto del sistema, aunque cada token solo use una parte. La explicación de PyTorch señala expresamente este requisito de memoria.

Un cálculo inicial útil es almacenamiento de pesos ≈ parámetros totales × bytes por parámetro almacenado. Solo es un punto de partida: la precisión puede variar entre tensores, y los metadatos de archivo, el relleno, las réplicas y las asignaciones de memoria durante la ejecución aumentan el espacio necesario.

Los pesos no son todo el presupuesto de memoria. La caché KV almacena las claves y los valores de atención de tokens anteriores para poder reutilizarlos. Un asistente de documentos con conversaciones más largas o más solicitudes simultáneas necesita memoria adicional para el estado de esas solicitudes. La guía de la caché KV explica esta limitación por separado.

La cuantización, que consiste en almacenar los pesos con menor precisión numérica, puede reducir el espacio que ocupan. No convierte los parámetros totales en activos ni elimina la necesidad de validar la calidad de las salidas. La guía de cuantización de LLM aborda la elección de formato y precisión; el mecanismo se documenta en la introducción a la cuantización de Hugging Face.

Capacidad de procesamiento: cargar el modelo es solo el primer requisito

Un modelo puede cargarse correctamente y, aun así, no cumplir el objetivo del servicio. El paralelismo de expertos distribuye los expertos entre dispositivos, lo que permite alojar un modelo que supera la memoria de un solo dispositivo. También obliga a enviar las representaciones de los tokens a los dispositivos que contienen los expertos seleccionados y a combinar los resultados.

Esas transferencias hacen que las interconexiones, los enlaces entre dispositivos, formen parte del diseño del sistema de inferencia. Repartir capacidad entre máquinas mal conectadas no equivale a disponer de esa misma capacidad en un sistema bien interconectado. Es una consecuencia directa del patrón de comunicación descrito en la implementación de paralelismo de expertos de PyTorch.

Para un asistente interno con poco tráfico, el problema práctico es mantener capacidad fija infrautilizada. Para un servicio por lotes con mucho trabajo, el problema puede ser alimentar de forma continua el cómputo de los expertos. Ninguno de esos resultados depende solo de la cifra de parámetros activos.

Enrutamiento: los expertos más solicitados pueden crear cuellos de botella

Un enrutador entrenado no garantiza un uso perfectamente equilibrado del hardware. El análisis del enrutamiento de Mixtral de NVIDIA encontró que el tráfico concentrado en un tema podía repartir la carga de forma desigual entre expertos. Algunos procesos terminan pronto mientras otros siguen ocupados.

Por eso, una demostración con tareas variadas no basta para evaluar un servicio que procesa principalmente contratos o código. Hay que probar esa concentración de solicitudes, incluidas las más lentas, en vez de basarse solo en un promedio.

El software de inferencia puede compensarlo, pero hacerlo también consume recursos. vLLM documenta el equilibrado de carga mediante expertos redundantes y advierte de que esas copias adicionales consumen memoria de GPU que podría destinarse a la caché KV. Si los pesos del modelo caben muy justos en memoria, puede faltar espacio para la configuración que permita servirlo bien.

Cómo elegir un LLM de mezcla de expertos: API o alojamiento propio

Quien desarrolla con una API debe evaluar el servicio que recibe; quien aloja el modelo también debe evaluar el despliegue completo. Ambos necesitan salidas aceptables, pero solo uno gestiona directamente dónde residen los expertos.

Para quienes desarrollan con una API, la arquitectura aporta contexto, pero no es por sí sola un motivo para cambiar de modelo. Evalúa tareas representativas, seguimiento de instrucciones, uso de herramientas cuando corresponda, tiempo hasta el primer token y tiempo total de respuesta con la concurrencia prevista. Registra los intentos fallidos y los reintentos. La eficiencia de inferencia del proveedor no determina tu factura ni el trabajo necesario para obtener un resultado aceptable.

Para quienes alojan el modelo en su propia infraestructura, el punto de partida es el checkpoint descargable exacto, su licencia y una implementación de inferencia compatible. Después hay que evaluar la precisión de los pesos, la memoria del modelo completo, el margen para la caché, las conexiones entre dispositivos y el rendimiento bajo carga. Nuestra guía de modelos con pesos abiertos distingue el acceso a los archivos de los derechos y las responsabilidades que implica operarlos.

Para quienes compran un servicio y responden por sus compromisos, la pregunta es si el candidato completa trabajo que cumpla los criterios de aceptación dentro del tiempo de respuesta exigido y sobre la infraestructura prevista. «Millones de millones de parámetros totales, miles de millones activos» describe una arquitectura; no garantiza un nivel de servicio.

1. 1

   Define la carga de trabajo antes de comparar modelos

   Usa solicitudes representativas con criterios de aceptación claros. Separa el trabajo interactivo del trabajo en cola e incluye las entradas largas y los temas recurrentes que tu aplicación procesa en la práctica.

2. 2

   Evalúa la vía de acceso que vas a utilizar

   Si usarás una API, prueba el proveedor y el endpoint previstos. Si alojarás el modelo, registra el checkpoint exacto, la precisión, el entorno de ejecución y el hardware. Una vía de inferencia distinta produce un resultado operativo distinto.

3. 3

   Prueba la capacidad y la calidad al mismo tiempo

   Aumenta el trabajo concurrente mientras controlas el uso de memoria, los tiempos de espera, la calidad de las salidas y los fallos. Una respuesta aislada rápida no demuestra una capacidad de procesamiento útil; una capacidad alta tampoco demuestra una latencia aceptable para uso interactivo.

4. 4

   Cambia de modelo solo si mejora el trabajo real

   Adopta el candidato cuando mejoren tanto el trabajo que supera los criterios de aceptación como el cumplimiento de los requisitos operativos. Conserva el modelo actual si esas mejoras no aparecen. Pospón el alojamiento propio si todavía no están disponibles los archivos de pesos necesarios o una vía de despliegue compatible.

Si la API actual ya cumple los requisitos de calidad y tiempo de respuesta, la etiqueta de su arquitectura no cambia la decisión de quien desarrolla con ella. En cambio, quien haya dimensionado un despliegue a partir de los parámetros activos debería revisar ese plan ahora.

¿Qué se exagera al hablar de MoE?

La exageración consiste en afirmar que la dispersión ofrece todas las ventajas de un modelo enorme con todas las características operativas de uno pequeño. MoE permite separar capacidad y cómputo de una forma útil, pero con condiciones.

Los expertos no son necesariamente especialistas en un área. El análisis de Mixtral de Mistral encontró patrones de enrutamiento que no separan claramente las disciplinas académicas. Un experto entrenado no es un especialista acreditado, y que el enrutador lo seleccione no explica por qué una respuesta es correcta.

Tener más parámetros totales no demuestra que las respuestas sean mejores. Tampoco lo demuestra una proporción menor de parámetros activos. Importan el entrenamiento, la arquitectura y la tarea. La tabla anterior explica los tamaños declarados; deliberadamente, no es una clasificación de calidad.

Una proporción menor de parámetros activos no implica un descuento ni una aceleración equivalentes. Por sí sola, no dice nada sobre las tarifas del proveedor, las colas, las transferencias de red o la cantidad de tokens que necesita generar tu tarea.

El artículo de investigación que fundamenta la mezcla de expertos

El artículo de Shazeer y sus colaboradores de 2017 formalizó una influyente capa MoE con activación dispersa que aumentaba la capacidad del modelo sin incrementar el cómputo en la misma proporción. Redes neuronales descomunalmente grandes: la capa de mezcla de expertos con activación dispersa es la referencia primaria de ese mecanismo. Su análisis del equilibrio de carga y del rendimiento distribuido recuerda que las contrapartidas operativas formaban parte de la propuesta desde el principio.

Preguntas frecuentes sobre los modelos MoE

¿Qué es la mezcla de expertos en un LLM?

Es una forma de construir un modelo de lenguaje grande con varias redes expertas internas y un enrutador entrenado. En una MoE dispersa, cada token utiliza solo los expertos seleccionados en cada capa MoE. La aplicación sigue llamando a un solo modelo.

¿GPT-4 utiliza una mezcla de expertos?

El informe técnico de GPT-4 no revela más detalles de la arquitectura, incluido el tamaño del modelo. No aporta un desglose de parámetros MoE verificado por el fabricante, por lo que las cifras que circulan como rumores no deben usarse como datos para un despliegue.

¿Qué implica hacer fine-tuning de un modelo MoE?

El ajuste fino adapta el comportamiento aprendido de un modelo; no elimina los requisitos de alojamiento de todos sus pesos. Evalúa la calidad del modelo adaptado en tus tareas y su comportamiento de enrutamiento con tráfico representativo. La guía de MoE de Hugging Face aborda los distintos problemas de sobreajuste y equilibrio que intervienen.

Qué hacer antes del próximo despliegue

El lunes, añade una ficha de inferencia a cada modelo de tu selección. Registra las cifras totales y activas declaradas por el fabricante, la fuente y el checkpoint o endpoint de API exacto. Para el acceso mediante un proveedor, añade los resultados de tus tareas y las mediciones de latencia. Para el alojamiento propio, añade el espacio que ocupan todos los pesos, la reserva para caché y el rendimiento con el tráfico previsto. Esa ficha resulta más útil que ordenar los candidatos por la cifra más grande de su publicidad.

Para recibir explicaciones prácticas sobre la infraestructura que hace posibles los productos de IA, suscríbete al boletín.