Det korte først. NVIDIA har frigivet Nemotron 3.5 Lightning, en åben mixture-of-experts-model med 30 milliarder parametre, men kun 3 milliarder aktive per token. Samtidig lander NeMo Switchyard, et open source router-bibliotek, der dirigerer hvert agent‑step til den mest egnede model. Ifølge NVIDIA får man en 1 million tokens kontekst og hastighedsgevinster, der i nogle scenarier nærmer sig 4× over lignende størrelser. Ambitiøst, ja — men pointen her er skiftet i arkitektur: fra “én stor model løser alt” til en operativ stak af mindre, specialiserede modeller bundet sammen af routing.
Hvad Lightning er teknisk set
Nemotron 3.5 Lightning er en 30B MoE med 3B aktive parametre per token, bygget som en hybrid af Mamba‑2, MoE og klassisk Attention, ifølge NVIDIA-dækningen hos Marktechpost. I en MoE aktiveres kun enkelte eksperter per token, så man får stor kapacitet i baghånden, men betaler compute som en langt mindre model. Derfor kan 3B aktive parametre føles som et sweet spot: nok kapacitet til eksekvering, uden prisen ved 30B fuld densitet.
Kontekstvinduet er opgivet til 1 million tokens. Det er voldsomt — især til retrieval‑tunge agentforløb og sporbarhed i lange sessioner. NVIDIA positionerer Lightning til høj-volumen execution‑opgaver, fordi langvarige agenter typisk bruger mest tid på rutinekald og kvalitetssikring, ikke dyb ræsonnering. Det matcher hverdagen mange teams beskriver: det er ofte alt det omkring, der æder tiden.
Hvor farten kommer fra
Kvantisering er én del. Et NVFP4‑checkpoint følger med (sammen med BF16), designet til at køre native på Blackwell og Hopper og udvidet til Ampere via W4A16‑kerner. Groft sagt: NVFP4 kan give markante throughput‑gevinster på moderne NVIDIA‑GPU’er uden at vælte nøjagtigheden — men mål på egne opgaver. Ifølge NVIDIA ses op til 4× højere output‑hastighed versus lignende modeller og cirka 30% hurtigere completion på 10.000 PinchBench‑opgaver end Qwen3.6 35B ved tilsvarende accuracy. Det er deres tal, ikke uafhængige benchmarks.
NeMo Switchyard i praksis
Switchyard beskrives som en router, der vurderer hvert agent‑step og sender det til den mest hensigtsmæssige model. Simpelt i idé, men operationelt vigtigt: man undgår at tænde hele kedlen på en frontier‑model hver gang. Lightning kan tage tool‑kald, validering og simple parsing‑opgaver, mens sværere stykker eskaleres. Ifølge NVIDIA rummer Switchyard både tuning‑fri routere (en LLM‑klassifikator med session‑affinitet, en stage‑router der læser nylig værktøjsaktivitet, en eskalations‑router der starter billigt og rykker op ved vedvarende sværhedsgrad) og en tunbar prefill‑router, der lærer fra modellens residualstrøm. Kort sagt: send simpelt til simpelt — og spar turene til det dyre.
Drift og deployment uden røgslør
NVIDIA nævner, at Lightning kan køre single‑GPU, fx på 1× DGX Spark (GB10) eller 1× H100. Det åbner døren for solo‑udviklere og seed‑teams, men også for miljøer, der vil teste on‑prem uden at bygge et helt cluster først. Der peges også på hosted muligheder via Baseten, Together AI og Nebius. Realismen? Tjek serviceaftalerne hos udbyderen — routing og multi‑model hosting kræver anden observability end én model bag et enkelt endpoint.
On‑prem versus cloud bliver et praktisk valg. For regulerede virksomheder er on‑prem oplagt, når vægte og træningsopskrifter er åbne under OpenMDW‑1.1. For mellemstore teams kan “serve it” via en modelhost være en hurtig rute til produktion. Ulempen er, at Switchyard‑routing på tværs af miljøer skruer op for kompleksiteten i netværk, logning og fejlhåndtering. Helt jordnært: latencybudgetter skal genforhandles.
Sikkerhed, governance og datastyring
Åbne vægte og opskrifter er godt nyt for audit og intern tilpasning. Lightning udgives under OpenMDW‑1.1, og NVIDIA siger, at modellen er klar til kommerciel brug. Det giver adgang — og ansvar. Når teams kan flytte vægte rundt, branch’e varianter og route requests mellem flere modeller, opstår modelsprawl, versioneringsrod og udfordringer i data lineage. Det skal tæmmes fra dag ét.
Økonomien bag den tekniske idé
MoE med få aktive parametre lover lavere compute pr. token. Sammen med NVFP4 kan TCO se pæn ud på papiret. Men økonomi er ikke kun tokens. VentureBeat peger på, at mange virksomheder køber compute for hastighed og tilgængelighed, mens få kan spore omkostningerne præcist. GPU’er kører ofte under kapacitetsgrænser, og styringslaget bliver den blinde vinkel. Hvis Lightning + Switchyard bringer flere små modeller i spil, kan orkestrering og monitorering æde det, man sparer på 3B aktive parametre.
Pointen er ikke kynisme — det er måling. Uden synlighed i både token‑forbrug, routing‑mønstre og driftstimer bliver økonomien gætværk. Sæt klare latencymål, cost‑per‑opgave og en model‑promotionspolitik, der undgår eskalationer “for en sikkerheds skyld”. Ellers ender man hurtigt tilbage på frontier‑modellen alligevel.
Brugsscenarier og tidlige kunder
NVIDIA nævner navne som CrowdStrike, Harvey, CodeRabbit, Fastino Labs og Lila Sciences til opgaver inden for cybersikkerhed, jura, kodning, finans og sundhed/life sciences. De workloads, der fremhæves, ligner netop eksekveringslaget: log‑triage, kontrakt‑parsing, tool‑kald, kode‑review‑routing og lang‑kontekst retrieval over det store vindue. Ikke højpoetisk — bare drift. Og det gør mig faktisk mere optimistisk end endnu en “general reasoning”‑demo, fordi ROI kan måles hurtigere her.
Spørgsmålet er modenhed. Hvis disse cases er i produktion, vil man se stabilitetsdata, SLO’er og reelle før/efter‑sammenligninger mod frontier‑only‑setups. Kilden rummer ikke de detaljer. Ikke et rødt flag — men en invitation til due diligence.
Begrænsninger og åbne spørgsmål
De rapporterede performance‑tal er NVIDIAs egne: op til 4× output‑hastighed og ca. 30% hurtigere PinchBench‑completion end Qwen3.6 35B ved sammenlignelig nøjagtighed. Uafhængig validering mangler. PinchBench dækker ikke alle virkelige agentmønstre, og generaliserbarhed på domænespecifikke opgaver (især med stramme nøjagtighedskrav) er stadig noget, der skal testes — ikke antages.
Der er også praktiske huller i informationen. Detaljer om Switchyards router‑politikker, SLA‑garantier, håndtering af fejl i underliggende modeller og versionskonflikter i multi‑model miljøer er ikke dokumenteret i kilden. Ligeledes er den præcise hardwareprofil for “single‑GPU” drift uklar: memory‑fodaftryk, latenstal per batch og anbefalet konkurrencegrad pr. GPU. Her må teams enten vente på whitepapers eller prøve sig frem med konservative defaults.
Hvad det betyder i hverdagen for implementering
Skiftet fra monolit til modulær agentstak flytter tyngden over i integration og drift. API‑kontaktflader skal udvides med routing‑metadata, fejlhåndtering skal kende forskel på model‑ og værktøjsfejl, og logging skal kunne følge en session på tværs af modeller. Ikke svært — bare nyt for teams, der har bygget omkring én model per use case.
Nøjagtighed under lavere aktive parametre er også en reel afvejning. 3B aktive parametre kan være rigeligt til eksekvering, men ikke til domæner med høj semantik‑kompleksitet. Det stiller krav til fallback‑strategi: hvornår eskalerer man fra Lightning til en frontier‑model, og hvornår stopper man og beder om menneskelig validering. En halv sætning — men vigtig: dokumentér beslutningsgrænserne tidligt.
Implementeringscheckliste
- Afgræns et PoC til høj‑volumen, lav‑kompleksitet: log‑triage, skematisering af dokumenter, simple tool‑kald.
- Definér latencymål per step og en promotionspolitik: hvor mange fejl/omformuleringer før eskalation.
- Opsæt observability: korrelerede traces på tværs af modeller, cost‑per‑opgave, modelversion i hver hop.
- Valider nøjagtighed med jeres egne benchmarks, ikke kun PinchBench. Mål både precision og driftstabilitet.
- Planlæg fallback: frontier‑model, cache eller menneskelig review — og hvornår hver bruges.
- Sikkerhed: adgangskontrol til routeren, redaction i logs, data lineage og opbevaringspolitik.
- Kapacitetsplan: start single‑GPU hvor muligt, men mål memory‑tryk, batch‑effekter og udkastmodellens overhead.
- Licens og compliance: gennemgå OpenMDW‑1.1 og dokumentér kommerciel brug, tredjeparts‑komponenter og dataflow.
Hvad konkurrenterne vil sige — og hvad der står tilbage
Konkurrenter vil pege på, at routing giver ekstra kompleksitet, og at “én stærk model” ofte er enklere at drifte. Fair. De vil også fremhæve egne frontier‑modellers reasoning‑styrke på tværs af opgaver. Men hvis Lightning leverer på eksekveringslaget, bliver argumentet svagere dér, hvor volumen er høj, og kravene til svar er mere strukturelle end kreative.
Det hele afhænger af måling. Hvis teams får synlighed i omkostning pr. løst step og kan holde latenstider nede via Switchyard, er skiftet mere end “nice to have”. Hvis ikke, har man to problemer i stedet for ét. Ikke elegant sagt — men sådan ser det ud i praksis.
Den korte dom
Hold øje med uafhængige benchmarks på repræsentative agent‑workloads og konkrete driftstal fra de nævnte kunder. Man mærker først forskellen, når man sidder med det i hænderne.
