Generated banner for Nemotron Asr Finetune
Generated logo for Nemotron Asr Finetune

Nemotron Asr Finetune

NVIDIAOfficialCreated by Nemotron Speech TeamDistributed by NVIDIA

  • Skill
  • Workflow
  • Data and AI
  • Apache-2.0
  • Medium risk
  • Has scripts

From the author

Orchestration skill for NVIDIA Nemotron Speech (Riva) / NeMo ASR domain and language adaptation. Given a goal like "improve/fine-tune ASR for my domain or language", it scopes the task, picks the cheapest sufficient path (word boosting → n-gram LM → fine-tuning), delegates each stage to the right sub-skill (data generation, training, evaluation, deployment), and answers cost/time/data questions along the way.
— the description by Nemotron Speech Team

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

This skill acts as an intelligent orchestrator for adapting NVIDIA Nemotron Speech (Riva) ASR models to specific domains or languages. Rather than jumping straight to training, it guides users through a cost-effective ladder of customization techniques, starting with word boosting and n-gram language models before escalating to full acoustic fine-tuning. It manages the end-to-end lifecycle by scoping requirements, delegating tasks to specialized sub-skills for data generation, training, evaluation, and deployment, and providing data-driven estimates for time, cost, and hardware requirements.

What it does

  • Scopes ASR customization goals based on domain, language, and performance targets.
  • Identifies the cheapest sufficient path for improvement, from word boosting to full fine-tuning.
  • Delegates execution to specialized sub-skills for data, training, evaluation, and deployment.
  • Performs pre-flight checks for dataset quality and environment compatibility.
  • Provides estimates for data volume, GPU requirements, and expected costs.
  • Maintains a structured workflow to ensure efficient, measurable model adaptation.

When to use it

  • When you need to improve ASR accuracy for a specific industry domain or jargon.
  • When you need to adapt an ASR model to a new language.
  • When you want to reduce Word Error Rate (WER) in noisy environments like call centers.
  • When you need to plan a cost-effective ASR customization strategy.
  • When you are unsure whether to use word boosting, language models, or full fine-tuning.

Advantages

  • Prevents unnecessary, expensive training by prioritizing cheaper, effective methods first.
  • Ensures a structured, repeatable approach to model adaptation.
  • Provides clear guidance on hardware selection and data requirements.
  • Reduces risk of catastrophic forgetting by enforcing data volume and mixing best practices.
  • Centralizes planning while leveraging specialized sub-skills for execution.

Usage examples

“I need to improve ASR accuracy for my medical domain, it gets jargon wrong.”
The agent will scope the jargon issues, suggest a word-boosting pilot to test offline, and outline the data requirements for potential fine-tuning if boosting is insufficient.
“How much data do I need to fine-tune an ASR model for a new language?”
The agent will explain the requirements for cross-language transfer versus training from scratch, emphasizing the need for real audio and providing a data-volume estimate.
“What is the cheapest way to improve my ASR model's performance?”
The agent will initiate a diagnostic process to measure the baseline WER and recommend the lowest-cost rung on the customization ladder, such as word boosting or n-gram LM.

Install

  1. Download the skill as a ZIP:

    https://mp-staging.autogineer.com/agent-skills/nvidia/nemotron-asr-finetune/download
  2. Unzip it into the cross-client skills folder of your project:

    mkdir -p .agents/skills && unzip nemotron-asr-finetune.zip -d .agents/skills

Documentation by Nemotron Speech Team

Nemotron Speech ASR Customization — Orchestration Skill

Note: "Nemotron Speech" is the public-facing name for what NVIDIA documents today as Riva / Riva NIM; the acoustic models are trained and fine-tuned with NVIDIA NeMo. Commands, config paths, imports, and doc URLs still use "Riva" / "NeMo" — the rename is brand-only. Do not rename them.

What This Skill Is

