| title | Fault Tolerance |
|---|---|
| subtitle | Handle failures gracefully with request migration, cancellation, and graceful shutdown |
Dynamo provides comprehensive fault tolerance mechanisms to ensure reliable LLM inference in production deployments. This section covers the various strategies and features that enable Dynamo to handle failures gracefully and maintain service availability.
Fault tolerance in Dynamo operates at multiple levels:
| Layer | Mechanism | Purpose |
|---|---|---|
| Request | Migration, Cancellation | Handle in-flight request failures |
| Worker | Health Checks, Graceful Shutdown | Detect and recover from worker failures |
| Engine Process | Shadow Engine Failover | Active/passive recovery for same-node engine-process failures in Kubernetes |
| System | Load Shedding, Request Rejection | Prevent system overload |
| Infrastructure | etcd HA, NATS resilience | Handle infrastructure component failures |
When a worker fails during request processing, Dynamo can migrate in-progress requests to healthy workers. The migration system:
- Preserves partial generation state (accumulated tokens)
- Transparently continues generation on a new worker
- Maintains seamless token flow to clients
See Request Migration for details.
Dynamo supports canceling in-flight requests to free computational resources:
- Graceful stop signals for clean termination
- Kill signals for immediate termination
- Hierarchical cancellation propagation through request chains
See Request Cancellation for details.
Workers handle shutdown signals (SIGTERM/SIGINT) gracefully:
- Immediately stop accepting new requests
- Optionally drain in-flight requests before terminating
- Clean up resources (engines, connections, temp files)
See Graceful Shutdown for details.
When workers are overloaded, Dynamo rejects new requests to prevent cascading failures:
- Configurable busy thresholds based on KV cache utilization
- Real-time worker load monitoring
- HTTP 503 responses with retry guidance
See Request Rejection for details.
Dynamo provides multiple health check mechanisms:
- HTTP Endpoints:
/healthand/liveendpoints for orchestration - Canary Health Checks: Active monitoring via periodic test requests
- Engine Monitoring: Automatic shutdown on engine failure detection
See Health Checks for details.
After a request-path failure, a runtime client temporarily removes that worker from its local routing set while service discovery propagates the worker's state. DYN_RUNTIME_INHIBITED_DURATION_SECS sets the maximum local inhibition window and is read once during client initialization. The default is 5 seconds; set it to 0 to disable local inhibition. Discovery updates remain authoritative and can restore or remove workers sooner. Direct dispatch bypasses local inhibition and honors an upstream-selected worker as long as it remains present in service discovery.
Changes to the environment variable take effect the next time the process starts.
For Kubernetes deployments, Shadow Engine Failover can help with same-node recovery from unknown backend engine or software-process failures. It uses GPU Memory Service to keep model weights resident while a standby or replacement engine attaches. It does not preserve in-flight requests or KV cache state, and it does not cover GPU or node loss.
| Feature | Environment Variable | Default |
|---|---|---|
| Worker health port | DYN_SYSTEM_PORT |
9090 |
| Canary health checks | DYN_HEALTH_CHECK_ENABLED |
false |
| Canary wait time | DYN_CANARY_WAIT_TIME |
10 seconds |
| Health check timeout | DYN_HEALTH_CHECK_REQUEST_TIMEOUT |
3 seconds |
| Decode blocks threshold | DYN_ACTIVE_DECODE_BLOCKS_THRESHOLD |
unset |
| Prefill tokens threshold | DYN_ACTIVE_PREFILL_TOKENS_THRESHOLD |
unset |
| Prefill tokens fraction threshold | DYN_ACTIVE_PREFILL_TOKENS_THRESHOLD_FRAC |
unset |
| Local worker inhibition | DYN_RUNTIME_INHIBITED_DURATION_SECS |
5 seconds (0 disables) |
- Worker receives SIGTERM from Kubernetes
- Endpoints are immediately invalidated (no new requests)
- In-flight requests complete or migrate (based on configuration)
- Resources are cleaned up
- Pod restarts with fresh state
- etcd lease expires (TTL-based detection)
- Client discovers endpoint removal via etcd watch
- New requests route to remaining healthy workers
- In-flight requests on crashed worker are migrated (if enabled)
- Worker loses connectivity to etcd/NATS
- Lease keep-alive fails, lease eventually expires
- Worker is removed from service discovery
- Traffic reroutes to reachable workers
- Engine health check detects GPU error (XID, OOM, etc.)
- Worker initiates graceful shutdown
- Runtime is shut down, engine cleaned up
- Process exits with code 1 for pod restart
Dynamo includes a comprehensive testing framework for validating fault tolerance:
- Request cancellation tests
- Migration tests with worker failures
- etcd HA failover tests
- Hardware fault injection (GPU XID, network partitions)
See Fault Tolerance Testing for details.
- Observability - Metrics and monitoring
- Shadow Engine Failover - Same-node active/passive engine failover for Kubernetes deployments
- Distributed Runtime - Service discovery architecture
- Event Plane - Pub/sub for KV cache events and worker metrics
- Discovery Plane - Service discovery and coordination