NVIDIA SDKs for Generative AI: NeMo, Riva, Triton, ACE, cuDNN, and AI Blueprints/VIA

Identity statement: each of these six NVIDIA names owns exactly one layer of a generative pipeline, and none of them substitute for each other — a model that is built is not thereby served, and a model that is served is not thereby optimized.

[GROUND TRUTH] (Sources/nca-genm/domain-6-software-development.md) gives this mapping directly:

Read this table as the primary artifact of the lesson: everything below exists to sharpen individual rows, not to introduce a seventh idea.

The single most named confusion in this domain pits three tools against each other, and M5-06 (Performance Optimization) already covers the TensorRT/Triton half of this pair in depth — this lesson adds NeMo to complete the trio rather than re-deriving what optimization or serving mean.

The fix for all three rows is the same discipline: name the stage of the pipeline a scenario is describing (building, optimizing, or serving) and match it to the one tool that owns that stage. A scenario that describes fine-tuning a generative model is a NeMo scenario; one describing fusing operations and calibrating precision is a TensorRT scenario; one describing handling concurrent requests with dynamic batching is a Triton scenario. None of the three is "the inference tool" in a way that subsumes the others.

⭐ THE EARNED INSIGHT All three tools can sit in the same pipeline, back to back, and that is exactly what makes the trap durable: seeing "NeMo" and "Triton" in the same sentence about the same model tempts you to treat them as redundant or interchangeable, when the whole point is that a single model passes through all three roles in sequence — built once, optimized once, served continuously — and no later stage folds the earlier one's job into itself.

Riva is the speech-specific SDK — automatic speech recognition (ASR) transcribing audio to text, text-to-speech (TTS) synthesizing audio from text, and neural machine translation (NMT), all GPU-accelerated for conversational AI. M3-07, elsewhere in this course, covers the fixed ASR → NLP/LLM → TTS pipeline order Riva participates in for a conversational system. This lesson's addition is ACE: [GROUND TRUTH] (Sources/nca-genm/domain-6-software-development.md) states that ACE combines four specific models into an end-to-end digital avatar — Riva ASR (speech-to-text), Riva TTS (speech synthesis), Audio2Face (A2F) (facial animation/lip sync), and a NeMo LLM (understanding input and generating responses).

The order those four pieces run in mirrors the conversational pipeline this course already established, with one addition: audio in (Riva ASR) → understand and respond (NeMo LLM) → speak the response (Riva TTS) → animate a face saying it (Audio2Face). ACE is therefore best understood as an orchestration layer, not a fifth model competing with the other four — it is the assembly of Riva's two speech directions, a NeMo-built language model, and Audio2Face's animation, chained into one avatar-facing product. The exam-relevant trap here is naming the wrong set of four components, or omitting Audio2Face specifically, since "digital avatar" as a phrase can tempt a guess toward a generic list of AI buzzwords rather than the four named pieces.

Notice what ACE is not doing at any of its four steps: it is not training a new model, and it is not itself an inference server. Every one of ACE's four components was built or served by one of the other five tools this lesson names — the NeMo LLM was built by NeMo, Riva ASR/TTS are Riva's own components by definition, and Audio2Face is a separate NVIDIA model performing one specific job (turning audio into facial animation). ACE's own contribution is the orchestration connecting all four in the right order with the right handoffs, which is precisely why it belongs in the "job" column of section 1's table as "builds an avatar," not "trains" or "serves" anything new by itself.

A distractor worth naming directly: a question may ask which single SDK "runs" a live ACE avatar in production, inviting a one-tool answer. There is no single correct one-tool answer, because ACE's four components still need serving individually once built — the NeMo LLM piece is served the same way any NeMo-built model is served (via Triton or NIM), and Riva's ASR/TTS models run on Riva's own runtime. "ACE" names the assembled product and the orchestration connecting its parts, not a fifth serving engine sitting alongside Triton; asking which tool serves an ACE avatar is really asking about the serving layer underneath each of its four components separately, not about ACE itself.

