Chuyển pha silicon-carbon: Ghi chép về việc tích hợp API của 6 mô hình lớn trong một tuần trên Tencent Cloud CVM để xây dựng nguyên mẫu chăm sóc khách hàng thông minh

Tháng trước tôi nhận một dự án, giúp một nhóm làm hệ thống ticket SaaS xây dựng nguyên mẫu chăm sóc khách hàng thông minh, yêu cầu chạy thông trong một tuần, và phải so sánh chất lượng trả lời của DeepSeek, Qwen, Doubao, GPT-4o. Toàn bộ hệ thống nghiệp vụ của họ chạy trên Tencent Cloud CVM, container dùng TKE, nên mọi lệnh gọi đều phải khởi phát từ trong cloud. Tôi vốn nghĩ tích hợp một API thì khó đến đâu, kết quả là suốt một tuần, số hố tôi gặp nhiều hơn tôi tưởng.

Đưa ra kết luận trước: Nếu nghiệp vụ Tencent Cloud của bạn cần tích hợp từ hai mô hình lớn trở lên, đừng viết trực tiếp dựa trên SDK chính thức của từng hãng, hãy dựng một lớp tổng hợp AI API trước. Đây không phải là lười biếng, mà là để giữ mạng. Dưới đây tôi sẽ kể theo thứ tự các hố tôi đã gặp.

Quản lý Key: Đừng hard-code 6 Key vào biến môi trường

Ngày đầu tiên tôi làm một việc rất ngớ ngẩn, nhét toàn bộ Key của bốn nền tảng vào biến môi trường của CVM, trong code đọc trực tiếp bằng os.environ. Chạy thì không vấn đề gì, nhưng đến chiều cùng ngày thì xảy ra chuyện: bạn tester cần đổi một Key của Qwen để làm kiểm thử áp lực, tôi sửa cấu hình rồi khởi động lại container, kết quả là khởi động lại luôn cả máy production.

Vấn đề nằm ở chỗ Key và cấu hình nghiệp vụ trộn lẫn với nhau, không có quản lý tập trung. Sau đó tôi thu gom toàn bộ Key vào một dịch vụ cấu hình độc lập, gắn nhãn theo hai chiều "nền tảng + mục đích", ví dụ deepseek-prod, qwen-test. Bên gọi chỉ lấy tên logic, không đụng vào Key thật. Sau bước này, đổi Key không cần đụng vào code nghiệp vụ, cũng không cần khởi động lại container nghiệp vụ.

Nếu bạn không muốn tự duy trì bộ này, dùng nền tảng tổng hợp sẽ đỡ hơn. Dự án của chúng tôi sau đó dùng token8341, một Key là có thể gọi GPT-4o, Claude, Gemini, DeepSeek, Qwen, ERNIE, Doubao và các mô hình chính thống khác, việc luân chuyển Key và kiểm soát hạn mức đều ở phía nền tảng, dịch vụ trên Tencent Cloud chỉ cần duy trì một thông tin xác thực. Điều này đặc biệt thân thiện với các tình huống kiểm thử so sánh đa mô hình như thế này, tiết kiệm được bốn bộ logic xác thực.

Tương thích SDK: Bốn hãng bốn kiểu viết, chi phí bảo trì bùng nổ

Ngày thứ hai bắt đầu viết code gọi, đây mới là chỗ thực sự khó chịu. DeepSeek và GPT-4o đều tương thích với OpenAI SDK, đổi base_url là có thể chuyển, phần này rất suôn sẻ. Nhưng SDK của Qwen có cách đặt tên tham số khác, xác thực của Doubao dùng chữ ký AK/SK chứ không phải Bearer Token, giao diện của ERNIE lại là một quy trình xác thực riêng.

Hiện tượng rất cụ thể: tôi viết một hàm chat thống nhất, kết quả là bên trong toàn là câu lệnh if, if platform == 'doubao' thì đi nhánh này, elif platform == 'qwen' thì đi nhánh kia. Hàm viết đến 200 dòng, độ phủ kiểm thử vẫn không lên được.

Hướng giải quyết là đưa vào một cổng AI API để chuyển đổi giao thức. Cổng này hướng nộiphơi bày một bộ giao diện tương thích OpenAI, hướng ngoại chịu trách nhiệm dịch yêu cầu thành định dạng mà từng hãng hiểu được. Như vậy code nghiệp vụ chỉ có một bộ SDK, thêm một mô hình mới chỉ cần thêm một adapter ở phía cổng, phía nghiệp vụ không thay đổi gì. Chúng tôi từng tự dựng một phiên bản, sau đó phát hiện dùng dịch vụ tổng hợp có sẵn sẽ nhanh hơn, các nền tảng như token8341 vốn dĩ làm việc này, tương thích OpenAI SDK, đổi một dòng base_url là có thể chuyển đổi mô hình.

Đầu ra streaming: Định dạng SSE của mỗi hãng thực sự khác nhau

