GPU Cloud Providers 2026: Runpod, Lambda, CoreWeave, Vast.ai, Modal, Together AI and Google Cloud

Choose GPU cloud providers by the job: Runpod for hands-on fine-tuning, Modal for custom serverless inference, Together AI for a managed model API, and Vast.ai for restartable marketplace work. These 7 providers also include Lambda for GPU virtual machines, CoreWeave for planned cluster capacity, and Google Cloud when your application already depends on its infrastructure. The decision starts with model memory and paid running time, not the lowest advertised GPU rate.

Pricing and product documentation verified on 30 October 2026. Prices below are USD amounts displayed on each maker's own pricing page that day. This is a documentation-based comparison, not a hands-on performance benchmark. Availability, taxes and the final deployment configuration can change what you pay.

Best GPU Cloud Providers by Job

Runpod is the first shortlist for a builder who wants to fine-tune a model directly; Modal and Together AI are the first shortlists for serving it without maintaining a permanent GPU machine. The right choice changes when you need a particular region, continuous capacity or a recovery-friendly batch environment.

Cloud GPU Pricing Comparison: Read the Unit Before the Number

Each starting rate names its product and hardware. These are entry points into different services, not equivalent performance offers. A GPU-only attachment excludes its host virtual machine; a serverless GPU-second excludes separately metered resources; a dedicated inference rate is not a token API price.

A marketplace offer can disappear, and the cheapest listed device may be too small for your model. The trial column describes the checked public offer, not every negotiated credit program. Together AI requires prepaid access; Google's GPU restriction is explicit in its Free Trial terms.

Serverless Inference: Custom Code or a Model API

Choose whether you need to own the model runtime before choosing a GPU. Inference means using a trained model to produce an answer. A managed API lets you request that answer; custom serverless compute lets you supply the code that produces it. That distinction matters more than whether both products use the word “serverless.”

1. Modal: Best for Custom Python Inference With Uneven Traffic

Modal is a serverless compute platform for containerized applications deployed through Python, and it fits a builder whose model-serving code is part of the product. A document-processing service, for example, might need custom preprocessing, a model call and postprocessing in the same deployment. Modal lets that application scale with demand, but its paid lifetime includes initialization and warm idle time, not just the useful model calculation. Pick Modal when you want to own the runtime without owning a permanently running VM.

Best for: Python teams deploying custom inference or queued GPU jobs with variable demand.
Standout: Application-level deployment and automatic scaling, with separately metered compute resources.
Pricing: GPU compute starts at $0.000164/second for a T4, plus CPU and memory, verified 30 October 2026 on Modal's pricing page.
Free trial: Starter includes $30/month in compute credits; token-based Shared Endpoints are outside that allowance.

The practical wall is latency after a quiet period. A cold start is the work needed to prepare a new container before it can answer. Starting the container, importing libraries and loading model weights are different stages. A fast container boot does not mean your model is immediately ready.

Modal exposes controls for keeping containers warm and maintaining spare capacity. Those controls can improve responsiveness, but they also keep resources allocated. For a customer-facing assistant, test the first request after inactivity as well as requests sent during a busy session. For an overnight extraction queue, waiting for initialization may be acceptable. Modal's cold-start guide explains the tradeoff.

The Starter plan also has a concrete scaling boundary: 3 workspace seats and 10 concurrent GPUs. That is enough to make a useful pilot, but a burst of independent workers can reach the concurrency limit before monthly spend looks large. Persistent volumes and network egress have included allowances and separate charges beyond them, so include the data path in your estimate.

Geography is another configuration decision. Modal distinguishes the region running your container from the region routing its requests. Region pinning also carries a pricing multiplier. A model running near your database is useful only if the request path meets your latency and residency requirements too. Region selection documentation describes both controls.

2. Together AI: Best When the Deliverable Is a Model Endpoint

Together AI is a managed inference and training platform, and it fits teams that want to ship a model-backed feature before managing GPU infrastructure. Its serverless API is the natural starting point when the required model is in the catalog; dedicated inference adds control over serving hardware. The boundary is customization: a supported model API is a different product from running your own arbitrary training environment. Choose Together AI when the endpoint is the product you need, then buy dedicated capacity only when traffic or control requirements justify it.

