LiteLLM ని మీ స్వంత సర్వర్‌లో హోస్ట్ చేయడం ఎలా?

Self-hosted LLM gateway ఏమి చేస్తుంది

LiteLLM అనేది మీరు స్వయంగా హోస్ట్ చేసుకోగల ఒక open source LLM gateway: ఇది మీ అప్లికేషన్లన్నీ కాల్ చేసే ఒకే ఒక HTTP endpoint. ఇది ప్రతి అభ్యర్థనను (request) దానికి తగిన provider కి పంపుతుంది. LLM అంటే large language model. ఈ gateway OpenAI chat completions API (application programming interface) ని ఉపయోగిస్తుంది. కాబట్టి, ఇప్పటికే OpenAI తో పనిచేసే ఏ client library అయినా, కేవలం base URL మరియు key లలో మార్పులు చేయడం ద్వారా దీనితో పనిచేస్తుంది.

ఈ ఒక్క అదనపు పొర (layer of indirection) ఉండటమే దీని ముఖ్య ఉద్దేశ్యం. మీ అప్లికేషన్లలో provider credentials ని నిల్వ చేయాల్సిన అవసరం ఉండదు. ఒక మోడల్‌ను మార్చాలంటే, ఐదు వేర్వేరు సర్వీసులలో కోడ్ మార్చడానికి బదులుగా, సర్వర్‌లోని config ఫైల్‌లో ఒక లైన్ మార్చితే సరిపోతుంది. ప్రతి కాల్ ఒకే process ద్వారా వెళ్తుంది కాబట్టి, ఖర్చులను నియంత్రించడానికి మరియు ఎంత ఖర్చయిందో రికార్డు చేయడానికి మీకు ఒక కేంద్ర స్థానం ఉంటుంది.

ఇది రన్ అవుతున్నప్పుడు మీకు లభించే సౌకర్యాలు ఇవే:

• ఒకే endpoint. అప్లికేషన్లు https://gateway.example.com/v1 ని లక్ష్యంగా చేసుకుని, మీరు సృష్టించిన bulk లేదా strong వంటి మోడల్ పేరును అడుగుతాయి.
• Virtual keys. ప్రతి అప్లికేషన్‌కు దాని స్వంత మోడల్ allowlist మరియు ఖర్చు పరిమితి (spend ceiling) కలిగిన ప్రత్యేక key లభిస్తుంది. మీరు ఒక key ని రద్దు చేసినా మిగిలిన వాటికి ఎటువంటి ఇబ్బంది ఉండదు.
• Fallbacks. ఒక కాల్ విఫలమైనా లేదా prompt పరిమాణం ఎక్కువగా ఉన్నా, అది స్వయంచాలకంగా మరొక మోడల్‌తో ప్రయత్నిస్తుంది.
• Logged record. ప్రతి అభ్యర్థన దాని ఖర్చుతో సహా ఒక row గా నమోదవుతుంది, కాబట్టి "ఏ అప్లికేషన్ ఎంత ఖర్చు చేసింది" అనే ప్రశ్నకు సమాధానం దొరుకుతుంది.

గేట్‌వేను మీరే ఎందుకు నిర్వహించుకోవాలి

మేనేజ్డ్ రూటర్ కూడా అదే విధంగా పనిచేస్తుంది, కానీ ప్రతి అభ్యర్థన మధ్యలో మరొకరి ప్రాసెస్ ఉంటుంది. మీరే స్వయంగా నిర్వహించుకోవడం వల్ల, మీ ప్రొవైడర్ కీలు మరియు ప్రాంప్ట్ టెక్స్ట్ మీరు నియంత్రించే బాక్స్‌లోనే ఉంటాయి. దీనికి అయ్యే ఖర్చు వాస్తవం: ప్రతి అప్లికేషన్ ఆధారపడే ఈ కాంపోనెంట్‌ను ఇప్పుడు మీరే నిర్వహించాలి. ఈ గైడ్ యొక్క చివరి విభాగం ఆ ఖర్చు గురించి వివరిస్తుంది, ఎందుకంటే చాలా కథనాలు ఈ విషయాన్ని వదిలేస్తాయి.

మీకు కావలసినవి

• Ubuntu 24.04 నడుస్తున్న ఒక VPS (virtual private server), దీనిలో Docker మరియు Compose plugin ఇన్‌స్టాల్ అయి ఉండాలి.
• ఒక డొమైన్ పేరు, ఇది ఆ సర్వర్‌కు పాయింట్ అయి ఉండాలి (ఒకవేళ మీ సర్వర్ వెలుపల ఉన్న యంత్రాలు TLS (transport layer security) ద్వారా ఈ గేట్‌వేని చేరుకోవాలనుకుంటే).
• కనీసం ఒక ప్రొవైడర్ API key.

