Sơ đồ kiến trúc cổng API LLM cho định tuyến và dự phòng nhiều nhà cung cấp

Một LLM API gateway là control plane giữa mã ứng dụng và nhiều nhà cung cấp mô hình. Kiến trúc hữu ích không chỉ là một URL proxy. Nó phải xác thực bên gọi, ánh xạ mô hình, áp dụng chính sách, chọn tuyến upstream, thực thi quota, ghi nhận mức sử dụng, tính chi phí, và quyết định điều gì xảy ra khi một nhà cung cấp gặp lỗi.

Hướng dẫn này cung cấp cho kỹ sư nền tảng một sơ đồ kiến trúc LLM API gateway thực tiễn cho định tuyến và failover đa nhà cung cấp. Nó sử dụng các pattern gateway công khai từ Vercel và Pydantic làm tham chiếu theo danh mục, sau đó giữ các tuyên bố cụ thể về Flatkey ở mức bằng chứng công khai hiện có: một API key, một endpoint router tương thích OpenAI tại https://router.flatkey.ai/v1, giá cả rõ ràng, lập hóa đơn hợp nhất, một dashboard cho keys, usage và routing, tự động chuyển đổi, và cân bằng tải.

Mục tiêu là giúp bạn xem xét thiết kế trước khi lưu lượng production phụ thuộc vào nó. Hãy dùng sơ đồ như một checklist cho gateway của riêng bạn, một bài đánh giá nhà cung cấp, hoặc một bài test staging của Flatkey.

Sơ đồ kiến trúc LLM API Gateway

Sơ đồ cho thấy đường đi của yêu cầu từ các ứng dụng client đến các nhà cung cấp mô hình upstream. Trung tâm của kiến trúc là LLM API gateway. Xung quanh nó là các dịch vụ chính sách giúp định tuyến an toàn khi vận hành: phạm vi khóa, ánh xạ mô hình, lớp tuyến, sổ cái hạn mức, thanh toán, nhật ký, kiểm tra tình trạng và các quy tắc dự phòng.

Lớp	Trách nhiệm	Câu hỏi thiết kế
Ứng dụng client	Gửi các yêu cầu chat, response, image, video, agent hoặc tool.	Cần những SDK và định dạng endpoint nào phải tiếp tục hoạt động?
Endpoint gateway	Nhận yêu cầu thông qua một base URL và API key ổn định.	Ứng dụng có thể di chuyển chỉ bằng cách thay đổi key, base URL hoặc cấu hình nhà cung cấp không?
Xác thực và phạm vi khóa	Xác định bên gọi, nhóm, ứng dụng, môi trường và tập mô hình được phép.	Có thể tách biệt staging, production và lưu lượng khách hàng không?
Engine chính sách	Áp dụng ánh xạ mô hình, lớp tuyến, ngân sách, hạn mức và quy tắc dự phòng.	Chính sách có giải thích được vì sao một yêu cầu có thể hoặc không thể dùng một tuyến không?
Router	Chọn một nhà cung cấp upstream, tài khoản, mô hình hoặc đường dự phòng.	Việc định tuyến có dựa trên chính sách đã phê duyệt thay vì “ma thuật” ẩn không?
Tình trạng và failover	Theo dõi lỗi nhà cung cấp, timeout, retry, fallback và điều kiện dừng.	Những lỗi nào nên retry, chuyển đổi, xếp hàng hoặc fail closed?
Nhật ký, hạn mức và thanh toán	Ghi lại mô hình, tuyến, trạng thái, token hoặc đơn vị media, chi phí, chủ sở hữu và khóa.	Kỹ sư và tài chính có thể truy vết một yêu cầu sau sự cố không?
Các nhà cung cấp upstream	Phục vụ mô hình đã chọn thông qua API gốc của nhà cung cấp hoặc API tương thích.	Những nhà cung cấp nào được phê duyệt cho từng lớp lưu lượng?

Cách Một Yêu Cầu Di Chuyển Qua Gateway

Một LLM API gateway chạy trong môi trường production nên làm cho đường đi của yêu cầu trở nên dễ giải thích. Nếu đội của bạn không thể vẽ ra đường đi, rất có thể bạn cũng không thể gỡ lỗi đường đi đó trong lúc gián đoạn dịch vụ hoặc khi xem xét thanh toán.

