Scaling
Agent Mask scales by matching service instances to Snowflake GPU compute pool nodes. A target of 3 runs 3 nodes and 3 service instances, allowing independent batches or concurrent calls to run in parallel.
Scale up or down
Section titled “Scale up or down”CALL app_public.scale(3); -- 3 nodes, 3 service instancesCALL app_public.scale(1); -- back to 1 (default)Instance families per cloud
Section titled “Instance families per cloud”The instance family is auto-selected based on which cloud region your account runs in:
| Cloud | Instance family |
|---|---|
| AWS | GPU_NV_S |
| Azure | GPU_NV_SM |
| GCP | GPU_GCP_NV_L4_1_24G |
These are single-GPU node families selected for the supported cloud. Availability and startup behavior are managed by Snowflake and can vary by region.
When to scale
Section titled “When to scale”- High-throughput batch jobs: you are masking large row sets or many files and the query can fan out across independent batches.
- Concurrent queries: multiple users, jobs, or dashboards call
mask()at the same time. Without additional instances, work queues behind the available instance.
When NOT to scale
Section titled “When NOT to scale”- Interactive single-call usage: one user calling
mask()ad-hoc. Extra nodes just sit idle and cost money. - To reduce cold-start time: scaling a suspended pool does not remove Snowflake provisioning and image startup time. Use
set_auto_suspend()with a longer window instead.
Cost control
Section titled “Cost control”- Scaling is explicit. There is no autoscaling.
- The configured node count remains in effect until you call
scale()again. If the pool auto-suspends, the same target count applies when it resumes. - More nodes increase running cost while the pool is active. Use
set_auto_suspend()so nodes can suspend between active windows. See Cold start and auto-suspend. - Scale back down after a batch window with
CALL app_public.scale(1);.