* fix(router): carry a 429 status on cooldown and no-deployment errors RouterRateLimitError and RouterRateLimitErrorBasic had no status_code, so the proxy answered an all-deployments-cooled-down request as a generic 500 class error and logged the bug report notice for every cooldown. Both now carry status_code 429, which the proxy maps to a rate_limit_error and which the retry policy already treats as retryable * fix(proxy): start Sentry at config load and never attach request bodies Sentry only came up inside set_callbacks on the first LLM call, so boot and background errors were never reported, and general_settings.alerting: [sentry] always raised Missing SENTRY_DSN because the alerting path read a dead litellm.utils pin instead of the live SDK. The proxy now initializes Sentry once while loading the config whenever sentry is a configured callback or alerting target, the alerting and failure handlers read the live instance, and max_request_body_size is pinned to never so prompts and completions stay out of Sentry events * fix(tracing): log Lens failures at ERROR and export row counters to Prometheus A tracing store that fails to start, or a Lens service that rejects a batch, was only logged at WARNING, so operators running at the default ERROR level never saw tracing silently go dark. Both now log at ERROR and name the lens store. The exporter's rows_written and rows_dropped tallies were never exported, so the two counts are now Prometheus counters litellm_lens_export_rows_written_total and litellm_lens_export_rows_dropped_total, registered lazily on the default registry like the other proxy-level counters and charted on the all-metrics Grafana dashboard * test(proxy): drop the litellm import the alerting tests no longer use * fix(proxy): start Sentry once a DSN is set, from any config source Boot-time init used to lock Sentry in even with no SENTRY_DSN, so a DSN loaded later from DB environment_variables was never picked up. initialize_sentry now skips when no DSN is set and re-inits when the DSN changes. alerting_handler calls it too, so alerting: [sentry] set through the DB works. Drops the litellm_settings.callbacks check since that config fails to load with sentry in it * fix(sentry): keep stack frame locals out of events unless PII is opted in Frame locals carried prompts (messages, request bodies, provider options) into every error event. include_local_variables now follows SENTRY_SEND_DEFAULT_PII * test(router): drop the test that only pinned the 429 class attribute * fix(proxy): start Sentry at boot when it is only an input callback * fix(proxy): keep Sentry init and alerting within the strict ruff and basedpyright ceilings --------- Co-authored-by: yuneng-jiang <yuneng@berri.ai> |
||
|---|---|---|
| .. | ||
| batch_api/bedrock | ||
| grafana_dashboard | ||
| mcp | ||
| secret_manager | ||
| braintrust_prompt_wrapper_README.md | ||
| braintrust_prompt_wrapper_server.py | ||
| cli_token_usage.py | ||
| readme.md | ||
liteLLM Proxy Server: 50+ LLM Models, Error Handling, Caching
Azure, Llama2, OpenAI, Claude, Hugging Face, Replicate Models
What does liteLLM proxy do
-
Make
/chat/completionsrequests for 50+ LLM models Azure, OpenAI, Replicate, Anthropic, Hugging FaceExample: for
modeluseclaude-2,gpt-3.5,gpt-4,command-nightly,stabilityai/stablecode-completion-alpha-3b-4k{ "model": "replicate/llama-2-70b-chat:2c1608e18606fad2812020dc541930f2d0495ce32eee50074220b87300bc16e1", "messages": [ { "content": "Hello, whats the weather in San Francisco??", "role": "user" } ] } -
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']
- Call all models using the OpenAI format -
-
Error Handling Using Model Fallbacks (if
GPT-4fails, tryllama2) -
Logging - Log Requests, Responses and Errors to
Supabase,Posthog,Mixpanel,Sentry,Lunary,Athina,Helicone(Any of the supported providers here: https://litellm.readthedocs.io/en/latest/advanced/Example: Logs sent to Supabase
-
Token Usage & Spend - Track Input + Completion tokens used + Spend/model
-
Caching - Implementation of Semantic Caching
-
Streaming & Async Support - Return generators to stream text responses
API Endpoints
/chat/completions (POST)
This endpoint is used to generate chat completions for 50+ support LLM API Models. Use llama2, GPT-4, Claude2 etc
Input
This API endpoint accepts all inputs in raw JSON and expects the following inputs
model(string, required): ID of the model to use for chat completions. See all supported models [here]: (https://litellm.readthedocs.io/en/latest/supported/): eggpt-3.5-turbo,gpt-4,claude-2,command-nightly,stabilityai/stablecode-completion-alpha-3b-4kmessages(array, required): A list of messages representing the conversation context. Each message should have arole(system, user, assistant, or function),content(message text), andname(for function role).- Additional Optional parameters:
temperature,functions,function_call,top_p,n,stream. See the full list of supported inputs here: https://litellm.readthedocs.io/en/latest/input/
Example JSON body
For claude-2
{
"model": "claude-2",
"messages": [
{
"content": "Hello, whats the weather in San Francisco??",
"role": "user"
}
]
}
Making an API request to the Proxy Server
import requests
import json
# TODO: use your URL
url = "http://localhost:5000/chat/completions"
payload = json.dumps({
"model": "gpt-3.5-turbo",
"messages": [
{
"content": "Hello, whats the weather in San Francisco??",
"role": "user"
}
]
})
headers = {
'Content-Type': 'application/json'
}
response = requests.request("POST", url, headers=headers, data=payload)
print(response.text)
Output [Response Format]
Responses from the server are given in the following format. All responses from the server are returned in the following format (for all LLM models). More info on output here: https://litellm.readthedocs.io/en/latest/output/
{
"choices": [
{
"finish_reason": "stop",
"index": 0,
"message": {
"content": "I'm sorry, but I don't have the capability to provide real-time weather information. However, you can easily check the weather in San Francisco by searching online or using a weather app on your phone.",
"role": "assistant"
}
}
],
"created": 1691790381,
"id": "chatcmpl-7mUFZlOEgdohHRDx2UpYPRTejirzb",
"model": "gpt-3.5-turbo-0613",
"object": "chat.completion",
"usage": {
"completion_tokens": 41,
"prompt_tokens": 16,
"total_tokens": 57
}
}
Installation & Usage
Running Locally
- Clone liteLLM repository to your local machine:
git clone https://github.com/BerriAI/liteLLM-proxy - Install the required dependencies using pip
pip install -r requirements.txt - Set your LLM API keys
os.environ['OPENAI_API_KEY]` = "YOUR_API_KEY" or set OPENAI_API_KEY in your .env file - Run the server:
python main.py
Deploying
-
Quick Start: Deploy on Railway
-
GCP,AWS,AzureThis project includes aDockerfileallowing you to build and deploy a Docker Project on your providers
Support / Talk with founders
- Our calendar 👋
- Community Discord 💭
- Our emails ✉️ ishaan@berri.ai / krrish@berri.ai
Roadmap
- Support hosted db (e.g. Supabase)
- Easily send data to places like posthog and sentry.
- Add a hot-cache for project spend logs - enables fast checks for user + project limitings
- Implement user-based rate-limiting
- Spending controls per project - expose key creation endpoint
- Need to store a keys db -> mapping created keys to their alias (i.e. project name)
- Easily add new models as backups / as the entry-point (add this to the available model list)