Token và chi phí API mô hình lớn: Ước lượng, đọc, ngân sách và ví dụ

Token là gì và cách tính phí

Token là đơn vị đo lường nhỏ nhất để mô hình xử lý văn bản, không phải ký tự hay từ, mà là “mảnh vỡ” nằm giữa hai khái niệm đó. Bạn có thể hình dung nó như các vạch chia trên đồng hồ nước: bạn dùng càng nhiều, vạch chạy càng nhanh. Việc tính phí chia làm hai phần:

Lưu ý: giá đơn vị đầu ra gấp bốn lần đầu vào, nên khiến mô hình “nói ít lời thừa” thường tiết kiệm hơn so với việc bạn “gửi ít ngữ cảnh hơn”, dù trong hội thoại, đầu vào có thể phình to do tích lũy lịch sử và bạn cần quản lý cả hai. Hình thức thanh toán là số dư trả trước, không phải đăng ký; số dư không bao giờ hết hạn; tài khoản mới có $0.50 tín dụng dùng thử, có hiệu lực trong 7 ngày.

Một điểm dễ nhầm lẫn: token đầu ra là số lượng mô hình thực sự tạo ra, không phải max_tokens bạn đặt. max_tokens chỉ là giới hạn trên; nếu mô hình trả lời xong ở 200 từ, bạn chỉ trả phí cho token tương ứng với 200 từ đó. Tuy nhiên, khi dự toán ngân sách, bạn nên tính theo giới hạn trên để chuẩn bị cho trường hợp xấu nhất, tránh bị bất ngờ bởi các đầu ra dài bất thường.

Ước lượng trước: Cách ước lượng tiếng Trung và tiếng Anh

Chưa gửi yêu cầu thì chỉ có thể ước lượng. Các giá trị dưới đây chỉ là xấp xỉ, có thể dao động tùy nội dung:

Cách dùng đúng của ước lượng là “xác định bậc độ lớn”: bài viết này khoảng 10.000 hay 100.000 token, có vượt quá cửa sổ ngữ cảnh 100.000 token không, một lần gọi API tốn khoảng bao nhiêu xu. Để chính xác, hãy đọc usage. Một thói quen tốt là lấy mẫu chạy thử hàng chục lần cho từng kịch cảnh kinh doanh, thống kê giá trị trung bình của usage và dùng nó thay cho giá trị kinh nghiệm.

Ví dụ kết hợp ước lượng và đo thực tế. Giả sử bạn cần xử lý một lô phản hồi khách hàng bằng tiếng Trung khoảng 2000 ký tự, ước lượng sơ bộ với 1.3 token/ký tự, mỗi yêu cầu khoảng 2600 token, cộng với prompt của bạn là 200 token, tổng đầu vào khoảng 2800. Hãy chọn 30 yêu cầu để chạy thử, đọc usage và lấy giá trị trung bình. Giả sử giá trị trung bình thực tế là 2500, bạn hãy điều chỉnh hệ số ước lượng của mình xuống còn khoảng 1.15. Sau đó, ngân sách cho toàn bộ lô sẽ được tính dựa trên hệ số đã điều chỉnh, sai số sẽ nhỏ hơn nhiều. Con số thực tế này chỉ là giả định để minh họa phương pháp, dữ liệu của bạn sẽ có giá trị riêng.

Đọc usage: “Số đồng hồ điện” thực sự

Mỗi phản hồi thành công đều chứa usage, bao gồm prompt_tokens, completion_tokens và total_tokens. Phản hồi truyền phát không cần tham số bổ sung; khối dữ liệu chứa usage sẽ tự động được thêm vào ở cuối. Mã dưới đây minh họa cả hai cách đọc và chuyển đổi các giá trị sang USD:

复制import os
from openai import OpenAI

client = OpenAI(base_url="https://api.apidamoxing.com/v1", api_key=os.environ["API_KEY"])
PRICE_IN, PRICE_OUT = 0.25, 1.00     # 美元 / 百万 token

def cost(u):
    return (u.prompt_tokens * PRICE_IN + u.completion_tokens * PRICE_OUT) / 1_000_000

