Chỉ số còn thiếu giữa token và chi phí đám mây

Vấn đề không phải là các đội AI thiếu dữ liệu chi phí. Mà là bảng điều khiển token và hóa đơn đám mây mô tả các hệ thống khác nhau, thuộc sở hữu của các đội khác nhau, và không có cách đáng tin cậy để kết nối chúng.

Một nhân viên hỗ trợ có thể giải quyết một phiếu sau năm lần gọi mô hình, một bước truy xuất, hai lần gọi công cụ, và một lần thử lại. Doanh nghiệp ghi nhận một trường hợp đã hoàn thành. Hạ tầng ghi lại một loạt các yêu cầu, pod, bộ nhớ, thời gian tăng tốc và các dịch vụ chia sẻ. Cho đến khi những bản ghi này khớp nhau, việc tối ưu chi phí vẫn phần nào là đoán mò.

Tại sao các chỉ số token và hóa đơn đám mây lại kể những câu chuyện khác nhau?

Số lượng token rất hữu ích. Chúng cho biết mô hình nhận và trả lại bao nhiêu văn bản, và giúp các đội so sánh các lời nhắc, mô hình hoặc lựa chọn định tuyến. Nhưng chúng không cho biết những gì đã xảy ra xung quanh lần gọi mô hình, bao nhiêu tính toán đã hỗ trợ việc truy xuất và sử dụng công cụ, có bao nhiêu lần thử thất bại đã xảy ra trước, hoặc kết quả cuối cùng có thực sự hữu ích hay không.

Báo cáo State of FinOps 2026 cho thấy AI đã nhanh chóng hòa nhập vào công việc FinOps thông thường: 98% người trả lời hiện quản lý chi tiêu AI, so với 63% vào năm 2025. Tuy nhiên, một mục ngân sách lớn hơn vẫn không cho biết quy trình nào đã tiêu tiền hoặc vì lý do gì. 

Hai công việc xử lý tài liệu có thể sử dụng gần như cùng một số lượng token. Một công việc có thể hoàn thành chỉ với một yêu cầu mô hình duy nhất. Công việc còn lại có thể truy xuất ngữ cảnh từ nhiều kho, gọi dịch vụ bên ngoài, chuyển sang mô hình khác, và chạy lại tài liệu sau một kiểm tra xác thực thất bại mà người dùng không thấy. Tổng số token trông giống nhau nhưng các đường thực thi lại khác nhau.

Unite.ai đã nghiên cứu lý do tại sao số lượng token không tự động phản ánh giá trị kinh doanh. Bước tiếp theo là kết nối những con số này với các khối tải đã tạo ra chúng. Nếu không, một đội có thể cải thiện chi phí trên mỗi token nhưng đồng thời làm tăng chi phí trên mỗi nhiệm vụ đã hoàn thành.

Chuỗi chi phí hoàn chỉnh trông như thế nào?

Một chuỗi chi phí hữu ích bắt đầu từ kết quả mà doanh nghiệp quan tâm. Đó có thể là một trường hợp hỗ trợ đã giải quyết, một tài liệu đã xử lý, một thay đổi mã được chấp nhận, hoặc một quy trình làm việc của agent đã hoàn thành. Mọi thứ phía dưới cần một định danh có thể được theo dõi xuyên suốt hệ thống.

Lớp ứng dụng cung cấp kết nối đầu tiên. Một request ID, trace ID, tên quy trình hoặc conversation ID có thể liên kết nhiều hoạt động mô hình và công cụ với một công việc duy nhất. Nếu không có chuỗi này, mười sự kiện liên quan sẽ trông như mười khoản phí không liên quan.

Các quy ước OpenTelemetry conventions for GenAI agents cung cấp một từ vựng mới cho lớp này. Chúng bao gồm các hoạt động, nhà cung cấp, mô hình được yêu cầu, agent, hội thoại, việc sử dụng token, thực thi công cụ, lỗi và quy trình làm việc. Các quy ước vẫn được đánh dấu đang phát triển, vì vậy các đội không nên coi chúng là tiêu chuẩn toàn cầu đã hoàn thiện. Chúng hữu ích vì chúng làm cho vấn đề tương quan trở nên cụ thể.