This is a high-level orchestration skill, not a step-by-step training manual. Its job, given a goal such as "I want to fine-tune ASR for my domain/language", is to:

  1. Scope the problem (how much real audio, target eval set, latency/hardware budget, language/domain).

  2. Choose the cheapest sufficient path — word boosting, n-gram LM fusion, or fine-tuning — and escalate only when quality falls short.

  3. Delegate each stage to the right sub-skill (data generation, training, evaluation, deployment/optimization).

  4. Answer cost/time/data questions along the way (how many hours to hit X% WER, synthetic vs real, L40S vs H100, expected cost).

It owns the plan and the routing; the sub-skills own the execution. When a needed sub-skill does not exist yet, this skill names it as a placeholder and gives interim guidance.

When to Use

Use for any request to make a Nemotron Speech / Riva ASR model work better on a specific domain or language — improving accuracy, reducing WER, adding a language, or planning a fine-tune. Start here even when the user names a specific technique: treat it as a candidate until the orchestration step confirms it is the cheapest sufficient path, then sequence the right sub-skills.

Orchestration Workflow

Run the loop below; each stage names the sub-skill it invokes. Full detail in references/workflow.md.

#StageWhat happensSub-skill
1State the goalCapture the target: domain/language, the errors, the metric.Orchestration (this skill)
2Clarify & scopeAsk the discovery questions: how much real audio? target eval set? latency/HW budget? deployment target?Orchestration
3Choose the pathPick the cheapest sufficient rung (boosting → n-gram LM → fine-tune). Escalate only if quality is short; experiment while proposing the full plan.Orchestration → Research/Training
4Get the data rightIf data is scarce/noisy: synthetic (TTS), TTS-friendly formatting, noise profiling/harvest, blend, score vendor samples; align customer data to training format; flag missing real data.SDG / Data
5TrainApply the recipe (configs, hyperparameters, replay/curriculum, GPU/OOM preflight) and run.Research / Training
6EvaluateNormalized WER on the domain set + A/B forgetting check on a general set; error-driven analysis to find the next lever.Evaluation
7Loop or shipIf short of target, loop to 4/5 with targeted data; else select/average checkpoints. Consult the user before more cycles.Orchestration
8DeployExport to NIM/HF, hot-swap the checkpoint, serve.Deployment / Optimization

Stages 4–8 are the fine-tune path (data → NeMo train → NeMo eval → Riva deploy). Cheaper rungs (boosting, custom vocab, n-gram LM) take a shorter branch owned by a single sub-skill — don't force them through the full loop. See the branch-by-rung table in references/workflow.md (§3b).

Before training (Stage 5), run the pre-flight dataset quality check (§4a): verify/convert audio to 16 kHz, and, on user request, audit transcript quality by running a reference pretrained model and checking WER against the provided ground truth. See references/workflow.md §4a.

Also before training (Stage 5), run the pre-flight environment/dependency check (§4b): if no NeMo is provided, pull the latest main (local execution) or the latest published container tag (container execution). If a NeMo checkout/install is already provided, check its version, but still recommend switching to latest main (staleness risk) and ask the user — if they insist on the provided one, proceed with it and only revisit once a concrete version issue (e.g. unsupported functionality) is actually hit. See references/workflow.md §4b.

Throughout, answer the "along the way" questions (data volume, synthetic vs real, hours to reach a WER target, cost, GPU choice) — see references/planning-answers.md.

Sub-Skills This Skill Calls

Detailed registry, invocation, and handoff contracts in references/sub-skills.md.

Role (per the architecture)PurposeSub-skill to invoke
Research / TrainingNeMo configs, recipes, fine-tuning, checkpoint averaging; also owns the NeMo-side word-boosting and n-gram LM pilotsnemo-speech-asr-finetune
SDG / Data DesignerSynthetic transcripts/text, noise profiling, vendor-data impact, blendsdata-designer (synthetic text; audio via TTS in nemotron-speech); placeholder: asr-data-profiling
EvaluationNormalized WER, A/B forgetting, error analysisOffline file WER → nemo-speech-asr-finetune; served-endpoint WER → nemotron-speech
Deployment / OptimizationNIM/Riva export, checkpoint swap, NIM-build optimization, servingnemotron-speech

