ஆல் Matt Connor 2026-08-05 · புதுப்பிக்கப்பட்டது 2026-08-13

LiteLLM-ஐ சொந்தமாக host செய்வது எப்படி?

Q: ஒரு virtual key-ன் வரவு செலவுத் திட்டம் (budget) தீர்ந்துவிட்டால் என்ன நடக்கும்?

அழைப்பு HTTP 401 பிழையுடன் தோல்வியடையும் மற்றும் அதன் body ExceededBudget: Current spend for token: 7.2e-05; Max Budget for Token: 2e-07 வடிவில் இருக்கும். இந்த 401 ஒரு பொறி: client library இதை ஒரு அங்கீகாரத் தோல்வியாக (authentication failure) அறிக்கை செய்யும், எனவே மக்கள் செய்தியைப் படிப்பதற்குப் பதிலாக key செல்லுபடியாகுமா என்று சரிபார்க்கத் தொடங்குவார்கள். Status code-உடன் சேர்த்து response body-ஐயும் log செய்யவும். Master key-க்கு எதிராக /key/info?key=sk-... மூலம் key-ன் உண்மையான நிலையை உறுதிப்படுத்தவும், வரவு செலவுத் திட்டம் மிகக் குறைவாக அமைக்கப்பட்டிருந்தால் /key/update மூலம் அதன் உச்சவரம்பை அதிகரிக்கவும்.

Q: Gateway உள்ளூர் மாதிரிகளுக்கும் (local model) மற்றும் ஹோஸ்ட் செய்யப்பட்ட மாதிரிகளுக்கும் routing செய்ய முடியுமா?

ஆம், இது model_list-ல் மற்றொரு உள்ளீடாக அமையும். ollama_chat/ prefix-ஐ api_base-உடன் பயன்படுத்தவும், உதாரணமாக api_base: http://ollama:11434-உடன் சேர்த்து model: ollama_chat/llama3.1-ஐப் பயன்படுத்தலாம். ஒரு container-க்குள் இருந்து, localhost என்பது அந்த container-ஐக் குறிக்கும், எனவே Docker network-ல் உள்ள Compose service பெயர் அல்லது host-ன் முகவரியைப் பயன்படுத்தவும், ஒருபோதும் 127.0.0.1-ஐப் பயன்படுத்த வேண்டாம். உள்ளூர் மாதிரியை நிறுவுவது ஒரு தனி வேலை: Ollama மூலம் VPS-ல் LLM-ஐ சுயமாக ஹோஸ்ட் செய்தல் என்பதைப் பார்க்கவும்.

உங்கள் அனைத்து LLM தேவைகளுக்கும் ஒரே OpenAI-compatible endpoint-ஐ உருவாக்குங்கள். LiteLLM மூலம் virtual keys, per-key budgets மற்றும் fallbacks ஆகியவற்றை எளிதாக நிர்வகிக்கலாம்.

self-hosted LLM gateway-ன் செயல்பாடுகள்

LiteLLM என்பது நீங்கள் சொந்தமாக host செய்யும் ஒரு open source LLM gateway ஆகும். இது ஒரு HTTP endpoint-ஐ வழங்குகிறது; உங்கள் அனைத்து applications-ம் இந்த endpoint-ஐ அழைக்கும், இது ஒவ்வொரு கோரிக்கையையும் (request) அதற்குரிய provider-க்கு அனுப்பி வைக்கும். LLM என்பது large language model-ஐக் குறிக்கும். இந்த gateway, OpenAI chat completions API (application programming interface)-ஐப் பயன்படுத்துகிறது. எனவே, ஏற்கனவே OpenAI-உடன் தொடர்புகொள்ளும் எந்தவொரு client library-யும், base URL மற்றும் key ஆகிய இரண்டையும் மாற்றிய பிறகு இதனுடன் வேலை செய்யும்.

இந்த ஒரு அடுக்கு மறைமுகத்தன்மை (indirection) தான் இதன் முக்கிய நோக்கம். உங்கள் applications-ல் provider credentials-ஐச் சேமிக்க வேண்டிய அவசியம் இருக்காது. ஒரு model-ஐ மாற்றுவதற்கு, ஐந்து வெவ்வேறு services-ல் code மாற்றங்களுக்குப் பதிலாக, server-ல் உள்ள ஒரு config file-ல் ஒரே ஒரு வரியை மாற்றினால் போதும். மேலும், ஒவ்வொரு அழைப்பும் ஒரே process வழியாகச் செல்வதால், செலவு வரம்பை (budget) நிர்ணயிக்கவும், எவ்வளவு செலவாகியுள்ளது என்பதற்கான பதிவை (record) வைத்திருக்கவும் ஒரு மைய இடம் கிடைக்கிறது.

இது இயங்கத் தொடங்கியதும் உங்களுக்குக் கிடைப்பவை:

