LiteLLM Proxy 2026: LLM Gateway Đa Nhà Cu…

Q: LiteLLM Proxy có miễn phí không?

Có. LiteLLM là mã nguồn mở dưới giấy phép MIT, self-host tự do. Có bản LiteLLM Enterprise trả phí với SSO, SLA và audit log nâng cao, nhưng Proxy core đủ dùng cho phần lớn production workload mà không cần license.

Q: LiteLLM Proxy khác gì OpenRouter?

OpenRouter là managed multi-provider gateway (họ giữ key, bạn trả tiền qua họ). LiteLLM Proxy là self-hosted, bạn giữ key vendor, quản lý infra, không có middleman markup. Chọn LiteLLM khi bạn cần compliance, VPC-only, hoặc muốn kiểm soát dữ liệu tuyệt đối.

Q: Có cần Postgres để chạy LiteLLM Proxy không?

Không bắt buộc cho POC vì Proxy chạy với chỉ file YAML là được. Nhưng để dùng virtual keys, budgets, team management, và fallback management endpoint mới (v1.85.0+), bạn cần bật database_url trỏ tới Postgres 12+ hoặc SQLite (chỉ dev).

Q: Semantic cache của LiteLLM có tương thích multi-turn agent không?

Không nên. Tài liệu chính thức cảnh báo semantic cache sẽ replay response cũ trên multi-turn/agentic traffic. Với agent, bật cache chỉ cho tool call đơn hoặc classify task, tắt cho chat completion nhiều lượt. Có thể phân tách bằng cấu hình cache theo model_name hoặc route.

Q: Làm sao theo dõi chi phí per-team qua LiteLLM Proxy?

Tạo virtual key gắn với team_id qua /key/generate , đặt max_budget và budget_duration . Cost tracking tự ghi vào table LiteLLM_SpendLogs . Xem dashboard tại /ui hoặc query trực tiếp Postgres; nhiều team export sang BigQuery/Snowflake để join với billing data khác.

Cập nhật: 29 tháng 08, 2026

LiteLLM Proxy là một LLM gateway self-hosted mã nguồn mở (MIT license) đưa hơn 100 nhà cung cấp mô hình (OpenAI, Anthropic, Google, AWS Bedrock, Azure, vLLM, Ollama) về một endpoint tương thích OpenAI duy nhất, kèm virtual API keys, per-team budgets, cost tracking, fallback tự động và admin UI dựng sẵn. Nếu bạn đang phải juggle nhiều SDK, nhiều scheme xác thực và nhiều format request cho từng vendor, thì LiteLLM Proxy chính là lớp trừu tượng cần có ở giữa app và mô hình. Bài viết này dựng lại pipeline production hoàn chỉnh, từ config.yaml đến Kubernetes, kèm mọi footgun tôi đã đạp trúng trong 2026.

LiteLLM có hai lớp: Python SDK (thay thế drop-in cho openai) và Proxy (FastAPI server có virtual keys, budgets, fallback, cache). Bạn gần như luôn muốn triển khai Proxy trong production.
Auto Router mới ở v1.94.x (bản dev đầu tiên ngày 14/07/2026) kết hợp routing theo độ phức tạp, semantic và adaptive; semantic auto router cũ đã bị deprecated nhưng vẫn chạy.
Fallback endpoints mới từ v1.85.0 cho phép chỉnh fallback qua API mà không cần đụng vào config, an toàn hơn /config/update.
Semantic caching qua Redis cắt được 40–70% token cost trên traffic một-lần (single-shot), nhưng không dùng cho multi-turn agentic vì sẽ replay câu trả lời cũ.
Router chọn deployment order=2 ngay lập tức khi tất cả order=1 đang cooldown, không cần chờ hết fallback path.
Chạy nhiều replica Proxy behind load balancer, share state qua PostgreSQL; container image chính thức là ghcr.io/berriai/litellm:main-latest.

LiteLLM Proxy là gì và tại sao cần một LLM Gateway?

Thú thật, từ góc nhìn của một workflow architect, tôi hay vẽ pipeline LLM production đơn giản thế này: app → gateway → provider. Cái gateway ở giữa là chỗ bạn muốn tập trung toàn bộ logic xác thực, chọn model, retry, ghi log chi phí, chặn abuse, và chuyển đổi request. LiteLLM Proxy chính là gateway đó, với gói MIT license và FastAPI làm nền, phơi 100+ nhà cung cấp qua một endpoint /v1/chat/completions theo chuẩn OpenAI.

