In this article
Serverless is not one uniform product. Choose owned-code execution or a managed model, then verify cold starts, waiting and billing structure.
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 | Workers and owned-application endpoints | Queue, cold start and endpoint type |
| Vast Serverless | AI workloads and workergroups | Workload preparation and scaling |
| Modal | Code-defined application and resources | Environment portability and container lifecycle |
| Crusoe | 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 and capacity planning.