ஒரே endpoint. Applications https://gateway.example.com/v1-ஐ இலக்காகக் கொண்டு, நீங்கள் உருவாக்கிய bulk அல்லது strong போன்ற model பெயர்களைக் கேட்கும்.
Virtual keys. ஒவ்வொரு application-க்கும் தனித்தனி key வழங்கப்படும்; அவற்றுக்கென தனித்தனி model allowlist மற்றும் செலவு வரம்பு (spend ceiling) இருக்கும். மற்றவற்றை பாதிக்காமல் நீங்கள் ஒரு key-ஐ மட்டும் revoke செய்ய முடியும்.
Fallbacks. ஒரு அழைப்பு தோல்வியடைந்தாலோ அல்லது prompt அளவு அதிகமாக இருந்தாலோ, அது தானாகவே வேறொரு model-க்கு மாற்றப்பட்டு மீண்டும் முயற்சி செய்யப்படும் (retry).
பதிவு செய்யப்பட்ட விவரங்கள் (logged record). ஒவ்வொரு கோரிக்கையும் அதன் செலவு விவரங்களுடன் பதிவு செய்யப்படும், எனவே "எந்த application அந்தச் செலவைச் செய்தது" என்பதற்கான விடை கிடைக்கும்.

ஏன் gateway-ஐ நீங்களே இயக்க வேண்டும்

Managed router என்பது மற்றொன்றின் process ஒவ்வொரு கோரிக்கையின் (request) இடையிலும் அமர்ந்திருக்கும் ஒரு அமைப்பாகும். நீங்களே இயக்கும்போது, உங்கள் provider keys மற்றும் prompt text ஆகியவை நீங்கள் கட்டுப்படுத்தும் ஒரு பெட்டியில் (box) இருக்கும். இதற்கான செலவு உண்மையானது: ஒவ்வொரு application-ம் சார்ந்திருக்கும் ஒரு கூறினை (component) இப்போது நீங்கள் இயக்குகிறீர்கள். இந்த வழிகாட்டியின் கடைசிப் பகுதி அந்தச் செலவைப் பற்றியது, ஏனெனில் பெரும்பாலான கட்டுரைகள் விடுபடும் பகுதி இதுவே.

தேவையானவை

Ubuntu 24.04 இயங்கும் ஒரு VPS (virtual private server), அதில் Docker மற்றும் Compose plugin நிறுவப்பட்டிருக்க வேண்டும்.
இயந்திரத்திற்கு வெளியே உள்ள பிற கணினிகள் TLS (transport layer security) மூலம் gateway-ஐ அணுக வேண்டுமெனில், அதற்கு ஒரு domain name சுட்டிக்காட்டப்பட்டிருக்க வேண்டும்.
குறைந்தபட்சம் ஒரு provider API key.

இந்த gateway எந்தவொரு inference-ஐயும் செய்வதில்லை. இது கோரிக்கைகளை (requests) முன்னனுப்பி, பதில்களைத் திரும்பப் பெறுகிறது. எனவே, இதன் CPU பயன்பாடு model-ன் அளவை விட, கோரிக்கைகளின் எண்ணிக்கையைப் பொறுத்தே அமையும். ஒரு 1 vCPU கொண்ட கணினியில் எந்தப் புகாருமின்றி பல internal applications-களை இயக்க முடியும். தரவுத்தளம் (database) மட்டுமே வளரும், ஏனெனில் ஒவ்வொரு கோரிக்கைக்கும் ஒரு spend row-ஐ gateway பதிவு செய்கிறது.

முதலில் config.yaml கோப்பை எழுதவும்

இந்த config கோப்பு, எந்தெந்த மாதிரிகளை (models) ஒரு client கோரலாம் என்பதைத் தீர்மானிக்கிறது. இதில் நான்கு முக்கிய பிரிவுகள் உள்ளன: model_list, litellm_settings, router_settings மற்றும் 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 என்பது உங்கள் client-கள் அனுப்பும் பெயர். litellm_params.model என்பது உண்மையான மாதிரி, இது provider/model என எழுதப்படும். மாதிரிகளுக்கு விற்பனையாளரின் பெயரை வைப்பதற்குப் பதிலாக, அவை செய்யும் பணியின் பெயரைச் சூட்டுங்கள். bulk என்று கோரும் ஒரு application, அடுத்த மாதம் நீங்கள் bulk-ஐ வேறொரு மாதிரியாக மாற்றினாலும் தொடர்ந்து வேலை செய்யும்.

api_key: os.environ/ANTHROPIC_API_KEY, அந்த variable-ஐ runtime-ல் வாசிக்குமாறு LiteLLM-க்கு அறிவுறுத்துகிறது. உண்மையான key இந்த கோப்பில் இடம்பெறாது; config.yaml கோப்பை நீங்கள் commit செய்வதால் இது முக்கியமானது.

