From 0dae78d55adea3f34347a52e628ef844b3894ba4 Mon Sep 17 00:00:00 2001 From: Isoken Date: Tue, 18 Aug 2026 18:53:25 +0100 Subject: [PATCH] doc: update range grammar description in GPU virtualization Signed-off-by: Isoken --- docs/core-concepts/gpu-virtualization.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/core-concepts/gpu-virtualization.md b/docs/core-concepts/gpu-virtualization.md index cf1047dd5..051fbe6af 100644 --- a/docs/core-concepts/gpu-virtualization.md +++ b/docs/core-concepts/gpu-virtualization.md @@ -5,7 +5,7 @@ sidebar_label: GPU Virtualization In AI inference scenarios, a common dilemma is that GPUs are expensive, but mostly idle. -A typical inference service often only uses 20%~40% of the GPU's compute and a small amount of VRAM, leaving the rest idle. Kubernetes' default GPU scheduling model is exclusive: `nvidia.com/gpu: 1` means the entire card is yours, and all other Pods must wait. Want to share a single GPU across multiple inference services? The standard Device Plugin cannot do it, because it can only report device counts (integers) to the scheduler - there is no concept of "VRAM quota." +A typical inference service often only uses between 20% and 40% of the GPU's compute and a small amount of VRAM, leaving the rest idle. Kubernetes' default GPU scheduling model is exclusive: `nvidia.com/gpu: 1` means the entire card is yours, and all other Pods must wait. Want to share a single GPU across multiple inference services? The standard Device Plugin cannot do it, because it can only report device counts (integers) to the scheduler - there is no concept of "VRAM quota." This led to various GPU sharing solutions. NVIDIA's official Time-Slicing allows multiple Pods to be scheduled concurrently, but provides no VRAM isolation - a Pod OOM can crash all tasks on the card. MIG hardware partitioning offers true isolation, but only datacenter-grade cards like A100 and H100 support it.