Mixture-of-Experts convierte el routing interno del modelo en una decisión de infraestructura y obliga a medir dónde se concentra realmente el cómputo

MoE introduce un router dentro del propio modelo. En una red densa, cada token atraviesa casi la misma estructura de cómputo. En Mixture-of-Experts, una función decide qué especialistas procesan cada token. Esa decisión parece interna, pero tiene consecuencias físicas: qué GPU recibe carga, cuánta memoria se usa, cuánta comunicación ocurre y cuánto tiempo permanece ociosa una parte del clúster. Por eso el rendimiento de un MoE no puede explicarse solo por parámetros totales y parámetros activos. El router se convierte en un scheduler que debe ser evaluado con la misma seriedad que cualquier capa de infraestructura distribuida.

El balance perfecto puede competir con la especialización útil. Si obligamos a que todos los expertos reciban la misma cantidad de tokens, maximizamos utilización, pero quizá distorsionamos lo que el modelo necesita aprender. Si dejamos al router elegir libremente, algunos expertos pueden saturarse y otros quedar subutilizados. La optimización real busca una frontera entre calidad y distribución. Esa tensión debe aparecer en métricas. Un throughput alto con routing artificialmente balanceado puede no conservar desempeño downstream. Una calidad excelente con hot spots severos puede ser demasiado costosa para producción. El benchmark debe mostrar ambos lados.

La comunicación puede devorar la ventaja de sparsity. Cuando expertos viven en dispositivos distintos, los tokens deben viajar hacia el lugar donde se ejecuta el experto seleccionado. En clústeres grandes, esa all-to-all communication puede convertirse en cuello de botella. Técnicas como grouping y fusión reducen overhead local, pero el topology-aware placement sigue importando. Dos sistemas con las mismas GPUs pueden rendir diferente por red, partición y distribución de expertos. Esto recuerda una regla general de sistemas de IA: el modelo lógico no determina por sí solo el costo. La geografía del cómputo importa incluso dentro de un datacenter.

La precisión reducida añade otra dimensión de routing económico. Si el hardware acelera formatos como MXFP8, parte del stack puede operar con menos memoria y mayor throughput. Pero la tolerancia a precisión puede variar por capa, experto o etapa de entrenamiento. En lugar de pensar “el modelo usa FP8”, podemos imaginar una policy que decide dónde resulta seguro. Esa granularidad abre optimizaciones más sofisticadas, pero también complica reproducibilidad. Cada benchmark debe registrar formatos y kernels exactos. Si no, una mejora atribuida a arquitectura puede venir de una combinación de precisión y runtime que otro equipo no puede reproducir.

La economía útil es costo por checkpoint que mantiene calidad. Entrenar más rápido importa porque reduce tiempo y gasto, pero el outcome real es un modelo que alcanza métricas científicas o de negocio. Un benchmark de MoE debería conectar throughput con convergencia, calidad downstream y estabilidad. Si una optimización permite 2x tokens por segundo pero necesita más pasos para converger, el ahorro puede ser menor. También conviene medir varianza entre runs, porque routing estocástico y balance pueden introducir comportamientos distintos. La eficiencia no es una captura de nvidia-smi; es una relación entre infraestructura consumida y capacidad obtenida.

Implicación para Goatify. El patrón MoE refuerza una idea que podemos aplicar al routing de agentes: no basta seleccionar el motor más barato; hay que observar cómo se distribuye trabajo y dónde aparecen hot spots. Nuestra plataforma puede tratar subagentes o modelos como expertos y medir carga, especialización y costo por outcome. Si ciertos tipos de tarea siempre terminan en un motor caro, el router debería explicarlo. Si una ruta está saturada, podemos degradar o reequilibrar. Lo que ocurre dentro de MoE es una versión compacta del problema de orquestar una flota heterogénea: asignar inteligencia donde produce mayor valor sin perder control del sistema.