Giải thích hoá đơn LLM cho CFO: tính chi phí trên mỗi kết quả, đừng dừng ở chi phí mỗi lần gọi

Thử hình dung: bản pilot đã chạy ổn được ba tuần. Rồi một email đến từ phòng tài chính của khách hàng: “Hoá đơn tháng này là bao nhiêu, tháng sau là bao nhiêu, và mỗi hồ sơ xử lý xong tốn của chúng tôi bao nhiêu tiền?” Người phải trả lời không phải account manager.

Người đó là bạn, vì chỉ bạn biết hệ thống gọi model bao nhiêu lần và gọi để làm gì.

Đây là lúc nhiều FDE lỡ một cơ hội lớn. Họ gửi lại tổng số token, hoặc tệ hơn, gửi bảng giá công khai của nhà cung cấp. CFO cần ba thứ khác: chi phí trên mỗi kết quả, một dự báo, và biên sai số của dự báo đó.

Kỹ năng này thuộc phần đo lường giá trị của nghề FDE. Nếu làm tốt, bạn biến một dòng chi phí khó hiểu thành unit economics mà ban giám đốc ra quyết định được. Muốn gia hạn hợp đồng hay mở rộng deployment, thường bạn phải đi qua đúng cuộc trò chuyện này.

Nó cũng đáng một dòng trong CV: “dựng mô hình chi phí trên mỗi kết quả, đối chiếu dự báo và thực chi hằng tháng với phòng tài chính của khách” nặng ký hơn nhiều so với “tối ưu token”.

Vì sao hoá đơn LLM làm CFO khó chịu?

CFO đã quen đọc hoá đơn cloud. Microsoft, khi viết về quản lý chi phí Azure OpenAI, chỉ ra khác biệt cốt lõi: dịch vụ cloud truyền thống tính theo giờ máy hoặc theo GB lưu trữ, còn LLM tính theo lượng token đã dùng. Một giờ máy thì dễ hình dung. Một triệu token thì CFO không có cách nào gắn với công việc của công ty.

Khó hơn nữa, số token cho cùng một việc không cố định. Microsoft cũng lưu ý rằng mức dùng đột biến làm việc dự báo khó hơn.

Với model suy luận, tài liệu của OpenAI cho biết token suy luận không hiện ra qua API nhưng vẫn bị tính tiền, và có trường hợp bạn trả tiền input và token suy luận mà không nhận được câu trả lời nào hiển thị.

Vì thế đừng bắt CFO học về token. Việc của bạn là quy token về đơn vị họ đã hiểu: một hồ sơ xử lý xong, một ticket đóng được, một hợp đồng đã rà soát.

Chia cho lần gọi hay chia cho việc làm xong?

Finout, một công ty làm công cụ FinOps, tách bạch hai chỉ số. Chi phí mỗi lần gọi (cost per inference) là tổng chi tiêu AI chia cho số lần gọi model.

Chi phí trên mỗi kết quả lấy chi phí AI đã phân bổ chia cho số kết quả. Chỉ số đầu tính lần gọi hỏng ngang với lần gọi làm xong việc, còn chỉ số sau chỉ đếm những việc thực sự xong. Việc hỏng vẫn tiêu tiền, nên tiền của nó nằm trong tử số; nó chỉ không được đếm ở mẫu số.

Để có tử số, CloudNuro, một nhà cung cấp công cụ quản lý chi phí, đưa ra công thức cho mỗi giao dịch: lấy số token mỗi lần gọi nhân giá token, cộng với số lần gọi mỗi giao dịch nhân phí mỗi lần gọi.

Trên nền công thức này, bạn thêm hai lớp mà hoá đơn không cho thấy: thử lại và thất bại. CloudNuro khuyên theo dõi riêng tỷ lệ thành công, thất bại và thử lại. Lần gọi nào bị thử lại cũng làm chi phí mỗi kết quả tăng lên.

Tính trọn một hồ sơ bồi thường, từ token đến cent

Thử hình dung một agent phân loại hồ sơ bồi thường bảo hiểm. Mỗi hồ sơ cần 3 lần gọi: trích xuất, phân loại, soạn phản hồi.

Mỗi lần gọi có 6.000 token input, trong đó 5.000 token là system prompt và hướng dẫn lặp lại có thể cache, và 800 token output.

Các giá dưới đây là giả định để dễ tính: input 3 USD mỗi triệu token, output 15 USD mỗi triệu token.

Tài liệu prompt caching của Anthropic cho hai hệ số cần biết. Đọc từ cache tính 0,1 lần giá input cơ bản (một số model có ngoại lệ). Ghi cache với TTL 5 phút tính 1,25 lần, và 2 lần nếu dùng TTL 1 giờ.

Theo giá giả định, một lần gọi không cache tốn 0,030 USD. Một lần cache hit tốn 0,0165 USD. Một lần phải ghi cache tốn 0,03375 USD, tức là đắt hơn cả lần gọi không cache.

Giả sử một tháng có 10.000 hồ sơ, 10% lần gọi phải thử lại, 90% lần gọi trúng cache. Tổng cộng có 33.000 lần gọi: 29.700 lần cache hit tốn 490,05 USD, 3.300 lần ghi cache tốn 111,375 USD, cộng lại khoảng 601,43 USD.