Best for: Teams serving supported models or using managed fine-tuning and dedicated inference.
Standout: A path from a token-billed API to dedicated model serving.
Pricing: Dedicated NVIDIA HGX H100 inference starts at $5.49/GPU-hour; serverless API rates depend on the model, verified 30 October 2026 on Together AI's pricing page.
Free trial: No free trial; purchased prepaid credits are required.

Keep the billing models separate. Serverless language inference charges for input and output tokens, the pieces of text a model processes. Dedicated inference charges by the minute for each ready replica, a running copy of your model service. Its documentation excludes provisioning and cold-start time from dedicated compute billing, but a ready replica continues to cost money even if it receives few requests. Scaling to zero stops that compute charge. Dedicated inference billing defines the boundary.

For a support application with sporadic conversations, serverless avoids purchasing idle model capacity. For a busy application with an established traffic pattern, dedicated replicas deserve a comparison using the same prompts and response lengths. Do not switch merely because a per-GPU rate looks lower: you need measured throughput to translate it into cost per completed answer.

Managed fine-tuning also needs its own estimate. Together lists adapter-based LoRA and full fine-tuning, with token-based charges that account for training passes and evaluation. An epoch is one pass through the training dataset. Repeating the dataset increases processed tokens; the uploaded file's size alone is not the bill.

The GPU cluster product is separate again. It offers on-demand and reserved capacity, with persistent storage billed independently. Cluster reservations are prepaid and nonrefundable; deleting a cluster does not automatically make every retained volume free. Its cluster docs state that ingress and egress are uncharged. Those rules should not be assumed to describe every API product. Cluster billing documentation supplies the detail.

For serving, verify the model and region together. Select serverless models support US-specific inference, while other regional requirements point toward dedicated endpoints. Shared API response times can vary with demand, and applications still need retry handling. Serverless documentation makes those limits explicit.

On-Demand Pods and VMs for Fine-Tuning

Rent an environment you control when you are still changing the training script, dependencies or model. Fine-tuning adapts an existing model using your data. A Pod or virtual machine gives you room to inspect failures and rerun the job; it also leaves you responsible for stopping compute and preserving the results.

3. Runpod: Best First Stop for Hands-On Fine-Tuning

Runpod provides dedicated GPU Pods alongside Serverless and cluster products, making it a practical first shortlist for a small team developing its own model workflow. A builder can choose a GPU and container template, work through a fine-tuning run, and later evaluate a separate Serverless deployment for inference. The limits are tangible: Community Cloud reliability varies by host, persistent storage has a lifecycle of its own, and a stopped Pod does not guarantee the same GPU will be available when resumed. Runpod earns its place through control and flexible deployment choices, not through a promise that every workload will be cheapest there.

Best for: Builders who need a GPU container for experiments, adapter fine-tuning and custom inference development.
Standout: Separate Pod and Serverless products for development and serving stages.
Pricing: The live page lists RTX A5000 Pods with 24 GB VRAM from $0.27/hour, verified 30 October 2026 on Runpod's pricing page.
Free trial: No free GPU trial was listed on the pricing page checked.

Start with memory, not the most impressive chip name. Runpod lists 24 GB cards, 48 GB options such as the A40 and RTX A6000, and 80 GB A100 and H100 variants. That gives a small team several memory classes to evaluate without immediately designing a cluster. It does not establish a throughput ranking: an inference engine, model precision and batch configuration can change which card is the better purchase.

Secure Cloud and Community Cloud are also different decisions. Runpod describes Secure Cloud as data-center infrastructure and Community Cloud as peer-to-peer supply with variable reliability. A replaceable experiment can tolerate a different failure profile from a service carrying customer requests. Choose the pool against the recovery and support requirements of the job. Runpod's Pod selection guide describes the distinction.

Storage is the limit most likely to surprise a first deployment. The container disk is temporary. A volume disk survives stopping but not deleting the Pod. A network volume persists independently, but is available for Pods on Secure Cloud and ties your choice of hardware to its location. Keeping checkpoints only on temporary storage defeats the point of saving them. Network volume documentation explains the placement constraint.

