Nemotron 3.5 Transcribe vs Nemotron 3.5 Transcribe 30B: två namn, en checkpoint, fyra filer

Om en katalog, en jämförelsesajt eller ditt eget inköpsblad listar Nemotron 3.5 Transcribe och Nemotron 3.5 Transcribe 30B som två poster, listar den samma modell två gånger. Det publicerade repositoriet är NVIDIA-Nemotron-3.5-Transcribe-30B-A4B, NVIDIAs modellkort anger totalen som 34B parametrar och antalet aktiva parametrar som cirka 4,3B, och det enkla namnet i varje rubrik är samma artefakt där storleken har utelämnats. Det finns ingen separat 30B-modell att jämföra med, vilket gör detta mindre till en direkt jämförelse än till ett namngivningsproblem med ett driftsättningsbeslut inbäddat i det.

Det beslutet är dock verkligt, och det är orsaken till att de två namnen ständigt dyker upp sida vid sida. Det ena namnet är det du söker efter och som en modellkatalog eller API-listning kan visa. Det andra är det du laddar ner, i en av fyra precisioner, vid ett av fyra minnesavtryck, och valet mellan dessa filer är den enda jämförelse som den här modellen faktiskt ber dig göra. Det som följer är avstämningen: vad som räknas in i 30B, varför kortet anger 34B, och vilken fil som passar den GPU du har snarare än den som lanseringssidan förutsätter.

Namnet som motsäger sig självt

Två siffror är i omlopp och båda är officiella. Repositorienamnet slutar på 30B-A4B, i enlighet med den konvention som NVIDIA använder för sin mixture-of-experts-serie: totala parametrar först, aktiva parametrar sedan. Modellkortet på samma sida uppger 34B totalt och cirka 4,3B aktiva, och anger uttryckligen att ljudkodaren ingår. Forskningssidan upprepar namnet 30B-A4B i sin rubrik och siffran 4,3B aktiva i brödtexten.

Kortet anger också delarna, och det är där aritmetiken börjar spela roll. Språkryggraden är Nemotron 3.5 Lightning 30B-A3B, en MoE-hybrid av Mamba-2 och Transformer med 3,5B aktiva parametrar. Den gemensamma ljudkodaren – en Transformer-ASR-kodare plus en talarkodare – ligger på omkring 800M. Lägger man samman dessa får man ungefär 30,8B, inte 34B. Antingen räknar 34B in något som NVIDIA inte har specificerat, eller så är 30B i förvarets namn en avrundad beteckning för en ryggrad som i själva verket är större än namnet antyder. NVIDIA har inte publicerat avstämningen, och någon oberoende parameterrevision av den fullständiga checkpointen finns ännu inte.

Vad det innebär för en köpare är snävare än det låter. Huruvida systemet är 31B eller 34B förändrar inte vilket kort det får plats på, eftersom filstorleken styrs av precisionen i mycket högre grad än av de sista tre miljarderna parametrar. Det innebär att varje datablad som anger "30B" och varje som anger "34B" beskriver samma nedladdning, och en upphandlingsjämförelse som bygger på skillnaden jämför en avrundningskonvention.

Vad 30B-suffixet egentligen räknar

Suffixet betecknar en språkmodell, inte en transkriberare. Nemotron 3.5 Transcribe är en talförstärkt LLM: ljudet går genom en Transformer-kodare, en fryst Nemotron 3 Diarization-modell bidrar med talarrepresentationer via det som NVIDIA kallar en parallell expertkodare, och den hybrida MoE-dekodern skriver transkriptionen. 30B-beteckningen tillhör dekodern och dess inbäddningsstack. Talvägen – kodaren, diariseraren, CTC-tidsstämpelhuvudet – ligger ovanpå och är inte det som namnet annonserar.

Det är därför modellen beter sig som en LLM på sätt som ett klassiskt ASR-system inte gör. Den tar emot promptar. Den svarar på frågor om ljudet. Den översätter mellan 31 par till och från engelska i samma genomkörning. Den har en kontext på 65 536 tokens så att en timmes tal får plats utan chunkning. Inget av detta kommer från att en 30B-avkodare är stor; det kommer från att avkodaren överhuvudtaget är en allmän språkmodell, med tal projicerat in i dess indatarymd.

Det förklarar också den frånvaro som alla ständigt letar efter. Det finns inget syskon som endast är 30B, ingen mindre dense Transcribe och ingen större sådan. Repositoriet innehåller precisionsversioner av en enda modell, inte en familj. De enda andra storlekarna i omlopp är kvantiseringar som gemenskapen har producerat, och en verkligt mindre streamingigenkännare – Nemotron Speech Streaming EN 0.6B – som är en annan modell med endast engelsk täckning och ingen diarisering, inte en miniversion av den här.

