Best serverless GPU providers in 2026

Serverless GPU providers handle infrastructure provisioning so you can focus on the workload: a model endpoint, an image-generation worker, a batch process, or another GPU application. But “serverless” does not describe one runtime or billing model.

Some platforms create workers in response to queued requests and scale to zero. Others operate managed GPU services that you size and scale. This comparison covers both approaches and makes those differences explicit, so a low hourly rate does not hide startup charges, idle capacity, or a runtime mismatch.

A serverless GPU provider operates the underlying GPU infrastructure while exposing a higher-level way to run code or serve models. You configure the workload rather than installing and maintaining the physical server.

Three common execution models matter:

• Functions and workers: Requests or queued jobs trigger GPU execution. Worker lifecycle and concurrency determine cost and latency.
• Model endpoints: You deploy a model behind an API, then configure its hardware and scaling behaviour.
• Managed GPU containers: You deploy your own serving process or job and control its resources, storage, and lifecycle through the platform.

Scale-to-zero means the active worker or replica count can reach zero. It does not guarantee an instant response to the next request, zero storage charges, or billing only for the time the GPU is doing useful computation.

Compare the execution model before comparing the price. The examples below use H100 offerings where available, but their included resources and billing behaviour differ.

Prices are in USD, checked on 16 October 2026. These are examples, not equivalent complete deployments or a cheapest-to-most-expensive ranking. GPU variants, region, capacity, supporting resources, storage, and warm-worker settings can change the result.

Runpod's entry is for Serverless workers, not Secure Cloud or Community Cloud Pods.

These six GPU cloud providers address different deployment preferences. Start with the runtime and scaling behaviour your application needs, then test the relevant pricing model.

Northflank runs GPU inference services, training workloads, and batch jobs from container images. You can configure the model server, allocate GPU and host resources, attach storage, and expose a protected endpoint without building your own Kubernetes deployment system.

Capabilities include:

• GPU-enabled services for model APIs and jobs for finite processing or training.
• Custom container images and runtime commands for your chosen framework.
• Persistent storage, secrets, private networking, logs, and metrics.
• Service autoscaling using CPU, memory, request, or custom metrics.

Why choose it: Northflank gives you control over the GPU workload's runtime and deployment rather than requiring a particular model API or function interface. That is useful for a single inference service as well as teams operating several models with different resource requirements.

You can use Northflank's managed cloud or bring your own cloud (BYOC), where Northflank acts as the control plane, managing Kubernetes and GPU workloads inside your cloud account and VPC. Hardware availability depends on the deployment location and capacity.

Pricing and limits: GPU pricing includes an L4 at $0.80, an A100 80 GB at $1.76, and an H100 80 GB at $2.74 per GPU-hour. GPU plans include their allocated CPU, RAM, and ephemeral storage. Persistent volumes and applicable network egress are priced separately. Enterprise arrangements cover custom capacity and support requirements.

Trade-off: GPU types and supported GPU counts vary by region, so your preferred hardware and deployment location need to align.

Modal provides a programmable environment for GPU functions, batch workloads, and model-serving applications. Its Python-oriented workflow lets developers define the execution environment and resource requirements in code.

Capabilities include:

• GPU-backed functions and web-serving workloads.
• Custom images and dependencies.
• Persistent volumes for model files and other retained data.
• Autoscaling controls, including minimum containers and scale-down behaviour.

Best for: Teams that want to express GPU execution and infrastructure configuration alongside their application code.

Pricing and limits: GPU, CPU, and memory charges contribute to the total. Keeping containers warm affects billable resource time, so the GPU rate alone does not describe endpoint cost.

Trade-off: Modal's execution and deployment abstractions become part of the application workflow. An existing containerised application may need adaptation around those interfaces. Use its autoscaling controls to balance cold starts against warm capacity rather than assuming every request has identical startup behaviour.

Baseten deploys models behind managed endpoints with configurable resources and replica counts. It supports packaging custom model-serving code and operating deployments through a model-focused workflow.

Capabilities include:

• Custom model packaging and deployment.
• GPU instance selection and replica autoscaling.
• Scale-to-zero configuration or minimum warm replicas.
• Deployment controls for production model serving.

Best for: Teams that want a managed inference deployment with control over hardware, model code, and serving capacity.

Pricing and limits: Dedicated deployment compute is billed by the minute. Replicas consume billable capacity during startup as well as serving, and keeping a minimum replica running adds idle cost.

Trade-off: Scale-to-zero reduces idle compute but introduces a model-startup path on subsequent traffic. Keeping replicas warm changes the economics. Set the minimum, maximum, and concurrency behaviour around the endpoint's latency and demand requirements.

Replicate exposes models through a prediction API and also supports custom models and dedicated deployments. It can suit teams that want a consistent way to invoke different model types without operating their own serving infrastructure.

Capabilities include:

• APIs for public models and privately deployed custom models.
• Custom model packaging through Cog.
• Deployment hardware selection and minimum/maximum instance settings.
• Prediction lifecycle and deployment monitoring tools.

Best for: Applications built around model predictions, including teams that want to move from a catalogue model to a custom deployment.

