Snowpark Container Services: New default values and validation of resource requirements for a service (Pending)¶
Attention
This behavior change is in the 2024_06 bundle.
For the current status of the bundle, refer to Bundle History.
Attention
This behavior change was going to be introduced with the 2024_05 bundle. However, it had been postponed and is now in the 2024_06 bundle.
You provide resource requirements for a service in the service specification.
The way in which Snowflake handles services with unspecified resource requirements is changing. In addition, the way in which Snowflake validates specified resource requirements is changing:
- Before the change:
If you do not provide any resource requirements, Snowflake assumes your service will consume negligible resources.
When you provide resource requirements, Snowflake validates the values against the entire node capacity. Resources consumed by Snowpark Container Services system components are not considered.
- After the change:
If resource requirements are not provided the following defaults are applied. Note that
resource.requests
andresource.limits
are relative to the node capacity (vCPU and memory) of the instance family of the associated compute pool.If a resource request (cpu, memory, or both) is not provided, Snowflake derives one for you:
For
cpu
, the derived value is either 0.5 or thecpu
limit you provided, whichever is smaller.For
memory
, the derived value is either 0.5 GiB or thememory
limit you provided, whichever is smaller.
If a resource limit (cpu, memory, or both) is not provided, Snowflake defaults the limits to the node capacity for the instance family of the associated compute pool.
If you do provide
resource.limits
and they exceed the node capacity, Snowflake will cap the limit to the node capacity.Snowflake evaluates these resource requirements independently for
cpu
andmemory
.
Note that if it’s theoretically impossible for Snowflake to schedule the service on the given compute pool, CREATE SERVICE will fail. Theoretically impossible assumes the compute pool has the maximum number of allowed nodes and there are no other services running on the compute pool. That is, there is no way Snowflake could allocate the requested resources within the compute pool limits. If it’s theoretically possible, but required resources are in use, then CREATE SERVICE will succeed. Some service instances will report status indicating that the service cannot be scheduled due to insufficient resources until resources become available.
Also, with this BCR the node capacity (vCPU and memory) for each instance type has changed as shown:
Instance family |
vCPU . before change |
vCPU . after change |
Memory (GiB) . before change |
Memory (GiB) . after change |
---|---|---|---|---|
CPU_X64_XS |
2 |
1 |
8 |
6 |
CPU_X64_S |
4 |
3 |
16 |
13 |
CPU_X64_M |
8 |
6 |
32 |
28 |
CPU_X64_L |
32 |
28 |
128 |
116 |
HIGHMEM_X64_S |
8 |
6 |
64 |
58 |
HIGHMEM_X64_M |
32 |
28 |
256 (AWA) . 256 (Azure) |
240 (AWS) . 244 (Azure) |
HIGHMEM_X64_L |
128 (AWS) . 96 (Azure) |
124 (AWS) . 92 (Azure) |
1024 (AWS) . 672 (Azure) |
984 (AWS) . 654 (Azure) |
GPU_NV_S . (AWS only) |
8 |
6 |
32 |
27 |
GPU_NV_M . (AWS only) |
48 |
44 |
192 |
178 |
GPU_NV_L . (AWS only) |
96 |
92 |
1152 |
1112 |
GPU_NV_XS . (Azure only) |
4 |
3 |
28 |
26 |
GPU_NV_SM . (Azure only) |
36 |
32 |
440 |
424 |
GPU_NV_2M . (Azure only) |
72 |
68 |
880 |
858 |
GPU_NV_3M . (Azure only) |
48 |
44 |
440 |
424 |
GPU_NV_SL . (Azure only) |
96 |
92 |
880 |
858 |
Ref: 1648