El aprendizaje por refuerzo MoE en Amazon EKS logra un 40% más de rendimiento, pero el benchmark tiene limitaciones

Amazon afirma que el aprendizaje por refuerzo MoE en Amazon EKS produjo un 40% más de rendimiento agregado en rollouts después de que sus ingenieros habilitaran DeepEP sobre Elastic Fabric Adapter. La prueba abarcó 48 instancias P5en, con 16 destinadas al entrenamiento de políticas y 32 a generar rollouts de inferencia. Es un resultado considerable para una etapa costosa del postentrenamiento de modelos grandes.

El cambio importante no consiste simplemente en otra configuración de GPU más rápida. Amazon ha adaptado la ruta de comunicación entre expertos de DeepEP para usar libfabric, lo que proporciona a DeepEP v2 compatibilidad nativa con las redes de AWS. Esta integración se dirige al patrón de tráfico irregular que se genera cuando un modelo Mixture-of-Experts enruta tokens entre expertos en diferentes GPU.

El resultado también necesita un encuadre cuidadoso. AWS divulgó una mejora relativa del rendimiento para una carga de trabajo MoE supersparsa, no un benchmark universal para todos los modelos, clústeres o frameworks de aprendizaje por refuerzo. Investigaciones independientes sobre sistemas han documentado la dificultad de trasladar la comunicación paralela entre expertos a distintas arquitecturas de GPU y red.

Qué cambió Amazon en su stack de aprendizaje por refuerzo MoE

La mejora reportada por Amazon provino de cambiar cómo viajan los tokens enrutados entre expertos, no de añadir más máquinas al clúster medido.

La arquitectura de AWS divide un trabajo de aprendizaje por refuerzo en varios grupos de workers. Los nodos GPU gestionan el entrenamiento de políticas, la inferencia del modelo de recompensa y la generación de rollouts. Los nodos CPU ejecutan entornos y preprocesamiento, mientras que los nodos optimizados para memoria alojan búferes de experiencia y cachés de checkpoints.

Amazon EKS actúa como capa de orquestación. Ubica contenedores, gestiona grupos de nodos separados, coordina fallos y permite a los operadores escalar cada parte de la carga de trabajo de forma independiente. Amazon S3 almacena conjuntos de datos, checkpoints, pesos finales y otros artefactos duraderos fuera de la ruta de ejecución sensible a la latencia.

Esta separación importa porque el aprendizaje por refuerzo no es un único cálculo uniforme. Durante la generación de rollouts, un worker de inferencia usa la política actual para interactuar con un entorno y producir respuestas o trayectorias candidatas. Un sistema de recompensa evalúa esas muestras, y los workers de entrenamiento de políticas consumen la experiencia resultante.

Los pesos actualizados regresan después a la flota de rollouts, iniciando otra iteración de la política. Este ciclo aparece en Reinforcement Learning from Human Feedback, o RLHF, que utiliza señales de preferencia para mejorar un modelo. También aparece en Group Relative Policy Optimization, o GRPO, que evalúa las salidas con respecto a otras muestras de un grupo.

Cada etapa somete a la infraestructura a exigencias distintas. La generación de rollouts se parece a la inferencia distribuida y a menudo puede dividir el trabajo entre workers independientes. El entrenamiento de políticas requiere una sincronización más estricta porque las GPU participantes deben completar operaciones coordinadas antes de poder avanzar al siguiente paso.

Por ello, la arquitectura separa 32 instancias de inferencia de 16 instancias de entrenamiento en la prueba reportada. En esos 48 sistemas P5en, Amazon afirma que DeepEP sobre EFA elevó el rendimiento agregado de rollouts en un 40% frente a la configuración sin DeepEP.

Las instancias P5en utilizan GPU NVIDIA H200 y redes AWS de gran ancho de banda. Una implementación completa de 48 instancias representa cientos de aceleradores, aunque AWS señala que su arquitectura más grande puede ampliarse hacia aproximadamente mil aceleradores. El porcentaje publicado describe la comparación de 48 instancias, no todos los tamaños de clúster posibles.

El propio modelo se describe únicamente como un modelo MoE supersparso. Un modelo Mixture-of-Experts contiene múltiples bloques especializados de propagación hacia adelante, pero activa solo un subconjunto para cada token. La dispersión reduce el cálculo por token, pero crea un exigente problema de enrutamiento cuando los expertos residen en diferentes GPU.