Pods bill compute by the second and have no ingress or egress fees under the checked Pod pricing rules. Stopped storage can still accrue charges. Serverless uses a different lifecycle: workers incur charges during initialization, execution and idle waiting until they stop. Flex workers can scale to zero; Active workers stay running. These are choices about paid residency, not merely different labels on the same hourly rate. See Pod billing and Serverless billing.

For the full rate and storage worksheet, use the site's Runpod pricing guide. Use that worksheet to model repeated runs and always-on serving.

1. 1

   Define the job before deploying

   Write down the exact model checkpoint, inference or fine-tuning mode, precision, maximum input length and expected concurrency. Choose a GPU memory class with room for the runtime, not just the model file.

2. 2

   Choose the storage location first

   If the job needs a network volume, create or select it in the intended data center before choosing the GPU. Confirm that suitable GPU capacity is available there. Keep a separate copy of irreplaceable training data and checkpoints.

3. 3

   Deploy a compatible template

   In Pods, select the GPU, choose the container template, set the GPU count and deploy on demand. Check the host CUDA compatibility filter against the template. CUDA is the software platform many NVIDIA GPU applications depend on.

4. 4

   Run a small rehearsal and confirm the exit

   Exercise the same loading, training and checkpoint-writing path as the intended job. Record peak GPU memory and elapsed time. Confirm the checkpoint exists on persistent storage before stopping or terminating compute, then inspect remaining storage charges.

These deployment controls are documented in Manage Pods. Treat the rehearsal as a recovery test too: the next launch should be able to continue without relying on a particular previous machine.

4. Lambda: Best for a Familiar GPU Virtual Machine

Lambda is a GPU cloud with Linux virtual machines and reserved cluster offerings, and it fits teams that want a conventional machine for a sustained training session. Its environments include NVIDIA tooling, while the instance catalog spans single-GPU configurations and larger allocations. The buying limit is the allocation itself: the same GPU can have a different per-GPU rate depending on how many you rent. Choose Lambda for a controlled training environment, and read the GPU-count selector before treating a rate as your invoice.

Best for: Training and fine-tuning teams that prefer SSH access to a GPU VM.
Standout: Single-GPU instances and a separate reserved-cluster path.
Pricing: Single-GPU Instances start at $0.69/GPU-hour for a Quadro RTX 6000 with 24 GB VRAM, verified 30 October 2026 on Lambda's pricing page.
Free trial: No free GPU trial was listed on the pricing page checked.

The GPU catalog includes the A6000 with 48 GB and H100 PCIe and SXM variants with 80 GB. Those names matter. “RTX 6000,” “A6000” and newer similarly named cards are not interchangeable purchases. Specify the full GPU name and memory in your deployment notes so a future rerun does not silently use a different device.

Lambda's on-demand compute is priced hourly but billed in one-minute increments, from healthy launch until termination. A machine that is running but doing no work still bills. For a training job, arrange the shutdown procedure around the provider's termination lifecycle rather than assuming that the end of the Python process ends the rental. Lambda's billing documentation describes the meter.

Persistent filesystems add another planning step: they must be attached during instance creation and reside in the same region as the instance. They continue billing while they exist, even when unmounted; the billing documentation says filesystem ingress and egress are uncharged. Confirm the GPU and filesystem can coexist in the desired location before staging a large dataset. Lambda's instance documentation lists the regional and storage rules.

The reserved-cluster option is a different scale of purchase. The public 1-Click Cluster table starts at 16 GPUs and a two-week term. That may suit a concentrated training campaign, but it is a poor starting point for a builder still finding out whether a single-device adaptation will solve the problem. Start with the smallest workable experiment and expand only after it establishes the required throughput.

Marketplace and Interruptible GPUs

Buy interruption risk only after proving that your job can recover. A marketplace combines offers from different hosts. An interruptible instance can be paused or reclaimed. These concepts overlap, but an on-demand marketplace rental is not automatically an interruptible rental.

5. Vast.ai: Best for Restartable Jobs With Flexible Placement

Vast.ai is a GPU marketplace where hosts set prices, making it useful for a builder who can inspect the offer and tolerate a changing supply of machines. A batch embedding job or repeatable fine-tuning experiment can fit well if its inputs and checkpoints survive the instance. The wall is host-specific economics: compute, storage and both directions of data transfer can have separate charges. Choose Vast.ai when you can engineer around the offer, rather than needing every offer to behave identically.

