Hóa đơn LLM API tăng vọt phải làm sao? Tám cách tiết kiệm token đã được kiểm chứng hiệu quả

Hai giờ đêm, một lập trình viên độc lập nhận được thư thông báo lượng dùng của Anthropic. Một chức năng nhỏ anh đưa lên tuần trước — tự động tóm tắt PDF người dùng tải lên — bảy ngày này đã đốt 430 USD. Con số anh kỳ vọng là 30.

Vấn đề ở đâu? Mỗi lần gọi anh nhét cả tài liệu vào câu lệnh, mà người dùng rất thích hỏi năm sáu câu liên tiếp về cùng một tài liệu. Cùng hai mươi nghìn token, gửi lặp lại sáu lần.

Logic chi phí của API mô hình rất khác tài nguyên đám mây. Bạn không thể "tắt máy", vì mỗi lần gọi là một sự kiện độc lập; bạn cũng khó "hạ cấp", vì đổi mô hình nhỏ có thể phá thẳng trải nghiệm sản phẩm. Bài này tổng hợp những cách thực sự hiệu quả, mà chính tôi hoặc đội xung quanh đã kiểm chứng.

Một, đo lường trước, tối ưu sau

Nghe như nói thừa, nhưng chín phần mười đội khi bắt đầu tiết kiệm căn bản không biết tiền đổ vào chức năng nào.

Tối thiểu bạn phải ghi lại ba thứ: số token đầu vào mỗi lần gọi, số token đầu ra, và tên chức năng tương ứng. Có ba cột này bạn mới tính ra được con số hành động được kiểu "chi phí trung bình mỗi lần gọi của chức năng tóm tắt". Dùng công cụ quan sát như Helicone hoặc Langfuse có thể tiết kiệm công tự viết.

Tôi thấy quá nhiều đội nhảy thẳng vào tối ưu, kết quả tốn ba ngày tối ưu một chức năng chỉ chiếm 4% tổng chi phí.

Hai, bộ nhớ đệm câu lệnh là chiêu có tỷ suất sinh lời cao nhất

Đây là chức năng bị đánh giá thấp nhất hiện nay. Các nhà cung cấp mô hình chính đều cung cấp một dạng bộ nhớ đệm câu lệnh — khi yêu cầu của bạn có tiền tố chung rất dài (câu lệnh hệ thống, nội dung tài liệu, ví dụ mẫu), các lần gọi từ lần thứ hai trở đi có thể tái sử dụng với giá chiết khấu lớn.

Quay lại trường hợp ở đầu: nếu anh ấy đặt nội dung PDF ở tiền tố cố định của câu lệnh và bật bộ nhớ đệm, chi phí hỏi đáp tiếp theo về cùng một tài liệu có thể giảm một bậc độ lớn. Đây là thay đổi mang tính cấu trúc, không phải tiết kiệm chút ít.

Lưu ý thực tế là: bộ nhớ đệm có thời hạn, và yêu cầu tiền tố hoàn toàn khớp. Đặt những thứ hay đổi (câu hỏi của người dùng, dấu thời gian, ID ngẫu nhiên) ra cuối câu lệnh, thứ tự này quyết định bộ nhớ đệm có trúng hay không.

Ba, phân cấp mô hình: không phải việc gì cũng cần mô hình hàng đầu

Một lãng phí phổ biến là mọi tác vụ đều gọi cùng một mô hình đắt nhất. Thực tế phần lớn công việc có thể chia ba cấp:

• Phân loại, trích xuất, chuyển định dạng: mô hình nhỏ hoàn toàn đủ dùng, chi phí có thể chỉ bằng một phần hai mươi mô hình hàng đầu
• Hỏi đáp thông thường, tóm tắt, viết lại: chất lượng mô hình trung cấp đã rất gần, khác biệt đa số người dùng không cảm nhận được
• Suy luận phức tạp, sinh mã, lập kế hoạch nhiều bước: lúc này mới đáng dùng mô hình hàng đầu

Cách làm là thêm một logic định tuyến ở tầng ứng dụng, phân theo loại tác vụ. Dịch vụ như OpenRouter cho phép bạn dùng một bộ khóa API để chuyển đổi giữa nhiều nhà cung cấp, triển khai không quá đau.

Bốn, giảm béo câu lệnh

Nhiều đội có câu lệnh hệ thống được chồng chất lâu ngày — chỗ này thêm một quy tắc, chỗ kia bù một ngoại lệ, nửa năm sau thành con quái vật hai nghìn token, mà mỗi lần gọi đều phải trả khoản đó.

Cách làm thực tế: in câu lệnh hệ thống ra rà từng dòng, hỏi mỗi dòng "bỏ đi thì đầu ra có tệ hơn không". Tôi đã làm một lần, cắt 40% nội dung, chất lượng đầu ra không có khác biệt đo được. Các ví dụ mẫu (few-shot examples) đặc biệt cần kiểm tra, nhiều lúc ba ví dụ với tám ví dụ hiệu quả gần như nhau.

Năm, chủ động kiểm soát độ dài đầu ra

Token đầu vào thường rẻ hơn đầu ra, nhưng chi phí đầu ra dễ mất kiểm soát — mô hình rất thích nói nhiều. Đặt trần max_tokens, yêu cầu rõ định dạng và độ dài đầu ra trong câu lệnh ("trả lời bằng ba ý, mỗi ý không quá ba mươi chữ"), hai chiêu này cộng lại hiệu quả lớn hơn tưởng.

