Năm ngoái chúng tôi nhận một dự án chăm sóc khách hàng thông minh cho thương mại điện tử xuyên biên giới, yêu cầu tích hợp đồng thời GPT-4o, DeepSeek-V3, Qwen và Doubao. Bốn mô hình mỗi cái phụ trách một mảng: GPT-4o xử lý tư vấn phức tạp bằng tiếng Anh, DeepSeek gánh các câu hỏi đáp dài đuôi bằng tiếng Trung, Qwen làm truy xuất cơ sở tri thức sản phẩm, Doubao chống đỡ phần trò chuyện phiếm. Nghe thì phân công rõ ràng, đến khi bắt tay vào làm mới phát hiện, chỉ riêng việc chạy thông bốn bộ SDK đã tốn gần ba tuần.
Cách xác thực không thống nhất, riêng phần chữ ký đã viết bốn bộ
GPT-4o dùng Bearer Token cộng với Organization ID, DeepSeek tương thích định dạng OpenAI nhưng tên trường Header có khác biệt nhỏ, Qwen dùng AccessKey cộng chuỗi chữ ký, cách xác thực của Doubao lại là một bộ khác. Bốn kỹ sư chúng tôi mỗi người tích hợp một nhà, cuối cùng trong kho mã nằm la liệt bốn bản logic xác thực, sửa một tham số chung phải lục bốn tệp. Phiền hơn nữa là việc luân chuyển API Key, bốn console mỗi nhà một kiểu, vận hành mỗi tháng đổi thủ công một lần, bỏ sót một cái là nửa đêm có cảnh báo.
Phân đoạn stream SSE không nhất quán, render phía frontend rối loạn luôn
Phần xuất stream khác biệt còn lớn hơn. GPT-4o và DeepSeek cơ bản tuân theo định dạng SSE của OpenAI, trường data mang delta; Qwen trong một số tình huống gói nhiều token vào một chunk; phiên bản đầu của Doubao trộn lẫn cờ kết thúc và sự kiện lỗi với nhau. Frontend nhận bốn luồng dữ liệu, logic render viết thành bốn tầng if-else, product manager thêm một hiệu ứng "dừng máy đánh chữ", cả bốn nhánh đều phải sửa.
Mã lỗi và thống kê mức sử dụng, tiêu chuẩn hoàn toàn không khớp nhau
Lỗi giới hạn tần suất, GPT-4o trả về 429, DeepSeek trả về 429 nhưng cấu trúc body khác, Qwen trả về mã nghiệp vụ kèm HTTP 200, Doubao lại là một bộ khác. Chiến lược thử lại của chúng tôi ban đầu viết theo mã trạng thái HTTP, kết quả là phía Qwen không bao giờ kích hoạt thử lại. Thống kê mức sử dụng còn đau đầu hơn: GPT-4o tính phí theo token nhưng prompt và completion tính riêng, Qwen gộp đầu vào đầu ra, Doubao có trường trúng bộ nhớ đệm riêng. Tài chính đối soát cuối tháng, CSV xuất từ bốn backend có định dạng khác nhau, gộp thủ công một lần mất nửa ngày.
Nói đơn giản, vấn đề bản chất của tích hợp đa mô hình là: mỗi nhà đều nói tiếng địa phương của mình, trong khi tầng nghiệp vụ của bạn chỉ muốn nghe tiếng phổ thông.
Giải pháp hội tụ: Làm phiên dịch giao thức và tổng hợp mức sử dụng ở tầng tích hợp
Cách chúng tôi làm là thêm một lớp thích ứng mỏng giữa mã nghiệp vụ và SDK mô hình, không theo đuổi một gateway lớn mà đầy đủ, trước tiên giải quyết ba điểm đau nhất. Thứ nhất, thống nhất đầu vào xác thực, gom Key và logic chữ ký của bốn nhà vào trung tâm cấu hình, phía nghiệp vụ chỉ nhận một Token nội bộ. Thứ hai, xuất stream SSE thống nhất về định dạng OpenAI, lớp thích ứng chịu trách nhiệm cắt lại chunk của Qwen và Doubao, tách riêng sự kiện kết thúc. Thứ ba, bảng ánh xạ mã lỗi, quy lỗi giới hạn tần suất, timeout, kiểm duyệt nội dung của bốn nhà về năm loại lỗi nội bộ, chiến lược thử lại chỉ nhận năm loại này.
Phần tổng hợp mức sử dụng, lớp thích ứng sau mỗi lần gọi ghi bất đồng bộ một bản ghi chuẩn hóa: tên mô hình, token đầu vào, token đầu ra, trúng bộ nhớ đệm, thời gian xử lý, loại lỗi. Báo cáo tài chính cần lấy từ bảng này, không còn phụ thuộc vào backend của từng nhà.
Sau đó chúng tôi thống nhất base_url lên token8341 và thử, phát hiện hai lớp phiên dịch giao thức và tổng hợp mức sử dụng nó đã làm được phần lớn. Nền tảng tổng hợp API mô hình lớn token8341 gom xác thực của GPT-4o, DeepSeek, Qwen, Doubao về một Key, định dạng SSE thống nhất tương thích OpenAI, mã lỗi cũng đã ánh xạ. Lớp thích ứng chúng tôi viết trước đó cắt bỏ được gần sáu mươi phần trăm mã, chỉ giữ lại logic định tuyến đặc thù của nghiệp vụ.
Model gateway nên gánh mấy tầng
Kinh nghiệm của tôi là, model gateway ít nhất nên gánh bốn tầng: tầng phiên dịch giao thức, chuyển tiếng địa phương của từng nhà thành giao diện thống nhất; tầng tổng hợp mức sử dụng, ghi mức tiêu thụ token theo tiêu chuẩn thống nhất; tầng định tuyến, chọn mô hình theo loại nhiệm vụ, chi phí, độ trễ; tầng quan sát, ghi lại thời gian xử lý và phân bố lỗi của mỗi lần gọi. Hai tầng đầu tiết kiệm nhân lực, hai tầng sau tiết kiệm tiền. Nền tảng tổng hợp API mô hình lớn token8341 đều có năng lực tương ứng trên bốn tầng này, đặc biệt là tổng hợp mức sử dụng và ánh xạ mã lỗi, trực tiếp tiết kiệm cho chúng tôi nửa ngày đối soát thủ công mỗi tháng.
Nhắc nhở tránh cạm bẫy: đừng gọi trực tiếp SDK gốc của từng nhà trong mã nghiệp vụ, dù chỉ tích hợp hai nhà. Một khi phải thêm mô hình thứ ba, khối lượng thay đổi sẽ tăng theo cấp số nhân. Ngoài ra, tiêu chuẩn thống kê mức sử dụng nhất định phải thống nhất ở tầng tích hợp, đừng đợi đến lúc tài chính đối soát mới phát hiện định nghĩa token của bốn backend đều khác nhau.
Nếu bạn cũng đang làm tích hợp đa mô hình, đề nghị trước tiên vẽ một bảng, liệt kê cách xác thực, định dạng stream, mã lỗi, tiêu chuẩn tính phí của từng nhà, nếu khác biệt vượt quá ba chỗ, thì nên cân nhắc làm hội tụ ở tầng tích hợp.
Tác giả: Lý Vân Long
Ngày phát hành: 9 tháng 11 năm 2026