இரண்டு பதிவுகள் வேண்டுமென்றே strong என்ற ஒரே பெயரைப் பகிர்ந்து கொள்கின்றன. ஒன்றுக்கும் மேற்பட்ட deployment-கள் ஒரே model_name-ஐக் கொண்டிருக்கும்போது, router அவற்றை ஒன்றுக்கொன்று மாற்றாகக் கருதி, முதலாவது தோல்வியுற்றால் மற்றொன்றை முயற்சிக்கும். ஒரு provider-ல் சிக்கல் ஏற்படும்போது, strong எவ்வாறு தொடர்ந்து இயங்குகிறது என்பதற்கான வழி இதுவே.

num_retries: 2, மீண்டும் முயற்சி செய்யக்கூடிய (retryable) பிழை ஏற்படும்போது அதே deployment-ல் மீண்டும் முயற்சிக்கும். அந்த முயற்சிகள் அனைத்தும் முடிந்த பிறகுதான் fallback செயல்படும். allowed_fails: 3 உடன் cooldown_time: 30-ஐப் பயன்படுத்தும்போது, ஒரு deployment 3 முறை தோல்வியடைந்தால், அது 30 வினாடிகளுக்குச் சுழற்சியிலிருந்து (rotation) நீக்கப்படும். இதனால், 500 பிழைகளைத் தரும் ஒரு provider, ஒவ்வொரு கோரிக்கையின் போதும் மீண்டும் மீண்டும் முயற்சி செய்யப்படுவதைத் தவிர்க்கலாம்.

fallbacks மற்றும் context_window_fallbacks வெவ்வேறு தூண்டுதல்களைக் (triggers) கொண்டுள்ளன. இதில் இரண்டாவதுதான் பயனுள்ளது, ஆனால் பலர் இதைப் புறக்கணிக்கிறார்கள்.

fallbacks, முதன்மை அழைப்பு (primary call) தோல்வியடையும் போது செயல்படும்.
context_window_fallbacks, ஒரு மாதிரி அதன் context window-வை விடக் கோரிக்கை நீளமாக இருப்பதால் நிராகரிக்கும்போது செயல்படும். இதனால், பெரிய prompt-கள் பிழையைத் தருவதற்குப் பதிலாக, இடவசதி கொண்ட மற்றொரு மாதிரிக்கு அனுப்பப்படும்.

மேலும், உள்ளடக்கக் கொள்கை (content policy) அடிப்படையில் ஒரு provider மறுக்கும்போது செயல்பட content_policy_fallbacks உள்ளது. அத்தகைய அழைப்புகளை அனுப்பத் தகுந்த இடம் இருந்தால் மட்டுமே இதை அமைக்கவும்.

Docker Compose மூலம் VPS-ல் LiteLLM-ஐ நிறுவுதல்

config.yaml, docker-compose.yml மற்றும் .env ஆகிய மூன்று கோப்புகளைக் கொண்ட ஒரு கோப்பகத்தை (directory) உருவாக்கவும். இதற்கான quickstart வழிகாட்டி latest tag-ஐப் பயன்படுத்த பரிந்துரைக்கிறது. அதற்குப் பதிலாக ஒரு குறிப்பிட்ட release tag-ஐப் பயன்படுத்தவும். அப்போதுதான், அடுத்த மாதம் docker compose up -d-ஐ இயக்கும்போதும் இன்று உங்களுக்குக் கிடைத்த அதே gateway பதிப்பு கிடைக்கும்; மேலும், ஒரு வரியில் rollback செய்யவும் இது உதவும்.

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 வழியாக அனைத்து மாறிகளையும் (variables) container-க்குள் அனுப்பவும் இது பயன்படுகிறது.

ஆகஸ்ட் 2026-ல் v1.95.0 என்பது தற்போதைய வெளியீடாக இருந்தது. நீங்கள் நிறுவும் போது, திட்டத்தின் releases பக்கத்தைச் சரிபார்த்து, தற்போதைய பதிப்பைப் பயன்படுத்தவும். ஒவ்வொரு வெளியீட்டிற்கும் ஒரு signature வெளியிடப்படுகிறது; எனவே, ஒரு image-ஐ நம்புவதற்கு முன்பு அதை நீங்கள் சரிபார்க்கலாம்:

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

Port வரி என்பது 127.0.0.1:4000:4000 ஆகும், இது loopback interface-ல் மட்டுமே port-ஐ வெளியிடுகிறது. அதற்குப் பதிலாக 4000:4000 என்று எழுதினால், உங்கள் gateway இணையம் முழுவதிலிருந்தும் அணுகக்கூடியதாகிவிடும். ஏனெனில், Docker தனது சொந்த விதிகளை iptables FORWARD chain-ல் சேர்க்கிறது; இவை ufw-ன் விதிகளுக்கு முன்பே மதிப்பீடு செய்யப்படுவதால், ufw deny 4000 அதைத் தடுக்காது. ஒரு self-hosted gateway தற்செயலாகத் திறக்கப்படுவதற்கு இதுவே பொதுவான காரணமாகும்: Docker எவ்வாறு ufw-ஐத் தாண்டி container port-ஐ வெளியிடுகிறது என்பதைப் பார்க்கவும். வெளிப்புறத்திலிருந்து வரும் traffic, reverse proxy வழியாகவே வர வேண்டும்.

