LLM Proxy và AI Gateway: kiến trúc, kiểm soát và đánh đổi

LLM proxy và AI gateway có thể nằm ở cùng một vị trí giữa ứng dụng và nhà cung cấp mô hình, nhưng không nhất thiết chịu cùng trách nhiệm. Proxy chủ yếu chuyển tiếp request và response. AI gateway thường bổ sung các kiểm soát hiểu mô hình như chính sách routing, fallback, ghi nhận usage, phân bổ chi phí và quy tắc truy cập theo workload.

Các tên gọi này không phải tiêu chuẩn. Có sản phẩm gọi một lớp điều khiển mô hình là “proxy”, trong khi sản phẩm khác gọi một managed endpoint đơn giản là “gateway”. Vì vậy, hãy so sánh trách nhiệm có thể kiểm chứng thay vì dựa vào nhãn sản phẩm.

Bắt đầu từ trách nhiệm, không phải tên gọi

Hai lớp thường xuất hiện ở cùng vị trí mạng:

Ứng dụng hoặc coding agent
        ↓
LLM proxy hoặc AI gateway
        ↓
Nhà cung cấp và mô hình được chọn

Sơ đồ này chưa cho biết lớp ở giữa thực sự làm gì. Ma trận trách nhiệm cho phép đánh giá rõ ràng hơn.

Trách nhiệm	LLM proxy thiên về truyền tải	AI gateway hiểu mô hình
Kết thúc TLS và chuyển tiếp HTTP	Phổ biến	Phổ biến
Xử lý upstream URL và Header	Phổ biến	Phổ biến
Chuyển tiếp streaming response	Thường có	Thường có, nhưng vẫn phải kiểm tra event contract
Cách ly credential của nhà cung cấp	Đôi khi	Phổ biến, nhưng cần xác minh ranh giới lưu trữ và truy cập
Bề mặt OpenAI-compatible	Đôi khi	Phổ biến, nhưng khác nhau theo mô hình và tính năng
Routing theo mô hình hoặc nhà cung cấp	Hạn chế hoặc do ứng dụng quản lý	Phổ biến
Retry và fallback có thứ tự	Tối đa là retry upstream cơ bản	Thường xét mô hình và loại lỗi
Rate hoặc quota theo workload	Thường ở bên ngoài	Phổ biến
Ghi nhận Token, usage và cost	Thường ở bên ngoài	Phổ biến
Chẩn đoán latency theo request	Thường ở bên ngoài	Phổ biến
Chính sách và audit	Thường ở bên ngoài	Tùy sản phẩm

“Phổ biến” không có nghĩa là được bảo đảm. Với từng trách nhiệm quan trọng, cần xác minh request contract, hành vi khi thất bại, dữ liệu được ghi và quyền điều khiển của operator.

LLM proxy thường phụ trách những gì

Proxy thiên về truyền tải có thể đủ khi mục tiêu chính là đặt một endpoint ổn định trước upstream API. Nó có thể tập trung TLS, hostname, một số Header, giới hạn kích thước, timeout và log cơ bản. Nếu hiểu Server-Sent Events, proxy cũng có thể chuyển tiếp streaming mà không buffer toàn bộ response.

Lớp này tạo đường mạng được kiểm soát và có thể giữ provider key khỏi một số môi trường client. Đây cũng là vị trí hợp lý cho xác thực thông thường và chính sách mạng.

Ranh giới thay đổi khi proxy bắt đầu chuyển đổi định dạng, chọn nhà cung cấp, đếm Token hoặc tính phí. Đó là hành vi hiểu mô hình. Khi ấy, hãy đánh giá nó như một gateway ngay cả khi sản phẩm vẫn dùng tên proxy.

Proxy đơn giản phù hợp khi:

• một ứng dụng dùng một nhà cung cấp và một số ít mô hình cố định;
• ứng dụng đã sở hữu retry, usage accounting và chẩn đoán sự cố;
• tính năng native của nhà cung cấp phải đi qua mà không biến đổi;
• không cần chính sách routing riêng theo nhóm hoặc workload;
• đội ngũ muốn lớp vận hành nhỏ nhất có thể.

AI gateway bổ sung điều gì

AI gateway không xem request mô hình như HTTP thông thường. Nó có thể dùng mô hình được yêu cầu, protocol, chính sách Key, khả dụng của group, giới hạn và kết quả lần thử trước để chọn route. Sau đó, lần thử cuối có thể được liên kết với Token, timing, status và cost.

Tính năng khác nhau theo sản phẩm. Tài liệu Cloudflare AI Gateway trình bày analytics, logging, cache, rate limiting, retry và fallback. Tài liệu metrics của Kong AI Gateway mô tả metrics về mô hình, Token, chi phí, cache, latency và error. Đây là ví dụ chứ không phải định nghĩa chung.