De fyra filerna bakom namnet, och vad var och en kostar i minne

Det här är jämförelsen som de två namnen egentligen pekar på. NVIDIA publicerar tre precisioner och communityn har lagt till ett fjärde leveransformat; minnessiffrorna nedan kommer från de publicerade checkpoints och community-repositorierna, inte från en enda leverantörstabell.

• BF16 – referenscheckpointen, cirka 67–68 GB på disk, serverad på ett enda H100 80GB. Det är den version som de publicerade benchmark-siffrorna producerades med, och den du ska använda när du behöver reproducera dem.

• FP8 – cirka 35 GB, vilket flyttar minimikravet till ett 48 GB-kort som L40S. Noggrannhetsförlusten gentemot BF16 är liten i NVIDIAs egen framställning, men det är NVIDIAs framställning; ingen oberoende FP8-utvärdering har publicerats.

• NVFP4 – cirka 21 GB, litet nog för ett RTX 5090 med 32 GB eller ett RTX PRO 6000. Det här är precisionen bakom NVIDIA:s omtalade genomströmningsanspråk på 2 238 sekunder ljud per sekund på ett enda RTX PRO 6000 med DFlash2-utkastmodellen ansluten.

• GGUF — fyra avkodare från communityn mellan 19,7 GB och 35 GB plus en obligatorisk F16-encoderfil på 1,67 GB. 19,7 GB-versionen IQ4_NL är den som är avsedd för 24 GB-kort, CPU-inferens, Metal och Vulkan; 19,7 GB-versionen NVFP4 är avsedd för Blackwell; Q5 ligger nära 29 GB och Q8 nära 35 GB. En valfri DFlash2-drafter på 1,15 GB lägger till spekulativ avkodning på CUDA-vägen.

• MLX — community-portningar på 4 till 8 bitar mellan ungefär 19 GB och 35 GB för Apple silicon, med en författare som rapporterar cirka 154 tokens per sekund i 4-bitarsbygget. Användbart för utvärdering på en Mac, inte en produktionsväg för servering.

Vad som kör dem, och det enda körningsfel folk gör

GGUF-filerna är fällan. Ett filnamn som slutar på .gguf innebär inte llama.cpp, Ollama eller LM Studio, och ingen av de tre kör den här modellen: den kräver en runtime för tal-LLM med ljudkodaren inkopplad. De fungerande vägarna vid lanseringen är snävare än formatlistan antyder.

• vLLM 0.32.0 – den primära vägen och den enda som exponerar hela utdataytan, inklusive ordtidsstämplar via V1-runnern och tidsstämpel-mellanprogramvaran. Utdata med talarattribuering och översättning finns här.

• SGLang-Omni 0.2.0 på SGLang 0.5.22 – transkribering av hela filer via en OpenAI-kompatibel ljudändpunkt, utan ordtidsstämplar, talarattribution, översättning eller spekulativ avkodning.

• NeMo Speech — finjusteringsverktygslådan, där NVIDIA anger 0,5 till 2,3 GPU-timmar per uppgift på en enda GPU. De publicerade LoRA-recepten körs på ett kort.

• NeMo-Speech.cpp och speech.cpp – den C++-väg som GGUF-byggarna riktar sig mot, och den enda som laddar dessa kvantiserade modeller. Både 19,7 GB- och 35 GB-filerna ovan distribueras för den, och README-filerna i repon är den ärliga källan till vad som passar var.

• Transformers — användning i samma process från en källinstallation, tillräcklig för utvärdering, inte för genomströmning.

Felet är att ladda ner den minsta kvantiserade versionen, peka llama.cpp mot den och dra slutsatsen att modellen är trasig. Den är inte trasig; den är en tal-LLM med en encoder som textkörningsmiljöerna inte har någon uppfattning om. Om körningsmiljön inte listar Nemotron 3.5 Transcribe bland sina arkitekturer som stöds, laddas filen inte oavsett hur liten den är.

Var varje fil passar in, i klarspråk

Arbeta bakåt från hårdvaran i stället för framåt från modellkortet. Den baslinje som anges på kortet – en H100 80GB i BF16 – är vägen för maximal trohet, inte den minsta.

• 24 GB-kort, RTX 4090 eller L4-klass — 19,7 GB IQ4_NL GGUF med sin 1,67 GB encoder. Lämna utrymme för KV-cachen och ljudbufferten; 24 GB är snålt men dokumenterat att fungera.

• 32GB-kort, RTX 5090 eller RTX PRO 6000 – 21GB NVFP4-checkpointen, som är den konfiguration som NVIDIAs påstående om genomströmning beskriver, med DFlash2-draftern om du vill ha spekulativ avkodning.

