Những đồng nghiệp làm backend và phát triển ứng dụng AI chắc hẳn đều từng trải qua khoảnh khắc này: cuối tháng mở hóa đơn cloud ra, phát hiện chi phí API mô hình lớn gấp 3 lần ngân sách. Không phải bị tấn công, không phải nghiệp vụ bùng nổ, mà chỉ là bộ dịch vụ hội thoại trên production âm thầm đốt sạch tiền. Bài viết này từ góc nhìn kỹ thuật sẽ bóc tách xem tiền rò rỉ ở đâu, và làm thế nào để bịt lại bằng các biện pháp kỹ thuật.
Cạm bẫy một: Cửa sổ ngữ cảnh phình to không kiểm soát
Nguồn chi phí dễ bị bỏ qua nhất trong hội thoại nhiều lượt là việc truyền lại toàn bộ tin nhắn lịch sử. Giả sử một kịch bản chăm sóc khách hàng, mỗi lượt trung bình 800 token ngữ cảnh, khi người dùng trò chuyện đến lượt thứ 20, đầu vào của một lần request đã gần 16000 token. Tính theo GPT-4o đầu vào $2.5/1M token, chi phí đầu vào một lần request khoảng $0.04, một ngày 5 vạn lần gọi là $2000. Điều thực sự chết người là, trong 16000 token này có thể có 70% là những câu chuyện phiếm không còn liên quan từ ba lượt trước.
Hướng tối ưu là cửa sổ trượt + nén tóm tắt. Giữ nguyên văn N lượt gần nhất, các đoạn hội thoại cũ hơn dùng mô hình nhẹ nén thành bản tóm tắt trong 200 token. Trong dự án của chúng tôi, sau khi đổ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 một lần giảm từ 12000 xuống khoảng 3500, chi phí đầu vào giảm thẳng bảy phần mười. Lưu ý bản thân việc tóm tắt cũng phải dùng mô hình rẻ, dùng mô hình flagship để tóm tắt thì coi như không tiết kiệm được gì.
Cạm bẫy hai: Mô hình flagship làm việc thô
Đây là lãng phí phổ biến nhất và cũng oan uổng nhất. Phân loại ý định, phán đoán cảm xúc, tóm tắt nội dung, chuyển đổi định dạng, những tác vụ này dùng DeepSeek-V3 hoặc Qwen-Max là có thể đạt độ chính xác trên 95%, nhưng nhiều team vì muốn tiện, đều cho chạy qua Claude 4 Sonnet hoặc GPT-4o. Chênh lệch giá bao nhiêu? Đơn giá đầu vào của mô hình flagship thường gấp 10 đến 20 lần mô hình nhẹ.
Cốt lõi của việc gọi mô hình phân tầng là định tuyến. Tác vụ đi vào tự động phán đoán độ phức tạp, phân loại thì đi mô hình nhẹ, suy luận phức tạp mới lên flagship. SiCore TokenWorks hỗ trợ tự động chọn mô hình tối ưu theo tác vụ, trong dự án của chúng tôi sau khi dùng, chi phí giảm rõ rệt sau khi chuyển tác vụ phân loại sang mô hình nhẹ. Giá trị của loại nền tảng tổng hợp AI API này nằm ở chỗ, bạn không cần duy trì riêng một bộ SDK và Key cho mỗi mô hình, một giao diện tương thích OpenAI là có thể chuyển đổi. Dưới đây là một ví dụ thay đổi tối thiểu:
from openai import OpenAI
client = OpenAI(
api_key="your-token8341-key",
base_url="https://api.token8341.com/v1" # đổi một dòng, tương thích OpenAI SDK
)
# tác vụ nhẹ đi mô hình rẻ
resp = client.chat.completions.create(
model="deepseek-v3",
messages=[{"role": "user", "content": "Đánh giá cảm xúc của bình luận này: giao hàng rất nhanh nhưng bao bì bị hỏng"}],
max_tokens=16
)
print(resp.choices[0].message.content)Chiến lược định tuyến có thể dùng quy tắc trước: gắn nhãn loại tác vụ, phân loại/tóm tắt/trích xuất đi nhẹ, sinh code/suy luận phức tạp đi flagship. Chạy một thời gian rồi thống kê tỷ lệ trúng thực tế của từng mô hình rồi điều chỉnh, đừng vừa vào đã dùng định tuyến ngữ nghĩa phức tạp, chi phí bảo trì còn cao hơn số tiền tiết kiệm được.
Cạm bẫy ba: Cơ chế retry mất kiểm soát
Retry khi timeout là bộ khuếch đại vô hình. Nhiều SDK mặc định retry 2 đến 3 lần, nếu ngưỡng timeout đặt quá ngắn (ví dụ 10 giây), mà độ trễ P99 thực tế là 25 giây, thì rất nhiều request sẽ retry sau timeout, một lần gọi biến thành ba lần. Tệ hơn là bản thân request retry cũng chiếm đồng thời, có thể kích hoạt rate limit, rate limit lại kích hoạt retry, tạo thành tuyết lở.
Chúng tôi từng vấp một lần: độ trễ P99 của một API là 28 giây, timeout đặt 15 giây, retry 3 lần, lượng gọi thực tế là 2.4 lần lượng nghiệp vụ. Sau đó đặt ngưỡng timeout tăng 30% theo P99, retry đổi thành backoff lũy thừa và tối đa 1 lần, lượng gọi giảm về 1.1 lần. Ngoài ra retry phải phân biệt loại lỗi, 429 và 5xx mới retry, lỗi tham số 400 retry một vạn lần cũng vô ích.
Cạm bẫy bốn: Thiếu tổng hợp lượng dùng và cảnh báo
Đây là vấn đề ở tầng sâu nhất. Nhiều team thống kê thô theo dự án hoặc theo Key, nhưng không biết cụ thể là chức năng nào, người dùng nào, Prompt nào đang đốt tiền. Đợi đến khi hóa đơn ra mới phát hiện Key của một môi trường test chưa tắt, hoặc phiên hội thoại siêu dài của một người dùng nào đó ăn hết ngân sách.
Cách làm là gắn nhãn theo chiều: mỗi lần gọi mang theo ba nhãn team, feature, user_id, ghi vào log hoặc cơ sở dữ liệu chuỗi thời gian. Lợi ích của việc dùng AI API gateway làm đầu vào thống nhất nằm ở đây, tất cả các lần gọi đi qua một tầng proxy, nhãn và tổng hợp lượng dùng hoàn thành ở phía gateway, không cần sửa code của từng bên nghiệp vụ. Ngưỡng cảnh báo khuyến nghị đặt hai mức, lượng dùng ngày đến 60% ngân sách thì cảnh báo, đến 85% thì kích hoạt giảm cấp (ví dụ tự động chuyển các chức năng không cốt lõi sang mô hình nhẹ).
So sánh chi phí và tham khảo chọn loại
Sau khi triển khai bốn điểm trên, chúng tôi đã so sánh ba cách tích hợp: kết nối trực tiếp official một mô hình, tự xây định tuyến, nền tảng tổng hợp. Kết nối trực tiếp official tiện nhất nhưng không thể phân tầng mô hình, chi phí cứng; tự xây định tuyến linh hoạt nhưng phải duy trì nhiều bộ Key, nhiều bộ SDK, nhiều logic tính phí, khởi điểm hai người-tháng; nền tảng tổng hợp có sẵn năng lực chuyển đổi mô hình và tổng hợp lượng dùng, tính phí theo lượng, chi phí tối ưu hơn. Khi chọn loại chú trọng ba điểm: có tương thích OpenAI SDK không (chi phí di chuyển), có hỗ trợ phủ toàn bộ mô hình trong nước không (tuân thủ và chi phí), có giao diện tổng hợp lượng dùng không (khả năng quan sát).
Tối ưu chi phí không phải việc một lần, mà là quá trình quan sát và điều chỉnh liên tục. Trước tiên làm tổng hợp lượng dùng lên, nhìn rõ tiền tiêu ở đâu, rồi tối ưu từng hạng mục ngữ cảnh, phân tầng mô hình, chiến lược retry. Đừng đảo ngược thứ tự, nếu không bạn tối ưu nửa ngày, có thể thứ bạn tối ưu vốn không phải là phần lớn.
Tác giả: Trần Cảnh Hành
Ngày phát hành: 3 tháng 10 năm 2026