Stop, delete, and repull a local model: map the states and costs

Define the state transition

Treat lifecycle as a set of independently owned objects, not one master switch. A model process can be idle while its runtime and virtual machine remain active. A powered-off server can retain allocated compute, a boot disk, an address or a separate storage subscription. Deleting a model file can leave container layers, caches and backups. Cancelling a service may follow a separate process and effective date.

Before requesting a change, write down the object identifier, current state, desired state, actor who can approve it, expected impact, and evidence that would prove completion. If the console uses labels such as “stop,” “delete,” “terminate,” “destroy” or “cancel,” record the provider’s definition for the exact product. Do not infer one action’s effect from another product’s wording.

Runtime model unload

Runtime unload releases an application model from active memory; it does not remove the model artifact or stop the runtime process, virtual machine, storage allocation, network address or subscription. The Ollama FAQ documents ollama stop with a model name as a way to unload that model from memory. It also describes a default keep-alive period and controls for changing retention. Those details are version and configuration sensitive, so check the documentation and selected installation before relying on timing.

Use unload when the immediate goal is to return memory to the host while keeping the service available for later requests. Its practical benefit is memory availability, not a presumed reduction in compute-hour or storage charges. Record whether another model or caller may reload it, whether an active request would be interrupted, and who owns the running service. If the objective is lower recurring host cost, continue the analysis at the host and billing layers.

The command shown by the Ollama source is an application command; this article does not execute it. It is appropriate only after confirming that the target runtime and model name are correct and that interrupting this model is acceptable. For runtime choice and lifecycle boundaries, see the runtime comparison. Do not transfer an Ollama command assumption to another server such as llama.cpp or vLLM.

# Copyable operator template. Defaults stop here; do not run unchanged.
MODEL_NAME='REPLACE_WITH_EXACT_LOADED_MODEL'
I_HAVE_OWNER_APPROVAL_FOR_UNLOAD='REPLACE_WITH_yes_ONLY_AFTER_APPROVAL'
I_CONFIRMED_OTHER_CALLERS_MAY_RELOAD='REPLACE_WITH_yes_ONLY_AFTER_CONFIRMATION'

if [ "$MODEL_NAME" = 'REPLACE_WITH_EXACT_LOADED_MODEL' ] ||
   [ "$I_HAVE_OWNER_APPROVAL_FOR_UNLOAD" != 'yes' ] ||
   [ "$I_CONFIRMED_OTHER_CALLERS_MAY_RELOAD" != 'yes' ]; then
  printf '%s\n' 'STOP: set exact values and obtain both confirmations first.'
  exit 1
fi

# Before hand-off, verify the selected installed runtime's current help/docs
# and re-confirm the exact target and impact with its owner.
ollama stop "$MODEL_NAME"

This is a deliberately unexecuted operator template. The owner must independently verify the selected runtime and exact loaded model, obtain approval for the unload, and confirm that other callers may trigger a reload. If either confirmation or the runtime hand-off is missing, leave the gates unchanged and stop. The article does not execute commands or handle credentials.

Host poweroff or provider stop

A guest operating-system shutdown, a provider-console stop and a paused or suspended state may have different billing effects. A provider may continue charging for reserved compute, GPU, memory, IP address, boot disk, attached storage, backups or an independent service. Conversely, an exact offer may define a different billing boundary. Record the precise product, region, stop action, date and current terms rather than using “powered off” as a synonym for “free.”

The captured Vultr billing article says stopped instances continue to reserve CPU, RAM, SSD and IP resources and remain billable until destroyed. Its Cloud GPU FAQ likewise says its stopped GPU instance incurs the same charges as an active one. These are provider- and product-scoped examples, not a Contabo rule or a universal cloud policy. For a Contabo VPS or any other product, obtain current product-specific terms and a billing-page view before assigning a saved amount.

Record impact on availability, restart time, service startup order, attached data, public addressing, GPU allocation and recurring charges. Identify whether the host’s power state is controlled by the guest, a control panel or an automation schedule. A shutdown does not prove that an external subscription or detached resource ended. If the provider’s billing boundary is unclear, mark the amount UNKNOWN and pause the cost claim.

Destroy, delete artifacts, cancel subscription

Instance destruction is an infrastructure action. It can remove the machine and its local boot disk, but separate volumes, snapshots, backups, IP products and subscriptions may persist. Artifact deletion is a data action: the target could be a model file, a runtime image layer, an embedding/index copy, a source dataset, a credential or a recovery copy. Subscription cancellation is a commercial action, possibly with a notice period, renewal date or final invoice. Verify each object and confirmation independently.

