NCP-GENL Production Monitoring and Reliability Practice Test 1 — 15 Questions

Question 1

Which THREE practices are recommended for ensuring high availability in a multi-GPU LLM inference environment?

Accepted Answer

Implement liveness and readiness probes. High availability requires removing single points of failure and ensuring efficient load distribution. Using health probes allows the load balancer to remove unhealthy nodes, while model replication across GPUs provides redundancy. Finally, using a container orchestrator like Kubernetes with proper resource limits ensures that individual node failures do not cascade, maintaining uptime. These practices are critical for production reliability when serving high-traffic, latency-sensitive generative AI models.

Answer

Run all models on a single GPU

Answer

Disable monitoring to reduce latency

Question 2

An enterprise deployment serving an LLM on NVIDIA Triton Inference Server experiences sudden latency spikes during peak traffic hours. The ML platform engineer needs to monitor GPU utilization and memory bandwidth bottlenecks in real-time without introducing significant overhead. Which tool and metric combination should the engineer configure?

Accepted Answer

Deploy NVIDIA DCGM-Exporter alongside Triton Inference Server to scrape real-time GPU telemetry, feeding metrics directly into a Prometheus and Grafana monitoring stack.. NVIDIA Data Center GPU Manager integrates natively with Triton Inference Server and Prometheus to scrape hardware-level metrics like SM active and memory bandwidth utilization. This approach ensures low-overhead, highly granular telemetry collection essential for diagnosing production bottlenecks without impacting active inference workloads running on the TensorRT-Core engines.

Answer

Attach NVIDIA Nsight Systems to every active Triton worker process to continuously stream kernel execution timelines directly to the central logging dashboard.

Answer

Configure standard CPU-based system monitoring utilities like top and vmstat to indirectly infer GPU memory bottlenecks through host process memory allocations.

Answer

Enable verbose Python garbage collection logging within the Triton model repository configuration file to track tensor allocations across device memory pools.

Question 3

A generative AI application uses NVIDIA Triton Inference Server with multiple models. The operations team wants to set up alerting for model inference failures. They need to distinguish between client-side errors (e.g., malformed input) and server-side errors (e.g., model execution failures). Which Triton metric should they monitor to specifically track server-side inference errors?

Accepted Answer

nv_inference_request_failure with error type label. To distinguish server-side inference errors from client-side errors, the team should monitor the nv_inference_request_failure metric and filter by the error type label. Triton exposes failure reasons such as 'input' for client errors and 'execute' for server-side execution failures. This granularity enables targeted alerting on server-side issues, which are critical for model reliability.

Answer

nv_inference_exec_count

Answer

nv_inference_request_success

Answer

nv_inference_request_failure

Question 4

A production LLM inference service on NVIDIA Triton Inference Server uses dynamic batching. During peak hours, the P99 latency of the service increases significantly, but GPU compute utilization remains around 40-50%. DCGM metrics show high GPU memory utilization and moderate memory bandwidth utilization. Which is the most likely cause of the elevated P99 latency?

Accepted Answer

High GPU memory utilization causing memory thrashing and increased latency due to insufficient memory for optimal batching. High GPU memory utilization with moderate compute utilization indicates that the GPU is memory-bound, likely due to large model size or inefficient memory management. This can force Triton to reduce batch sizes dynamically, increasing per-request latency and causing high P99. Addressing memory usage through techniques like quantization or model optimization is key to improving latency.

Answer

Network latency between clients and the Triton server causing increased response times

Answer

Insufficient CPU resources for pre-processing and post-processing steps, causing a bottleneck

Answer

Inefficient batching due to small batch sizes, leading to underutilization of GPU compute units

Question 5

A company has deployed an LLM for customer support on NVIDIA Triton Inference Server. They want to ensure high availability and automatic recovery from failures. Which feature of Triton should they configure to automatically restart failed model instances?

Accepted Answer

Model instance health checks with automatic restart. To automatically restart failed model instances, the team should configure Triton's model instance health checks with automatic restart. Triton monitors instance health and can restart instances that become unresponsive or crash. This provides resilience and high availability for production LLM services. Other features like versioning or instance groups do not offer automatic recovery.

Answer

Instance groups

Answer

Model versioning

Answer

Model warmup

Question 6

A production LLM inference service runs on NVIDIA Triton Inference Server with multiple models. The operations team observes that end-to-end latency for a specific model has increased by 40% over the past week, while GPU utilization remains steady at 65%. Which Triton metric should be analyzed first to identify whether the latency increase originates from the inference server's internal processing?

Accepted Answer

nv_inference_compute_infer_duration_us. The metric nv_inference_compute_infer_duration_us specifically measures the time Triton spends executing the model's inference, which is the core processing step. Since GPU utilization is unchanged, the latency increase likely comes from longer inference computations, perhaps due to larger inputs or suboptimal batching. This metric directly isolates internal processing time, enabling the team to confirm if the server's inference logic is the source.

Answer

nv_inference_pending_request_count

Answer

nv_gpu_utilization

Answer

nv_inference_request_duration_us

Question 7

A production LLM deployment on NVIDIA Triton Inference Server is experiencing occasional out-of-memory (OOM) errors on the GPU. Which TWO actions should be taken to mitigate this issue? (Choose two.)

Accepted Answer

Reduce the maximum batch size in the model configuration. Reducing the maximum batch size and using lower precision (FP16) both decrease GPU memory consumption. Smaller batches require less memory for activations, and FP16 halves the memory needed for weights and activations compared to FP32. These actions directly address the root cause of OOM errors, whereas increasing batch size or instances would worsen the problem.

