Adding vLLM inference entrypoints to Flamingo

[veekaybee]

This PR adds an additional model loading class for running evaluations against a pre-loaded model available at an OpenAI-style inference endpoint. See code in source here for instructions on how to load a model at a vLLM inference endpoint.

It implements:

• a new set of integrations, vllm, that allows for local model loading
• a class, InferenceServerConfig that implements a base_url pointing to the loaded inference point
• Additional unit tests for this new config
• Some ruff formatting cleanup of spaces and adding a precommit
• Putting requirements.txt in .gitignore since we only work with them locally, as explained in CONTRIBUTING.md and the examples

NOTE: This code change does not allow jobs to work yet, as we still need to implement changes to load_and_evaluate in the lm_harness entrypoint in order to pass the model parameters correctly, like here:

lm_eval --model local-chat-completions --tasks gsm8k --model_args model=facebook/opt-125m,base_url=http://{yourip}:8000/v1

I don't want to block merges and this PR is big enough already , so if this is merged I'll follow up with this next PR.

See: https://mzai.atlassian.net/browse/RD2024-71

[sfriedowitz]

Suggested change

	def model_config_with_vllm():
	def inference_server_config():

[veekaybee]

that's fine, was following the pattern of model_config_with_repo_id and model_config_with_artifact

[sfriedowitz]

What are these docstrings for?

[veekaybee]

to make it slightly clearer why we're running the same test twice, alternatively I could also fold this into one paramterized test. actually, I think I'll do that.

[sfriedowitz]

That's fine then, I would just add the to within the test function body, not the middle of the file :D

[veekaybee]

changed this to be a bit cleaner

[sfriedowitz]

Minor comment, but fine to go into dev branch from this point.

[sfriedowitz]

This line not necessary, since requirements_lock.txt doesn't exist in this repo

[sfriedowitz]

I would also suggest in the future not having a singular development branch for the entire repo, since multiple people working on separate tickets would cause conflicts trying to merge into the dev branch. It's probably best to keep dev branches isolated to features/mini-projects, and merge a handful of related PRs into that branch before finally bringing it together with main.

e.g., dev/vicky/infernce-server and then a series of PRs into that branch as the work evolves

[veekaybee]

gotcha, makes sense. i think we can adjust as need be based on what patterns we see as issues in future PRs - hopefully they'll become smaller as we go and we can use the dev branch as "staging" for what we want to release as as a whole 🤞