Las operaciones colectivas estándar funcionan bien cuando cada rango intercambia bloques predecibles de tamaño similar. El enrutamiento MoE es distinto. Los tokens eligen expertos dinámicamente, por lo que el tráfico puede ser disperso, desigual y estar compuesto por muchas transferencias pequeñas.

Esa diferencia explica por qué la infraestructura importa tanto. Una mayor capacidad teórica del modelo no ofrece automáticamente más tokens útiles por segundo. Si el envío a expertos y la recopilación de resultados saturan la red, las costosas GPU esperan activaciones en lugar de procesarlas.

Por qué el aprendizaje por refuerzo MoE en Amazon EKS choca con una barrera de red

El cómputo disperso ahorra operaciones aritméticas, pero el paralelismo entre expertos puede devolver ese coste en forma de retrasos de comunicación.

El paralelismo entre expertos distribuye los expertos de un modelo entre GPU. Cuando un router selecciona expertos remotos, el sistema debe enviar la activación de cada token al dispositivo correcto. Después de que el experto la procesa, una operación de combinación devuelve la salida a su ruta de ejecución original.

Estos intercambios ocurren repetidamente en todo el modelo. Sus destinos dependen de decisiones de enrutamiento tomadas en tiempo de ejecución, y distintos expertos pueden recibir cantidades diferentes de tokens. Por tanto, la red debe gestionar muchas transferencias detalladas sin permitir que unos pocos destinos ocupados bloqueen a todos los participantes.

DeepEP fue creado para este patrón. El proyecto DeepEP proporciona kernels especializados de envío y combinación para cargas de trabajo paralelas entre expertos. Utiliza NVLink para la comunicación dentro de un servidor y un transporte compatible con RDMA entre servidores.

Remote Direct Memory Access, o RDMA, permite que una máquina transfiera datos directamente a la memoria de otra con menor intervención de la CPU. Esta ruta más corta puede reducir la sobrecarga de software y hacer más útil el hardware de red de alta velocidad.

Elastic Fabric Adapter, o EFA, es la interfaz de red de baja latencia de AWS para cómputo estrechamente acoplado. La documentación de EFA describe una ruta que evita el sistema operativo y está construida sobre AWS Scalable Reliable Datagram. EKS puede exponer dispositivos EFA a pods que ejecutan aplicaciones de aprendizaje automático distribuido.

Dentro de cada instancia P5en, NVLink y NVSwitch transportan el tráfico de GPU a través de la estructura local de aceleradores. Para las transferencias entre instancias, EFA se convierte en la ruta pertinente. La integración de Amazon utiliza libfabric, una interfaz que permite a las aplicaciones acceder a distintos proveedores de red de alto rendimiento mediante una API común.

Amazon afirma que sus ingenieros aportaron funciones que trasladaron las primitivas de comunicación de DeepEP de un backend RDMA específico de CUDA a libfabric. Con este trabajo, DeepEP v2 puede enviar datos entre nodos mediante EFA mientras conserva kernels especializados para el envío y la combinación de expertos.

La distinción entre operaciones especializadas para expertos y colectivas densas es fundamental para el resultado. NCCL sigue siendo útil para operaciones regulares como all-reduce, all-gather y reduce-scatter. DeepEP se dirige a los intercambios dispersos all-to-all en torno a las capas MoE.

Investigaciones recientes reflejan esta división. Los autores de NCCL EP describen modos separados de baja latencia y alto rendimiento para la comunicación entre expertos. Su diseño de alto rendimiento agrega datos dentro de dominios NVLink antes de transmitirlos mediante conexiones RDMA entre nodos.

Esta jerarquía reduce la cantidad de tráfico detallado que cruza la frontera más lenta entre máquinas. También reconoce que un clúster no es una red uniforme. La comunicación dentro de un servidor tiene características de ancho de banda y latencia diferentes de la comunicación entre servidores.

La implementación de AWS sigue el mismo principio general. El tráfico local permanece en NVLink, mientras que libfabric transporta el tráfico DeepEP entre nodos mediante EFA. Esta ruta consciente de la topología sustituye un tratamiento genérico de cada transferencia de token.

El aumento resultante del 40% se refiere a la producción agregada de rollouts, no simplemente a un microbenchmark de comunicación. Esta medida de extremo a extremo es valiosa porque un kernel más rápido no siempre acelera todo el ciclo de aprendizaje por refuerzo. La mejora sugiere que la comunicación entre expertos era lo bastante importante como para afectar el trabajo de rollout completado.

