Show HN: liteLLM Proxy Server: 50+ LLM Models, Error Handling, Caching (github.com)
I’m the maintainer of liteLLM() - package to simplify input/output to OpenAI, Azure, Cohere, Anthropic, Hugging face API Endpoints: https://github.com/BerriAI/litellm/
We’re open sourcing our implementation of liteLLM proxy: https://github.com/BerriAI/litellm/blob/main/cookbook/proxy-...
TLDR: It has one API endpoint /chat/completions and standardizes input/output for 50+ LLM models + handles logging, error tracking, caching, streaming
What can liteLLM proxy do? - It’s a central place to manage all LLM provider integrations
- Consistent Input/Output Format - Call all models using the OpenAI format: completion(model, messages) - Text responses will always be available at ['choices'][0]['message']['content']
- Error Handling Using Model Fallbacks (if GPT-4 fails, try llama2)
- Logging - Log Requests, Responses and Errors to Supabase, Posthog, Mixpanel, Sentry, Helicone
- Token Usage & Spend - Track Input + Completion tokens used + Spend/model
- Caching - Implementation of Semantic Caching
- Streaming & Async Support - Return generators to stream text responses
You can deploy liteLLM to your own infrastructure using Railway, GCP, AWS, Azure
Happy completion() !
35 comments
[ 4.4 ms ] story [ 107 ms ] threadRe: LocalLLM's like Llama2 - yes we support self-deployed models, through Huggingface, Replicate, TogetherAI integrations.
We're missing support for locally deployed models - and would love the help!
Re: ollama - we spent a couple hours trying to integrate ollama. We had a couple issues though, would love to try and support it. Got time to chat sometime this/next week? I think this would be an awesome addition.
There's also the fact that the data being sent to these LLM "destinations" could be significantly more valuable (or contain significantly more sensitive information) than the average segment identity or track objects.
If you have ideas for improvement - we'd love a ticket/PR!
Most production use cases probably need some sort of fall back of small -> medium -> large -> GPT4.
Given the costs + low quota limits, I would be surprised if any significant portion of the market is falling back from one expensive proprietary* API to another.
With the rapid improvements in model servers like llama.cpp and vllm.ai, providing an abstraction layer for “fastest model server of the month” would be useful.
Should we add support for llama.cpp and vllm.ai in the proxy server ? Or should we assume you can host them on your own infra and the proxy server requests your hosted model ?
There is a ton of boilerplate around the actual model server that’s just busy work , but if done wrong can be a huge performance suck. Solve that.
Build the proxy that works with the most model servers out there. Do it in a way that once you have mindshare, the model server makers will be find it easy to put up a PR so that they can claim your proxy supports their server.
Don’t take a hard dependency on non-OSS stuff - being able to build an “on-prem” solution (read “deployed into customer’s VPC”) is table stakes for anyone to use your offering for a lot of enterprise use cases.
Edit: another unsolved problem - different models need slightly different prompts to solve the same problem well…
But in general I’m in agreement that this sounds like a separate concept than any given model server.
That said, where is a list of model servers for the most commonly wanted LLMs at this point?
Perhaps maintaining a list of those that do and don’t work with the proxy would be helpful.
We're adding new integrations every day, so if there's any specific one you'd like to add feel free to let us know (discord/ticket/email/etc.) - here's my email: krrish@berri.ai
edit: Found the cache notebook[1] and the calls to the cache and distance eval in the code[2]
[1] https://github.com/BerriAI/litellm/blob/main/cookbook/liteLL...
[2] https://github.com/BerriAI/litellm/blob/80d77fed7123af222011...
> …can’t people just build their product with openAI or other and plan to move away based on the cost and fit for their circumstances?
> Couldn’t someone say prototype the entire product on some lower-quality LLM and occasionally pass requests to GPT4 to validate behavior?
This seems to reduce the switching costs to almost nothing.
[1] https://news.ycombinator.com/item?id=36626943
tldr; reliable model switching involved multiple 100-line if/else statements, which made our code messy, and debugging in prod pretty hard.
There's a lot of good model deployment platforms that would make it easy to call your model behind a hosted endpoint
-- If you do want to self-host - there's some great libraries like https://github.com/lm-sys/FastChat and https://github.com/ggerganov/llama.cpp that might be helpful
If none of these really solve your issue - feel free to email me and I'm happy to help you figure something out - krrish@berri.ai
Here's the tutorial - https://github.com/BerriAI/litellm/blob/main/cookbook/liteLL...