Trong thực tế 2026, hầu hết team AI production đang chạy đa nhà cung cấp: Opus 4.8 trên Anthropic cho reasoning phức tạp, GPT-5.4 mini/nano trên OpenAI cho latency thấp, Bedrock hoặc EKS khi dữ liệu phải nằm trên AWS. Mỗi vendor một SDK, một scheme xác thực, một shape request. Nếu app gọi trực tiếp, bạn phải viết ba (hoặc bốn) client, mỗi client có retry logic riêng, budget riêng, log riêng. Sau vài tháng, ai đó sẽ leak ANTHROPIC_API_KEY qua một notebook, và bạn không biết ai đã tiêu $8,000 trong bốn ngày. Tôi đã tận mắt chứng kiến chuyện này ở một team fintech nhỏ hồi Q1.

LiteLLM Proxy giải quyết bằng cách tách caller (developer, app) khỏi provider: mỗi caller nhận một virtual key (bắt đầu bằng sk-litellm-...) có budget riêng, RPM riêng, danh sách model cho phép riêng. Ai lộ key, bạn revoke key đó, không phải xoay OPENAI_API_KEY master trên tất cả provider. Xem tài liệu chính thức về config Proxy để nắm khung tổng thể.

LiteLLM SDK vs LiteLLM Proxy: nên chọn cái nào?

Câu hỏi này gần như lúc nào cũng được hỏi đầu tiên. Tôi chọn theo một quy tắc đơn giản: SDK là client, Proxy là platform. SDK giúp một developer đỡ mệt; Proxy giúp cả tổ chức governable.

Tiêu chí	LiteLLM SDK	LiteLLM Proxy
Cài đặt	`pip install litellm`, import và dùng	Docker/K8s, cần config.yaml, thường thêm Postgres
Virtual API keys	Không	Có, với budget/RPM/model list riêng
Multi-tenant / team	Không	Team, project, key hierarchy
Cost tracking chung	Log tại app	Trung tâm, dashboard UI, export SQL
Fallback / retry	Cấu hình trong code	Cấu hình trong YAML hoặc endpoint API
Semantic cache Redis	Có nhưng phải tự nối	Bật bằng khối `cache` trong YAML
Phù hợp cho	Prototype, script, notebook	Production, nhiều app, nhiều team

Trong pipeline tôi thường dựng (app FastAPI, workflow n8n, cộng vài script offline), cả ba đều gọi vào Proxy. Nhờ vậy, một quy tắc "chỉ được dùng claude-haiku-4-5 cho classify" viết một lần ở gateway là xong, không phải copy-paste vào ba codebase khác nhau. Nếu bạn đang xây một MCP server bằng Python với FastMCP làm tool layer, để MCP server gọi vào LiteLLM Proxy thay vì gọi trực tiếp OpenAI là pattern hợp lý. Bạn giữ được model routing và budget control ở một chỗ.

Cài đặt LiteLLM Proxy trong 10 phút

Cách nhanh nhất để có một Proxy chạy được là Docker. Tạo một file config.yaml tối giản, rồi mount vào container. Đây là setup tôi hay dùng khi mới POC:

# config.yaml — Proxy tối giản, 2 provider, 1 virtual key
model_list:
  - model_name: anthropic-sonnet
    litellm_params:
      model: anthropic/claude-sonnet-4-6
      api_key: os.environ/ANTHROPIC_API_KEY
  - model_name: openai-mini
    litellm_params:
      model: openai/gpt-5.4-mini
      api_key: os.environ/OPENAI_API_KEY

general_settings:
  master_key: sk-litellm-master-CHANGE-ME

# Chạy proxy trên port 4000
docker run -d \
  --name litellm \
  -p 4000:4000 \
  -e ANTHROPIC_API_KEY=$ANTHROPIC_API_KEY \
  -e OPENAI_API_KEY=$OPENAI_API_KEY \
  -v $(pwd)/config.yaml:/app/config.yaml \
  ghcr.io/berriai/litellm:main-latest \
  --config /app/config.yaml --port 4000

Sau đó gọi thử bằng chính SDK openai, không cần đổi thư viện:

from openai import OpenAI

# Trỏ base_url về Proxy, api_key là master key hoặc virtual key
client = OpenAI(
    base_url="http://localhost:4000",
    api_key="sk-litellm-master-CHANGE-ME",
)