Sin embargo, el rendimiento de rollouts sigue siendo solo una capa del sistema. El tiempo de iteración de la política también depende de la ejecución del entorno, la evaluación de recompensas, el almacenamiento en búfer de muestras, la publicación de checkpoints, el cómputo de entrenamiento y la sincronización de pesos. Optimizar una etapa puede revelar un cuello de botella en otra.

La verdadera competencia es entre enrutamiento especializado y colectivas genéricas

La competencia principal enfrenta una comunicación diseñada para el enrutamiento dinámico de expertos con operaciones colectivas diseñadas para el movimiento regular de datos.

Las colectivas genéricas resultan atractivas porque son maduras, tienen amplio soporte y son más fáciles de integrar. Funcionan con muchos frameworks de entrenamiento y configuraciones de hardware. Los operadores también pueden probarlas con herramientas conocidas y razonar sobre su comportamiento de sincronización.

El tráfico MoE incumple varias premisas que hacen eficientes a esas colectivas. Cada token puede seleccionar un conjunto distinto de expertos. Algunos expertos se vuelven temporalmente populares, los tamaños de los mensajes se mantienen pequeños y el sistema ejecuta operaciones de envío y combinación en cada capa MoE.

Una implementación convencional puede empaquetar este tráfico en operaciones all-to-all. Este enfoque sigue siendo funcional, pero la sobrecarga de sincronización y gestión de mensajes crece a medida que el paralelismo entre expertos abarca más nodos. Entonces, más GPU crean más relaciones de comunicación en lugar de aportar proporcionalmente más cómputo útil.

DeepEP aborda este problema con kernels construidos en torno a la semántica del enrutamiento de expertos. El kernel de envío manda activaciones de tokens a los expertos seleccionados. El kernel de combinación devuelve las activaciones procesadas, al tiempo que evita trabajo que una colectiva general podría realizar para destinos no utilizados.

El diseño también intenta superponer comunicación y cómputo. Si una GPU puede continuar operaciones matriciales útiles mientras avanzan las transferencias, parte del tiempo de red desaparece de la ruta crítica. Esa superposición se vuelve más difícil cuando la comunicación requiere coordinación repetida de la CPU o una sincronización global estricta.

La migración de Amazon a libfabric importa porque la optimización original estaba estrechamente asociada con las GPU NVIDIA y las redes de estilo InfiniBand. Una biblioteca de comunicación que funciona bien sobre una estructura no conserva automáticamente su comportamiento sobre otra. Las garantías de orden, la iniciación de mensajes y las interfaces de dispositivos varían.

Por tanto, la integración representa más que cambiar una dirección de red. Las premisas de DeepEP deben mapearse a la semántica de transporte de EFA, y la implementación debe preservar la entrega correcta de tokens. También debe evitar introducir suficiente sobrecarga de software como para borrar los beneficios del enrutamiento especializado.

Amazon afirma que los sistemas P5 y P6 compatibles pueden utilizar GPUDirect RDMA con EFA. GPUDirect RDMA permite que las transferencias de red lean y escriban en la memoria de GPU sin preparar cada carga útil a través de la memoria ordinaria del host. El sistema operativo permanece fuera de la ruta de datos principal.

Este diseño presiona a las implementaciones MoE genéricas que se basan únicamente en colectivas estándar. Los equipos de infraestructura que utilizan grandes modelos paralelos entre expertos ahora tienen evidencia de que una ruta especializada puede mejorar una carga de trabajo de aprendizaje por refuerzo relevante para producción.

El resultado también presiona a los responsables de mantenimiento de frameworks. La compatibilidad con DeepEP debe llegar a motores de serving, sistemas de aprendizaje por refuerzo, imágenes de contenedor, programadores y herramientas de observabilidad. Un transporte rápido que requiere una compilación personalizada frágil puede perder su ventaja durante la implementación o la recuperación.

NCCL 2.31 añade otra parte al panorama. AWS afirma que esa versión incluye optimizaciones más recientes de EFA para comunicación colectiva densa. Por tanto, una pila realista de entrenamiento de MoE utiliza mecanismos distintos para diferentes clases de tráfico, en lugar de declarar un único ganador universal.

DeepEP gestiona el envío y la combinación irregulares entre expertos. NCCL sigue manejando la sincronización densa en torno a las capas de atención, el paralelismo de tensores, el paralelismo de datos y el estado del optimizador. EFA transporta ambas clases entre máquinas mediante rutas optimizadas para sus respectivos patrones.