ఈ గేట్‌వే ఎటువంటి inference చేయదు. ఇది అభ్యర్థనలను ఫార్వర్డ్ చేస్తుంది మరియు సమాధానాలను తిరిగి స్ట్రీమ్ చేస్తుంది, కాబట్టి దీని CPU లోడ్ మోడల్ పరిమాణంపై కాకుండా అభ్యర్థనల సంఖ్యపై ఆధారపడి ఉంటుంది. 1 vCPU ఉన్న సర్వర్ ఎటువంటి ఇబ్బంది లేకుండా కొన్ని అంతర్గత అప్లికేషన్లను నిర్వహించగలదు. డేటాబేస్ పరిమాణం మాత్రం పెరుగుతుంది, ఎందుకంటే గేట్‌వే ప్రతి అభ్యర్థనకు ఒక spend row ను రికార్డ్ చేస్తుంది.

Write config.yaml first

The config file decides which models a client may ask for. Four top level sections matter: model_list, litellm_settings, router_settings and general_settings.

model_list:
  - model_name: bulk
    litellm_params:
      model: anthropic/claude-haiku-4-5
      api_key: os.environ/ANTHROPIC_API_KEY
  - model_name: strong
    litellm_params:
      model: anthropic/claude-sonnet-5
      api_key: os.environ/ANTHROPIC_API_KEY
  - model_name: strong
    litellm_params:
      model: openai/gpt-5.5
      api_key: os.environ/OPENAI_API_KEY

litellm_settings:
  num_retries: 2
  request_timeout: 120
  allowed_fails: 3
  cooldown_time: 30
  json_logs: true
  set_verbose: false

router_settings:
  fallbacks: [{"bulk": ["strong"]}]
  context_window_fallbacks: [{"bulk": ["strong"]}]

general_settings:
  background_health_checks: true
  health_check_interval: 300

model_name is the name your clients send. litellm_params.model is the real model, written as provider/model. Name your models after the job rather than after the vendor. An application that asks for bulk keeps working when you decide next month that bulk should be a different model.

api_key: os.environ/ANTHROPIC_API_KEY tells LiteLLM to read that variable at run time. The literal key never appears in the file, which matters because config.yaml is the file you commit.

Two entries share the name strong, on purpose. When more than one deployment carries the same model_name, the router treats them as interchangeable and tries the other one when the first fails. That is how strong survives one provider having a bad hour.

num_retries: 2 retries the same deployment on a retryable error. A fallback only fires after those retries are used up. allowed_fails: 3 with cooldown_time: 30 pulls a deployment out of rotation for 30 seconds once it has failed 3 times, so a provider returning 500s stops being tried on every single request.

fallbacks and context_window_fallbacks have different triggers, and the second one is the useful one people skip.

• fallbacks fires when the primary call fails.
• context_window_fallbacks fires when the provider rejects the request for being longer than that model's context window, so an oversized prompt goes to a model with room for it instead of returning an error to the caller.

There is also content_policy_fallbacks, for a provider refusing on content policy grounds. Set it only if you have somewhere sensible to send those calls.

Docker Compose ఉపయోగించి VPSపై LiteLLMను డిప్లాయ్ చేయడం

మూడు ఫైళ్లను కలిగి ఉండే ఒక డైరెక్టరీని సృష్టించండి: config.yaml, docker-compose.yml మరియు .env. అప్‌స్ట్రీమ్ క్విక్‌స్టార్ట్ latest ట్యాగ్‌ను పుల్ చేస్తుంది. దానికి బదులుగా ఒక నిర్దిష్ట రిలీజ్ ట్యాగ్‌ను పిన్ చేయండి. దీనివల్ల వచ్చే నెలలో docker compose up -d చేసినప్పుడు, ఈరోజు మీకు లభించిన అదే గేట్‌వే లభిస్తుంది, మరియు రోల్‌బ్యాక్ చేయడం కూడా ఒకే లైన్ పని అవుతుంది.

services:
  litellm:
    image: ghcr.io/berriai/litellm:v1.95.0
    restart: unless-stopped
    command: ["--config", "/app/config.yaml", "--num_workers", "1"]
    ports:
      - "127.0.0.1:4000:4000"
    volumes:
      - ./config.yaml:/app/config.yaml:ro
    env_file: .env
    depends_on:
      db:
        condition: service_healthy

  db:
    image: postgres:16
    restart: unless-stopped
    environment:
      POSTGRES_USER: litellm
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD:?set POSTGRES_PASSWORD in .env}
      POSTGRES_DB: litellm
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U litellm"]
      interval: 5s
      timeout: 5s
      retries: 10
    volumes:
      - postgres_data:/var/lib/postgresql/data

volumes:
  postgres_data:

Compose ఇక్కడ .envను రెండుసార్లు చదువుతుంది. ఒకసారి compose ఫైల్‌లోనే ${POSTGRES_PASSWORD}ను సబ్‌స్టిట్యూట్ చేయడానికి, మరొకసారి env_file ద్వారా ప్రతి వేరియబుల్‌ను కంటైనర్‌లోకి పంపడానికి.

v1.95.0 అనేది ఆగస్టు 2026 నాటి ప్రస్తుత రిలీజ్. ప్రాజెక్ట్ యొక్క రిలీజెస్ పేజీని తనిఖీ చేసి, మీరు డిప్లాయ్ చేసే సమయానికి ఏది కరెంట్‌గా ఉంటే దానిని పిన్ చేయండి. ప్రతి రిలీజ్ ఒక సిగ్నేచర్‌ను పబ్లిష్ చేస్తుంది, కాబట్టి మీరు ఇమేజ్‌ను నమ్మే ముందు దానిని తనిఖీ చేయవచ్చు:

