LiteLLM Gateway Production: Self-Hosting, Routing, Audit Và Kiểm Soát MCP

Đưa một ứng dụng AI từ bản demo lên môi trường có nhiều người dùng thường làm lộ ra một vấn đề không nằm trong model: mỗi nhóm đang gọi nhà cung cấp theo một cách khác nhau. Có nơi giữ API key trong biến môi trường của ứng dụng, nơi khác gọi thẳng OpenAI-compatible endpoint, còn một agent nội bộ tự chuyển sang model dự phòng khi lỗi. Khi số dự án tăng, đội vận hành khó trả lời ba câu hỏi cơ bản: request nào đã đi qua model nào, ai có quyền sử dụng deployment đó, và chi phí hoặc lỗi sẽ được giới hạn ở đâu.

LiteLLM AI Gateway giải quyết đúng lớp trung gian này. Thay vì để từng ứng dụng tự quản provider, khóa, retry và log, team đặt một gateway có giao diện tương thích OpenAI ở giữa client và nhiều backend model. Tuy nhiên, “cài được proxy” chưa đồng nghĩa với “có một lớp kiểm soát production”. Bài viết này trình bày một case study triển khai theo hướng an toàn: tách quyền truy cập bằng virtual key, định tuyến bằng routing group, quan sát bằng log, kiểm soát thay đổi và đặt MCP server sau hàng đợi phê duyệt.

Phạm vi bài không tuyên bố LiteLLM thay thế hệ thống IAM, SIEM, secret manager hoặc nền tảng quan sát chuyên dụng. Gateway chỉ là một control plane hữu ích khi nó được đặt trong kiến trúc có ranh giới rõ, cấu hình được version hóa và có quy trình xử lý sự cố. Repository phần mềm chính thức BerriAI/litellm đang hoạt động, không archived; repository tài liệu BerriAI/litellm-docs công bố theo MIT License.

Case study: một team Vibe Coding có nhiều agent và nhiều provider

Giả sử một product team có bốn workload. Agent hỗ trợ lập trình cần model mạnh cho thay đổi nhiều file; bot phân loại issue chỉ cần model nhanh và rẻ; luồng RAG nội bộ xử lý dữ liệu nhạy cảm; còn môi trường thử nghiệm cho phép developer đổi model thường xuyên. Nếu mỗi workload giữ khóa provider riêng, team sẽ sớm gặp bốn dạng phân mảnh.

• Phân mảnh xác thực: khó thu hồi quyền của một project mà không xoay khóa cho các project khác.
• Phân mảnh định tuyến: retry, fallback và timeout được viết lại ở nhiều codebase, dẫn tới hành vi khác nhau.
• Phân mảnh chi phí: hóa đơn nằm ở provider nhưng ownership nằm ở team, project hoặc agent.
• Phân mảnh audit: khi có sự cố, log của ứng dụng, gateway và provider không dùng chung một correlation ID.

Mục tiêu của case study không phải “một endpoint cho mọi thứ”, mà là một giao diện chung đi kèm policy. Client chỉ biết model logic như coding-primary, triage-fast hoặc rag-private. Gateway ánh xạ tên logic sang deployment thực, thực thi budget và rate limit, sau đó phát log đủ để truy ngược quyết định định tuyến. Nhờ vậy, thay đổi provider không bắt buộc sửa từng ứng dụng, nhưng quyền quyết định vẫn nằm trong quy trình vận hành.

Kiến trúc kiểm soát: gateway là ranh giới, không phải chiếc hộp thần kỳ

Một deployment production tối thiểu nên phân biệt năm lớp. Lớp client gồm IDE agent, backend ứng dụng, automation và job nền. Lớp ingress kết thúc TLS, giới hạn kích thước request và chỉ mở route cần thiết. LiteLLM Gateway nằm sau ingress, chịu trách nhiệm xác thực logical key, chọn model, áp policy và ghi log. PostgreSQL lưu cấu hình hoặc dữ liệu quản trị cần thiết; Redis có thể hỗ trợ cache, rate limiting hoặc trạng thái phân tán tùy cấu hình. Cuối cùng là provider hoặc inference endpoint thực tế.

