RunPod vs Salad for Self-Hosted LLM Hosting

Compare RunPod and Vast.ai billing and storage controls, while identifying what current Salad documentation must settle before comparison.

For a self hosted llm, RunPod documents per-second compute and storage charges and no data ingress/egress fees in its billing overview. Stopping a Pod preserves /workspace according to the storage options guide, while stopped storage remains billable under the Pods pricing documentation. Salad's billing, GPU access, persistence, and interruption rules are not verified here, so there is no defensible Salad winner; the separately documented Vast.ai marketplace model provides context, not Salad terms.

RunPod: Separate Usage, Commitment, and Interruption

Treat RunPod's deployment choice as three separate decisions. On-demand is pay-as-you-go and its resources cannot be displaced by other users, but deploying one requires a balance covering at least one hour of the selected configuration, according to the Pods pricing documentation. A savings plan is a 3- or 6-month upfront commitment, is non-refundable, and has a fixed expiration date; after a Pod stops, the plan applies to the next deployment of the same GPU type. Record the term, expiration date, and GPU restriction before committing.

The API adds an interruption choice. The interruptible boolean defaults to false. Set it to true for a lower-cost spot Pod that can be stopped at any time; with false, the documented reserved Pod runs until it exits or you stop it, as described in the Create a Pod API reference.

{
  "interruptible": false
}

Build an estimate from the line items on your current bill or quote:

RUNPOD_TOTAL = YOUR_COMPUTE_CHARGE + YOUR_STORAGE_CHARGE

Fill each placeholder from your own billing record rather than inserting a rate from this article.

Prepare a self hosted llm workload

Before choosing a GPU, record the model's parameter count, intended serving runtime, context requirement, artifact location, exposed port, acceptable downtime, and backup destination. These are workload decisions rather than provider features.

RunPod's Pod selection guide gives a sizing rule of thumb of approximately 2 GB of VRAM per billion parameters. Use that only as an initial screen; verify the final memory requirement against the model and serving runtime you actually intend to operate.

A RunPod template can bundle the container image, disk sizes and mount paths, exposed ports, environment variables, and startup commands, as described in the template overview. This can reduce assembly work, but it does not change where each storage type keeps data or how interruptions affect the running process.

Deploy and Check RunPod Access

The Manage Pods guide gives this console order: choose the GPU type, name the Pod, optionally choose a template, set the GPU count, and click Deploy On-Demand. It also documents these CLI and REST creation paths:

runpodctl pod create --name YOUR_VALUE --gpu-id "YOUR_VALUE" --image "YOUR_VALUE"

curl --request POST \
  --url https://rest.runpod.io/v1/pods \
  --header 'Authorization: Bearer YOUR_VALUE'

The REST example establishes the documented method, endpoint, and authorization header. Use the current request schema for all required body fields rather than inventing values.

Pod creation does not by itself verify model serving. Confirm that a GPU is attached, start the application using its own documentation, and query that application's documented health endpoint. Do not assume that the GPU provider defines a universal model endpoint.

Every Pod includes proxied basic SSH, but that connection does not support SCP or SFTP. Full file-transfer capabilities require a Pod with a public IP and an SSH daemon running inside it, according to RunPod's SSH documentation. The browser terminal is intended for quick access rather than long-running processes, as noted in its connection options.

Storage Lifecycle and Common Failures

Container disk: This is temporary storage and is cleared when the Pod stops. The /workspace volume disk survives stops and restarts but is deleted when the Pod is terminated. RunPod also says its storage is not intended for long-term cloud storage and recommends external backups; see the storage options.
Network volume: It exists independently of a Pod and survives Pod deletion. It must be attached when the Pod is created, cannot be detached later, and replaces the volume disk at /workspace, according to the network volume documentation.
Stopped or exhausted Pods: Storage charges continue on stopped Pods. If the account balance is exhausted, running Pods stop; Pods without a network volume are terminated and their data cannot be recovered, as described in the RunPod billing overview.
Unpaid network storage: Network-volume storage remains billable while Pods are stopped. If those charges cannot be covered, the volume may eventually be terminated and its data cannot be recovered; see the same network volume guidance.
OCI runtime create failed: At deployment, use Additional filters → CUDA Versions to select compatible machines. This is the documented response in the Pod management guide.
Zero GPUs after restart: Stopping releases the specific GPU while the stopped Pod remains associated with its physical machine. Another user may rent that GPU, so a restart can find none available; the zero-GPU troubleshooting guide explains the allocation behavior.

Salad: Obtain the Missing Decision Facts

Do not use Vast.ai terms as a substitute for Salad documentation. Before treating the title as a provider-to-provider verdict, obtain Salad's current official page or quote and record:

Available GPU types and whether resources are dedicated, interruptible, or subject to another availability rule.
Every compute, storage, network, minimum, commitment, and cancellation line.
What survives a stop, interruption, restart, or deletion, and where backups must be placed.
The supported image, deployment command or configuration, exposed port, and application endpoint.
Commitment, cancellation, refund, SLA, support, and data-handling terms.

If the quote itemizes charges, use:

SALAD_TOTAL = SUM(YOUR_QUOTE_LINE_ITEMS)

Copy every recurring and one-time line into the same units and billing period. Leave an undocumented item as unknown rather than treating it as zero. Until Salad publishes the relevant details, an exact command, endpoint, availability promise, or all-in cost would be unsupported.

Vast.ai: A Documented Marketplace Comparison

Vast.ai's Concepts page describes a marketplace where hosts set their own prices. Its host range extends from individuals with a single gaming PC to Tier-4 datacenters, and hosts also set their reliability expectations and verification level.

The instance pricing guide says the total combines GPU compute, storage, and bandwidth, with actual usage billed by second. Upload and download traffic are charged per byte at host-specific rates, while storage continues billing for as long as the instance exists; deleting the instance stops that storage charge.

VAST_TOTAL =
  YOUR_GPU_COMPUTE_CHARGE
+ YOUR_STORAGE_CHARGE
+ YOUR_BANDWIDTH_CHARGE

For a quote with separate transfer rates, calculate bandwidth as:

YOUR_BANDWIDTH_CHARGE =
  (YOUR_UPLOAD_BYTES × YOUR_HOST_UPLOAD_RATE)
+ (YOUR_DOWNLOAD_BYTES × YOUR_HOST_DOWNLOAD_RATE)

The instance type documentation distinguishes on-demand instances with fixed pricing and guaranteed high-priority resources, reserved instances with discounted prepayment and high priority, and interruptible instances with the lowest cost that may be paused. An instance's type generally cannot change after rental, except that an on-demand instance can be converted to reserved.

An interruptible renter sets a bid, and a higher bid can stop the instance and kill its processes, according to the Rental Types FAQ. A paused interruptible instance preserves its data but is not functional and resumes automatically when priority returns. On-demand offers also have a maximum rental duration, and an expired instance may be deleted 48 hours after expiration, so the current instance terms should be checked before retaining data there.

Make the Decision in a Fixed Order

Compare the providers by answering these questions in sequence:

Can the workload tolerate a stopped GPU or killed inference process?
Which data survives each stop or termination state, and where is it backed up?
What do the provider's compute, storage, transfer, and commitment charges add up to?
Which documented image, port, and endpoint will serve the model?
What are the cancellation, refund, SLA, and support boundaries?

RunPod has documented answers to several of these operational questions, but a true RunPod-versus-Salad comparison remains incomplete until Salad supplies equivalent current documentation. These steps are compiled from the official documentation linked in the text; no commands were run for this article, and the current version should be checked before use.