• 48GB-kort, L40S eller A6000 — 35GB FP8-checkpointen, den minst besvärliga kompromissen mellan återgivning och kostnad.

• 80GB-accelerator, H100 eller A100 — BF16, referenskonfigurationen och den enda som återskapar den publicerade WER-tabellen utan något precisionsförbehåll.

Ingen GPU alls – inga av dessa filer. Encodern körs på CPU i C++-vägen, men en timme ljud på en 30B-A3B-dekoder utan acceleration är ett batchjobb som mäts i timmar, inte en tjänst.

Ett villkor gäller oavsett precision: indata är 16 kHz mono-PCM och taket är en timme ljud per begäran. Nedsampling och kanalval sker innan modellen ser något, och en stereoinspelning från ett styrelserum mixas till mono om du inte själv delar upp kanalerna. Det är ett förbearbetningsbeslut, inte ett checkpointbeslut, och att göra det fel kostar mer i transkriberingskvalitet än BF16-till-FP8-steget gör.

Kontrollerna som ska köras när en annons visar båda namnen

Eftersom situationen med dubblerade namn är reell och kommer att återkomma i kataloger och jämförelsesidor är en kort verifieringsrutin värd mer än ännu ett förklarande stycke.

• Repo-id – den enda officiella artefakten är NVIDIA-Nemotron-3.5-Transcribe-30B-A4B. En rad med namnet Nemotron 3.5 Transcribe 30B med ett annat repo-id är antingen en kvantisering eller en helt annan modell.

• Licenssträng — OpenMDW-1.1 i den officiella utgåvan, kommersiell användning tillåten. En listning som anger endast forskning eller icke-kommersiell beskriver något annat.

• Kontext- och ljudfönster — 65 536 tokens och en timme. En specifikation som anger ett längre fönster är felaktig eller beskriver en annan checkpoint.

• Parameterpåstående — 30B-A4B i namnet, 34B i kortet, 4,3B aktiva i båda. En listning som anger 4B totalt har förväxlat det aktiva antalet med totalen, vilket är den vanligaste återgivningen av den här modellen på webben.

• Filförteckning — BF16, FP8 och NVFP4 från NVIDIA, plus en DFlash2-utkastmodell. Om en sida erbjuder "Nemotron 3.5 Transcribe 30B" som en enda nedladdningsbar fil och inga precisionsvarianter, är det en community-kvant som bär leverantörens namn.

Routningsfrågan som faktiskt är separat

När filen är vald och körningsmiljön fungerar är driftsättningsfrågan över, och en äldre återvänder: vad som händer med texten. En transkription är råmaterial för sammanfattning, entitetsutvinning, bortredigering, sökindexering och frågebesvarande, och dessa anrop är vanlig textmodellstrafik med vanliga textmodellproblem – hastighetsbegränsningar, avbrott uppströms, en billig klassificeringsmodell som skulle räcka för nio tiondelar av volymen.

OrcaRouter erbjuder inte Nemotron 3.5 Transcribe, och katalogen har ingen post under något av namnen; om du ser två rader för den här modellen var som helst är repo-kontrollen ovan det snabbaste sättet att avgöra saken. Det plattformen däremot erbjuder är lagret efter att transkriptionen finns: en OpenAI-kompatibel nyckel för över 200 text- och visionsmodeller till leverantörens listpris med 0 % påslag, automatisk redundansväxling mellan leverantörer, och ett routing-DSL som kombinerar flera modeller till ett anrop så att det billiga extraktionspasset och det dyra bedömningspasset kan ligga bakom en enda slutpunkt. GPU:n transkriberar; routingen avgör vad transkriptionen är värd.

Ändelsen är en filstorleksbeteckning, inte en andra modell

Det enklaste sättet att hålla båda namnen i huvudet är detta: Nemotron 3.5 Transcribe är produkten, Nemotron 3.5 Transcribe 30B är repot, och 30B räknar en avkodare medan kortet räknar ett system. Gapet mellan 30,8B och 34B är en ouppklarad detalj som NVIDIA bör stämma av, men den ändrar inget beslut en köpare fattar, eftersom beslutet fattas i gigabyte och i vilka körningsmiljöer som stöds, inte i den tredje siffran i ett parameterantal.

Välj den precision som ditt grafikkort klarar, bekräfta att körningsmiljön listar arkitekturen och behandla varje listning som presenterar de två namnen som separata modeller som ett katalogfel snarare än ett val. Det verkliga vägskälet i den här utgåvan – det som skulle motivera en genuin direkt jämförelse – är den strömmande igenkännaren på 0.6B på ena sidan och den här offline-transkriberaren på 30B på den andra. Den jämförelsen handlar om latens och täckning, och den är värd att göra. Att jämföra en modell med dess eget filnamn är det inte.