vllm-project / vllm-project/aibrix
Design question: where should tenant/task/adapter governance live in an AIBrix/vLLM stack?
- Dominant language
- Go
- Stars
- 5.1k
- Forks
- 697
- Avg merge
- 1d 19h
- Merged PRs (30d)
- 104
Description
Hi AIBrix team,
I’m Irénée Akilimali, an independent engineer exploring tenant/task/adapter governance for vLLM-style serving stacks.
I saw that AIBrix already covers several major infrastructure needs: high-density LoRA management, LLM gateway/routing, autoscaling, unified runtime, distributed inference, KV cache, heterogeneous serving, and hardware reliability.
I’m working on a narrower prototype called AKM-CLR. It is not a replacement for AIBrix or vLLM. It explores a specific governance question:
Before a request reaches a shared vLLM/AIBrix-managed backend, should this tenant, task, adapter, or context source be allowed?
The public runnable demo compares:
1. Direct backend — forwards every request.
2. Naive router — routes but still forwards unsafe or wrong-domain requests.
3. AKM-CLR gateway — allows, fallbacks, or blocks before backend inference and records an audit trace.
Repo:
https://github.com/irenee28/akm-clr-governance-layer
The demo uses a mock backend, so it can run locally without GPU cost or API keys.
My question for this community:
Where would this kind of tenant/task/adapter governance belong in an AIBrix-style architecture?
Would it make more sense as:
* an external gateway before AIBrix,
* a sidecar,
* a router plugin,
* an admission-control policy module,
* or something else?
Important caveat: this is a prototype, not production-ready or guaranteed secure. I am looking for architectural criticism and guidance, not trying to position it as a replacement for existing AIBrix components.
Thanks,
Irénée Akilimali
Contributor guide
Research direction
No source files or tests are named. Start by running or reviewing the linked AKM-CLR mock-backend demo, then read the AIBrix components mentioned in the issue and compare the proposed integration points. Done means reaching and documenting an architectural recommendation for where tenant, task, adapter, or context governance should live.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go, python
- Domain
- backend-api-design, infrastructure
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100