Add control panel allow manage multi vllm instances

[leiwen83]

trafficstars

This PR import controller feature from fastchat, which make vllm could be running with its full openai compatible server of latest features.

• it inherits original fastchat controller core feature, such like model registry, auto scale, model roll update

• it keeps controller logic layer at minimal shape, which it would forward whatever user request pass to vllm openai compatible server worker

• it would also track each worker's unfinished queue length, and adjust the request sending speed accordingly. Thus keep the whole cluster balanced, and at its full serving capability.

• Currently, only v1/completions and v1/chat/completions are implemented. Along with other three interface to help check controller status.

  • /list_workers: show current registered workers and their status
  • /health: whether current controller is functional
  • /list_models: all registered model names

FILL IN THE PR DESCRIPTION HERE

FIX #4226 Since vllm openai compatible server is evolving rapidly, I think we may need to move the control panel feature we see from fastchat into vllm itself, to enjoy those feature fastchat brought to us along with latest vllm functions.

[simon-mo]

Can you open an RFC for this for design discussion?

[robertgshaw2-redhat]

It would be good to have an open discussion about this feature as there is a real debate about what should be in or out of scope for vllm

[tdene]

Scope or not, there's no point to porting over FastChat's Python controller implementation, it's literally 1000x slower at scale than 1 day's worth of Rust code.

[leiwen83]

@simon-mo @robertgshaw2-neuralmagic RFC https://github.com/vllm-project/vllm/issues/4873 is created

[leiwen83]

Scope or not, there's no point to porting over FastChat's Python controller implementation, it's literally 1000x slower at scale than 1 day's worth of Rust code.

Yep, rust also could be a choice, since fastchat original choose python style and also the rest of vllm, we may head it up with python first, and latter people could improve it if found rust have performance benefit.

[tdene]

@leiwen83 I apologize, I did not mean to be rude. The idea is good, this type of controller is very useful.

But I have seen first-hand how incredibly slow FastAPI is at this particular job, even after you eliminate 90% of the current code's overhead through things like using persistent sockets instead of individual calls.

The user experience is bad. It will end up taking more dev time to deal with Issues than it would take to just make it performant from the beginning.

[github-actions[bot]]

This pull request has been automatically marked as stale because it has not had any activity within 90 days. It will be automatically closed if no further activity occurs within 30 days. Leave a comment if you feel this pull request should remain open. Thank you!

[mergify[bot]]

This pull request has merge conflicts that must be resolved before it can be merged. Please rebase the PR, @leiwen83.

https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/syncing-a-fork