Pointen først: prime-rl 0.6.0 er ude. Målet er RL-træning af trillion-parameter MoE-modeller på lange, agentiske arbejdsgange. Arkitekturen er asynkron og skåret til for at holde farten fra rollout til opdatering — uden at én outlier lammer hele kæden. Hvis du har kørt RL på komplekse kodningsopgaver, ved du, hvor ofte en enkelt timeout vælter en hel batch. Her skal det ikke ske.
Hvad prime-rl 0.6.0 forsøger at være
På inference-siden peges der på FP8, Wide Expert Parallelism, adskilt prefill og decode, tieret KV-offload og router replay. Kort fortalt: FP8 bytter en smule præcision for markant throughput. Wide EP fordeler eksperter på mindst 32 GPU’er, så routing bliver effektiv. Prefill og decode skilles ad, så tunge prefill-bursts ikke kvæler decode. KV-offload flytter cache fra GPU til RAM og disk i lag, så langt mere kontekst kan holdes i spil. Router replay gemmer routerens valg og spiller dem tilbage i træneren for mindre mismatch. Niche, ja — men vigtigt når rutevalg skifter med last og cache-genbrug.
Træningsoptimeringerne i kort form
På trænersiden: 3D-parallelisme (FSDP til at shard’e parametre og optimizer-state, ekspert-parallelisme til MoE, pipeline\/checkpointing efter behov). Derudover block-scaled FP8 under træning for at balancere hastighed og stabilitet. Bygget på Torchtitan som PyTorch-native base. Ambitionen er at undgå, at RL bliver permanent inference-skævt — i stedet holdes både træner og inference varme uden at vente på hinanden.
Komponenterne er ikke nye hver for sig. Det nye er kombinationen — især asynkrone opdateringer, router replay og aggressiv KV-styring — målrettet de lange SWE-forløb, hvor en agent skriver, tester, kalder værktøjer, læser logs, prøver igen. Det er en rodet tråd, der stadig skal destilleres til et brugbart læringssignal.
Validering af tallene
MarkTechPost fremhæver: 131k tokens i sekvens, 256 rollouts i batch, step-tider under fem minutter, 28 H200-noder. Stramme tal. Men afgørende detaljer mangler for at vurdere kapacitet og reproducerbarhed: Er 256 rollouts pr. optimizer-step, pr. GPU, eller samlet global batch? Hvordan måles step time — fra første token i batchen til nye weights pushes, eller som glidende median? Og hvad er variansen — steady-state eller bedste run?
Hvorfor det betyder noget for SWE-automatisering
Hvis det virker som beskrevet, løfter det brugbarheden af flertrins kodeagenter. Længere kontekster og stabil throughput gør, at en agent kan fastholde en hel fejlsøgningssession uden at miste tråden. Det reducerer manuelle handoffs og copy-paste mellem værktøjer. Det er dér forskellen ofte opstår — fra en poleret demo til noget, der kører tirsdag eftermiddag, når CI fejler halvvejs.
Men regningen findes stadig. Data og infrastruktur bliver tungere. Test og generalisering bliver sværere, fordi politikken lærer i et system med ruter og caches, der flytter sig. Og omkostninger kan eksplodere, hvis routeren rammer skævt, eller eksperter belastes ujævnt. Med MoE kan en forkert tune give hot-spot-eksperter, der sluger kvoten, mens andre står kolde.
Drift og omkostninger i realiteten
28 H200-noder lyder lavt til et trillion-parameter MoE-setup, men MoE aktiverer kun et top-k sæt eksperter pr. token. Compute- og memory-tryk ligner derfor ikke en tæt 1T-model. FP8 på inference og block-scaled FP8 under træning hjælper yderligere på throughput og VRAM. KV-offload frigør GPU-hukommelse, men kræver RAM- og diskdesign, der ikke kvæles af I\/O — regningen flyttes, ikke slettes.
Grov pejling: En tæt 100B-model i BF16 kræver væsentligt mere GPU-hukommelse end en sparsommere MoE med mange inaktive parametre. Til gengæld koster MoE på routing og netværk: dispatch\/combine pr. lag, cross-node hop, router-score overhead og ekstra telemetry. Med 3D-parallelisme stiger kravet til interconnect. 28 H200 kan være nok til et specifikt GLM-5.1-layout, men uden netværksspec og ekspertstørrelser kan tallet ikke bruges som generelt pejlemærke.
Sikkerhed, governance og modelkontrol
Lange, agentiske jobs med asynkrone opdateringer bringer policy drift i fokus. Når rollouts kan blande vægtversioner, risikerer man uforudsete handlinger — især hvis værktøjer uden sandbox kalds sent i et forældet forløb. max_off_policy_steps, KV-salt og request-dropping er fornuftige værn, men kræver tæt monitorering: Hvad er off-policy-raten under spidslast? Hvor ofte droppes ældre requests? Hvad er fallback, hvis trafikken zigzagger under en uheldig deploy?
Policy-versionering bør være strammere end i klassisk supervised-træning. Logs fra router replay, per-ekspert-udnyttelse og KV hit\/miss er baseline — ikke nice-to-have. Uden dem ved man ikke, om læringen optimerer de rigtige spor, eller bare bliver hurtig til at gentage tidligere ruter. Governance bliver lige så meget en netværks- og køstyringsopgave som en modelopgave.
Hvad journalister og konkurrenter bør tjekke
- Repo og release: offentlig commit for prime-rl 0.6.0, changelog og eksempelkonfigurationer (rl.toml, Slurm-scripts).
- Benchmark-logs: dokumentation af 131k-sekvens, 256 rollouts og <5 min step-tider inkl. metode, varians og steady-state vs. bedste run.
- Hardware og netværk: bekræft 28 H200-noder, InfiniBand\/NVLink-topologi og I\/O-profil for KV-offload. En faktura eller cloud-kvoteudtog hjælper.
- Plausibilitetstjek: en uafhængig driftsingeniør\/hardwarepartner bør vurdere routingtrafik, EP-skalering og båndbreddekrav — inkl. router replay-payloads i stor skala.
- Reproducerbar mini-test: kør en neddroslet konfiguration for at måle step-time og KV-offload-latens. Det afslører ofte mere end slide-tal.
Praktisk betydning for workflows
For softwareteams er ikke ordet “trillion” det interessante, men om en agent kan holde en lang plan kørende uden at blive kortåndet. Med 131k tokens i konteksten kan designovervejelser, testfald og fejlspor ligge i samme session. En agent, der læser issue-tråden, foreslår patch, kører tests og justerer efter logs — uden at skulle genoptrænes med halve romaner hver gang — er reelt nyttig. Det er her, RL på agentiske forløb skiller sig ud fra ren SFT.
Arbejdsgangene ændrer sig dog. Testmiljøer og sandkasser skal være mere robuste, fordi agenten kan tage længere beslutningskæder. Observability flytter fokus: policy-version skew, off-policy-rate, KV hit\/miss, per-rollout ventetid, memory pressure. SLA’er bliver anderledes: Asynkronitet glatter gennemsnit, men halerne skal fanges, så læring ikke går i stå i mørke pletter, når køer låser.
Implementering og drift
Start et pilotsetup med node- og netværksarkitektur. Planlæg tiered KV-offload: GPU → RAM → hurtig lokal NVMe → evt. delt butik. Adskil prefill\/decode med en jobplanlægger, der forstår forskellige worker-typer. Checkpoint hyppigt nok til at tåle preemption og outliers. Vælg router (fx vllm-router-fork vs. NVIDIA-variant) ud fra målinger — små forskelle i scorefunktioner kan give store forskelle i hot-spotting.
Overvåg tæt: per-ekspert-udnyttelse, router replay-throughput, dispatch\/combine-tid pr. lag, off-policy-metrikker. Mål cost-per-rollout i kroner og minutter — ikke kun tokens\/sek. FP8 skærer GPU-timer, men kan flytte tryk til RAM\/disk og netværk. Den regning tæller også.
Projektprioritering og tradeoffs
Kør et MoE-RL-pilot, når der er klart definerede multi-step-flows med målbar gevinst pr. succesfuld gennemførsel, budget til nogle dusin GPU’er plus solid storage og hurtigt net, og governance klar til versionering og nødbremse. Ellers ender det i en dyr PoC, der mest viser, at observability ikke er klar.
FP8 vs. BF16\/FP16: FP8 giver fart, men kan give små præcisionsstød. I RL kan hjørner gøre ondt, fordi belønningssignal og politik opdateres i sløjfer. Test derfor kvalitet og stabilitet — ikke kun throughput. Sparse routing sparer compute, men gør jer afhængige af routerens dømmekraft. Fejlrouting kan koste dyrt.
To realistiske startspor
1) En lille MoE med få eksperter og moderat sekvenslængde, asynkron RL, adskilt prefill\/decode og enkel KV-offload. Mål end-to-end step-time og off-policy-rate under last. 2) Et latensfokuseret forsøg, hvor router-scoring tunes mod KV-genbrug, og hvor I måler, om replay faktisk reducerer KL-mismatch i jeres data.
Tag ikke hele pakken fra dag ét. Hold et par elementer konstante og mål effekten af de andre. Små skridt. Der er rigeligt at styre — også uden trillioner i overskriften.
Det sidste, der undrer
Router replay beskrives som at kunne skære KL-mismatch cirka en størrelsesorden. Stor gevinst. Men payload-formatet — [num_layers, top_k, seq_len] — og datarater i titals Gbps varsler dyr netværksadfærd. Uden en klar forklaring på, hvordan det holdes effektivt over 28 H200-noder, er der et hul. I et lukket cluster med tyk InfiniBand kan det være fint; på commodity cloud kan det blive noget andet.
Ambitionen om at køre en fuld GLM-5.1-run via én Slurm-kommando er tiltalende. Hvis der følger en reproducerbar eksempelkonfiguration med, vil mange teams bruge den som baseline — ikke fordi det er plug-and-play, men fordi en solid start gør det nemmere at finde flaskehalsene i eget miljø.
