Title: Lab 11 — MIG Partition Planning and DRA Claim Design
Course: AIINFRA 200: Production Inference Serving & GPU Orchestration > Section: Week 11 — Dynamic Resource Allocation and MIG Partitioning

🛠️ Lab 11 — MIG Partition Planning and DRA Claim Design (50 pts)

Goal: Since consumer and free-tier GPUs cannot create real MIG partitions, this lab has you design a MIG partitioning plan on paper for a shared A100, validate it against NVIDIA's official partition profile syntax, and then get hands-on with the scheduling side of the story by writing real DRA YAML (DeviceClass and ResourceClaim) against a free local Kubernetes cluster. Steps:

1. Install kind (Kubernetes-in-Docker) and kubectl locally if you don't already have them — both are free and run on a laptop.
2. Read the partition profile table in the NVIDIA MIG User Guide (linked in Resources). Note the profile naming convention (e.g., 1g.5gb, 2g.10gb, 3g.20gb, 4g.20gb, 7g.40gb) and what compute-slice-count and memory each profile provides on an 80GB A100.
3. Design your partitioning plan: Assume a single A100 (80GB) must be shared across 4 course teams with these needs — Team A needs a small inference sandbox (\~5GB), Team B needs a mid-size fine-tuning slot (\~20GB), Team C needs another mid-size slot (\~20GB), and Team D needs a larger evaluation slot (\~40GB). Choose specific MIG profiles for each team and show that your choices fit within the GPU's total instance and memory budget. State whether you are using the single or mixed MIG strategy and justify your choice in 3-5 sentences.
4. Write a short YAML snippet (ResourceClass or InferenceService-style resource requests: block) for each team expressing your chosen MIG profile as a resource request, matching the syntax shown in NVIDIA's documentation.
5. Create a local kind cluster (kind create cluster) and, following the CNCF 2026 DRA walkthrough (see Resources), write a DeviceClass YAML and a ResourceClaim YAML for a simulated/time-sliced GPU device (kind clusters have no real GPUs, so this uses the DRA driver's simulated or CPU-only demo device — that's expected and fine).
6. Apply your YAML with kubectl apply -f, create a simple pod that references your ResourceClaim, and run kubectl describe pod to confirm the claim was satisfied (or capture the scheduling event/log showing the claim being processed if full satisfaction isn't possible on kind).
7. Write a one-paragraph reflection connecting your MIG plan to your DRA YAML: how would a real DRA-for-GPUs driver turn your Step 3 plan into the kind of on-demand ResourceClaim you tested in Steps 5-6?

Deliverables: Submit your MIG partitioning plan (table + strategy justification), your 4 resource-request YAML snippets, your DeviceClass/ResourceClaim YAML, a terminal screenshot or log excerpt showing kubectl describe pod output (or the scheduling event you captured), and your reflection paragraph — as a single document upload or pasted text entry.