AI hay gặpAI gateway (LLM proxy) là lớp trung gian giữa app và các LLM provider — vai trò như API gateway nhưng hiểu chuyện riêng của LLM: token, streaming, fallback theo model.
Vì sao cần khi tổ chức có nhiều app cùng gọi LLM: quy key về một chỗ để app không giữ key provider, quy được chi phí về từng team/tính năng, đổi provider mà không sửa app, và áp guardrail cùng audit ở một nơi thay vì rải khắp codebase.
Những quyết định thiết kế đáng nói:
- Giữ nguyên API chuẩn OpenAI (
/v1/chat/completions): app chỉ đổibase_urllà xong, không đụng code. Đây là thứ quyết định gateway có được dùng hay không. - Định tuyến động, đừng gán cứng: map tên bí danh (
model=smart) sang model thật để sau này đổi được; thử model rẻ trước rồi mới gọi model mạnh khi kết quả chưa đủ tin cậy; việc cần tool-calling thì buộc route sang provider làm tốt việc đó. - Chuỗi dự phòng primary → backup, kích hoạt khi timeout/
429/5xx, kèm circuit breaker theo từng provider để một provider lỗi không làm toàn hệ ngừng phục vụ. - Cache hai tầng: băm chính xác cho request
temperature=0, và cache theo ngữ nghĩa (so embedding) cho câu hỏi lặp lại. Không cache nội dung gắn với một người dùng cụ thể. - Chính sách theo team — ví dụ dữ liệu có PII không được ra provider ngoài, team EU phải dùng endpoint EU. Đặt ở gateway mới ép được; đặt trong app thì sẽ có chỗ quên.
Observability: trace xuyên suốt một request, metric chi phí/độ trễ/lỗi bổ theo team và provider. Lưu ý không log thẳng prompt và response nếu chưa lọc PII — đây là lỗi compliance hay gặp nhất ở tầng này.
Tự xây hay dùng sẵn: đa số nên bắt đầu bằng LiteLLM (open-source, đỡ sẵn phần lớn provider) hoặc một gateway managed (Cloudflare, Portkey, Vercel); chỉ tự xây khi chính sách nội bộ quá đặc thù.
Lỗi hay gặp: gateway chặn streaming làm hỏng trải nghiệm chat; mọi app dùng chung một API key nên không quy được chi phí; gateway thành nút thắt vì ôm quá nhiều việc đồng bộ trên đường xử lý request — giữ độ trễ thêm dưới ~50ms, việc nặng đẩy ra nền.