Điểm quan trọng nhất là không cho client đi vòng qua gateway. Nếu ứng dụng vừa có virtual key của LiteLLM vừa giữ khóa gốc của provider, team sẽ có một “đường tắt” không chịu budget, routing và audit. Secret provider chỉ nên hiện diện tại gateway hoặc secret manager mà gateway được phép đọc. Developer nhận khóa scope hẹp gắn với team hoặc project; CI nhận khóa riêng; workload production dùng danh tính máy hoặc secret có vòng đời ngắn nhất mà hạ tầng hỗ trợ.

Trang Router Settings cho thấy các tham số như routing strategy, allowed fails, cooldown, số lần retry và timeout. Đây là policy vận hành, không phải nút “tối ưu tự động”. Retry quá cao có thể nhân chi phí và kéo dài tail latency. Cooldown quá ngắn có thể đưa một deployment đang chập chờn trở lại pool sớm. Timeout quá dài làm hàng đợi tích tụ; quá ngắn tạo false failure cho model cần suy luận lâu. Vì vậy mỗi model logic cần SLO và budget lỗi riêng.

Lớp	Trách nhiệm chính	Không nên giao cho lớp này
Client	Gửi request, truyền correlation ID, xử lý lỗi theo hợp đồng	Giữ nhiều khóa provider hoặc tự phát minh fallback
Ingress	TLS, network policy, giới hạn request, IP allowlist khi phù hợp	Quyết định model theo chi phí hoặc chất lượng
LiteLLM	Auth, routing, budget, rate limit, policy, log	Lưu bí mật trong file cấu hình được commit
Database/Redis	Trạng thái bền vững và điều phối phân tán	Mở trực tiếp ra Internet
Provider	Thực thi inference	Đóng vai trò source of truth duy nhất cho ownership nội bộ

Chọn model logic trước khi chọn chiến lược định tuyến

Một lỗi phổ biến là tạo routing group theo tên nhà cung cấp, ví dụ openai-group hoặc anthropic-group. Cách đặt tên này làm rò rỉ chi tiết hạ tầng vào client và khiến migration khó hơn. Tên model logic nên mô tả hợp đồng mà ứng dụng cần: context tối thiểu, hỗ trợ tool calling, structured output, mức dữ liệu được phép gửi, giới hạn latency và trần chi phí.

Ví dụ, coding-primary có thể yêu cầu tool calling, context dài và mức chất lượng cao; triage-fast ưu tiên độ trễ với schema JSON nhỏ; rag-private chỉ được route tới endpoint nằm trong vùng dữ liệu cho phép. Khi policy được mô tả theo workload, cùng một deployment có thể tham gia nhiều group với quota khác nhau, còn client không cần biết khóa hay endpoint thật.

Thiết kế routing group và failure domain

Routing group gom nhiều model hoặc deployment dưới một tên logic. Ảnh tài liệu minh họa nhóm có nhiều model và chiến lược latency-based. Trong thực tế, team không nên bỏ mọi deployment vào cùng một pool. Một nhóm tốt cần có failure domain được cân nhắc: khác region, khác account hoặc khác provider khi yêu cầu kinh doanh cho phép. Hai deployment dùng chung region và chung quota account có thể cùng thất bại, dù giao diện trông như có dự phòng.

Chiến lược least-busy hoặc latency-based hữu ích khi các deployment tương đương về chất lượng và policy. Nếu model khác nhau đáng kể, ưu tiên định tuyến theo capability trước, rồi mới cân tải. Không nên để thuật toán chọn một model rẻ nhưng thiếu structured output cho request bắt buộc schema; cũng không nên fallback dữ liệu nhạy cảm sang provider chưa được phê duyệt chỉ vì endpoint chính trả lỗi.

