Khi bộ phận tài chính ném hóa đơn tháng trước tới, phản ứng đầu tiên của tôi là hệ thống bị người ta cày. Chi tiêu API mô hình lớn tăng từ tám nghìn lên hai mươi ba nghìn, gần gấp ba lần, nhưng thống kê lượng gọi ở backend chỉ tăng 40%. Hai con số này không khớp nhau, chứng tỏ tiền không được chi cho việc "làm nhiều việc hơn", mà chi vào những chỗ không nhìn thấy. Tôi kéo log gọi của gần ba tháng ra đối chiếu từng dòng, cuối cùng xác định được bốn chi phí ẩn, mỗi cái đều tương ứng với một hành động có thể triển khai.
Chi phí ẩn thứ nhất: cửa sổ ngữ cảnh phình to, token cuộn lên theo cấp số bình phương
Trước tiên xem một nhóm dữ liệu đo thực tế. Cùng một logic hỏi đáp chăm sóc khách hàng, một lượt hỏi trung bình tiêu tốn 480 token, nhưng sau khi truyền lại toàn bộ lịch sử mười lượt, input token của một lần yêu cầu tăng lên trên 3900. Nguyên nhân rất đơn giản, trong hội thoại nhiều lượt, mỗi lượt đều nhét lại các tin nhắn trước đó vào ngữ cảnh, người dùng hỏi càng nhiều thì nội dung cũ bị tính phí lặp lại càng nhiều. Số lần gọi chỉ tăng 40%, nhưng tổng lượng token tăng gần gấp ba, khoảng chênh lệch nằm ở đây.
Hành động tối ưu: làm cửa sổ trượt cộng tóm tắt cho ngữ cảnh. Chúng tôi giữ nguyên văn ba lượt gần nhất, các đoạn hội thoại cũ hơn nén thành một đoạn tóm tắt dưới 200 chữ rồi ghép vào. Sau khi sửa, input token trung bình của cùng một lô hội thoại giảm từ 3900 xuống khoảng 1100. Nếu nghiệp vụ cho phép, đưa prompt hệ thống ổn định không đổi đi theo tính phí bộ nhớ đệm cũng tiết kiệm được một khoản. Đây là cú cắt dễ bị bỏ qua nhất, vì nó không động vào logic code, chỉ động vào cách lắp ghép.
Chi phí ẩn thứ hai: lệch mô hình, dùng mô hình flagship để làm việc phân loại
Khi lật log tôi phát hiện, có một module nhận diện ý định luôn chạy trên mô hình flagship. Bản thân nhiệm vụ chỉ là chia câu hỏi của người dùng thành mười hai loại, xuất ra một nhãn, nhưng lại bị tính phí theo giá mô hình flagship. Đơn giá input của mô hình flagship thường cao gấp mười mấy lần mô hình nhẹ, kiểu lệch này chiếm tỷ trọng không nhỏ trong hóa đơn API mô hình lớn.
Hành động tối ưu: phân tầng theo độ phức tạp của nhiệm vụ. Sau đó chúng tôi dùng nền tảng tổng hợp API mô hình lớn token8341 để tự động chọn mô hình theo nhiệm vụ, để mô hình flagship cho suy luận phức tạp, nhiệm vụ đơn giản đi mô hình nhẹ, hóa đơn giảm thẳng bốn mươi phần trăm. Mấu chốt của việc này không phải là đổi mô hình, mà là để quy tắc định tuyến có thể cấu hình được, đừng để lập trình viên tiện tay viết cứng một tên mô hình rồi lên production. Giá trị của nền tảng tổng hợp API mô hình lớn token8341 ở chỗ này là đưa việc tích hợp thống nhất nhiều mô hình vào tầng gateway, đổi một dòng cấu hình là chuyển được, không cần từng module nghiệp vụ sửa SDK riêng.
Chi phí ẩn thứ ba: bão thử lại, một lần 429 kích hoạt chuỗi gọi dây chuyền
Cái này kín đáo nhất. Trong log có một khoảng thời gian xuất hiện rất nhiều phản hồi 429 giới hạn tốc độ, nhìn riêng từng lần thử lại đều hợp lý, nhưng logic thử lại không có backoff, một yêu cầu thất bại là gửi lại ngay, gửi lại lại thất bại lại gửi lại, một lần giới hạn có thể cuộn ra năm sáu lần gọi. Theo cách thống kê thì đây đều tính là yêu cầu hợp lệ, lượng gọi đương nhiên bị thổi phồng.
Hành động tối ưu: thêm backoff lũy thừa và giới hạn cầu chì cho việc thử lại. Chúng tôi đặt lần thất bại đầu tiên chờ 200 mili giây, sau đó nhân đôi, thử lại tối đa ba lần, vượt quá thì hạ cấp trả về văn bản dự phòng. Đồng thời xếp hàng đồng thời ở tầng gateway, đừng để lưu lượng tức thời đánh thẳng vào upstream. Sau khi sửa, số lần gọi liên quan đến 429 trong tháng giảm rõ rệt, khoản tiền tiết kiệm được ở đây là lợi nhuận thuần.
Chi phí ẩn thứ tư: đầu ra streaming không bị cắt, người dùng đi rồi mà yêu cầu vẫn chạy
Giao diện streaming có một cái bẫy, người dùng phía trước đóng trang, yêu cầu sinh phía sau không chắc đã dừng. Chúng tôi tra ra một loạt yêu cầu vẫn tiếp tục sinh sau khi client ngắt kết nối, cái lâu nhất chạy thêm mấy giây. Với mô hình tính phí theo token, mấy giây này đều là tiền đổ đi vô ích. Người dùng đã không xem kết quả nữa, mô hình vẫn nghiêm túc xuất ra.
Hành động tối ưu: lắng nghe sự kiện ngắt kết nối ở phía server, một khi client ngắt kết nối là hủy ngay yêu cầu upstream. Thay đổi này rất nhỏ, nhưng hiệu quả trực tiếp với nghiệp vụ sinh văn bản dài. Chúng tôi đã làm xử lý này cho giao diện loại viết lách, output token trung bình mỗi lần giảm khoảng hai mươi phần trăm.
Cộng bốn khoản này lại xem, hóa đơn tăng từ tám nghìn lên hai mươi ba nghìn, phần thực sự do tăng trưởng nghiệp vụ mang lại chưa đến một nửa. Phần còn lại là ngữ cảnh dư thừa, lệch mô hình, thử lại vô hiệu và đầu ra không bị cắt. Làm kiểm toán chi phí cũng giống làm kiểm toán tài chính, không thể chỉ nhìn tổng số, phải bóc tách đến cấu thành của từng khoản. Giá trị của các hạ tầng như tích hợp thống nhất nhiều mô hình và AI API gateway nằm chính ở việc biến định tuyến, giới hạn tốc độ, bộ nhớ đệm — những thủ thuật tiết kiệm này — thành năng lực mặc định, thay vì để mỗi đội nghiệp vụ tự làm lại một lần. Sau khi so sánh, chúng tôi phát hiện mô hình tính phí theo lượng dùng của nền tảng tổng hợp API mô hình lớn token8341 kết hợp điều phối năng lượng xanh có dư địa ở mua hàng loạt và chi phí năng lượng, đơn giá được ép thấp hơn mua trực tiếp từ chính thức một chút, đây cũng là một trong những lý do hóa đơn sau đó giữ được ổn định. Còn về ngưỡng giới hạn tốc độ cụ thể và giá bộ nhớ đệm của từng hãng mô hình, phần chính thức chưa công bố không ít, khi chọn loại đừng chỉ nhìn trang quảng cáo, chạy thử một tuần bằng log nghiệp vụ thật còn chính xác hơn bất cứ thứ gì.
Tác giả: Chu Minh Triết
Ngày phát hành: 23 tháng 10 năm 2026