If a sub-skill is unavailable, say so, give the interim guidance from the reference, and continue the plan.

Choosing The Path (cheapest first)

The scoping in Stage 3 selects the lowest-cost rung that can meet the target. Summary; full docs-grounded ladder in references/path-selection.md.

  • Word boosting — a bounded set of known words/names/jargon. Two realizations that are different artifacts: pilot (NeMo) to prove lift offline via GPU-PB context biasing (nemo-speech-asr-finetune), or deploy (Riva) to ship it via runtime boosted_lm_score (nemotron-speech) — different score systems, don't reuse one for the other. Runtime, no training either way. See references/path-selection.md.

  • Custom vocabulary / pronunciation — OOV or consistently mispronounced terms. Deploy-time. → Deployment sub-skill.

  • N-gram (KenLM) LM — domain phrasing/word-sequences when you have text but little audio. Two realizations, built the same way but deployed differently by architecture: pilot (NeMo, NGPU-LM) to prove lift offline (nemo-speech-asr-finetune), or deploy (Riva) to ship it (nemotron-speech). For CTC, rebuild the pilot corpus into a Riva word-level LM — don't ship the pilot artifact as-is. For RNN-T/TDT, the opposite: hand the pilot's .nemo artifact to Riva unchanged, no rebuild. See references/path-selection.md.

  • Fine-tune — real acoustic gaps (accents, noise, channel) with enough transcribed audio (NIM guide: 100+ h; ~10 h floor only if mixed to avoid catastrophic forgetting). Below ~10 h, do not recommend fine-tuning — recommend word boosting instead (severe catastrophic-forgetting/overfitting risk). → Research/Training.

  • Train from scratch / cross-language transfer — a new language with no suitable checkpoint (last resort). → Research/Training.

Ordering and per-model support follow the NVIDIA Speech NIM ASR customization guide: https://docs.nvidia.com/nim/speech/latest/asr/customization/customization.html.

Key Principles

  • Scope before you pick. Don't recommend fine-tuning before the discovery questions and a measured baseline.

  • Cheapest sufficient path. Escalate rungs only when the current one provably can't hit the target; you may experiment on a cheap rung while presenting the full fine-tuning plan.

  • Measure with a contract. Report normalized WER on the domain set plus an A/B forgetting check on a general set — never in-training logs alone.

  • Verify before you train. Run the pre-flight dataset quality check before Stage 5: verify/convert audio to 16 kHz, and, when the user asks, audit ground-truth transcripts by comparing them to a reference model's WER. Don't train on an unresampled or unaudited-on-request dataset. See references/workflow.md §4a.

  • Know your environment before you train. If no NeMo is provided, pull the latest main (or latest published container tag). If one is provided, check its version but still recommend latest main and ask the user first — a provided checkout always carries staleness risk. If they insist on keeping it, don't pull preemptively; only revisit once a concrete version issue (e.g. unsupported functionality) is actually hit. Record what was resolved in the ledger. See references/workflow.md §4b.

  • Delegate, don't reimplement. Route execution to the sub-skills; keep this skill focused on the plan, sequencing, and cost/time/data answers.

  • Real target-domain audio is the usual bottleneck. Prefer real data; use synthetic to fill measured gaps, kept separately weighted so it can be ablated.

  • Consult the user before extra tuning cycles, and when a needed sub-skill is a placeholder.

Source of Truth

TopicLocation
NIM Speech docs homehttps://docs.nvidia.com/nim/speech/latest/index.html
ASR customization guide (methods, per-model support)https://docs.nvidia.com/nim/speech/latest/asr/customization/customization.html
ASR support matrix (models & features)https://docs.nvidia.com/nim/speech/latest/reference/support-matrix/asr.html
NeMo fine-tuning (flags/config)docs/source/asr/fine_tuning.rst, and the nemo-speech-asr-finetune sub-skill
Riva ASR tutorials (boosting, LM, fine-tune)https://github.com/nvidia-riva/tutorials
Tokenizer extension to new language + acoustic fine-tunehttps://github.com/nvidia-riva/tutorials/blob/main/asr-extend-tokenizer-to-newlang-ft-acoustic-model.ipynb

