Feature Idea
This is a follow-up to Discussion #1280, “Per-user queue priorities and fair-share scheduling for multi-user mode.”
I run a private multi-user SwarmUI instance where several trusted users share a single GPU. SwarmUI's existing role system and Max T2I Simultaneous setting work well for limiting how many generations an individual user can run concurrently, but there does not appear to be an equivalent way to limit how many generations a user can place into the queue.
This creates a remaining resource-management issue since a user limited to one simultaneous generation can still submit a large number of generations. The queued jobs can potentially delay work submitted by other users.
Example:
User A queues 32 generations
User B queues 2 generations
User C queues 3 generations
With a shared FIFO-style queue, B and C may have to wait behind a large amount of work submitted by A, despite all three users having the same role and Max T2I Simultaneous limit.
Proposed features:
1. Maximum queued/outstanding generations per role
Add a role setting alongside Max T2I Simultaneous, for example:
Max T2I Simultaneous: 1
Max T2I Queued: 4
Ideally this would count a user's outstanding generation work and reject or defer additional submissions once the role's limit is reached.
This would also be useful independently of fair-share scheduling, since it would prevent one user from accidentally or intentionally creating an extremely large backlog.
A value such as 0 or -1 could represent unlimited, preserving current behavior for Owner/Admin or existing installations.
2. Fair-share scheduling between users
As proposed in Discussion #1280, it would also be useful for users at the same priority level to receive fair access to available backends rather than scheduling purely according to global submission order.
A simple round-robin approach would be sufficient for many small multi-user installations:
User A: A1 A2 A3 A4 A5...
User B: B1 B2
User C: C1 C2 C3
Possible execution:
A1 → B1 → C1 → A2 → B2 → C2 → A3 → C3 → A4...
This doesn't necessarily need to interrupt generations already running, it could apply when selecting the next queued generation for an available backend.
3. Optional role/user queue priority
Discussion #1280 also proposed queue priorities. This could complement fair sharing, particularly for between administrators and lower permission level users.
For example:
Owner/Admin: High priority
PowerUser: Normal priority
User: Normal priority
Guest: Low priority
Fair-share scheduling would then operate among users at the same priority level.
Use case
My particular installation is a friends-and-family SwarmUI server exposed through Cloudflare Access. Each person has their own SwarmUI account and a restricted custom role.
The existing permissions system already provides very good separation of administrative capabilities, backend access, model management, outputs, etc. Max T2I Simultaneous also provides a useful concurrency control.
The main resource-control gap I've encountered is queued work rather than simultaneous work.
For a small single-GPU server, something like:
Role: Friends
Max T2I Simultaneous: 1
Max T2I Queued: 4
Queue Priority: Normal
This, combined with fair scheduling between users, would make SwarmUI's existing multi-user/role system more practical without requiring an external queue manager.
Implementation considerations
Ideally these limits would be enforced server-side rather than only through the Generate page UI controls, so they would also apply to API requests.
It would also be helpful if the user's current running/queued generation counts already tracked by SwarmUI could be reused for this rather than introducing a separate accounting mechanism.
I think the queue-limit portion would be extremely useful even if fair-share scheduling or queue priorities require more extensive scheduler changes and are implemented separately.
Related: Discussion #1280
Other
No response
Feature Idea
This is a follow-up to Discussion #1280, “Per-user queue priorities and fair-share scheduling for multi-user mode.”
I run a private multi-user SwarmUI instance where several trusted users share a single GPU. SwarmUI's existing role system and Max T2I Simultaneous setting work well for limiting how many generations an individual user can run concurrently, but there does not appear to be an equivalent way to limit how many generations a user can place into the queue.
This creates a remaining resource-management issue since a user limited to one simultaneous generation can still submit a large number of generations. The queued jobs can potentially delay work submitted by other users.
Example:
With a shared FIFO-style queue, B and C may have to wait behind a large amount of work submitted by A, despite all three users having the same role and Max T2I Simultaneous limit.
Proposed features:
1. Maximum queued/outstanding generations per role
Add a role setting alongside Max T2I Simultaneous, for example:
Max T2I Simultaneous: 1
Max T2I Queued: 4
Ideally this would count a user's outstanding generation work and reject or defer additional submissions once the role's limit is reached.
This would also be useful independently of fair-share scheduling, since it would prevent one user from accidentally or intentionally creating an extremely large backlog.
A value such as 0 or -1 could represent unlimited, preserving current behavior for Owner/Admin or existing installations.
2. Fair-share scheduling between users
As proposed in Discussion #1280, it would also be useful for users at the same priority level to receive fair access to available backends rather than scheduling purely according to global submission order.
A simple round-robin approach would be sufficient for many small multi-user installations:
This doesn't necessarily need to interrupt generations already running, it could apply when selecting the next queued generation for an available backend.
3. Optional role/user queue priority
Discussion #1280 also proposed queue priorities. This could complement fair sharing, particularly for between administrators and lower permission level users.
For example:
Fair-share scheduling would then operate among users at the same priority level.
Use case
My particular installation is a friends-and-family SwarmUI server exposed through Cloudflare Access. Each person has their own SwarmUI account and a restricted custom role.
The existing permissions system already provides very good separation of administrative capabilities, backend access, model management, outputs, etc. Max T2I Simultaneous also provides a useful concurrency control.
The main resource-control gap I've encountered is queued work rather than simultaneous work.
For a small single-GPU server, something like:
This, combined with fair scheduling between users, would make SwarmUI's existing multi-user/role system more practical without requiring an external queue manager.
Implementation considerations
Ideally these limits would be enforced server-side rather than only through the Generate page UI controls, so they would also apply to API requests.
It would also be helpful if the user's current running/queued generation counts already tracked by SwarmUI could be reused for this rather than introducing a separate accounting mechanism.
I think the queue-limit portion would be extremely useful even if fair-share scheduling or queue priorities require more extensive scheduler changes and are implemented separately.
Related: Discussion #1280
Other
No response