Compute Pools and Warehouses for Snowflake ML Workloads

1.Compute pools: the hardware behind Container Runtime

Snowflake gives ML work two kinds of compute: virtual warehouses and compute pools. This page explains both, starting with compute pools because most Snowflake ML infrastructure runs on them. The Snowflake Container Runtime is a set of preconfigured environments for machine learning, built on Snowpark Container Services. Your custom Python ML code and the supported training APIs run inside Snowpark Container Services, and that code needs somewhere to run. That place is a compute pool: a group of nodes that are all the same machine type. ML Jobs, Notebooks on Container Runtime and other Snowpark Container Services workloads all get scheduled onto a pool.

You create a pool with three required properties. MIN_NODES is the minimum number of nodes the pool keeps, and it must be greater than 0. MAX_NODES is the most nodes the pool can scale to. INSTANCE_FAMILY sets the machine type for every node, so it decides whether you get CPU or GPU nodes, how big they are, and how many credits the pool uses while it runs. The optional properties cover how the pool behaves over its lifecycle: AUTO_RESUME, INITIALLY_SUSPENDED and AUTO_SUSPEND_SECS.

CREATE COMPUTE POOL [ IF NOT EXISTS ] <name>
  [ FOR APPLICATION <app-name> ]
  MIN_NODES = <num>
  MAX_NODES = <num>
  INSTANCE_FAMILY = <instance_family_name>
  [ AUTO_RESUME = { TRUE | FALSE } ]
  [ INITIALLY_SUSPENDED = { TRUE | FALSE } ]
  [ AUTO_SUSPEND_SECS = <num>  ]

For ML Jobs, the documentation gives a default pool size: the CPU_X64_S instance family, with at least 1 node and at most 25. If that is too small, or you need GPUs, you create your own pool with a different INSTANCE_FAMILY and pass its name when you submit the job. The ML Jobs documentation says jobs can run on GPU and high-memory CPU instances. Which of those you get depends on the instance family you chose for the pool.

Sources12

2.Idle cost and who can operate the pool

Because the instance family sets the credits a pool uses while it is running, a pool that runs with nothing to do still costs money. Two properties, which you can set at creation or change later with ALTER COMPUTE POOL, deal with this. AUTO_SUSPEND_SECS is how many seconds of inactivity Snowflake waits before suspending the pool. Inactivity has a specific meaning here: no services and no jobs running on any node in the pool. AUTO_RESUME sets whether submitting a service or job wakes a suspended pool automatically. If AUTO_RESUME is FALSE, someone has to run ALTER COMPUTE POOL <name> RESUME before any job can start. So for occasional training runs, the main setting to reduce idle cost is a shorter AUTO_SUSPEND_SECS, with AUTO_RESUME left on so the next job still starts without manual help.

Access to a pool is split into separate privileges, and exam scenarios often describe a role that needs two of them. Running a job and suspending a pool are separate rights.

Sources3

3.Allocating work: Snowpark-optimized warehouse or Container Runtime

Not every training job needs a compute pool. Snowpark-optimized warehouses are virtual warehouses built for workloads that need a lot of memory and compute. With them, you can train a model with custom code inside a Snowpark Python stored procedure. The procedure runs nested queries to load and transform data, pulls the data into its own memory, trains the model, and can write the trained model to a stage. The documentation describes this pattern as single-node training.

Container Runtime is the option when that single node is not enough. It runs on CPU or GPU compute pools and comes with popular ML and deep learning frameworks already installed. When you use the Snowflake ML APIs, it spreads the processing across the available resources. Its distributed framework uses every GPU on a multi-GPU node by default. You can also set the number of resources for each task, including GPU and memory, through the provided APIs. Container Runtimes are versioned, so you can pin a workload to a specific version and upgrade when you choose.

When the Snowflake-provided Container Runtime image does not contain the libraries or exact versions you need, you can deploy your own runtime on Container Runtime instead of installing packages by hand in every session. You build a custom container image on top of an official Snowflake ML runtime base image, adding your own packages and configuration. Base images are specific to the hardware type (CPU or GPU) and Python version, so pick the one that matches your compute pool. You then push the image to a Snowflake image repository, validate it, and register it as a Custom Runtime Environment (CRE). Custom images also suit regulated teams that need pre-scanned, allowlisted images, and teams without external access to PyPI at runtime, because the packages are already baked into the image.

The workflow has a fixed shape. Log the local Docker client in to the Snowflake image registry with snow spcs image-registry login. Write a Dockerfile that starts FROM the Snowflake base image and installs your packages. Build it for the linux/amd64 platform. Validate it locally with snow custom-image validate, which checks for the exact entrypoint /usr/local/bin/entrypoint.sh, the DASHBOARD_PORT=12003 environment variable, a set of mandatory Python packages, and a conflict-free dependency tree. Vulnerability scanning is optional. Then tag and push the image to your image repository, and run the registration DDL. Snowflake runs a server-side validation during registration, and the CRE is created only if that check passes.

CREATE CUSTOM RUNTIME ENVIRONMENT my_cre
    IMAGE_PATH = '/<database>/<schema>/<image_repo>/my-custom-image:v1'
    BASE_IMAGE_TYPE = CPU;

Once the CRE is in the RESOLVED state, you reference it from an ML Job with the runtime_environment parameter in the form cre@<name>, for example runtime_environment="cre@my_cre" on the @remote decorator. The same keyword is supported by submit_file, submit_directory and submit_from_stage. The active role needs the USAGE privilege on the CRE plus access to the underlying image repository, and a DEPRECATED CRE cannot be used for new jobs. The system also checks the image's SHA digest at runtime: if the image in the repository was modified after the CRE was registered, the job submission is rejected and you must recreate the CRE. Notebooks reference a CRE the same way, using cre@<name>. If you leave runtime_environment out, Snowflake uses the latest Snowflake Container Runtime version on your compute pool.

Sources456

Exam traps

Each one states something that sounds right. Open it to see what is actually true.

1. 1.USAGE on a compute pool is enough to suspend and resume it manually.Why is that wrong?

   USAGE only lets a role run services and jobs on the pool. Suspending and resuming need the separate OPERATE privilege.

   Covered in Idle cost and who can operate the pool

2. 2.A custom runtime image can be built from any base image, such as a generic Python image, as long as it contains your libraries.Why is that wrong?

   Custom images must derive from an official Snowflake ML runtime base image, matched to the hardware type and Python version, and must pass validation before registration.

   Covered in Allocating work: Snowpark-optimized warehouse or Container Runtime