1. Client gửi một yêu cầu. Ứng dụng gọi gateway với tên model, endpoint, messages hoặc đầu vào media, và một application API key.
2. Gateway xác thực key. Key được ánh xạ tới owner, environment, quota, tập model được phép, và chính sách logging.
3. Policy engine phân loại lưu lượng. Yêu cầu được gắn nhãn là customer chat, background work, evaluation, media generation, coding tool traffic, hoặc một lớp tuyến khác.
4. Router chọn một tuyến ứng viên. Nó kiểm tra ánh xạ model, trạng thái khả dụng của provider, các upstream account được phép, chính sách chi phí, trạng thái quota, và bất kỳ priority hoặc weight nào đã cấu hình.
5. Gateway gửi yêu cầu upstream. Tùy theo provider và endpoint, việc này có thể giữ nguyên dạng request tương thích OpenAI hoặc sử dụng một giao thức native của provider.
6. Phản hồi được chuẩn hóa khi có thể. Gateway trả về cho client dạng phản hồi, lỗi, stream, hoặc job reference như mong đợi.
7. Yêu cầu được ghi lại. Log ghi nhận route, model, status, latency, usage units, ước tính chi phí, key, và owner để đội ngũ có thể gỡ lỗi và đối soát chi tiêu.

Đó là lý do bước OpenAI-compatible API migration chỉ là một phần của kiến trúc. Việc đổi base URL chỉ đưa lưu lượng đến gateway. Sẵn sàng cho production còn phụ thuộc vào policy, routing, quota, billing, logs, và hành vi fallback sau đó.

Chính sách định tuyến đi trước chuyển đổi dự phòng

Lỗi kiến trúc phổ biến nhất là coi chuyển đổi dự phòng như một điều tốt cho mọi trường hợp. Một LLM API gateway không nên tự động phát lại mọi yêu cầu thất bại qua mọi nhà cung cấp. Trước hết, nó phải quyết định liệu đường dự phòng có được phép cho lớp lưu lượng đó hay không.

Tài liệu công khai của các gateway cho thấy vì sao sự phân biệt này quan trọng. Pydantic mô tả các nhóm định tuyến, trong đó các nhà cung cấp có thể có mức ưu tiên, trọng số và trạng thái hoạt động, cho phép chuyển đổi dự phòng giữa các nhà cung cấp phục vụ cùng một mô hình hoặc cân bằng tải giữa các thành viên cùng mức ưu tiên. Vercel định vị AI Gateway xoay quanh định tuyến, thanh toán, khả năng quan sát, nhiều mô hình, cùng định tuyến theo nhà cung cấp/mô hình với cơ chế dự phòng. Những mô hình đó là các tham chiếu hữu ích, nhưng chính sách sản xuất của bạn vẫn phải xác định điều gì là chấp nhận được cho khối lượng công việc của mình.

Lớp lưu lượng	Quy tắc định tuyến chính	Quy tắc chuyển đổi dự phòng
Chat hướng tới khách hàng	Chỉ sử dụng các họ mô hình và nhà cung cấp đã được phê duyệt.	Chỉ chuyển sang một phương án tương đương đã được phê duyệt, hoặc trả về một lỗi được kiểm soát.
Tóm tắt nền	Ưu tiên chi phí và thông lượng khi yêu cầu về chất lượng ổn định.	Thử lại, xếp hàng, hoặc dùng một mô hình đã được phê duyệt có chi phí thấp hơn nếu chất lượng đầu ra vẫn chấp nhận được.
Đánh giá và benchmark	Giữ danh tính mô hình ổn định.	Fail closed; fallback ẩn khiến kết quả khó so sánh.
Tạo nội dung media	Tôn trọng hình dạng endpoint, vòng đời job, chính sách media và ngân sách.	Fail closed trừ khi mô hình thay thế có cùng hợp đồng đầu ra đã được phê duyệt.
Luồng tác tử	Tôn trọng hỗ trợ công cụ, giới hạn ngữ cảnh, ranh giới dữ liệu và nhu cầu kiểm toán.	Chỉ fallback khi hành vi công cụ và cách xử lý dữ liệu vẫn hợp lệ.

Nội dung công khai của Flatkey cho biết nó định tuyến nhiều tài khoản upstream với chuyển đổi tự động và cân bằng tải. Hãy dùng đó làm điểm khởi đầu sản phẩm, rồi xác định lớp lưu lượng nào của bạn có thể tự động chuyển đổi và lớp nào bắt buộc phải fail closed.

Failover Cần Một Điều Kiện Dừng

Mỗi thiết kế failover của LLM API gateway đều cần một điều kiện dừng. Nếu không có, một request bị định dạng sai có thể trở thành chuỗi lặp lại các lệnh gọi không hợp lệ, gây chi tiêu trùng lặp, log gây nhầm lẫn và hành vi người dùng không nhất quán.

Một thang xử lý lỗi thực tế trông như sau:

