Nói kết luận trước: chatbot chăm sóc khách hàng đốt tiền, tám phần không phải do đơn giá model đắt, mà là do cách gọi API có vấn đề. Một chatbot hỏi đáp hậu mãi nội bộ của chúng tôi với vài nghìn người dùng hoạt động mỗi ngày, ngay tháng đầu tiên ra mắt hóa đơn đã vọt thẳng lên gấp ba lần ngân sách. Sau khi rà soát, đơn giá model không hề thay đổi, tất cả đều là chi phí ẩn trong cấu trúc gọi API. Bài này viết lại quá trình điểm lại, những ai đang quan tâm đến tối ưu chi phí API model lớn có thể đối chiếu với hóa đơn của mình để kiểm tra một lượt.
Hóa đơn bất thường trông như thế nào
Đặc điểm của bất thường không phải là "tổng số cao", mà là "cấu trúc kỳ lạ". Chúng tôi kéo chi tiết gọi API theo ngày, phát hiện ba điểm không ổn: những ngày có lượng gọi cao nhất, số token trung bình mỗi lần request đang tăng lên; tỷ lệ số lần retry chiếm gần hai mươi phần trăm; cùng một câu hỏi của người dùng, ngắn thì vài trăm token, dài thì hàng vạn token, phương sai cực lớn. Ba điều này cộng lại, cơ bản có thể xác định vấn đề không nằm ở phía model, mà nằm trong chuỗi gọi API của chính chúng tôi.
Bốn khoản chi phí ẩn, cái sau càng khó phát hiện hơn cái trước
Thứ nhất, model flagship làm việc thô. Ban đầu chúng tôi vì tiện, tất cả request đều đi qua model flagship. Nhưng trong kịch bản chăm sóc khách hàng, hơn bảy mươi phần trăm là nhận diện ý định và trả lời theo mẫu cố định như "đơn hàng của tôi đến đâu rồi" "làm sao để trả hàng", những tác vụ này dùng model nhỏ hoàn toàn đủ, chi phí chênh lệch cả một bậc độ lớn. Để model flagship trả lời "mấy giờ mở cửa", chẳng khác nào dùng xe tải đi giao đồ ăn.
Thứ hai, ngữ cảnh phình to không kiểm soát. Trong hội thoại nhiều lượt, chúng tôi nhồi toàn bộ tin nhắn lịch sử trở lại, người dùng trò chuyện đến lượt thứ mười, chỉ riêng lịch sử đã chiếm phần lớn token. Rắc rối hơn là, nhiều lịch sử chẳng liên quan gì đến câu hỏi hiện tại, thuần túy chạy theo cho có. Ngữ cảnh không phải càng dài càng thông minh, sau một độ dài nhất định, độ chính xác tăng hạn chế, nhưng chi phí lại tăng tuyến tính.
Thứ ba, bão retry. Chúng tôi đặt một cơ chế retry thất bại đơn giản, nhưng không làm backoff và circuit breaker. Khi thượng nguồn thỉnh thoảng timeout, cùng một loạt request sẽ bị đánh lên liên tục, thất bại một lần retry một lần, retry lại thất bại lại retry tiếp. Phần gọi API này trên hóa đơn toàn là tiền tiêu vô ích, còn người dùng nhìn thấy vẫn là báo lỗi.
Thứ tư, streaming và non-streaming tính phí trùng. Điều này dễ bị bỏ qua nhất. Một số luồng của chúng tôi để lấy kết quả đầy đủ làm hậu xử lý, gọi non-streaming một lần; frontend lại cần hiệu ứng máy đánh chữ, gọi streaming thêm một lần nữa. Cùng một câu hỏi, hai khoản tiền. Sau đó thống nhất thành nhận streaming, lắp ráp tại local, khoản chi phí trùng lặp này mới được xóa bỏ.
Định tuyến phân tầng triển khai như thế nào
Ý tưởng không phức tạp: phân luồng theo độ khó của tác vụ. Nhận diện ý định, trích xuất slot, mẫu câu cố định thì đi model nhẹ; những cuộc hội thoại phức tạp thực sự cần suy luận, phán đoán nhiều bước, xoa dịu cảm xúc mới giao cho model flagship. Ở giữa thêm một lớp model gateway để phán đoán, request vào trước tiên qua bộ phân loại, gắn nhãn tác vụ rồi mới quyết định định tuyến đến model nào.
Chúng tôi dùng logic tự động chọn model tối ưu theo tác vụ, đã chạy một vòng so sánh trên định tuyến đa model của SiCore TokenWorks, sau khi tác vụ đơn giản chuyển sang model nhẹ, chi phí tổng thể giảm rõ rệt, phản hồi cũng nhanh hơn. Điểm then chốt ở đây không phải "dùng model nào", mà là bảng ánh xạ "tác vụ nào đi với model nào" phải được điều chỉnh liên tục. Giai đoạn đầu ra mắt chúng tôi cấu hình theo kinh nghiệm, sau hai tuần chạy thì hiệu chỉnh lại theo tỷ lệ trúng thực tế, hiệu quả tốt hơn nhiều so với cấu hình đoán mò. Lợi ích của việc tích hợp đa model thống nhất cũng thể hiện lúc này, đổi chiến lược định tuyến không cần sửa code nghiệp vụ, chỉ cần điều chỉnh ở tầng gateway là được.
So sánh hóa đơn trước và sau tối ưu
Không báo con số cụ thể, báo tỷ lệ. Tổng lượng gọi API không đổi, vì lượng người dùng không đổi. Tổng chi phí giảm khoảng sáu mươi phần trăm, trong đó tỷ lệ gọi model flagship từ gần một trăm phần trăm giảm xuống khoảng ba mươi phần trăm, phần còn lại phân luồng sang model nhẹ. Các gọi API liên quan đến retry từ gần hai mươi phần trăm ép xuống mức một chữ số phần trăm. Số token trung bình mỗi lần request giảm khoảng bốn mươi phần trăm, chủ yếu đến từ cắt tỉa ngữ cảnh. Khoản tính phí trùng streaming trực tiếp về không. Tính tổng thể, từ vượt ngân sách gấp ba lần trở về trong ngân sách vẫn còn dư.
Giám sát và cảnh báo cấu hình như thế nào
Số tiền tiết kiệm được phải giữ vững, dựa vào giám sát, không dựa vào tự giác. Chúng tôi cấu hình bốn cảnh báo: số token mỗi lần request vượt ngưỡng thì kích hoạt, phòng ngữ cảnh mất kiểm soát; tỷ lệ retry vượt tỷ lệ đặt trước thì kích hoạt, phòng bão retry; tỷ lệ gọi model flagship tăng cao bất thường thì kích hoạt, nghĩa là định tuyến có thể đã mất hiệu lực; mức tăng chi phí theo ngày so với chu kỳ trước vượt ngưỡng thì kích hoạt. Bốn điều này không cần làm quá phức tạp, tổng hợp theo ngày, vượt đường cảnh báo là đủ dùng. Trong chế độ tính phí Token, chi phí tích lũy theo thời gian thực, đợi đến cuối tháng xem hóa đơn rồi mới tối ưu, tiền đã tiêu ra rồi.
Tóm gọn một câu: phần chi phí lớn của chatbot chăm sóc khách hàng nằm ở cấu trúc gọi API, không nằm ở đơn giá model. Làm chắc bốn việc định tuyến phân tầng, cắt tỉa ngữ cảnh, kiểm soát retry, thống nhất streaming, hóa đơn tự nhiên giảm xuống. Mở rộng thêm một bước, nếu kịch bản của bạn còn có RAG retrieval, số lượng kết quả truy hồi từ vector database cũng đáng được kiểm tra theo cách này một lượt.