Hóa đơn OpenAI của bạn cho biết bạn đã chi 4.237 đô la vào tháng trước. Nó không cho bạn biết rằng 3.100 đô la trong số đó đến từ một điểm cuối tóm tắt chạy quá mức, 700 đô la từ một khách hàng đang trả cho bạn 50 đô la mỗi tháng, và 437 đô la từ một tính năng không ai sử dụng. Bảng điều khiển ẩn đi bức tranh bạn cần để đưa ra bất kỳ quyết định nào về giá cả, năng lực hay lộ trình.
Hướng dẫn này chỉ cho bạn cách phân bổ chi phí API OpenAI đúng cách: gắn thẻ mỗi yêu cầu với siêu dữ liệu, tổng hợp chi tiêu theo tính năng, tuyến đường và khách hàng, đặt giới hạn ngân sách theo từng khóa, và thiết kế các lời nhắc để chi phí không còn là một khoản mục bí ẩn. Nếu bạn triển khai các tính năng LLM, đây là công việc biến AI từ một khoản chi phí vượt tầm kiểm soát thành một chi phí sản phẩm được quản lý.
TL;DR
Gắn thẻ mọi cuộc gọi API OpenAI bằng siêu dữ liệu có cấu trúc (tính năng, tuyến đường, customer_id, môi trường), phát ra một dòng nhật ký có cấu trúc cho mỗi yêu cầu ghi lại số lượng token và chi phí tính toán, sau đó tổng hợp theo thẻ trong kho dữ liệu của bạn. Đặt giới hạn ngân sách theo từng khóa trong bảng điều khiển OpenAI, cảnh báo về các bất thường chi tiêu hàng giờ và xác thực trình bao bọc từ đầu đến cuối bằng các kiểm thử kịch bản Apidog trước khi bạn tin vào các con số.
Giới thiệu
Bạn triển khai một tính năng AI mới vào thứ Ba. Đến sáng thứ Sáu, CFO của bạn đã nhắn tin hỏi tại sao khoản chi OpenAI lại tăng 40 phần trăm. Bạn mở bảng điều khiển. Nó cho thấy tổng chi tiêu đang tăng lên. Nó không cho biết tính năng nào, khách hàng nào, hoặc tuyến đường nào chịu trách nhiệm. Bạn bắt đầu đoán mò.
Đây là khoảng trống mà mọi nhóm đang chạy các tác vụ LLM trong môi trường sản xuất đều gặp phải. Giao diện thanh toán của OpenAI được xây dựng cho các khoản phải trả, chứ không phải để phân bổ cho kỹ thuật. Bạn thấy tổng số hàng ngày, phân tích theo mô hình, và thế là hết. Bạn không thấy hình dạng yêu cầu, khách hàng đã kích hoạt nó, hoặc tính năng đã gọi mô hình.
Giải pháp về mặt khái niệm thì đơn giản, nhưng thực hiện lại rất khó khăn. Bạn bọc mỗi cuộc gọi API bằng một lớp siêu dữ liệu. Bạn ghi nhật ký mọi yêu cầu vào một kho lưu trữ có cấu trúc. Bạn tổng hợp theo thẻ. Bạn đặt giới hạn. Bạn cảnh báo về các thay đổi. Đến cuối bài viết này, bạn sẽ có một mô hình dữ liệu cụ thể, hai mẫu mã hoạt động, một quy trình xác minh với Apidog và một so sánh công cụ để bạn có thể quyết định xây dựng, mua, hoặc sử dụng trực tiếp API sử dụng của OpenAI.
Để có bối cảnh định giá thúc đẩy tính toán chi phí của bạn, hãy xem phân tích chi tiết giá GPT-5.5. Đối với một vấn đề phân bổ thanh toán liên quan trong lĩnh vực công cụ phát triển, hãy xem thanh toán sử dụng GitHub Copilot cho các nhóm API. Đối với các kiến thức cơ bản về API OpenAI, hãy xem tài liệu tham khảo API OpenAI chính thức.
Tại sao bảng điều khiển thanh toán của OpenAI lại không đủ
Hãy mở trang thanh toán của OpenAI ngay bây giờ. Bạn sẽ thấy biểu đồ chi tiêu hàng ngày, phân tích theo mô hình và giới hạn sử dụng. Đó là toàn bộ giao diện. Nó hoạt động tốt nếu bạn có một ứng dụng, một khách hàng và một tính năng. Ngay khi bạn có bất kỳ yếu tố nào sau đây: nhiều tính năng trong cùng một sản phẩm, nhiều khách hàng, nhiều môi trường hoặc nhiều nhà phát triển, bảng điều khiển sẽ trở nên vô dụng.
Đây là những gì còn thiếu.
Tổng chi tiêu không có ngữ cảnh. Bảng điều khiển cho bạn biết rằng bạn đã chi 312 đô la ngày hôm qua cho GPT-5.5. Nó không cho bạn biết liệu khoản chi đó đến từ một khách hàng truy cập điểm cuối trò chuyện hỗ trợ của bạn 50.000 lần hay từ một tác vụ nền đã tóm tắt lại toàn bộ cơ sở kiến thức của bạn vì ai đó đã quên tắt một cờ. Cả hai đều trông giống hệt nhau trên biểu đồ.
Không phân tích theo tính năng. OpenAI gắn thẻ các yêu cầu theo khóa API và mô hình. Nó không gắn thẻ chúng theo tính năng, tuyến đường, ID khách hàng hoặc môi trường của bạn. Nếu bạn muốn bất kỳ điều gì trong số đó, bạn phải tự xây dựng. Không có chiều phân tích sản phẩm gốc trong bảng điều khiển.
Độ trễ báo cáo. Dữ liệu sử dụng hiển thị với độ trễ từ vài chục phút đến vài giờ. Đến lúc một vòng lặp chạy quá mức xuất hiện trong bảng điều khiển của bạn, nó đã đốt cháy một thẻ tín dụng rồi. Bạn cần theo dõi thời gian thực, chứ không phải một biểu đồ lịch sử.
Không có cơ chế cảnh báo cơ bản. OpenAI cung cấp cho bạn một giới hạn ngân sách cho mỗi tổ chức và một email thông báo mềm. Không có cảnh báo theo từng khóa, không có ngưỡng theo từng tính năng, không có phát hiện bất thường. Nếu bạn muốn “thông báo cho tôi nếu điểm cuối trò chuyện vượt quá 50 đô la trong một giờ,” bạn phải tự xây dựng.
Không phân bổ theo khách hàng. Nếu bạn bán B2B SaaS với một tính năng AI, bạn cần biết khách hàng nào đã tạo ra chi phí nào để bạn có thể định giá, điều tiết hoặc bán thêm. Bảng điều khiển không thể trả lời câu hỏi “khách hàng X đang tốn của tôi bao nhiêu trong tháng này.” Đội ngũ tài chính của bạn cần con số đó để tính toán tỷ suất lợi nhuận gộp trên mỗi khách hàng. Nếu không có nó, kinh tế đơn vị của bạn chỉ là phỏng đoán.
Tài khoản dịch vụ và khóa cấp dự án có ích, nhưng chỉ một phần. Các khóa dự án của OpenAI cho phép bạn phân chia việc sử dụng theo dự án. Điều đó mang lại cho bạn một cấp độ phân bổ. Nó không mang lại cho bạn phân bổ theo tính năng, theo khách hàng hoặc theo tuyến đường. Bạn vẫn cần siêu dữ liệu cấp ứng dụng để trả lời các câu hỏi quan trọng. API sử dụng của OpenAI trả về dữ liệu tổng hợp theo dự án, không theo yêu cầu.
Mô hình này lặp lại ở mọi nhóm triển khai các tính năng LLM ở quy mô lớn. Chủ đề Dev.to “OpenAI Tells You What You Spent. Not Where. So I Built a Dashboard” (OpenAI cho bạn biết bạn đã chi bao nhiêu. Không phải ở đâu. Vì vậy tôi đã xây dựng một bảng điều khiển) đã lan truyền rộng rãi vì nó đã nói thẳng vấn đề: bạn không thể quản lý những gì bạn không thể đo lường. Bảng điều khiển gốc trả lời một câu hỏi tài chính. Bạn cần trả lời một câu hỏi sản phẩm.
Mô hình dữ liệu phân bổ chi phí
Phân bổ chi phí bắt đầu bằng một quyết định: mỗi yêu cầu OpenAI sẽ nhận được một sự kiện được gắn thẻ và ghi vào kho dữ liệu của bạn. Sự kiện đó là đơn vị phân tích của bạn. Thiết lập đúng schema và phần còn lại của công việc, bảng điều khiển, cảnh báo, giới hạn, sẽ trở thành một truy vấn SQL.
Đây là schema tối thiểu bạn cần.
| Cột | Kiểu | Ví dụ | Tại sao nó quan trọng |
|---|---|---|---|
request_id |
uuid | 7a91... |
Tính toàn vẹn, loại bỏ trùng lặp, thử lại |
timestamp |
timestamptz | 2026-05-06T14:23:01Z |
Truy vấn chuỗi thời gian, phát hiện bất thường |
feature |
text | support-chat |
Giao diện sản phẩm đã kích hoạt cuộc gọi |
route |
text | /api/v1/chat/answer |
Tuyến HTTP hoặc ID tác vụ nền |
customer_id |
text | cust_4291 |
Chi tiêu trên mỗi khách hàng, tỷ suất lợi nhuận gộp |
environment |
text | prod, staging, dev |
Giữ chi phí phát triển tách biệt khỏi phân bổ khách hàng |
model |
text | gpt-5.5, gpt-5.4-mini |
Giá khác nhau tùy theo mô hình |
prompt_tokens |
int | 15234 |
Số lượng token đầu vào từ phản hồi |
completion_tokens |
int | 812 |
Số lượng token đầu ra từ phản hồi |
reasoning_tokens |
int | 4500 |
Token suy luận (được tính là thanh toán đầu ra) |
cached_tokens |
int | 12000 |
Lượt truy cập bộ nhớ cache lời nhắc, tính phí 50 phần trăm |
latency_ms |
int | 2341 |
Để tương quan chi phí với trải nghiệm người dùng |
cost_usd |
numeric(10,6) | 0.045672 |
Tính toán tại thời điểm ghi từ số lượng token |
prompt_cache_key |
text | system-v3 |
Theo dõi tỷ lệ truy cập bộ nhớ cache trên mỗi tính năng |
error_code |
text | null, 429 |
Để bạn không tính trùng khi thử lại |
Tính toán chi phí tại thời điểm ghi, không phải tại thời điểm truy vấn. Giá cả thay đổi; bạn muốn một con số cố định phản ánh tỷ lệ bạn đã trả vào ngày yêu cầu xảy ra. Logic tính toán cho GPT-5.5 trông như sau:
PRICING = { # USD per 1M tokens, as of May 2026
"gpt-5.5": {"input": 5.00, "cached": 2.50, "output": 30.00},
"gpt-5.5-pro": {"input": 30.00, "cached": 15.00, "output": 180.00},
"gpt-5.4": {"input": 2.50, "cached": 1.25, "output": 15.00},
"gpt-5.4-mini": {"input": 0.25, "cached": 0.125, "output": 2.00},
}
def compute_cost_usd(model, prompt_tokens, cached_tokens, completion_tokens, reasoning_tokens):
rates = PRICING[model]
uncached = max(0, prompt_tokens - cached_tokens)
input_cost = (uncached * rates["input"]) / 1_000_000
cache_cost = (cached_tokens * rates["cached"]) / 1_000_000
output_cost = ((completion_tokens + reasoning_tokens) * rates["output"]) / 1_000_000
return round(input_cost + cache_cost + output_cost, 6)
Token suy luận được tính là đầu ra. API OpenAI trả về chúng trong usage.completion_tokens_details.reasoning_tokens, nhưng chúng được tính phí theo tỷ lệ đầu ra. Bỏ qua điều này và bạn sẽ tính thiếu chi phí trên mỗi cuộc gọi chế độ Thinking. Để biết toán học định giá đầy đủ, hãy xem phân tích chi tiết giá GPT-5.5.
Bây giờ hãy bọc client OpenAI. Mọi cuộc gọi đều đi qua một hàm. Hàm đó lấy siêu dữ liệu, tạo yêu cầu và ghi sự kiện.
import time, uuid, json, logging
from openai import OpenAI
client = OpenAI()
logger = logging.getLogger("llm.cost")
def call_with_attribution(
*, feature, route, customer_id, environment,
model, messages, **openai_kwargs
):
request_id = str(uuid.uuid4())
started = time.time()
error_code = None
response = None
try:
response = client.chat.completions.create(
model=model, messages=messages, **openai_kwargs
)
except Exception as e:
error_code = getattr(e, "code", "unknown_error")
raise
finally:
latency_ms = int((time.time() - started) * 1000)
u = response.usage if response else None
prompt_tokens = getattr(u, "prompt_tokens", 0)
completion_tokens = getattr(u, "completion_tokens", 0)
cached_tokens = getattr(getattr(u, "prompt_tokens_details", None), "cached_tokens", 0) or 0
reasoning_tokens = getattr(getattr(u, "completion_tokens_details", None), "reasoning_tokens", 0) or 0
cost_usd = compute_cost_usd(model, prompt_tokens, cached_tokens, completion_tokens, reasoning_tokens)
logger.info(json.dumps({
"event": "openai.request",
"request_id": request_id,
"feature": feature,
"route": route,
"customer_id": customer_id,
"environment": environment,
"model": model,
"prompt_tokens": prompt_tokens,
"completion_tokens": completion_tokens,
"reasoning_tokens": reasoning_tokens,
"cached_tokens": cached_tokens,
"latency_ms": latency_ms,
"cost_usd": cost_usd,
"error_code": error_code,
}))
return response
Trình bao bọc duy nhất đó là bề mặt phân bổ chi phí của bạn. Mọi tính năng trong sản phẩm của bạn đều gọi nó. Dòng nhật ký có cấu trúc là đầu vào kho dữ liệu của bạn. Từ đây, hãy gửi nhật ký đến BigQuery, ClickHouse, Snowflake hoặc Postgres thông qua hệ thống đường ống nhật ký hiện có của bạn (Vector, Fluent Bit, Logstash, OTLP collector). Không có đường ống thứ hai. Không có dịch vụ bổ sung.
Đối với các nhóm Node.js, hình dạng là tương tự. Bọc SDK OpenAI trong một hàm nhận siêu dữ liệu, ghi lại response.usage, tính toán chi phí và ghi một dòng JSON. Nếu nền tảng của bạn đã chạy một bus sự kiện (Kafka, NATS, Pub/Sub), hãy xuất bản sự kiện đó thay vì stdout và để các consumer hạ nguồn phân phối nó đến kho dữ liệu và hệ thống cảnh báo của bạn.
Kết nối theo dõi chi phí và kiểm thử bằng Apidog
Bạn đã có schema và trình bao bọc. Bây giờ hãy biến nó thành một cái gì đó có thể vận hành. Sáu bước.
1. Thay thế các cuộc gọi OpenAI trực tiếp bằng trình bao bọc. Tìm kiếm trong codebase của bạn các chuỗi OpenAI( và client.chat.completions.create. Mỗi lần tìm thấy sẽ trở thành một cuộc gọi call_with_attribution(...). Đặt feature và route làm đối số bắt buộc. Truyền chúng tại điểm gọi, không phải từ một biến toàn cục. Nếu bạn quên truyền chúng, hàm phải báo lỗi, chứ không phải mặc định là “unknown.”
2. Phát ra nhật ký có cấu trúc. Ghi nhật ký ra stdout dưới dạng JSON, mỗi dòng một sự kiện. Đặt mức độ nhật ký thành INFO cho riêng các sự kiện này. Đừng xen kẽ chúng với các thông báo debug ồn ào. Nếu bạn đã sử dụng một trình ghi nhật ký có cấu trúc (structlog, pino, winston), hãy kết nối nó vào đó.
3. Tổng hợp theo tính năng trong kho dữ liệu của bạn. Một khi các sự kiện được đưa vào BigQuery hoặc ClickHouse, các truy vấn sẽ tự được viết:
SELECT
feature,
DATE_TRUNC(timestamp, DAY) AS day,
COUNT(*) AS requests,
SUM(cost_usd) AS spend_usd,
SUM(prompt_tokens + completion_tokens) AS tokens,
AVG(latency_ms) AS avg_latency_ms,
SUM(cached_tokens) / NULLIF(SUM(prompt_tokens), 0) AS cache_hit_rate
FROM openai_events
WHERE environment = 'prod'
AND timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
GROUP BY feature, day
ORDER BY day DESC, spend_usd DESC;
4. Biểu đồ chi tiêu theo tuyến đường. Trỏ Grafana, Metabase, Looker hoặc Superset vào bảng. Xây dựng ba chế độ xem: chi tiêu theo tính năng theo thời gian, chi tiêu theo khách hàng theo thời gian, và bảng top 20 tuyến đường được sắp xếp theo chi tiêu của ngày hôm qua. Đó là bảng điều khiển hoạt động hàng ngày của bạn.
5. Kiểm thử trình bao bọc với Apidog trước khi triển khai. Đây là bước mà hầu hết các nhóm bỏ qua và hối tiếc. Trình bao bọc của bạn ghi nhật ký có cấu trúc. Nếu schema sai, kho dữ liệu của bạn cũng sẽ sai một cách lặng lẽ, và các bảng điều khiển sẽ đưa ra thông tin sai lệch. Sử dụng Apidog để chạy các kiểm thử end-to-end đối với dịch vụ của bạn:
- Tạo một kịch bản trong Apidog gửi yêu cầu đến điểm cuối AI của bạn với
customer_idvàfeatuređã biết. - Ghi lại phản hồi và đầu ra nhật ký kênh phụ (stdout, OTLP, điểm cuối nhật ký của bạn).
- Sử dụng các khẳng định phản hồi của Apidog để xác minh tải trọng nhật ký chứa
feature,route,customer_idmong muốn, vàcost_usd > 0vàprompt_tokens > 0. - Chạy cùng một kịch bản trên các môi trường staging và prod bằng cách sử dụng các biến môi trường của Apidog.
- Phát lại các yêu cầu được gắn thẻ và khẳng định rằng các cuộc gọi được thử lại không tính chi phí hai lần (trình bao bọc của bạn nên sử dụng lại
request_idkhi thử lại).
Đối với các phương pháp kiểm thử API rộng hơn phù hợp với bước xác minh này, hãy xem công cụ kiểm thử API cho kỹ sư QA. Đối với phương pháp contract-first đi kèm với việc bao phủ phân bổ chi phí, hãy xem phát triển API theo hợp đồng trước.
6. Đặt giới hạn ngân sách và cảnh báo theo từng khóa. OpenAI cho phép bạn tạo một khóa dự án cho mỗi môi trường hoặc mỗi tính năng. Hãy sử dụng nó. Tạo khóa prod-support-chat, khóa prod-summarization, khóa staging-all. Đặt giới hạn cứng trong bảng điều khiển OpenAI để một vòng lặp chạy quá mức trên một tính năng không thể làm cạn kiệt toàn bộ ngân sách tổ chức. Thêm lớp cảnh báo của riêng bạn lên trên: một truy vấn SQL chạy mỗi 10 phút và thông báo cho bạn nếu bất kỳ tính năng nào vượt quá 3 lần mức chi tiêu trung bình hàng giờ trong 7 ngày của nó. PagerDuty, Opsgenie hoặc một webhook Slack đều hoạt động; trình kích hoạt đến từ kho dữ liệu của bạn, không phải từ OpenAI.
Sự kết hợp giữa giới hạn khóa gốc và cảnh báo dựa trên kho dữ liệu mang lại cho bạn hai lớp phòng thủ. Giới hạn gốc là một rào cản chống lại việc đốt cháy chi phí thảm khốc. Cảnh báo từ kho dữ liệu sẽ phát hiện sự tăng trưởng chậm trước khi giới hạn bị kích hoạt.
Các kỹ thuật nâng cao và mẹo chuyên nghiệp
Khi đường ống cơ bản đang chạy, các tối ưu hóa sẽ theo sau.
Lưu trữ lời nhắc (Prompt caching). GPT-5.5 tính phí 50 phần trăm tỷ lệ đầu vào cho các token được lưu trong bộ nhớ cache. Cấu trúc lời nhắc hệ thống của bạn dưới dạng tiền tố ổn định và đặt các biến theo yêu cầu ở cuối. Tỷ lệ truy cập bộ nhớ cache trên 70 phần trăm đối với các tác vụ trò chuyện là bình thường khi bạn thực hiện điều này. Theo dõi cache_hit_rate cho mỗi tính năng trong bảng điều khiển của bạn để bạn có thể thấy khi nào một thay đổi lời nhắc làm giảm tỷ lệ truy cập của bạn. Tài liệu chính thức về lưu trữ lời nhắc của OpenAI bao gồm các quy tắc đủ điều kiện.
Batch API cho công việc ngoại tuyến. Bất cứ thứ gì không cần phản hồi đồng bộ đều đi qua Batch API để được giảm giá 50 phần trăm. Tóm tắt hàng đêm, chạy đánh giá, điền lại nhúng, xử lý lại tài liệu. Trình bao bọc chi phí vẫn được áp dụng; gọi điểm cuối Batch và gắn thẻ các sự kiện với batch_job_id để bạn có thể phân bổ chúng trở lại tác vụ nguồn.
Điều chỉnh mức độ nỗ lực suy luận (Reasoning effort tuning). GPT-5.5 Thinking là cùng một mô hình ở mức reasoning.effort cao hơn. Mỗi cấp độ nỗ lực nhân lên số lượng token đầu ra. Kiểm tra các tính năng của bạn: bạn có đang chạy medium trong khi low đã đạt tiêu chuẩn chất lượng không? Chạy thử nghiệm A/B, theo dõi chất lượng và chi phí, triển khai tùy chọn rẻ hơn nếu chất lượng được duy trì. Để biết toán học chuyên sâu hơn, hãy xem cách sử dụng API GPT-5.5.
Kỷ luật cửa sổ ngữ cảnh (Context-window discipline). Các lời nhắc dài rất tốn kém. RAG với ngân sách truy xuất chặt chẽ tốt hơn việc nhồi nhét toàn bộ cơ sở kiến thức vào cửa sổ ngữ cảnh. Theo dõi số lượng prompt_tokens trung bình cho mỗi tính năng; nếu nó tăng lên hàng tuần mà không có thay đổi tính năng, lời nhắc của bạn đang bị phình to.
Theo dõi giới hạn 272K token của GPT-5.5. OpenAI áp dụng hệ số nhân đầu vào 2 lần và hệ số nhân đầu ra 1.5 lần đối với các yêu cầu trên 272K token. Thêm một bộ bảo vệ trong trình bao bọc của bạn để ghi lại cảnh báo khi prompt_tokens > 250000 để bạn có thể phát hiện các lời nhắc sắp chạm đến giới hạn này. Để biết chi tiết về giá, hãy xem bài viết về giá GPT-5.5.
Giới hạn chi tiêu theo từng khách hàng. Nếu bạn bán B2B và hợp đồng của bạn bao gồm một tính năng được hỗ trợ bởi LLM, bạn cần một giới hạn theo từng khách hàng. Tính toán chi tiêu luân phiên trên mỗi customer_id từ kho dữ liệu của bạn và yêu cầu ứng dụng của bạn kiểm tra nó trước mỗi cuộc gọi. Nếu giới hạn bị đạt, trả về mã 429 với thông báo “quota AI hàng tháng đã vượt quá” và một CTA thanh toán. Đây là điều biến các tính năng AI từ rủi ro lợi nhuận thành sản phẩm có lợi nhuận.
Những lỗi phổ biến cần tránh.
- Đếm token suy luận là đầu vào. Chúng là đầu ra. Tính phí chúng theo tỷ lệ đầu ra.
- Tin tưởng bảng điều khiển OpenAI cho các quyết định thời gian thực. Nó có độ trễ. Hãy sử dụng kho dữ liệu của riêng bạn.
- Gắn thẻ ở cấp SDK thay vì tại điểm gọi. Các thẻ thuộc về tính năng, không thuộc về client.
- Quên gắn thẻ các tác vụ nền. Các tác vụ cron, worker hàng đợi và webhook thực hiện các cuộc gọi OpenAI tương tự; gắn thẻ chúng bằng một
routetổng hợp nhưcron:nightly-summarizehoặcqueue:image-caption. - Lấy mẫu. Đừng lấy mẫu. Ghi nhật ký mọi yêu cầu. Khối lượng dữ liệu không đáng kể; độ chính xác phân bổ thì không.
- Để
customer_idlà null. Nếu bạn không biết khách hàng, hãy ghi nhật kýinternalhoặcsystem, không bao giờ là null. Null trở thành một lỗ đen phân bổ.
Các lựa chọn thay thế và công cụ
Bạn không nhất thiết phải tự xây dựng điều này. Dưới đây là so sánh trung thực.
| Phương pháp | Ưu điểm | Chi phí | Khi nào nên dùng |
|---|---|---|---|
| OpenAI usage API | Bản địa, không cần thiết lập, chính xác đến từng cent | Miễn phí | Một dự án, một tính năng, không phân bổ theo khách hàng |
| Helicone | Proxy dễ dàng tích hợp, bảng điều khiển, bộ nhớ đệm, chi phí theo người dùng | Gói miễn phí; trả phí từ 20 đô la/tháng | Muốn bảng điều khiển được host nhanh chóng, chấp nhận proxy trong đường dẫn |
| Langfuse | Mã nguồn mở, tự host hoặc trên đám mây, dấu vết + chi phí | Tự host miễn phí; đám mây từ 29 đô la/tháng | Muốn dấu vết và chi phí trong một công cụ, ưu tiên mã nguồn mở |
| LangSmith | Tích hợp chặt chẽ LangChain, đánh giá + chi phí | Trả phí từ 39 đô la/người dùng/tháng | Đã sử dụng LangChain, muốn một nhà cung cấp |
| Custom warehouse | Kiểm soát hoàn toàn, phù hợp với hệ thống hiện có của bạn, không cần proxy | Thời gian kỹ thuật | Tác vụ lớn, kích thước tùy chỉnh, yêu cầu nghiêm ngặt về vị trí dữ liệu |
Những đánh đổi cần lưu ý. Một proxy (Helicone) thêm một bước nhảy vào đường dẫn quan trọng của bạn; chi phí độ trễ nhỏ nhưng có thật, và bạn phụ thuộc vào khả năng sẵn sàng của họ. Một ngăn xếp quan sát tự host (Langfuse) cho phép bạn kiểm soát hoàn toàn nhưng bạn phải vận hành nó. Đường dẫn kho dữ liệu tùy chỉnh là nơi hầu hết các nhóm lớn kết thúc; nó tích hợp với phần còn lại của ngăn xếp dữ liệu của bạn, nhưng bạn tự viết các truy vấn và cảnh báo. API sử dụng gốc vẫn ổn nếu nhu cầu của bạn đơn giản, nhưng sẽ trở nên vô dụng khi chúng không còn đơn giản nữa.
Để đọc sâu hơn về việc quan sát chi phí LLM hiệu quả trông như thế nào trong thực tế, hướng dẫn của nhóm Helicone về theo dõi chi phí LLM trình bày chi tiết phương pháp dựa trên proxy. Tài liệu Langfuse về theo dõi chi phí đề cập đến con đường mã nguồn mở.
Nếu bạn vận hành điều này ở quy mô nền tảng, các mô hình sẽ được tổng quát hóa. Hãy xem nền tảng API cho kiến trúc microservices để biết cách các trình bao bọc phân bổ chi phí phù hợp với chiến lược service mesh.
Các trường hợp sử dụng thực tế
SaaS B2B với chi tiêu LLM trên mỗi khách hàng. Một công ty bán sản phẩm thông minh về bán hàng. Mỗi khách hàng kích hoạt các cuộc gọi GPT-5.5 khi họ yêu cầu một bản tóm tắt. Nếu không có phân bổ, công ty biết mình chi 80.000 đô la mỗi tháng cho OpenAI. Với phân bổ theo từng khách hàng, họ nhận ra rằng 12 phần trăm khách hàng tạo ra 71 phần trăm chi tiêu. Công ty giới thiệu giá theo cấp bậc, hạn ngạch mềm cho cấp thấp nhất và phí vượt quá cho mỗi chỗ ngồi. Tỷ suất lợi nhuận gộp trên tính năng AI chuyển từ 41 phần trăm lên 73 phần trăm trong một quý.
Theo dõi công cụ dành cho nhà phát triển nội bộ. Một tổ chức kỹ thuật cấp cho mỗi nhà phát triển quyền truy cập vào trợ lý trò chuyện GPT-5.5 riêng. Với các thẻ theo nhà phát triển (customer_id trở thành dev_email), kỹ thuật nền tảng thấy rằng ba nhà phát triển chiếm 50 phần trăm chi tiêu nội bộ. Hai trong số họ đang chạy các vòng lặp tác nhân tự động mà họ quên tắt. Tắt chúng giúp tiết kiệm 1.800 đô la mỗi tháng. Người thứ ba đang thực hiện công việc hợp pháp; dữ liệu chứng minh cho một hạn ngạch toàn tổ chức cao hơn cho họ.
Dự báo chi tiêu tính năng AI. Một nhóm sản phẩm muốn triển khai một tính năng tóm tắt mới. Quản lý sản phẩm không biết cách dự báo chi phí. Với dữ liệu lịch sử theo tính năng, nhóm xây dựng một mô hình: số token lời nhắc trung bình trên mỗi cuộc gọi, số token đầu ra trung bình, số cuộc gọi dự kiến trên mỗi người dùng hoạt động, số người dùng hoạt động dự kiến. Dự báo trả về: 0,04 đô la trên mỗi người dùng hoạt động mỗi ngày, hoặc 1,20 đô la mỗi tháng. Nhóm định giá đặt giá tính năng ở mức 5 đô la trên mỗi người dùng mỗi tháng. Bộ phận tài chính chấp thuận vì kinh tế đơn vị đã rõ ràng.
Kết luận
Bạn không thể quản lý những gì bạn không thể đo lường. Bảng điều khiển thanh toán của OpenAI trả lời một câu hỏi tài chính. Việc phân bổ theo tính năng, theo khách hàng, theo tuyến đường trả lời câu hỏi sản phẩm. Xây dựng trình bao bọc, ghi nhật ký sự kiện, truy vấn kho dữ liệu, và dòng AI của bạn sẽ không còn là một bí ẩn.
Năm điểm rút ra:
- Gắn thẻ mọi yêu cầu với tính năng, tuyến đường, customer_id và môi trường. Đặt các thẻ là bắt buộc tại điểm gọi.
- Tính toán chi phí tại thời điểm ghi để dữ liệu lịch sử phản ánh tỷ lệ bạn đã trả vào ngày đó.
- Sử dụng một khóa dự án cho mỗi môi trường và đặt giới hạn cứng trong bảng điều khiển OpenAI như một biện pháp dự phòng.
- Thêm lớp cảnh báo dựa trên kho dữ liệu lên trên các giới hạn gốc để bạn phát hiện sự tăng trưởng chậm trước khi giới hạn bị kích hoạt.
- Kiểm thử trình bao bọc với Apidog trước khi triển khai; các thẻ xấu có nghĩa là lỗi phân bổ ngầm.
- Kiểm tra nỗ lực suy luận và kích thước lời nhắc hàng quý; tối ưu hóa rẻ nhất là tối ưu hóa giữ chất lượng ổn định.
- Theo dõi tỷ lệ truy cập bộ nhớ cache trên mỗi tính năng để thay đổi lời nhắc không làm tăng gấp đôi chi phí đầu vào của bạn một cách thầm lặng.
Tải Apidog và sử dụng nó để xác minh trình bao bọc phân bổ chi phí của bạn từ đầu đến cuối. Điều khiển các điểm cuối AI của bạn bằng các yêu cầu được gắn thẻ, khẳng định hình dạng tải trọng nhật ký và phát lại các kịch bản trên các môi trường để dữ liệu mà kho dữ liệu của bạn tin cậy chính là dữ liệu mà các kỹ sư của bạn đã viết.
Để đọc thêm về quản lý chi phí liên quan, hãy xem phân tích chi tiết giá GPT-5.5 và thanh toán sử dụng GitHub Copilot cho các nhóm API.
Câu hỏi thường gặp
Token suy luận có được tính là đầu vào hay đầu ra để thanh toán không?Token suy luận được tính phí theo tỷ lệ đầu ra. API OpenAI trả về chúng dưới usage.completion_tokens_details.reasoning_tokens. Hãy thêm chúng vào completion_tokens khi bạn tính toán chi phí. Để biết các hệ số nhân theo mức độ nỗ lực, hãy xem phân tích chi tiết giá GPT-5.5.
Độ chính xác của response.usage so với bảng điều khiển OpenAI như thế nào?Số lượng token trong response.usage khớp với bảng điều khiển từng token. Thay đổi giá có thể gây ra sai lệch nhỏ nếu bạn tính toán chi phí từ bảng giá cũ; hãy cố định tỷ lệ cho mỗi mô hình và cập nhật nó vào ngày OpenAI thay đổi giá.
Tôi có thể phân bổ chỉ với các khóa dự án OpenAI không?Các khóa dự án cung cấp cho bạn một chiều phân bổ: theo dự án. Chúng không cung cấp cho bạn phân bổ theo tính năng, theo khách hàng hoặc theo tuyến đường. Sử dụng các khóa dự án để phân chia môi trường và giới hạn ngân sách; sử dụng siêu dữ liệu cấp ứng dụng cho mọi thứ khác.
Còn về việc thử lại và lỗi giới hạn tỷ lệ thì sao? Chúng có tính chi phí hai lần không?Một yêu cầu thất bại trước khi mô hình chạy (lỗi 4xx, lỗi mạng trước khi hoàn thành) không trả về đối tượng usage, vì vậy không có chi phí nào được ghi nhật ký. Một yêu cầu thành công và sau đó được thử lại ở lớp ứng dụng sẽ được ghi nhật nhật ký hai lần trừ khi bạn sử dụng lại request_id. Các lần thử lại idempotent nên truyền cùng request_id và trình bao bọc của bạn nên loại bỏ trùng lặp khi ghi.
API sử dụng của OpenAI trả về dữ liệu nhanh đến mức nào?API sử dụng có độ trễ vài chục phút. Đối với các quyết định thời gian thực (cảnh báo, công tắc ngắt), hãy sử dụng kho dữ liệu của riêng bạn. Đối với đối chiếu hàng tháng, API sử dụng vẫn ổn và khớp với hóa đơn thanh toán của bạn.
Tôi có nên lấy mẫu các yêu cầu để giảm khối lượng nhật ký không?Không. Khối lượng dữ liệu nhỏ (một dòng JSON cho mỗi yêu cầu), và việc lấy mẫu làm hỏng phân bổ theo khách hàng và theo tuyến đường. Hãy ghi nhật ký mọi yêu cầu.
Tôi có thể sử dụng phương pháp này cho các nhà cung cấp LLM khác không?Có. Schema có thể tổng quát hóa. Thêm cột provider (openai, anthropic, google, deepseek) và một bảng giá cho mỗi nhà cung cấp. Trình bao bọc là cụ thể cho từng nhà cung cấp; kho dữ liệu và bảng điều khiển thì không. Để so sánh, hãy xem giá API DeepSeek V4.
Điều này có hoạt động cho các cuộc gọi nhúng (embeddings) và tạo hình ảnh không?Có, với toán học chi phí cụ thể cho từng nhà cung cấp. Nhúng được tính phí trên mỗi token đầu vào theo một mức giá cố định; hình ảnh được tính phí trên mỗi hình ảnh theo tỷ lệ độ phân giải. Thêm endpoint (ví dụ: chat, embeddings, image) vào schema và phân nhánh tính toán chi phí của bạn dựa trên nó.