Sleep, wake, and warm

ColdSnap lets you keep a workload’s runtime in place while freeing managed GPU memory, then bring it back when needed. You can also restore a capsule into a warm state ahead of demand and defer loading its weights until you are ready to serve.

Start with a materialized published capsule or your own local capture. Run the commands from your activated ColdSnap plugin preview environment and use a recipe and placement that support the lifecycle operations you need. In the examples below, replace recipe.yaml with your recipe path or @coldsnap/... name, and two-node with your saved cluster name.

Choose the operation

Operation	Start from	What it does
sleep	A running ColdSnap workload	Releases managed model and graph memory while retaining the live runtime.
warm	A prepared n610 capsule	Restores the runtime with model weights and KV memory still unloaded. It is not ready to serve yet.
wake	A sleeping or warm workload	Loads the required memory, validates the workload, and returns it to serving.

Use sleep → wake between periods of activity. Use warm → wake when you want to do part of the restore work before requests arrive.

Sleep a running workload

Pause incoming traffic and let active requests finish. Then put the running ColdSnap workload to sleep:

sparkrun coldsnap sleep recipe.yaml --cluster two-node
sparkrun coldsnap status recipe.yaml --cluster two-node

The lifecycle report should show state: sleeping. The containers stay in place, but the workload is no longer ready to serve. Sleep releases managed weights and graph allocations and discards the configured KV cache contents.

The retained processes, CUDA contexts, communication state, and other runtime allocations still consume some GPU memory. The amount freed depends on the workload; sleep does not free all GPU memory.

Wake it when needed

Use the same recipe and placement to resume the retained workload:

sparkrun coldsnap wake recipe.yaml --cluster two-node
sparkrun coldsnap status recipe.yaml --cluster two-node

Wake reloads the model weights, restores required memory mappings, and checks health and the recipe’s expected response. Resume traffic after it succeeds and the lifecycle report shows state: running.

Restore into a warm state

For n610 capsules on hosts with NVIDIA driver 610 or newer, warm performs the process, CUDA, and distributed communication restoration ahead of time. It stops before loading model weights and mapping KV memory:

sparkrun coldsnap warm recipe.yaml --cluster two-node
sparkrun coldsnap status recipe.yaml --cluster two-node

The report should show state: warm. When you need the workload:

sparkrun coldsnap wake recipe.yaml --cluster two-node

warm starts a restore and follows the normal deployment replacement behavior. Use it when preparing an activation; use sleep to retain a workload that is already running. The n580 snapshot driver does not support warm activation.

Retained state and recovery

Sleep and warm state depend on the live containers and their hosts. If the containers are removed or a host restarts, use sparkrun run to restore from your capsule again. A new placement may need materialization first.

Lifecycle commands target the workload matching your recipe on the selected cluster. If the workload is absent or ambiguous, inspect sparkrun status --cluster two-node and confirm the recipe and placement before retrying.

For the underlying lifecycle details, see warm and live sleep/wake in the Sparkrun reference.