Add support for Azure, llama2, palm, claude2, cohere command nightly (etc)

[ishaan-jaff]

This PR adds support for models from all the above mentioned providers using https://github.com/BerriAI/litellm/

Here's a sample of how it's used:

from litellm import completion, acompletion

## set ENV variables
# ENV variables can be set in .env file, too. Example in .env.example
os.environ["OPENAI_API_KEY"] = "openai key"
os.environ["COHERE_API_KEY"] = "cohere key"

messages = [{ "content": "Hello, how are you?","role": "user"}]

# openai call
response = completion(model="gpt-3.5-turbo", messages=messages)

# llama2 call
model_name = "replicate/llama-2-70b-chat:2c1608e18606fad2812020dc541930f2d0495ce32eee50074220b87300bc16e1"
response = completion(model_name, messages)

# cohere call
response = completion("command-nightly", messages)

# anthropic call
response = completion(model="claude-instant-1", messages=messages)

[ishaan-jaff]

@minimaxir can you please take a look at this PR when possible😊 Happy to add docs/tests too if this initial commit looks good

[ishaan-jaff]

Addressing: https://github.com/minimaxir/simpleaichat/issues/73 https://github.com/minimaxir/simpleaichat/issues/71 https://github.com/minimaxir/simpleaichat/issues/70 (works with fine tuned models) https://github.com/minimaxir/simpleaichat/issues/43

[minimaxir]

Looking into this now: it'll take a bit longer since it's adding a dependency.

[minimaxir]

After some investigation into LiteLLM, I will have to reject adding it despite the high demand for alternative services for a number of reasons:

1. This PR is insufficient. Every instance of hitting the API would need to be update, along with a full refactor. Additionally, the new behavior would have to be documented from scratch, which is partially why I'm intending to add new services one by one.
2. LiteLLM code is highly redundant with its implementations compared to what simpleaichat is doing, in addition to its own extra dependencies.
3. Your implementations for pinging the API and ETLing the I/O are inefficient and would result in a slowdown for simpleaichat. Additionally, it's not clear if your hacks used to interface with non-ChatGPT APIs are optimal.
4. Your demos notebooks have undocumented behavior of automatically creating a dashboard, which is a complete nonstarter.

The design intent of simpleaichat is to be very clear, transparent, and consistent, even in its codebase.

[ishaan-jaff]

@minimaxir thanks for the feedback

Your implementations for pinging the API and ETLing the I/O are inefficient and would result in a slowdown for simpleaichat. Additionally, it's not clear if your hacks used to interface with non-ChatGPT APIs are optimal.

Was there something in particular that made it seem like it would result in a slowdown and sub-optimal results ?

Your demos notebooks have undocumented behavior of automatically creating a dashboard, which is a complete nonstarter.

Thanks for pointing that out - it was an experimental feature that users can opt in to. We will clean that out

[minimaxir]

Was there something in particular that made it seem like it would result in a slowdown and sub-optimal results ?

More in general for optimization (e.g. minimizing serialization overhead, minimizing HTTP session creation).