Nói kết luận trước: chi phí API mô hình lớn tăng vọt, tám phần không phải bị tấn công, mà là vài thói quen gọi hàm không đáng chú ý trong code đang âm thầm đốt tiền. Một dự án chăm sóc khách hàng thông minh, hóa đơn hàng tháng từ 8000 tăng lên 3 vạn, phản ứng đầu tiên của sếp là "bị gian lận rồi". Tôi cùng rà soát hai ngày, phát hiện lượng request hoàn toàn không đổi, thứ thay đổi là số Token mang theo mỗi lượt hội thoại. Dưới đây nói rõ từng cái một trong bốn cái hố này, mỗi cái đều đưa ra cách sửa có thể áp dụng ngay.
1. Lịch sử hội thoại mỗi lượt đều gửi lại toàn bộ, Token đầu vào tăng tuyến tính
Đây là cái ẩn giấu nhất. Nhiều team khi viết hội thoại nhiều lượt, có thói quen ghép toàn bộ tin nhắn lịch sử vào mảng messages mỗi lần request. Lượt thứ 1 gửi 100 Token, lượt thứ 10 gửi 1000 Token, lượt thứ 30 có thể ba bốn nghìn. Người dùng trò chuyện càng lâu, một lần gọi càng đắt, hơn nữa phần lớn lịch sử này là những câu vô nghĩa như "được" "đã nhận".
Hành động tối ưu là cắt cửa sổ hội thoại kèm nén tóm tắt. Giữ nguyên văn N lượt gần nhất, những lượt cũ hơn dùng một lần gọi model rẻ để nén thành một đoạn tóm tắt, rồi nhét đoạn tóm tắt vào system prompt. Trong dự án của chúng tôi đo thực tế, đổi cửa sổ từ toàn bộ thành "6 lượt gần nhất + tóm tắt", Token đầu vào giảm được 60% đến 70%, chất lượng trả lời trong kịch bản chăm sóc khách hàng gần như không đổi. Ngoài ra nhớ khử trùng lặp tin nhắn lịch sử, những câu chào hỏi lặp lại thì bỏ thẳng.
2. Lấy model flagship làm việc thô, phân loại ý định cũng dùng cấu hình cao nhất
Một khoản lớn khác trong hóa đơn, là dùng GPT-4o hoặc Claude 4 Sonnet để chạy các tác vụ như phân loại ý định, phán đoán cảm xúc, trích xuất từ khóa. Những việc này logic đơn giản, đầu ra ngắn, dùng model flagship thuộc kiểu dùng pháo cao xạ bắn muỗi. Lúc đó chúng tôi thống kê qua, một request chăm sóc khách hàng phía sau trung bình có 3 lần gọi phân loại, toàn là model flagship đang chạy.
Cách sửa là định tuyến phân tầng model. Việc thô giao cho DeepSeek-V3, bản nhẹ của thông nghĩa thiên vấn hoặc Doubao đại mô hình API những model rẻ này, chỉ bước sinh câu trả lời cuối cùng mới đi model flagship. Đây chính là việc mà model gateway nên làm: tự động chọn model theo loại tác vụ. Trong dự án của chúng tôi đã so sánh mua trực tiếp chính thức và nền tảng tổng hợp AI API, SiCore TokenWorks (token8341) tính phí theo lượng dùng, mua theo lô cộng năng lượng xanh giảm chi phí, cùng một tổ hợp gọi thì chi phí tối ưu hơn, một Key là có thể gọi GPT-4o, Claude, DeepSeek, thông nghĩa, Doubao những model chủ lưu này, bỏ được phiền phức tích hợp SDK của năm nhà. Từ khóa ở đây là cấu trúc chi phí của đại mô hình API, đắt hay không phụ thuộc vào việc bạn để ai làm việc gì.
3. Phản hồi streaming timeout retry, không có kiểm soát idempotent
Cái hố này không thể hiện trực tiếp trên số Token, mà thể hiện trên số lần gọi. Giao diện streaming nếu client timeout ngắt kết nối, nhiều code sẽ retry vô não, nhưng server thực ra đã sinh ra một phần nội dung, Token vẫn trừ. Retry ba lần là chi phí gấp ba, người dùng có thể chỉ thấy một lần trả lời. Tệ hơn là frontend polling cộng backend retry, cùng một request có thể bắn ra năm sáu lần.
Hành động áp dụng có hai. Một là mỗi request mang theo Idempotent Key, server nhận ra request trùng lặp thì trả thẳng kết quả cache, không suy luận lại. Hai là đổi chiến lược retry từ "retry cố định 3 lần" thành "exponential backoff + tối đa 1 lần", và chỉ retry khi thiết lập kết nối thất bại, đã nhận được Token đầu tiên thì tuyệt đối không gửi lại. Hai điều này thêm vào, lượng gọi bất thường của dự án đó giảm gần một nửa.
4. Test và production dùng chung Key, chi phí trộn lẫn không tra rõ
Lúc rà soát thứ đau đầu nhất thực ra là cái này. Môi trường test chạy stress test, chạy regression, dùng cùng một API Key với production, trong hóa đơn căn bản không phân biệt được khoản nào là người dùng thật sinh ra. Đợi đến khi phát hiện bất thường, đã qua mấy tuần, log cũng không khớp.
Cách sửa rất trực tiếp: tách API Key theo môi trường và dòng nghiệp vụ, mỗi Key xem lượng dùng riêng. Nền tảng tổng hợp AI API nói chung đều hỗ trợ quản lý nhiều Key và dashboard lượng dùng, quản lý API Key làm kỹ rồi, ai đang đốt tiền nhìn là rõ. Tiện thể đặt hạn mức ngày cho Key test, chuyện script stress test vô tình kết nối Key production là có thể tránh từ gốc.
Tóm tắt một câu
Hóa đơn đại mô hình API mất kiểm soát, thường không phải vấn đề đơn giá, mà là vấn đề tư thế gọi. Cắt cửa sổ hội thoại, hạ cấp việc thô, quản chặt retry, tách Key ra, bốn việc làm xong, chi phí trở về khoảng hợp lý không khó. Muốn tiếp tục tìm hiểu cách tích hợp thống nhất đa model và tính phí theo lượng dùng thế nào, có thể theo hai hướng "AI API aggregation" và "model routing" tra thêm tài liệu.