ProjectTech4DevAI / ProjectTech4DevAI/kaapi-backend

Evaluation: Worker cap for LLM jobs

Open
#1,019 0 comments 0 reactions 1 assignee View on GitHub

@AkhileshNegi is already working on this.

Since Jul 9, 2026.

bug
Dominant language
Python
Stars
18
Forks
10
Avg merge
2d 20h
Merged PRs (30d)
14

Description

Is your feature request related to a problem?
Fast evaluations and high-priority LLM jobs share one Celery default queue and one global worker_concurrency, with no cap on how many fast-eval chunk tasks can run at once. A 500-item run fans out to 10 chunk tasks (chunk size 50), so 2-3 concurrent eval runs (20-30 tasks) can occupy every worker slot.

Task priority (LLM=9, eval=6) does not help here: RabbitMQ priority only decides which queued task runs next when a slot frees — it does not preempt a running task. So when all slots are busy with eval chunks, an incoming LLM job waits until a chunk finishes (soft time limit 300s), meaning a high-priority LLM call can wait ~4 minutes. Not acceptable for interactive latency.

Describe the solution you'd like
Cap the worker capacity fast evals can consume, so high-priority LLM jobs always have headroom

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.