Cómo benchmarkear entrenamiento MoE sin confundir throughput de laboratorio con una mejora real en costo y calidad del modelo final

Paso 1 — Congela la tarea científica antes de comparar kernels. Usa el mismo dataset, tokenización, objetivo, número de expertos, top-k routing y criterios de calidad. Define un baseline denso o MoE existente y registra hardware, software, versiones y topología. Si cambias arquitectura y kernel a la vez, reporta ambas diferencias. Establece checkpoints comparables por tokens vistos y por tiempo. La pregunta no es cuál run produce más samples por segundo en cinco minutos, sino qué configuración alcanza una calidad definida con menor costo total y estabilidad suficiente. El benchmark necesita conservar el problema mientras permite variar la implementación.

Paso 2 — Mide routing y balance explícitamente. Registra tokens por experto, porcentaje de capacidad desperdiciada, overflow, entropy del router y frecuencia de expertos dominantes. Visualiza distribución por batch y a lo largo del entrenamiento. Un promedio global puede ocultar que un experto recibe picos que saturan memoria o comunicación. Si aplicas auxiliary loss para balance, documenta su peso y observa impacto en calidad. La meta no es igualdad perfecta, sino una distribución que preserve especialización sin destruir utilización. Comparar dos runtimes sin mirar routing puede atribuir al kernel una diferencia causada por comportamiento del modelo.

Paso 3 — Separa cómputo local de comunicación. Mide tiempo en GEMM, routing, all-to-all, espera de red y kernel launches. Repite con diferentes números de GPUs y, si es posible, topologías. Una optimización que funciona en un nodo puede perder ventaja cuando expertos se distribuyen entre nodos. Registra ancho de banda efectivo y tamaño de mensajes. Esto permite decidir si el siguiente dólar debe invertirse en GPU, red o software. Para equipos que entrenan a escala, localizar el cuello de botella produce más valor que perseguir una cifra única de utilización. El profiler debe contar una historia causal, no solo entregar porcentajes.

Paso 4 — Trata precisión como una variable independiente. Compara BF16 y formatos reducidos como MXFP8 bajo seeds y condiciones controladas. Mide memoria, throughput, grad norms, pérdida, estabilidad y métricas downstream. Si una precisión necesita ajustes de learning rate o scaling, registra esa configuración como stack distinto. No declares que una arquitectura es 2x más rápida si la mitad de la mejora proviene de un formato que también podría aplicarse al baseline. Esta separación permite saber qué técnica aporta qué ganancia y facilita migrar componentes. La reproducibilidad mejora cuando cada optimización tiene un ablation claro.

Paso 5 — Calcula costo hasta un umbral de calidad. Define uno o varios quality gates relevantes al dominio y mide cuánto tiempo, energía o dinero necesita cada configuración para alcanzarlos. Incluye runs que no convergen dentro del presupuesto. Reporta costo por checkpoint útil, no solo costo por hora. También observa si el modelo final mantiene calidad en tareas raras que podrían depender de expertos menos frecuentes. En biología, la métrica downstream puede ser distinta a pérdida de preentrenamiento; en otros dominios, usa evaluaciones representativas. La infraestructura más rápida solo gana si entrega un modelo igual o mejor dentro de un presupuesto menor.

Paso 6 — Versiona el stack como artefacto reproducible. Guarda commit, container, drivers, Transformer Engine, precision policy, router config y placement de expertos. Crea un report con métricas crudas y no solo la mejor cifra. Si una optimización parece prometedora, repítela en otra escala antes de promoverla. En Goatify, podemos aplicar el mismo método cuando evaluemos clusters locales o inference routing: aislar variables, medir outcomes y conservar un stackreceipt. Esta disciplina convierte claims de proveedor en hipótesis que podemos confirmar o rechazar sobre el workload real. La meta no es desconfiar de benchmarks; es hacerlos transferibles a una decisión propia.