Esta división es la lección arquitectónica más amplia. El escalado de MoE depende de identificar la comunicación según su forma y propósito. Tratar cada transferencia como intercambiable deja rendimiento desaprovechado.

Lo que la afirmación de un 40% más de rendimiento con DeepEP no demuestra

El benchmark respalda una decisión arquitectónica concreta, pero no establece una mejora universal del 40% de DeepEP frente a EFA.

Amazon identifica la asignación de instancias, la mejora relativa y el amplio perfil de dispersión del modelo. No publica el número de parámetros del modelo, la cantidad de expertos, la distribución de enrutamiento, las longitudes de secuencia, los tamaños de lote ni la configuración completa de referencia.

Estos detalles afectan directamente a la comunicación entre expertos. Un modelo que activa más expertos por token puede generar más tráfico. Los lotes más grandes pueden combinar mensajes de forma más eficiente, mientras que los lotes pequeños de decodificación pueden amplificar la latencia fija.

La expresión “rendimiento agregado de rollout” también necesita contexto. AWS no proporciona en la publicación pública el número absoluto de tokens de salida, trayectorias o solicitudes completadas por segundo. Los lectores no pueden calcular la utilización total del clúster ni compararla directamente con la de otro proveedor.

La referencia importa igual de mucho. “Sin DeepEP” podría significar una implementación estándar de NCCL all-to-all con determinadas opciones de ajuste. Una agregación de mensajes, colocación de expertos, concurrencia o políticas de enrutamiento diferentes podrían reducir o ampliar la brecha medida.

Amazon informa de un resultado controlado de su propia carga de trabajo interna. La empresa no afirma que el benchmark haya sido auditado de forma independiente, y el material público no incluye la variación de ensayos repetidos. Por ello, la formulación correcta es que AWS afirma que el rendimiento aumentó un 40%.

También existe una cuestión de portabilidad. Investigaciones anteriores sobre UCCL-EP sostuvieron que los sistemas de comunicación entre expertos estrechamente vinculados a interfaces de GPU y red generan un trabajo de integración considerable. El artículo examinó específicamente cómo distintas semánticas de orden complican la compatibilidad con EFA y otras redes no InfiniBand.

Esa investigación es anterior al trabajo nativo de EFA descrito recientemente por Amazon. Sigue siendo relevante porque explica la barrera técnica que AWS afirma haber abordado ahora mediante contribuciones a libfabric. Ambos relatos describen momentos distintos de una historia de implementación que cambia rápidamente.

UCCL-EP adopta otra vía. Mantiene las decisiones de enrutamiento en las GPU, pero delega la ejecución de red en proxies de CPU multihilo, usando un canal de control para salvar las diferencias de hardware. Sus autores informan de mejoras en sistemas NVIDIA más EFA, pero esas pruebas implican sus propios modelos, frameworks y configuraciones.

Ningún resultado invalida al otro. Muestran que el diseño de transporte puede cambiar el resultado y que “compatibilidad con EFA” no identifica una única ruta de ejecución fija. Los operadores necesitan saber si una compilación utiliza transferencias iniciadas por GPU, proxies de CPU, agregación de mensajes u otra capa de compatibilidad.

Los requisitos publicados y los resultados de rendimiento de DeepEP también han evolucionado. La documentación actual del proyecto informa de un alto ancho de banda en configuraciones RDMA compatibles, pero anima a los usuarios a evaluar directamente implementaciones más grandes con paralelismo de expertos. Ese consejo es especialmente importante en infraestructuras de nube con una topología y un comportamiento de congestión distintos.

La escala del clúster introduce más incertidumbre. La prueba comunicada utilizó 48 instancias P5en, mientras que AWS analiza el escalado de la arquitectura más amplia hacia aproximadamente mil aceleradores. Un diseño que funciona bien en 48 nodos no necesariamente conserva la misma eficiencia a todas las escalas superiores.

La contención de red puede surgir cuando varios grupos de trabajadores comparten infraestructura. El enrutamiento de tokens puede desequilibrarse más a medida que cambia el comportamiento del modelo o de la carga de trabajo. Un único rango lento también puede retrasar operaciones de entrenamiento estrechamente sincronizadas.

El aprendizaje por refuerzo añade su propia fuente de variación. Las longitudes de los prompts y las respuestas, la latencia del entorno, los ajustes de muestreo y la complejidad del modelo de recompensa afectan al tiempo que los trabajadores de rollout dedican a comunicarse. Una mejora del 40% en una carga de trabajo intensiva en comunicación puede reducirse cuando predominan la generación o la ejecución del entorno.

