Skip to content

Commit fd755ce

Browse files
committed
Add more explanations about nvFractions features
Signed-off-by: davidLif <davidshani12@gmail.com>
1 parent 167a456 commit fd755ce

4 files changed

Lines changed: 117 additions & 0 deletions

File tree

docs/gpu-sharing/README.md

Lines changed: 5 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -325,6 +325,11 @@ metadata:
325325

326326
KAI keeps pods with incompatible compute sharing modes out of the same fractional GPU group.
327327

328+
`time-slicing` is the default. Use `sm-sharing` for workloads that need to run
329+
concurrently and have MPS configured. For guidance on choosing a mode, the
330+
memory request and limit semantics, and diagrams of both models, see
331+
[NvFractions GPU Sharing](nv-fraction/README.md).
332+
328333
## Troubleshooting
329334

330335
### Fractional GPU pod is rejected
Lines changed: 112 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,112 @@
1+
# NvFractions GPU Sharing
2+
3+
NvFractions is one of KAI Scheduler's operator-backed GPU-sharing mode. It uses CUDA
4+
memory limits to enforce a GPU-memory boundary for each fractional workload.
5+
The `gpu-sharing` operator configures the runtime support for those limits and
6+
reports when GPU nodes are ready to accept NvFractions workloads. KAI uses the
7+
workload's GPU-memory request to make placement and accounting decisions.
8+
9+
Unlike non-enforced GPU sharing, NvFractions applies CUDA memory limits at
10+
runtime:
11+
12+
| Mode | Memory isolation | Request model |
13+
| --- | --- | --- |
14+
| `NonMemoryEnforced` | KAI schedules a fraction but does not enforce memory limits at the container level. | Pod-level `gpu-fraction` or `gpu-memory` annotations. |
15+
| `NvFractions` | CUDA memory limits are applied through the GPU-sharing operator's runtime integration. | Per-container `request` and `limit` annotations using Kubernetes memory quantities. |
16+
17+
NvFractions also adds these capabilities:
18+
19+
- A request identifies the container that receives the fractional GPU and is
20+
the value KAI schedules.
21+
- A limit can let a workload use spare memory above its request, while
22+
preserving the request as its guaranteed allocation.
23+
- KAI only schedules a fractional workload after the GPU-sharing operator and
24+
its target GPU node report ready.
25+
26+
For installation, runtime configuration, and the complete annotation
27+
reference, see [GPU Sharing](../README.md).
28+
29+
## Before you begin
30+
31+
An administrator must install KAI in `NvFractions` mode and make the
32+
GPU-sharing operator ready before submitting workloads. In particular, the
33+
`GpuSharingConfig` named `default` and the target GPU node must report ready.
34+
See [NvFractions readiness](../README.md#nvfractions-readiness).
35+
36+
## Submit an NvFractions workload
37+
38+
Use the NvFractions submission instructions in the parent
39+
[GPU Sharing guide](../README.md#request-gpu-memory-with-nvfractions). It
40+
includes the required KAI queue label, scheduler name, and annotation format.
41+
42+
Ready-to-apply examples are available in the parent directory:
43+
44+
- [Memory request](../nv-fractions-memory.yaml)
45+
- [Memory request and limit](../nv-fractions-request-limit.yaml)
46+
47+
48+
### Dynamic fraction - Allow a workload to grow when memory is available
49+
50+
nvFraction`request` and `limit` operate in a similar way to the standard k8s request and limit.
51+
Set a lower `request` and a higher `limit` when a workload has a known baseline
52+
but can make useful progress with spare GPU memory. The request is its
53+
guaranteed scheduling allocation; it may use memory up to its limit while that
54+
capacity is available. The runtime can reclaim memory above the request when
55+
the GPU becomes contended. The request must not exceed the limit. See the
56+
[request-and-limit example](../nv-fractions-request-limit.yaml).
57+
58+
![Fixed and elastic GPU-memory allocations](dynamic-fraction.png)
59+
60+
If only `limit` is set, KAI uses the limit as the request. Use an explicit
61+
request when the workload should be scheduled on a guaranteed amount smaller
62+
than its maximum.
63+
64+
Setting a `limit` is useful for pods that have occasional "bursts" of gpu memory usage.
65+
66+
## Choose a compute-sharing mode
67+
68+
GPU memory and GPU compute mode are selected independently. The
69+
`kai.scheduler/gpu-compute-sharing-mode` annotation chooses how workloads in
70+
the same fractional GPU group share compute. KAI supports these values:
71+
72+
| Mode | How workloads run | Best fit |
73+
| --- | --- | --- |
74+
| `time-slicing` | Workloads take turns using the GPU. Unused time is available to other workloads. This is the default. | Bursty development, notebooks, and throughput-oriented or latency-tolerant inference. |
75+
| `sm-sharing` | Workloads run concurrently and share the GPU streaming multiprocessors (SMs). | Steady or latency-sensitive inference, and coordinated multi-GPU or multi-Pod workloads. Requires MPS. |
76+
77+
Set `kai.scheduler/gpu-compute-sharing-mode` in the NvFractions Pod manifest.
78+
The [GPU Sharing guide](../README.md#compute-sharing-mode-within-a-fractional-gpu-group)
79+
shows the annotation in context.
80+
81+
![Time-slicing and SM-sharing](compute-mode.png)
82+
83+
Two pods requiring diffrent gpu compute mode cannot share the same device.
84+
Because of this, KAI keeps workloads that use different compute-sharing modes
85+
in separatefractional GPU groups. A pod that requests `sm-sharing` is therefore not
86+
placed with a `time-slicing` pod, and the reverse is also true.
87+
88+
### Choosing the right compute mode
89+
90+
Choose `time-slicing` for workloads that can tolerate an occasional delay and
91+
do not use the GPU continuously. It has no MPS dependency and is the safest
92+
default for interactive development and batch work.
93+
94+
Choose `sm-sharing` when concurrent GPU progress matters more than burst
95+
throughput. For example, it can provide steadier latency for online inference
96+
and avoids one participant pausing while other participants in a distributed
97+
job continue to wait. Configure MPS on the GPU nodes before using this mode;
98+
see [GPU Sharing with MPS](../mps/README.md).
99+
100+
## Verify the allocation
101+
102+
After creating the Pod, confirm that KAI scheduled it and that the runtime
103+
started it:
104+
105+
```bash
106+
kubectl get pod <pod-name> -n <namespace> -o wide
107+
kubectl describe pod <pod-name> -n <namespace>
108+
```
109+
110+
If the Pod remains pending, check the GPU-sharing configuration and the target
111+
node's `gpu-sharing.nvidia.com/Ready` condition as described in
112+
[Troubleshooting](../README.md#fractional-gpu-pod-stays-pending-in-nvfractions-mode).
79 KB
Loading
68.6 KB
Loading

0 commit comments

Comments
 (0)