Đo lường việc sử dụng AI theo từng khách hàng là hệ điều hành đằng sau việc tính phí công bằng cho các tính năng AI nhúng. Nếu một trợ lý hỗ trợ, trình phân tích tài liệu, trình tạo hình ảnh hoặc tác nhân quy trình làm việc chạy bên trong sản phẩm của bạn, hóa đơn mô hình sẽ không cho bạn biết khách hàng nào đã gây ra chi tiêu nào, tính năng nào đã tạo ra nhu cầu hoặc liệu một mục hàng bị tranh chấp có nên được ghi có hay không.
Lỗ hổng đó nhanh chóng trở nên tốn kém. Bảng điều khiển của nhà cung cấp có thể hiển thị việc sử dụng theo dự án, khóa API, người dùng, mô hình, mục hàng hoặc ngày. Các cổng (Gateway) có thể lưu giữ siêu dữ liệu, nhật ký, số lượng token, trạng thái và chi phí. Hệ thống thanh toán có thể nhận các sự kiện sử dụng với ID khách hàng, giá trị, dấu thời gian và khóa an toàn (idempotency key). Nhưng không có phần nào trong số đó trở thành bằng chứng thanh toán cho đến khi ứng dụng của bạn đóng dấu bối cảnh khách hàng phù hợp vào mỗi yêu cầu AI và đối chiếu chuỗi trước khi hóa đơn được chốt.
Flatkey quan trọng trong quy trình làm việc này vì trang web công khai định vị flatkey.ai là một khóa API duy nhất cho các mô hình GPT, Claude, Gemini, DeepSeek, hình ảnh, âm thanh và video, với giá cả, phân tích sử dụng, kiểm soát chi phí và một hóa đơn duy nhất cho tất cả các nhà cung cấp. Hãy coi đó là bề mặt truy cập và xem xét thống nhất. Đừng coi nó là sự thay thế cho hợp đồng phân bổ khách hàng của riêng bạn. Trước khi thanh toán chính thức, hãy xác minh các trường bảng điều khiển chính xác, nhật ký yêu cầu, hành vi xuất, danh mục mô hình, đơn vị giá và cài đặt lưu giữ trong tài khoản Flatkey hiện tại của bạn.
Đo lường việc sử dụng AI theo từng khách hàng: Phiên bản ngắn gọn
Đo lường việc sử dụng AI theo từng khách hàng nên trả lời bốn câu hỏi cho mọi tính năng AI nhúng:
| Câu hỏi | Trường bằng chứng | Tại sao nó quan trọng |
|---|---|---|
| Khách hàng nào đã gây ra yêu cầu? | customer_meter_id hoặc ID tenant đã băm | Hỗ trợ thanh toán, tín dụng và giới hạn cấp khách hàng |
| Tính năng nào đã tạo ra việc sử dụng? | feature_id, route, workflow, hoặc SKU | Tách biệt các cuộc trò chuyện, tìm kiếm, tóm tắt, tác nhân và các công việc nền |
| Lệnh gọi AI đã tiêu thụ những gì? | mô hình, token đầu vào, token đầu ra, số lượng yêu cầu, token bộ nhớ đệm, đơn vị phương tiện | Chuyển đổi việc sử dụng thành các đơn vị của nhà cung cấp và hóa đơn |
| Bộ phận tài chính có thể bảo vệ khoản phí không? | ID yêu cầu, dấu thời gian, kỳ thanh toán, phiên bản giá, ID sự kiện đo lường, trạng thái đối chiếu | Hỗ trợ dấu vết kiểm toán và xem xét tranh chấp |
Mô hình hữu ích không phải là "ghi nhật ký mọi thứ." Mô hình này là phân bổ khách hàng an toàn về quyền riêng tư, bằng chứng yêu cầu bền vững và tổng hợp có kiểm soát thành các sự kiện đo lường thanh toán. Đó là cách đo lường việc sử dụng AI theo từng khách hàng biến AI nhúng từ một bất ngờ về tỷ suất lợi nhuận gộp thành một dòng sản phẩm có thể xem xét được.
Tại sao việc sử dụng ở cấp độ nhóm là không đủ
Theo dõi việc sử dụng ở cấp độ nhóm giúp kỹ thuật quản lý chi tiêu, nhưng nó quá thô để thanh toán cho AI nhúng. Một khóa API sản xuất duy nhất có thể trộn lẫn lưu lượng truy cập từ các bản dùng thử miễn phí, khách hàng trả phí, nhân viên nội bộ, tài khoản demo, các lần thử lại, lập chỉ mục nền và các thiết bị kiểm tra. Nếu bạn chỉ nhóm theo nhóm hoặc môi trường, cuộc trò chuyện về hóa đơn sẽ trở thành phỏng đoán.
Phân bổ cấp khách hàng trở nên cần thiết khi:
- Bạn gộp các tín dụng AI vào các gói trả phí.
- Bạn tính phí vượt mức cho việc sử dụng AI cao cấp.
- Bộ phận bán hàng hứa hẹn các khoản tín dụng hoặc giới hạn cụ thể cho khách hàng.
- Bộ phận mua sắm hỏi việc sử dụng AI xuất hiện trên hóa đơn như thế nào.
- Một khách hàng tranh chấp một khoản phí hoặc nói rằng một tính năng đã không được sử dụng.
- Bộ phận hỗ trợ cần giải thích tại sao một tenant vượt quá hạn ngạch.
- Bộ phận tài chính cần tỷ suất lợi nhuận gộp theo tài khoản, phân khúc hoặc tính năng.
Đo lường việc sử dụng AI theo từng khách hàng không yêu cầu gửi dữ liệu cá nhân cho nhà cung cấp AI. Thực tế, nó nên tránh điều đó. Khóa khách hàng bạn đo lường thường phải là một mã định danh nội bộ an toàn cho việc thanh toán, chẳng hạn như cust_meter_8f2a9c, không phải là địa chỉ email, tên công ty, lời nhắc hoặc tên người dùng cuối.
Xây dựng hợp đồng đo lường khách hàng trước tiên
Hợp đồng đo lường là một tập hợp nhỏ các trường mà mọi yêu cầu AI phải mang theo trước khi đến cổng (gateway) hoặc nhà cung cấp. Hãy giữ cho nó ổn định, đơn giản và có thể kiểm toán được.
| Trường | Ví dụ | Quy tắc |
|---|---|---|
| customer_meter_id | cust_8f2a9c | ID khách hàng hoặc tenant nội bộ, ẩn danh khi có thể |
| billing_account_id | acct_2041 | Tài khoản sở hữu hóa đơn, không nhất thiết là người dùng cuối |
| feature_id | support_summary | Tính năng sản phẩm hoặc SKU có thể tính phí |
| environment | prod | Tách biệt lưu lượng sản xuất khỏi lưu lượng dàn dựng và kiểm thử |
| request_id | req_01HX... | ID yêu cầu ứng dụng duy nhất để phát lại và hỗ trợ |
| idempotency_key | meter_01HX... | Khóa sự kiện đo lường duy nhất để các lần thử lại không bị tính phí hai lần |
| model_requested | gpt-4o-mini hoặc bí danh cổng | Những gì ứng dụng đã yêu cầu |
| model_served | mô hình thực tế sau khi định tuyến | Những gì đã thực sự chạy, khi có sẵn |
| unit_basis | tokens, requests, seconds, images | Đơn vị sẽ được tổng hợp vào thanh toán |
| pricing_version | ai-plan-2026-07 | Phiên bản được sử dụng để tính toán cho khách hàng |
| privacy_mode | metadata_only | Liệu các payload của lời nhắc/đầu ra có được giữ lại hay không |
Hợp đồng này nên được tạo ra bởi các nhóm sản phẩm và tài chính cùng nhau. Kỹ thuật sở hữu chất lượng thu thập; tài chính sở hữu việc diễn giải thanh toán; hỗ trợ sở hữu lời giải thích mà khách hàng sẽ nghe.
Đóng dấu siêu dữ liệu trước khi lệnh gọi AI rời khỏi ứng dụng của bạn
Nơi an toàn nhất để thêm bối cảnh khách hàng là ranh giới dịch vụ đã biết tenant và tính năng đã được xác thực. Đừng yêu cầu các máy khách frontend gửi ID khách hàng làm bằng chứng thanh toán đáng tin cậy. Backend nên lấy ID đo lường khách hàng từ phiên, tenant, quyền lợi hoặc chủ sở hữu công việc.
type AiMeteringContext = {
customerMeterId: string;
billingAccountId: string;
featureId: "support_summary" | "contract_review" | "agent_run";
environment: "prod" | "staging" | "dev";
requestId: string;
pricingVersion: string;
};
function buildAiMetadata(ctx: AiMeteringContext) {
return {
customer_meter_id: ctx.customerMeterId,
billing_account_id: ctx.billingAccountId,
feature_id: ctx.featureId,
environment: ctx.environment,
app_request_id: ctx.requestId,
pricing_version: ctx.pricingVersion,
};
}
Phương thức vận chuyển chính xác phụ thuộc vào cổng và SDK của bạn. Ví dụ, Cloudflare AI Gateway có tài liệu về siêu dữ liệu tùy chỉnh để gắn thẻ yêu cầu và cho biết các giá trị siêu dữ liệu xuất hiện trong nhật ký để tìm kiếm và lọc. Tài liệu ghi nhật ký của nó cũng mô tả việc ghi nhật ký chỉ siêu dữ liệu khi sử dụng cf-aig-collect-log-payload: false, giữ lại số lượng token, mô hình, nhà cung cấp, mã trạng thái, chi phí và thời gian trong khi bỏ qua các payload của prompt và phản hồi thô. Vercel AI Gateway có tài liệu về các trường người dùng và thẻ để báo cáo, cộng với các tiêu đề như ai-reporting-user và ai-reporting-tags để ghi nhận việc sử dụng mà không cần viết lại mọi vị trí gọi.
Những ví dụ đó là các mẫu của nhà cung cấp và cổng, không phải là các xác nhận tính năng của Flatkey. Nếu bạn sử dụng Flatkey, hãy xác minh đường dẫn siêu dữ liệu được hỗ trợ hiện tại và nhật ký trong tài khoản của bạn trước khi dựa vào một trường để tính phí.
Bảo toàn các chiều kích sử dụng và chi phí của nhà cung cấp
Sổ cái khách hàng nội bộ của bạn không nên làm phẳng chi tiết của nhà cung cấp quá sớm. Các API sử dụng của nhà cung cấp thường hiển thị các chiều kích giúp giải thích những thay đổi về chi phí sau này.
Điểm cuối sử dụng của tổ chức của OpenAI hỗ trợ nhóm việc sử dụng hoàn thành theo các trường như dự án, người dùng, khóa API, mô hình, lô và cấp dịch vụ, và trả về các trường sử dụng như token đầu vào, token đầu ra, token được lưu trong bộ nhớ đệm, token âm thanh, số lượng yêu cầu, mô hình, ID dự án, ID người dùng và ID khóa API. Điểm cuối chi phí của tổ chức của OpenAI hỗ trợ nhóm chi phí theo dự án, mục hàng và khóa API, và trả về các trường số tiền, tiền tệ, mục hàng, ID dự án, ID khóa API và số lượng.
Điều đó không có nghĩa là sổ cái khách hàng của bạn nên sử dụng ID người dùng OpenAI làm ID khách hàng. Điều đó có nghĩa là lớp đo lường việc sử dụng AI theo từng khách hàng của bạn nên bảo toàn đủ ngữ cảnh ở cấp độ yêu cầu để kết hợp:
- ID khách hàng của ứng dụng với ID yêu cầu của cổng.
- ID yêu cầu của cổng với ID yêu cầu hoặc ID tạo của nhà cung cấp.
- Đơn vị sử dụng của nhà cung cấp với đơn vị có thể tính phí cho khách hàng.
- Mục hàng chi phí của nhà cung cấp với nhóm sử dụng của khách hàng.
- Các sự kiện thử lại/dự phòng với quyết định tính phí cuối cùng.
Nếu một báo cáo của nhà cung cấp sau đó cho thấy sự tăng vọt chi phí theo mô hình hoặc khóa API, bạn cần truy vết lại đến khách hàng, tính năng và kỳ hóa đơn mà không làm lộ nội dung của prompt.
Sử dụng sổ cái sử dụng của khách hàng
Sổ cái sử dụng của khách hàng là bảng có thể xem xét lại nằm giữa nhật ký AI thô và hóa đơn của khách hàng. Nó nên là chỉ ghi thêm (append-only) hoặc được phiên bản hóa, vì các tranh chấp hóa đơn thường hỏi những gì đã được biết tại thời điểm chốt sổ, chứ không phải những gì bảng điều khiển hiện tại hiển thị sau khi điền lại dữ liệu.
| Cột | Ví dụ | Mục đích |
|---|---|---|
| occurred_at | 2026-07-10T11:03:22Z | Thời gian yêu cầu nguồn |
| billing_period | 2026-07 | Nhóm hóa đơn |
| customer_meter_id | cust_8f2a9c | Phân bổ cho khách hàng |
| feature_id | support_summary | Phân bổ cho tính năng |
| environment | prod | Loại trừ lưu lượng không thể tính phí |
| app_request_id | req_01HX... | Dấu vết hỗ trợ |
| gateway_request_id | gw_91b... | Dấu vết cổng |
| provider_request_id | gen_72c... | Dấu vết nhà cung cấp, khi có sẵn |
| model_served | model-alias | Mô hình thực sự được sử dụng |
| input_tokens | 841 | Đơn vị sử dụng |
| output_tokens | 226 | Đơn vị sử dụng |
| requests | 1 | Đơn vị sử dụng |
| raw_provider_cost | 0.0042 | Cơ sở chi phí nội bộ |
| billable_units | 1.067 token | Đơn vị hiển thị cho khách hàng |
| pricing_version | ai-plan-2026-07 | Diễn giải giá |
| meter_event_id | meter_01HX... | Bàn giao cho hệ thống tính phí |
| reconciliation_state | matched | Chất lượng bằng chứng |
Sổ cái này là tài sản giá trị cho việc đo lường sử dụng AI theo từng khách hàng. Nhật ký thô quá chi tiết đối với bộ phận tài chính. Hóa đơn thì quá muộn đối với bộ phận kỹ thuật. Sổ cái là lớp bằng chứng được chia sẻ.
Chuyển đổi các hàng trong sổ cái thành sự kiện đo lường thanh toán
Nếu bạn sử dụng Stripe hoặc một hệ thống thanh toán dựa trên mức sử dụng khác, đừng gửi mọi yêu cầu AI thô một cách mù quáng. Trước tiên, hãy quyết định điều gì được tính là mức sử dụng có thể tính phí.
API sự kiện đo lường của Stripe yêu cầu một event_name và một payload. Payload phải chứa các trường khớp với ánh xạ khách hàng và cài đặt giá trị của công cụ đo lường; tài liệu có các ví dụ sử dụng payload[value] và payload[stripe_customer_id]. Stripe cũng hỗ trợ một identifier để đảm bảo tính duy nhất và một timestamp được đo bằng giây Unix, với các giới hạn dấu thời gian được xác định bởi API.
Điều đó ánh xạ một cách rõ ràng vào sổ cái:
{
"event_name": "embedded_ai_tokens",
"identifier": "meter_01HX7VJ8AQB8",
"timestamp": 1783681402,
"payload": {
"stripe_customer_id": "cus_123",
"value": 1067,
"feature_id": "support_summary",
"pricing_version": "ai-plan-2026-07"
}
}
Sự kiện thanh toán nên có tính bất biến (idempotent). Nếu worker của bạn thử lại sau khi hết thời gian chờ, cùng một yêu cầu AI không nên tạo ra hai sự kiện có thể tính phí. Giữ ID sự kiện đo lường trong sổ cái khách hàng và lưu trữ phản hồi API thanh toán, ngay cả khi phản hồi là "đã được xử lý".
Quyết định những gì không thể tính phí
Việc đo lường sử dụng AI theo từng khách hàng cũng quan trọng về các khoản loại trừ như các khoản phí. Sổ cái của bạn nên phân loại lưu lượng truy cập trước khi nó đi vào hệ thống thanh toán:
| Loại lưu lượng | Quyết định thanh toán mặc định | Bằng chứng cần lưu giữ | |---|---|---| | Hành động của khách hàng trong môi trường production | Có thể tính phí, nếu gói dịch vụ cho phép đo lường AI | ID khách hàng, tính năng, ID yêu cầu, đơn vị sử dụng | | Hành động hỗ trợ nội bộ thay mặt khách hàng | Thường không tính phí hoặc được phân loại riêng | ID nhân viên, ID ticket, ID khách hàng, lý do | | Thử lại sau lỗi của nhà cung cấp | Chỉ tính phí cho yêu cầu logic thành công | ID yêu cầu gốc, số lần thử lại, trạng thái cuối cùng | | Chuyển đổi dự phòng từ mô hình này sang mô hình khác | Tính phí theo chính sách, không tính phí cả hai một cách mù quáng | Mô hình được yêu cầu, mô hình đã phục vụ, quyết định định tuyến | | Lưu lượng staging/dev/test | Không tính phí | Môi trường, chủ sở hữu, dấu hiệu kiểm thử | | Lạm dụng hoặc vòng lặp tự động | Thường được hoàn tiền hoặc giới hạn | Sự kiện giới hạn tốc độ, lý do phát hiện, thông báo cho khách hàng | | Bù đắp hoặc di chuyển dữ liệu | Thường không tính phí | ID công việc, người vận hành, sự chấp thuận |
Công bố các quy tắc này trong nội bộ trước khi khách hàng hỏi. Một chính sách được ghi lại bằng văn bản sẽ ngăn chặn các bộ phận hỗ trợ, tài chính và kỹ thuật tạo ra các ngoại lệ đặc biệt cho mọi tranh chấp.
Giữ nội dung Prompt ngoài bằng chứng thanh toán khi có thể
Bằng chứng thanh toán hiếm khi cần các prompt hoặc completion thô. Hầu hết các tranh chấp có thể được xử lý bằng dấu thời gian, tính năng, khách hàng, mô hình, số lượng token, trạng thái yêu cầu và các nhãn sự kiện mà khách hàng thấy.
Một chính sách đo lường việc sử dụng AI theo từng khách hàng an toàn về quyền riêng tư nên tách biệt:
- Siêu dữ liệu đo lường: ID đo lường của khách hàng, tính năng, môi trường, ID yêu cầu, mô hình, token, chi phí, dấu thời gian.
- Tải trọng hoạt động: prompt, tài liệu được truy xuất, văn bản được tạo, tệp đính kèm, đầu vào công cụ.
- Chú thích hỗ trợ: ID ticket, ID người đánh giá, lý do hoàn tiền, giải thích cho khách hàng.
Lưu trữ danh mục đầu tiên lâu hơn danh mục thứ hai. Hạn chế danh mục thứ hai một cách nghiêm ngặt hơn. Mẫu ghi nhật ký chỉ siêu dữ liệu của Cloudflare rất hữu ích ở đây vì nó cho thấy một sự phân chia hoạt động phổ biến: giữ lại các chỉ số sử dụng và siêu dữ liệu yêu cầu mà không lưu trữ phần thân yêu cầu và phản hồi cho yêu cầu đó. Nếu cổng hoặc nhà cung cấp của bạn cung cấp một cơ chế kiểm soát tương tự, hãy kiểm thử nó trước khi bạn gửi lưu lượng truy cập của khách hàng được quy định.
Đối chiếu trước khi hóa đơn được chốt
Công việc đối chiếu là nơi việc đo lường sử dụng AI theo từng khách hàng trở thành bằng chứng thanh toán. Hãy chạy nó trước khi hóa đơn được hoàn tất, chứ không phải sau khi có khiếu nại đầu tiên.
Sử dụng quy trình làm việc hàng ngày hoặc hàng giờ này:
- Lấy các sự kiện AI thô của ứng dụng cho kỳ thanh toán.
- Lấy nhật ký hoặc dữ liệu xuất của cổng cho cùng kỳ.
- Lấy tóm tắt sử dụng và chi phí của nhà cung cấp theo mô hình, khóa API, dự án hoặc hạng mục.
- Lấy xác nhận sự kiện đo lường thanh toán.
- Kết hợp dựa trên ID yêu cầu, dấu thời gian, ID đo lường của khách hàng và bí danh mô hình.
- Đánh dấu mỗi hàng trong sổ cái là
matched,missing_gateway_log,missing_provider_usage,meter_not_sent,meter_duplicate,nonbillable, hoặcneeds_review. - Chặn việc hoàn tất hóa đơn đối với các hàng có giá trị cao chưa được giải quyết.
- Xuất bản tóm tắt cấp khách hàng cho bộ phận hỗ trợ và tài chính.
Báo cáo quan trọng nhất không phải là tổng chi tiêu. Đó là hàng đợi ngoại lệ. Một số lượng nhỏ các hàng không khớp có thể tạo ra vấn đề lớn nhất về lòng tin của khách hàng.
Xây dựng một gói tài liệu tranh chấp
Khi một khách hàng hỏi, "Tại sao tôi bị tính phí cho việc sử dụng AI?", bộ phận hỗ trợ không nên mở năm bảng điều khiển và ứng biến. Hãy chuẩn bị một định dạng gói tài liệu tranh chấp:
| Phần | Bao gồm | Tránh | |---|---|---| | Tóm tắt | kỳ thanh toán, tính năng, đơn vị sử dụng, gói của khách hàng, tổng phí | Văn bản prompt hoặc completion trừ khi thực sự cần thiết | | Bằng chứng | ID yêu cầu, dấu thời gian, loại mô hình, số lượng token/yêu cầu, ID sự kiện đo lường | Bí mật nội bộ của nhà cung cấp hoặc khóa API thô | | Chính sách | quy tắc tính phí, chính sách thử lại/dự phòng, chính sách tín dụng đi kèm | Các giải thích một lần không được phê duyệt | | Quyết định | chấp nhận, hoàn tiền, sửa chữa, hoặc chuyển cấp | Đổ lỗi qua lại giữa các nhà cung cấp | | Theo dõi | thay đổi giới hạn, sửa lỗi, thông báo cho khách hàng | Các chỉnh sửa thủ công không có tài liệu |
Điều này đặc biệt quan trọng đối với các tính năng AI nhúng vì người dùng nhấp vào tính năng có thể không phải là người mua xem xét hóa đơn. Gói tài liệu phải giải thích khoản phí bằng ngôn ngữ sản phẩm, không chỉ bằng ngôn ngữ API.
Danh sách kiểm tra triển khai
Sử dụng danh sách kiểm tra này trước khi ra mắt tính năng thanh toán AI cho khách hàng:
- Mỗi yêu cầu AI nhận được một
customer_meter_idđược tạo từ backend. - Lưu lượng không phải production được đánh dấu trước khi đến cổng.
- Ứng dụng tạo ra một
app_request_idổn định cho mỗi hành động AI logic. - Các lần thử lại chia sẻ một ID yêu cầu cha và không bị đếm hai lần theo mặc định.
- Các sự kiện dự phòng ghi lại mô hình được yêu cầu, mô hình đã phục vụ và chính sách thanh toán.
- Nhật ký của cổng hoặc nhà cung cấp có thể được kết hợp trở lại với yêu cầu của ứng dụng.
- Dữ liệu xuất về việc sử dụng và chi phí của nhà cung cấp được lưu giữ ở các cấp độ nhóm hữu ích.
- Một sổ cái sử dụng của khách hàng lưu trữ các hàng có thể tính phí và không thể tính phí.
- Các sự kiện đo lường thanh toán sử dụng các định danh bất biến.
- Bộ phận tài chính có thể xem xét các tổng hợp theo khách hàng, tính năng, mô hình và kỳ.
- Bộ phận hỗ trợ có một mẫu gói tài liệu tranh chấp.
- Việc lưu giữ prompt và completion được giảm thiểu, tách biệt với siêu dữ liệu đo lường.
- Khách hàng có thể xem đủ chi tiết sử dụng để hiểu hóa đơn của họ.
Flatkey phù hợp ở đâu
Flatkey phù hợp khi vấn đề vận hành là quyền truy cập mô hình và sự lan rộng của hóa đơn. Trang web Flatkey công khai hiện tại nhấn mạnh một khóa duy nhất cho các mô hình GPT, Claude, Gemini, DeepSeek, hình ảnh, âm thanh và video, một cổng tương thích OpenAI, phân tích sử dụng và kiểm soát chi phí, nhật ký yêu cầu và một hóa đơn duy nhất cho tất cả các nhà cung cấp. Đó là một nền tảng thực tế cho các đội nhóm muốn có ít tài khoản nhà cung cấp hơn và một bề mặt đánh giá gọn gàng hơn.
Để đo lường việc sử dụng AI theo từng khách hàng, hãy sử dụng Flatkey như một tuyến đường thống nhất nơi lưu lượng AI sản xuất của bạn có thể được xem xét, định giá và quản lý. Lưu giữ bằng chứng thanh toán cấp khách hàng trong sổ cái ứng dụng của riêng bạn trừ khi tài khoản Flatkey hiện tại của bạn hỗ trợ rõ ràng trường, xuất, lưu giữ và quy trình thanh toán chính xác mà bạn cần. Sau đó, đối chiếu hồ sơ sử dụng Flatkey với bản tóm tắt của nhà cung cấp và đồng hồ đo thanh toán của bạn trước khi gửi hóa đơn.
Nếu bạn đang thiết kế mô hình thương mại, hãy kết hợp hướng dẫn này với phân bổ chi phí AI API theo nhóm, chi phí cho mỗi yêu cầu AI API, và đối chiếu hóa đơn AI API. Khi bạn cần thông tin chi tiết về giá cả và gói mô hình hiện tại, hãy sử dụng trang giá của Flatkey.
Câu hỏi thường gặp
Đo lường việc sử dụng AI theo từng khách hàng có giống như ghi nhật ký sử dụng API không?
Không. Ghi nhật ký sử dụng API ghi lại những gì đã xảy ra về mặt kỹ thuật. Đo lường việc sử dụng AI theo từng khách hàng kết nối hoạt động đó với khách hàng, tính năng, kỳ thanh toán, phiên bản định giá và quyết định lập hóa đơn.
Có nên gửi ID khách hàng cho các nhà cung cấp mô hình không?
Thường là không. Sử dụng ID đo lường nội bộ an toàn về quyền riêng tư hoặc siêu dữ liệu cổng khi được hỗ trợ. Tránh gửi email, tên công ty, lời nhắc hoặc dữ liệu cá nhân của người dùng cuối làm định danh thanh toán trừ khi bộ phận pháp lý và quyền riêng tư của bạn phê duyệt rõ ràng.
Các tính năng AI nhúng nên tính phí theo đơn vị nào?
Đơn vị tốt nhất phụ thuộc vào sản phẩm. Token chính xác cho văn bản, yêu cầu dễ hiểu hơn cho khách hàng, giây có thể phù hợp với video hoặc âm thanh và tín dụng có thể chuẩn hóa nhiều phương thức. Dù bạn chọn đơn vị nào, hãy giữ các đơn vị thô của nhà cung cấp trong sổ cái để bộ phận tài chính có thể đối chiếu lợi nhuận.
Nên tính phí cho các lần thử lại và dự phòng như thế nào?
Tính phí cho hành động hợp lý của khách hàng, không phải mọi nỗ lực nội bộ, trừ khi các điều khoản khách hàng của bạn có quy định khác. Lưu giữ bằng chứng thử lại và dự phòng để bộ phận kỹ thuật có thể gỡ lỗi các đợt tăng đột biến chi phí mà không tính phí hai lần cho khách hàng.
Gói bằng chứng khả thi tối thiểu là gì?
Một gói thực tế bao gồm ID đo lường khách hàng, tính năng, dấu thời gian, ID yêu cầu, mô hình hoặc lớp mô hình, đơn vị sử dụng, kỳ thanh toán, phiên bản định giá, ID sự kiện đo lường, trạng thái đối chiếu và quyết định hỗ trợ. Đó là mức tối thiểu để việc đo lường sử dụng AI theo từng khách hàng có thể bảo vệ được.
Đo lường việc sử dụng AI theo từng khách hàng nên làm cho việc thanh toán trở nên nhàm chán. Khi ID khách hàng, đơn vị sử dụng, hồ sơ cổng, chi phí nhà cung cấp và các sự kiện thanh toán được đối chiếu trước khi đóng hóa đơn, các tính năng AI nhúng sẽ trở nên dễ dàng hơn để định giá, giải thích và mở rộng quy mô. Sử dụng Flatkey để đơn giản hóa lớp truy cập mô hình và thanh toán của nhà cung cấp, sau đó duy trì một sổ cái khách hàng mà bộ phận tài chính và hỗ trợ có thể tin cậy. Xem giá.