El resultado dice aún menos sobre el servicio en línea. La inferencia en producción suele utilizar lotes más pequeños y objetivos estrictos de latencia por solicitud. Un kernel de alto rendimiento optimizado para la generación de rollouts no reduce automáticamente el tiempo hasta el primer token ni el tiempo por token de salida para usuarios interactivos.

El coste sigue sin expresarse como medida absoluta. Un mayor rendimiento en el mismo clúster suele mejorar el trabajo útil por hora de acelerador, pero la publicación no proporciona el coste total del entrenamiento. Tampoco compara la configuración optimizada con tipos de instancia o bibliotecas de red alternativos.

Estas omisiones no hacen que el resultado sea poco importante. Definen dónde resulta útil. El benchmark es evidencia de que la integración de DeepEP de AWS puede eliminar un cuello de botella significativo en una gran canalización de aprendizaje por refuerzo con MoE.

EKS y la capacidad Spot cambian el resto del sistema de RL

La mejora de comunicación se vuelve operativamente útil solo cuando el planificador, el búfer, el almacenamiento y el modelo de fallos mantienen abastecida a la flota de rollouts más rápida.

Amazon EKS permite que la arquitectura asigne distintos tipos de nodos a tareas diferenciadas. Los grupos de nodos GPU pueden escalar en función de la demanda de entrenamiento e inferencia. Los grupos de CPU pueden ampliarse para los trabajadores de entorno, mientras que los sistemas orientados a memoria absorben datos de experiencia de corta duración.

Esta heterogeneidad es especialmente relevante para GRPO y RLHF. Los trabajadores de rollout pueden generar grandes cantidades de datos temporales, pero los entrenadores de políticas los consumen en lotes sincronizados. Si las tasas de producción y consumo divergen, una parte espera mientras la otra acumula una cola.

Un búfer compartido de experiencia en memoria desacopla esas tasas durante periodos cortos. Los trabajadores de rollout publican muestras completadas y los entrenadores extraen lotes cuando están preparados. Las cachés de puntos de control ayudan a distribuir pesos actualizados sin obligar a que cada transferencia pase por almacenamiento persistente de objetos.

Amazon S3 cumple una función distinta. Alberga conjuntos de datos, puntos de control recuperables, artefactos de modelo terminados y pesos finales. Mantener esa ruta persistente fuera del intercambio de muestras más frecuente evita que la latencia del almacenamiento de objetos controle cada paso de entrenamiento.

Esta separación también aclara el valor de EKS. Kubernetes no acelera la multiplicación de matrices ni los kernels de expertos. Coordina la colección de servicios necesaria para mantener productivos a los aceleradores.

EKS gestiona la colocación, los reinicios, las políticas de escalado y los límites entre grupos de nodos. Puede programar capacidad estable para el entrenamiento de políticas por separado de los trabajadores de rollout más elásticos. Ese límite respalda la segunda optimización de Amazon: usar EC2 Spot Instances para parte de la generación de rollouts.

La capacidad Spot puede interrumpirse cuando AWS necesita recuperar las instancias subyacentes. Ese riesgo es difícil para el entrenamiento de políticas estrechamente sincronizado porque perder un trabajador puede detener o reiniciar un trabajo coordinado. Las tareas de rollout son más fáciles de particionar y reintentar.

Amazon recomienda proporcionar a los trabajadores de rollout unidades de trabajo acotadas y publicar muestras con frecuencia. Cuando llega un aviso de interrupción, un trabajador puede finalizar las solicitudes activas y devolver las tareas incompletas a una cola. Los demás trabajadores continúan sin reiniciar todo el grupo de entrenamiento de políticas.

La estrategia no elimina el coste de las interrupciones. Las generaciones parciales perdidas desperdician parte del cómputo, y los nodos de reemplazo necesitan contenedores, pesos de modelo y bibliotecas de comunicación. Las decisiones de escalado automático también deben considerar la profundidad de la cola, el tiempo de carga del modelo y la capacidad Spot disponible.

Aun así, la topología aísla dos dominios de fallo. Los entrenadores de políticas permanecen en capacidad estable, mientras que la generación de rollouts utiliza un grupo más barato pero menos predecible. Ese diseño se ajusta a los distintos requisitos de sincronización de ambas etapas.

El aumento del 40% en el rendimiento de DeepEP puede alterar este equilibrio. Los trabajadores de inferencia más rápidos pueden entregar experiencia más rápido de lo que la consumen los entrenadores. Entonces, los operadores deben redimensionar grupos de nodos, ajustar la programación de lotes o reducir la capacidad de inferencia para evitar pagar por producción inactiva.

