Tính chi phí token LLM cho mỗi request

Bài viết này được dịch và biên tập từ bài gốc tiếng Anh trên blog của Modelflare.

Hướng dẫn cho môi trường production: tính chi phí token LLM cho mỗi request. Bài viết gồm một artifact có tính tất định (deterministic), các ranh giới lỗi, những bước kiểm tra khi rollout và các giới hạn có dẫn nguồn rõ ràng.

Quyết định trước tiên

Tính chi phí token LLM cho mỗi request là một hợp đồng production tường minh, không phải một thay đổi code đơn lẻ. Hãy xác định tín hiệu thành công, trạng thái lỗi cuối cùng và điều kiện rollback trước khi chuyển traffic. Artifact dưới đây tách bạch bằng chứng với giả định và giúp truy vết được từng lần thử.

Hãy bắt đầu với usage_source, chứng minh input bằng một case tất định, và coi settlement là một cửa kiểm soát (gate) trước khi release thay vì một việc để làm sau.

Artifact có thể tái sử dụng

Hãy dùng bảng này làm biên bản review. Một dòng chỉ đạt khi bằng chứng của nó đến từ cùng một request, cùng một khung thời gian test hoặc cùng một snapshot cấu hình.

Ví dụ minh họa

Ví dụ này là dữ liệu tổng hợp và có tính tất định. Hãy thay các identifier và threshold bằng những giá trị đã được review từ workload của chính bạn; tuyệt đối không dán secret production hay prompt của khách hàng vào test fixture.

input_tokens = 1200
cache_read_tokens = 800
cache_write_tokens = 0
output_tokens = 300

cost = (input_tokens * input_rate
      + cache_read_tokens * cache_read_rate
      + cache_write_tokens * cache_write_rate
      + output_tokens * output_rate) / 1_000_000

round_at = owned_currency_or_quota_boundary

Quy trình triển khai

1. Đóng băng request, response, cấu hình và baseline quan sát được hiện tại trước khi thay đổi hành vi.
2. Chạy một case positive tất định và lưu lại toàn bộ kết quả mà client nhìn thấy.
3. Chạy case negative hoặc case giới hạn đi kèm để hành vi khi lỗi được chứng minh chứ không phải suy đoán.
4. Gắn mọi lần thử với một request ID logic, sau đó ghi lại timing, trạng thái cuối cùng và usage mà không lưu nội dung nhạy cảm.
5. Rollout qua một nhóm (cohort) có giới hạn với điều kiện dừng rõ ràng; đừng mở rộng traffic chỉ vì happy path đã chạy được.
6. Đọc lại trạng thái đã lưu bền vững và hành vi công khai sau khi thay đổi, và thực hiện kế hoạch rollback đã chuẩn bị nếu có bất kỳ bất biến nào bị vi phạm.

Các kiểu lỗi

Những lỗi sau làm kết quả mất giá trị ngay cả khi HTTP request bên ngoài trông có vẻ thành công:

• Một mức giá provider hoặc danh mục token biến động bị nhúng vào mà không có nguồn, ngày kiểm tra hay bước kiểm tra lại trước khi xuất bản.
• Các request đồng thời vượt qua kiểm tra số dư chỉ đọc và tiêu vượt hạn mức dự kiến vì không có reservation nguyên tử.
• Phần tích hợp chỉ đọc một trường tiện lợi và lặng lẽ bỏ mất các output có kiểu, tool call, từ chối hoặc kết quả một phần.
• Usage dùng chung chưa phân bổ bị dồn vào một team, khiến tổng showback/chargeback không thể đối soát.

Ranh giới khi dùng Modelflare

Một gateway như Modelflare có thể tập trung hóa routing tương thích OpenAI, key, group, bản ghi usage và việc xử lý lỗi, nhưng một route đã được cấu hình không chứng minh rằng mọi upstream đều hỗ trợ mọi trường tùy chọn. Hãy kiểm chứng model và channel đã chọn bằng đường đi của giao thức gốc (native). Quản lý giá của provider theo nguồn giá hiện hành, giữ nguyên các giá trị 0 được khai báo tường minh, và coi kết quả quyết toán cuối cùng đã được lưu bền vững — không phải con số ước tính — là căn cứ tính phí.

Tham khảo bài hướng dẫn gốc để hiểu ranh giới quyết định ở phạm vi rộng hơn, và tài liệu thiết lập cho cấu hình client hiện tại.

Nguồn và ngày kiểm chứng

Các nguồn được kiểm tra vào ngày 2026-08-07. Chúng xác lập hợp đồng bên ngoài hoặc nguyên tắc vận hành; chúng không chứng minh khả năng hỗ trợ trên một route provider chưa được test.

• OpenAI: API pricing
• OpenAI: Prompt caching

Tác giả là đội ngũ phát triển Modelflare, một AI API gateway; nếu bạn muốn dùng nhiều provider qua một API tương thích OpenAI, có thể tham khảo thêm tại https://modelflare.dev.