cosign verify --key https://raw.githubusercontent.com/BerriAI/litellm/v1.95.0/cosign.pub ghcr.io/berriai/litellm:v1.95.0

పోర్ట్ లైన్ 127.0.0.1:4000:4000గా ఉంది, ఇది లూప్‌బ్యాక్ ఇంటర్‌ఫేస్‌పై మాత్రమే పోర్ట్‌ను పబ్లిష్ చేస్తుంది. దీనికి బదులుగా 4000:4000 అని రాస్తే, మీ గేట్‌వే మొత్తం ఇంటర్నెట్ నుండి అందుబాటులోకి వస్తుంది. ఎందుకంటే Docker తన సొంత రూల్స్‌ను iptables FORWARD చైన్‌లో జోడిస్తుంది మరియు అవి ufw రూల్స్ కంటే ముందే మూల్యాంకనం చేయబడతాయి, కాబట్టి ufw deny 4000 దీనిని ఆపలేదు. సెల్ఫ్-హోస్టెడ్ గేట్‌వేలు అనుకోకుండా ఓపెన్ అవ్వడానికి ఇది అత్యంత సాధారణ మార్గం: Docker కంటైనర్ పోర్ట్‌ను ufw దాటి ఎలా పబ్లిష్ చేస్తుందో చూడండి. బయటి నుండి వచ్చే ట్రాఫిక్ రివర్స్ ప్రాక్సీ ద్వారానే రావాలి.

ప్రొవైడర్ కీలను ఇమేజ్ వెలుపల ఉంచండి

.env ఫైల్ అన్ని రహస్యాలను (secrets) కలిగి ఉంటుంది. ఇది రన్ టైమ్‌లో environment వేరియబుల్‌గా పంపబడుతుంది, కాబట్టి ఇది ఎప్పటికీ ఇమేజ్‌లో ఉండదు మరియు ఎప్పటికీ కమిట్ చేయబడదు.

LITELLM_MASTER_KEY=sk-REPLACE_ME
LITELLM_SALT_KEY=sk-REPLACE_ME_TOO
POSTGRES_PASSWORD=REPLACE_ME_AS_WELL
DATABASE_URL=postgresql://litellm:REPLACE_ME_AS_WELL@db:5432/litellm
STORE_MODEL_IN_DB=True
LITELLM_MODE=PRODUCTION
LITELLM_LOG=ERROR
ANTHROPIC_API_KEY=sk-ant-...
OPENAI_API_KEY=sk-proj-...

రెండు LiteLLM కీలను సరైన randomness తో రూపొందించండి, ఆపై ఫైల్‌ను లాక్ చేయండి:

printf 'sk-%s\n' "$(openssl rand -hex 32)"
chmod 600 .env

LITELLM_MASTER_KEY అనేది అడ్మిన్ క్రెడెన్షియల్. ఇది మేనేజ్‌మెంట్ APIని ప్రామాణీకరిస్తుంది మరియు /ui వద్ద ఉన్న Admin UI కోసం ఇది పాస్‌వర్డ్. ఏ అప్లికేషన్ కూడా దీనిని కలిగి ఉండకూడదు.

LITELLM_SALT_KEY అనేది డేటాబేస్‌లో నిల్వ చేయబడిన ప్రొవైడర్ క్రెడెన్షియల్స్‌ను ఎన్‌క్రిప్ట్ చేస్తుంది. దీనిని ఒక్కసారి సెట్ చేసి వదిలేయండి. దీనిని తర్వాత మార్చితే, ఇప్పటికే నిల్వ ఉన్న క్రెడెన్షియల్స్‌ను డిక్రిప్ట్ చేయడం సాధ్యపడదు. అప్పుడు గేట్‌వే సాధారణంగానే ప్రారంభమవుతుంది, కానీ ఆ ప్రొవైడర్లకు చేసే ప్రతి కాల్ ప్రామాణీకరణ (authentication) విఫలమవుతుంది.

STORE_MODEL_IN_DB=True ద్వారా మీరు config.yaml ను తాకకుండానే Admin UI నుండి మోడళ్లను జోడించవచ్చు మరియు సవరించవచ్చు. ఇది సౌకర్యవంతంగా ఉంటుంది, కానీ ఇది మీ source of truth ను రెండుగా విభజిస్తుంది. ఏది ప్రామాణికమో నిర్ణయించుకుని, ఆ నిర్ణయాన్ని config పక్కన రాసి ఉంచండి.

కీలను కాన్ఫిగరేషన్ ఫైల్ వెలుపల ఉంచడానికి గల కారణాలే, మీరు ఏజెంట్‌కు ఇచ్చే టూల్స్ నుండి వాటిని దూరంగా ఉంచడానికి కూడా వర్తిస్తాయి. ప్రొవైడర్ రహస్యాలను AI ఏజెంట్ల నుండి దూరంగా ఉంచడం ఈ పద్ధతిని వివరిస్తుంది, మరియు Docker Compose లో env ఫైళ్లు మరియు రహస్యాలు దీనికి సంబంధించిన సాంకేతిక అంశాలను వివరిస్తుంది.

