¿Cómo cambia el enrutamiento de mezcla de expertos el cómputo de los modelos locales?

Eva Wong es la Redactora técnica y manitas residente en ZimaSpace. Una geek de toda la vida con pasión por los homelabs y el software de código abierto, se especializa en traducir conceptos técnicos complejos en guías accesibles y prácticas. Eva cree que el autoalojamiento debe ser divertido, no intimidante. A través de sus tutoriales, empodera a la comunidad para desmitificar las configuraciones de hardware, desde construir su primer NAS hasta dominar los contenedores Docker.

El enrutamiento de Mixture-of-Experts cambia el cómputo de los modelos locales al enviar cada token únicamente a un pequeño subconjunto de redes neuronales feed-forward expertas, en lugar de activar todos los expertos.

Esto hace que un modelo MoE grande resulte inusual en un servidor doméstico: su checkpoint total puede ser enorme, pero el cómputo experto realizado para un token puede parecerse al de un modelo activo mucho más pequeño. La ventaja reside en la aritmética dispersa, no en disponer de memoria gratuita. Los pesos de los expertos siguen necesitando almacenamiento, y el enrutamiento entre varios dispositivos puede convertir parte del cómputo ahorrado en comunicación.

Un Transformer denso activa los mismos parámetros feed-forward para cada token

En una capa Transformer densa convencional, cada token pasa por la misma red feed-forward. Por tanto, aumentar la cantidad de parámetros feed-forward incrementa tanto el tamaño del modelo como la cantidad de operaciones que realiza cada token.

Switch Transformer contrasta esto con las capas Mixture-of-Experts activadas de forma dispersa, en las que distintos tokens pueden seleccionar diferentes subconjuntos de parámetros.

Para la inferencia local, esto crea la primera distinción de MoE: los parámetros totales determinan cuánto estado del modelo debe almacenarse, mientras que los parámetros activados determinan gran parte del cómputo experto por token.

Un enrutador evalúa cada token frente a los expertos disponibles

En una capa MoE, un pequeño enrutador examina la representación del token y genera puntuaciones o probabilidades para los expertos candidatos. A continuación, el tiempo de ejecución elige un número limitado, normalmente el primero o los k primeros, según la arquitectura.

Megatron Core de NVIDIA incluye un enrutador que determina a qué expertos se envía cada token. La decisión de enrutamiento cambia qué matrices expertas procesarán ese token.

Por tanto, dos tokens del mismo prompt pueden activar pesos expertos diferentes, aunque compartan la atención y otras partes densas del modelo.

La activación dispersa reduce el cómputo experto, pero no el almacenamiento total de pesos

Si una capa contiene ocho expertos, pero envía cada token a dos, para ese token solo se ejecutan los cálculos de los expertos seleccionados. Las matrices de los expertos restantes permanecen inactivas durante ese paso.

La investigación Expert Choice describe MoE como un sistema que aumenta la cantidad de parámetros manteniendo el cómputo por token relativamente acotado. Por eso un checkpoint MoE puede anunciar una cantidad total de parámetros muy grande, pero una cifra de parámetros activos mucho menor.

Un servidor doméstico sigue necesitando que el conjunto completo de pesos expertos esté disponible en algún lugar, a menos que el tiempo de ejecución los transmita o descargue. El cómputo disperso no equivale a un almacenamiento disperso.

La ubicación de los expertos puede convertir el enrutamiento en comunicación entre dispositivos

En una sola GPU, seleccionar un experto cambia principalmente qué bloques de pesos locales se leen. En varias GPU, los expertos pueden distribuirse de modo que la representación de un token deba viajar al dispositivo que posee el experto seleccionado y después regresar al flujo principal de la capa.

El diseño de inferencia MoE de DeepSpeed asigna grupos de expertos mediante paralelismo entre expertos en varias GPU. Por tanto, el enrutamiento incluye tanto comunicación como multiplicación de matrices.

En consecuencia, un pequeño servidor doméstico con varias GPU puede quedar limitado por la interconexión incluso cuando el cómputo de cada token es disperso. La topología PCIe y la compatibilidad entre dispositivos importan más de lo que sugiere por sí sola la cifra de parámetros activos.

El enrutamiento desequilibrado crea expertos saturados y capacidad inactiva

Los prompts reales no distribuyen necesariamente los tokens de manera uniforme. Si muchos tokens eligen el mismo experto, ese dispositivo o kernel se convierte en un cuello de botella mientras los demás expertos esperan.

MoETuner identifica el enrutamiento desequilibrado de tokens y la activación de expertos como cuellos de botella prácticos del servicio, porque algunos dispositivos pueden acumular más trabajo de enrutamiento y comunicación que otros.

En la inferencia local, el enrutamiento desigual puede manifestarse como una latencia variable por token entre prompts, incluso cuando la longitud del contexto y el tamaño del modelo son similares. El modelo está eligiendo dinámicamente una ruta de cómputo diferente.

Planifica la capacidad local de MoE por separado para los pesos totales y la ruta activa

Una estimación de hardware útil registra el tamaño total de los pesos del modelo, el número de expertos activos por token, el coste de las capas densas, la caché KV, la cuantización y si los expertos residen en un único acelerador, en varias GPU, en la RAM de la CPU o en el almacenamiento.

El análisis de ZimaSpace sobre la memoria de IA local y la planificación de aceleradores ofrece el contexto más amplio sobre la capacidad de los servidores domésticos. MoE añade una separación más entre la capacidad residente y el cómputo activo.

Evalúa prompts de distintas tareas, porque los patrones de enrutamiento pueden variar. Mide los tokens por segundo, la utilización de cada dispositivo, la carga de los expertos, el tráfico de comunicación y la permanencia en memoria, en lugar de asumir que la cifra anunciada de parámetros activos predice el comportamiento de todo el sistema.

Para checkpoints locales especialmente grandes, el análisis de implementación de modelos grandes de ZimaSpace aborda la cuestión de capacidad relacionada. El enrutamiento cambia el cómputo activo, pero la permanencia total de los pesos y su distribución entre dispositivos siguen determinando si el modelo resulta práctico.

Centro de Tecnología e IA

Más para leer

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.