Chi phí AI cho SME: model rẻ chưa chắc vận hành đã rẻ

TL;DR: Chi phí AI cho SME phải được tính trên một tác vụ đạt chuẩn, gồm cả những lần chạy lại và công sửa của con người. Giá token thấp là lý do để thử nghiệm, chưa phải bằng chứng hệ thống vận hành rẻ hơn.

Một model vừa giảm giá thường khiến câu hỏi “có nên đổi không?” xuất hiện rất nhanh. Nhưng nếu doanh nghiệp đang dùng AI để xử lý hồ sơ, soạn nội dung hoặc phân loại yêu cầu, hóa đơn API chỉ phản ánh một đoạn của công việc. Phần còn lại nằm ở người kiểm tra, những lần chạy lại và kết quả bị loại. Tôi muốn đặt quyết định này trở lại đúng bài toán: doanh nghiệp trả bao nhiêu để nhận được một đầu ra sử dụng được? Khung tính chi phí và ROI của AI là điểm khởi đầu; bài này đi sâu vào quyết định đổi model trong một workflow đang có.

Model rẻ có làm tổng chi phí AI cho SME giảm không?

Model rẻ chỉ làm tổng chi phí giảm nếu phần tiết kiệm không bị công sửa, retry và kết quả lỗi hấp thụ. Muốn biết điều đó, cần giữ nguyên tiêu chuẩn nghiệm thu khi so sánh.

Ngày 10/09/2026, changelog chính thức của DeepSeek thông báo V4.1 Flash và việc tạm chuyển các model ID V4 Flash cũ sang phiên bản mới. Chi tiết này cho thấy một vấn đề ít được chú ý: tên cấu hình không luôn chứng minh phiên bản thực sự đang phục vụ yêu cầu.

Trước khi thử một model khác, tôi sẽ ghi lại model ID, ngày chạy và chính sách giá áp dụng. Nếu bỏ bước này, một so sánh có thể vô tình đo hai phiên bản khác với những gì người thực hiện tưởng mình đang dùng.

Tuy nhiên, thông báo giảm giá không trả lời được một câu hỏi nghiệp vụ: đầu ra có còn đạt chuẩn của doanh nghiệp không? Một bản nháp tốn ít token nhưng phải viết lại vẫn tiêu tốn thời gian. Một yêu cầu được phân loại nhanh nhưng chuyển sai người nhận vẫn tạo thêm công việc ở phía sau.

Những chi phí nào thường biến mất khỏi bảng tính?

Chi phí thường bị bỏ sót là công kiểm tra, xử lý ngoại lệ và duy trì tích hợp. Các khoản này cần được ghi cùng chi phí API thay vì nằm trong trí nhớ của người vận hành.

Tôi ưu tiên bảng này hơn một bảng so sánh giá model vì nó buộc người quyết định nhìn toàn bộ vòng đời tác vụ. Chẳng hạn, bản nháp đã được tạo nhưng bị người biên tập từ chối phải nằm trong chi phí của hệ thống. Nó không được biến mất chỉ vì chưa đi đến bước xuất bản.

Đặc biệt, cần tách hai câu hỏi: một lần chuyển đổi tốn bao nhiêu và vận hành sau chuyển đổi tốn bao nhiêu. Trộn chúng có thể khiến model mới trông quá đắt ở tuần đầu hoặc quá rẻ khi bỏ qua công tích hợp.

So sánh hai model thế nào để kết quả có ý nghĩa?

Hãy cho hai cấu hình xử lý cùng tập tác vụ và áp dụng cùng tiêu chí đầu ra. Ghi kết quả từng lần thử, không chỉ giữ những lần chạy đẹp nhất.

Tôi đề xuất chọn dữ liệu thuộc phạm vi doanh nghiệp được phép sử dụng, gồm cả yêu cầu bình thường và ngoại lệ thường gặp. Đầu ra được chấm theo mục đích thật: bản nháp dùng được, dữ liệu đúng schema, hoặc yêu cầu đến đúng người phụ trách.

Một cách tính cần thống nhất trước khi chạy là:

Chi phí mỗi tác vụ đạt chuẩn =
(API của mọi lần thử + công kiểm tra/sửa + hạ tầng phân bổ)
/ số tác vụ được nghiệm thu

Đây là công thức đo, không phải kết quả tiết kiệm đã được chứng minh. Nếu không có tác vụ nào đạt chuẩn, cấu hình đó chưa đủ điều kiện để so sánh bằng chi phí bình quân.

Ngoài chi phí, hãy giữ các điều kiện không được đánh đổi: phạm vi dữ liệu, thời gian phản hồi chấp nhận được và những lỗi nghiệp vụ không được phép xảy ra. Một phương án rẻ hơn nhưng vi phạm các điều kiện này cần bị loại trước khi xếp hạng.

Khi nào nên giữ, đổi hoặc phân tuyến model?

Giữ model khi chưa có bằng chứng thay đổi mang lại lợi ích. Đổi khi cấu hình mới đạt cùng chuẩn với tổng chi phí thấp hơn; phân tuyến chỉ khi nhóm tác vụ khác nhau có tiêu chí và cơ chế kiểm soát rõ.

Tôi không muốn một lớp định tuyến trở thành tính năng mới chỉ vì nghe có vẻ tiết kiệm. Nó cũng có chi phí bảo trì, phân loại sai và kiểm tra. Trước khi bổ sung, người vận hành phải giải thích được tác vụ nào đi qua tuyến nào và điều gì xảy ra khi quyết định phân tuyến sai.

Một phiếu quyết định ngắn có thể gồm:

• Phạm vi tác vụ và phiên bản đang so sánh.
• Tiêu chuẩn nghiệm thu và các lỗi buộc dừng.
• Chi phí ghi nhận cùng phương pháp phân bổ.
• Điều kiện quay lại cấu hình cũ.

Nếu các ô này còn trống, quyết định hợp lý là tiếp tục đo. Không cần biến một lần thử thành lời hứa “giảm chi phí” để biện minh cho việc thử nghiệm.

Kết luận

Giá model là tín hiệu thị trường hữu ích, nhưng quyết định vận hành thuộc về dữ liệu của doanh nghiệp. Tôi sẽ chọn phương án có thể giải thích được chi phí và chất lượng trên cùng một tác vụ, thay vì phương án có đơn giá hấp dẫn nhất.

Nếu doanh nghiệp chưa xác định được tác vụ và tiêu chí nghiệm thu, hãy bắt đầu từ kiểm tra mức độ sẵn sàng ứng dụng AI. Bạn đang tối ưu một kết quả sử dụng được, hay chỉ đang tối ưu một dòng hóa đơn?