Mixture of experts: por qué un modelo enorme apenas usa sus parámetros

Un modelo gigante que casi no calcula

Lees la ficha técnica: 400.000 millones de parámetros. Esperas una factura de cómputo acorde y, sin embargo, ese modelo genera cada token gastando lo que gastaría uno diez veces más pequeño. No hay truco de marketing en la cifra. Hay una decisión de arquitectura: mixture of experts (MoE), o mezcla de expertos.

La idea que la sostiene es incómoda para la intuición. Durante años dimos por hecho que más parámetros significaba más cómputo por cada token: si el modelo es el doble de grande, cada palabra cuesta el doble. MoE rompe ese vínculo. Separa cuánto sabe un modelo de cuánto calcula para responder. Y esa separación es la razón de que los modelos abiertos más capaces de hoy quepan en un presupuesto de inferencia razonable.

Qué es un experto (y qué no es)

Empecemos por deshacer el nombre, porque induce a error. Un “experto” en MoE no es un submodelo entrenado en medicina y otro en derecho. No hay especialización temática que puedas señalar con el dedo. Un experto es, simplemente, una red feed-forward más entre varias, dentro de una capa del transformer.

Recuerda cómo es un bloque transformer denso: atención, y después una red feed-forward (FFN) por la que pasan todos los tokens. Esa FFN es donde vive la mayor parte de los parámetros del modelo. MoE hace un cambio quirúrgico: en lugar de una sola FFN gigante, pone muchas FFN pequeñas en paralelo —los expertos— y, para cada token, usa solo unas pocas.

Un modelo con 64 expertos que activa 2 por token no calcula con 64 redes. Calcula con 2. Los 62 restantes están en memoria, quietos, sin multiplicar nada para ese token. Ahí está el ahorro: los parámetros existen y aportan capacidad al conjunto, pero no todos se encienden a la vez.

El router: la pieza que de verdad decide

Si cada token solo pasa por 2 de los 64 expertos, algo tiene que elegir cuáles. Esa pieza es el router (o gating network), y es el corazón real de MoE.

El router es una capa diminuta —una proyección lineal seguida de un softmax— que mira el vector de cada token y produce una puntuación por experto. Se quedan los k mejores (el top-k, casi siempre 1 o 2), el token se envía solo a esos, y sus salidas se combinan ponderadas por la puntuación del router. Todo lo demás se ignora.

import torch
import torch.nn.functional as F

def moe_layer(x, expertos, router, k=2):
    # x: (tokens, dim). Un vector por token.
    logits = router(x)                       # (tokens, num_expertos)
    pesos, idx = logits.topk(k, dim=-1)      # top-k expertos por token
    pesos = F.softmax(pesos, dim=-1)         # normaliza SOLO entre los elegidos

    salida = torch.zeros_like(x)
    for j in range(k):
        for e, experto in enumerate(expertos):
            mask = idx[:, j] == e            # tokens que enrutan a este experto
            if mask.any():
                # solo estos tokens pasan por esta FFN; el resto ni la toca
                salida[mask] += pesos[mask, j:j+1] * experto(x[mask])
    return salida

Ese bucle es didáctico, no eficiente —en producción el enrutado se vectoriza y se reparte entre GPU—, pero deja clara la mecánica: la FFN de un experto solo se ejecuta sobre los tokens que el router le manda. El cómputo por token depende de k, no del número total de expertos. Por eso puedes multiplicar la capacidad añadiendo expertos sin que la latencia por token se dispare.

Parámetros totales frente a parámetros activos

Aquí está la distinción que hay que interiorizar, y la que explica esas fichas técnicas confusas.

Cuando un modelo se describe como “236B totales, 21B activos”, esas dos cifras cuentan cosas distintas. Los 236B fijan cuánto conocimiento cabe en el modelo; los 21B fijan cuánto cuesta cada token. MoE es la técnica que permite que la primera cifra sea mucho mayor que la segunda.

El coste que la cifra bonita esconde

MoE no es cómputo gratis, y conviene decirlo claro porque es el error más común al leer una ficha técnica. El ahorro es en cómputo, no en memoria.

Para servir el modelo tienes que tener los 64 expertos cargados en VRAM, aunque cada token use dos. No sabes de antemano a qué experto irá el siguiente token, así que no puedes descargar ninguno. Un MoE de 236B parámetros ocupa la memoria de un modelo de 236B, con el coste de hardware que eso implica; lo que baja es la factura de FLOPs por token, no la de gigabytes. Es la operación inversa a la cuantización, que ataca la memoria: aquí bajas cómputo y la memoria se mantiene.

Y aparece un problema nuevo que el modelo denso no tenía: el balanceo de carga. Si el router aprende a mandar casi todos los tokens a sus tres expertos favoritos, el resto se queda sin entrenar y la capacidad extra que pagaste no sirve para nada. Es un colapso silencioso: el modelo funciona, pero la mitad de los parámetros son peso muerto. Por eso el entrenamiento de un MoE añade una pérdida auxiliar de balanceo que penaliza al router por repartir de forma desigual, empujándolo a usar todos los expertos de manera pareja. Sin esa presión, la mezcla de expertos degenera en una FFN cara con adornos.

Qué hacer con esto

No vas a implementar la capa de enrutado tú, igual que no reescribes el planificador de tu motor de inferencia. Pero entender MoE cambia cómo lees y dimensionas un despliegue:

• Al elegir modelo, mira las dos cifras. Los parámetros activos predicen tu latencia y tu coste de cómputo por token; los totales predicen tu factura de VRAM. Un modelo “pequeño en activos” puede seguir necesitando una GPU enorme para caber entero.
• No esperes ahorro de memoria. Si tu cuello de botella es la VRAM —y en servir LLM casi siempre lo es—, MoE no te rescata por sí solo. Ahí la palanca sigue siendo cuantizar o repartir el modelo entre varias GPU.
• Trata “número de expertos” como capacidad, no como velocidad. Más expertos es más conocimiento potencial a igual coste por token, siempre que el balanceo funcione. No te hará responder más rápido.
• Si te sale barato en cómputo pero caro en hardware, es la señal esperada. Ese perfil —FLOPs bajos, memoria alta— es exactamente lo que MoE produce. No es una anomalía de tu configuración.

La lección de fondo es la misma que recorre toda la capa de inferencia: capacidad y coste no son la misma variable, y las arquitecturas que ganan son las que aprenden a separarlas. Mixture of experts lo hace por el lado del cómputo, dejando que un modelo sepa mucho sin tener que pensarlo todo entero en cada token.