దీనిని ప్రారంభించి, మొదటి బూట్ ప్రక్రియను గమనించండి:

docker compose up -d
docker compose logs -f litellm

ఇది నిజంగా పనిచేస్తుందో లేదో తనిఖీ చేయండి

ఇక్కడ రెండు అథెంటికేషన్ అవసరం లేని ప్రోబ్‌లు మరియు ఒకటి అథెంటికేషన్ అవసరమైన ప్రోబ్ ఉన్నాయి, ఇవి వేర్వేరు కారణాల వల్ల విఫలమవుతాయి.

curl -s http://127.0.0.1:4000/health/liveliness
curl -s http://127.0.0.1:4000/health/readiness

/health/liveliness కు ఎటువంటి అథెంటికేషన్ అవసరం లేదు మరియు ప్రాసెస్ నడుస్తున్నంత సేపు "I'm alive!" అని సమాధానం ఇస్తుంది. /health/readiness కు కూడా అథెంటికేషన్ అవసరం లేదు. ఇది "status": "healthy" మరియు db ఫీల్డ్‌లతో కూడిన JSON ఆబ్జెక్ట్‌ను తిరిగి ఇస్తుంది, లేదా డేటాబేస్ అందుబాటులో లేనప్పుడు 503 ఎర్రర్‌ను ఇస్తుంది. మీ మానిటరింగ్‌ను readiness వైపు మళ్లించండి, ఎందుకంటే ఒకే వర్చువల్ కీని కూడా వెతకలేని గేట్‌వేపై liveliness ఎప్పుడూ గ్రీన్‌గానే ఉంటుంది.

అథెంటికేషన్ అవసరమైన చెక్ ప్రొవైడర్లతో కమ్యూనికేట్ చేస్తుంది:

curl -s http://127.0.0.1:4000/health \
  -H "Authorization: Bearer $LITELLM_MASTER_KEY"

ఇది healthy_endpoints మరియు unhealthy_endpoints అర్రేలతో సమాధానం ఇస్తుంది. unhealthy_endpoints లో ఉన్న మోడల్ అథెంటికేషన్ ఎర్రర్‌ను చూపిస్తుందంటే, .env లోని ప్రొవైడర్ కీ తప్పుగా ఉందని లేదా లేదని అర్థం, మీరు ఇప్పుడు కనుగొనవలసిన వైఫల్యం ఇదే. background_health_checks: true సెట్ చేయబడినందున, ప్రాక్సీ ఈ ప్రోబ్‌లను ప్రతి health_check_interval సెకన్లకు స్వయంగా రన్ చేస్తుంది మరియు /health చివరి ఫలితాన్ని తిరిగి ఇస్తుంది, కాబట్టి దీనిని పోల్ చేయడం వల్ల ప్రతిసారీ మీ ప్రొవైడర్లకు టెస్ట్ రిక్వెస్ట్ వెళ్లదు.

వర్చువల్ కీలు మరియు ప్రతి కీకి బడ్జెట్ పరిమితులు

ప్రతి అప్లికేషన్ మాస్టర్ కీ ఆధారంగా రూపొందించబడిన దాని స్వంత కీని పొందుతుంది.

curl -s http://127.0.0.1:4000/key/generate \
  -H "Authorization: Bearer $LITELLM_MASTER_KEY" \
  -H 'Content-Type: application/json' \
  -d '{
    "key_alias": "nightly-summariser",
    "models": ["bulk"],
    "max_budget": 5,
    "budget_duration": "30d",
    "rpm_limit": 60,
    "tpm_limit": 200000
  }'

ప్రతిస్పందనలో sk- తో ప్రారంభమయ్యే key ఫీల్డ్ ఉంటుంది. అప్లికేషన్‌కు అందేది ఆ స్ట్రింగ్ మాత్రమే, మరియు అది మాత్రమే దానికి అందుబాటులో ఉంటుంది.

• models అనేది ఈ కీ దేనిని అభ్యర్థించవచ్చో తెలిపే అనుమతుల జాబితా (allowlist). పైన ఉన్న కీ bulk ని మాత్రమే అడగగలదు, వేరే దేనినీ కాదు.
• max_budget: 5 మరియు budget_duration: "30d" కలిపి ఉంటే, అది ప్రతి 30 రోజుల కాలానికి ఐదు అమెరికన్ డాలర్ల బడ్జెట్‌ను సూచిస్తుంది, ఆ తర్వాత కీ పనిచేయడం ఆగిపోతుంది.
• rpm_limit మరియు tpm_limit ఈ కీకి మాత్రమే నిమిషానికి ఎన్ని అభ్యర్థనలు (requests) మరియు ఎన్ని టోకెన్లు ఉండాలో పరిమితిని విధిస్తాయి.
• key_alias అనేది ఆరు వారాల తర్వాత మీరు ఖర్చుల లాగ్ (spend log) లో గుర్తించగలిగే పేరు. దీన్ని ఎల్లప్పుడూ సెట్ చేయండి.

