Sharing NVIDIA GPUs in Kubernetes environments is a growing necessity to optimize costs and resources, but choosing the right model can be the difference between an efficient deployment and operational chaos. There are two main approaches — Multi-Instance GPU (MIG) and time-slicing — each addressing different problems. This article analyzes their differences, when to use each, and how to complement them with resource quotas, from a technical and business perspective, with the support of Q2BSTUDIO, a company specialized in custom software development, artificial intelligence, cybersecurity, and cloud computing.
The main challenge is that GPUs are expensive resources often underutilized. Kubernetes treats them as indivisible extended resources: an application requests one GPU, gets it fully allocated, and the rest of the cluster considers it busy even if the workload uses only a fraction of its capacity. The solution lies in sharing the GPU, but not all techniques are equivalent. MIG physically divides the GPU into independent hardware instances, each with dedicated memory and compute. Time-slicing, on the other hand, advertises multiple logical replicas of the same GPU, but all share the same hardware and compete for execution time, without memory isolation or guaranteed performance.
When to use MIG? It is ideal for multi-tenant environments where each workload needs predictable resource limits and real isolation. For example, in inference platforms with known model sizes, where a 1g.10GB MIG instance is sufficient, and a 2g.20GB one is reserved for a larger model. MIG provides hardware partitioning that avoids the 'noisy neighbor' problem and delivers performance guarantees. However, it has limitations: available profiles depend on the GPU model (H100, A100, etc.) and are not arbitrarily configurable. Changing MIG geometry requires draining the node, applying the new configuration, and waiting for MIG Manager to validate it. This is a disruptive operation that must be planned as major maintenance.
When to use time-slicing? It is suitable for lightweight, bursty workloads, development environments, notebooks, or CI/CD pipelines. Since no hardware partitions are created, you can advertise, for example, 4 or 8 replicas of the same physical GPU. The advantage is flexibility: you can change the number of replicas without rebooting the node, only by restarting the device plugin. The downside is the lack of isolation: one workload can exhaust all GPU memory, and latency becomes unpredictable under contention. To mitigate risks, rename shared resources (e.g., nvidia.com/gpu.shared) and enable failRequestsGreaterThanOne to prevent a pod from requesting multiple references thinking it will get more performance.
Both techniques can be combined: MIG as a first layer of hardware partitioning, and time-slicing on top of each MIG instance for further oversubscription. This is useful for very small workloads but adds operational and monitoring complexity. Our recommendation at Q2BSTUDIO is to start with separate node pools: an exclusive pool for full GPUs (training, latency-sensitive inference), a MIG pool for production multi-tenancy, and a time-slicing pool for development and testing. Each pool should have its own labels, taints, quotas, and metrics.
ResourceQuotas are an indispensable complement. They limit how many GPU resources a namespace can claim, whether MIG profiles or time-slicing resources. But note: a quota does not guarantee performance or a percentage of GPU; it only controls admission. If a namespace has a quota of 4 for nvidia.com/gpu.shared, it can run up to 4 pods, but all will compete for the same physical GPU. For true governance, combine quotas with affinity policies, explicit naming, and concurrent performance tests.
From an implementation standpoint, the NVIDIA GPU Operator automates much of the work. For MIG, use MIG Manager with 'single' strategy (all devices identical) or 'mixed' strategy (varied profiles). In mixed strategy, resources are advertised with names like nvidia.com/mig-1g.10gb, giving developers transparency. In single strategy, nvidia.com/gpu is used along with a product label. The choice depends on workload diversity in the cluster.
For time-slicing, configure a ConfigMap with the number of replicas and flags such as renameByDefault: true. It is important to validate that monitoring adapts: with time-slicing, DCGM Exporter cannot reliably associate GPU metrics with individual containers. Therefore, applications should include their own telemetry (latency, throughput, error rate). At Q2BSTUDIO we design custom observability solutions, integrating business metrics with infrastructure data so each team has real visibility into their consumption.
A common practical case is a company deploying conversational AI agents. Each agent requires real-time inference with variable spikes. Using a full GPU per agent would be prohibitive. With MIG, fixed-size instances can be assigned to critical agents, and time-slicing for test ones. Additionally, namespace quotas give each department a clear limit. This is complemented by cloud services like AWS or Azure to scale horizontally when demand exceeds local capacity. At Q2BSTUDIO we help companies design this hybrid architecture, integrating AWS/Azure cloud services with on-premise Kubernetes clusters, and developing custom software applications that manage the AI model lifecycle.
Another key aspect is cybersecurity. Sharing GPUs introduces risks of information leakage between processes if there is no hardware isolation. MIG offers stronger isolation, but it is not impenetrable. For regulated environments, we recommend combining MIG with network policies, dedicated namespaces, and encryption of data in transit and at rest. Our cybersecurity team performs configuration audits and penetration testing to ensure the sharing model does not expose sensitive data.
Finally, don't forget business intelligence. When sharing GPUs, understanding real usage is critical for decision-making. BI tools like Power BI can consume DCGM data and custom metrics to generate dashboards on utilization, cost per workload, and capacity planning. At Q2BSTUDIO we integrate BI/Power BI solutions with cluster data pipelines, providing actionable reports that help adjust MIG profiles or time-slicing replicas based on actual demand.
In summary, sharing GPUs is not a binary decision. MIG, time-slicing, and quotas are complementary tools that must be applied according to each workload's requirements. The key is to design an architecture of separate pools, with clear policies, proper monitoring, and a controlled change process. If your organization seeks to optimize GPU usage without sacrificing performance or security, Q2BSTUDIO can help you implement these solutions, from design to ongoing operations.