The captured Vultr Cloud GPU destruction guide describes one especially important residue: when that instance boots from bootable Block Storage, destroying the instance leaves the volume in the account as an independent subscription that continues to incur charges until separately deleted. The same guide says recovery requires a snapshot or backup when instance data is removed. This is an example scoped to that product path, not a statement about all Vultr instances or any other provider.

Before any irreversible action, the operator should identify exact targets in the account, establish that recovery copies are usable and authorized, confirm the billing effect, and obtain explicit human approval. Never treat a broad cleanup operation as a substitute for object-by-object review. If a data owner, deletion authority, cancellation date or recoverability is missing, do not proceed.

Inventory what remains

Complete one row per independently stored or billed object. “On the server” is not a sufficient location: note the host path, named volume, provider resource, registry, external account or recovery destination. Keep state before and after distinct, and make the evidence column point to a dated console view, invoice line, inventory or owner confirmation. If you cannot see an object or confirm who controls it, mark its state and charge UNKNOWN.

Storage and recovery costs depend on the number and location of actual copies. A model in an Ollama store, a separate GGUF file, an image layer and a backup are not presumed duplicates that will be deduplicated or collected automatically. Likewise, a volume that appears detached may still be retained and billable. Verify the selected runtime’s storage layout and the provider’s resource list; do not infer garbage collection behavior from a source-code snapshot or from a different release.

For artifact identity, including revision, files and license, transfer the model row to the artifact and memory worksheet. For vector data, snapshots and restore quantities, use the Qdrant recovery guide. Keep detailed storage, transfer and recurring totals in the full cost worksheet; this page identifies exit-specific quantities without duplicating its total.

Calculate a targeted exit scenario

Select one intended action path at a time. Do not add mutually exclusive paths together. For the selected path, record current recurring charges that continue, charges that cease only after a verified event, one-time transfer costs, operator time, temporary capacity and the cost of validating the result. Use the account’s current product, region, currency, billing unit and renewal date. Unknown is not zero; leave unverified rows open rather than manufacturing a savings figure.

Keep the calculation small and traceable. For each selected recurring line, record quantity × verified unit price × applicable billing period. For one-time work, record the source and destination, expected bytes, rate or allowance, retry policy, elapsed operator time and who pays. Do not count a retained copy as both deleted and available for restore. Do not add a second host if the selected path is a same-host restart. Roll these quantities into Article 2 rather than creating a parallel “exit total.”

The Vultr stopped-instance and Cloud GPU captures show why separate columns matter: the named stopped state continues billing, and one named destroy path can leave bootable Block Storage with its own continuing charge. Contabo’s captured help page discusses traffic under a fair-use policy and product-specific port information; it does not establish that a particular reader’s repull is free or unlimited. Check current allowance, region, direction, rate and service terms for the actual account before pricing bytes. For contractual acceptance, termination and rights fields, see the terms and rights checklist.

Set an acceptance threshold before the change: maximum transfer volume, maximum wait, temporary free-space reserve, permitted downtime, acceptable restore duration and required integrity checks. These are workload-specific thresholds, not provider guarantees. If the plan exceeds a limit or its owner cannot confirm a charge, pause and ask for evidence before approval.

Repull and rebuild plan

A repull is not free inference. It consumes network transfer and time, writes data to a destination with finite free space, and may require authentication or license acceptance. A rebuild can also consume CPU/GPU time, dependencies, compilation or cache creation, and operator attention. A restore may require temporary room for both source and restored copies. Estimate each independently from the specific source and destination; do not assume deduplication, cache reuse, a free transfer allowance or automatic garbage collection.

Fill this worksheet before removing the last recoverable copy. Separate known values from estimates and unknowns; attach the evidence or owner for each. Size estimates refer to exact files and artifacts—not system RAM, VRAM, runtime buffers or a universal model multiplier.

Compute a bounded transfer estimate only when both quantity and rate basis are known: bytes ÷ observed or documented effective throughput gives an indicative transfer duration, not a completion promise. Add time for authentication, retries, unpacking, verification, index reconstruction, restore and runtime initialization. Record whether caches can be reused, must be rebuilt or are not understood; do not assume that a warm-up cache survives host deletion.

A captured Ollama issue asks maintainers to check usable disk space before model downloads and shows one reporter’s partial download ending in a no-space error. It is a feature request and an individual report, not proof of common failure or current product behavior. Use it only as a practical preflight prompt: inspect the actual destination filesystem, account for other writers and temporary copies, and stop if the free-space requirement is unknown. It does not establish an Ollama command or a universal required-space formula.