1. Từ chối trước khi lên upstream: fail closed với auth không hợp lệ, model bị cấm, vượt quota, endpoint không được hỗ trợ hoặc thiếu tham số bắt buộc.
2. Thử lại cùng tuyến: chỉ retry khi lỗi có khả năng là tạm thời, chẳng hạn timeout mạng hoặc một số lỗi 5xx từ upstream.
3. Chuyển sang cùng hợp đồng: dùng account, region hoặc đường dẫn provider khác chỉ khi nó phục vụ cùng một hợp đồng model đã được phê duyệt.
4. Dùng phương án dự phòng đã được phê duyệt: chuyển sang model khác chỉ khi chủ sở hữu sản phẩm, chất lượng, tuân thủ và ngân sách chấp thuận phương án dự phòng.
5. Xếp hàng hoặc hạ cấp: trì hoãn công việc không khẩn cấp khi fallback ngay lập tức sẽ tốn kém hoặc rủi ro.
6. Trả về lỗi có kiểm soát: dừng lại khi chính sách cho biết không còn tuyến an toàn nào.

Hướng dẫn cân bằng tải và failover cho AI API trình bày chi tiết hơn về chủ đề này. Trong rà soát kiến trúc, câu hỏi quan trọng là mỗi bước chuyển có rõ ràng và quan sát được hay không.

Quota, Thanh toán, Và Nhật ký Là Một Phần Của Đường Dẫn Yêu Cầu

Lưu lượng mô hình không được tính phí giống như lưu lượng HTTP thông thường. Một LLM API gateway duy nhất có thể phải tính đến token đầu vào, token đầu ra, token được lưu trong bộ nhớ đệm, token suy luận, đơn vị hình ảnh, thời lượng video, lời gọi công cụ, lần thử lại, và các đơn vị hạn ngạch cụ thể của nhà cung cấp. Nếu thanh toán và hạn ngạch bị xem như một báo cáo ban đêm, gateway sẽ không thể ngăn chặn mức sử dụng vượt kiểm soát ngay tại thời điểm đó.

Đặt hạn ngạch và thanh toán gần với chính sách định tuyến:

• Kiểm tra ngân sách còn lại của người gọi trước khi chuyển tiếp các yêu cầu tốn kém.
• Chặn hoặc cảnh báo với các tuyến thiếu dữ liệu định giá khi giới hạn chi tiêu là quan trọng.
• Ghi lại mô hình đã chọn, họ endpoint, tuyến upstream, khóa, chủ sở hữu, trạng thái, và các đơn vị sử dụng.
• Tách riêng các lần thử lại và các cuộc gọi dự phòng trong nhật ký để một yêu cầu người dùng không che khuất nhiều lần thử từ nhà cung cấp.
• Hiển thị rõ khóa staging và production như các trung tâm chi phí khác nhau.
• Xuất đủ dữ liệu cho tài chính, hỗ trợ, và rà soát sự cố.

Vị thế công khai hiện tại của Flatkey bao gồm định giá rõ ràng, thanh toán hợp nhất, khả năng hiển thị mức sử dụng, giới hạn hạn ngạch, và một bảng điều khiển cho khóa, mức sử dụng, và định tuyến. Một ảnh chụp API định giá vào ngày phát hành đã trả về 656 hàng mô hình và hỗ trợ siêu dữ liệu endpoint cho lưu lượng tương thích OpenAI, OpenAI Responses, Anthropic, Gemini, tạo ảnh, và tạo video. Hãy xem đó là bằng chứng đã cũ, rồi xác minh chính xác mô hình và đơn vị của bạn trên trang định giá trực tiếp.

Nơi Flatkey phù hợp trong kiến trúc này

Flatkey được thiết kế để giảm tình trạng phân tán tài khoản nhà cung cấp phía sau một khóa duy nhất. Trong kiến trúc LLM API gateway này, Flatkey tương ứng với endpoint gateway được host, lớp truy cập nhà cung cấp, dashboard, lớp sử dụng/thanh toán, và lớp định tuyến.

Một bài kiểm tra staging cẩn thận cho Flatkey nên trông như sau:

1. Tạo một khóa không dùng cho production trong dashboard Flatkey.
2. Trỏ một client vào https://router.flatkey.ai/v1.
3. Chạy một yêu cầu đã biết là tốt cho họ endpoint mà bạn cần.
4. Xác nhận yêu cầu xuất hiện trong nhật ký sử dụng với model, trạng thái, số đơn vị, và bằng chứng chi phí.
5. Xem lại trang giá trực tiếp cho model và đơn vị tính phí đã chọn.
6. Xác định những nhóm lưu lượng nào có thể dùng chuyển đổi tự động hoặc cân bằng tải.
7. Chạy một bài kiểm tra lỗi an toàn, hoặc ghi rõ vì sao không được phép mô phỏng lỗi trong staging.