బడ్జెట్ అయిపోయినప్పుడు, కాల్ HTTP 401 ఎర్రర్‌తో విఫలమవుతుంది మరియు ఈ క్రింది ఆకృతిలో బాడీని కలిగి ఉంటుంది:

ExceededBudget: Current spend for token: 7.2e-05; Max Budget for Token: 2e-07

ఈ స్టేటస్ కోడ్ వల్ల గందరగోళం ఏర్పడుతుంది. క్లయింట్ లైబ్రరీ 401ని అథెంటికేషన్ సమస్యగా చూపిస్తుంది, కాబట్టి స్టాక్ ట్రేస్‌ను చదివే డెవలపర్ కీ చెల్లుబాటు అవుతుందో లేదో తనిఖీ చేయడం ప్రారంభిస్తారు. స్టేటస్ కోడ్‌తో పాటు రెస్పాన్స్ బాడీని కూడా లాగ్ చేయండి, లేకపోతే బడ్జెట్ అయిపోవడం ప్రతిసారీ పాడైపోయిన క్రెడెన్షియల్ లాగా కనిపిస్తుంది.

అదే మేనేజ్‌మెంట్ API ద్వారా కీలను తనిఖీ చేయండి మరియు సర్దుబాటు చేయండి:

curl -s "http://127.0.0.1:4000/key/info?key=sk-..." \
  -H "Authorization: Bearer $LITELLM_MASTER_KEY"

curl -s -X POST http://127.0.0.1:4000/key/update \
  -H "Authorization: Bearer $LITELLM_MASTER_KEY" \
  -H 'Content-Type: application/json' \
  -d '{"key": "sk-...", "max_budget": 25}'

గేట్‌వే వద్ద అమలు చేయబడిన బడ్జెట్, ఏజెంట్ స్వయంగా విఫలమైనప్పుడు కూడా పనిచేస్తుంది, అందుకే ఇది VPSలో AI ఏజెంట్ల కోసం ఖర్చు నియంత్రణకు వెన్నెముకగా ఉంటుంది.

తక్కువ ఖర్చుతో కూడిన మోడల్‌కు బల్క్ పనులను పంపడం

క్లయింట్‌ను గేట్‌వే వైపు మళ్లించండి. Base URL, కీ, మరియు మోడల్ పేరును ఇలా సెట్ చేయండి:

curl -s http://127.0.0.1:4000/v1/chat/completions \
  -H "Authorization: Bearer sk-<the virtual key>" \
  -H 'Content-Type: application/json' \
  -d '{
    "model": "bulk",
    "messages": [{"role": "user", "content": "Say hello in five words."}]
  }'

ఏదైనా OpenAI క్లయింట్ లైబ్రరీ ఇదే విధంగా పనిచేస్తుంది: base_url ను https://gateway.example.com/v1 గా, మరియు api_key ను వర్చువల్ కీగా సెట్ చేయండి.

config.yaml లోని రూటింగ్ పాలసీ ఇప్పుడు కాల్ చేసే వారికి తెలియకుండానే వర్తిస్తుంది. bulk కోసం వచ్చే అభ్యర్థన తక్కువ ఖర్చుతో కూడిన మోడల్‌కు వెళ్తుంది. ఒకవేళ ఆ కాల్ దాని retries తర్వాత విఫలమైతే, ఆ అభ్యర్థనను strong కి వ్యతిరేకంగా మళ్ళీ ప్రయత్నిస్తుంది. ఒకవేళ ప్రాంప్ట్ bulk కి చాలా పెద్దదిగా ఉంటే, context_window_fallbacks దాన్ని ఎర్రర్ చూపడానికి బదులుగా strong కి పంపుతుంది. క్లాసిఫికేషన్ పాస్ లేదా సమ్మరైజింగ్ బ్యాక్‌లాగ్ వంటి బల్క్ పనులు డిఫాల్ట్‌గా తక్కువ ఖర్చుతో పూర్తవుతాయి, కేవలం కష్టమైన అభ్యర్థనలకు మాత్రమే ఎక్కువ ఖర్చవుతుంది.

టూల్స్ ఉపయోగించే ఏజెంట్లతో గేట్‌వే ఎందుకు అవసరమో ఇక్కడ అర్థమవుతుంది. ఒకే VPSలో ఉన్న MCP (model context protocol) server మరియు దానిని నడిపే ఏజెంట్ రెండూ ఒకే ఎండ్‌పాయింట్‌ను సూచించగలవు, కాబట్టి వాటిని మళ్ళీ డిప్లాయ్ చేయాల్సిన అవసరం లేకుండానే వెనుక ఉన్న మోడల్‌ను మార్చవచ్చు.

Fallback జరిగిందని ఎలా తెలుసుకోవాలి?

ఇది డబ్బు ఖర్చయ్యే వైఫల్య విధానం, ఎందుకంటే ఏదీ పాడైపోయినట్లు కనిపించదు. విజయవంతమైన fallback సాధారణ HTTP 200 ప్రతిస్పందనను మరియు సాధారణ బాడీని అందిస్తుంది. మీ చౌకైన మోడల్ ఒక రోజు పాటు డౌన్ అవ్వవచ్చు, ప్రతి కాల్ నిశ్శబ్దంగా ఖరీదైన మోడల్ ద్వారా సర్వ్ చేయబడవచ్చు, దీనికి మొదటి నిదర్శనం మీ బిల్లు మాత్రమే.