cuDNN is worth its own short section because it is the row in section 1's table most likely to be mistaken for something it is not. [GROUND TRUTH] (Sources/nca-genm/domain-6-software-development.md) names cuDNN as "the CUDA Deep Neural Network library — GPU-accelerated primitives (convolutions, pooling) under frameworks," and flags directly that a common exam trap is "thinking cuDNN is a model or a server." cuDNN sits underneath PyTorch and TensorFlow, providing the optimized low-level operations — convolutions, pooling, and similar primitives — that those frameworks call into when they run on an NVIDIA GPU. You do not train a model "with cuDNN" the way you would with NeMo, and you do not serve a model "on cuDNN" the way you would on Triton; cuDNN is invisible infrastructure a framework depends on, not a tool you interact with directly at either the training or serving layer.

[VENDOR SPEC] (Sources/nvidia-genai-multimodal-associate-study-guide.md) lists NVIDIA AI Blueprints as reference applications for AI workflows and VIA (Visual Insights Agent) as the tool for customizing those Blueprints. The relationship is template-and-customizer: a Blueprint is a starting-point reference workflow for a category of AI application, and VIA is what a team uses to adapt that reference workflow to its own specific use case rather than building from a blank slate. This is a recognition-depth pairing on the exam — know that Blueprints are the templates and VIA is the customization layer, not the reverse, and do not expect to derive what any specific Blueprint's internals look like.

Placed alongside the other five tools in this lesson, Blueprints and VIA occupy a different layer than any of them: they are not a build tool competing with NeMo, not a serving tool competing with Triton, and not a speech tool competing with Riva. A Blueprint is closer to a starting point that could itself be assembled from several of the other five tools — a reference video-analytics workflow, say, might already wire together a vision model, a serving layer, and a monitoring dashboard — and VIA's job is adapting that assembled starting point to a specific deployment's cameras, categories, or thresholds, rather than building any one piece of it from scratch. [GROUND TRUTH] (Sources/nca-genm/domain-6-software-development.md)'s own recommended-training material names "customize NVIDIA AI Blueprints with VIA" as a distinct skill from anything the other five SDKs in this lesson teach, which is the signal that this pairing is tested as its own recognizable fact rather than folded into the build/optimize/serve trio.

Treat the following as a constructed scenario, illustrative rather than a description of a specific deployed system, built to make the routing decision concrete.

A team is building a customer-support avatar that:
  1. Listens to a spoken customer question
  2. Transcribes it to text
  3. Generates a response using a fine-tuned LLM
  4. Speaks the response back
  5. Animates a lip-synced face while speaking
  6. Needs to handle many simultaneous customer sessions in production

Routing:
  Step 2 (transcribe speech to text)        -> Riva ASR
  Step 3 (generate a response)              -> a NeMo-built/fine-tuned LLM
  Step 4 (speak the response)               -> Riva TTS
  Step 5 (animate a lip-synced face)         -> Audio2Face (A2F)
  Steps 2-5 assembled end to end             -> NVIDIA ACE
  Step 6 (serve at scale, many sessions)     -> Triton Inference Server
  (Optimizing the LLM before serving it)     -> TensorRT
  (Underneath all of the above, on GPU)      -> cuDNN, invisibly

Every step in the scenario maps to exactly one tool, and no tool in the list does more than one step's job. This is the practical test of whether the six-way mapping in section 1 has actually been internalized: given a described system, can each piece of it be routed to its one correct owner without any tool being asked to do a job that belongs to a different one.

Software Development is 15% of the NCA-GENM exam, and its own framing names Riva, NeMo, Triton, and ACE explicitly as the SDKs a candidate is expected to recognize, alongside cuDNN and AI Blueprints/VIA from the suggested-readings and key-technologies lists. [GROUND TRUTH] (Sources/nca-genm/domain-6-software-development.md) frames the whole domain's scope as foundational: understand the SDK roles and how they fit together, not ship a production service built on all of them. This lesson's six-way mapping is close to a direct restatement of that scope, because the scope itself is narrow and the exam tests it as recognition rather than derivation.

The question tends to arrive in a small number of recognizable shapes: naming which SDK does which job from a one-line description; identifying the four components ACE assembles; distinguishing cuDNN's infrastructure role from a model or server; and — the most frequent — distinguishing NeMo (build), TensorRT (optimize), and Triton (serve) from a scenario describing one specific stage of a pipeline. The reliable distractor pattern across all of these is a real capability from one tool, offered as though it belonged to a different one — NeMo described as serving, Triton described as optimizing, cuDNN described as a trainable model.