Provider keys-ஐ image-க்குள் வைக்க வேண்டாம்

.env கோப்பு அனைத்து ரகசியங்களையும் கொண்டுள்ளது. இது run time-ல் environment-ஆக வழங்கப்படுகிறது, எனவே இது ஒருபோதும் image-க்குள் பதிக்கப்படுவதில்லை, மேலும் இது ஒருபோதும் commit செய்யப்படுவதில்லை.

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 keys-ஐ உண்மையான சீரற்ற தன்மையுடன் (randomness) உருவாக்கி, பின் கோப்பைப் பாதுகாக்கவும்:

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

LITELLM_MASTER_KEY என்பது நிர்வாகி சான்றாகும் (admin credential). இது management API-ஐ அங்கீகரிக்கிறது மற்றும் /ui-ல் உள்ள Admin UI-க்கான கடவுச்சொல்லாகும். எந்தவொரு application-மும் இதை வைத்திருக்கக்கூடாது.

LITELLM_SALT_KEY என்பது database-ல் சேமிக்கப்பட்டுள்ள provider சான்றுகளை குறியாக்க (encrypt) செய்கிறது. இதை ஒருமுறை அமைத்து அப்படியே விட்டுவிடவும். இதை மாற்றினால், ஏற்கனவே சேமிக்கப்பட்ட சான்றுகளை மறைகுறியாக்க (decrypt) முடியாது; இதனால் gateway சாதாரணமாகத் தொடங்கும், ஆனால் அந்த providers-க்கு செய்யப்படும் ஒவ்வொரு அழைப்பும் அங்கீகாரப் பிழையில் (authentication failure) முடியும்.

STORE_MODEL_IN_DB=True, config.yaml-ஐத் தொடாமலேயே Admin UI-லிருந்து models-ஐச் சேர்க்கவும் திருத்தவும் உங்களை அனுமதிக்கிறது. இது வசதியானது, ஆனால் இது உங்கள் source of truth-ஐ இரண்டாகப் பிரிக்கிறது. எது முதன்மையானது என்பதை முடிவு செய்து, அந்த முடிவை config-க்கு அருகில் எழுதி வைக்கவும்.

config கோப்பில் keys-ஐ வைக்காமல் இருப்பதற்கான அதே காரணம்தான், நீங்கள் ஒரு agent-க்கு வழங்கும் கருவிகளிலும் அவற்றை வைக்காமல் இருக்க உதவுகிறது. AI agents-ல் provider secrets-ஐத் தவிர்த்தல் அந்த முறையை விளக்குகிறது, மேலும் Docker Compose-ல் env கோப்புகள் மற்றும் secrets அதன் செயல்பாடுகளை விளக்குகிறது.

இதை இயக்கி, முதல் boot-ஐக் கவனிக்கவும்:

docker compose up -d
docker compose logs -f litellm

இது சரியாகச் செயல்படுகிறதா என்று சரிபார்த்தல்

அங்கீகாரம் தேவைப்படாத இரண்டு ஆய்வுகளும் (probes), அங்கீகாரம் தேவைப்படும் ஒரு ஆய்வும் உள்ளன. இவை வெவ்வேறு காரணங்களுக்காகத் தோல்வியடைகின்றன.

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 object-ஐத் தரும்; database-ஐ அணுக முடியாவிட்டால் 503 பிழையைத் தரும். உங்கள் கண்காணிப்பு அமைப்பை readiness-க்கு அமைக்கவும், ஏனெனில் ஒரு virtual key-ஐக் கண்டறிய முடியாத gateway-லும் liveliness எப்போதும் green நிலையிலேயே இருக்கும்.

provider-களுடன் தொடர்புகொள்ளும் அங்கீகாரம் தேவைப்படும் ஆய்வு இது:

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

இது healthy_endpoints மற்றும் unhealthy_endpoints arrays மூலம் பதிலளிக்கும். unhealthy_endpoints-ல் உள்ள ஒரு model, அங்கீகாரப் பிழையைக் காட்டினால், .env-ல் உள்ள provider key தவறாகவோ அல்லது விடுபட்டோ உள்ளது என்று பொருள். நீங்கள் இப்போது கண்டறிய வேண்டிய தோல்வி இதுதான். background_health_checks: true அமைக்கப்பட்டிருப்பதால், proxy இந்த ஆய்வுகளைத் தானாகவே ஒவ்வொரு health_check_interval வினாடிகளுக்கும் இயக்கும். /health அதன் கடைசி முடிவை மட்டுமே வழங்கும், எனவே நீங்கள் polling செய்யும்போது ஒவ்வொரு முறையும் provider-களுக்குப் புதிய test request அனுப்பப்படாது.