Tiếp đến là hạ tầng. Dữ liệu phân bổ chi phí chia sẻ của AWS cho EKS split cost allocation data for EKS có thể gán chi phí tính toán và bộ nhớ chia sẻ cho các pod Kubernetes và hiển thị các chi tiết như cụm, namespace, deployment, node, tên workload và loại workload. Đối với các instance tăng tốc được hỗ trợ, dữ liệu còn bao gồm các đặt trước GPU, Trainium và Inferentia.

Đó là nửa còn lại của chuỗi. Một trace có thể giải thích ứng dụng đã cố gắng làm gì; việc phân bổ Kubernetes có thể cho thấy tài nguyên nào đã thực hiện công việc. Hướng dẫn của Unite.ai về deploying and monitoring LLMs on Kubernetes cung cấp bối cảnh sản xuất rộng hơn, bao gồm phân bổ tài nguyên, mở rộng và khả năng quan sát.

Sự liên kết sẽ không xảy ra một cách ngẫu nhiên. Các đội cần một định danh ổn định đủ lâu để kết nối dữ liệu đo lường ứng dụng với các nhãn workload, bản ghi phân bổ hoặc lớp ánh xạ khác. Dữ liệu khách hàng không nên nằm trong thẻ Kubernetes. Các đội nên quyết định những định danh có độ phân giải thấp nào có thể an toàn kết nối một danh mục quy trình, dịch vụ hoặc tính năng với các tài nguyên đã tiêu thụ.

Khi bối cảnh ứng dụng đã sẵn sàng, các đội có thể bắt đầu theo dõi chi phí Kubernetes theo workload và kết nối namespace, CPU, bộ nhớ và việc sử dụng GPU trở lại với công việc đang thực hiện. Điều này vẫn không cho biết quy trình có tạo ra giá trị kinh doanh hay không, nhưng nó cung cấp cho phía hạ tầng của phép tính một yếu tố cụ thể để gắn kết. 

Đơn vị đo lường nào doanh nghiệp nên tin tưởng?

Không có một chỉ số chi phí AI duy nhất mà mọi đội đều nên sử dụng. Chi phí trên mỗi token trả lời câu hỏi về tiêu thụ mô hình. Chi phí trên mỗi pod trả lời câu hỏi về phân bổ hạ tầng. Cả hai đều không cho chủ sản phẩm biết tính năng có mang lại giá trị hay không.

Mẫu số tốt nhất thường là kết quả nhỏ nhất mà doanh nghiệp có thể xác định rõ ràng và đội sản phẩm có thể ảnh hưởng. Một hoạt động hỗ trợ có thể theo dõi chi phí trên mỗi trường hợp đã giải quyết. Một hệ thống tài liệu có thể sử dụng chi phí trên mỗi tệp được xử lý thành công, trong khi một trợ lý lập trình có thể xem chi phí trên mỗi thay đổi được chấp nhận thay vì chi phí trên mỗi đề xuất.

Thành công làm thay đổi phép tính.

Một quy trình với chi phí mỗi lần thử thấp có thể tốn kém nếu nó thường thất bại, gây ra việc xác thực lặp lại, hoặc gửi quá nhiều trường hợp cho người kiểm tra. Đó là lý do tại sao các đội nên tách chi phí cho mỗi lần thử khỏi chi phí để hoàn thành và, nếu có thể, chi phí cho mỗi kết quả được chấp nhận. Con số cuối cùng thường là hữu ích nhất vì nó bao gồm công việc mà hệ thống tạo ra nhưng doanh nghiệp không thể sử dụng.

