NVIDIA NCA-GENM common mistakes
NVIDIA NCA-GENM · Understand the traps and how to avoid them.
Treating 'generative model' questions as purely about transformer architecture and answering with next-token prediction mechanics even when the stem describes a diffusion or GAN-style training objective, then forcing a tokenizer explanation into the answer.
Most candidates prepare from LLM-centric material, so the default mental frame is autoregressive language modelling; the exam intentionally spans diffusion, VAEs, and adversarial training, and an auto-pilot answer drifts off the actual objective being tested.
What to do instead
Before answering, identify the training objective named or implied (denoising score matching, variational lower bound, minimax adversarial loss, autoregressive likelihood) and select the answer that is correct for that objective. Build a one-page comparison table of objectives, sampling procedure, and typical failure symptom for each family, and re-derive it from scratch weekly.
Reading an evaluation metric as an absolute quality verdict - for example answering that a model with lower FID, perplexity, or loss is definitively better for the deployment described, ignoring the distribution, sample size, or downstream task mismatch.
Metrics are taught as leaderboard numbers, so candidates map 'lower is better' directly onto 'better model' without checking what the metric actually measures or whether the comparison is valid across different sample counts and preprocessing.
What to do instead
Always attach the measurement conditions to the metric: number of samples, resolution, prompt set, and whether the compared models share preprocessing. Practice stating what each metric does not capture (FID ignores text alignment; perplexity ignores factuality; BLEU ignores semantic equivalence) and pick answers that cite the limitation rather than the ranking.
Designing or critiquing an experiment without a held-out baseline or with the test set touched during model selection, then choosing the answer that reports the best observed configuration as the recommendation.
Candidates optimize for the numerically best result in the scenario and forget that comparing many configurations against one split produces selection bias; the exam rewards the answer that names the leakage or missing control, not the one that reports the highest score.
What to do instead
Run a checklist on every experimentation stem: is there a baseline, is there a fixed split, how many configurations were compared against that split, and is the reported improvement larger than run-to-run variance? When a stem shows many trials against one validation set, answer with nested cross-validation or a fresh holdout rather than the top score.
Treating a multimodal pipeline as independent unimodal stages - describing image encoding and text encoding separately and never specifying how the representations are aligned, fused, or how one modality conditions the other.
Study material is usually organized by modality, so the joint interface is the least rehearsed part; the exam probes exactly that interface through questions about contrastive alignment, cross-attention, projection layers, and token budgeting.
What to do instead
For every multimodal scenario, explicitly write the fusion point and mechanism: early fusion by concatenation, late fusion by score combination, or cross-attention at named layers, plus the contrastive or captioning objective that trains the alignment. Practice sketching the tensor shapes flowing from each encoder into the fusion module so the interface, not the encoder, is what you reason about.
Answering a throughput or latency question with a generic 'use a bigger GPU' or 'enable mixed precision' instead of diagnosing the actual bottleneck - memory-bandwidth bound decoding, KV-cache growth, dataloader starvation, or kernel launch overhead.
Optimization advice is often memorized as a list of flags, so candidates apply the list without profiling; the exam presents a profile snapshot or a described symptom and expects the candidate to map symptom to bottleneck.
What to do instead
Memorize a symptom-to-bottleneck table: flat GPU utilization with high CPU wait means input pipeline starvation; low arithmetic intensity during autoregressive decode means bandwidth bound; memory climbing linearly with sequence length means KV cache. Answer with the intervention that targets the named bottleneck, and state the measurement you would take to confirm it before changing configuration.
Writing or evaluating code that assumes tensors are on the same device, that batch dimensions broadcast silently, or that the input dtype matches the model, and then selecting the option that looks algorithmically correct but would raise a runtime error.
Candidates reason about the algorithm on paper and skip mental execution; exam code snippets are short enough that device placement, dtype promotion, and shape broadcasting are the actual discriminator between options.
What to do instead
Trace every snippet line by line and annotate shape, dtype, and device at each step before looking at the options. Practice with short examples involving CPU-to-GPU movement, autocast regions, and non-contiguous transposes so the runtime failure, not the pseudocode logic, becomes the first thing you notice.
Handling a safety or bias question by proposing a single mitigation - a content filter, a refusal prompt, or a fairness metric - and declaring the system trustworthy, rather than layering controls and naming residual risk.
Guardrail tooling is easy to name, so candidates treat one control as sufficient; the exam tests whether the candidate understands that filters fail on adversarial and out-of-distribution input and that evaluation, monitoring, and documentation are separate controls.
What to do instead
Answer trustworthy-AI stems with a layered structure: data provenance and curation, training-time mitigation, inference-time filtering or refusal, red-team evaluation with reported failure rates, and ongoing monitoring with escalation. Explicitly state what the layers do not cover, because options that acknowledge residual risk and require measurement usually beat options that claim elimination.
Confusing fine-tuning, parameter-efficient adaptation, and retrieval augmentation when the stem describes a scenario with a fixed small dataset, frequent knowledge updates, or strict latency and cost budgets, and choosing full fine-tuning by default.
Fine-tuning is the most familiar adaptation path, so it becomes the reflexive answer; the exam separates the methods by data volume, update cadence, and whether the problem is behavioural versus factual.
What to do instead
Map the scenario to the constraint first: changing facts that update often points to retrieval; changing style or task behaviour with limited labelled data points to parameter-efficient tuning; large in-domain corpora and available compute justify fuller adaptation. State the cost and staleness implication of the chosen method so the trade-off, not just the technique name, drives the answer.
Reporting a single aggregate metric for a dataset with clearly skewed subgroups, or comparing model variants on pooled results, when the scenario provides per-group breakdowns.
Aggregate accuracy is the habit formed by benchmark culture; the exam supplies subgroup tables precisely to see whether the candidate notices that a pooled improvement can hide a regression in a smaller, high-stakes group.
What to do instead
When a stem includes a breakdown, compute or compare at the group level and lead with the group where performance is worst or where the variant regresses. Reject answers that justify a pooled win without addressing the subgroup, and recommend stratified reporting plus a decision threshold set per group when the cost of errors differs.
Ignoring the evaluation harness when interpreting a generative result - comparing two models on samples generated with different decoding settings, prompts, or seeds and concluding one model is superior.
Candidates focus on the model as the only variable and overlook that temperature, top-p, guidance scale, prompt template, and seed all shift output quality and diversity metrics substantially.
What to do instead
Audit every comparison for controlled variables: fixed decoding parameters, identical prompt sets, matched sample counts, and multiple seeds with variance reported. If the stem varies sampling settings, answer that the comparison is confounded and specify the controlled rerun needed before any quality claim is made.