Mỗi group nên có tài liệu ngắn gồm owner, consumer, data classification, model list, lý do strategy, timeout, retry, cooldown, fallback order và tiêu chí rollback. Đây là phần biến cấu hình kỹ thuật thành tài sản vận hành. Nếu không có owner và tiêu chí thay đổi, group nhanh chóng trở thành nơi tích lũy model cũ mà không ai dám xóa.

Thay đổi cấu hình như thay đổi production code

Giao diện quản trị giúp thao tác nhanh, nhưng production cần một source of truth có thể review. Cấu hình nền tảng nên được version hóa hoặc xuất thành manifest có kiểm soát; thay đổi qua UI phải tạo audit event và được đối chiếu lại với cấu hình mong muốn. Nếu UI là đường duy nhất, ít nhất hãy yêu cầu ticket, người duyệt, cửa sổ thay đổi và bằng chứng sau triển khai.

Một rollout an toàn có ba bước. Đầu tiên, thêm deployment mới nhưng chưa nhận toàn bộ traffic. Tiếp theo, gửi synthetic request đại diện cho tool call, structured output, streaming và prompt dài. Cuối cùng, tăng traffic từng nấc trong khi theo dõi success rate, p95/p99 latency, token, chi phí và error class. Không đánh giá chỉ bằng một request thành công trong Playground.

Thay đổi strategy arguments cũng cần test. Một cửa sổ latency quá ngắn có thể phản ứng với nhiễu; một ngưỡng cooldown không phù hợp gây dao động; retry trên lỗi không idempotent có thể lặp tác vụ. Với agent có tool gây mutation, retry toàn bộ vòng hội thoại nguy hiểm hơn retry một lời gọi inference thuần túy. Gateway phải biết giới hạn của nó: nó có thể retry request model, nhưng không thể tự chứng minh tool phía sau là idempotent.

Rollback và xóa routing group phải có đường lui

Ảnh xác nhận xóa nêu rõ model trong group có thể quay về chiến lược định tuyến cấp cao hơn. Đây là chi tiết dễ bị bỏ qua: xóa một group không nhất thiết làm traffic dừng; nó có thể làm traffic đi theo policy khác. Trước khi xóa, operator phải tìm consumer của tên model logic, xác định hành vi sau xóa và kiểm tra xem top-level routing có đáp ứng cùng ràng buộc dữ liệu hay không.

Rollback tốt không phải “khôi phục bằng trí nhớ”. Team nên lưu snapshot cấu hình trước thay đổi, có lệnh hoặc manifest đưa hệ thống về trạng thái trước, và xác minh bằng cùng bộ synthetic request. Với thay đổi lớn, có thể tạo group mới có tên phiên bản nội bộ, chuyển một nhóm consumer nhỏ sang trước, rồi mới đổi alias. Cách này giảm blast radius và tránh sửa trực tiếp group đang phục vụ toàn bộ production.

Khi một deployment lỗi, đừng xóa ngay khỏi hệ thống nếu hành động đó làm mất bằng chứng. Đặt cooldown hoặc loại khỏi pool, giữ log và metadata đủ để điều tra, sau đó mới dọn cấu hình. Quy trình incident nên phân biệt lỗi provider, lỗi quota, lỗi network, lỗi schema, lỗi content policy và lỗi do client. Gom tất cả thành “model failed” làm team chọn biện pháp sai.

Virtual key, budget và rate limit: ba lớp không thay thế nhau

Virtual key tạo ranh giới truy cập giữa consumer và provider secret. Mỗi key nên gắn với team, project, environment và owner; không chia sẻ một key production cho nhiều ứng dụng. Scope model giới hạn key chỉ gọi model logic cần thiết. Thời hạn, rotation và revoke cần được thử định kỳ, không chờ đến khi có nhân sự rời team.

Budget trả lời “được phép tiêu bao nhiêu trong một khoảng”, còn rate limit trả lời “được phép gửi nhanh đến mức nào”. Một workload có chi phí trung bình thấp vẫn có thể tạo burst làm cạn quota; ngược lại, request chậm nhưng context rất lớn có thể vượt budget dù RPM thấp. Do đó nên theo dõi đồng thời request, token input/output và chi phí quy đổi.

