Snowpark Container Services: Novos valores padrão e validação de requisitos de recurso para um serviço

Atenção

Essa mudança de comportamento está no pacote 2024_06.

Para saber o status atual do pacote, consulte Histórico do pacote.

Atenção

Essa mudança de comportamento seria introduzida com o pacote 2024_05. No entanto, ela foi adiada e agora está no pacote 2024_06.

Você fornece requisitos de recurso para um serviço na especificação do serviço.

A maneira como o Snowflake lida com serviços com requisitos de recurso não especificados está mudando. Além disso, a maneira como o Snowflake valida os requisitos de recurso especificados está mudando:

Antes da mudança:
  • Se você não fornecer nenhum requisito de recurso, o Snowflake assumirá que seu serviço consumirá recursos insignificantes.

  • Quando você fornece requisitos de recurso, o Snowflake valida os valores em relação à capacidade total do nó. Os recursos consumidos pelos componentes do sistema Snowpark Container Services não são considerados.

Após a mudança:

Se os requisitos de recurso não forem fornecidos, os seguintes padrões serão aplicados. Observe que resource.requests e resource.limits são relativos à capacidade do nó (vCPU e memória) da família de instância do pool de computação associado.

  • Se uma solicitação de recurso (CPU, memória ou ambos) não for fornecida, o Snowflake deriva uma para você:

    • Para cpu, o valor derivado é 0,5 ou o limite de cpu fornecido, o que for menor.

    • Para memory, o valor derivado é 0,5 GiB ou o limite de memory fornecido, o que for menor.

  • Se um limite de recurso (CPU, memória ou ambos) não for fornecido, o Snowflake definirá os limites como padrão para a capacidade do nó para a família de instância do pool de computação associado.

  • Se você fornecer resource.limits e eles excederem a capacidade do nó, o Snowflake limitará a capacidade do nó.

  • O Snowflake avalia esses requisitos de recurso de forma independente para cpu e memory.

Observe que, se for teoricamente impossível para o Snowflake agendar o serviço no pool de computação fornecido, CREATE SERVICE falhará. Teoricamente impossível pressupõe que o pool de computação tenha o número máximo de nós permitidos e não haja outros serviços em execução no pool de computação. Ou seja, não há como o Snowflake alocar os recursos solicitados dentro dos limites do pool de computação. Se for teoricamente possível, mas os recursos necessários estiverem em uso, então CREATE SERVICE será bem-sucedido. Algumas instâncias de serviço relatarão o status indicando que o serviço não pode ser agendado devido a recursos insuficientes até que os recursos estejam disponíveis.

Além disso, com este BCR a capacidade de nó (vCPU e memória) para cada tipo de instância foi alterada conforme mostrado:

Família de instâncias

vCPU . antes da mudança

vCPU . depois da mudança

Memória (GiB) . antes da mudança

Memória (GiB) . após mudança

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 . (somente AWS)

8

6

32

27

GPU_NV_M . (somente AWS)

48

44

192

178

GPU_NV_L . (somente AWS)

96

92

1152

1112

GPU_NV_XS . (somente Azure)

4

3

28

26

GPU_NV_SM . (somente Azure)

36

32

440

424

GPU_NV_2M . (somente Azure)

72

68

880

858

GPU_NV_3M . (somente Azure)

48

44

440

424

GPU_NV_SL . (somente Azure)

96

92

880

858

Ref.: 1648