resp = client.chat.completions.create(
    model="anthropic-sonnet",  # tên logic trong config.yaml
    messages=[{"role": "user", "content": "Xin chào từ LiteLLM"}],
)
print(resp.choices[0].message.content)

Cấu hình `config.yaml` cho production

File config.yaml là "trung tâm điều khiển" của Proxy. Khi store_model_in_db tắt, database không bao giờ được đọc để lấy config, nên YAML là nguồn duy nhất. Đây là bộ khung production đầy đủ tôi thường dùng, kèm chú giải theo từng section:

model_list:
  - model_name: chat-cheap
    litellm_params:
      model: openai/gpt-5.4-mini
      api_key: os.environ/OPENAI_API_KEY
      rpm: 10000
    model_info:
      mode: chat
      max_tokens: 128000
  - model_name: chat-smart
    litellm_params:
      model: anthropic/claude-sonnet-4-6
      api_key: os.environ/ANTHROPIC_API_KEY
      rpm: 4000
  - model_name: chat-smart          # cùng logical name, deployment thứ 2
    litellm_params:
      model: bedrock/anthropic.claude-sonnet-4-6-v1:0
      aws_region_name: us-east-1

router_settings:
  routing_strategy: simple-shuffle    # load-balance qua deployment cùng model_name
  num_retries: 3
  timeout: 30
  fallbacks:
    - chat-smart: ["chat-cheap"]
  context_window_fallbacks:
    - chat-cheap: ["chat-smart"]

litellm_settings:
  drop_params: true                   # bỏ param provider không hỗ trợ thay vì raise
  set_verbose: false
  cache: true
  cache_params:
    type: redis-semantic
    host: os.environ/REDIS_HOST
    port: 6379
    similarity_threshold: 0.85
    redis_semantic_cache_embedding_model: openai/text-embedding-3-small

general_settings:
  master_key: os.environ/LITELLM_MASTER_KEY
  database_url: os.environ/DATABASE_URL
  store_model_in_db: false
  proxy_budget_rescheduler_min_time: 600

Hai điểm dễ bỏ sót: một logical model_name có thể trỏ tới nhiều deployment, và Router sẽ shuffle qua chúng. Còn drop_params: true là cứu tinh khi bạn dùng cùng client cho nhiều provider; ví dụ Anthropic không có presence_penalty, LiteLLM sẽ tự bỏ thay vì crash.

Fallback và retry: sống sót khi provider chết

Nếu bạn từng bị OpenAI 429 kéo dài 20 phút giữa giờ cao điểm, bạn hiểu vì sao fallback là tính năng number one của LLM gateway. Router LiteLLM hỗ trợ ba loại fallback: error fallback (mọi lỗi trừ 429), rate-limit cooldown (429 → deployment vào cooldown), và context window fallback (request vượt max tokens → escalate lên model context lớn hơn).

Quy tắc order trong deployment quyết định thứ tự thử: nếu toàn bộ deployment order=1 đang trong cooldown, Router chọn thẳng order=2 ngay lập tức khi retry, và bạn không phải chờ hết fallback path. Đây là chi tiết tinh tế nhưng ảnh hưởng lớn đến p95 latency; hãy đọc kỹ tài liệu Fallbacks chính thức để nắm hết edge case.

Sequence diagram trong prose khi request chat-smart gặp lỗi 401:

Router chọn deployment Anthropic (order=1), nhận 401.
Deployment bị đánh dấu bad, không cooldown vì không phải 429.
Router thử deployment Bedrock cùng logical name, thành công và trả cho client.
Nếu Bedrock cũng lỗi, Router đi tiếp fallbacks: chat-smart → [chat-cheap].
Toàn bộ chain được ghi vào Langfuse trace với span cho từng deployment.

Từ v1.85.0 có endpoint quản lý fallback mới. Bạn thêm/sửa/xoá fallback qua REST mà không cần đụng vào file config. Điều kiện: STORE_MODEL_IN_DB=True và model phải đã tồn tại trong Router. Ngoài ra, ba tham số test mock_testing_fallbacks, mock_testing_context_fallbacks, mock_testing_content_policy_fallbacks bị strip khỏi request Proxy từ v1.85.0. Chúng chỉ còn tác dụng khi gọi trực tiếp litellm.Router trong unit test.

Semantic caching với Redis: cắt token cost