Soft budget dùng để cảnh báo trước khi chặn cứng. Hard limit bảo vệ tài chính nhưng có thể gây outage nếu đặt quá sát mức trung bình. Một cách thực dụng là đặt cảnh báo ở nhiều ngưỡng, nêu rõ người nhận và runbook: kiểm tra loop, cache miss, prompt phình, model bị đổi, hay traffic hợp lệ tăng. Nếu cảnh báo chỉ gửi vào kênh không có owner, nó không phải control.

Observability: chứng minh gateway đã route như dự kiến

Ảnh log chính thức minh họa một truy vấn có thể đọc routing group, model và strategy đã chọn. Đây là bằng chứng quan trọng hơn việc UI hiển thị cấu hình mong muốn. Audit production cần nối được bốn mốc: request từ client, quyết định của gateway, phản hồi provider và kết quả ứng dụng. Correlation ID nên được tạo ở biên sớm nhất, truyền qua gateway và xuất hiện trong trace hoặc log downstream.

Không log vô điều kiện toàn bộ prompt và response. Dữ liệu có thể chứa source code, tài liệu nội bộ, PII hoặc secret bị người dùng vô tình dán vào. Thiết kế logging nên có chế độ metadata-only mặc định, redaction trước khi xuất, sampling theo rủi ro và retention khác nhau cho môi trường. Quyền đọc log cũng cần tách khỏi quyền quản trị model; người vận hành chi phí không mặc nhiên cần đọc nội dung hội thoại.

Một dashboard hữu ích nên trả lời: success rate theo model logic; p50, p95 và p99 latency; retry và fallback count; cooldown event; token và chi phí theo project; rate-limit rejection; guardrail decision; cùng tỷ lệ request không có owner hoặc correlation ID. Để đánh giá chất lượng nội dung và regression sâu hơn, gateway log có thể kết nối với quy trình eval. Bài Langfuse AI Eval với golden dataset và regression gate trình bày lớp kiểm thử này.

MCP server là một phần của software supply chain

MCP mở rộng agent từ “sinh văn bản” sang “gọi công cụ”. Vì vậy thêm MCP server không tương đương thêm một model; nó tương đương cấp thêm capability. Một server có thể đọc repository, tạo issue, truy vấn database hoặc kích hoạt workflow. Hàng đợi Submitted MCPs trong tài liệu LiteLLM thể hiện đúng tư duy cần có: submission ở trạng thái pending trước khi trở thành active.

Review phải bắt đầu từ identity của server: ai sở hữu, code nằm ở đâu, phiên bản nào được triển khai, transport nào được dùng, endpoint có TLS hay không và secret được lấy từ đâu. Tiếp theo là tool inventory: tên tool, input schema, hành động đọc hay ghi, phạm vi tài nguyên và khả năng gây tác động bên ngoài. Cuối cùng là dữ liệu: prompt hoặc file nào sẽ đi tới server, retention ra sao và log có thể chứa gì.

Không nên duyệt chỉ vì server đến từ thương hiệu quen thuộc. Rủi ro nằm trong deployment cụ thể, cấu hình cụ thể và quyền cụ thể. Một MCP GitHub chỉ đọc repository public khác hoàn toàn một MCP có quyền push branch, merge PR và đọc repository private. Nguyên tắc least privilege phải áp dụng ở token, scope, repository allowlist và tập tool được expose.

Gate phê duyệt MCP: kiểm tra trước khi Active

Nút Approve chỉ nên là bước cuối của một checklist có bằng chứng. Reviewer cần lưu owner, mục đích kinh doanh, phạm vi tool, dữ liệu được phép, credential scope, giới hạn network, timeout, rate limit, audit destination, ngày hết hạn và kế hoạch thu hồi. Với tool có mutation, nên yêu cầu confirmation ở lớp ứng dụng hoặc policy riêng, thay vì cho model gọi trực tiếp mà không có người duyệt.

