You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/fault-tolerance/request-migration.md
+9Lines changed: 9 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -34,6 +34,15 @@ The migration limit is configured at the **frontend** level and applies globally
34
34
- Set via `--migration-limit` flag on the frontend
35
35
- Applies to all models served by the frontend
36
36
37
+
### Retry Concurrency Configuration
38
+
39
+
During worker failover, many in-flight streams can disconnect at the same time and retry against the newly active worker. `DYN_MIGRATION_RETRY_CONCURRENCY` optionally caps the number of migrated retry streams that can run concurrently in a frontend process:
40
+
41
+
- Default behavior: unlimited retry concurrency (`DYN_MIGRATION_RETRY_CONCURRENCY=0` or unset)
42
+
- Set via `DYN_MIGRATION_RETRY_CONCURRENCY` on the frontend or Bulwark gateway
43
+
- The cap applies only after a request has entered migration/retry; first-attempt traffic is not throttled
44
+
- A migrated stream holds a permit until that stream completes, which prevents a failover replay burst from overwhelming a warm shadow worker
45
+
37
46
### Max Sequence Length Configuration
38
47
39
48
The max sequence length setting controls how long the migration system will cache token state for a request. Once the total sequence length (prompt + generated tokens) exceeds this limit, migration is disabled for that request and token tracking stops:
0 commit comments