Bật cache là câu trả lời nhanh nhất cho câu hỏi "làm sao giảm 40% hóa đơn OpenAI tháng sau?". LiteLLM hỗ trợ ba loại: in-memory, Redis exact-match, và Redis semantic. Cấu hình trong khối cache_params đã ở phần config trên; điểm quan trọng là similarity_threshold. Tôi hay bắt đầu ở 0.85 rồi nới hoặc siết dựa trên A/B test.

litellm_settings:
  cache: true
  cache_params:
    type: redis-semantic
    host: redis.internal
    port: 6379
    similarity_threshold: 0.85
    redis_semantic_cache_embedding_model: openai/text-embedding-3-small
    semantic_cache_embedding_timeout: 5
    ttl: 3600

Cache hoạt động thế này: request đến, LiteLLM embed prompt bằng model bạn chỉ định, tìm nearest neighbor trong Redis; nếu cosine similarity ≥ threshold, trả response cũ (chỉ trong TTL). Cache miss thì gọi provider bình thường, embed và lưu lại. Bạn tiết kiệm cả token đầu vào lẫn output, thường 60–90% chi phí trên các endpoint FAQ/chatbot public. Chi tiết trong tài liệu Caching LiteLLM.

Auto Router v1.94.x: định tuyến thông minh theo độ phức tạp

Từ v1.92.x, LiteLLM giới thiệu routing plugins; đến v1.94.x (bản dev đầu tiên cut ngày 14/07/2026), Auto Router hợp nhất ba chiến lược cũ (complexity, semantic, adaptive) vào một hệ thống duy nhất. Ý tưởng: mỗi request được phân loại thành SIMPLE, MEDIUM, COMPLEX hoặc REASONING, rồi Router chọn model tương ứng.

Có bốn cách phân loại (bạn có thể kết hợp): heuristic scorer (đếm từ, độ dài, keyword), LLM classifier (dùng một model nhỏ như Haiku 4.5 hoặc GPT-5.4 nano với structured output), lexical/semantic keyword rules, hoặc plugin classifier tự viết. Semantic auto router cũ đã bị deprecated nhưng vẫn chạy để backward compatible.

auto_router_settings:
  enabled: true
  classifier: llm
  classifier_model: chat-cheap                    # dùng model rẻ để phân loại
  classifier_fallback: default_model
  complexity_router_default_model: chat-smart
  keyword_rules:
    - keyword: ["chứng minh", "prove", "derivation"]
      tier: REASONING
    - keyword: ["dịch", "translate", "tóm tắt"]
      tier: SIMPLE
  semantic_keyword_matching: true                 # cho phép match diễn giải
  tier_models:
    SIMPLE: chat-cheap
    MEDIUM: chat-smart
    COMPLEX: chat-smart
    REASONING: reasoning-o5

Khi nhiều rule cùng match, Router escalate lên tier cao nhất theo thứ tự SIMPLE < MEDIUM < COMPLEX < REASONING, nên thứ tự khai báo rule không âm thầm thay đổi behavior. Đây là một quyết định thiết kế tôi cực kỳ tán đồng sau vài lần bị "rule đầu tiên thắng" cắn ở project trước. Nếu LLM classifier timeout, trả rỗng hoặc lệch schema, Router fallback về heuristic scorer, cuối cùng về complexity_router_default_model. Muốn hiểu sâu hơn về cách ngữ cảnh ảnh hưởng đến kết quả classify, xem thêm bài context engineering cho ứng dụng AI production 2026.

Triển khai production: Postgres, load balancer, observability

Chạy Proxy trong production, kiến trúc tôi luôn dựng như sau: 3+ replica ghcr.io/berriai/litellm:main-latest sau HAProxy hoặc AWS ALB, share một PostgreSQL 15+ để lưu virtual keys, spend, và audit log. Rate-limit counter in-memory nằm ở từng replica, nhưng spend tổng và policy đều đọc từ Postgres, nên bạn thêm/xoá replica thoải mái.

# deployment.yaml (Kubernetes)
apiVersion: apps/v1
kind: Deployment
metadata:
  name: litellm-proxy