Answer

Enable model instances to share the GPU

Answer

Enable dynamic batching with a larger maximum batch size

Answer

Increase the batch timeout to allow more requests to accumulate

Question 8

A production LLM inference service on NVIDIA Triton Inference Server is monitored using NVIDIA DCGM. The team observes that GPU memory utilization is consistently above 90%, but GPU compute utilization is low. Which action is most appropriate to improve performance?

Accepted Answer

Reduce the model's memory footprint by using quantization or a smaller model. When GPU memory utilization is high but compute utilization is low, the workload is memory-bound. Reducing the memory footprint via quantization or a smaller model decreases memory pressure and can improve performance by allowing more efficient memory access. Other options either increase memory usage or do not address the root cause.

Answer

Increase the number of model instances to utilize more GPU compute

Answer

Enable dynamic batching to increase batch size and improve compute utilization

Answer

Switch to a GPU with more memory bandwidth

Question 9

An LLM application deployed on NVIDIA Triton Inference Server is experiencing intermittent latency spikes. Which metric is most critical to monitor to determine if the issue stems from GPU compute saturation?

Accepted Answer

SM (Streaming Multiprocessor) occupancy. Monitoring GPU utilization alone is insufficient because it does not distinguish between compute saturation and memory bandwidth bottlenecks. NVML-based metrics specifically tracking SM (Streaming Multiprocessor) occupancy provide the granular insight required to identify whether the execution cores are fully utilized. This metric is essential for capacity planning and ensuring that the inference throughput meets strict service level agreements under high concurrent request loads in production environments.

Answer

Total system CPU usage

Answer

Network interface throughput

Answer

Total GPU memory capacity

Question 10

Refer to the exhibit. The inference server reports an OOM error while running multiple LLMs. What configuration change most effectively improves reliability without upgrading the hardware?

Accepted Answer

Implement KV cache block paging. The exhibit shows that the VRAM is almost completely exhausted, likely due to excessive KV cache allocation for concurrent models. Implementing PagedAttention or optimizing the KV cache block size allows for more efficient memory management. This approach improves reliability by preventing memory fragmentation and allowing the system to handle higher request concurrency within existing hardware constraints, which is vital for production systems requiring high uptime and predictable performance.

Answer

Increase the batch size

Answer

Enable FP32 precision mode

Answer

Increase the number of threads

Question 11

Which TWO of the following telemetry types are essential for detecting 'model drift' in a production LLM deployment?

Accepted Answer

Output token distribution statistics. Model drift refers to the degradation of model output quality over time as real-world data deviates from training distributions. Tracking output tokens and response semantic consistency allows engineers to identify when the model starts producing incoherent or irrelevant results. Proactive monitoring of these metrics is critical because drift often occurs silently, potentially damaging user trust before traditional error logs or system performance metrics indicate a failure.

Answer

GPU power consumption levels

Answer

Hardware temperature monitoring

Answer

Network latency between nodes

Question 12

In the context of NVIDIA AI Enterprise, what is the primary purpose of using 'NVIDIA Triton Model Analyzer'?

Accepted Answer

To automate performance optimization and configuration. The Model Analyzer is a critical tool for determining the optimal configuration for models deployed on Triton Inference Server. By automating the testing of various batch sizes and concurrency levels, it ensures that models are tuned for maximum throughput and minimum latency. This tuning is essential for maintaining reliability and cost-efficiency in large-scale production, preventing performance degradation caused by suboptimal configuration settings that often go unnoticed in manual deployments.

Answer

To perform real-time model training

Answer

To detect GPU hardware failures

Answer

To encrypt model weights at rest

Question 13

Refer to the exhibit. Why did the system fail to trigger an alert despite high latency?

Accepted Answer

The alert is suppressed by a duration requirement. Alerting systems often require sustained violation of thresholds to avoid 'flapping' or false positives. The exhibit shows the current latency is 850ms, which exceeds the threshold, but the alerting logic likely requires consecutive samples or a window-based average to trigger. This is a common reliability feature in monitoring stacks to ensure that transient spikes do not disrupt operational teams with unnecessary alerts during non-critical fluctuations.

Answer

The error rate threshold was too low

Answer

The Prometheus backend is down

Answer

The logging level is set too high

Question 14

When auditing an NVIDIA Triton deployment for security, which action is most critical to protect sensitive inference data?

Accepted Answer

Enabling TLS for client-server communication. Securing the communication channel is the first line of defense in protecting sensitive user input data sent to an LLM. Utilizing TLS/SSL encryption prevents man-in-the-middle attacks where data could be intercepted during transit. In professional production environments, this is a standard requirement for compliance and data privacy, ensuring that prompt data and generated completions remain confidential between the client and the inference server.

Answer

Disabling the GPU logging

Answer

Increasing the memory buffer

Answer

Switching to an unsecured port

Question 15

What is the primary benefit of using NVIDIA DCGM (Data Center GPU Manager) for monitoring production LLMs?

Accepted Answer

To detect hardware-level issues. DCGM provides hardware-level telemetry that is essential for proactive maintenance and reliability. Unlike higher-level metrics that only show software performance, DCGM can identify physical issues such as ECC memory errors, thermal throttling, or failing power supplies. This level of visibility is crucial for anticipating hardware failure before it results in a service outage, allowing operations teams to migrate workloads gracefully and maintain high system reliability.

Answer

To train LLMs faster

Answer

To optimize model weights

Answer

To generate natural language output