దీనికి సంబంధించిన ఆధారాలు రెస్పాన్స్ హెడర్లలో ఉంటాయి. వాటిని ఇలా అడగండి:

curl -s -D - -o /dev/null http://127.0.0.1:4000/v1/chat/completions \
  -H "Authorization: Bearer sk-<the virtual key>" \
  -H 'Content-Type: application/json' \
  -d '{"model":"bulk","messages":[{"role":"user","content":"ping"}]}' \
  | grep -i '^x-litellm'

• x-litellm-model-group అనేది క్లయింట్ అడిగిన మోడల్. x-litellm-model-id అనేది సమాధానం ఇచ్చిన డిప్లాయ్‌మెంట్. ఈ రెండూ వేర్వేరుగా ఉన్నప్పుడు, fallback జరిగినట్లు అర్థం.
• x-litellm-attempted-fallbacks మరియు x-litellm-attempted-retries వీటిని లెక్కిస్తాయి. సాధారణ స్థితిలో ఉన్న కాల్‌లో ఈ రెండు 0 గా ఉంటాయి.
• x-litellm-response-cost అనేది ఆ ఒక్క కాల్‌కు అయిన ఖర్చు (US డాలర్లలో).
• x-litellm-call-id అనేది మీ లాగ్స్‌లో అదే కాల్‌ను కనుగొనడానికి మీరు ఉపయోగించే ఐడెంటిఫైయర్.

ప్రతి అభ్యర్థనపై x-litellm-attempted-fallbacks ని రికార్డ్ చేయండి మరియు అది 0 కాకుండా మారినప్పుడు అలర్ట్ సెట్ చేయండి. పనిచేసే రూటింగ్ పాలసీకి మరియు నిశ్శబ్దంగా "ఎల్లప్పుడూ ఖరీదైన మోడల్‌నే వాడండి" అని మారిపోయిన రూటింగ్ పాలసీకి మధ్య ఉన్న వ్యత్యాసం ఆ ఒక్క సంఖ్యే.

దీని పూర్తి వెర్షన్ ట్రేసింగ్, దీనికి ప్రత్యేక సెటప్ అవసరం: ఏజెంట్ కాల్‌లను ట్రేస్ చేయడానికి self-hosted Langfuse. LiteLLM ఈ callback ను కలిగి ఉంటుంది, కాబట్టి దీన్ని అనుసంధానించడం రెండు లైన్ల కోడ్ మరియు క్రెడెన్షియల్స్ తో పూర్తవుతుంది.

litellm_settings:
  success_callback: ["langfuse"]
  failure_callback: ["langfuse"]

LANGFUSE_PUBLIC_KEY=pk-lf-...
LANGFUSE_SECRET_KEY=sk-lf-...
LANGFUSE_HOST=https://langfuse.example.com

failure_callback తో పాటు success_callback ని కూడా సెట్ చేయండి. దీన్ని వదిలేస్తే, ఏ సమస్య లేని అభ్యర్థనల ట్రేస్‌లు మాత్రమే మీకు మిగులుతాయి. వీటితో సంబంధం లేకుండా, LiteLLM ప్రతి అభ్యర్థనకు ఒక spend row ను Postgres లోకి రాస్తుంది మరియు /ui వద్ద ఉన్న Admin UI ఆ టేబుల్‌ను చదువుతుంది. ట్రాఫిక్ పెరిగేకొద్దీ ఇది పెరుగుతుంది, కాబట్టి చిన్న డిస్క్ ఉన్నప్పుడు దీన్ని గమనిస్తూ ఉండండి.

గేట్‌వేను రివర్స్ ప్రాక్సీ వెనుక ఉంచడం

బాహ్య ప్రపంచం నుంచి ఏదీ నేరుగా port 4000 ను చేరుకోకూడదు. TLS ను nginx లేదా Caddy లో ముగించి (terminate చేసి), దానిని loopback అడ్రస్‌కు ఫార్వర్డ్ చేయండి.

location / {
    proxy_pass http://127.0.0.1:4000;
    proxy_http_version 1.1;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_buffering off;
    proxy_read_timeout 600s;
}

పైన పేర్కొన్న వాటిలో రెండు లైన్లను చాలామంది విస్మరిస్తుంటారు. proxy_buffering off అనేది చాలా ముఖ్యం, ఎందుకంటే స్ట్రీమింగ్ కంప్లీషన్ అనేది server-sent events యొక్క వరుస క్రమం. nginx లో buffering ఆన్‌లో ఉంటే, అది ప్రతి భాగాన్ని (chunk) రెస్పాన్స్ పూర్తయ్యే వరకు ఆపి ఉంచుతుంది. దీనివల్ల క్లయింట్ ఏమీ రానట్లుగా నిశ్శబ్దంగా ఉండి, చివరకు మొత్తం సమాచారాన్ని ఒకేసారి పొందుతుంది. proxy_read_timeout 600s కూడా అంతే ముఖ్యం, ఎందుకంటే సుదీర్ఘమైన జనరేషన్ ప్రక్రియ nginx యొక్క 60 సెకన్ల డిఫాల్ట్ సమయాన్ని దాటిపోతుంది. అలా జరిగినప్పుడు, క్లయింట్‌కు 504 error వస్తుంది మరియు error log లో upstream timed out (110: Connection timed out) while reading response header from upstream నమోదవుతుంది.

