NVIDIA har frigivet Nemotron 3 Ultra, en åben sprogmodel i den tunge ende af skalaen. Den er bygget som en 550 milliarder-parameter Mixture‑of‑Experts med 55 milliarder aktive per token og en hybrid Mamba‑Attention‑stack. Samtidigt annoncerer AWS dag‑nul tilgængelighed via SageMaker JumpStart med én‑klik deployment. Timingen er god. Og hvis påstandene holder, kan langkørende agenter blive både hurtigere og billigere at drive.
Vi har arbejdet med kunder, hvor agent‑workflows kører 20–200 step, kalder værktøjer, samler tråde op igen, og kontekstvinduet vokser som uønsket gæld. Her betyder throughput og pris per færdig opgave mere end single‑prompt latency.
Hvad der er nyt
Ifølge MarkTechPosts dækning af NVIDIAs tekniske rapport er Nemotron 3 Ultra en 550B total-parameter MoE‑model, 55B aktive per token. Arkitekturen kombinerer Mamba‑lag (sekvens‑effektive) med et mindre antal Attention‑lag for mere præcis genkaldelse. Konteksten er udvidet til 1 million tokens. Pretraining er kørt på omkring 20 billioner tokens, med eftertræning via SFT, RL og MOPD. AWS bekræfter samtidig, at modellen kan deployes dag ét via SageMaker JumpStart.
Kernepointen: modellen er målrettet langkørende agenter, som planlægger, kalder værktøjer og resonerer over mange omgange. Det fremgår både af MarkTechPosts artikel og AWS’ blog. NVIDIA fremhæver throughput‑gevinster mod åbne alternativer, og AWS skriver 5x hurtigere inferens og op til 30 procent lavere omkostninger ved agentiske workloads. Det er deres tal. Vi kommer tilbage til forbeholdene.
Kort teknisk overblik
Den tekniske rapport, som MarkTechPost linker til, oplister bl.a. 108 lag, modeldimension 8.192, 64 query‑hoveder og 2 key‑value‑hoveder for at holde KV‑cachen lille. Hvert MoE‑lag har 512 eksperter, hvor top‑22 aktiveres per token. Der bruges LatentMoE til mere effektiv routing, og Multi‑Token Prediction (MTP) gør det muligt at forudsige flere tokens per fremadkørsel. Det hjælper spekulativ dekodning på vej.
Hybrid Mamba‑Attention er praktisk interessant, fordi Mamba holder decode‑omkostningen pr. skridt mere stabil, når sekvensen vokser. Teorien er, at throughput derfor skalerer pænt op på lange forløb, hvor traditionelle Attention‑stakke ellers ville blive kvadratiske i omkostning.
Data, pretraining og læringskurver
MarkTechPost gengiver, at NVIDIA har kørt en Warmup‑Stable‑Decay læringsrate over cirka 20T tokens, hvor de sidste 5T har højere datakvalitet. Der nævnes også frigivelse af domænedatasæt, herunder 173 milliarder GitHub‑kode‑tokens, samt post‑training i stor skala: 10 millioner nye SFT‑eksempler og 1 million RL‑opgaver, plus 15 nye RL‑miljøer. Tallene er store – og de kommer fra NVIDIA‑materiale via MarkTechPost.
Ikke alt var gnidningsfrit. Rapporten beskriver to dokumenterede loss‑divergenser: én omkring 8T tokens relateret til gradientreduktion i for lav præcision, som blev rettet ved at gå tilbage til FP32; og endnu én omkring 16T tokens uden bekræftet rodårsag, hvor man justerede læringsraten og afkortede totalen til 20T tokens. Sjældent at se beskrevet så åbent – klædeligt for feltet.
Ydelse og forbehold
NVIDIA hævder ifølge MarkTechPost op til cirka 6x højere inferens‑throughput end sammenlignelige åbne LLM’er ved samme nøjagtighed. AWS skriver 5x hurtigere inferens og op til 30 procent lavere hostingomkostning for agentiske workloads, og at NVFP4‑optimeringen gør hosting hurtigere og mere omkostningseffektiv. Vigtigt: alt det er leverandørtal og skal valideres i uafhængige tests. Vi har ikke set tredjeparts wall‑clock målinger på 100k–1M token episoder endnu.
Husk også forskellen på latency og throughput. En MoE‑model med MTP kan køre mange tokens per sekund og stadig have en første‑token latency, som ikke altid imponerer i korte prompts. Det er fint for lange agenter, mindre relevant for chat med korte svar. Læs tallene i lyset af jeres brug.
Hvorfor arkitekturen kan gøre en forskel
108 lag, 8.192 dimension og 2 KV‑hoveder er ikke pynt. Det angriber den skjulte regning: KV‑cache. Med færre KV‑hoveder falder hukommelsesforbruget per token. LatentMoE bytter bredde i de skjulte dimensioner for at få flere eksperter i spil til samme pris, og MTP giver indbygget spekulativ dekodning. Summa: potentielt højere gennemløb uden at KV‑cachen eksploderer.
Men routing er ikke gratis. Top‑22 eksperter per token giver også mere varians. I en anonymiseret kundecase skabte skift i inputdistribution (fra kort faktasøgning til lang kodegenerering) “hotspots” i få eksperter. Det gav latency‑spikes på 30–40 procent i korte perioder. Løsningen var throttling og caching, men det tog uger at tæmme.
NVFP4 og kvantificering
NVFP4 beskrives i rapporten (via MarkTechPost) som E2M1 4‑bit med to‑dimensionel blokkvantificering af vægte, anvendt helt under pretraining. NVIDIA kalder det den største stabile og nøjagtige NVFP4‑demonstration til dato. Hvis det holder, er det et vink om, at hosting i samme format kan blive væsentligt billigere og hurtigere. AWS peger i samme retning i deres blog.
Et forbehold: vi mangler uafhængige replikationer, især for post‑training i NVFP4s slipstrøm. Numerisk stabilitet i efterfølgende SFT og RL i skarp drift er nævnt som stabil af NVIDIA, men tredjeparts validering er ikke på plads. Endnu.
Praktisk betydning i drift
Driften afgør alt. Hybrid Mamba‑Attention og 2 KV‑hoveder bør reducere KV‑cache‑overhead. Som groft Snilld‑estimat: hvis KV‑cachen lagres i en mellempræcision (ofte FP16 eller lign.), kan man tælle cirka dimension × hoveder × bytes × sekvenslængde for key og det samme for value. Med dim 8.192, 2 hoveder og hypotetisk 2 byte per element er vi i omegnen af 8.192 × 2 × 2 × 2 ≈ 65 kB per token for K+V. Over 1M tokens bliver det teoretisk ~65 GB pr. kontekstvindue. Der er mange hvis’er her (implementeringer kan komprimere, paginere til NVMe eller bruge anden præcision). Tag det som et konservativt overslag, ikke en fabriksopgivelse.
Overslaget betyder to ting i praksis: 1) uden pagineret KV eller cache‑pruning bliver 1M vinduer på enkelt‑GPU urealistiske; 2) planlæg for lagdelt hukommelse og aggressiv kontekststyring. Vi forventer, at Nemotron 3 Ultra‑deployment på SageMaker udnytter NVFP4‑optimeringer og streaming‑teknikker, men AWS’ blog oplister ikke konkrete GPU‑specs for 1M kontekst. Det savner vi.
Sådan sætter man et pilotforsøg op
Start simpelt. To trin. Først en throughput‑måling på jeres egne agent‑episoder: tokens pr. sekund, tool‑call overhead, andel af tiden i I\/O. Dernæst en cost‑per‑episode‑måling, hvor alle omkostninger tælles med, inkl. retrieval‑kald, API‑egress og fejlforsøg. Brug en fast “agent‑opskrift”, ellers er tallene ubrugelige at sammenligne på tværs af uger.
Tre målepunkter har fungeret for os: 1) token‑pris per færdig episode, 2) wall‑clock til succes, 3) kvalitetsmetrikker tæt på forretningen (fx løst sagsnummer, korrekt plan, gennemsnitlige efterrettelser). Vi har set én model vinde på tokens\/s, men tabe på wall‑clock pga. flere tool‑kald og længere kæder. Nemotron skal måles på det samlede billede.
Drifts‑ og governance‑hensyn
Lang kontekst giver nye risici. KV‑caches kan indeholde følsomme data. Krypter, afkort retention, og scrub PII inden caching. Overvej deterministic routing for kritiske flows og logning af top‑k ekspertfordelinger, så I kan auditere beslutningsveje, når noget går galt. Det er ekstra ingeniørarbejde, men man vil gerne have de logs den dag, hvor en agent beslutter noget underligt.
Der er også spørgsmålet om stabilitet over million‑token vinduer. NVIDIA rapporterer forbedringer i ablationer, men vi har ikke set uafhængige tal for hallucinationer eller factual drift ved 100k+. Vi har oplevet små, langsomme drifts i faktuel præcision, som først dukkede op efter 40–60 minutters kontinuerlig reasoning. Små ting, men de koster dyrt i produktion.
Adgang og integration
AWS’ blog siger dag‑nul adgang via SageMaker JumpStart med én‑klik deployment. Det gør early adoption let, og NVFP4‑optimeringen skulle gøre hosting hurtigere og billigere. Fint – men husk vendor‑lockin og datalokalisering. Vi anbefaler en hybrid arkitektur: lokal caching og RAG tæt på data, model i cloud, og tydelig strategi for egress‑omkostninger. Skaler efter behov, ikke efter hype.
“Åben” model lyder godt. Men hvad betyder det præcist i licens og artefakter? MarkTechPost omtaler åbenheden, og AWS kalder modellen åben, men vi savner klarhed om hvilke vægte, tokenizer og datasætsmetadata der frigives, og under hvilke vilkår. Indtil vi ser licenslinjerne, notér det som et åbent spørgsmål.
Begrænsninger og ubesvarede spørgsmål
Der er tre klare huller i materialet: 1) uafhængige wall‑clock benchmarks på lange agent‑episoder, 2) konkrete hardwarekrav for 1M kontekst (GPU‑RAM, NVMe‑scratch, cache‑strategi), 3) robusthed af LatentMoE‑routing under distributionsskift og modstandsdygtighed mod adversarial input. Vi har heller ikke set grundige målinger på dansk domænesprog. Det kan være fint, men vis os tallene.
Og så en teknisk krølle: NVFP4 er lovende, men hvad er den reelle indflydelse på eftertræningsfaser i skarp produktion over tid? NVIDIA kalder det stabilt i rapporten via MarkTechPost, men tredjepartsreplikationer mangler. Det ville klæde feltet med et par åbne reproduktioner.
Implikationer for produktteams
Hvis ydelsespåstandene holder på jeres data, kan I bygge mere tilstandsfulde agenter: planlæggere, kontrolsløjfer, orchestration med flere værktøjer – uden at prisen løber løbsk i inferens. To ting går stadig galt oftere end de burde: værktøjsfejl‑håndtering (time‑outs, retries) og gradual drift i kontekst over lange forløb. Byg testcases, der løber i 1–2 timer, ikke 5 minutter. Så opdager I forskellen.
På dansk og i regulerede domæner (offentlig forvaltning, finans) bør der lægges en ekstra compliance‑ramme ned over KV‑styring, logning og redigering af følsomme felter. Kedeligt, ja – men det er her, projekter enten dør eller skalerer.
Hvad vi forventer i målinger
For gennemløb: mål tokens\/s ved 50k, 200k og 1M kontekst. For pris: regn cost per afsluttet episode, ikke per 1k tokens alene. For kvalitet: brug 2–3 forretningsnære metrikker, ikke 20 generiske benchmarks. En enkel huskeregel: hvis jeres “hurtigere model” alligevel bruger flere tool‑kald og laver flere reparationer, er den ikke hurtigere i virkeligheden.
Når I evaluerer caching, så log KV‑footprint i GB per 100k tokens samt GPU‑udnyttelse. Snilld‑estimat som start: 6–8 GB ekstra GPU\/NVMe pr. 100k tokens for en konfiguration med moderat præcision og paginering. Det er et groft interval, ikke dokumentation. Kalibrér det med jeres egen opsætning.
Konsistens og hvor kilderne er tynde
Kilderne er konsistente på de store linjer: 550B total\/55B aktive, hybrid Mamba‑Attention, 1M kontekst, NVFP4, de nævnte arkitekturparametre og AWS’ dag‑nul JumpStart. MarkTechPost henviser eksplicit til NVIDIAs tekniske rapport for de tekniske detaljer. AWS’ 5x\/30 procent‑tal står i deres blog. Det tynde lag er de uafhængige driftstal, hardware‑specs for lang kontekst og licensdetaljer for “åben”. Dem mangler vi.
Vi blev positivt overraskede over, at NVIDIA delte træningsdivergenser. Det giver troværdighed. Men uden tredjeparts målinger på langløbende agent‑opgaver holder vi igen med superlativerne. Man opdager forskellen, når man sidder med det i hænderne – og ser regningen.
Hvad vi mener lige nu
Nemotron 3 Ultra ligner et seriøst bud på høj gennemløb til agenter, med MoE‑routing, MTP og NVFP4 som de praktiske gear. 2 KV‑hoveder er en no‑nonsense beslutning. AWS’ hurtige tilgængelighed gør det lav friktion at teste. Om 5–6x holder i jeres miljø, afhænger af kontekstbredde, tool‑mix og I\/O‑flaskehalse. Det er ikke kun en model – det er et system.
Andre aktører har også hurtige modeller. Men Nemotron 3 Ultra går direkte efter et smertepunkt, vi ser igen og igen: pris og fart i lange episoder. Hvis den rammer rigtigt, flytter den mere i praksis end endnu et pænt leaderboard.
Konklusion
Takeaway til jer der bygger agent‑løsninger: Nemotron 3 Ultra er værd at teste, især hvis jeres workloads løber længe og trækker stor kontekst. Teknisk set er pakken overbevisende med 550B MoE, 55B aktive, hybrid Mamba‑Attention, 1M kontekst og NVFP4. Kommercielt set er dag‑nul på SageMaker en klar accelerator. Men mål på jeres egne flows, ikke på andres grafer. Vi savner fortsat uafhængige wall‑clock tal, klare 1M hardwarekrav og licensdetaljer. Indtil da er det lovende – men kun bevis i egen drift tæller.