Đừng suy ra SLA uptime, cam kết độ trễ, thuật toán định tuyến chính xác, hoặc tính sẵn có được đảm bảo của nhà cung cấp từ bài viết này. Kiến trúc cho bạn biết cần kiểm chứng điều gì; bằng chứng từ staging sẽ cho bạn biết một lần triển khai cụ thể đã sẵn sàng hay chưa.

Implementation Checklist

Trước khi gửi lưu lượng sản xuất qua một LLM API gateway, hãy đảm bảo kiến trúc có sẵn các kiểm soát sau:

Checklist Item	Pass Condition
Base URL and SDK migration	Ít nhất một yêu cầu staging thành công thông qua gateway bằng SDK hoặc client dự kiến.
Model and endpoint mapping	Mỗi họ endpoint production đều có model, giao thức và chủ sở hữu đã được phê duyệt.
Key scope	Các key được tách biệt theo ứng dụng, môi trường, nhóm hoặc khách hàng khi cần.
Routing policy	Các lớp lưu lượng xác định các tuyến chính và tuyến dự phòng được phép.
Failover stop condition	Gateway biết khi nào cần thử lại, chuyển đổi, xếp hàng và đóng lỗi an toàn.
Quota and budget checks	Giới hạn có thể chặn hoặc hạn chế lưu lượng tốn kém trước khi nó đến được nhà cung cấp upstream.
Logs and observability	Có thể xem lại sau đó bằng chứng về request, route, model, owner, status, usage và cost.
Rollback	Ứng dụng có thể quay lại cấu hình nhà cung cấp trước đó nếu việc triển khai gateway thất bại.

Để có cái nhìn rộng hơn về yêu cầu, hãy bắt đầu với AI API gateway checklist. Đối với công việc so sánh nền tảng, hướng dẫn OpenRouter alternatives cho thấy các đánh đổi giữa managed gateway khác với marketplace của nhà cung cấp và các lớp định tuyến tự quản lý như thế nào.

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

LLM API gateway là gì?

Một LLM API gateway là một lớp điều khiển giữa ứng dụng và các nhà cung cấp mô hình. Nó có thể tập trung hóa khóa API, quyền truy cập mô hình, định tuyến, hạn mức, thanh toán, nhật ký và chính sách dự phòng cho lưu lượng LLM.

Kiến trúc của một LLM API gateway nên bao gồm những gì?

Một kiến trúc LLM API gateway nên bao gồm các ứng dụng khách, một endpoint gateway ổn định, xác thực, phạm vi khóa, kiểm tra chính sách, ánh xạ mô hình, định tuyến nhà cung cấp, kiểm tra sức khỏe, quy tắc dự phòng, hạn mức, thanh toán, nhật ký và các nhà cung cấp thượng nguồn.

Failover có luôn an toàn cho lưu lượng LLM không?

Không. Failover chỉ an toàn khi tuyến dự phòng giữ nguyên hợp đồng mô hình đã được phê duyệt, ranh giới dữ liệu, hành vi endpoint, kỳ vọng chất lượng và chính sách chi phí. Một số lưu lượng nên fail closed thay vì chuyển đổi.

LLM API gateway khác gì so với một API gateway thông thường?

Một API gateway thông thường xử lý lưu lượng API chung. LLM API gateway bổ sung các mối quan tâm nhận biết mô hình như định dạng nhà cung cấp, mức sử dụng token và media, ánh xạ mô hình, chính sách dự phòng, kiểm soát chi tiêu, khả năng quan sát prompt/response và định tuyến dành riêng cho AI.

Flatkey nằm ở đâu trong sơ đồ?

Flatkey nằm như lớp gateway được lưu trữ, router, truy cập nhà cung cấp, mức sử dụng, thanh toán và bảng điều khiển. Nội dung công khai của nó hỗ trợ một khóa API, https://router.flatkey.ai/v1, giá rõ ràng, thanh toán hợp nhất, hiển thị mức sử dụng/định tuyến, chuyển đổi tự động và cân bằng tải.

Kết luận cuối cùng

Một cổng API LLM cho môi trường production nên giúp việc kiểm soát lưu lượng mô hình trở nên dễ hơn, chứ không phải khó giải thích hơn. Kiến trúc cần một endpoint ổn định, khóa theo phạm vi, ánh xạ mô hình, kiểm tra chính sách, quy tắc định tuyến, kiểm soát hạn mức và thanh toán, nhật ký, và một điều kiện dừng chuyển đổi dự phòng.

Flatkey cung cấp cho các nhóm một khóa duy nhất, một endpoint bộ định tuyến tương thích với OpenAI, và một bảng điều khiển duy nhất cho quyền truy cập mô hình và vận hành. Để kiểm thử kiến trúc với workload staging của riêng bạn, lấy một khóa và xác minh đường đi của request trước khi chuyển lưu lượng production.