Chia cho số lần gọi được khoảng 1,8 cent mỗi lần. Con số này đẹp nhưng không có ích cho CFO.

Bây giờ giả sử chỉ 80% hồ sơ, tức 8.000 hồ sơ, được xử lý trọn vẹn không cần người can thiệp. 2.000 hồ sơ còn lại vẫn chạy đủ các lần gọi của chúng, nên tiền của chúng vẫn nằm trong 601,43 USD, nhưng chúng không được tính là kết quả.

Chi phí trên mỗi kết quả là 601,43 chia 8.000, khoảng 7,5 cent. Con số này gấp hơn bốn lần chi phí mỗi lần gọi, và là con số CFO có thể so trực tiếp với chi phí nhân công cho một hồ sơ.

Biên sai số nằm ở những giả định nào?

CloudNuro khuyên mô hình hoá nhiều kịch bản: bảo thủ, cơ sở, tích cực. Mỗi kịch bản phải dựa trên một giả định cụ thể, nếu không chỉ là con số đoán. Với ví dụ trên, ba biến số làm kết quả dao động nhiều nhất là tỷ lệ cache hit, tỷ lệ thử lại và tỷ lệ thành công.

Kịch bản	Cache hit	Thử lại	Thành công	Tổng chi tháng	Chi phí mỗi kết quả
Bảo thủ	50%	20%	70%	~904,50 USD	~12,9 cent
Cơ sở	90%	10%	80%	~601,43 USD	~7,5 cent
Tích cực	95%	5%	85%	~546,92 USD	~6,4 cent

Cache hit là biến dễ bị đánh giá sai nhất. Theo Anthropic, cache mặc định sống 5 phút và được làm mới miễn phí mỗi lần dùng. Ban ngày hồ sơ đến liên tục nên cache luôn còn.

Ban đêm, nếu cứ mười phút mới có một hồ sơ, cache đã hết hạn trước khi hồ sơ tiếp theo đến. Giả sử ba bước của một hồ sơ dùng chung phần tiền tố đã cache và chạy liền nhau, thì lần gọi đầu của mỗi hồ sơ phải ghi cache lại với giá 1,25 lần, chỉ hai lần sau trúng cache.

Như vậy tỷ lệ cache hit ban đêm tụt về khoảng 67%, thấp hơn hẳn mức 90% của kịch bản cơ sở. Nếu mỗi bước dùng một prompt riêng, cả ba lần gọi đều phải ghi cache. Tỷ lệ bạn đo trong lúc load test có thể cao hơn hẳn thực tế.

Token suy luận làm biên sai số rộng thêm. OpenAI khuyên khi mới thử nghiệm nên dự phòng ít nhất 25.000 token cho phần suy luận và output.

Với giá output giả định ở trên, một lần gọi chạm mức này tốn 0,375 USD, bằng hơn 20 lần chi phí trung bình mỗi lần gọi trong kịch bản cơ sở.

Nếu workflow dùng model suy luận, hãy ghi trần chi phí mỗi lần gọi thành một giả định riêng trong bảng.

Những lỗi hay gặp

Lỗi phổ biến nhất là báo chi phí mỗi lần gọi rồi để CFO tự hiểu đó là chi phí mỗi việc. Đến khi họ tự chia hoá đơn cho số hồ sơ, bạn mất uy tín ngay. Lỗi thứ hai là lấy tỷ lệ cache hit từ môi trường dev, nơi request đến dày đặc, rồi áp vào production có lưu lượng thưa vào ban đêm.

Lỗi thứ ba là quên phụ phí ghi cache, nên tưởng mọi lần gọi đều được hưởng giá 0,1 lần. Lỗi thứ tư là gộp thất bại và thử lại vào một con số chung, nên không biết chi phí tăng vì model kém hay vì pipeline lỗi. Lỗi cuối cùng là chỉ đưa ra một con số dự báo duy nhất, không kèm kịch bản nào.

Nói với CFO thế nào?

Câu mở đầu nên là: “Mỗi hồ sơ xử lý xong hiện tốn khoảng 7,5 cent, và trong tình huống xấu có thể lên khoảng 12,9 cent.” Câu tiếp theo nói biến nào đẩy chi phí lên mức xấu và bạn theo dõi biến đó ra sao. Token chỉ nên xuất hiện trong phụ lục.

Blog của CloudNuro nêu rằng trung bình các tổ chức chi cho dịch vụ AI tính theo mức tiêu thụ nhiều hơn 17% so với ngân sách ban đầu. Đây là số liệu của một nhà cung cấp nên chỉ nên xem để tham khảo, nhưng nó cho thấy ngân sách không có biên dự phòng sẽ dễ bị vượt.

Vì thế, trước khi rời cuộc họp, hãy hẹn một nhịp đối chiếu. CloudNuro viết rằng dự báo chỉ đáng tin khi được so với thực tế đều đặn, và đề xuất mỗi tháng rà soát dự báo với thực chi một lần.

Dự báo đầu tiên gần như chắc chắn sẽ lệch. Điều CFO nhớ là tháng sau bạn quay lại với con số thực chi, chỉ ra giả định nào đã sai và bảng kịch bản đã được sửa ra sao.