Performance Optimization

An inference platform packs many small models onto A100 40GB cards and partitions each card with Multi-Instance GPU into seven 1g.5gb instances under the device plugin's mixed MIG strategy. A team wants each of their lightweight model pods scheduled onto exactly one of these smallest slices. Which container resource request correctly targets a single 1g.5gb MIG instance?

• ASet nvidia.com/mig-1g.5gb to 1 in the container resource limits, because the device plugin advertises each MIG profile as its own fully qualified extended resource name.check_circle Correct
• BSet nvidia.com/gpu to 1 and add a node selector for the mixed MIG strategy, because the standard GPU resource name resolves to the smallest free slice when MIG is enabled.
• CSet nvidia.com/mig to 1 and label the pod with the profile 1g.5gb, because the device plugin reads the profile label to select the slice size at bind time.
• DSet the container memory limit to 5Gi alongside a request for nvidia.com/gpu, because the device plugin maps the requested GPU memory limit onto the matching MIG instance size.

Why A is correct: Correct: under the mixed MIG strategy the device plugin exposes each profile as a distinct resource such as nvidia.com/mig-1g.5gb, so requesting one unit of that exact resource name binds the pod to a single slice of that size.

Why B is wrong: Tempting because nvidia.com/gpu is the familiar GPU request, but under the mixed MIG strategy whole-GPU and slice resources are advertised under distinct names, so requesting nvidia.com/gpu does not target a specific MIG profile and will not match the 1g.5gb slices.

Why C is wrong: Tempting because it pairs a MIG-flavoured resource with a profile label, but there is no generic nvidia.com/mig resource and the device plugin selects slices by the fully qualified resource name rather than by a separate profile label.

Why D is wrong: Tempting because 5Gi matches the slice memory, but Kubernetes memory limits govern system RAM and are never interpreted as a GPU partition selector, so this would not bind the pod to a 1g.5gb instance.

A team runs a transformer inference service on Kubernetes and wants the HorizontalPodAutoscaler to add replicas when GPU compute utilisation across the fleet stays high. The DCGM exporter is running and a Prometheus instance is already scraping its DCGM_FI_DEV_GPU_UTIL series successfully, yet the HPA reports the metric as unavailable and never scales. Which missing component lets the HPA consume that Prometheus series?

• AReconfigure the HPA to target the built-in cpu resource metric, because the kubelet aggregates GPU utilisation into the standard resource metrics pipeline once the DCGM exporter is present.
• BRaise the HPA maxReplicas ceiling, because the metric is reported as unavailable only while the desired replica count already sits at the configured maximum.
• CDeploy a metrics adapter, such as the Prometheus Adapter, that registers the DCGM utilisation series with the custom or external metrics API so the HPA controller can query it.check_circle Correct
• DAnnotate the inference pods so metrics-server scrapes the DCGM endpoint directly, since metrics-server can serve any Prometheus gauge once pod scrape annotations are present.

Why A is wrong: Tempting because CPU metrics work out of the box through metrics-server, but the kubelet never folds GPU utilisation into CPU resource metrics, so this discards the very GPU signal the team needs and still leaves the metric unavailable.

Why B is wrong: Tempting because a low ceiling can stall scaling, but an unavailable metric is a metrics-API discovery failure rather than a ceiling condition, so changing maxReplicas does nothing to make the GPU series queryable.

Why C is correct: Correct: the HPA controller reads non-resource metrics only through the custom.metrics.k8s.io or external.metrics.k8s.io API, and an adapter is what surfaces a Prometheus series like the DCGM gauge through that API for the controller to read.

Why D is wrong: Tempting because scrape annotations are a familiar Prometheus pattern, but metrics-server only serves CPU and memory resource metrics and cannot expose arbitrary Prometheus gauges, so it can never deliver the DCGM series to the HPA.

A cluster mixes cheap CPU worker nodes with a few costly GPU nodes. After a multimodal service is deployed, ordinary CPU-only batch jobs keep landing on the GPU nodes and consuming their CPU and memory, leaving GPU pods Pending because the nodes are full of non-GPU work. The team wants the GPU nodes reserved so that only workloads that explicitly opt in may schedule there. Which combination of mechanisms achieves this reservation?

