County health wants HPC-style batch jobs isolated from interactive inference on the same GPU. What should be enabled?
Select an answer to reveal the explanation.
Short Explanation
Turn on MIG when batch HPC and interactive inference must share a county GPU without stepping on each other—lanes, not a free-for-all.
Full Explanation
County health wanting HPC-style batch jobs isolated from interactive inference on the same GPU should enable MIG so AI and HPC tenancy can be isolated on the same physical GPU. Batch and interactive profiles differ in duration, memory footprint, and latency sensitivity; MIG partitions give each tenancy a bounded device slice instead of relying on polite process behavior. That isolation is the exam-relevant mechanism for mixed AI/HPC sharing on one GPU. Allowing a single unrestricted process with unlimited GPU memory for every user fails by concept: unrestricted sharing eliminates isolation and lets one tenant dominate the device. Using only CPU cgroups while leaving GPUs fully shared and unpartitioned fails by concept: CPU controls do not partition GPU memory or compute. Using random process killing as the primary isolation mechanism fails by concept: reactive kills are not deterministic tenancy isolation and harm civic job reliability. Exam caveat: MIG isolates GPU resources; scheduler and queue policy still decide which jobs land on which instances—MIG alone does not invent fair-share scheduling. Operational check: enable MIG on the county health GPU, assign HPC batch and interactive inference to separate instances, run both concurrently, and verify neither tenant can exhaust the other’s partitioned memory or compute.