Before a repull, compare source identity, revision and license with the inventory, confirm that access is authorized, and verify the target location and free space. Decide whether to resume from an existing verified copy or fetch anew only after checking the chosen tool’s documented behavior. Keep download and checksum output free of credentials. After arrival, validate file identity, runtime compatibility and one representative task using the selected version’s documented procedure. Do not treat “download completed” as proof of a usable model or a restored service.

Safe exit checklist and evidence

Use this checklist as a human decision gate. It describes a review process; it does not perform a deletion, stop a host, cancel a service or verify an account. Capture evidence in an access-controlled change record and redact identifiers that are not needed by the reviewer. Never copy API keys, passwords, environment dumps or private model data into a general ticket.

1. Scope the request. Name each target object, provider/product, region, account owner, current state and desired state. Separate runtime unload, host stop, host destroy, file deletion and service cancellation into distinct decisions.
2. Assign authority. Identify the service owner, data owner, account payer, deletion approver and operator. Confirm that the person requesting an exit can authorize each data and commercial action.
3. Protect recovery. Identify an independent recovery copy, its location, retention and access owner. Confirm that the required model files, configuration, source data, Qdrant data and keys are recoverable under applicable rights. If restore capability is unproven, mark it unverified and retain the source.
4. Record the baseline. Save dated, redacted evidence of instance state, attached and detached storage, snapshots/backups, model and container locations, external subscriptions, billing lines, renewal/cancellation dates and selected service health. Do not infer a complete inventory from one screen.
5. Reconcile money and transfer. Link every expected recurring and one-time item to a current product term, account page, invoice or written support answer. Record byte quantity, direction, allowance, rate and the payer. Leave unknown terms open.
6. Review the exact action. Read the current procedure for the selected product and resource identifier. Confirm what the action removes, preserves, bills and makes unrecoverable. Review neighboring resources before approval; do not rely on similarly named buttons or broad clean-up commands.
7. Obtain explicit approval. The human approver signs off on the exact target, expected service interruption, retained resources, deletion scope, recovery route and cost uncertainty. Stop if any item is ambiguous or outside the approved request.
8. Operator performs one scoped transition. Use the selected provider/runtime’s documented control. Capture the confirmation and resulting state before considering another object. This article supplies no destructive command and makes no claim that an action has been performed.
9. Verify result and residue. Re-open the inventory and compare object IDs, attachment/state, retained data, remaining billing and service availability with the approved plan. Verify absence only for the selected object, and verify that unrelated services still operate or are deliberately retired.
10. Close the record. Record actual effective dates, final charges still pending, cancellation receipts, repull/rebuild evidence, reviewer and follow-up owner. Keep access to recovery material until the designated owner accepts the exit.

Stop immediately if the recovery copy is missing, a data owner has not approved deletion, a detached volume or backup has an unknown payer, the cancellation effective date is unclear, the transfer allowance is unresolved, or the observed account state differs from the approved plan. Resolve that specific question with the account owner or provider before continuing.

The selected provider’s rules can change, and this draft cannot observe your account or confirm live prices. The captured sources provide bounded evidence: Ollama’s FAQ describes model unload; Vultr’s captured billing pages describe selected stopped/destroyed states; Contabo’s captured terms and traffic help page apply only within their stated product and policy scope. They do not establish universal stop savings, free repulls, cross-runtime deduplication, cache deletion, or garbage collection.

For a complete cost roll-up, use Article 2; return to the Local AI decision hub for the wider workload chain. Source capture(s) checked 2026-11-06. Primary sources and their roles:

• Ollama FAQ — runtime model unload and configuration context; selected-version behavior should be rechecked.
• Ollama command source at captured commit — lineage only; not a universal garbage-collection claim.
• Vultr: Are stopped instances still billed? — provider-specific stopped-instance billing capture; verify current product terms.
• Vultr: Destroy a Cloud GPU instance — product-scoped retained bootable Block Storage example.
• Vultr Cloud GPU FAQ — captured stopped-state billing answer for that product.
• Contabo Terms and Conditions — captured contract context; review current terms and exact service before acting.
• Contabo bandwidth and traffic guidance — captured fair-use and product-specific traffic context; not a free repull promise.
• Ollama issue: check usable disk before download — one open feature request and reporter example; a preflight prompt, not prevalence evidence.
• Vultr Use Policy — limited excerpt captured 2026-11-06; consult current policy for exact scope.

For site scope, methods and source handling, see Methodology. This article is a planning worksheet; no host, account, data, billing control, restore or cancellation was operated or tested while drafting.