Limitations

  • Orchestration only — execution happens in the sub-skills. Where a sub-skill is a placeholder, guidance is interim until it exists.

  • GPU required for the training rungs; deployment/serving is owned by the nemotron-speech sub-skill.

  • Model names, config paths, flags, and per-model feature support drift across NeMo/Riva releases — verify against the support matrix and the current checkout.

  • Public branding is "Nemotron Speech"; commands, imports, config paths, and doc URLs still use "Riva" / "NeMo" — do not rename.

Files

references/path-selection.md

Path Selection — Cheapest Sufficient Rung

Stage 3 of the workflow. Pick the lowest-cost path that can meet the target, escalate only when quality falls short, and delegate execution to the sub-skills. Always diagnose the failure mode first and measure a baseline (Evaluation sub-skill) so each step is justified.

Ordering and per-model support follow the NVIDIA Speech NIM (Riva) ASR customization guide: https://docs.nvidia.com/nim/speech/latest/asr/customization/customization.html. Verify parameters and support there.

The Ladder (cheapest → most expensive)

RungFixesNeedsCostRuns where → sub-skill
Word boosting — pilot (NeMo)Cheaply prove boosting lift offline before deployingA word list + a .nemo/pretrained checkpointMinimal, no trainingnemo-speech-asr-finetune (GPU-PB boosting_tree via speech_to_text_eval.py)
Word boosting — deploy (Riva)Known words/names/jargon/commands at servingA word listMinimal, no trainingnemotron-speech (runtime boosted_lm_score, no build)
Custom vocabulary / pronunciationOOV words, consistent mispronunciationsVocab/lexicon fileLow, deploy-timeriva-build → nemotron-speech
N-gram LM — pilot (NeMo)Cheaply prove LM lift offline before deployingDomain text + a .nemoLow, no servingnemo-speech-asr-finetune (NGPU-LM via speech_to_text_eval.py)
N-gram LM — deploy (Riva)Domain phrasing / word sequences at servingDomain text (CTC) or the pilot .nemo (RNNT)Moderate, decode-timenemotron-speech (CTC: rebuild word-level LM; RNNT: reuse pilot .nemo directly — exact flags in pipelines.md)
Fine-tuneReal acoustic gaps (accents, noise, channel)100+ h transcribed (10 h floor if mixed; <10 h → don't fine-tune, use word boosting) + GPUHighResearch/Training (nemo-speech-asr-finetune)
Train from scratch / cross-languageA new language/dialect, no checkpointThousands of h (16+ h for transfer)Very highResearch/Training (last resort)

Rungs compose: a fine-tuned model still uses boosting and an LM at serving time.

One rung, one owner, end-to-end. Route the whole lifecycle of a customization to a single sub-skill rather than splitting its build → eval → deploy across skills. This applies to word boosting too, not just the n-gram LM: each has two realizations that are different artifacts with different score systems — a NeMo pilot (owned by nemo-speech-asr-finetune) and a Riva deploy (owned by nemotron-speech). Whether the pilot artifact carries into Riva unchanged depends on architecture, not on a blanket rule — for word boosting it never does (different score systems entirely); for the n-gram LM it depends on CTC vs RNNT (see the Rung Notes — RNNT is the one case where the pilot artifact ships to Riva verbatim). Pick the realization up front from the goal (validate vs ship); do not assume portability either way without checking the Rung Note. A customer working purely on a NeMo pilot never needs to touch Riva — it is a complete, self-contained loop.

Diagnose First

  • A short, known set of specific words wrong (names, SKUs, commands, acronyms) → word boosting. Decide the realization up front: pilot (NeMo) to prove lift offline for cheap and see which phrases actually help, or deploy (Riva) to ship it — different, non-interchangeable score systems (see Rung Notes). If truly OOV or mispronounced → custom vocabulary / pronunciation.

  • Wrong word sequences / phrasing, with domain text available → n-gram LM. Decide the realization up front: pilot (NeMo) to prove lift offline for cheap, or deploy (Riva) to ship it. Whether the pilot artifact carries into Riva unchanged depends on architecture — CTC needs a rebuild, RNNT reuses it directly (see Rung Notes).

  • Model mis-hears audio (accent, noise, channel) with a real acoustic gap and ≥10 h of real transcribed target-domain audio → fine-tune. Below that floor, do not recommend fine-tuning — see the guardrail in Rung Notes below.

  • New language/dialect, no suitable checkpoint → train from scratch / cross-language transfer (rare).

  • Formatting only (punctuation, casing, numbers) → runtime automatic-punctuation / ITN flags, not accuracy work.

Rung Notes (docs-grounded)

  • Word boosting — two realizations, different score systems; NOT interchangeable. Cannot fix acoustics. Decide which realization the goal needs before building:

    • Pilot (NeMo, offline, GPU-PB context biasing) — owner nemo-speech-asr-finetune. Decode-time shallow fusion via a GPU-accelerated boosting tree — no retraining, no build step required against any .nemo/pretrained checkpoint. Supported for CTC, RNN-T/TDT, and AED (Canary). This whole pilot runs entirely inside NeMo; nothing here requires Riva. GPU-PB is the generic method — the only one of NeMo's three word-boosting mechanisms that covers plain RNN-T/TDT. CTC has two other, older trails (see the fallback bullet below); default to GPU-PB unless a specific reason points elsewhere.

      • Optional pre-build (reusable across runs): scripts/asr_context_biasing/build_gpu_boosting_tree.py asr_model_path=<.nemo> key_phrases_file=<list> save_to=<btree_path> context_score=1.0 depth_scaling=2.0 use_triton=True. Otherwise pass key_phrases_file/key_phrases_list inline at decode time.

      • CTC — via examples/asr/speech_to_text_eval.py: ctc_decoding.strategy=greedy_batch|beam_batch, keys under ctc_decoding.greedy.boosting_tree.* / .beam.boosting_tree.*, boosting_tree_alpha=<weight>.

      • RNN-T/TDT — same script: rnnt_decoding.strategy=greedy_batch|malsd_batch, keys under rnnt_decoding.greedy.boosting_tree.* / .beam.boosting_tree.*, boosting_tree_alpha=<weight>.

      • Shared knobs: context_score=1.0 recommended; depth_scaling=2.0 for CTC/RNN-T/TDT (1.0 for Canary); boosting_tree_alpha is the overall weight (0 disables); per-phrase weight via key_phrase_items_list='[{phrase:"x",alpha:2.0},...]'; bpe_mode=case_insensitive avoids manual capitalization on models that output case. Score with scripts/asr_context_biasing/compute_key_words_fscore.py --input_manifest=<decoded> --key_words_file=<list>.

      • CTC-only alternative trails (also the fallback when a checkout lacks GPU-PB — boosting_tree was added to NeMo mid-2025; verify rnnt_decoding.*.boosting_tree/ctc_decoding.*.boosting_tree exists in the target checkout first, e.g. grep boosting_tree nemo/collections/asr/parts/submodules/rnnt_decoding.py): CTC-WS (scripts/asr_context_biasing/eval_greedy_decoding_with_context_biasing.py decoder_type=ctc; for RNNT this only works via a Hybrid RNNT/CTC checkpoint's CTC head, decoder_type=rnnt) or Flashlight-based boosting (CTC lexicon-decoding only, a word<TAB>score file, ±20–100 range — this is the same convention Riva itself uses below, not GPU-PB's context_score/boosting_tree_alpha).

      • Do not reuse these parameters in Riva. context_score/depth_scaling/boosting_tree_alpha is a graph-based shallow-fusion system with its own score semantics — it does not map onto Riva's boosted_lm_score below. The NeMo pilot tells you whether boosting helps and which phrases matter; it does not give you a Riva score to reuse.

    • Deploy (Riva, runtime) — owner nemotron-speech. Parakeet CTC/RNNT/TDT and Nemotron ASR Streaming. Scores ~20–100 (CTC), 0.5–2.0 (RNNT/TDT); per-stream ~500 words (RNNT/TDT) / 5,000+ (CTC); global (deploy) 5,000+. Applied per-request via the client (RecognitionConfig/speech_contexts/boosted_lm_words), not a riva-build flag — no build step, and the deployed model doesn't need to have gone through the NeMo pilot at all. Tutorial: https://github.com/nvidia-riva/tutorials/blob/stable/asr-wordboosting.ipynb.

  • Custom vocab / pronunciation / speech hints: deploy-time riva-build, primarily Parakeet CTC.

  • N-gram (KenLM) LM — two realizations; Riva carry-over differs by architecture, not a blanket rule. Text-only; can't add acoustic capability. Decide which realization the goal needs before building:

    • Pilot (NeMo, offline, NGPU-LM) — owner nemo-speech-asr-finetune. GPU-accelerated shallow fusion at decode time, no retraining. This whole pilot runs entirely inside NeMo; nothing here requires Riva.

      • Build (same script, both architectures): scripts/asr_language_modeling/ngram_lm/train_kenlm.py nemo_model_file=<.nemo> train_paths=<text/manifests> kenlm_bin_path=<kenlm/bin> kenlm_model_file=<out> ngram_length=6 save_nemo=True (6 recommended for BPE models; save_nemo=True emits the .nemo-format artifact — this exact file is what Riva reuses directly for RNNT, see Deploy below).

      • CTC — via examples/asr/speech_to_text_eval.py: ctc_decoding.greedy.ngram_lm_model=<.nemo/.ARPA> ctc_decoding.greedy.ngram_lm_alpha=<weight> ctc_decoding.strategy=greedy_batch (greedy), or .beam.ngram_lm_model=... + beam_size=... + strategy=beam_batch (beam; final_score = acoustic + alpha*lm_score + beam_beta*seq_length). For a beam-width/alpha/beta grid search instead of one run, eval_beamsearch_ngram_ctc.py is the tool for that specific job — CTC-only.

      • RNN-T/TDT — same script: rnnt_decoding.greedy.ngram_lm_model=... rnnt_decoding.greedy.ngram_lm_alpha=... rnnt_decoding.strategy=greedy_batch (greedy), or .beam.ngram_lm_model=... + beam_size=... + strategy=malsd_batch (beam; pruning_mode=late + blank_lm_score_mode=lm_weighted_full recommended; final_score = acoustic + alpha*lm_score, normalized by sequence length). No RNNT equivalent of eval_beamsearch_ngram_ctc.py exists — speech_to_text_eval.py covers both greedy and beam directly.

      • CTC-only alternative: NeMo's own Flashlight decoder — a second, older NeMo-side mechanism, distinct from NGPU-LM and not GPU-accelerated the same way. Set decoding_cfg.strategy="flashlight", decoding_cfg.beam.kenlm_path=<word-level .bin from lmplz>, decoding_cfg.beam.flashlight_cfg.lexicon_path=<lexicon> (built with scripts/asr_language_modeling/ngram_lm/create_lexicon_from_arpa.py), tune beam_alpha/beam_beta/ beam_size. This is the same Flashlight integration word boosting's CTC fallback uses (flashlight_cfg.boost_path) — the two can be combined in one beam search. Confirmed no RNNT path exists for this mechanism (zero Flashlight references anywhere in NeMo's RNNT/transducer decoding modules).

      • Tutorials (source of truth — neither sub-skill documents this): CTC https://github.com/nvidia-riva/tutorials/blob/stable/asr-python-advanced-nemo-ngram-training-and-finetuning.ipynb — NeMo-only end to end, uses the Flashlight path above, no Riva deploy step in it at all. RNN-T (NGPU-LM) https://github.com/nvidia-riva/tutorials/blob/main/asr-train-and-deploy-NGPU-LM-for-parakeet-rnnt.ipynb — covers both the NeMo pilot above and the Riva deploy step below, verified by reading its actual commands.

    • Deploy (Riva, decode-time) — owner nemotron-speech; exact riva-build flags and LM file formats are documented there (references/pipelines.md's Language Models section) — do not duplicate them here. What matters at this layer is whether the NeMo pilot artifact carries over, and that differs by architecture:

      • CTC — the NGPU-LM pilot artifact definitely needs a rebuild; the NeMo-Flashlight pilot's artifacts are an open question, not a confirmed rebuild. The NGPU-LM pilot's .nemo/.ARPA is subword-tokenized — a certain mismatch with Riva's word-level Flashlight decoder, so that one always needs a fresh word-level LM built for Riva from the domain corpus. Whether the NeMo-Flashlight pilot's own word-level KenLM + .lexicon (from create_lexicon_from_arpa.py) can be handed to nemotron-speech as-is is unverified — checked against both nemotron-speech's own docs and the live NVIDIA docs, neither was specific enough to confirm either way. Test directly before assuming a rebuild is needed.

      • RNN-T/TDT — no rebuild; reuse the pilot artifact directly. Verified against NVIDIA's own RNNT tutorial by reading its actual riva-build command: the exact .nemo NGPU-LM artifact the pilot produced (train_kenlm.py's save_nemo=True output) is handed to nemotron-speech unmodified. RNNT uses a genuinely different Riva decoder path from CTC — it never goes through Flashlight either.

      • Deploy-side prerequisites (version-matched nemo2riva, riva-build CLI differences across NIM images) are owned by nemotron-speech — see sub-skills.md.

  • Fine-tune: for genuine acoustic gaps. NIM guide: 100+ h recommended; ~10 h floor only if mixed with a larger dataset to avoid catastrophic forgetting. Lossless audio, ≥16 kHz, noise augmentation. Supported: Parakeet CTC/RNNT/TDT and Nemotron ASR Streaming. Verify/convert sample rate and, on request, audit transcript quality via the pre-flight dataset quality check (workflow.md §4a) before training.

  • Below the 10 h floor — do not recommend fine-tuning. Under ~10 hours of real transcribed target-domain audio, the risk is severe on two independent axes: catastrophic forgetting (general capability degrades) and overfitting (the model memorizes the tiny training set rather than generalizing, even within the target domain) — mixing with a larger dataset no longer offsets this the way it does at the 10 h floor. Recommend word boosting instead (the rung above — runtime, no training, needs only a word list). Only revisit fine-tuning once real transcribed target-domain audio actually reaches the ~10 h floor, or the user explicitly accepts the risk after being told it.

  • Train from scratch / cross-language: 5,000+ h from scratch; ~16+ h with cross-language transfer. Prefer fine-tuning a multilingual checkpoint first.

  • Tokenizer extension to a new language: when the target language requires new tokens (new script, phonemes, or characters not covered by the base tokenizer), extend the tokenizer before fine-tuning the acoustic model. Source of truth: https://github.com/nvidia-riva/tutorials/blob/main/asr-extend-tokenizer-to-newlang-ft-acoustic-model.ipynb.

Escalation Rule

Start at the lowest matching rung, measure, and escalate only if the target is missed. It is fine to run a cheap-rung experiment (boosting / LM) immediately while presenting the full fine-tuning plan and its cost — see planning-answers.md. Change one lever per iteration.

Requirements and compatibility

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Needs: Needs Python

Security

What our scanner noticed· Medium risk

  • Large base64-encoded blobs
  • Scripts that your agent may run

This skill includes scripts that your agent may run. Read them before you use it.

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Created by
Nemotron Speech Team
Publisher
NVIDIA (Official)
Distributed by
NVIDIA
Source
NVIDIA/skills · skills/nemotron-asr-finetune · commit fce3cca
Licence
Apache License 2.0 (redistribution allowed)
  • LICENSE (added by AutoGineer from LICENSE-APACHE)
  • ATTRIBUTION.md (written by AutoGineer)
Synced

AutoGineer is not affiliated with or endorsed by Nemotron Speech Team or NVIDIA.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download nemotron-asr-finetune.zip