spec:
  replicas: 3
  selector:
    matchLabels: { app: litellm-proxy }
  template:
    metadata:
      labels: { app: litellm-proxy }
    spec:
      containers:
        - name: proxy
          image: ghcr.io/berriai/litellm:main-latest
          args: ["--config", "/app/config.yaml", "--port", "4000"]
          ports: [{ containerPort: 4000 }]
          env:
            - name: ANTHROPIC_API_KEY
              valueFrom: { secretKeyRef: { name: llm-keys, key: anthropic } }
            - name: OPENAI_API_KEY
              valueFrom: { secretKeyRef: { name: llm-keys, key: openai } }
            - name: LITELLM_MASTER_KEY
              valueFrom: { secretKeyRef: { name: llm-keys, key: master } }
            - name: DATABASE_URL
              valueFrom: { secretKeyRef: { name: llm-keys, key: pg } }
          volumeMounts:
            - name: config
              mountPath: /app/config.yaml
              subPath: config.yaml
          readinessProbe:
            httpGet: { path: /health/readiness, port: 4000 }
            initialDelaySeconds: 5
      volumes:
        - name: config
          configMap: { name: litellm-config }

Observability tối thiểu: bật Langfuse callback qua success_callback: ["langfuse"] trong litellm_settings. Mỗi request sẽ được trace kèm span cho từng deployment thử, span cache hit/miss, và metadata virtual key + team. Trên Postgres, table LiteLLM_SpendLogs cho phép query cost theo team/model/thời gian; tôi thường export nó sang BigQuery mỗi giờ để dashboard tài chính không đụng vào transaction DB.

Nếu bạn đã có pipeline đánh giá chất lượng như trong bài đánh giá RAG với RAGAS vs DeepEval 2026, hãy đưa Proxy vào giữa. Pipeline eval sẽ chạy song song trên cùng traffic thật thay vì replay log offline, và nhờ cache/fallback ổn định hơn, chỉ số RAGAS ít bị nhiễu bởi lỗi hạ tầng.

Sai lầm phổ biến khi triển khai LiteLLM Proxy

Ba năm dựng LLM gateway cho vài team khác nhau, đây là top-5 sai lầm tôi thấy lặp lại:

Bật semantic cache cho tất cả traffic. Chatbot đa lượt sẽ nhận response cũ và mất context; user báo bug, bạn debug hai ngày. Nguyên tắc: cache theo route, không theo global.
Không set rpm/tpm per deployment. Router load-balance dựa vào cấu hình rpm; nếu bỏ trống, một deployment yếu sẽ nhận traffic ngang deployment mạnh và làm p99 tăng vọt.
Fallback về cùng vendor. Anthropic Sonnet fallback sang Anthropic Haiku vô nghĩa khi cả tài khoản bị rate-limit. Fallback qua vendor khác, đó mới là mục đích của gateway.
Chạy Proxy chung network với app không segment. Bất cứ pod nào cũng gọi được /v1/chat/completions với master_key nghĩa là ai leak env cũng thành catastrophe. Tách namespace, tách Service, dùng virtual key.
Không dùng Postgres backend từ đầu. Thêm sau khi đã có 200 virtual key là chuyện đau đầu; enable từ POC, tốn không đáng bao nhiêu.

Muốn kiểm tra config nhanh, hãy chạy repo LiteLLM trên GitHub ở local với flag --detailed_debug. Bạn sẽ thấy từng bước router chọn deployment, retry, và cache lookup. Đó là công cụ debug tốt nhất trước khi lên staging.

Câu hỏi thường gặp

LiteLLM Proxy có miễn phí không?

Có. LiteLLM là mã nguồn mở dưới giấy phép MIT, self-host tự do. Có bản LiteLLM Enterprise trả phí với SSO, SLA và audit log nâng cao, nhưng Proxy core đủ dùng cho phần lớn production workload mà không cần license.

LiteLLM Proxy khác gì OpenRouter?

OpenRouter là managed multi-provider gateway (họ giữ key, bạn trả tiền qua họ). LiteLLM Proxy là self-hosted, bạn giữ key vendor, quản lý infra, không có middleman markup. Chọn LiteLLM khi bạn cần compliance, VPC-only, hoặc muốn kiểm soát dữ liệu tuyệt đối.

Có cần Postgres để chạy LiteLLM Proxy không?

Không bắt buộc cho POC vì Proxy chạy với chỉ file YAML là được. Nhưng để dùng virtual keys, budgets, team management, và fallback management endpoint mới (v1.85.0+), bạn cần bật database_url trỏ tới Postgres 12+ hoặc SQLite (chỉ dev).

Semantic cache của LiteLLM có tương thích multi-turn agent không?