Triton Inference Server. It serves models across multiple frameworks — TensorRT, PyTorch, TensorFlow, ONNX — with dynamic batching, concurrency handling, versioning, and metrics, and it does this after a model has already been built (NeMo) and, typically, optimized (TensorRT). Neither NeMo nor TensorRT performs this serving role; NeMo's output is a trained model file, and TensorRT's output is an optimized version of that model, but getting either of those to actually answer live inference requests at scale is specifically Triton's job.

Not in the way NeMo or Triton are used directly — cuDNN sits one layer further down, underneath the framework a developer actually interacts with. A team building or serving a generative model writes code against PyTorch, TensorFlow, NeMo, or Triton; those tools, in turn, call into cuDNN for GPU-accelerated low-level operations like convolutions and pooling, entirely inside their own implementation. [GROUND TRUTH] (Sources/nca-genm/domain-6-software-development.md) names exactly this distinction as a standing trap: mistaking cuDNN for a model or a server, when it is neither — it is infrastructure a framework depends on, invisible to the developer working one layer above it.

1. Which SDK is responsible for fine-tuning a generative model before it is deployed?
   • A. Triton.
   • B. NeMo.
   • C. cuDNN.
   • D. VIA.
2. What four components does NVIDIA ACE combine into a digital avatar?
   • A. NeMo, Triton, TensorRT, and cuDNN.
   • B. Riva ASR, Riva TTS, Audio2Face, and a NeMo LLM.
   • C. CLIP, a diffusion U-Net, a GAN, and a VAE.
   • D. AI Blueprints, VIA, ONNX, and PyTorch.
3. A team says "we deploy our model on cuDNN." What is wrong with this statement?
   • A. Nothing — cuDNN is a valid deployment target.
   • B. cuDNN is a low-level primitives library used underneath frameworks, not something a model is deployed "on" directly.
   • C. cuDNN should be replaced with the word "Triton" for the statement to make sense.
   • D. cuDNN only works with TensorFlow, not PyTorch.
4. What is the relationship between AI Blueprints and VIA?
   • A. VIA is a reference workflow and Blueprints customize it.
   • B. They are unrelated tools with no connection.
   • C. AI Blueprints are reference workflow templates, and VIA is the tool used to customize them.
   • D. Blueprints replace the need for VIA entirely.

Answers

1. B. NeMo is the framework for building, training, and fine-tuning LLMs and generative models — Triton serves, cuDNN is infrastructure, and VIA customizes Blueprints, none of which fine-tune a model.
2. B. ACE specifically combines Riva ASR, Riva TTS, Audio2Face, and a NeMo LLM — not a generic list of AI buzzwords, and not the optimization/serving tools from section 2's trio.
3. B. cuDNN sits underneath frameworks as a GPU primitives library; a model is deployed on Triton (serving) after being optimized (TensorRT), never "on cuDNN" directly.
4. C. AI Blueprints are the reference workflow templates; VIA is the customization layer applied on top of them — reversing the two is the named trap.

• Six names, six jobs, no overlap: NeMo builds, Riva handles speech, Triton serves, ACE assembles an avatar, cuDNN is low-level infrastructure, and AI Blueprints/VIA are templates plus their customization tool.
• NeMo, TensorRT, and Triton form the domain's standing trap: build, optimize, and serve are three separate pipeline stages, each with its own tool, and no one tool does another's job.
• ACE combines exactly four named models — Riva ASR, Riva TTS, Audio2Face, and a NeMo LLM — into an end-to-end digital avatar, in that functional order.
• cuDNN is never a model or a server — it is a GPU primitives library frameworks call into, and this is the domain's explicitly named trap for this specific tool.
• AI Blueprints are reference templates; VIA customizes them — not the reverse.

Short-length note: this lesson is written at its honest, natural length for a 50-minute, recognition-depth objective — six named tools mapped to six named jobs, with the one standing three-way trap (NeMo/TensorRT/Triton) and the one named single-tool trap (cuDNN) worked through concretely. Padding this content to the module's 4,800-word target would mean inventing SDK internals, version histories, or deployment procedures the source material does not assert and the exam's own scope note explicitly excludes ("you are not expected to ship production services").

This module now turns from naming the surrounding tools to the discipline of using them well — and of getting the generative output itself right. Next: M6-05 covers prompt engineering for generative systems alongside the software-quality practices (version control, reproducibility, input/output validation) that keep a pipeline built on this SDK stack maintainable once it is running.