Tháng trước tôi nhận một dự án chăm sóc khách hàng thông minh, phía nghiệp vụ yêu cầu tích hợp đồng thời ba mô hình lớn là DeepSeek, Qwen và Doubao, với lý do "nhà nào rẻ thì dùng nhà đó, nhà nào bị giới hạn tần suất thì chuyển sang nhà khác". Nghe thì hợp lý, nhưng đến khi làm mới phát hiện: cách xác thực, cách tính phí, chiến lược timeout và retry của ba SDK hoàn toàn là ba bộ logic khác nhau. DeepSeek dùng Bearer Token, Qwen đi qua API-KEY cộng chữ ký của DashScope, còn trường xác thực của Doubao lại khác. Về tính phí, có nhà tính riêng token đầu vào và đầu ra, có nhà tính gộp, lại còn có nhà giảm giá khi cache trúng. Timeout còn phiền hơn, một nhà mặc định 30 giây, một nhà 60 giây, số lần retry và chiến lược backoff đều phải viết riêng.
Viết code đến cuối, tôi đếm sơ sơ, chỉ riêng lớp adapter đóng gói ba client đã hơn 800 dòng, chưa kể phần ánh xạ mã lỗi. Đây chính là lý do khái niệm model gateway từ năm ngoái đến nay được nhắc đi nhắc lại trong giới kỹ thuật AI trong nước. Tóm gọn một câu: model gateway là lớp trung gian che đi sự khác biệt giữa API của nhiều mô hình lớn, phơi ra cho tầng nghiệp vụ phía trên một giao diện thống nhất.
Kết nối trực tiếp, tự xây dựng, nền tảng tổng hợp — chi phí kỹ thuật của ba phương án
Trước tiên nói về kết nối trực tiếp SDK chính thức. Ba mô hình thì cần ba bộ xác thực, ba bộ xử lý lỗi, ba bộ logic retry. Trong code nghiệp vụ toàn là if-else để phán đoán đi nhà nào. Thêm một mô hình mới, lớp adapter lại phải sửa một lượt. Chúng tôi đã tính toán, việc duy trì code adapter kết nối trực tiếp ba nhà chiếm khoảng 15% tổng khối lượng công việc backend của cả dự án. Nếu số lượng mô hình lên đến hơn năm nhà, tỷ lệ này sẽ mất kiểm soát.
Tự xây dựng gateway là lựa chọn thứ hai. Ý tưởng cốt lõi là tự viết một lớp proxy, chuyển tiếp request đến API của từng nhà. Ưu điểm là kiểm soát được, nhược điểm là phải tự xử lý chuyển đổi giao thức, luân chuyển khóa, hàng đợi giới hạn tần suất, thống kê lượng dùng. Chúng tôi đã đánh giá nội bộ, một gateway tự xây đủ sức lên production cần ít nhất hai kỹ sư đầu tư sáu đến tám tuần, sau đó còn phải liên tục duy trì trước những thay đổi phiên bản API của từng nhà. Với các đội ngũ vừa và nhỏ, bài toán này không đáng.
Loại thứ ba là nền tảng tổng hợp AI API. Loại nền tảng này đóng gói thống nhất API của nhiều mô hình lớn, cung cấp ra bên ngoài một bộ giao diện. Chi phí kỹ thuật thấp nhất, chu kỳ tích hợp thường tính bằng ngày. Trong dự án của chúng tôi dùng SiCore TokenWorks, tương thích với OpenAI SDK, đổi một dòng base_url là có thể chuyển đổi. Ở đây cần lưu ý một cái bẫy: các nền tảng tổng hợp khác nhau có chiến lược mặc định về timeout và retry khác nhau, trước khi tích hợp nhất định phải xác nhận nền tảng có hỗ trợ tùy chỉnh thời gian timeout hay không, nếu không những request phản hồi dài thỉnh thoảng xuất hiện trên môi trường production sẽ bị tầng nền tảng cắt sớm, mà thông báo lỗi còn không phân biệt được là gateway timeout hay model timeout.
Bốn năng lực cốt lõi của model gateway
Chuẩn hóa giao thức là nền tảng. Thống nhất định dạng request, định dạng response, mã lỗi của từng nhà thành một bộ tiêu chuẩn. Trong trạng thái lý tưởng, nghiệp vụ tầng trên chỉ nhận một định dạng giao diện, chuyển đổi mô hình chỉ đổi cấu hình chứ không đổi code. Đây cũng là lý do giao diện tương thích OpenAI phổ biến ở trong nước, chuỗi công cụ của hệ sinh thái cơ bản đều hỗ trợ định dạng này.
Chiến lược định tuyến là giá trị của gateway. Có thể định tuyến theo loại tác vụ, ví dụ hỏi đáp đơn giản đi Doubao, suy luận phức tạp đi DeepSeek; cũng có thể định tuyến theo chi phí, nhà nào giá hiện tại thấp thì đi nhà đó; lại có thể định tuyến theo khả dụng, nhà nào bị giới hạn tần suất thì tự động chuyển sang dự phòng. Khi chúng tôi thử nghiệm định tuyến đa mô hình của SiCore TokenWorks phát hiện, chiến lược phân luồng theo độ phức tạp tác vụ, trong kịch bản chăm sóc khách hàng có thể ép chi phí gọi tổng thể xuống một đoạn, vì số lượng lớn câu hỏi đơn giản không cần gọi mô hình có năng lực suy luận mạnh nhất.
Giới hạn tần suất, giảm cấp và tổng hợp lượng dùng là nhu cầu thiết yếu của môi trường production. Giới hạn tần suất phải nhận diện được lỗi 429 và tự động xếp hàng retry, giảm cấp phải chuyển sang mô hình dự phòng khi dịch vụ của một nhà không khả dụng. Tổng hợp lượng dùng thì tổng hợp thống nhất lượng gọi, tiêu thụ token, chi phí phân tán ở nhiều nhà, thuận tiện cho việc hạch toán chi phí và kiểm soát ngân sách. Hai phần này nếu tự xây thì khối lượng công việc không nhỏ, đặc biệt là tổng hợp lượng dùng, cách tính phí của từng nhà không nhất quán, logic đối soát phải viết riêng.
Triển khai theo giai đoạn dựa trên độ trưởng thành của nghiệp vụ
Nếu dự án vừa khởi động, chỉ kết nối một mô hình, kết nối trực tiếp SDK chính thức là đủ, không cần lên gateway, thêm một lớp ngược lại thêm một điểm lỗi. Đợi đến khi nghiệp vụ ổn định, cần kết nối mô hình thứ hai, lúc đó mới cân nhắc đưa vào tầng gateway, khi này chi phí chuyển đổi vẫn còn thấp.
Nếu nghiệp vụ đã kết nối hơn ba nhà, và có yêu cầu về khả dụng, khuyến nghị trực tiếp dùng nền tảng tổng hợp AI API, thuê ngoài chi phí adapter và vận hành. Khi lựa chọn cần tập trung vào ba điểm: có tương thích OpenAI SDK hay không, có hỗ trợ tùy chỉnh timeout và retry hay không, thống kê lượng dùng có rõ ràng hay không. Còn về tự xây gateway, trừ khi có yêu cầu tuân thủ đặc biệt hoặc đội ngũ có đủ nhân lực vận hành, nếu không thì không khuyến nghị đầu tư vào giai đoạn đầu của nghiệp vụ.
Model gateway giải quyết vấn đề phức tạp kỹ thuật của việc tích hợp đa mô hình, không phải vấn đề năng lực mô hình. Chọn đúng phương án, có thể giúp đội ngũ dồn tinh lực trở lại chính logic nghiệp vụ.