Lo contrario puede suceder tras una actualización de la política. La distribución de pesos y el tiempo de reinicio de los trabajadores pueden privar temporalmente de datos al búfer de experiencia. Por tanto, un panel de producción útil debe supervisar la iteración completa de la política, no solo los tokens generados por segundo.

Los equipos también necesitan información de compilación reproducible. DeepEP, NCCL, CUDA, libfabric, los controladores de EFA, las versiones de frameworks y la arquitectura de GPU influyen en la ruta de datos. Cambiar un componente puede seleccionar silenciosamente una alternativa más lenta.

Esta evidencia operativa debería conservarse junto con los registros del modelo y los experimentos. Los equipos de ingeniería pueden preservar decisiones de configuración, notas de benchmarks e informes de fallos en una base de conocimiento técnico consultable. Esta práctica cobra valor cuando una reconstrucción posterior de imagen modifica el rendimiento sin cambiar el modelo.

Tres señales mostrarán si la mejora se generaliza

La siguiente prueba es la reproducibilidad entre modelos, tamaños de clúster e iteraciones completas de política.

La primera señal es un paquete público de benchmarks con rendimiento absoluto. Los resultados útiles incluirían tokens o trayectorias por segundo, distribuciones de latencia, desequilibrio de carga entre expertos, utilización de red y variación entre ejecuciones repetidas.

Ese paquete debería especificar la operación colectiva de referencia, todas las versiones de software pertinentes y la ruta de transporte precisa de DeepEP. También debería revelar las dimensiones del modelo, los expertos activos por token, los tamaños de lote, las longitudes de prompts y respuestas, y el grado de paralelismo de expertos.

Si equipos independientes reproducen una mejora similar, la afirmación de AWS será más sólida. Si los resultados varían mucho, la integración seguirá siendo útil, pero específica de la carga de trabajo. Cualquiera de los dos resultados ayudaría a los operadores a decidir cuándo se justifica su complejidad adicional.

La segunda señal es la eficiencia de escalado más allá de la configuración publicada de 48 instancias. Los resultados en varios tamaños de clúster mostrarían si el rendimiento crece proporcionalmente o pierde terreno ante la sincronización, la congestión y el desequilibrio entre expertos.

Un estudio de escalado significativo debería mantener constante la definición de la carga de trabajo mientras aumenta los recursos. Debería informar tanto de la producción agregada como de la eficiencia por acelerador. El rendimiento agregado puede aumentar incluso cuando cada GPU añadida contribuye menos trabajo útil.

Una eficiencia sólida hacia aproximadamente mil aceleradores respaldaría la afirmación arquitectónica más amplia de AWS. Una caída pronunciada indicaría que DeepEP eliminó un cuello de botella mientras surgía otro a mayor escala.

La tercera señal es el tiempo de iteración de política de extremo a extremo bajo fallos reales. El rendimiento de rollout importa porque los trabajadores de entrenamiento necesitan experiencia reciente, no porque generar tokens aislados sea el objetivo final.

Las mediciones futuras deberían incluir la ejecución del entorno, la evaluación de recompensas, las demoras del búfer, las actualizaciones de políticas, la publicación de puntos de control y la redistribución de pesos. También deberían mostrar cómo las interrupciones de Spot afectan las muestras completadas y el tiempo de recuperación.

Una iteración completa más corta confirmaría que la optimización de comunicación mejora el avance del aprendizaje por refuerzo, en lugar de trasladar el tiempo inactivo a otra parte. Si el tiempo de iteración apenas cambia, los equipos deberían investigar el entrenamiento, el almacenamiento o la sincronización antes de añadir más capacidad de rollout.

El aprendizaje por refuerzo de MoE en Amazon EKS cuenta ahora con una vía creíble para combinar la orquestación de Kubernetes, las redes EFA y la comunicación especializada entre expertos. El aumento reportado del 40 % hace que valga la pena probar esa vía, pero sigue siendo una medición inicial, no una constante transferible. Los equipos de infraestructura deberían reproducir la comparación con su propio modelo, perfil de enrutamiento y bucle de RL antes de estandarizar la pila. La cuestión práctica no es si DeepEP puede generar una gráfica más rápida. Es si el mismo clúster completa más actualizaciones de políticas validadas, con una fiabilidad y un coste aceptables, una vez contabilizadas todas las partes del sistema.