Các hệ thống agent làm cho việc này trở nên khó hơn vì các đường đi của chúng có thể thay đổi từ lần chạy này sang lần chạy khác. Phân tích của Unite.ai về the economics of scaling agentic AI workloads bao gồm định tuyến, gọi công cụ, thử lại và gán nhãn ở mức quy trình. Những hành vi này nên được đưa vào đơn vị đo lường khi chúng tiêu thụ tài nguyên, ngay cả khi người dùng cuối chỉ thấy một câu trả lời.

Chỉ số vẫn không hoàn hảo. Các dịch vụ chia sẻ, kết quả được lưu trong bộ nhớ đệm, công việc batch và xử lý trễ có thể làm mờ việc gán nhãn. Một ước tính hữu ích cho quyết định tốt hơn so với độ chính xác giả tạo, đặc biệt khi nó cho các kỹ sư biết lớp nào cần được điều tra.

Ai sở hữu con số này?

Phần khó nhất có thể là về mặt tổ chức. Các đội ML hiểu các lần gọi mô hình và đánh giá. Các đội nền tảng hiểu các workload và hành vi cụm. FinOps hiểu dữ liệu thanh toán và quy tắc phân bổ. Các đội sản phẩm biết kết quả nào quan trọng.

Không có đội nào sở hữu toàn bộ chuỗi.

Điều này tạo ra một tranh luận dự đoán được về việc bảng điều khiển nào là đúng. Đội ML có thể chỉ ra việc sử dụng token thấp hơn, trong khi đội nền tảng thấy giờ GPU tăng và đội sản phẩm thấy số nhiệm vụ hoàn thành giảm so với trước. Ba quan sát này có thể đồng thời đúng. Chỉ số chung phải giải thích mối quan hệ giữa chúng.

Một điểm khởi đầu khả thi là một quy trình sản xuất với sự kiện hoàn thành rõ ràng. Gán cho nó một định danh ổn định. Mang bối cảnh này qua các trace của mô hình và công cụ, ánh xạ nó tới dịch vụ hoặc workload chạy trên Kubernetes, và chọn một mẫu số kinh doanh. Sau đó, tập hợp các đội lại khi con số thay đổi bất ngờ.

Đánh giá đó quan trọng hơn một bảng điều khiển được trau chuốt. Một đột biến tăng đột ngột có thể xuất phát từ các lời nhắc dài hơn, một đường dự phòng mới, khả năng GPU chưa được sử dụng hết, chính sách tự động mở rộng đã thay đổi, hoặc quyết định sản phẩm khiến nhiều công việc hơn được chuyển qua tính năng AI. Mỗi nguyên nhân thuộc về một chủ sở hữu khác nhau.

Tự động hoá nên đến sau. Một công cụ đề xuất chỉ có thể hành động dựa trên các nhãn và ngưỡng mà nó nhận được, và một mẫu số kém có thể khiến một hệ thống hiệu quả trông lãng phí hoặc thưởng cho một quy trình rẻ tiền mà người dùng từ chối. Các đội cần đủ khả năng quan sát chung để phân biệt hành vi mô hình với thiết kế ứng dụng và phân bổ hạ tầng trước khi cho phép hệ thống hành động dựa trên kết quả. Nếu không, một biện pháp tối ưu chi phí tự động có thể giảm khả năng, tăng độ trễ và chuyển chi phí đến nơi ít được nhìn thấy hơn.

Chuỗi chi phí phải được chia sẻ

Kiểm soát chi phí AI sẽ tiếp tục bị phân mảnh miễn là mỗi đội chỉ tối ưu lớp mà họ có thể nhìn thấy. Token, trace, pod, bộ tăng tốc và hóa đơn không phải là các phép đo cạnh tranh. Chúng là các phần của cùng một chuỗi chi phí.

Các công ty kết nối chúng sẽ không có được một con số hoàn hảo ngay từ ngày đầu. Điều quan trọng là đội có thể truy vết một hoá đơn cao trở lại quy trình đã gây ra, xác định những gì đã thay đổi, và quyết định liệu kết quả có xứng đáng với chi phí hay không.