Virtual keys மற்றும் per-key வரவுசெலவுத் திட்டங்கள்

ஒவ்வொரு application-க்கும் அதன் சொந்த key வழங்கப்படுகிறது, இது master key-க்கு எதிராக உருவாக்கப்படுகிறது.

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
  }'

பதிலானது key என்ற புலத்தைக் கொண்டுள்ளது, அது sk--ல் தொடங்குகிறது. அந்த string-தான் application-க்குக் கிடைப்பது, அது மட்டுமே application-க்கு எப்போதும் கிடைக்கும் ஒரே விஷயமாகும்.

models என்பது இந்த key எதைக் கோரலாம் என்பதற்கான allowlist ஆகும். மேலே உள்ள key bulk-ஐ மட்டுமே கேட்க முடியும், வேறு எதையும் கேட்க முடியாது.
max_budget: 5 மற்றும் budget_duration: "30d" என்பது ஒவ்வொரு 30 நாட்களுக்கும் ஐந்து அமெரிக்க டாலர்கள் ஆகும், அதன் பிறகு key வேலை செய்வதை நிறுத்திவிடும்.
rpm_limit மற்றும் tpm_limit ஆகியவை இந்த key-க்கான ஒரு நிமிடத்திற்கான கோரிக்கைகள் மற்றும் ஒரு நிமிடத்திற்கான tokens ஆகியவற்றைக் கட்டுப்படுத்துகின்றன.
key_alias என்பது ஆறு வாரங்களுக்குப் பிறகு spend log-ல் நீங்கள் அடையாளம் காணக்கூடியது. இதை எப்போதும் அமைக்கவும்.

வரவுசெலவுத் திட்டம் தீர்ந்துவிட்டால், அழைப்பு HTTP 401 பிழையுடன் தோல்வியடையும் மற்றும் அதன் உடல் பகுதி இந்த வடிவத்தில் இருக்கும்:

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

இந்த status code குழப்பத்தை ஏற்படுத்துகிறது. ஒரு client library 401-ஐ authentication சிக்கலாகப் புகாரளிக்கிறது, எனவே stack trace-ஐப் படிக்கும் developer, key செல்லுபடியாகுமா என்று சரிபார்க்கத் தொடங்குகிறார். status code-க்கு அருகில் response body-ஐ log செய்யவும், இல்லையெனில் வரவுசெலவுத் திட்டம் தீர்ந்துபோனது ஒவ்வொரு முறையும் உடைந்த credential போலத் தோன்றும்.

அதே management API மூலம் key-களை ஆய்வு செய்து சரிசெய்யவும்:

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}'

gateway-ல் அமல்படுத்தப்படும் வரவுசெலவுத் திட்டம், agent-ல் ஏதேனும் தவறு நடந்தாலும் சரியாகச் செயல்படும், அதனால்தான் இது VPS-ல் AI agents-க்கான செலவுக் கட்டுப்பாடு-ன் முதுகெலும்பாக உள்ளது.

குறைந்த கட்டண மாடலுக்கு மொத்தமாக பணிகளை அனுப்புதல்

Gateway-ஐ நோக்கி client-ஐ அமைக்கவும். Base URL, key, மற்றும் model name ஆகியவற்றை உள்ளிடவும்:

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 client library-யும் ஒரே மாதிரியாகவே செயல்படும்: base_url-ஐ https://gateway.example.com/v1 என்றும், api_key-ஐ virtual key என்றும் அமைக்கவும்.

config.yaml-ல் உள்ள routing policy, அழைப்பவருக்குத் தெரியாமலேயே இப்போது செயல்படும். bulk-க்கான கோரிக்கை குறைந்த கட்டண மாடலுக்குச் செல்லும். அந்த அழைப்பு அதன் retries-க்குப் பிறகும் தோல்வியடைந்தால், strong-க்கு எதிராக மீண்டும் முயற்சி செய்யப்படும். ஒருவேளை prompt-ன் நீளம் bulk-க்கு அதிகமாக இருந்தால், context_window_fallbacks அதை பிழையைத் தருவதற்குப் பதிலாக strong-க்கு அனுப்பிவிடும். வகைப்படுத்துதல் (classification) அல்லது சுருக்கம் செய்தல் (summarising) போன்ற மொத்தப் பணிகள் இயல்பாகவே குறைந்த கட்டணத்தில் இயங்கும், கடினமான கோரிக்கைகளுக்கு மட்டுமே கூடுதல் செலவாகும்.

Tool-களைப் பயன்படுத்தும் agents-க்கு Gateway எங்கு பயனுள்ளதாக இருக்கும் என்பது இங்கேதான் தெரிகிறது. ஒரே VPS-ல் உள்ள MCP (model context protocol) server மற்றும் அதை இயக்கும் agent ஆகிய இரண்டுமே ஒரே endpoint-ஐ சுட்டிக்காட்ட முடியும். இதனால், இரண்டையும் மீண்டும் deploy செய்யாமலேயே அவற்றுக்குப் பின்னால் உள்ள மாடலை மாற்ற முடியும்.