Gateway hữu ích khi nhiều yêu cầu sau xuất hiện cùng lúc:

• nhiều ứng dụng hoặc agent cần API Key và usage được phân bổ riêng;
• cùng một mô hình có nhiều route đủ điều kiện;
• giới hạn phải áp dụng trước khi upstream tạo công việc và chi phí;
• operator cần tách xác thực, routing, chờ upstream, output hữu ích đầu tiên và generation;
• mọi khoản phí phải giải thích được theo request;
• route chính cần chính sách fallback rõ ràng và có thứ tự;
• nhiều group mô hình cần chung một góc nhìn vận hành.

Gateway không tự động làm mọi nhà cung cấp tương đương. Nó cũng không thay thế kiểm tra output, tính idempotent của Tool, bảo vệ secret trong ứng dụng hoặc kiểm thử tính năng native.

Dùng ma trận quyết định theo workload

Workload	Nhu cầu chính	Lớp khởi đầu hợp lý	Lý do
Dịch vụ nội bộ với một nhà cung cấp và mô hình	Đường mạng ổn định	Direct API hoặc proxy nhỏ	Chính sách phức tạp có thể chưa tạo giá trị
Ứng dụng khách hàng có nhiều route cho cùng mô hình	Khả dụng và bằng chứng lần thử	AI gateway	Routing, fallback giới hạn và chẩn đoán cần một owner
Coding agent cho cả đội	Key, quota, phân bổ và offboarding	AI gateway	Credential dùng chung và chi phí không rõ chủ sở hữu là rủi ro
Ứng dụng dùng tính năng native mới	Wire Contract chính xác	Bắt đầu với native endpoint, rồi thêm lớp đã kiểm chứng	API chuẩn hóa có thể chậm hoặc bỏ sót field mới
Batch workflow có Queue và retry riêng	Throughput và phục hồi bởi ứng dụng	Proxy/gateway với retry tắt hoặc giới hạn	Nhiều lớp retry khuếch đại lỗi và lặp công việc
Workload nhạy cảm hoặc bị quản lý	Bằng chứng về đường dữ liệu, lưu trữ và truy cập	Theo các kiểm soát đã xác minh	Từ “gateway” không chứng minh bảo mật hay compliance

Quyết định có thể thay đổi khi workload trưởng thành. Bắt đầu với một nhà cung cấp rồi thêm gateway sau là hợp lý nếu model client nằm sau interface nội bộ rõ ràng và migration contract được kiểm thử.

Tính đến các trade-off ẩn

Phải đo hop bổ sung

Proxy hoặc gateway thêm mạng và xử lý. Một số latency trung bình là chưa đủ. Hãy đo upstream Header, output hữu ích đầu tiên, văn bản hiển thị đầu tiên, tổng thời gian và tốc độ output ở concurrency thực tế. Overhead cố định nhỏ có thể được bù bởi khả năng phục hồi tốt hơn, nhưng phụ thuộc workload.

Tương thích phụ thuộc từng tính năng

“OpenAI-compatible” có thể chỉ bao gồm Base URL, Header xác thực và request Chat Completions cơ bản. Responses Events, Structured Outputs, Tool Calls, usage fields và error format có thể khác. Hãy kiểm thử mọi tính năng ứng dụng dùng. Hướng dẫn OpenAI-Compatible API cung cấp baseline migration; Responses API và Chat Completions giải thích tại sao endpoint không đủ chứng minh tương thích hoàn chỉnh.

Tập trung hóa tạo một miền lỗi

Tập trung Key, routing, limit và log làm rõ ownership nhưng biến lớp này thành thành phần quan trọng. Cần kiểm tra versioning và rollback cấu hình, hành vi khi control plane không khả dụng, và việc hoàn tất request đang chạy khi có thay đổi.

Chi phí cần Source of Truth

Một số gateway dùng giá công khai; số khác dùng giá cấu hình, hệ số group hoặc Billing Expression có version. Hãy xác định thời điểm giá được chọn và cố định, cách biểu diễn Cached Tokens và Tool, và khả năng đối soát khoản phí cuối với usage. Xem AI API Cost Tracking.

Exit cost cũng quan trọng

Trước khi dùng interface chuẩn hóa, hãy tìm phụ thuộc vào Header riêng, model alias, route name hoặc log API. Lớp này nên làm vận hành dễ hơn mà vẫn giữ đường quay lại native protocol.

Ba ví dụ thực tế

Trợ lý nội bộ với một nhà cung cấp