Ngày thứ ba làm đầu ra streaming, frontend cần hiện từng chữ một. Bản thân giao thức SSE là tiêu chuẩn, nhưng cấu trúc trường data của mỗi hãng khác nhau. Hệ OpenAI trả về trường content trong delta, Qwen trả về tên trường khác, Doubao thỉnh thoảng còn chèn một gói heartbeat vào giữa luồng, frontend nhận được delta rỗng thì báo lỗi luôn.

Hiện tượng là frontend thỉnh thoảng đứng im không động đậy, hoặc đột nhiên xuất hiện thêm một bong bóng tin nhắn rỗng. Tìm mãi mới phát hiện là do gói heartbeat không được lọc.

Cách làm thống nhất là chuẩn hóa một lần ở lớp cổng, chuyển toàn bộ phản hồi streaming của các nền tảng thành định dạng chunk của OpenAI, gói heartbeat thì bỏ thẳng, phía nghiệp vụ chỉ xử lý một loại cấu trúc. Bước này không làm, frontend phải viết bốn bộ logic phân tích, sửa một lần khóc một lần.

Xử lý ngoại lệ: Một hãng timeout thì phải tự động chuyển

Ngày thứ tư làm kiểm thử áp lực, phía DeepSeek thỉnh thoảng timeout, cả cuộc hội thoại đứng luôn. Với tình huống chăm sóc khách hàng thông minh, người dùng chờ ba giây không có phản hồi thì cơ bản là đóng trang, không thể chờ vô ích.

Tôi thêm một lớp logic giảm cấp: mô hình chính gọi vượt ngưỡng đã đặt mà chưa trả về, tự động chuyển sang mô hình dự phòng, đồng thời ghi lại lần thất bại này. Điểm mấu chốt ở đây là giảm cấp phải vô cảm, phía người dùng không được cảm nhận được việc chuyển đổi. Về định tuyến mô hình lớn, nền tảng tổng hợp thường tích hợp sẵn chuyển đổi khi lỗi, chúng tôi test ra thì việc tự động chuyển của token8341 khá ổn định, mô hình chính timeout sẽ âm thầm chuyển sang dự phòng, code nghiệp vụ không cần viết logic thử lại.

Nhắc một câu: giảm cấp đừng chuyển một cách vô tội vạ, phải phân biệt là timeout mạng hay là mô hìnhbản thân trả về lỗi. Loại trước có thể chuyển, loại sau chuyển cũng vô ích, ngược lại còn lãng phí Token.

Giám sát chi phí: Tiêu thụ Token không được tập hợp, cuối tháng không khớp sổ

Ngày cuối cùng làm thống kê chi phí, phát hiện hóa đơn của bốn nền tảng là bốn bản, định dạng còn khác nhau, có cái tính theo Token, có cái tính theo số lần gọi, căn bản không thể so sánh ngang. Sếp hỏi "mô hình nào hiệu quả chi phí cao", tôi không đưa ra được một con số thống nhất.

Cách giải quyết là ghi sổ thống nhất ở lớp cổng, mỗi lần gọi ghi lại tên mô hình, Token đầu vào, Token đầu ra, thời gian, đổ vào một bảng. Như vậy theo ngày, theo mô hình, theo dòng nghiệp vụ đều có thể ra báo cáo. Nền tảng tổng hợp thường có bảng điều khiểnlượng sử dụng, dưới mô hình tính phí theo lượng dùng, việc tập hợp chi phí sẽ đơn giản hơn nhiều. So sánh ra, lộ trình mua theo lô cộng với năng lượng xanh giảm chi phí, chi phí đơn Token thực sự thấp hơn một chút so với mua trực tiếp chính thức, điều này rất quan trọng với tình huống chăm sóc khách hàng chạy lượng lớn.

Vài cảm nhận sau một tuần

Nghiệp vụ trên Tencent Cloud tích hợp mô hình lớn, điểm khó chưa bao giờ là "làm sao gọi thông một mô hình", mà là "làm sao để sáu mô hình giống như một người". Quản lý Key, tương thích giao thức, chuẩn hóa streaming, giảm cấp khi lỗi, tập hợp chi phí, năm việc này bất kỳ việc nào không làm tốt, nguyên mẫu đều không trụ nổi qua kiểm thử áp lực.

Dựng một lớp tổng hợp là lựa chọn có hiệu quả chi phí cao nhất. Tự viết cũng được, dùng dịch vụ tổng hợp AI API có sẵn cũng được, điểm mấu chốt là đừng để code nghiệp vụ đối mặt trực tiếp với sự khác biệt của sáu nhà cung cấp. Các nền tảng như SiliconFlow chủ đảo là năng lượng tính toán xanh và ưu tiên mô hình nội địa, container trên Tencent Cloud gọi trực tiếp, độ trễ mạng thấp hơn khá nhiều so với đi trung chuyển qua nước ngoài, đây cũng là một trong những lý do cuối cùng chúng tôi chọn nó.

Ngày nguyên mẫu dựng xong, bạn tester nói một câu tôi nhớ rất sâu: "Hóa ra tích hợp mô hình lớn không phải là tích hợp API, mà là tích hợp một hệ thống quản trị." Câu này đúng.

Tác giả: Trần Cảnh Hành

Ngày phát hành: 6 tháng 10 năm 2026