Fallback நிகழ்ந்ததை எவ்வாறு கண்டறிவது?

இது பண இழப்பை ஏற்படுத்தும் ஒரு தோல்வி நிலை, ஏனெனில் எதுவும் பழுதடைந்ததாகத் தெரியாது. ஒரு வெற்றிகரமான fallback, சாதாரண response body-உடன் HTTP 200 நிலையைத் தரும். உங்கள் மலிவான model ஒரு நாள் முழுவதும் முடங்கியிருக்கலாம், ஒவ்வொரு அழைப்பும் விலையுயர்ந்த model மூலம் அமைதியாக நிறைவேற்றப்பட்டிருக்கலாம்; இதற்கான முதல் ஆதாரம் உங்கள் invoice மட்டுமே.

இதற்கான ஆதாரம் response headers-ல் உள்ளது. அவற்றைச் சரிபார்க்கவும்:

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 என்பது client கோரியது. x-litellm-model-id என்பது பதிலளித்த deployment ஆகும். இவை இரண்டும் பொருந்தவில்லை என்றால், fallback நிகழ்ந்துள்ளது என்று அர்த்தம்.
x-litellm-attempted-fallbacks மற்றும் x-litellm-attempted-retries ஆகியவை அவற்றின் எண்ணிக்கையைக் குறிக்கின்றன. ஆரோக்கியமான அழைப்பில் இவை இரண்டும் 0 ஆக இருக்கும்.
x-litellm-response-cost என்பது அந்த ஒரு அழைப்பிற்கான அமெரிக்க டாலர் மதிப்பிலான செலவு ஆகும்.
x-litellm-call-id என்பது உங்கள் logs-ல் அதே அழைப்பைக் கண்டறிய நீங்கள் பயன்படுத்தும் அடையாளங்காட்டி (identifier) ஆகும்.

ஒவ்வொரு கோரிக்கையிலும் x-litellm-attempted-fallbacks-ஐப் பதிவு செய்து, அது 0 ஆக இல்லாதபோது எச்சரிக்கை (alert) அனுப்பவும். அந்த ஒரு எண் தான், சரியாகச் செயல்படும் routing policy-க்கும், அமைதியாக "எப்போதும் விலையுயர்ந்த model-ஐப் பயன்படுத்து" என்று மாறிய routing policy-க்கும் உள்ள வித்தியாசம்.

இதன் முழுமையான வடிவம் tracing ஆகும், இதற்குத் தனிப்பட்ட அமைப்பு தேவை: tracing agent அழைப்புகளுக்கான self-hosted Langfuse. LiteLLM-ல் callback வசதி உள்ளதால், அதை இணைப்பது இரண்டு வரிகள் மற்றும் credentials-ஐப் பொறுத்தது.

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 ஆகியவற்றை அமைக்கவும். இதைத் தவிர்த்தால், எந்தப் பிழையும் ஏற்படாத கோரிக்கைகளை மட்டுமே நீங்கள் trace செய்ய முடியும். இதிலிருந்து தனித்தனியாக, LiteLLM ஒவ்வொரு கோரிக்கைக்கான செலவு விவரத்தையும் Postgres-ல் எழுதும், மேலும் /ui-ல் உள்ள Admin UI அந்த அட்டவணையைப் படிக்கும். traffic அதிகரிக்க அதிகரிக்க இதுவும் வளரும் என்பதால், சிறிய disk-ல் இதைக் கண்காணித்து வரவும்.

Gateway-ஐ reverse proxy-க்கு பின்னால் வைத்தல்

பெட்டியின் (box) வெளிப்புறத்திலிருந்து எந்தவொரு இணைப்பும் port 4000-ஐ அடையக்கூடாது. Nginx அல்லது Caddy-ல் TLS termination செய்து, அதை 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 முக்கியமானது, ஏனெனில் streaming completion என்பது server-sent events-ன் தொடர் ஆகும். Nginx-ல் buffering இயக்கப்பட்டிருந்தால், response முடியும் வரை அது chunks-ஐத் தடுத்து வைக்கும்; இதனால் client எந்தத் தகவலும் இன்றி காத்திருந்து, இறுதியில் அனைத்தையும் ஒரே நேரத்தில் பெறும். proxy_read_timeout 600s முக்கியமானது, ஏனெனில் நீண்ட generation செயல்முறை Nginx-ன் இயல்பான 60 வினாடி காலக்கெடுவைத் தாண்டிச் செல்லும். அவ்வாறு நிகழும்போது, client-க்கு 504 பிழை கிடைக்கும் மற்றும் error log-ல் upstream timed out (110: Connection timed out) while reading response header from upstream பதிவாகும்.