• AAdd a nodeSelector for the GPU nodes to the GPU pods only, which suffices because a node selector both attracts the GPU pods and repels every workload that lacks the selector.
• BSet a high priorityClassName on the GPU pods so the scheduler preempts the CPU jobs from the GPU nodes whenever a GPU pod is pending.
• CDefine a ResourceQuota on the GPU node pool that forbids pods without a GPU request, which the scheduler enforces per node to keep CPU jobs away.
• DApply a taint to the GPU nodes and add a matching toleration to the GPU pods, so the taint repels untolerating workloads while the toleration admits the GPU pods.check_circle Correct

Why A is wrong: Tempting because a nodeSelector does steer GPU pods onto the right nodes, but selectors only express attraction and never repel other pods, so CPU jobs with no selector remain free to schedule onto the GPU nodes.

Why B is wrong: Tempting because preemption can evict lower-priority pods, but priority only acts once a GPU pod is already pending and competing, and it does not stop CPU jobs from occupying the nodes in the first place, causing churn rather than reservation.

Why C is wrong: Tempting because it sounds like a guard against non-GPU pods, but ResourceQuota is namespace-scoped rather than node-scoped and cannot express a per-node rule that blocks pods lacking a GPU request, so CPU jobs would still land on the GPU nodes.

Why D is correct: Correct: a node taint repels any pod that does not carry a matching toleration, and adding that toleration only to the GPU pods lets them schedule while keeping ordinary CPU jobs off the reserved GPU nodes.

A multimodal pipeline reuses a pretrained convolutional backbone to extract image features for a downstream text-image retrieval task. The team debates whether to fine-tune the backbone or use it purely as a fixed feature extractor. Which consideration most strongly favours full fine-tuning of the backbone over freezing it?

• AThe team has very limited GPU memory and needs to minimise the number of parameters held in the optimiser state during training.
• BThe downstream dataset is small and closely resembles the distribution on which the backbone was originally pretrained.
• CThe backbone uses a diffusion-based architecture whose denoising layers are not suited to gradient-based adaptation for discriminative tasks.
• DThe downstream dataset is large and its image distribution differs significantly from the backbone's pretraining data.check_circle Correct

Why A is wrong: Limited GPU memory is an argument for freezing the backbone, not fine-tuning it; fine-tuning requires storing gradients and optimiser states for all backbone parameters, which increases memory consumption substantially.

Why B is wrong: A small, similar-distribution dataset is the textbook case for feature extraction with a frozen backbone; fine-tuning in this setting risks overfitting the pretrained representations to limited samples.

Why C is wrong: Diffusion model backbones can be fine-tuned with gradient descent for discriminative tasks; the architectural style does not prohibit gradient-based adaptation, making this rationale incorrect as a general rule.

Why D is correct: When the target distribution diverges substantially from the pretraining distribution and sufficient labelled data is available, fine-tuning the backbone allows all layers to adapt their representations, yielding better feature alignment than frozen weights that encode a mismatched distribution.

An organisation trains a 7-billion-parameter generative text model and wants to deploy it on edge devices that support at most 500 million parameters. Which transfer learning technique produces a smaller deployable model by using the large model to supervise training of the smaller one?

• ARetrieval-augmented generation, where the large model indexes its own activations into a vector store that the small model queries at inference time.
• BQuantisation-aware training of the large model to 4-bit precision, reducing its memory footprint to fit within the edge device constraint.
• CKnowledge distillation, where the large model acts as a teacher producing soft probability distributions that train a smaller student model.check_circle Correct
• DAdapter-based fine-tuning of the large model on edge-representative data, then pruning the adapter weights to meet the parameter budget.

Why A is wrong: Retrieval-augmented generation augments a model with external knowledge at inference time; it does not reduce the model size or transfer learned representations into a smaller architecture.

Why B is wrong: Quantisation compresses a single model's weight representation and can reduce memory, but a 7B model quantised to 4-bit still has 7B parameters and may not meet a 500M parameter target; it does not transfer knowledge to a separate smaller architecture.

Why C is correct: Knowledge distillation transfers learned behaviour from a large teacher to a compact student by training the student to match the teacher's output distributions rather than hard labels. This produces a genuinely smaller architecture suitable for edge deployment while retaining much of the teacher's predictive quality.

Why D is wrong: Adapter fine-tuning adds small modules to the existing large model and pruning reduces them, but the base 7B weights remain intact; this combined approach is unlikely to reach a 500M parameter target without also reducing the backbone, making it a less direct solution than distillation.