LLM proxy và AI gateway: bạn cần kiến trúc nào?
So sánh reverse proxy LLM với AI gateway về định tuyến, xác thực, tính phí, failover, quan sát và trường hợp phù hợp của từng kiến trúc.
Reverse proxy LLM chuyển tiếp yêu cầu dạng OpenAI tới một hoặc nhiều API model thượng nguồn với rất ít policy, còn AI gateway là control plane bổ sung xác thực, phân quyền, định tuyến, quota, hạch toán sử dụng, failover và khả năng quan sát vận hành lên trên lớp truyền tải đó. Nếu chỉ cần che một base URL, proxy có thể đủ. Nếu nhiều team, khóa, nhà cung cấp hoặc budget cùng chia sẻ một đường traffic, bạn cần trách nhiệm của gateway bất kể gọi component đó là gì.
Trang này là hướng dẫn lựa chọn: công việc nào thuộc về chặng trung gian, điều gì hỏng khi không có người sở hữu, và cách quyết định mà không bịa ra bảng xếp hạng thắng thua. Công thức self-host tiếp tục trong gateway LLM API tự lưu trữ. Cách chuyển SDK nhà cung cấp nằm trong các bài dùng Claude và Gemini với OpenAI SDK.
Bắt đầu từ công việc thực sự của từng lớp
Team thường dùng “proxy” và “gateway” thay nhau vì cả hai đều nằm giữa client và nhà cung cấp. Khác biệt quan trọng trong production là trách nhiệm nào được sở hữu tại chặng đó.
Reverse proxy LLM
Công việc proxy thường gặp:
- kết thúc TLS và chuyển tiếp HTTP
- viết lại host header hoặc base path
- chèn hoặc thay khóa API thượng nguồn
- tùy chọn retry đơn giản khi lỗi kết nối
- tùy chọn access log cơ bản
Proxy tối ưu cho truyền tải đơn giản. Nó gần với nginx, Envoy, Caddy hoặc một dịch vụ Go nhỏ gửi request tới /v1/chat/completions của một nhà cung cấp.
AI gateway
Công việc gateway thường gặp:
- phát hành và xác minh API key theo tenant hoặc người dùng
- ánh xạ tên model logic tới kênh nhà cung cấp
- áp rate limit, budget và allowlist model
- chuyển payload riêng của nhà cung cấp khi cần, ví dụ tool kiểu OpenAI ở đầu vào sang Claude Messages ở thượng nguồn
- ghi usage, ước tính chi phí và audit trail
- định tuyến theo health và failover
- cung cấp UI operator cho kênh, log và bối cảnh giá
Gateway tối ưu cho quyền truy cập model đa tenant hoặc đa team có thể vận hành được. Dự án như gateway Go self-host trong repository này kết hợp đầu vào tương thích OpenAI với cấu hình kênh, quản lý người dùng và hạch toán usage thay vì chỉ làm đường ống.
So sánh song song
| Mối quan tâm | Reverse proxy LLM | AI gateway |
|---|---|---|
| Mục tiêu chính | Chuyển tiếp request | Quản trị quyền truy cập model |
| Mô hình xác thực | Thường một khóa thượng nguồn dùng chung | Khóa có phạm vi, group, kiểm soát kiểu RBAC |
| Nhà cung cấp | Thường một, đôi khi nhiều thượng nguồn tĩnh | Định tuyến đa kênh hạng nhất |
| Tên model | Truyền nguyên | Alias và catalog |
| Tính phí / quota | Bên ngoài hoặc không có | Usage log và budget tích hợp |
| Failover | Thủ công hoặc retry thô | Kênh dự phòng theo policy |
| Quan sát | Access log | Lịch sử request, health kênh, dashboard |
| Chuyển payload | Hiếm | Phổ biến, như OpenAI ↔ Claude / Gemini |
| Phù hợp nhất | Một ứng dụng, một chặng biên nhà cung cấp | Platform team phục vụ nhiều ứng dụng |
Không cột nào “đúng hơn”. Proxy phát triển thiếu kiểm soát thường trở thành gateway tình cờ nhưng không có test hoặc UI của một gateway được thiết kế có chủ ý.
Khi reverse proxy là câu trả lời đúng
Chọn proxy mỏng khi phần lớn điều sau đúng:
- một team ứng dụng sở hữu cả client và thông tin xác thực
- một nhà cung cấp chính xử lý gần như toàn bộ traffic
- bạn không cần budget theo tính năng bên trong proxy
- failover nằm trong code ứng dụng hoặc downtime chấp nhận được
- nhu cầu audit đã được APM và hóa đơn nhà cung cấp đáp ứng
- người sửa proxy cũng là người phát hành ứng dụng
Ví dụ:
- môi trường staging viết lại
api.openai.comsang mirror khu vực - sidecar chèn secret để container không giữ khóa nhà cung cấp thô
- chặng migration tạm thời khi đổi DNS hoặc chứng chỉ
Trong các trường hợp này, tính năng gateway chỉ thêm bề mặt vận hành mà không cải thiện chất lượng quyết định.
Khi bạn cần AI gateway
Chuyển sang semantics của gateway khi xuất hiện bất kỳ dấu hiệu nào sau đây.
Nhiều consumer chia sẻ một đường
Chat nội bộ, đánh giá batch, support agent và tính năng sản phẩm không nên cùng nhúng một khóa nhà cung cấp không giới hạn. Khóa có phạm vi, role-based access control và policy group giữ blast radius nhỏ.
Nhiều nhà cung cấp thuộc chiến lược sản phẩm
Nếu Claude, Gemini và OpenAI đều là lựa chọn thật, mỗi client không nên tự triển khai SDK nhà cung cấp và failover tùy tiện. Gateway API tương thích OpenAI giữ một client contract trong khi kênh chứa sự đa dạng thượng nguồn. Điều này đặc biệt quan trọng khi chế độ “tương thích OpenAI” trực tiếp của nhà cung cấp chỉ hướng tới đánh giá — như Anthropic nói về con đường OpenAI SDK — còn production cần ánh xạ thượng nguồn gốc dưới một đầu vào.
Chi phí phải được quy trách nhiệm và giới hạn
Hóa đơn nhà cung cấp đến quá muộn để kiểm soát theo tính năng. Gateway phơi bày usage cấp request, bối cảnh giá và khái niệm ví hoặc quota giúp team trả lời “ai chi bao nhiêu cho model nào” mà không đào bới spreadsheet. Kết hợp với usage log và theo dõi chi phí LLM.
Độ tin cậy là SLA của platform
Nếu product manager kỳ vọng “chat vẫn hoạt động khi nhà cung cấp A chập chờn”, policy failover dùng chung phải nằm ở một chặng. Xem chiến lược failover LLM API. Ứng dụng vẫn xử lý suy giảm hiển thị cho người dùng khi không còn kênh khỏe.
Bảo mật và tenancy quan trọng
Agent gọi tool, dữ liệu khách hàng trong prompt và SaaS đa tenant đều làm tăng rủi ro của master key dùng chung. Phạm vi khóa gateway, allowlist model và audit log là khác biệt giữa platform có kiểm soát và reverse proxy tự do.
Phác thảo kiến trúc
Đường proxy
App --Bearer provider key or injected secret--> Reverse proxy --> Single provider API
\
access log (optional)
Đường gateway
Apps / agents / eval jobs
| HTTPS + gateway key
v
AI gateway
- authN/authZ, quotas, aliases
- OpenAI-compatible /v1/*
- usage logs + operator UI
|
+--> Channel: OpenAI
+--> Channel: Anthropic (native Messages)
+--> Channel: Gemini
+--> Channel: Azure / Bedrock / others
Client tiếp tục dùng OpenAI SDK. Đa dạng thượng nguồn là cấu hình. Đó cũng là lý do gọi tool khả chuyển và chương trình đánh giá đa nhà cung cấp thường phát triển gateway thay vì thêm ba proxy.
Checklist tính năng để quyết định
Hãy trả lời mười câu hỏi sau bằng văn bản. Nếu hơn một nửa là “chưa xác định” hoặc “mỗi ứng dụng làm khác nhau”, bạn đã cần semantics của gateway dù traffic vẫn chỉ có một nhà cung cấp.
- Identity — Caller xác thực như dịch vụ, người dùng hay tenant?
- Authorization — Mọi caller có được gọi mọi model không?
- Budget — Có chặn cứng trước khi agent runaway làm cạn tiền không?
- Routing — Tên model logic có che đổi tên nhà cung cấp không?
- Translation — Tool call hoặc streaming có cần chuẩn hóa giữa nhà cung cấp không?
- Failover — Ai sở hữu việc chọn model dự phòng?
- Audit — Có thể dựng lại request tính phí sau incident không?
- Operator UX — Kỹ sư không trực on-call có cần UI cho kênh và log không?
- Ranh giới dữ liệu — Một số traffic có phải ở nhà cung cấp hoặc khu vực cụ thể không?
- Tốc độ thay đổi — Model ID và giá đổi thường xuyên đến đâu?
Các failure mode phổ biến
Bẫy “smart proxy”
Proxy tích lũy Lua script riêng lẻ, custom header và quy tắc retry không tài liệu. Chỉ một kỹ sư hiểu nó. Khi nhà cung cấp đổi dạng lỗi streaming, mọi client hỏng và log không đủ. Nếu cần các quy tắc đó, hãy nâng chúng thành gateway có test và cấu hình rõ ràng.
Hai control plane
Một số tổ chức chạy proxy cho ứng dụng “đơn giản” và gateway cho ứng dụng “platform”. Hai hệ thống khóa và hai định dạng log xuất hiện. Ưu tiên một contract đầu vào dù policy nâng cao vẫn tắt cho tenant đơn giản.
Gateway ở phía client
Mỗi microservice tự triển khai abstraction nhà cung cấp, budget và retry. Đó là gateway phân tán không có khả năng quan sát chung. Hãy tập trung policy hop hoặc chấp nhận incident bị nhân bản.
Vận hành dựa vào hóa đơn
Nếu lần đầu finance thấy chi phí model là hóa đơn hàng tháng, bạn thiếu đo đếm cấp gateway. Ngay cả gateway self-host nhỏ với log theo khóa vẫn tốt hơn dọn CSV sau sự kiện.
Coi lớp tương thích nhà cung cấp là platform
Trỏ mọi microservice tới base URL tương thích OpenAI của Anthropic hoặc Google có thể trông như chiến lược đa nhà cung cấp. Thực tế thường là năm bản sao wiring đánh giá: không quota dùng chung, không alias thống nhất và mỗi vendor bỏ trường âm thầm khác nhau. Endpoint tương thích hữu ích, nhưng không thay thế control plane.
AveMujica API nằm ở phía gateway như thế nào
AveMujica API hướng tới trách nhiệm gateway: endpoint tương thích OpenAI như /v1/chat/completions và /v1/responses, kênh nhà cung cấp, model catalog, lịch sử sử dụng và dashboard overview. Team vẫn có thể đặt reverse proxy thường ở trước để xử lý TLS hoặc allowlist IP; các mối quan tâm mạng đó bổ sung cho AI control plane thay vì thay thế nó.
Với vận hành hằng ngày sau khi chọn gateway, dùng model catalog, cấu hình kênh và view lịch sử sử dụng của deployment, hoặc trang model/giá công khai tương đương khi chia sẻ cho stakeholder. Đừng đặt deep link console cần xác thực vào tài liệu kiến trúc cho người không vận hành.
Hướng dẫn quyết định
| Tình huống | Ưu tiên |
|---|---|
| Một app, một nhà cung cấp, chặng biên tạm thời | Reverse proxy |
| Chỉ chèn secret | Reverse proxy hoặc sidecar |
| Nhiều app, một platform team | AI gateway |
| Định tuyến đa nhà cung cấp và alias | AI gateway |
| Budget và audit theo team | AI gateway |
| Agent dùng nhiều tool với policy chung | AI gateway |
| Chưa chắc nhưng dự kiến agent tăng | AI gateway, bắt đầu hẹp |
Nếu vẫn chưa chắc, hãy triển khai đường gateway với một nhà cung cấp và một team trước. Bạn có thể giữ routing đơn giản trong khi khóa, log và quota đã nằm đúng lớp.
Nguồn chính thức và nguồn dự án
Kiểm tra lần cuối: 2026-07-15.
Câu hỏi thường gặp
AI gateway chỉ là tên tiếp thị của reverse proxy?
Không. Tiếp thị đôi khi làm mờ thuật ngữ, nhưng khác biệt vận hành là thật: gateway sở hữu identity, policy, metering và định tuyến đa kênh; proxy chủ yếu chuyển byte và đôi khi chèn credential.
Có thể đặt reverse proxy trước AI gateway không?
Có. Proxy mạng xử lý TLS, WAF hoặc giới hạn IP. AI gateway vẫn sở hữu policy model và hạch toán usage phía sau lớp biên đó.
Chỉ dùng OpenAI thì có cần gateway không?
Không phải lúc nào cũng cần. Một team với auth mạnh trong ứng dụng có thể đủ. Gateway có giá trị khi nhiều sản phẩm chia sẻ chi tiêu, khi cần phạm vi khóa chặt hơn hoặc khi sắp thêm nhà cung cấp.
Tín hiệu sớm nhất cho thấy proxy không còn đủ là gì?
Thường là một trong hai: nhiều team dùng chung một khóa nhà cung cấp, hoặc finance yêu cầu quy trách nhiệm chi phí AI theo tính năng mà access log không trả lời được.
Failover nên nằm trong app hay gateway?
Policy failover dùng chung thuộc về gateway để mọi client kế thừa cùng lớp retry và model dự phòng. App vẫn phải xử lý suy giảm hiển thị cho người dùng khi không còn kênh khỏe.
Viết bảng trách nhiệm
Ghi lại identity, budget, routing, log và failover cho chặng AI hiện tại. Nếu hơn một nửa các hàng chưa xác định hoặc khác nhau theo app, hãy dựng cấu hình kênh gateway và chuyển một workflow thật sang khóa có phạm vi trước khi thêm nhà cung cấp.