Certificate-க்கு, Nginx-ல் Let's Encrypt உடன் Certbot என்பது எளிதான வழியாகும். ஏற்கனவே பல containers இயங்கும் சூழல் என்றால், பல Compose apps-க்கு முன்னால் Traefik பயன்படுத்துவது routing மற்றும் certificates-ஐ ஒரே இடத்தில் கையாள உதவும்.

Gateway இப்போது ஒரு ஒற்றைப் புள்ளி தோல்வி (single point of failure) ஆகிவிட்டது

நீங்கள் உருவாக்கியுள்ள அமைப்பின் தன்மையை உணர்ந்து கொள்ளுங்கள். நீங்கள் வைத்திருக்கும் ஒவ்வொரு application-மும் இப்போது ஒரே VPS-ல் உள்ள ஒரே container-ஐச் சார்ந்துள்ளன. அது செயலிழந்தால், எந்தவொரு model-ஐயும் உங்களால் அழைக்க முடியாது; மிகச் சரியாக இயங்கும் provider-களும் கூட கிடைக்காது. இதிலிருந்து நான்கு விஷயங்கள் கவனிக்கப்பட வேண்டும்.

தவறான config அனைத்தையும் ஒரே நேரத்தில் முடக்கும். restart: unless-stopped ஒரு crash-ஐ மீண்டும் தொடங்கும், மேலும் config.yaml-ஐ parse செய்ய முடியாத ஒரு container-ஐ அது மீண்டும் மீண்டும் தொடங்கும். ஒவ்வொரு config மாற்றத்திற்குப் பிறகும் docker compose logs litellm-ஐப் படியுங்கள், மேலும் மாற்றங்களைக் கண்காணிக்கும் நேரம் இருக்கும்போது மட்டும் அவற்றைச் செய்யுங்கள்.
Postgres கோரிக்கை பாதையில் (request path) உள்ளது. Virtual key lookup மற்றும் spend recording ஆகிய இரண்டுமே இதைப் பயன்படுத்துகின்றன. /health/readiness 503 error-ஐத் தருகிறது என்றால், gateway இயங்குகிறது ஆனால் எதையும் செய்ய முடியவில்லை என்று அர்த்தம்.
ஒன்றை பெரிதாக்குவதற்குப் பதிலாக, பல instances-களைச் சேர்த்து அளவிடுங்கள் (scale). இந்த project-ன் வழிகாட்டுதல் என்னவென்றால், ஒரு instance-க்கு ஒரு worker (--num_workers 1) வீதம் பல instances-களை ஒரே database-ஐப் பகிரச் செய்வதாகும். Load balancer-க்கு பின்னால் இரண்டு சிறிய gateway-களை வைப்பது, ஒற்றை container சார்ந்த சிக்கலை நீக்கும். ஆனால் அது database சிக்கலை நீக்காது.
மீண்டும் உருவாக்க முடியாதவற்றை backup எடுங்கள். அது config.yaml மற்றும் .env, அத்துடன் database-ன் pg_dump ஆகியவற்றை உள்ளடக்கியது. LITELLM_SALT_KEY-ஐ இழந்துவிட்டால், அந்த dump-ல் உள்ள encrypted provider credentials பயனற்றதாகிவிடும். எனவே, env file மற்றும் dump ஆகியவற்றை ஒரே backup பணியில் சேர்ப்பது அவசியம்: restic மூலம் off-box storage-க்கு backup எடுத்தல்.

Upgrade செய்வது என்பது image tag-ஐ மாற்றி docker compose up -d-ஐ இயக்குவதாகும். LiteLLM இயல்பாகவே தொடக்கத்தில் prisma migrate deploy-ஐ இயக்குகிறது, எனவே புதிய container அதன் முதல் boot-ல் database schema-வை migrate செய்யும். Tag-ஐ மாற்றுவதற்கு முன் dump எடுத்துக்கொள்ளுங்கள், ஏனெனில் பழைய image-க்குத் திரும்புவது ஏற்கனவே நடந்த migration-ஐத் திரும்பப் பெறாது.

FAQ

ஒவ்வொரு அழைப்பிலும் LiteLLM குறிப்பிடத்தக்க தாமதத்தை (latency) ஏற்படுத்துமா?