Best for: Cost-sensitive experiments, batch jobs and training that can resume from checkpoints.
Standout: Host-level choice across on-demand, reserved and interruptible rentals.
Pricing: Host-set GPU rates billed per second, plus storage and transfer; check the starting offer for your configuration on Vast.ai's live pricing page, reviewed 30 October 2026.
Free trial: No free GPU trial was listed on the pricing page checked.

The cheapest listing is useful only if its hardware fits the job. Vast.ai's live catalog lists 24 GB RTX 3090 and RTX 4090 cards, 48 GB L40S, and 80 GB H100 SXM. Filter for the memory and software your job needs first. Then compare the specific host's CPU, system memory, storage, transfer terms and location.

Compute is metered by the second while running. Storage remains billable while the instance exists, including when stopped. Upload and download charges vary by host. A cheap GPU that repeatedly downloads a large model or dataset can therefore be a poor purchase for a short job. Keep the whole data path in the comparison, not just the graphics card. Vast.ai's pricing documentation explains these components.

For an interruptible training run, a saved model file alone may not be enough to resume accurately. Preserve the state your training framework needs and prove the restart path before relying on it. For a batch queue, assign stable job identifiers so retrying work does not duplicate customer-visible results. These are acceptance criteria for choosing interruptible capacity, not claims that the provider performs recovery for you.

Vast.ai also offers serverless infrastructure. Its existence does not erase the underlying host and data-cost questions: the checked documentation describes serverless billing through the instance's compute, storage and bandwidth costs. This shortlist emphasizes marketplace rentals because that is the clearest fit for a small team willing to manage those tradeoffs.

Reserved Clusters and Existing Cloud Infrastructure

Reserve capacity after measuring steady demand; stay near existing infrastructure when moving the workload would create more work than it saves. These are different reasons to choose a larger platform. A small team can have either reason without becoming a hyperscaler-scale buyer.

6. CoreWeave: Best for a Defined Cluster Requirement

CoreWeave is an AI infrastructure cloud with managed Kubernetes on bare-metal GPU nodes, and it fits a team that has progressed from an experiment to a planned compute requirement. Kubernetes coordinates containers across machines; it is useful when the deployment needs that orchestration and someone owns it. The small-team limit is allocation and operations: a node-level purchase and a managed cluster still require a clear workload, storage plan and operator. Shortlist CoreWeave when capacity planning is a real requirement, not as the default place to discover your model's needs.

Best for: Teams with known cluster demand and the ability to operate a Kubernetes workload.
Standout: Managed Kubernetes on bare-metal nodes with cluster networking and isolation.
Pricing: The North America table lists a single-GPU GH200 instance at $6.50/hour; reserved capacity requires a quote, verified 30 October 2026 on CoreWeave's pricing page.
Free trial: No free GPU trial was listed on the pricing page checked.

Read CoreWeave's columns with care. Several published GPU instances contain 8 GPUs, including H100, H200, A100, L40 and L40S rows. The page separately shows single-GPU inference prices, and its footnote restricts that pricing to inference-platform customers. Dividing a node price by its GPU count is useful accounting, but it does not prove that you can rent one fraction of that node for an ordinary cluster job.

The price page separates North America and Europe and lists on-demand, spot and reserved options. For a reservation, ask for the exact node configuration, deployment location, commitment window and capacity terms. Also confirm billing granularity in the quote: a public hourly unit alone does not establish second-by-second metering.

CoreWeave lists internet and internal data transfer as free, while storage and public IP services have their own charges. That makes a workload with substantial data movement worth examining, but the compute commitment still needs to be useful. Cheap transfer cannot compensate for a cluster that spends most of its reservation idle.

CoreWeave Kubernetes Service documentation describes the managed control plane, bare-metal nodes, private networks and GPU networking. For a small AI team, the decisive question is ownership: who will package jobs, watch failures, manage secrets and restore service? If the answer is the same person still validating the application, a simpler Pod or API may produce a working feature sooner.

7. Google Cloud: Best When the Workload Belongs Beside Your Existing App

