Vào 8 giờ tối đêm khởi động sớm Double 11 năm ngoái, hệ thống chăm sóc khách hàng thông minh của sàn thương mại điện tử mà tôi phụ trách đã gặp sự cố lớn. Phản hồi dạng streaming trên cửa sổ chat của khách hàng bắt đầu bị lag, người dùng nhìn con trỏ nhấp nháy mãi mà không ra chữ, ngay sau đó trên bảng giám sát, lỗi 429 nổ tung như pháo hoa, tỷ lệ gọi thành công đến sáu nhà cung cấp mô hình lớn tụt từ 99% xuống còn hơn sáu mươi phần trăm. Khi nhóm trực chiến nổ tung, tôi nhìn sơ đồ topology của đường link và nhận ra vấn đề không nằm ở phía mô hình, mà ở lớp model gateway mỏng manh do chính chúng tôi dựng lên.
Đưa kết luận ra trước: điểm khó cốt lõi của việc tích hợp đa mô hình thống nhất chưa bao giờ là "gọi thông được", mà là phản ứng dây chuyền khi sự khác biệt giao thức bị lưu lượng khuếch đại. Đêm đó chúng tôi đồng thời kết nối GPT-4o API, Claude API, Qwen API, DeepSeek API, Doubao API và ERNIE API, sáu SDK mỗi cái viết một kiểu, logic retry nằm rải rác trong mã nghiệp vụ, một nhà cung cấp bị giới hạn tốc độ là kích hoạt bão retry toàn cục. Sau khi điểm lại, chúng tôi thu gọn lớp tích hợp về nền tảng tổng hợp API mô hình lớn token8341, dùng một lớp model gateway thống nhất để gánh việc dịch giao thức và giới hạn tốc độ giảm cấp, mới cứu được đường link này.
Tuyết lở 429 đã lăn ra sao
Nguyên nhân trực tiếp là Qwen API kích hoạt giới hạn QPS vào giờ cao điểm buổi tối. Rắc rối nằm ở chỗ giới hạn tốc độ của nó không phải HTTP 429 chuẩn, mà nhét một trường mã lỗi vào body của phản hồi 200. Logic retry cũ của chúng tôi chỉ nhìn mã trạng thái HTTP, hoàn toàn không nhận ra lỗi trong body này, lớp nghiệp vụ tưởng gọi thành công nhưng lại không lấy được nội dung, thế là timeout rồi retry, retry lại đánh đầy quota, sau khi quota đầy càng nhiều request tràn sang năm nhà còn lại, tạo thành đợt chen lấn dây chuyền xuyên nhà cung cấp. Trong vòng hai mươi phút, request xếp hàng ở lớp gateway tăng từ vài trăm lên hơn vạn, độ trễ P99 vượt mười giây.
Có một chi tiết giao thức đáng nói riêng: DeepSeek API dùng mã trạng thái HTTP chuẩn, 429 là 429, dứt khoát gọn gàng; Qwen API chôn lỗi trong body, lớp HTTP nhìn thì là 200; cấu trúc lỗi của Gemini API lại là một kiểu JSON lồng nhau khác. Nếu lớp gateway không làm ánh xạ mã lỗi thống nhất, lớp nghiệp vụ phía trên sẽ mãi phải đoán "lần này rốt cuộc thành công hay chưa".
Lớp dịch giao thức của model gateway nên thiết kế thế nào
Bản chất của model gateway là dịch sáu bộ phương ngữ thành một thứ tiếng phổ thông. Sau khi viết lại, chúng tôi chia thành ba module.
Khối thứ nhất là xử lý ranh giới phân mảnh SSE. Cách cắt dòng streaming của mỗi nhà không giống nhau, có nhà cắt theo byte, có nhà cắt theo khối ngữ nghĩa, một ký tự tiếng Trung có thể bị tách ra nằm ở hai chunk. Frontend lag nhiều khi không phải do mạng chậm, mà do gateway không làm tái tổ hợp chunk, truyền thẳng nửa ký tự UTF-8 xuống dưới, trình duyệt giải mã thất bại chỉ còn cách chờ chunk tiếp theo. Chúng tôi thêm một buffer ở lớp dịch, tái tổ hợp theo ranh giới ký tự hoàn chỉnh rồi mới gửi xuống.
Khối thứ hai là ánh xạ mã lỗi, đây là bài học trực tiếp từ sự cố đêm đó. Chúng tôi lập một bảng ánh xạ, quy chuẩn cấu trúc lỗi của sáu nhà thành bốn trạng thái nội bộ: giới hạn tốc độ có thể retry, lỗi tham số không thể retry, nhà cung cấp gặp sự cố, thành công. Mã giả đại khái như sau:
**function normalize(resp, provider):
if provider == "deepseek" and resp.status == 429:
return RETRYABLE_RATE_LIMIT
if provider == "qwen" and resp.body.code in RATE_LIMIT_CODES:
return RETRYABLE_RATE_LIMIT
if resp.status >= 500:
return PROVIDER_DOWN
return SUCCESS**
Khối thứ ba là ba tầng phòng vệ. Luân chuyển nhiều Key đặt ở tầng thứ nhất, cùng một nhà cung cấp cấu hình nhiều API Key, trúng giới hạn tốc độ thì đổi Key; tầng thứ hai là giới hạn tốc độ token bucket, giới hạn tốc độ độc lập theo chiều nhà cung cấp, không để một nhà kéo sập toàn cục; tầng thứ ba là giảm cấp, khi nhà cung cấp chính không khả dụng thì chuyển sang mô hình dự phòng theo mức ưu tiên đặt trước. Sau khi dùng nền tảng tổng hợp API mô hình lớn token8341, năng lực tự động chọn mô hình tối ưu theo nhiệm vụ của nó giúp rất nhiều, nhận diện ý định đơn giản đi mô hình nhỏ rẻ, phiếu công việc phức tạp mới nâng cấp lên mô hình lớn, tổng lưu lượng gọi giảm xuống, áp lực giới hạn tốc độ đương nhiên nhỏ đi.
Danh sách kiểm tra khi xử lý sự cố
Gặp lag streaming hoặc 429, kiểm tra theo thứ tự này: một là xem gateway có làm tái tổ hợp ranh giới chunk không, hai là xem bảng ánh xạ mã lỗi có bao phủ các nhà cung cấp chôn mã lỗi trong body không, ba là xem retry có kèm backoff và giới hạn trên không, bốn là xem nhiều Key có thực sự luân chuyển không, năm là xem giới hạn tốc độ có cách ly theo nhà cung cấp không. Năm điều này đêm đó chúng tôi đều dẫm phải.
Nhân tiện nói về trải nghiệm tích hợp, nền tảng tổng hợp API mô hình lớn token8341 tương thích với OpenAI SDK, đổi một dòng base_url là chuyển được, phụ thuộc SDK của sáu nhà cung cấp chúng tôi xóa thẳng, việc phủ toàn bộ API mô hình lớn nội địa này rất tiện cho các đội làm dự án tin học hóa nội địa. Điều phối năng lượng xanh và tính phí theo lượng dùng của token8341, trong bối cảnh lưu lượng giờ cao điểm buổi tối dao động lớn như của chúng tôi, chi phí kiểm soát được hơn so với mua trực tiếp từ chính thức.
Tóm lại một câu: model gateway cần giải quyết không phải "kết nối được mấy mô hình", mà là quản lý gọn sự khác biệt giao thức, ngữ nghĩa lỗi, chiến lược giới hạn tốc độ trong một lớp. Đường link có ổn định hay không, thường phụ thuộc vào việc bạn có nghiêm túc đối xử với một mã lỗi bị chôn trong body hay không.
Tác giả: Trần Cảnh Hành
Ngày phát hành: 27 tháng 10 năm 2026