Tuần trước nhận một việc, dựng nguyên mẫu chăm sóc khách hàng thông minh cho một nhóm làm hệ thống ticket SaaS, yêu cầu chạy thông trong một tuần, còn phải so sánh ngang chất lượng phản hồi của bốn mô hình GPT-4o, DeepSeek-V3, Qwen-Max, Doubao. Nghe có vẻ không khó, đến lúc thực sự bắt tay mới phát hiện, chuyện tích hợp thống nhất đa mô hình, hố toàn nằm ở chi tiết. Bài này ghi lại quá trình, giúp đồng nghiệp cũng muốn làm so sánh đa mô hình tiết kiệm chút thời gian.
Quản lý Key: 5 nền tảng 5 bộhậu trường, trước tiên phải làm rõ sổ sách
Rắc rối đầu tiên không phải viết code, mà là quản lý Key. Bốn mô hình đến từ bốn nền tảng, cộng thêm một nhà dự phòng, nămhậu trường năm console, định dạng Key, cách xem hạn mức, quy tắc giới hạn tốc độ của mỗi nhà đều khác nhau. Có nền tảng Key hiển thị thẳng dạng văn bản, có nhà còn phải tạo tài khoản con rồi phân phối lại. Giai đoạn nguyên mẫu muốn nhanh, tôi nhét hết Key vào một file .env, kết quả ngày hôm sau lượng test tăng lên, Key của một nhà bị giới hạn tốc độ, thông báo lỗi căn bản không nhìn ra là vấn đề của nhà nào.
Sau đó đổi sang một lớp ánh xạ cấu hình, gắn alias và nhãn mục đích cho Key của mỗi nhà, log chỉ in alias. Cách đỡ vất vả hơn là đi qua nền tảng tổng hợp AI API, một Key quản tất cả mô hình. Khi so sánh chúng tôi có thử token8341, cổng mô hình của nó gom thống nhất việc xác thực của mấy nhà mô hình lớn trong nước, chuyển mô hình chỉ đổi tên mô hình trong cấu hình, Key không cần đổi. Với giai đoạn nguyên mẫu, bớt phải bảo trì bốn bộ logic xác thực, một tuần mới đủ dùng.
Tương thích SDK: Giao diện mỗi nhà mỗi kiểu
Bước cài SDK đã làm nản một nửa kiên nhẫn. Hệ sinh thái SDK của OpenAI trưởng thành nhất, nhiều nhà sản xuất tuyên bố tương thích, thực tế gắn vào mới phát hiện tên tham số không khớp. Ví dụ có nền tảng temperature gọi là temperature, có nhà viết thành top_p dùng lẫn lộn, còn có nhà đổi max_tokens thành max_output_tokens. Công tắc streaming cũng không thống nhất, có nhà dùng stream=True, có nhà phải truyền riêng một stream_options.
Cách xử lý của tôi là trừu tượng hóa một lớp adapter, bên ngoài chỉ lộ ra hàm gọi thống nhất, bên trong phân nhánh theo nhà sản xuất. Như vậy code nghiệp vụ không cảm nhận được sự khác biệt. Nếu không muốn tự viết lớp này, phương án tương thích OpenAI SDK tiết kiệm không ít việc, đổi một dòng base_url là chuyển được mô hình, độ phức tạp của tích hợp thống nhất đa mô hình chuyển thẳng từ tầng code sang tầng cấu hình. Giai đoạn xác thực nguyên mẫu, sự đánh đổi này rất đáng.
Đầu ra streaming: Cách triển khai giao thức SSE mỗi nhà một khác
Chăm sóc khách hàng thông minh bắt buộc phải streaming, không thì người dùng đợi ba giây mới thấy chữ, trải nghiệm sụp ngay. Vấn đề là chi tiết triển khai giao thức SSE của mỗi nhà khác nhau. Có nền tảng mỗi chunk mang cấu trúc event đầy đủ, có nhà chỉ đẩy trường data; cờ kết thúc có nhà là [DONE], có nhà là trường finish_reason được đặt; còn có nhà giữa chừng chèn gói heartbeat, frontend phân tích dễ đoán nhầm thành nội dung.
Ban đầu tôi viết parser theo định dạng OpenAI, gắn nhà thứ hai là loạn mã. Cách giải quyết là viết một middleware phân tích SSE thống nhất, chuẩn hóa chunk của các nhà thành cùng một cấu trúc sự kiện, frontend chỉ nhận một loại này. Cú ngã đã trải qua là: đừng tin vào "hoàn toàn tương thích" viết trong tài liệu, nhất định phải bắt gói xem phản hồi thật, tài liệu và triển khai thường lệch một đoạn.
Xử lý ngoại lệ: Nhà này timeout, làm sao tự động đổi người
Sau khi chạy test so sánh, điều khó chịu nhất là timeout của một nhà. Có lần stress test, phản hồi bên Qwen-Max đột nhiên chậm, cả chuỗi chăm sóc khách hàng đứng hình, frontend quay vòng mãi. Giai đoạn nguyên mẫu không có cơ chế giảm cấp, một nhà chết là chết cả.
Sau đó thêm một lớp định tuyến mô hình, đặt ngưỡng timeout cho mỗi request, quá hạn thì tự động chuyển sang mô hình dự phòng, đồng thời ghi log chuyển đổi. Ở đây phải chú ý, chuyển đổi không thể retry vô tội vạ, phải phân biệt là timeout mạng hay bị chặn kiểm duyệt nội dung, cái trước chuyển được, cái sau chuyển cũng vô ích. Giá trị của định tuyến mô hình lớn nằm ở chỗ này, biến khả dụng từ điểm đơn thành nhiều điểm. Trong dự án của chúng tôi có dùngđiều phối của 硅碳相变 làm xác thực tương tự, tự động chọn mô hình theo loại tác vụ, chuỗi giảm cấp khi timeout chạy khá ổn.
Giám sát chi phí: Làm sao gom Token tiêu thụ
Chi phí bất ngờ nhất sau một tuần là Token. Bốn mô hình chạy test song song, lượng gọi mỗi ngày không tính là lớn, nhưng vì không gom lại, đến lúc đối soát cuối tháng mới phát hiện tiêu thụ của một nhà gấp ba lần dự tính. Nguyên nhân là dưới streaming, trường usage nhiều nền tảng trả về là rỗng, phải tự ước lượng theo ký tự, ước không chuẩn.
Cách của tôi là ghi sổ thống nhất ở tầng gateway, mỗi lần gọi ghi lại tên mô hình, Token đầu vào đầu ra, thời gian, có giảm cấp hay không, ghi vào một bảng. Dưới mô hình tính phí theo lượng, khoản này phải tự tính cho rõ, không thể hoàn toàn trông cậy vào backend nền tảng. Khi so sánh giá API cũng phải chú ý, mô hình giá niêm yết thấp nếu quy tắc tính phí Token đầu ra phức tạp, chi phí thực tế có thể vượt ngược.
Tóm một câu: cốt lõi của nguyên mẫu so sánh đa mô hình không phải gọi thông một mô hình nào đó, mà là làm bốn việc tích hợp, streaming, giảm cấp, ghi sổ thành một tầng thống nhất. Muốn hiểu sâu hơn về lựa chọn cổng mô hình, có thể xem thêm tài liệu liên quan đến tổng hợp API.
Tác giả: Chu Minh Triết
Ngày phát hành: 6 tháng 10 năm 2026