Google Cloud offers GPU-backed Compute Engine virtual machines, making it a sensible shortlist when your application and data already live there. Keeping model execution near the rest of the system can simplify the deployment decision, even if a specialist cloud has an attractive GPU quote. Its wall is access: the machine type, region, quota and physical availability all have to line up. Choose Google Cloud for a workload that benefits from its location and existing operating setup, rather than assuming its entry GPU price is a complete server price.

Best for: Builders adding GPU work to an application already operated on Google Cloud.
Standout: GPU machine families with explicit regional availability and quota controls.
Pricing: A T4 attachment in Iowa starts at $0.35/hour for the GPU alone, plus the VM, verified 30 October 2026 on Google's accelerator pricing page.
Free trial: GPUs cannot be added during the Free Trial; a paid-account upgrade is required.

Google Cloud GPU Pricing: The VM Still Counts

A GPU attachment is an additional resource, not an entire machine. The quoted T4 has 16 GB of GPU memory. An application that needs more memory or a different accelerator should select another configuration rather than build a budget around that entry rate.

Google also lists integrated GPU machine families, including G2 with L4, A2 with A100 variants, and A3 variants using H100 or H200. An integrated machine price and an attached-GPU price have different scopes. Keep the chosen machine type in the estimate alongside storage and network charges.

Compute Engine charges per second after a minimum of one minute. A running idle VM still bills. Reservations can also bill while resources are not started, so reserving availability is not the same decision as launching a job. The Compute Engine billing rules describe these boundaries.

Google Cloud GPU Availability: Quota Is Only One Gate

A published GPU type is not a promise that your account can launch it in the preferred zone today. Google documents GPU support by zone, and quota controls operate separately from underlying capacity. Check the intended machine in the GPU regions and zones list, then confirm the necessary GPU quotas.

For example, a team serving customers near its existing database should identify acceptable nearby locations before requesting a GPU configuration. If the desired zone lacks capacity, moving only the model server farther away can change both response time and the data-transfer path. Treat that fallback as an application change that needs a test.

The Free Trial has a separate restriction: it does not allow adding GPUs or requesting quota increases. Google's ongoing Free Tier also excludes GPUs. A welcome credit headline is therefore insufficient evidence that a new account can immediately start a GPU experiment. Google's own terms are the rule to follow.

How to Choose a GPU Cloud for AI

Eliminate hardware that cannot fit the workload before comparing providers that offer it. GPU memory, often called VRAM, holds the model and the state needed to run it. A model that barely loads can still fail when a longer prompt or another simultaneous request arrives.

Start with a weight-only estimate. At 16 bits, each parameter takes 2 bytes; at 4 bits, the raw weight takes half a byte. An 8-billion-parameter model therefore has about 16 GB of 16-bit weights or 4 GB of raw 4-bit weights. A 32-billion-parameter model gives 64 GB or 16 GB; a 70-billion-parameter model gives 140 GB or 35 GB. These are our decimal-GB calculations, not measured serving requirements. Runpod's sizing guide provides the underlying memory rule.

The missing space matters. The inference runtime needs working memory, and the KV cache stores attention state as generation proceeds. Context length and simultaneous requests change that state. A “35 GB model” does not make a 35 GB deployment budget. Hugging Face's cache documentation explains why the cache is a separate memory decision.

Use 24 GB, 48 GB and 80 GB cards as evaluation buckets, not guarantees. A small quantized model may leave useful room on a 24 GB device. A larger model, longer context or more concurrent requests can push you into another class. Keep an explicit margin for the highest observed memory use rather than sizing from the smallest successful request.

Fine-tuning changes the problem. Full training adds gradients, optimizer state and saved activations. Adapter-based methods update a smaller subset of parameters, which can reduce requirements, but they do not remove every memory cost. A successful inference run is not proof that full fine-tuning will fit on the same card. See the training memory breakdown and parameter-efficient fine-tuning overview.

Then inspect the GPU variant and software compatibility. A provider listing H100 does not establish that every H100 offer has the same form factor, memory configuration, CPU allocation or interconnect. Multiple GPUs also need a framework that can divide the work effectively; buying more cards is not an automatic solution to a slow or oversized job.

Finish with the paid lifecycle. For each finalist, distinguish compute startup, useful work, warm waiting, termination and retained storage. Estimate a month using your expected schedule, including idle periods and retries. A continuously allocated machine and a short daily batch need different budgets even if the displayed hourly rate is identical.