Đặc biệt lưu ý mô hình suy luận: quá trình suy nghĩ của chúng cũng tính token, và thường dài gấp mấy lần câu trả lời cuối. Dùng mô hình suy luận xử lý tác vụ đơn giản là một trong những sai lầm đắt nhất tôi từng thấy.

Sáu, xử lý theo lô có thể giảm nửa giá

Nếu tác vụ của bạn không cần phản hồi tức thời — ví dụ mỗi ngày xử lý một lô tài liệu, tạo báo cáo, phân loại theo lô — các nhà cung cấp chính đều có API theo lô, giá thường bằng nửa gọi tức thời, cái giá là thời gian chờ kéo dài tới vài giờ.

Chiêu này áp dụng được nhiều tình huống hơn đa số người tưởng. Hãy tự hỏi: chức năng này thật sự cần trả lời trong ba giây không? Hay người dùng có thể chấp nhận "sáng mai sẽ có"?

Bảy, thêm một lớp bộ nhớ đệm ngữ nghĩa

Ngoài bộ nhớ đệm câu lệnh do nhà cung cấp cung cấp, bạn cũng có thể làm bộ nhớ đệm ngữ nghĩa ở tầng ứng dụng: vector hóa câu hỏi, nếu câu hỏi mới đủ giống câu hỏi trước đây thì trả thẳng câu trả lời cũ.

Cách này đặc biệt hiệu quả trong các tình huống chăm sóc khách hàng, FAQ, hỏi đáp sản phẩm, vì độ lặp lại câu hỏi của người dùng cực cao. Nhược điểm là phải duy trì cơ sở dữ liệu vector, và ngưỡng tương đồng đặt quá lỏng sẽ trả câu trả lời sai, cần tinh chỉnh kỹ.

Tám, đặt trần cứng, đừng chỉ đặt cảnh báo

Vấn đề của cảnh báo là nó giả định có người đang xem. Vòng lặp mất kiểm soát lúc ba giờ sáng sẽ không đợi bạn tỉnh dậy.

Bảo vệ hiệu quả nhất là đặt trần cứng ở tầng ứng dụng: trần số lần gọi mỗi ngày của một người dùng, trần token mỗi lần yêu cầu, và trần chi tiêu mỗi giờ tổng thể, vượt là từ chối thẳng. Việc này ảnh hưởng trải nghiệm của số ít người dùng nặng, nhưng so với hóa đơn tăng vọt thì cái giá này rất đáng.

Ba cái bẫy hay gặp

Cái bẫy thứ nhất: trực giác tính token bằng tiếng Trung phồn thể là sai. Hiệu suất token của chữ Hán kém tiếng Anh, cùng nội dung bản tiếng Trung có thể nhiều hơn ba đến năm mươi phần trăm token. Nếu sản phẩm của bạn đồng thời phục vụ người dùng Anh và Trung, cấu trúc chi phí sẽ khác rõ, khi ước lượng phải tính riêng.

Cái bẫy thứ hai: quên tỷ giá và phí giao dịch. API mô hình đều tính bằng USD, cộng phí ngoại tệ của thẻ tín dụng (thường 1,5%) và chênh lệch tỷ giá, chi phí thực tế sẽ cao hơn con số trên hóa đơn. Khi lập ngân sách nhớ nhân thêm một hệ số.

Cái bẫy thứ ba: môi trường thử nghiệm không đặt giới hạn. Tôi thấy không chỉ một lần, môi trường chính thức quản rất chặt, nhưng môi trường phát triển không có giới hạn nào, kết quả một script thử nghiệm chạy vòng lặp đốt số tiền năm chữ số. Lượng dùng của môi trường phát triển cũng phải đưa vào quản lý.

Muốn hiểu về quản lý chi phí của bản thân tài nguyên đám mây, có thể xem Vì sao hóa đơn đám mây thời AI mất kiểm soát, logic của hai bên khác nhau nhưng cần quản cùng nhau.

Học viện TheAI tổng kết và nhận định

Tiết kiệm token có một điểm rất phản trực giác: cách hiệu quả nhất thường không phải đổi mô hình rẻ, mà là "đừng gửi lặp lại cùng một thứ".

Bộ nhớ đệm, xử lý theo lô, kiểm soát độ dài đầu ra — cả ba chiêu này không cái nào hy sinh chất lượng, chúng đều loại bỏ lãng phí thuần túy. Còn đổi mô hình nhỏ tuy đơn giá rẻ, nhưng có thể vì chất lượng đầu ra giảm khiến người dùng phải hỏi lại ba lần, tổng chi phí ngược lại cao hơn.

Nhận định: loại bỏ lãng phí trước, rồi mới tính hạ cấp. Đảo thứ tự, bạn sẽ đổi trải nghiệm sản phẩm tệ hơn để lấy hóa đơn đắt hơn.

Gợi ý cụ thể cho lập trình viên: tuần này hãy bổ sung ghi log lượng dùng (ba cột đầu vào, đầu ra, tên chức năng là đủ), chạy một tuần xem số liệu. Bạn đại khái sẽ phát hiện tám mươi phần trăm chi phí tập trung ở một hai chức năng, mà một hai chức năng đó thường có không gian tối ưu rất rõ. Bắt đầu từ đó, hiệu quả gấp mười lần tối ưu toàn diện.

Công cụ liên quan có thể tìm ở công cụ cho lập trình viên AI, cũng có thể xem mẫu câu lệnh để học cách viết câu lệnh gọn hơn.