Sandbox là cần thiết nhưng không đủ. Server chạy trong container vẫn có thể truy cập network, volume hoặc metadata service nếu policy mở. Egress nên allowlist theo endpoint cần thiết; filesystem mount chỉ đọc khi có thể; secret không đưa vào image; image được pin theo digest hoặc release đã xác minh. Health check chỉ chứng minh process sống, không chứng minh tool hành xử an toàn.

Team cũng cần test prompt injection theo đường dữ liệu. Một issue, trang web hoặc file README có thể chứa chỉ dẫn nhằm khiến agent gọi tool ngoài mục tiêu. Gateway có thể áp guardrail hoặc policy, nhưng ứng dụng vẫn phải phân tách dữ liệu không tin cậy khỏi instruction và yêu cầu confirmation cho hành động nhạy cảm. Không có một filter duy nhất loại bỏ hoàn toàn rủi ro này.

Tiêu chí từ chối và cách ghi lý do có thể hành động

Reject không nên là ngõ cụt. Lý do tốt phải giúp owner sửa và nộp lại: “token có quyền ghi trên toàn organization, hãy giới hạn ở hai repository và read-only”, “endpoint chưa pin certificate hoặc chưa có allowlist egress”, “tool delete không có confirmation”, hoặc “không có owner và ngày hết hạn”. Lý do mơ hồ như “không an toàn” không tạo ra cải thiện.

Từ chối ngay khi server yêu cầu credential rộng hơn use case, không có nguồn code hoặc artifact xác minh, không cung cấp inventory tool, không có audit, hoặc gửi dữ liệu sang vùng chưa được phê duyệt. Với server thử nghiệm, có thể cấp môi trường sandbox, dữ liệu giả và key ngắn hạn thay vì phê duyệt production. Quy trình tốt tạo lối đi an toàn cho thử nghiệm, không buộc developer tìm đường vòng.

Guardrail, policy và giới hạn của gateway

LiteLLM hỗ trợ nhiều cơ chế guardrail và policy tùy cấu hình, nhưng cần định nghĩa guardrail đang bảo vệ điều gì. Content moderation, phát hiện PII, kiểm soát tool, model allowlist và network policy là các lớp khác nhau. Một guardrail văn bản không ngăn server MCP dùng credential quá rộng; một model allowlist không ngăn prompt chứa secret; một budget không ngăn data exfiltration.

Hãy xây policy matrix theo workload. Agent code production có thể dùng model A/B, đọc repository cụ thể, nhưng mọi thao tác ghi cần confirmation. Bot triage chỉ được dùng model rẻ, schema cố định và tool read-only. RAG nội bộ không được fallback ra provider ngoài vùng. Playground có quota thấp, log redacted và không dùng dữ liệu thật. Policy rõ giúp team điều tra decision, thay vì dựa vào cảm giác “gateway đã bật bảo mật”.

So sánh ba kiểu triển khai phổ biến

Kiểu	Ưu điểm	Rủi ro chính	Khi nên dùng
SDK trực tiếp trong từng app	Đơn giản, ít hạ tầng	Khóa, retry, log và cost bị phân mảnh	Prototype cá nhân hoặc workload rất nhỏ
Một LiteLLM Gateway dùng chung	Policy và quan sát tập trung	Blast radius lớn nếu không HA và phân quyền	Nhiều app cần chung chuẩn model access
Nhiều gateway theo trust zone	Cô lập dữ liệu và failure domain	Chi phí vận hành và cấu hình cao hơn	Production có nhiều vùng dữ liệu hoặc mức nhạy cảm

Không phải team nào cũng cần multi-region ngay. Giai đoạn đầu có thể chạy một gateway với database bền vững, backup, health check, resource limit và runbook. Khi gateway trở thành dependency chung, hãy kiểm thử HA, schema migration, rollback image và khôi phục database. Tài liệu chính thức khuyến nghị dùng stable image đã qua chu kỳ kiểm thử thay vì kéo tag thay đổi liên tục; production cũng nên pin phiên bản, xác minh chữ ký image khi quy trình hỗ trợ và nâng cấp qua staging.