Pricing and limits: Public models can use model-specific pricing. Private deployment hardware follows its own billing rules, including setup and idle time while instances are online. Do not apply one public model's price to a dedicated custom endpoint.

Trade-off: Your application integrates with Replicate's prediction and deployment model. If you need an existing arbitrary HTTP server or other long-running process unchanged, evaluate whether that interface fits before choosing the platform.

Runpod Serverless runs GPU workers behind queue-based or load-balanced endpoints. It is distinct from Runpod Pods, which use a different deployment and billing model.

Capabilities include:

• Custom worker images for GPU execution.
• Queue-based processing and load-balanced endpoints.
• Flexible worker capacity that can scale down between requests.
• Active workers for capacity kept ready continuously.

Best for: Teams that want to build a GPU request-processing workflow around workers and explicit scaling controls.

Pricing and limits: Serverless billing covers the worker lifecycle, including startup, execution, and idle time before shutdown. Active workers use a separate pricing arrangement. Network storage and other resources can add to the total.

Trade-off: A worker that repeatedly downloads a large model can spend a meaningful share of its lifecycle preparing to serve. Package dependencies carefully and evaluate caching, storage, and warm-worker settings using your actual model rather than relying on the execution time of a single request.

Koyeb deploys GPU-backed applications from container images or Git repositories. Its service model suits teams that want to expose an application endpoint without operating the underlying servers.

Capabilities include:

• GPU instance selection for containerised applications.
• Git and container-image deployment workflows.
• Service networking and health checks.
• Scaling controls and scale-to-zero options for supported configurations.

Best for: Developers and teams deploying an existing model-serving application through a managed application service.

Pricing and limits: Instance usage is billed by the second. The H100 example above includes host CPU and memory, so it should not be compared directly with another provider's GPU-only component rate.

Trade-off: Scale-to-zero is in public preview. Confirm the supported service configuration and sleep behaviour before making it part of a production latency target. Waking a service and loading its model are separate from accepting a network request.

The useful comparison is cost per successful request at your required latency and quality, including the billable time around execution.

For a worker-based service, estimate:

Compute cost = billable worker time × resource rate
Total cost = compute + storage + networking + other applicable charges

Suppose a configuration costs $4 per worker-hour and remains billable for 90 seconds across startup, processing, and idle timeout. That lifecycle costs $0.10 before other charges. If processing itself took 30 seconds, estimating only those 30 seconds would understate the compute cost by two-thirds.

This is an illustrative calculation, not a provider price or measured workload. The same principle applies when a deployment keeps warm replicas: unused capacity is part of the cost of meeting the latency target.

For an LLM endpoint, measure input and output lengths, time to first token, generation speed, concurrency, and errors. For image or audio models, measure completed outputs at the required quality. A faster GPU may cost less per completed result even when its hourly rate is higher.

Test the complete path from an idle deployment to a successful response, then repeat under realistic concurrent demand.

Cold starts can include scheduling, pulling the image, downloading weights, initialising the runtime, and loading the model into GPU memory. A fast container start does not establish that the model is ready to serve.

Use a small evaluation plan:

1. Run from zero or a cold state: Measure the first successful response, not just process startup.
2. Run with warm capacity: Measure latency and throughput without initialisation.
3. Send a representative burst: Observe queues, new replicas, errors, and timeouts.
4. Leave the service idle: Check when instances stop and what remains billable.
5. Repeat after a deployment: Confirm the effect of new images, model caches, and readiness checks.

For vLLM workloads, memory and concurrency configuration affects how many requests each GPU can handle. Autoscaling more replicas will not fix a single instance that cannot fit the model and its request workload.

Choose Northflank for configurable GPU services and jobs with managed deployment or customer-cloud placement; Modal for programmable GPU functions; Baseten for managed model serving; Replicate for prediction APIs; Runpod Serverless for worker-based request processing; and Koyeb for GPU-backed application services. Test one representative workload, including idle periods and bursts, before comparing the final bill.

These answers distinguish the deployment and billing choices that most affect a first project.

They can be for intermittent workloads that release capacity between requests. For sustained utilisation, an always-running GPU instance or committed capacity may be more economical. Compare the same model, throughput, latency, and supporting resources.

No. The term covers different managed execution models. Check the specific offering's minimum replica count, idle behaviour, wake-up mechanism, and billing rules. Configurable autoscaling does not automatically establish request-triggered scale-from-zero.

Yes, many providers support custom weights and serving code. The packaging differs: it may be a function, worker image, model bundle, or application container. Confirm runtime compatibility, model licensing, storage, and startup requirements.

Some can, but suitability depends on job duration, checkpoint storage, GPU allocation, and the execution model. A platform designed around short prediction requests may require a different configuration for training. Use a finite job or batch interface where it matches the workload.

No. It can stop active compute charges once the platform has shut down the relevant capacity, but retained storage and other resources may remain billable. Startup, idle timeout, and minimum warm capacity also affect the bill.

Start with the model and runtime your application needs, then measure the full deployment lifecycle. The right provider should make both its performance and its cost understandable.

Compare the broader GPU market and follow a deployment walkthrough.

• Best GPU cloud providers
• Cheapest cloud GPU providers
• Rent GPUs for AI