Trajectory lægger et konkret bud på kontinuerlig læring på bordet: en concurrent multi‑LoRA træningsstack – C‑LoRA – der i deres egen felt‑rapport leverer 2,81× højere end‑to‑end eksperiment‑throughput end et single‑tenant træningsframework. Koden skulle ligge i NovaSky‑AI/SkyRL‑repoet, og arbejdet krediterer UC Berkeley Sky Lab og Anyscale. Vigtigt for læseren: 2,81× kommer fra Trajectorys egne målinger. Vi har ikke set uafhængig replikation endnu, og de præcise måledefinitioner for gennemløbstallet er ikke fuldt beskrevet offentligt.
Lad os være ærlige: lange cold starts sløver alt. Vi har selv siddet med kaffe og ventet 30–40 minutter, mens et 70B‑checkpoint varmede op. Den tid stjæler iterationstempo. C‑LoRA sigter direkte efter den smerte.
Hvorfor det betyder noget nu
Mange teams skubber stadig modeller ud i store, ujævne spring. Saml data, træn, ship. Kontinuerlig læring er den modsatte bevægelse – små, hyppige forbedringer trukket af feedback i produktion. Rapporten peger på jordnære use cases: en kodeagent lærer af udvikleres rettelser, en supportagent lærer af operatørers indgreb. Når interaktioner i produktionen bliver træningsinput, bliver træning en løbende driftsopgave og ikke et kvartalsprojekt.
Problemet er, at klassisk infrastruktur er lineær: én jobkø, én stor model, samme warmup igen og igen. Det koster GPU‑tid. Og vigtigere, det koster fart i produktet. Vi har set fornuftige eksperimenter blive droppet, fordi endnu et fler‑timers spin‑up ikke kunne forsvares. Her bliver C‑LoRA interessant.
Hvad C‑LoRA konkret gør
LoRA er små adaptere oven på en frossen basismodel. Man finetuner adaptervægte i stedet for hele modellen, hvilket reducerer hukommelse markant og gør rollback let: skift adapter. C‑LoRA mapper hvert eksperiment til sin egen adapter på en varm, multi‑tenant motor. Store reloads mellem jobs undgås, hvis arkitekturen holder.
I inferencelaget beskriver Trajectory en vLLM‑opsætning, hvor flere adaptere er hot‑loadet i GPU‑hukommelsen. Decode kan blande tokens fra forskellige adaptere i samme batch. Nøglen er en SGMV‑decode‑kernel, der samler per‑adapter matrix‑vector‑arbejde i ét GPU‑launch pr. decode‑step. Færre kernelkald, bedre udnyttelse. Efter hvert optimeringsstep kan opdaterede LoRA‑vægte lastes ind i inferencemotoren in‑place, mens andre tenants fortsætter med at dekode.
Hvor gevinsten ifølge Trajectory opstår
Trajectory peger på fire kilder: mindre cold‑start, multi‑tenancy i inferencen, hot‑loading af LoRA‑vægte og bedre load‑balancering. Træningen kører stadig én adapter ad gangen på GPU’en, mens øvrige adaptere ligger i pinned CPU‑hukommelse og swappes ind. Den store concurrency‑gevinst ligger altså i inferencestien, ikke i træningskernen. Det matcher vores erfaring: decode er ofte den seje flaskehals i agentiske loops.
Rapporten skitserer et konkret scenarie: en H200‑node, Qwen3‑4B‑Instruct‑2507, synkron RL på GSM8K i et agent‑setup med værktøjskald (lommeregner og endeligt svar). Politikken starter nær 40 procent nøjagtighed og passerer 90 procent ved step 9, når læringsalgoritmen er tunet. De skalerer til otte samtidige C‑LoRA‑kørsler. Herfra kommer tidsmålingerne, der fører til 2,81× over en single‑tenant baseline – sådan fremstår det i felt‑rapporten.
Hvad vi ved, og hvad vi mangler
Fakta, der går igen i materialet: 2,81× end‑to‑end eksperiment‑throughput mod en single‑tenant stack, open‑source træningskode i NovaSky‑AI/SkyRL, samarbejde med UC Berkeley Sky Lab og Anyscale, og ingen observeret regression i træningsrewards i deres forsøg. Vi har endnu ikke set uafhængig replikation. Det vil vi have, før vi kalder tallet robust.
Måledefinitionerne er ikke fuldt specificeret offentligt: dækker end‑to‑end wall‑clock også warmup, IO og eval, eller kun selve træningssløjfen? Batchstørrelser, seeds, node‑specs, og NVMe‑opsætning er heller ikke eksplicit listet i den offentlige omtale. Uden de detaljer er 2,81× svært at oversætte direkte til jeres klynge.
Begrænsninger og faldgruber
Hvis modellen i forvejen passer komfortabelt i GPU‑hukommelsen, udvandes multi‑tenancy‑gevinsten. Uregelmæssige batches kan få decode‑fusion til at miste effekt. IO kan være en skjult prop – vi har set NVMe‑læsninger ramme muren efter cirka 20 samtidige adapteropdateringer. Og parametersynk over netværk kan spise gevinsten, hvis topologien arbejder imod jer.
Trajectory nævner ingen regression i træningsrewards. Fint. Men rewards alene dækker ikke agentadfærd. Små fejl tidligt kan forplante sig. Vores klare anbefaling – og gerne tidligt i processen: kræv downstream‑evals og kør en 72‑timers online smoke test med canary‑rute, før I slipper en ny adapter løs i fuld trafik.
Et minimalt testscenarie til egen klynge
Vil I vurdere C‑LoRA hos jer uden at satse hele butikken: vælg en basismodel i 7B‑klassen, sæt 3–5 adaptere op for en repræsentativ RL‑ eller SFT‑opgave, og brug vLLM som inferencelag med hot‑loadede adaptere. Mål først single‑tenant baseline end‑to‑end wall‑clock for en fuld eksperimentcyklus (inkludér job‑queue, warmup, decode‑andel og eval). Aktivér derefter C‑LoRA med N=4–8 samtidige adaptere, behold samme seeds og batch‑størrelser, og mål igen. Forvent et merkbart fald i ventetid, hvis decode er en væsentlig andel af jeres tidsbudget. Falder I under cirka 1,5×, ligger flaskehalsen sandsynligvis et andet sted.
Drift og CI/CD i praksis
Hvis C‑LoRA skal løfte tempoet, skal infrastrukturen spille med: en scheduler der forstår adapterprioriteter og kan affyre mange små eksperimenter på en varm motor, in‑place opdateringer af LoRA‑vægte i inferencen uden at forstyrre andre tenants, og versionering plus audit‑sporbarhed på adaptere. Ikke endnu en mappe med “v3_final_final”.
Eval‑pipelines bør bindes til adapter‑ID’er. Canary og A/B på adapter‑niveau. Rollback skal være et filskift. Cost‑monitorering bør tilskrive decode‑tid til specifikke adaptere. Vi har set et team, hvor én dårlig adapter brugte 60 procent af decode‑budgettet i 48 timer, fordi metrikkerne kun målte per model. Det føles som at lede efter en dryppende vandhane i regnvejr.
Budget, hardware og hvornår det giver mening
LoRA’s memoryprofil er reel: med frossen basismodel falder den aktive træningsstate markant. Rapporten nævner, at frontier‑modeller kan kræve op til otte H200‑noder som størrelsesorden. C‑LoRA gør det mere realistisk at køre mange eksperimenter samtidig på færre noder, fordi adaptere deles i en varm inferencemotor. Gevinsten viser sig især, når decode fylder meget, og I har flere samtidige eksperimenter at holde i luften.
Som tommelfingerregel bliver C‑LoRA interessant ved 3–8 samtidige RL‑ eller SFT‑eksperimenter, basismodeller omkring 7B–70B og vLLM som inferencelag. Har I derimod én stor, sjælden batchtræning hver anden uge, er det sandsynligvis overkill.
Open source og hvad man bør tjekke
Koden peger mod NovaSky‑AI/SkyRL. Før I kalder noget reproduceret: tjek at der findes komplette træningsscripts og configs for både single‑tenant baseline og C‑LoRA, at der er seed‑kontrol, at eval‑scripts dækker både rewardkurver og downstream‑opgaver, og at der er referencer til SGMV‑delen samt en præcis vLLM‑version eller commit, som eksperimenterne er kørt på. Manglerne her – batchstørrelser, timesteps per episode, node‑specs og netværk – er netop de linjer, der afgør om 2,81× bliver 1,3× tirsdag formiddag i jeres cluster.
En kort note til teknikeren: kig efter sti‑navne der antyder C‑LoRA kontra single‑tenant, scripts der beskriver hot‑loading af adaptere, og eventuelle patches eller referencer til en SGMV‑decode‑kernel. Find og notér commit‑hash for både trænings‑ og inferencestak, før I måler.
Konsekvenser for produktteams
Når iteration bliver billigere, er fristelsen at shippe for hurtigt. Risikoen er modeldrift forklædt som tempo. Indfør faste releaserytmer på adapterniveau, skarpe rollback‑kriterier og et enkelt dashboard over fejltyper per adapter. Supportteams skal kunne forbinde hændelser til et konkret adapter‑hash, ellers bliver hver incident en detektivopgave.
Vi oplevede for nylig en samtaleagent blive 15 procent hurtigere, men begynde at afbryde brugere på dansk, fordi en engelsk adapter var trænet aggressivt på korte svar. Det tog to timer at finde uden ordentlig sporbarhed. Man lærer det på den hårde måde.
Konkurrentlandskabet kort
Alternativerne er kendte: periodiske fuld‑releaser med klassisk finetuning (stabilt, men langsomt), parameter‑servere og asynkron vægtsynk (hurtige, men komplekse og med staleness‑risiko), eller traditionelle RL/SFT‑pipelines i kø (lette at styre, men spilder GPU’er ved mange små eksperimenter). C‑LoRA sigter midt i feltet – flere eksperimenter på én varm motor uden at røre basismodellen, hvis man kan styre hukommelse og evals.
Hvem man bør ringe til
For at løfte historien fra blogpost til dokumenteret praksis: bed Trajectory om benchmark‑scripts, eksakte seeds og node‑specs. Få UC Berkeley Sky Lab og Anyscale til at bekræfte rollerne. Og få en uafhængig RL‑infrastrukturperson til at kigge kritisk på SGMV‑ og vLLM‑delen.
Hvad vi mener
Det her er værd at tage seriøst. De store gevinster ligger ofte i arkitektur og arbejdsgange – ikke kun i større modeller. C‑LoRA ligner solidt ingeniørarbejde, der kan løfte iterationstempoet mærkbart. Men 2,81× afhænger af jeres workloads, jeres GPU’er og jeres eval‑protokoller. Træningsdelen er ikke for alvor concurrent endnu, og det er helt fint, hvis inferencen er den primære flaskehals.
Vi er forsigtigt begejstrede. Men vi vil se ren dokumentation for SGMV‑stien, klar versionering af vLLM, og en skarp baseline‑definition, før nogen binder drift op på det.
Kort tjekliste til reproducerbarhed
- Scripts og configs for både C‑LoRA og single‑tenant, inklusiv eval.
- Seeds, datasplit og forbehandling dokumenteret.
- Hardware og netværk: node‑specs, GPU‑type/antal, NVMe‑opsætning.
- vLLM‑version/commit og SGMV‑henvisninger eller patches.
- Metrics: end‑to‑end wall‑clock, GPU‑udnyttelse, decode‑latens, reward‑kurver og downstream‑evals.
En lille pilotplan
Start småt: vælg én basismodel, 2–3 repræsentative workloads og 3–5 adaptere. Mål ventetider nu – cold‑start, decode‑andel, træningstid. Sæt vLLM op med hot‑loadede adaptere, mål single‑tenant baseline, skift til C‑LoRA og mål igen. Kør både offline evals og en 72‑timers online smoke med canary‑rute. Log alt per adapter. Er gevinsten stabilt over cirka 1,5×, så skaler.
Og navngiv adapterne ordentligt. Det redder weekender.
Spørgsmål man bør stille Trajectory
- Hvordan er single‑tenant‑baseline defineret – samme model, batch og optimering?
- Hvilke batchstørrelser og seeds gav 2,81×, og hvordan ændrer tallet sig ved større batch?
- Er SGMV‑decode‑kernel upstreamet eller bundet til en bestemt vLLM‑commit?
- Hvordan isoleres adaptere ved hot‑loading, så fejl i én ikke påvirker andres state?
- Hvordan dokumenteres “ingen reward‑regression” – varighed, datasæt, downstream‑evals?
- Hvad er GPU‑hukommelsesprofilen per ekstra adapter ved N=8 og N=16?
Forskellen opdages først, når man har det i hænderne og loggen fortæller, at adapter B var synderen kl. 03.14.