# 非流式：usage 在响应对象上
r = client.chat.completions.create(
    model="uncensored", max_tokens=200,
    messages=[{"role": "user", "content": "用三句话解释什么是通货膨胀。"}],
)
print(r.usage.prompt_tokens, r.usage.completion_tokens, f"${cost(r.usage):.6f}")

# 流式：最后一个数据块带 usage，其余块的 usage 为空
usage_last = None
stream = client.chat.completions.create(
    model="uncensored", max_tokens=200, stream=True,
    messages=[{"role": "user", "content": "再用三句话解释什么是通货紧缩。"}],
)
for chunk in stream:
    if chunk.usage:
        usage_last = chunk.usage
    if chunk.choices and chunk.choices[0].delta.content:
        print(chunk.choices[0].delta.content, end="", flush=True)
print()
if usage_last:
    print(usage_last.prompt_tokens, usage_last.completion_tokens, f"${cost(usage_last):.6f}")

Khi dùng streaming, hãy lưu ý: chỉ có khối cuối cùng chứa usage, các khối trước đó trường này trống, vì vậy bạn chỉ cần dùng if chunk.usage để kiểm tra. Hãy ghi lại số đọc của mỗi lần vào nhật ký hoặc cơ sở dữ liệu, cuối tháng đối chiếu hóa đơn, kiểm tra bất thường và tính chi phí cho mỗi người dùng đều dựa vào bản ghi này.

Một thói quen đáng rèn luyện nữa là gắn nhãn cho từng chức năng kinh doanh và ghi chép chi phí cùng nhãn đó. Ví dụ: ghi riêng cho “tóm tắt”, “hỗ trợ khách hàng”, “dịch thuật”. Cuối tháng đối chiếu, bạn sẽ biết chính xác chức năng nào tốn kém nhất, từ đó biết nên tối ưu prompt, cắt giảm lịch sử hay giảm max_tokens. Nếu không có nhãn, chỉ có một tổng số, bạn sẽ khó biết bắt đầu tối ưu từ đâu.

Ba ví dụ (các giả định đã được nêu rõ)

Ví dụ 1: Hỏi đáp dịch vụ khách hàng

Giả định: Mỗi yêu cầu đầu vào 800 token (bao gồm system và đoạn kiến thức), đầu ra 200 token; 10.000 lần mỗi ngày.

Chi phí mỗi lần: 800 × 0,25 ÷ 1.000.000 = $0,0002, đầu ra 200 × 1,00 ÷ 1.000.000 = $0,0002, tổng cộng $0,0004. Mỗi ngày $4,00, 30 ngày $120. Với tốc độ này, số dư dùng thử $0,50 có thể hỗ trợ khoảng 1.250 lần gọi như vậy.

Ví dụ 2: Tóm tắt bài viết dài

Giả định: Mỗi bài viết đầu vào 20.000 token, tóm tắt đầu ra 600 token; tổng cộng 500 bài.

Mỗi bài: 20.000 × 0,25 ÷ 1.000.000 = $0,005, cộng 600 × 1,00 ÷ 1.000.000 = $0,0006, tổng cộng $0,0056. 500 bài tổng cộng $2,80. Có thể thấy các tác vụ có đầu vào dài và đầu ra ngắn rất rẻ.

Ví dụ 3: Trò chuyện đa lượt và cắt bớt lịch sử

Giả định: system 100 token; mỗi lượt đầu vào của người dùng 60 token, phản hồi 150 token; một cuộc hội thoại 20 lượt.

Đầu vào của phương án toàn lịch sử là: 20 × (100 + 60) + 210 × (0 + 1 + … + 19) = 3.200 + 39.900 = 43.100. Phương án cắt bớt 3 lượt đầu tiên lần lượt là 160, 370, 580, từ lượt 4 đến lượt 20 mỗi lượt 790, tổng cộng 14.540. Chi phí chênh lệch khoảng một nửa, và số lượt càng nhiều thì chênh lệch càng lớn, vì đầu vào của phương án toàn lịch sử tăng theo bậc hai theo số lượt.