Trợ lý nội bộ gửi request non-streaming tới một mô hình cố định. Ứng dụng đã lưu Job ID và giữ provider key trên server. Proxy thông thường có thể đủ; routing đa nhà cung cấp chưa giải quyết vấn đề thực tế. Interface model client nội bộ vẫn nên được giữ để có thể thêm gateway sau.

Ứng dụng production có nhiều route

Nếu cùng một mô hình phải tiếp tục khả dụng khi một upstream account bão hòa và đội ngũ cần biết route nào tạo chi phí, gateway là phù hợp. Fallback, billing và chẩn đoán phải dùng chung request identity. Đổi sang mô hình khác làm thay đổi chất lượng, latency, Tool và giá, nên phải là chính sách rõ ràng. Xem hướng dẫn routing AI API tin cậy.

Coding agent trong đội engineering

Coding agent tạo session dài, dùng nhiều Tool trên nhiều máy. Một provider key dùng chung làm quota, phân bổ, rotation và offboarding khó quản lý. Gateway có thể cấp Key theo workload và liên kết usage với project. Quyền repository, sandbox, phê duyệt Tool và kiểm tra code vẫn nằm ngoài lớp routing.

Vị trí của Modelflare

Modelflare được thiết kế như lớp truy cập và routing hiểu AI, không chỉ là HTTP relay trong suốt. API Key thường có thể chọn group mô hình chính và các group fallback theo thứ tự. Smart API Key có thể đánh giá group đủ điều kiện theo chiến lược cấu hình. Cả hai đều tìm route cho mô hình được yêu cầu và không nên âm thầm thay bằng mô hình khác.

Group RPM được áp dụng cho group cụ thể trước billing và upstream. Nếu group đầy, hệ thống có thể xét group đủ điều kiện tiếp theo; nếu không còn route, trả về 429. Usage Logs liên kết status, Token, cost và timing, đồng thời tách xác thực, chọn group, upstream Header, event đầu tiên, output hữu ích đầu tiên, văn bản đầu tiên và tổng thời gian.

Ranh giới tương thích vẫn rõ ràng: traffic GPT, Codex và OpenAI là mục tiêu adapter đầy đủ. Các họ model OpenAI-compatible khác nên được xem là Chat Completions pass-through cho đến khi hành vi bổ sung được xác minh. Base URL chung không bảo đảm cùng contract cho Responses, Tools hoặc Structured Outputs.

Xem Models & Pricing để biết model và group hiện có, và tài liệu Modelflare để cấu hình client.

Checklist đánh giá production

• Protocol: hình dạng request và response đang dùng có được giữ nguyên không?
• Streaming: event và Tool Arguments có được chuyển không buffer, mất hoặc đổi thứ tự không?
• Model identity: model được yêu cầu có giữ nguyên khi route đổi không?
• Fallback: lỗi nào đủ điều kiện, có bao nhiêu lần thử và khi nào dừng?
• Limit: rate và quota có áp dụng trước upstream và billing không?
• Usage và cost: Token và phí cuối có liên kết với route và giá thực không?
• Diagnosis: có tách được thời gian gateway, chờ upstream, output đầu và generation không?
• Secrets: ai có thể đọc credential và nội dung request?
• Change Control: chính sách có thể review và rollback không?
• Exit Path: có thể trở lại native endpoint mà không rewrite ứng dụng không?

Hãy kiểm thử với cùng model, loại Prompt, độ dài output, streaming mode, Tool, region và concurrency như production. “Hello World” thành công chỉ chứng minh kết nối.

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

Mọi proxy OpenAI-compatible đều là AI gateway phải không?

Không. Tương thích mô tả một phần API; gateway mô tả trách nhiệm vận hành. Proxy có thể cung cấp định dạng đó mà không sở hữu routing, cost, limit hoặc diagnosis.

AI gateway có loại bỏ provider key không?

Không nhất thiết. Gateway có thể giữ credential, hỗ trợ BYOK hoặc có quan hệ billing riêng. Hãy xác minh nơi lưu Key và quyền sử dụng hoặc export.

AI gateway có làm request nhanh hơn không?

Không tự động. Nó thêm một hop, dù có thể cải thiện khả dụng và diagnosis. Hãy đo toàn bộ timeline của workload.

Fallback có nên chọn mô hình khác không?

Chỉ khi ứng dụng chấp nhận rõ thay đổi về chất lượng, tương thích, latency và giá. Mặc định an toàn hơn là route khác cho cùng mô hình và protocol.

Khác biệt thực tế rất đơn giản: chọn proxy khi chủ yếu cần đường truyền được kiểm soát; chọn AI gateway khi routing, policy, usage, cost và bằng chứng request cần một owner chung. Tên sản phẩm tự nó không phải bằng chứng.