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 and resource.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 the cpu limit you provided, whichever is smaller.

    • For memory, the derived value is either 0.5 GiB or the memory 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 and memory.

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