ஆகஸ்ட் 2026-ல் அதன் README-ல் குறிப்பிட்டுள்ளபடி, வினாடிக்கு 1000 கோரிக்கைகள் என்ற விகிதத்தில் 95-வது சதவீதத்தில் 8 ms தாமதம் ஏற்படுவதாக இந்தத் திட்டம் தெரிவிக்கிறது. இதை ஒரு விற்பனையாளர் வழங்கும் புள்ளிவிவரமாகக் கருதவும். உங்கள் பயன்பாடுகளுக்கும் (applications) gateway-க்கும் இடையிலான பிணையத் தூரமே (network distance) உங்கள் தாமதத்தை நிர்ணயிக்கும் உண்மையான காரணியாகும், ஏனெனில் ஒவ்வொரு அழைப்பிலும் ஒரு கூடுதல் round trip-ஐ நீங்கள் சேர்த்துள்ளீர்கள். Gateway-ஐ அதை அழைக்கும் பயன்பாடுகள் இருக்கும் அதே பிராந்தியத்தில் (region) இயக்கி, உண்மையான பதிலில் உள்ள x-litellm-overhead-duration-ms header-ஐக் கொண்டு உங்கள் சொந்த overhead-ஐ அளவிடவும்.

Nginx-ஐ முன்னால் வைத்த பிறகு streaming ஏன் வேலை செய்யவில்லை?

Nginx இயல்பாகவே upstream பதில்களை buffer செய்வதாலும், streaming completion என்பது server-sent events-ன் தொடர் என்பதாலும் இது நிகழ்கிறது. proxy_buffering ஆன் செய்யப்பட்டிருக்கும்போது, Nginx துண்டுகளைச் சேகரித்து பதில் முழுமையாக முடிந்த பிறகு மட்டுமே வெளியிடுகிறது, எனவே client அமைதியாகக் காத்திருந்து முழு பதிலையும் ஒரே நேரத்தில் பெறுகிறது. Location block-ல் proxy_buffering off;-ஐ அமைக்கவும். அதே block-ல் proxy_read_timeout-ஐ அதிகரிக்கவும், இல்லையெனில் நீண்ட generation செயல்முறை Nginx-ன் இயல்பான 60 வினாடி காலாவதியைத் தாண்டிவிடும் மற்றும் client-க்கு 504 பிழை கிடைக்கும்.

ஒரு virtual key-ன் வரவு செலவுத் திட்டம் (budget) தீர்ந்துவிட்டால் என்ன நடக்கும்?

அழைப்பு HTTP 401 பிழையுடன் தோல்வியடையும் மற்றும் அதன் body ExceededBudget: Current spend for token: 7.2e-05; Max Budget for Token: 2e-07 வடிவில் இருக்கும். இந்த 401 ஒரு பொறி: client library இதை ஒரு அங்கீகாரத் தோல்வியாக (authentication failure) அறிக்கை செய்யும், எனவே மக்கள் செய்தியைப் படிப்பதற்குப் பதிலாக key செல்லுபடியாகுமா என்று சரிபார்க்கத் தொடங்குவார்கள். Status code-உடன் சேர்த்து response body-ஐயும் log செய்யவும். Master key-க்கு எதிராக /key/info?key=sk-... மூலம் key-ன் உண்மையான நிலையை உறுதிப்படுத்தவும், வரவு செலவுத் திட்டம் மிகக் குறைவாக அமைக்கப்பட்டிருந்தால் /key/update மூலம் அதன் உச்சவரம்பை அதிகரிக்கவும்.

Gateway உள்ளூர் மாதிரிகளுக்கும் (local model) மற்றும் ஹோஸ்ட் செய்யப்பட்ட மாதிரிகளுக்கும் routing செய்ய முடியுமா?

ஆம், இது model_list-ல் மற்றொரு உள்ளீடாக அமையும். ollama_chat/ prefix-ஐ api_base-உடன் பயன்படுத்தவும், உதாரணமாக api_base: http://ollama:11434-உடன் சேர்த்து model: ollama_chat/llama3.1-ஐப் பயன்படுத்தலாம். ஒரு container-க்குள் இருந்து, localhost என்பது அந்த container-ஐக் குறிக்கும், எனவே Docker network-ல் உள்ள Compose service பெயர் அல்லது host-ன் முகவரியைப் பயன்படுத்தவும், ஒருபோதும் 127.0.0.1-ஐப் பயன்படுத்த வேண்டாம். உள்ளூர் மாதிரியை நிறுவுவது ஒரு தனி வேலை: Ollama மூலம் VPS-ல் LLM-ஐ சுயமாக ஹோஸ்ட் செய்தல் என்பதைப் பார்க்கவும்.

#litellm #llm-gateway #self-hosted-ai #docker #cost-control

Built for exactly this: a fresh Ubuntu 24.04 KVM VPS with root.

SSD Nodes-ன் 15 ஆண்டுகள், அனைத்திற்கும் 15% தள்ளுபடி: எந்தத் திட்டமும், எந்தக் கட்டணச் சுழற்சியும், புதிய மற்றும் ஏற்கனவே உள்ள வாடிக்கையாளர்களும். முழு root access, 4TB தரவு பரிமாற்றம், 14 நாள் பணம் திரும்பப் பெறும் உத்தரவாதம்.

செலுத்தும் பக்கத்தில் LEARN15 குறியீடு உங்களுக்காகப் பயன்படுத்தப்படும்.

எனது 15% தள்ளுபடியைப் பெறுக →