Thêm tính năng đo lường chi phí và hiển thị mức chi tiêu LLM vào hệ thống đa tác nhân

Do Matteo Rossi viết. Hóa đơn LLM hàng tháng tăng vọt, nhưng không ai trong nhóm có thể xác định tác nhân (agent), người dùng, hay quy trình làm việc nào đã gây ra điều đó. Bảng điều khiển của nhà cung cấp phân tích mức sử dụng theo tổ chức, không gian làm việc, dự án, mô hình và khóa API. Bộ phận tài chính cố gắng đặt một câu hỏi khác: tác nhân nào, công cụ nào, người dùng nào, quy trình làm việc nào, dấu vết nào, lần thử lại nào, người thuê nào? Không có tính năng bảng điều khiển nào có thể giải quyết khoảng trống này, vì nhà cung cấp không biết ứng dụng của chúng ta tồn tại. Đây là một vấn đề về quy mô. Một tác nhân hoặc một nguyên mẫu duy nhất không cần bất kỳ điều gì sau đây: bảng điều khiển gốc đã trả lời câu hỏi khi chỉ có một đối tượng đang tiêu tốn. Những điều sau đây dành cho thời điểm khi điều đó không còn đúng nữa. **Chúng ta đã đến đây như thế nào** Các triển khai ban đầu sử dụng một tác nhân và một khóa API, và việc phân bổ hoạt động bằng cách loại trừ: vì chỉ có chi tiêu được theo dõi, tổng chi phí hàng tháng và chi phí của tác nhân là cùng một con số. Sau đó là sự điều phối đa tác nhân: một bộ lập kế hoạch, các tác nhân phụ, các lệnh gọi công cụ lồng nhau, các lần thử lại, nơi một yêu cầu người dùng duy nhất trở thành một cây lệnh gọi. Khóa API chưa bao giờ là vấn đề vì nó chưa bao giờ mang theo sự phân bổ ngay từ đầu. Vấn đề là ngữ cảnh ứng dụng (tác nhân nào, công cụ nào, bước quy trình làm việc nào đã thực hiện lệnh gọi) chỉ tồn tại trong bộ nhớ tại thời điểm yêu cầu và biến mất trừ khi có thứ gì đó ghi lại nó tại ranh giới lệnh gọi. Có bốn vấn đề khác nhau ở đây. Một khóa chỉ tạo ra một ranh giới tại chính khóa đó. Việc chia tách các tác nhân thành các khóa API riêng biệt rất dễ dàng, và hầu hết các nhà cung cấp báo cáo chi tiêu theo từng khóa. Nhưng một khóa không nói lên điều gì về phiên, dấu vết, công cụ hoặc lần thử lại, và việc cấp phát một khóa cho mỗi chiều sẽ không còn khả năng mở rộng ngay khi các chiều đó nhân lên, đó chính xác là điều mà sự điều phối đa tác nhân thực hiện theo thiết kế. Dữ liệu sử dụng được ghi lại muộn. Số lượng token được trả về trong mỗi phản hồi API. Một số nhà cung cấp sau đó hiển thị mức sử dụng thông qua các báo cáo quản trị hoặc thanh toán, nhưng các báo cáo đó chỉ báo cáo tổng số, không phải ngữ cảnh thời gian chạy. Tác nhân, công cụ, phiên, dấu vết, lần thử lại và người thuê đằng sau một lệnh gọi chỉ có sẵn tại thời điểm lệnh gọi trả về. Các lệnh gọi lồng nhau che giấu chi phí thực. Một tác vụ người dùng bùng nổ thành nhiều lệnh gọi trên bộ lập kế hoạch, các tác nhân phụ và công cụ, và tổng chi phí của quy trình làm việc đó không xuất hiện trong bất kỳ dòng nhật ký nào. Các lần thử lại được tính phí một cách âm thầm. Một lệnh gọi thất bại hai lần và thành công ở lần thử thứ ba đã tính phí chúng ta cho ba lần, và tổng tài khoản hiển thị một con số bao gồm tất cả chúng một cách âm thầm. Không ai nhận thấy một cơn bão thử lại từ bảng điều khiển của nhà cung cấp, nhưng họ nhận thấy nó từ hóa đơn. **Ghi lại mức sử dụng và tổng hợp trong MongoDB** Cách tiếp cận ở đây là đo lường tại điểm gọi và tổng hợp trong MongoDB. Xung quanh mỗi lệnh gọi LLM là một lớp đo lường mỏng, và ngay khi phản hồi đến, nó đọc mức sử dụng token, làm giàu nó với ngữ cảnh phân bổ mà chúng ta chỉ biết tại thời gian chạy, định giá nó và ghi chi phí một lần, tại thời điểm ghi. Số lượng token không bao giờ được ước tính từ các từ hoặc câu: phản hồi mang theo số lượng chính xác, và lớp đo lường có thể đọc chúng. Lưu trữ chúng dưới dạng các số riêng biệt thay vì một tổng số, vì chúng không có cùng chi phí: token đầu ra có giá gấp vài lần token đầu vào, token đọc lại từ bộ nhớ đệm lời nhắc có giá chỉ bằng một phần nhỏ, và việc ghi mục nhập bộ nhớ đệm đó tốn kém hơn so với đầu vào thông thường. Nếu gộp chúng vào một tổng số token duy nhất (totalTokens), chi phí sẽ không thể được tái tạo từ tài liệu. Ví dụ, trong Spring AI, đối tượng Usage chung mang theo đầu vào và đầu ra; các bộ đếm bộ nhớ đệm nằm trên nhà cung cấp. đối tượng gốc bên dưới nó. Đơn giá được lấy từ một tập hợp giá nhỏ mà lớp đọc khi ghi, chứ không phải từ một hằng số trong mã. Mỗi tài liệu là một thẻ giá được lập phiên bản: ```json { "model": "claude-haiku-4–5", "provider": "anthropic", "currency": "USD", "inputPerMtok": 1.0, "outputPerMtok": 5.0, "cacheWritePerMtok": 1.25, "cacheReadPerMtok": 0.1, "effectiveDate": { "$date": "2026–07–01T00:00:00Z" }, "pricingVersion": 1 } ``` Đây là mức giá trên mỗi token được Anthropic công bố cho Claude Haiku 4.5 tại thời điểm viết bài: 1,00 USD cho đầu vào, 5,00 USD cho đầu ra, 1,25 USD để ghi một mục bộ nhớ đệm 5 phút, 0,10 USD để đọc lại một mục, tất cả đều tính trên mỗi triệu token. Việc lưu trữ chúng trong một tập hợp thay vì một hằng số có nghĩa là một thay đổi giá vào quý tới hoặc một mô hình thứ hai tham gia hệ thống sẽ dẫn đến một tài liệu mới thay vì một lần triển khai. Tuy nhiên, tập hợp trường này là dành riêng cho nhà cung cấp. Anthropic định giá hai cấp độ ghi bộ nhớ đệm (1,25 lần đầu vào cơ bản cho mục 5 phút, 2 lần cho một giờ), và OpenAI không tính phí ghi bộ nhớ đệm trước dòng GPT-5.6. Việc thêm một nhà cung cấp thứ hai có thể yêu cầu các trường mới, không chỉ các tài liệu mới. Một dịch vụ tra cứu thẻ hiện tại cho mô hình và trả về cả chi phí lẫn tỷ lệ đã tạo ra nó. Phép tính là một phép nhân cho mỗi loại token, được giữ trong một hàm thuần túy không có kho lưu trữ và không có framework nào gần đó: ```java public static double costUsd(ModelPrice price, int promptTokens, int completionTokens, int cacheCreationTokens, int cacheReadTokens) { return (promptTokens * price.inputPerMtok() + completionTokens * price.outputPerMtok() + cacheCreationTokens * price.cacheWritePerMtok() + cacheReadTokens * price.cacheReadPerMtok()) / 1_000_000; } ``` Đó cũng là lý do tại sao tỷ lệ được trả về cùng với chi phí: nó được sao chép vào tài liệu sử dụng mà nó đã định giá. Việc chỉnh sửa tập hợp giá vào ngày mai không thể thay đổi chi phí đã được ghi, và bất kỳ ai kiểm toán khoản bồi hoàn của tháng trước đều có thể tính toán lại mọi dòng từ các con số được lưu trữ bên cạnh. Dưới đây là một tài liệu như vậy, trực tiếp từ tác nhân truy xuất. `traceId` được chia sẻ bởi mọi lệnh gọi phục vụ cùng một yêu cầu người dùng, và đó là thứ sau này tái tạo chi phí của toàn bộ quy trình làm việc: ```json { "traceId": "f7035cf6-a13e-468d-9660–07452c5f2f4a", "agent": "retrieval-agent", "model": "claude-haiku-4–5", "promptTokens": 148, "completionTokens": 62, "cacheCreationTokens": 0, "cacheReadTokens": 0, "price": { "currency": "USD", "inputPerMtok": 1.0, "outputPerMtok": 5.0, "cacheWritePerMtok": 1.25, "cacheReadPerMtok": ```