AWS hævder, at en arkitektur med Amazon EKS, Elastic Fabric Adapter og DeepEP kan give 40 procent mere throughput for post-træning af Mixture-of-Experts-modeller med RLHF eller GRPO. Hvis det holder, flytter det på både pris og tid til resultater for teams, der sidder med MoE og store rollout-farme. Men dokumentationen er et blogindlæg, ikke et paper. Ingen offentlige konfigurationer. Ingen reproducérbare benchmarks. Det er værd at have i baghovedet.
Kernen er dog relevant: MoE ændrer, hvor smertepunkterne ligger. Ikke kun på compute. I stigende grad i netværket. Og i orkestreringen, der skal balancere rollout, træning, checkpoints, reward-modeller og verifikatorer.
Tre samtidige problemer som MoE-RL forstørrer
Blogindlægget fra AWS beskriver tre udfordringer, når man skalerer RLHF eller GRPO oven på MoE: koordinering af heterogent compute til både rollout-generering og policytræning, vedvarende høj-throughput kommunikation på tværs af mange acceleratorer, samt dynamisk orkestrering for at holde delsystemerne i balance. Det matcher, hvad mange teams mærker i praksis, når RL skal køre side om side med træning.
Pointen er ikke ny, men skalaen er. Rollout-jobs vil have bred, elastisk inferens. Træningen vil have tæt kobling og forudsigelig latency. Læg oveni at MoE øger kommunikationspresset under træning, fordi tokens flyttes på kryds og tværs mellem eksperter. Så står man med et orkestreringsproblem, ikke bare et GPU-problem.
Hvorfor MoE flytter smerten fra compute til kommunikation
MoE gør det muligt at opskalere til hundredvis af milliarder eller billioner af parametre ved at aktivere et lille sæt eksperter pr. token. Det reducerer inferenskosten. Men under træning stiger kommunikationsbehovet, fordi tokens skal routes all-to-all mellem eksperter på tværs af noder. Sammenlignet med tætte modeller er flaskehalsen i stigende grad netværket.
Kernen her er Expert Parallelism. EP tilføjer et dynamisk all-to-all-mønster oven på de mere velkendte mønstre i Tensor-, Data- og Pipeline-parallelisering. Det skaber fan-out-trafik og sårbarhed over for p99-latency og små jitter-hændelser. En enkelt straggler kan stoppe en hel step.
Deep-dive i Expert Parallelism
EP betyder, at hver batch splitter tokens efter gating og sender dem til de valgte eksperter. Trafikken er ikke kun stor, den er ujævn. Expert load kan svinge fra step til step, og routing skal håndtere det uden overdreven buffering eller kopiering. På små klustre kan intra-node båndbredde bære en del. Når der skaleres ud, kommer inter-node RDMA, kollektiv kommunikation og all-to-all-optimeringer i centrum.
Interaktionen med TP\/DP\/PP gør tingene mere skrøbelige. TP lægger faste, tætte kommunikationsmønstre. DP synkroniserer gradients. PP sekventerer lag hen over noder. EP skærer på tværs og bryder antagelser om jævn trafik. Summen kræver stabil, lav-latens fabric og et kommunikationslag, der forstår EP’s all-to-all-særheder.
EKS + EFA + Deep
EP — hvad hver komponent bidrager med
Amazon EKS er Kubernetes som managed service. Pointen er, at EKS kan orkestrere heterogene workloads: rollout-farme med elastisk skalering og træningsjobs med strammere ressourcegarantier, affinity og isolering. EKS bringer kendte primitives som nodepools, DaemonSets, PodDisruptionBudgets og autoscalere ind i ML-klyngen.
Elastic Fabric Adapter er AWS’ netværksinterface med RDMA-lignende kapabiliteter på EC2. Ifølge AWS-dokumentationen bruges EFA til HPC og distribueret træning med lav latency og høj båndbredde over instanser. Det er her, MoE’s all-to-all kan undgå at køre ned i TCP-sand. Det er ikke magi, men RDMA hjælper.
DeepEP’s rolle i eksperttrafikken
DeepEP præsenteres som et optimeret kommunikationslag bygget til Expert Parallelism. Pointen er at gøre all-to-all effektiv over EFA ved at minimere kopieringer, samle små pakker og udnytte hardware-queues mere fornuftigt. Detaljerne i implementeringen er ikke fuldt dokumenteret i blogindlægget, men retningen giver mening: specialiseret kollektiv for EP frem for at tvinge alt gennem generiske NCCL-rutiner.
Hvis DeepEP ovenikøbet reducerer variance i latenstid, hjælper det hele RL-cyklussen. Stragglers koster dyrt, fordi træningen skal videre i lockstep, og rollout-arbejdere står og venter, hvis gradients eller checkpoints halter.
Konkrete krav til instanser og topologi
Det praktiske spørgsmål er altid: hvilke instanser og hvilken topologi. AWS’ HPC- og træningsguides peger typisk på EFA-aktiverede instanser som p4d\/p4de, p5 og tilsvarende generationer med NVLink\/NVSwitch intra-node og EFA inter-node. Man får mest ud af EP, når GPU’erne internt er forbundet tæt, og når inter-node-forbindelserne er stabile og brede.
Topologi betyder noget. All-to-all er nådesløs mod asymmetri. Over-subscription i top-of-rack, ujævn rack-placering af noder eller blandede instanstyper gør ondt. Det kan være fristende at blande standby-rollout-noder og træningsnoder i én nodepool for at spare, men det kan give forstyrrelser i fabric og uforudsigelig performance.
Så hvad med de 40 procent
Blogindlægget peger på 40 procent mere throughput. Hvad menes der? Gælder det tokens per sekund på træningens hot path, sekvensgennemsnit over en fast varighed, eller en samlet pipelineløft for rollout plus træning? Der er ikke leveret fulde metrikker, batch-størrelser, sekvenslængder, antal eksperter pr. lag, modelstørrelse eller cluster-skala. Det gør påstanden interessant, men ikke verificeret.
For at tage tallet alvorligt bør man se p50\/p95\/p99 for batch-throughput pr. step, stabilitet over mindst nogle tusind steps, samt fejlrater, retry-adfærd og eventuelle OOM-spikes. Uden den kontekst er 40 procent et pejlemærke, ikke en garanti.
Hvad der skal være på plads for produktion
MoE-RL i produktion kræver mere end netværk: robust checkpointing (med integritetscheck og hurtig genstart), autoskalering af rollout-farme uden at sulte træningskøen, kontrol over eksperternes belastning (gating-regularisering, load-balancing) og en CI\/CD-lignende vej for belønningsmodeller og verifikationslogik.
På Kubernetes betyder det også pod-placering med GPU-affinity, isolering af netværksintensive pods, forudsigelige opgraderinger af noder og mekanismer til at undgå N-1-mareridt, når en enkelt nodenedsmeltning sender all-to-all på slingrekurs.
Drift, MLOps og den kedelige del
RLHF- og GRPO-workflows har biprodukter: masser af artefakter, logs og målinger. Reward-modeller skal versionsstyres og kunne rulles tilbage. Verifikatorer kræver dataadgang med governance. Checkpoints vil sluge I\/O. Definér klare livscyklusser for modeller og data, plus kvoter, så rollout ikke fylder hele lageret med midlertidige traces.
Orkestrering af rollout mod træning bliver et reelt planlægningsproblem. En praktisk strategi er at køre separate nodegrupper for rollout og træning med forudsigelig QoS og kun tillade opportunistisk deling, når klyngen har luft. Mixing uden kontrol forurener målingerne og gør performance-sammenligninger ubrugelige.
Økonomi og TCO
Hvis man kan løfte throughput 40 procent uden at øge omkostningen tilsvarende, falder pris per token i træning. Men EFA-aktiverede instanser er dyre, og nogle topologier binder dig til bestemte regioner eller kapacitetsvinduer. Den reelle gevinst opstår først, hvis løftet går igen i slut-til-slut-pipelinen, ikke kun i én kollektiv i et enkelt lag.
En nøgtern TCO-model bør inkludere: instansomkostninger, netværksomkostninger, potentielle premium-gebyrer for EFA, marginale lageromkostninger for flere checkpoints og artefakter samt udviklingstid til at tune DeepEP og EP-parametre. Og en separat linje for fejl og re-run. Det er her, pengene forsvinder, hvis man glemmer det.
En nøgtern POC-opskrift
Før større investeringer giver en kort POC rigeligt læring. Et muligt forløb:
- Definér en lille MoE-model med EP aktiv, fastlæg eksperter pr. lag og sekvenslængder, og frys hyperparametre.
- Provisionér et minimalt EFA-aktiveret klyngeudsnit i EKS med dedikerede nodegrupper til rollout og træning samt isolerede netværkspolicies.
- Mål baseline uden DeepEP (fx generisk NCCL-opsætning), indsamling af p50\/p95\/p99 per step over mindst 2.000 steps, log varians og fejl.
- Aktivér DeepEP, gentag nøjagtigt samme workload og mål samme metrikker. Sammenlign også end-to-end tid for en fuld RL-iteration inkl. rollout.
- Log ressourceudnyttelse: GPU busy, PCIe\/NVLink-udnyttelse, netværksbåndbredde og retransmits. Uden det er tallet svært at forklare.
- Udregn pris per token og pris per fuld iteration, ikke kun tokens per sekund.
Hvis gevinsten er stabil og reproducerbar, har man et reelt grundlag til at gå op i skala. Hvis ikke, var det en billig læring.
Hvornår arkitekturen ikke giver mening
Små teams med moderate modeller får sjældent værdi af EP-kompleksiteten. Standard DP\/TP over et godt Ethernet kan være fint. Ligeledes hvis rollout er lille, og træningen dominerer, vil gevinsten ved at orkestrere to heterogene lasttyper falde.
Der er også lock-in-overvejelser. DeepEP over EFA er en AWS-specifik kombination. Ønsker man multicloud eller hybrid, kan det koste tid at oversætte stakken til andre RDMA-løsninger. Det kan være et fair trade, men bør være et bevidst valg.
Hvad der mangler i materialet
Blogindlægget mangler centrale detaljer for metodisk vurdering: præcis workload (sekvenslængde, batch-størrelse), antal eksperter pr. lag, model- og klyngestørrelse, p50\/p95\/p99 på throughput og latenstid samt fejl- og retry-profiler. Der er heller ikke vedlagt offentlige konfigurationer til EKS-operatorer, netværkspolicies eller DeepEP-parametre, der gør forsøget reproducerbart.
Uafhængige benchmarks mod alternativer er fraværende: standard NCCL over EFA, RoCE-baserede RDMA-varianter eller sammenligning med lignende stakke hos andre udbydere. Uden de datapunkter er 40 procent en lovende indikation, ikke en konklusion.
Hvorfor det alligevel betyder noget
Selv uden fuld metode er budskabet klart: når MoE bliver mere sparsom, skifter man flaskehals fra compute til kommunikation. Arkitekturen skal optimeres derefter. RDMA-lignende netværk og EP-bevidste kollektivbiblioteker vil sandsynligvis være standard i næste bølge af produktionstræning af store modeller.
Det interessante er også, at RLHF\/GRPO tvinger inferens og træning ind i samme operationelle ramme. Det er ikke bare en engangsfinetuning. Det er en løbende fabrik — med krav til skalerbarhed, overvågning og styr på levetiden for modeller og data.
Hvordan man læser 40-procent-tal i 2026
Bed om varians og konfidensintervaller. Bed om fejlprofiler. Og bed om at se end-to-end-målinger, ikke kun et enkelt kollektiv. Et flot gennemsnit kan gemme på grimme haler. Det er halerne, der ødelægger nætter.
Hvis tallene ikke kan leveres, så lav din egen måling i lille skala. Måske får du ikke 40. Måske 15. Sommetider er 15 det, der får budgettet til at hænge sammen. Det er stadig en sejr.
Det sidste åbne spørgsmål
Hvad sker der, når eksperter ubalancerer i praksis, eller når et par EKS-noder hopper af under en rullende opgradering? Der er ikke meget skrevet om failure modes. Heller ikke om korruption af checkpoints. En ærlig postmortem eller to ville hjælpe — ikke for at udstille, men for at lære.
Indtil der kommer mere dokumentation, er det klogt at regne med driftsfejl som førsteordens faktor. Overprovisionér lidt netværk. Vær konservativ med EP-param-tuning. Hold øje med p99, ikke kun p50.
Konklusion uden pynt
AWS’ opskrift med EKS, EFA og DeepEP adresserer reelle problemer: orkestrering af heterogent compute, høj-throughput kommunikation og stabilisering af EP’s all-to-all. Påstanden om 40 procent flere tokens lyder plausibel i nogle scenarier, men mangler endnu metode og reproducerbarhed i offentligt materiale. Retningen er fornuftig for teams, der mærker netværket mere end GPU’erne.
Næste skridt for beslutningstagere er enkelt: kræv målinger med varians, kør en lille POC, modellér TCO’en med både compute, net og driftstid — og vælg topologi før prisskilt.