Runbook triển khai 14 bước

1. Liệt kê consumer, owner, môi trường và dữ liệu mà từng workload xử lý.
2. Đặt tên model logic theo capability, không theo provider.
3. Tạo secret provider tại secret manager; loại khóa gốc khỏi client.
4. Triển khai gateway sau TLS ingress và đóng database/Redis khỏi Internet.
5. Tạo virtual key riêng theo project và environment.
6. Áp model allowlist, budget, RPM/TPM và ngày hết hạn cho từng key.
7. Tạo routing group với failure domain và strategy có lý do rõ.
8. Đặt timeout, retry, allowed fails và cooldown theo SLO.
9. Chạy synthetic request cho streaming, tool call, schema và prompt dài.
10. Truyền correlation ID; xuất metric và log đã redaction.
11. Tạo dashboard cho latency, error, fallback, token, cost và policy rejection.
12. Đưa MCP submission vào hàng đợi; review identity, tool, data và credential.
13. Thử revoke key, loại deployment khỏi pool và rollback cấu hình.
14. Lưu owner, bằng chứng kiểm thử, ngày review tiếp theo và runbook incident.

Checklist readiness trước khi mở traffic thật

• Không còn provider key trong client, notebook, CI log hoặc repository.
• Mỗi virtual key có owner, scope, budget, rate limit và expiration.
• Model logic có capability contract và data classification.
• Routing group không gom các deployment cùng một failure domain mà tưởng là dự phòng.
• Retry không lặp tool mutation; timeout phù hợp với workload.
• Có synthetic test và bằng chứng log cho quyết định route.
• Prompt/response logging mặc định redacted hoặc metadata-only.
• Database, Redis và admin UI không mở công khai không cần thiết.
• Image được pin; migration, backup và rollback đã thử.
• MCP server có owner, inventory tool, credential scope và audit.
• Approve/Reject có người chịu trách nhiệm và lý do lưu được.
• Dashboard có cảnh báo gắn với runbook, không chỉ biểu đồ đẹp.

LiteLLM đứng ở đâu trong stack AI hiện có?

LiteLLM không thay thế nền tảng xây workflow. Nếu team cần orchestration trực quan, RAG và agent graph, hãy tham khảo Dify Deep Dive cho workflow và RAG self-hosted. Nếu automation xoay quanh trigger, SaaS connector và quy trình nghiệp vụ, bài n8n Deep Dive về AI workflow self-hosted phù hợp hơn. LiteLLM nằm thấp hơn: chuẩn hóa đường gọi model, policy truy cập, định tuyến và cost control cho nhiều consumer.

Trong local AI, Ollama và Open WebUI giải quyết inference cục bộ cùng giao diện trợ lý. LiteLLM có thể đứng trước nhiều backend, kể cả endpoint OpenAI-compatible, nhưng việc ghép chúng phải dựa trên yêu cầu chứ không phải số lượng công cụ. Mỗi lớp thêm vào làm tăng khả năng kiểm soát đồng thời tăng failure mode, upgrade path và burden quan sát.

Kết luận

Giá trị lớn nhất của LiteLLM Gateway không phải là đổi một base URL để gọi nhiều model. Giá trị xuất hiện khi team dùng gateway như một hợp đồng vận hành: client chỉ gọi model logic; provider secret nằm sau ranh giới; routing có failure domain và tiêu chí rollback; chi phí gắn với owner; log chứng minh quyết định; MCP server chỉ active sau review.

Một kiến trúc tốt không cố tự động hóa mọi quyết định. Nó làm rõ quyết định nào có thể tự động, quyết định nào cần confirmation và bằng chứng nào phải tồn tại sau sự cố. Bắt đầu với một workload ít rủi ro, thiết lập virtual key và routing group tối thiểu, kiểm thử revoke cùng rollback, rồi mới mở rộng. Khi gateway trở thành shared infrastructure, hãy đối xử với cấu hình, image và policy của nó nghiêm túc như production code.