Who Should Pick What

The rule that flips the choice is whether you need runtime control, then whether keeping that runtime warm is useful. If a supported API delivers the feature, start by evaluating Together AI. If your own inference code is essential and traffic is uneven, compare Modal with Runpod Serverless. If you need an interactive environment or a sustained fine-tuning run, start with Runpod Pods and Lambda instances.

For a restartable batch job with flexible placement, add Vast.ai. For a known cluster workload with an owner for operations, add CoreWeave. If the application already depends on a particular Google Cloud location and operating setup, evaluate its GPU capacity before paying the migration cost to another provider.

Reserved capacity becomes sensible when you know the hardware stays useful over the commitment window and availability itself matters. Do not reserve to discover utilization. Run the workload first, establish the demand that persists during quiet periods, and reserve only the capacity justified by that baseline.

A latency-sensitive service can also prefer dedicated or warm capacity at relatively low request volume. A customer waiting after every quiet interval may be more costly than an idle worker. Measure the first response after inactivity and the slowest responses during bursts; an average latency can hide both failures.

If you are still deciding whether to own a GPU runtime at all, the inference chips versus GPUs guide explains the broader hardware-control choice.

How These Were Picked

The criteria are workload fit, a verifiable buying unit, memory suitability, data costs, startup behavior and regional access. The seven providers cover managed model APIs, custom serverless applications, direct GPU rentals, marketplaces and planned clusters. Placement is a recommendation for a job, not a universal speed ranking.

Pricing and capability claims were checked against maker pages on 30 October 2026. No GPUs were rented and no throughput or uptime tests were performed for this comparison. The weight estimates are explicit arithmetic; the platform recommendations are analysis of documented behavior.

The shortlist stays focused on a builder or small AI team. Broader cloud directories, procurement brokers and additional hyperscalers would add names without replacing the first decision: whether you need a model endpoint, a machine or a cluster. A provider belongs in the final evaluation only if it can supply the required configuration where you can use it.

The Ones to Avoid

Avoid the wrong purchasing model for your workload, even when the vendor itself is a good fit elsewhere.

• Vast.ai interruptible capacity for a job that cannot resume or safely retry. Prove recovery before buying interruption risk.
• Runpod Community Cloud when your plan depends on attaching a Runpod network volume. That storage option is for Secure Cloud Pods.
• Modal scaled to zero when every first response must meet a tight latency target and you have not measured initialization. Budget warm capacity or change the deployment.
• Lambda 1-Click Clusters or a CoreWeave reservation while the useful GPU count and workload duration are still guesses. Establish demand with a smaller rental first.
• Together AI serverless when the required checkpoint or runtime behavior is outside the supported API product. Evaluate its dedicated products or a programmable GPU environment instead.
• Google Cloud's unupgraded Free Trial as a plan for immediate GPU access. Its GPU restrictions are explicit.

GPU Cloud Questions

Gpu cloud providers list

The seven providers compared here are Runpod, Lambda, CoreWeave, Vast.ai, Modal, Together AI and Google Cloud. Start with the product category you need: a managed model API, custom serverless compute, an on-demand machine, a marketplace rental or reserved cluster capacity. The provider sections explain where those categories overlap.

Free cloud GPU

Modal's Starter plan includes limited monthly compute credits, not unlimited GPU access, and its Shared Endpoint token charges are separate. Google's Free Trial blocks GPU attachments until a paid-account upgrade, while the ongoing Free Tier excludes GPUs. Together AI explicitly requires prepaid access. Treat credits as a way to evaluate a workload, not a production capacity plan.

Cloud GPU comparison

Compare the same checkpoint, precision, input lengths and concurrency on the exact GPU variant and allocation size. Include paid startup and idle time, storage, transfers and failed work. The useful result is the cost of completed work that meets your latency and recovery requirements, not the smallest number next to “GPU-hour.”

Next week, give two finalists the same small workload and acceptance criteria. Record peak memory, time to the first useful result, completed-job throughput, billed resource lifetime and the cost left behind after stopping. For training, rehearse recovery from a saved checkpoint; for serving, exercise a request after inactivity and a burst. Expand the deployment only after that evidence supports it.

Get the AI Business Workflow Audit Checklist and the operator newsletter.