A school-district GPU lab wants about twenty students to run homework models at once. What MIG approach fits?
Select an answer to reveal the explanation.
Short Explanation
MIG turns one GPU into classroom seats—twenty students get fractional cards instead of fighting over one. Handing out whole servers per student or banning GPUs wastes the lab budget.
Full Explanation
Enabling MIG so students receive fractional GPUs is the right fit for a school-district lab that wants about twenty concurrent homework models. MIG carves supported GPUs into isolated instances so many notebooks can run at once with memory boundaries, instead of one student monopolizing a whole card. Pair MIG profiles with namespace quotas and fair admission so the classroom fleet stays usable during peak lab hours.
Giving each student exclusive ownership of an entire multi-GPU server destroys density—twenty students would demand an unaffordable rack footprint for homework-scale models. Forbidding GPU access and requiring CPU-only notebooks removes the learning objective and overloads CPUs without teaching accelerator workflows. Configuring one shared full GPU with no profiles and hoping for fairness invites OOM kills and silent contention; without MIG or a governed time-slicing policy, "hope" is not a scheduler.
Exam caveat: profile size must match typical homework models—too-small MIG slices cause OOMs; too-large slices reduce concurrency below twenty. Not all GPUs support MIG; lab SKUs must be chosen accordingly. Student RBAC should never include node reconfiguration rights that could flip MIG mode mid-class.
Operational check: provision enough MIG instances for the target concurrency, smoke-test twenty concurrent small training jobs, verify isolation (one student's OOM does not kill peers), and publish a simple matrix of which notebook sizes map to which MIG profiles for instructors.