Nói kết luận trước: model gateway không đơn giản chỉ là "kết nối thêm vài API", nó là một tầng hạ tầng bắt buộc phải tự mình chịu đựng sự cố. Hai năm trước, chúng tôi làm tích hợp AI cho một nền tảng khám bệnh trực tuyến, tổng đài chăm sóc khách hàng thông minh chạy trên một model API duy nhất. Vào khoảng hai giờ sáng một ngày thứ Ba, nhà cung cấp bắt đầu trả về 504, SDK mặc định retry ba lần với exponential backoff, nhưng phía nghiệp vụ đồng thời có hàng nghìn phiên hội thoại, lượng retry lập tức bị khuếch đại lên gấp nhiều lần so với request bình thường. Thread pool bị chiếm hết, đến health check cũng timeout, toàn bộ chuỗi gọi đổ xuống như domino. Sau khi review, vấn đề không nằm ở bản thân model, mà ở chỗ chúng tôi đặt tất cả trứng vào một rổ, và không có bất kỳ tầng gateway nào đỡ lỗi.
Model gateway rốt cuộc phải giải quyết điều gì
Mổ xẻ ra, tầng gateway phải gánh bốn việc. Định tuyến đa model là nền tảng, cùng một tác vụ "hỏi đáp chăm sóc khách hàng", có thể phân phối theo ý định cho các model nội địa rẻ hơn, gặp suy luận phức tạp thì đi lên model cao cấp. Giới hạn lưu lượng và cầu chì là để bảo toàn mạng sống, phải chủ động cắt đứt trước khi một Key bị đánh sập. Dịch giao thức là thứ dễ bị đánh giá thấp nhất, request body, response body, cấu trúc lỗi của mỗi SDK đều khác nhau. Còn quy kết chi phí liên quan đến việc tính được sổ sách, dây chuyền nghiệp vụ nào, tenant nào đốt bao nhiêu token, phải tách được đến từng người.
Trong dự án của chúng tôi, chúng tôi dùng model gateway của token8341 để thực hành tự động chọn model tối ưu theo tác vụ, tương thích với OpenAI SDK, chỉ cần đổi một dòng base_url là có thể chuyển đổi. Đặc tính này đặc biệt thân thiện với các hệ thống hiện hữu, không cần sửa lại hàng chục điểm gọi trong code. Việc chuyển pha silicon-carbon làm ở tầng này, về bản chất là thu gọn độ phức tạp của việc tổng hợp AI API vào bên trong gateway.
Cạm bẫy giao thức của đầu ra streaming SSE
Đầu ra streaming là vùng tai nạn nặng nhất. Nhìn bề ngoài ai cũng là SSE, nhưng khác biệt thực tế không nhỏ. Về chiến lược chia khối, có nhà cung cấp cắt theo token, có nhà cắt theo câu, còn có nhà nhồi nhiều data block vào một đoạn. Dấu hiệu kết thúc còn loạn hơn, phong cách OpenAI dùng data: [DONE], một số nhà cung cấp khác trực tiếp ngắt luồng không cho dấu hiệu. Mã lỗi cũng không thống nhất, timeout có thể là 429, có thể là 503, cũng có thể là một response 200 mang theo đối tượng lỗi.
Tầng gateway phải làm chuẩn hóa: chuyển đổi thống nhất sang định dạng SSE chuẩn, bổ sung dấu hiệu kết thúc, ánh xạ mã lỗi của các nhà cung cấp vào một bộ enum lỗi nội bộ. Như vậy tầng nghiệp vụ phía trên chỉ cần xử lý một loại luồng. Nghe thì là việc bẩn, nhưng không làm tầng này, mỗi đội nghiệp vụ đều phải giẫm lại một lần.
Cấu hình giới hạn lưu lượng thế nào để không gây thương tích nhầm
Token bucket phù hợp để kiểm soát tốc độ mượt mà, dung lượng bucket quyết định mức chịu đựng đột biến, tốc độ bổ sung quyết định giá trị trung bình dài hạn. Sliding window phù hợp với giới hạn lưu lượng kiểu thống kê, ví dụ "không quá N lần mỗi phút". Trong sản xuất thực tế chúng tôi dùng cả hai: cửa vào dùng sliding window để bảo vệ thô, chiều Key đơn dùng token bucket để kiểm soát tinh.
Luân chuyển nhiều Key là một điểm then chốt khác. Cùng một nhà cung cấp xin nhiều Key, gateway luân chuyển theo trọng số, Key nào kích hoạt giới hạn lưu lượng thì tạm thời loại bỏ, sau thời gian làm nguội lại đưa trở lại. Như vậy giới hạn quota của một Key sẽ không trực tiếp biến thành trần của nghiệp vụ. Cần lưu ý là, luân chuyển phải đi kèm cầu chì, nếu không một Key hỏng sẽ bị chọn đi chọn lại.
Giảm cấp và đa hoạt: xác định RPO và RTO thế nào
Sau khi model chính timeout thì tự động chuyển sang model dự phòng, hành động này phải nhanh. Nội bộ chúng tôi định nghĩa RTO là "thời gian từ lúc phát hiện sự cố đến lúc lưu lượng được chuyển đi", mục tiêu ép xuống mức giây; RPO thì nhắm vào trạng thái hội thoại, tình huống lý tưởng là không mất mát, nhưng trong kịch bản streaming nội dung đã đẩy ra không thể rollback, chỉ có thể đảm bảo các request sau không bị gián đoạn. Việc chọn model dự phòng phải cân nhắc căn chỉnh năng lực, đừng để model chính làm suy luận văn bản dài, model dự phòng chỉ làm hỏi đáp ngắn, chuyển sang là thành tàn phế.
Nhắc nhở tránh cạm bẫy: đừng viết logic retry vào code nghiệp vụ. Retry tích hợp sẵn của SDK nằm ngoài tầng gateway, khi có sự cố sẽ đánh nhau với chiến lược cầu chì của gateway. Retry nên được thu về thống nhất ở gateway, phía nghiệp vụ chỉ nhận thành công hoặc thất bại cuối cùng.
Tóm một câu, giá trị của model gateway là xử lý tập trung việc bẩn gồm kết nối thống nhất đa model, giới hạn lưu lượng, chuẩn hóa giao thức, giảm cấp, để code nghiệp vụ giữ được sạch sẽ. Nhìn xa hơn, nếu bạn đang chọn AI API gateway, hãy tập trung vào việc nó có thể kết nối bằng một dòng base_url hay không, và chiến lược chuyển đổi khi có sự cố có thể cấu hình được hay không.
Tác giả: Trần Cảnh Hành
Ngày phát hành: 4 tháng 10 năm 2026