This guide provides best practices for configuring Flash endpoints based on your use case. Recommendations are organized by workload type and optimization goal.
Production workloads
Here are some best practices for production deployments requiring reliability and consistent performance:
General recommendations
- Pin specific GPU types instead of using
GpuGroup.ANY for predictable performance and costs.
- Use network volumes for large models to avoid downloading on each worker startup.
- Set appropriate
execution_timeout_ms to prevent runaway jobs and control costs.
- Use environment variables for configuration and secrets, not hardcoded values.
Queue-based endpoints
Queue-based endpoints handle asynchronous batch processing where jobs can wait in queue:
Key settings:
workers=(1, n): Set min to 1 to avoid cold starts for first job in queue.
workers=(n, max): Set max based on expected peak concurrent jobs.
idle_timeout: 900-1800 seconds (15-30 minutes) for production workloads.
Load-balanced endpoints
Load-balanced endpoints handle synchronous HTTP requests where immediate response is critical:
Key settings:
workers=(n, max): Set min ≥ 1 for production APIs to avoid cold starts. Unlike queue-based endpoints where jobs can wait, API clients expect immediate responses.
workers=(min, n): Set max based on expected peak concurrent requests.
idle_timeout: 1200-1800 seconds (20-30 minutes) to keep workers ready.
- Include health check routes (e.g.,
GET /health) for monitoring.
Development
Here are some best practices for development and testing environments prioritizing fast iteration:
General recommendations
- Use
GpuGroup.ANY for fastest GPU provisioning during development.
- Set
workers=(0, n) to minimize costs when not actively testing.
- Keep max workers low (1-3) to control development expenses.
- Use short
idle_timeout (300 seconds / 5 minutes) to scale down quickly between test runs.
- Test locally with
flash dev before deploying to production.
Example configuration
Cost optimization
Here are some best practices for minimizing costs on infrequent or batch workloads:
General recommendations
- Set
workers=(0, n) to scale to zero when idle (no usage = no cost).
- Use smaller GPU types when workload allows (e.g.,
GpuType.NVIDIA_GEFORCE_RTX_4090 instead of GpuType.NVIDIA_A100_80GB_PCIe).
- Use CPU endpoints when GPU acceleration isn’t needed.
- Reduce
idle_timeout for sporadic workloads (300-600 seconds / 5-10 minutes).
- Batch operations into fewer job submissions when possible.
Cost-optimized queue-based endpoint
Cost-optimized CPU endpoint
For workloads that don’t require GPU acceleration:
Configuration trade-offs
Understanding the trade-offs helps you balance cost, latency, and performance:
Configuration checklist
Before deploying to production, verify:
- GPU selection: Using specific GPU types (not
GpuGroup.ANY) for predictable performance
- Worker scaling:
workers=(1, n) or higher min for load balancers and latency-sensitive workloads
- Timeouts:
execution_timeout_ms set appropriately for your workload
- Storage: Network volume attached if using large models or datasets
- Environment variables: All configuration and secrets passed via
env parameter
- Monitoring: Health check routes implemented (load balancers)
- Testing: Tested locally with
flash dev before production deployment
Last modified on August 14, 2026