సర్టిఫికేట్ కోసం, nginx పై Certbot మరియు Let's Encrypt వాడటం సులభమైన మార్గం. ఒకవేళ ఆ సర్వర్ ఇప్పటికే అనేక కంటైనర్లను నడుపుతుంటే, అనేక Compose అప్లికేషన్ల ముందు Traefik వాడటం ద్వారా రూటింగ్ మరియు సర్టిఫికేట్లను ఒకే చోట నిర్వహించవచ్చు.

గేట్‌వే ఇప్పుడు ఒకే వైఫల్య బిందువుగా (single point of failure) మారింది

మీరు నిర్మించిన దాని గురించి వాస్తవంగా ఉండండి. మీరు కలిగి ఉన్న ప్రతి అప్లికేషన్ ఇప్పుడు ఒక VPSలోని ఒకే కంటైనర్‌పై ఆధారపడి ఉంది. అది ఆగిపోయినప్పుడు, ఏ మోడల్‌ను కూడా పిలవలేరు, పూర్తిగా ఆరోగ్యంగా ఉన్న ప్రొవైడర్లు కూడా అందుబాటులో ఉండరు. దీని వల్ల నాలుగు పరిణామాలు ఉంటాయి.

• తప్పుడు కాన్ఫిగరేషన్ మొత్తం వ్యవస్థను ఒకేసారి నిలిపివేస్తుంది. restart: unless-stopped క్రాష్‌ను రీస్టార్ట్ చేస్తుంది, కానీ అది config.yaml ను పార్స్ చేయలేని కంటైనర్‌ను పదేపదే రీస్టార్ట్ చేస్తుంది. ప్రతి కాన్ఫిగరేషన్ మార్పు తర్వాత docker compose logs litellm ను చదవండి, మరియు వాటిని పర్యవేక్షించడానికి సమయం ఉన్నప్పుడు మాత్రమే కాన్ఫిగరేషన్ మార్పులు చేయండి.
• Postgres అభ్యర్థన మార్గంలో (request path) ఉంటుంది. వర్చువల్ కీ లుకప్ మరియు ఖర్చుల నమోదు రెండూ దీనినే ఉపయోగిస్తాయి. /health/readiness 503 ఎర్రర్‌ను ఇస్తుందంటే, గేట్‌వే నడుస్తున్నప్పటికీ ఏ పని చేయలేకపోతోందని అర్థం.
• ఒక దానిని పెద్దదిగా చేయడం కంటే, మరిన్ని ఇన్‌స్టాన్స్‌లను జోడించడం ద్వారా స్కేల్ చేయండి. ప్రాజెక్ట్ మార్గదర్శకాల ప్రకారం, ఒక డేటాబేస్‌ను పంచుకునే అనేక ఇన్‌స్టాన్స్‌లతో ప్రతి ఇన్‌స్టాన్స్‌కు ఒక వర్కర్ (--num_workers 1) ఉండాలి. లోడ్ బ్యాలెన్సర్ వెనుక రెండు చిన్న గేట్‌వేలను ఉంచడం ద్వారా ఒకే కంటైనర్‌పై ఆధారపడటాన్ని తొలగించవచ్చు. కానీ ఇది డేటాబేస్ సమస్యను తొలగించదు.
• మీరు తిరిగి సృష్టించలేని వాటిని బ్యాకప్ చేయండి. అంటే config.yaml మరియు .env, వీటితో పాటు డేటాబేస్ యొక్క pg_dump. LITELLM_SALT_KEY పోగొట్టుకుంటే, ఆ డంప్‌లోని ఎన్‌క్రిప్ట్ చేయబడిన ప్రొవైడర్ క్రెడెన్షియల్స్ పనికిరాకుండా పోతాయి, కాబట్టి env ఫైల్ మరియు డంప్ రెండూ ఒకే బ్యాకప్ జాబ్‌లో ఉండాలి: restic ద్వారా ఆఫ్-బాక్స్ స్టోరేజ్‌కు బ్యాకప్‌లు.

అప్‌గ్రేడ్ చేయడం అంటే ఇమేజ్ ట్యాగ్‌ను ఎడిట్ చేసి docker compose up -d రన్ చేయడం. LiteLLM డిఫాల్ట్‌గా స్టార్టప్‌లో prisma migrate deploy ను రన్ చేస్తుంది, కాబట్టి కొత్త కంటైనర్ మొదటిసారి బూట్ అయినప్పుడు డేటాబేస్ స్కీమాను మైగ్రేట్ చేస్తుంది. ట్యాగ్‌ను మార్చడానికి ముందే డంప్ తీసుకోండి, ఎందుకంటే పాత ఇమేజ్‌ను తిరిగి ఉంచడం వల్ల ఇప్పటికే జరిగిన మైగ్రేషన్ వెనక్కి వెళ్లదు.