Từ ba ví dụ này, bạn có thể rút ra một công thức kinh nghiệm: chi phí chủ yếu được quyết định bởi “số lượng yêu cầu × lượng đầu vào/đầu ra mỗi lần”, và trong lượng đầu vào mỗi lần, lịch sử và tài liệu đính kèm là phần dễ điều chỉnh nhất. Trong ngữ cảnh dịch vụ khách hàng, bạn hãy giảm độ dài đoạn kiến thức; trong ngữ cảnh trò chuyện, hãy cắt bớt lịch sử; trong ngữ cảnh tóm tắt, hãy chia nhỏ và xử lý song song. Tất cả đều dựa trên cùng một nguyên lý: đừng trả tiền thừa cho các token không cần thiết. Cần nhấn mạnh rằng, các con số trong ba ví dụ này đều dựa trên các giả định đã nêu ở trên, dữ liệu thực tế của bạn vui lòng dựa vào usage để xác nhận.

Hãy xem một phép tính ngược: nếu ngân hàng tháng của bạn là $30, bạn muốn biết sản phẩm trò chuyện có thể duy trì được bao nhiêu cuộc hội thoại 20 lượt mỗi tháng. Theo phương án “chỉ mang 3 lượt gần nhất” của ví dụ 3, mỗi cuộc khoảng $0,0066, $30 ÷ 0,0066 khoảng 4.545 cuộc. Với cùng ngân sách, nếu dùng phương án toàn lịch sử, mỗi cuộc $0,0138, chỉ đủ cho khoảng 2.174 cuộc. Đây chính là sự khác biệt thực tế mà việc cắt bớt lịch sử mang lại.

Kiểm soát ngân sách: Lắp van điều tiết cho chương trình của bạn

Ước lượng chỉ là dự báo, van điều tiết mới là bảo hiểm. Dưới đây là một lớp ngân sách ngày tính theo đô la: trước khi gửi yêu cầu, hãy dự đoán bằng “trường hợp xấu nhất” (đầu ra dùng đầy max_tokens), sau khi gửi yêu cầu hãy ghi chép theo usage thực tế.

复制class Budget:
    """按美元计的日预算。超出时拒绝新请求。"""
    def __init__(self, daily_usd):
        self.limit = daily_usd
        self.spent = 0.0

    def check(self, est_prompt_tokens, max_tokens):
        # 最坏情况：输出用满 max_tokens
        worst = (est_prompt_tokens * 0.25 + max_tokens * 1.00) / 1_000_000
        if self.spent + worst > self.limit:
            raise RuntimeError(f"预算不足：已用 ${self.spent:.4f}，本次最坏 ${worst:.4f}，上限 ${self.limit}")

    def record(self, usage):
        self.spent += (usage.prompt_tokens * 0.25 + usage.completion_tokens * 1.00) / 1_000_000

budget = Budget(daily_usd=5.0)
budget.check(est_prompt_tokens=1200, max_tokens=500)   # 请求前
# ……发请求……
# budget.record(response.usage)                        # 请求后

Ngoài van điều tiết trong chương trình, bạn còn có ba phương pháp ở tầng cấu hình:

1. Đặt max_tokens theo nhiệm vụ, đừng kéo đều lên mức tối đa, mặc định là 2048, tối đa là 32.000;
2. Đặt giới hạn độ dài lịch sử hội thoại, xem hướng dẫn trong Hướng dẫn xây dựng chatbot;
3. Chỉ nạp tiền vào tài khoản với số tiền bạn dự định sử dụng, nạp thêm khi hết, chế độ tín dụng trả trước vốn dĩ đã là một giới hạn cứng.

Giá đơn vị và quy tắc về số dư dựa trên Trang giá cả; chi tiết giao diện API có trong Giải thích tham số.

Cuối cùng, bạn hãy tổng hợp thành một bảng kiểm tra: trước khi làm, hãy ước lượng quy mô, đặt max_tokens, kiểm tra độ dài lịch sử; trong khi làm, hãy chú ý đến usage của khối cuối cùng khi xuất stream; sau khi làm, hãy ghi chép và phân loại theo chức năng, so sánh với ngân sách. Sau khi hoàn thành ba bước này, hóa đơn sẽ rõ ràng.