Serverless
Hand-reviewed 2026-07-18 · review after 2026-10-18
Setup: moderate
- Deployment
- A provider-specific handler runs inside a custom container behind a managed queue endpoint. Images can be supplied from a container registry or deployed from a GitHub repository.
- queued worker · synchronous http · asynchronous job · task queue
- Scale to zero
- Flex workers scale dynamically to zero when idle. Active workers are a separate always-running option for workloads that must avoid cold starts.
- supported · default
- Billing behavior
- Flex workers are billed from worker startup until complete shutdown, including initialization and the configured idle timeout, rounded to the provider's billing increment. Storage is charged separately.
- Startup behavior
- Cold-start time depends on image download, worker initialization and model loading. Cached models and FlashBoot can reduce it, but the general worker path has no single guaranteed end-to-end cold-start time.
- Setup
- The standard workflow requires a Runpod handler, local container testing, an image registry or GitHub deployment, and endpoint/GPU configuration in the Runpod console or API.
- Requires: Runpod account · Runpod handler integration · Docker image or GitHub repository · Serverless endpoint configuration
- Important constraints
-
- Several lower-cost GPU classes group multiple GPU models, so exact hardware and performance may vary within the selected class.
- Worker concurrency limits depend on account balance unless increased by support.