# Four serverless approaches to GPU inference

Investigate Runpod, Vast.ai, Modal and Crusoe serverless workflows: owned code, workers, managed model APIs, cold starts and different charging units.

Author: Retrivium team
Updated: 2026-11-01
Canonical URL: https://retrivium.ai/journal/top-serverless-gpu-providers/
Language: en

Serverless separates applications from individual-machine management, but covers different workflows. Some teams deploy code and workers; others call a managed model. For LLMs, that distinction changes control, latency and budget.

Current to 1 November 2026, this is an editorial map of four documented approaches, without independent testing or price and speed rankings.

## Inclusion criteria

We selected services with officially described serverless routes for AI. Criteria include what customers deploy, execution scaling and the charging unit. Partner programmes did not determine selection.

Inclusion does not mean all four fit your model. Verify devices, account restrictions, request formats and functions. Compute-time and shared-API billing cannot be compared without the same task.

## Four approaches to investigate

| Service | Starting point | Pilot checks |
| --- | --- | --- |
| [Runpod Serverless](https://docs.runpod.io/serverless/overview) | Workers and owned-application endpoints | Queue, cold start and endpoint type |
| [Vast Serverless](https://docs.vast.ai/guides/serverless) | AI workloads and workergroups | Workload preparation and scaling |
| [Modal](https://modal.com/docs/guide) | Code-defined application and resources | Environment portability and container lifecycle |
| [Crusoe](https://docs.crusoe.ai/serverless-inference/index.html) | Managed serverless inference | Model, API functions and charging unit |

These are different service layers. A ready model API is not an arbitrary container, while owned-code execution does not establish model quality.

## Measure the first request

Test a launch without active capacity, repeated requests and streaming if required. Separate queueing from generation. One warm response does not describe an irregularly used application.

Preserve input/output sizes, context and concurrency. If the service chooses devices or modes automatically, include that in the conditions. Findings should describe a tested configuration rather than the abstract serverless label.

## Budget variable traffic

A hypothetical team creates two profiles: isolated occasional requests and a brief burst. For each, calculate complete expense including applicable startup, waiting and storage. Check the selected product rather than transferring rules from another branded service.

Include image preparation, error handling and observability work. Serverless reallocates duties without removing application responsibility. Keeping capacity active for latency is a separate budget decision.

## Relate the choice to an owned pool

This test clarifies the workload owned infrastructure might serve and the functions clients need. It does not forecast paid GPU utilisation.

Read the [throughput–latency trade-off](/journal/throughput-latency-tradeoff/) and [capacity planning](/journal/inference-capacity-planning/).