FAQ

LiteLLM ప్రతి కాల్‌కు గుర్తించదగ్గ జాప్యాన్ని (latency) కలిగిస్తుందా?

ఆగస్టు 2026 నాటి దాని README ప్రకారం, సెకనుకు 1000 అభ్యర్థనల వద్ద 95వ పర్సంటైల్ వద్ద 8 ms జాప్యం ఉంటుందని ఈ ప్రాజెక్ట్ పేర్కొంది. దీనిని ఒక వెండర్ గణాంకంగా మాత్రమే పరిగణించండి. మీ జాప్యాన్ని వాస్తవంగా ప్రభావితం చేసే అంశం మీ అప్లికేషన్లకు మరియు గేట్‌వేకు మధ్య ఉన్న నెట్‌వర్క్ దూరం, ఎందుకంటే మీరు ప్రతి కాల్‌కు ఒక అదనపు రౌండ్ ట్రిప్‌ను జోడించారు. గేట్‌వేను కాల్ చేసే అప్లికేషన్లు ఉన్న అదే రీజియన్‌లో రన్ చేయండి, ఆపై వాస్తవ ప్రతిస్పందనపై x-litellm-overhead-duration-ms హెడర్‌తో మీ స్వంత ఓవర్‌హెడ్‌ను కొలవండి.

nginxను ముందు ఉంచిన తర్వాత స్ట్రీమింగ్ ఎందుకు పనిచేయడం లేదు?

ఎందుకంటే nginx డిఫాల్ట్‌గా అప్‌స్ట్రీమ్ ప్రతిస్పందనలను బఫర్ చేస్తుంది మరియు స్ట్రీమింగ్ కంప్లీషన్ అనేది సర్వర్-పంపిన ఈవెంట్‌ల (server-sent events) వరుస క్రమం. proxy_buffering ఆన్‌లో ఉన్నప్పుడు, nginx ఆ భాగాలను సేకరించి ప్రతిస్పందన పూర్తయినప్పుడు మాత్రమే విడుదల చేస్తుంది, కాబట్టి క్లయింట్ నిశ్శబ్దంగా వేచి ఉండి, చివరకు మొత్తం సమాధానాన్ని ఒకేసారి అందుకుంటుంది. location బ్లాక్‌లో proxy_buffering off; సెట్ చేయండి. అదే బ్లాక్‌లో proxy_read_timeout విలువను పెంచండి, లేకపోతే సుదీర్ఘమైన జనరేషన్ nginx యొక్క 60 సెకన్ల డిఫాల్ట్ సమయాన్ని మించిపోతుంది మరియు క్లయింట్‌కు 504 ఎర్రర్ వస్తుంది.

వర్చువల్ కీ బడ్జెట్ అయిపోయినప్పుడు ఏమి జరుగుతుంది?

కాల్ HTTP 401 ఎర్రర్‌తో విఫలమవుతుంది మరియు ExceededBudget: Current spend for token: 7.2e-05; Max Budget for Token: 2e-07 రూపంలో బాడీని కలిగి ఉంటుంది. ఈ 401 ఒక ఉచ్చు: క్లయింట్ లైబ్రరీ దీనిని అథెంటికేషన్ వైఫల్యంగా చూపిస్తుంది, కాబట్టి ప్రజలు సందేశాన్ని చదవడానికి బదులుగా కీ చెల్లుబాటు అవుతుందో లేదో తనిఖీ చేయడం ప్రారంభిస్తారు. స్టేటస్ కోడ్‌తో పాటు రెస్పాన్స్ బాడీని లాగ్ చేయండి. మాస్టర్ కీకి వ్యతిరేకంగా /key/info?key=sk-... తో కీ యొక్క అసలు స్థితిని నిర్ధారించుకోండి మరియు బడ్జెట్ చాలా తక్కువగా సెట్ చేయబడితే /key/update తో పరిమితిని పెంచండి.

గేట్‌వే హోస్ట్ చేసిన మోడళ్లతో పాటు లోకల్ మోడల్‌కు కూడా రూట్ చేయగలదా?

అవును, ఇది model_list లో మరొక ఎంట్రీ అవుతుంది. ollama_chat/ ప్రిఫిక్స్‌ను api_base తో ఉపయోగించండి, ఉదాహరణకు api_base: http://ollama:11434 తో పాటు model: ollama_chat/llama3.1. కంటైనర్ లోపల నుండి, localhost అంటే ఆ కంటైనర్ అని అర్థం, కాబట్టి Docker నెట్‌వర్క్‌లో Compose సర్వీస్ పేరును లేదా హోస్ట్ అడ్రస్‌ను ఉపయోగించండి, ఎప్పుడూ 127.0.0.1 ఉపయోగించవద్దు. లోకల్ మోడల్‌ను సిద్ధం చేయడం అనేది ఒక ప్రత్యేక పని: Ollamaతో VPSలో LLMను self-hosting చేయడం చూడండి.