Bởi Tại sao giá output token của Claude đắt hơn input?
Chi phí output token của Claude cao gấp 5 lần input do cơ chế decoding tuần tự. Bài viết giải thích kỹ thuật prefill và decoding, giúp bạn tối ưu hóa hóa đơn API hàng tháng.
Tại sao output token lại đắt hơn input token
Output token có chi phí gấp năm lần input token trên mọi model Claude trong danh mục hiện tại. Nguyên nhân nằm ở cách thức tính toán. Việc đọc một prompt chỉ là một lượt xử lý qua model. Việc viết phản hồi là một lượt xử lý cho mỗi token, và mỗi lượt phải chờ lượt trước đó hoàn tất.
Tỷ lệ này giống nhau trên mọi dòng trong bảng giá, vì vậy model bạn chọn không làm thay đổi tỷ trọng chi phí output trong hóa đơn của bạn. Hình thái workload của bạn mới quyết định điều đó. Một bước tác vụ agent đọc 60,000 token và trả lời 800 token gần như không tốn chi phí cho output. Một công việc soạn thảo đọc 2,000 token và viết 12,000 token gần như không tốn chi phí cho input. Cả hai trường hợp đều được tính toán dưới đây dựa trên bảng giá tháng 8 năm 2026 của Anthropic.
Prefill chạy một lần, decoding chạy một lần cho mỗi token
Một inference server xử lý yêu cầu theo hai giai đoạn với chi phí rất khác nhau. Prefill đọc prompt. Decoding ghi câu trả lời.
Prefill xử lý toàn bộ prompt cùng lúc. Mọi token trong prompt đi vào mạng trong cùng một forward pass, vì vậy công việc attention và feed-forward trở thành một số lượng nhỏ các phép nhân ma trận lớn, xử lý hàng ngàn token mỗi lần. Một lần đọc trọng số mô hình (model weights) từ bộ nhớ phục vụ cho toàn bộ prompt. Các đơn vị ma trận của bộ tăng tốc luôn bận rộn, nghĩa là prefill bị giới hạn bởi tính toán (compute-bound): giới hạn nằm ở tốc độ chip thực hiện phép nhân.
Decoding không thể hoạt động như vậy, vì token 2 phụ thuộc vào token 1. Token mà mô hình vừa tạo ra trở thành một phần đầu vào cho bước tiếp theo, nên các bước không thể chạy cùng lúc. Mỗi token đầu ra có một forward pass riêng, và mỗi pass đó đọc toàn bộ tập trọng số mô hình từ bộ nhớ băng thông cao (high-bandwidth memory) để tạo ra một token duy nhất. Điều này làm cho decoding bị giới hạn bởi bộ nhớ (memory-bound): giới hạn nằm ở tốc độ di chuyển trọng số, không phải tốc độ nhân. Cùng một lưu lượng trọng số tiêu tốn cho cả một prompt trong quá trình prefill chỉ đổi lại được một token trong quá trình decoding.
Các hệ thống phục vụ đối phó bằng cách batching. Nhiều yêu cầu được decode cùng nhau, vì vậy một lần đọc trọng số sẽ tạo ra một token cho mỗi yêu cầu trong batch. Đó là lý do tại sao decoding có thể thực hiện được. Giới hạn lại là bộ nhớ. Mỗi yêu cầu đang chạy đều giữ một KV cache (key/value cache, trạng thái attention đã lưu cho mỗi token tính đến thời điểm hiện tại), cache đó tăng lên theo mỗi token được tạo ra, và khi nó làm đầy bộ tăng tốc, batch không thể tăng thêm được nữa.
Không có thông tin nào ở trên đưa ra cho bạn một con số chính xác, và bạn không nên hiểu 5x là một tỷ lệ phần cứng đã đo đạc. Đó là một mức giá, do Anthropic thiết lập, dựa trên sự bất đối xứng đó. Điều bạn có thể tự kiểm tra là xu hướng, và việc đó chỉ mất khoảng một phút.
Tự đo độ trễ đầu vào và đầu ra
Cài đặt các công cụ trên bất kỳ máy Ubuntu nào:
sudo apt update && sudo apt install -y curl jq moreutilsBây giờ, hãy stream một prompt ngắn yêu cầu câu trả lời dài và gắn dấu thời gian cho mỗi dòng khi nó xuất hiện.
curl -sN https://api.anthropic.com/v1/messages \
-H "x-api-key: $ANTHROPIC_API_KEY" \
-H "anthropic-version: 2023-06-01" \
-H "content-type: application/json" \
-d '{"model":"claude-sonnet-5","max_tokens":1000,"stream":true,
"messages":[{"role":"user","content":"Count from 1 to 300, one number per line."}]}' \
| ts -s '%.s'ts -s thêm số giây đã trôi qua kể từ khi lệnh bắt đầu vào đầu mỗi dòng. Có hai thông số đáng chú ý từ kết quả này. Dòng content_block_delta đầu tiên là thời gian để nhận token đầu tiên, toàn bộ quá trình prefill đã diễn ra trong khoảng thời gian đó. Mỗi dòng sau đó là một bước giải mã nhỏ, và các dấu thời gian tiếp tục tăng cho đến khi message_stop xuất hiện.
Bây giờ hãy đảo ngược cấu trúc. Đưa một tài liệu dài vào prompt và giới hạn câu trả lời chỉ trong vài token.
curl -sN https://api.anthropic.com/v1/messages \
-H "x-api-key: $ANTHROPIC_API_KEY" \
-H "anthropic-version: 2023-06-01" \
-H "content-type: application/json" \
-d "$(jq -n --rawfile doc ./long-document.txt \
'{model:"claude-sonnet-5", max_tokens:16, stream:true,
messages:[{role:"user", content:("Answer in one word. Is this document about networking?\n\n" + $doc)}]}')" \
| ts -s '%.s'Khoảng thời gian đầu tiên mất nhiều thời gian hơn so với prompt ngắn, vì prefill phải đọc nhiều văn bản hơn. Sau khi nhận được phản hồi, quá trình kết thúc gần như ngay lập tức vì chỉ còn vài token cần giải mã. Hàng chục nghìn token đã được gửi vào nhưng đồng hồ gần như không thay đổi. Chỉ vài trăm token được xuất ra nhưng đồng hồ đã chạy trong suốt quá trình đó.
Mọi phản hồi không stream đều kết thúc bằng các con số mà bạn bị tính phí.
{
"usage": {
"input_tokens": 41283,
"output_tokens": 6,
"cache_creation_input_tokens": 0,
"cache_read_input_tokens": 0
}
}Hãy log lại cả bốn trường cho mỗi request. output_tokens bao gồm cả phần suy nghĩ mở rộng, vì vậy một model suy nghĩ trước khi trả lời sẽ tính phí phần suy nghĩ đó theo mức giá của output. Để tính giá cho một prompt trước khi gửi, POST /v1/messages/count_tokens chấp nhận cùng một request body, trả về {"input_tokens": N} mà không cần chạy model, và hoàn toàn miễn phí. Đây không phải là phần duy nhất của API không tốn phí, và việc xem những phần nào của Claude API bạn không bao giờ bị tính phí là điều đáng làm trước khi bạn lập ngân sách cho dự án đầu tiên.
Chi phí mỗi triệu token của Claude tính đến tháng 8 năm 2026
The data behind this chart
[
{
"label": "Haiku 4.5",
"input_usd": 1,
"output_usd": 5,
"output_multiple": 5
},
{
"label": "Sonnet 5 (to 31 Aug)",
"input_usd": 2,
"output_usd": 10,
"output_multiple": 5
},
{
"label": "Sonnet 5 (from 1 Sep)",
"input_usd": 3,
"output_usd": 15,
"output_multiple": 5
},
{
"label": "Opus 5",
"input_usd": 5,
"output_usd": 25,
"output_multiple": 5
},
{
"label": "Fable 5",
"input_usd": 10,
"output_usd": 50,
"output_multiple": 5
}
]Cột cuối cùng là đầu ra chia cho đầu vào, hiển thị 5 trên mỗi hàng. Haiku 4.5 tính phí $1 cho đầu vào và $5 cho đầu ra. Opus 5 tính phí $5 và $25. Fable 5, model đắt nhất, tính phí $10 và $50, và những gì mức giá Fable 5 mang lại là nội dung đáng đọc trước khi bạn bỏ qua hàng đầu tiên đó. Việc chuyển lên các phân khúc cao hơn sẽ nhân cả hai phía với cùng một hệ số, vì vậy nó làm thay đổi tổng chi phí của bạn nhưng giữ nguyên tỷ lệ đầu vào trên đầu ra.
Sonnet 5 xuất hiện hai lần vì mức giá ưu đãi dùng thử của nó sẽ hết hạn. Đến hết ngày 31 tháng 8 năm 2026, nó tính phí $2 và $10. Từ ngày 1 tháng 9 năm 2026, mức giá tiêu chuẩn là $3 và $15 sẽ được áp dụng, cao hơn 50% ở cả hai phía. Mọi ví dụ tính toán bên dưới đều sử dụng mức giá của tháng 8.
Giá cả có thể thay đổi và đây không phải là nơi bạn nên kiểm tra giá chính thức. claude.com/pricing mới là nguồn tin cậy nhất. Điều không thay đổi sau khi giá điều chỉnh chính là phương pháp tính toán.
Một lưu ý mà bảng giá không hiển thị. Tài liệu của Anthropic nêu rõ rằng Claude 4.7 và các model sau này sử dụng tokenizer mới, tạo ra số lượng token nhiều hơn khoảng 30% cho cùng một văn bản so với tokenizer trong Sonnet 4.6 trở về trước. Nếu chỉ so sánh giá mỗi triệu token, các model mới sẽ có vẻ rẻ hơn, vì cùng một tài liệu sẽ tốn nhiều token hơn trên các model này. Hãy so sánh dựa trên chi phí cho mỗi tác vụ hoàn thành và tính toán các prompt thực tế của bạn dựa trên model mà bạn dự định sử dụng. giá trị của một triệu token Claude trong văn bản thực tế sẽ cho bạn biết khối lượng đó trông như thế nào trong thực tế.
Khi nào chi phí output bắt đầu chiếm ưu thế trong hóa đơn của bạn?
Với giá output được tính bằng 5 lần so với input, điểm hòa vốn rất dễ tính nhẩm. Gọi số lượng token input là I và token output là O. Chi phí input là I. Chi phí output là 5 lần O. Output sẽ chiếm hơn một nửa chi phí của bạn khi 5 lần O lớn hơn I, tức là tỷ lệ token là 5 input trên 1 output.
Vì vậy, nếu prompt của bạn dài gấp hơn năm lần câu trả lời, input sẽ là khoản mục chi phí lớn hơn. Dưới mức đó, output mới là khoản lớn hơn.
The data behind this chart
[
{
"label": "100:1",
"input_share_pct": 95.2,
"output_share_pct": 4.8
},
{
"label": "75:1",
"input_share_pct": 93.75,
"output_share_pct": 6.25
},
{
"label": "20:1",
"input_share_pct": 80,
"output_share_pct": 20
},
{
"label": "10:1",
"input_share_pct": 66.7,
"output_share_pct": 33.3
},
{
"label": "5:1",
"input_share_pct": 50,
"output_share_pct": 50
},
{
"label": "1:1",
"input_share_pct": 16.7,
"output_share_pct": 83.3
},
{
"label": "1:6",
"input_share_pct": 3.2,
"output_share_pct": 96.8
}
]Ở tỷ lệ 100 trên 1, output chiếm 4.8% chi phí, và việc tối ưu prompt là công việc duy nhất đáng làm. Ở tỷ lệ 5 trên 1, hai bên cân bằng. Ở tỷ lệ 1 trên 6, output chiếm 96.8% và prompt chỉ là sai số làm tròn. Hầu hết mọi người đều đoán sai tỷ lệ của chính mình, vì vậy hãy lấy dữ liệu từ log trước khi tối ưu bất cứ thứ gì.
Workload của agent: input ngữ cảnh dài, output câu trả lời ngắn
Hãy xét một bước thực hiện của retrieval agent: 60.000 token input từ tài liệu được truy xuất và lịch sử hội thoại, cùng với 800 token cho câu trả lời. Tỷ lệ này là 75:1, mức bình thường đối với bất kỳ tác vụ nào cần đọc trước khi viết.
The data behind this chart
[
{
"label": "Haiku 4.5",
"input_cost": 0.06,
"output_cost": 0.004,
"total_cost": 0.064
},
{
"label": "Sonnet 5 (Aug)",
"input_cost": 0.12,
"output_cost": 0.008,
"total_cost": 0.128
},
{
"label": "Opus 5",
"input_cost": 0.3,
"output_cost": 0.02,
"total_cost": 0.32
},
{
"label": "Fable 5",
"input_cost": 0.6,
"output_cost": 0.04,
"total_cost": 0.64
}
]Output chiếm 6.25% chi phí của mỗi lần gọi trên mọi model, vì tỷ lệ này cố định trên toàn bộ bảng giá. Lần gọi này tốn $0.32 trên Opus 5, $0.128 trên Sonnet 5 theo mức giá tháng Tám, và $0.064 trên Haiku 4.5. Hai trăm bước như vậy mỗi ngày trên Opus 5 sẽ tốn $64 một ngày.
Đòn bẩy tối ưu hóa sẽ rõ ràng khi bạn nhìn vào sự phân chia này. Cắt giảm câu trả lời từ 800 token xuống 400 chỉ tiết kiệm được khoảng 3% chi phí cuộc gọi. Loại bỏ 20.000 token ngữ cảnh cũ ra khỏi prompt sẽ tiết kiệm được khoảng một phần ba chi phí. Việc thắt chặt độ dài output trên một agent thiên về đọc là nỗ lực gần như vô ích. nơi các token của một coding agent thực sự đổ về sẽ phân tích chi tiết những gì lấp đầy prompt đó ngay từ đầu.
Workload tạo nội dung: prompt ngắn, bản nháp dài
Bây giờ hãy đảo ngược cấu trúc. Một bản tóm tắt 2.000 token, một bản nháp 12.000 token, tỷ lệ 1 trên 6.
The data behind this chart
[
{
"label": "Haiku 4.5",
"input_cost": 0.002,
"output_cost": 0.06,
"total_cost": 0.062,
"batch_total_cost": 0.031
},
{
"label": "Sonnet 5 (Aug)",
"input_cost": 0.004,
"output_cost": 0.12,
"total_cost": 0.124,
"batch_total_cost": 0.062
},
{
"label": "Opus 5",
"input_cost": 0.01,
"output_cost": 0.3,
"total_cost": 0.31,
"batch_total_cost": 0.155
},
{
"label": "Fable 5",
"input_cost": 0.02,
"output_cost": 0.6,
"total_cost": 0.62,
"batch_total_cost": 0.31
}
]Đầu ra chiếm 96.8% hóa đơn này. Opus 5 tốn $0.31 cho mỗi bản nháp so với $0.062 trên Haiku 4.5. Mức chênh lệch gấp năm lần này gần như hoàn toàn đến từ phía đầu ra, đây chính xác là nơi một model rẻ hơn giúp bạn tiết kiệm nhiều nhất.
Cột cuối cùng là cùng một công việc thực hiện qua Batch API, giúp giảm 50% chi phí cho cả input và output. Opus 5 giảm xuống còn $0.155 mỗi bản nháp. Batch trả về kết quả trong vòng 24 giờ thay vì ngay lập tức, vì vậy nó phù hợp cho việc tạo báo cáo qua đêm và phân loại dữ liệu hàng loạt. Nó không phù hợp với bất kỳ tác vụ nào mà người dùng đang ngồi chờ đợi.
Model routing mang lại hiệu quả ở đây theo cách mà bước agent không bao giờ có được. Nếu phần công việc dài dòng mang tính cơ học, như định dạng lại văn bản hoặc mở rộng một dàn ý mà bạn đã duyệt, model giá rẻ sẽ tạo ra các token đó với giá chỉ bằng một phần năm. lựa chọn giữa Opus, Sonnet và Haiku đề cập đến việc ranh giới chất lượng thực sự nằm ở đâu.
Caching giảm giá đầu vào, và chỉ đầu vào
Prompt caching lưu trữ một phần tiền tố của prompt trên server và tính phí bằng một phần nhỏ so với mức giá đầu vào để đọc lại dữ liệu đó. Tính đến tháng 8 năm 2026, các hệ số nhân là 1.25x so với giá đầu vào cơ bản để ghi cache 5 phút, 2x để ghi cache 1 giờ, và 0.1x để đọc một hit.
Output không nằm trong ưu đãi này. Không có khái niệm cached output. Mỗi token mà model viết ra đều bị tính phí theo mức giá output đầy đủ, mỗi lần thực hiện, bất kể bao nhiêu phần trăm prompt được lấy lại từ cache hit.
Hãy lấy ví dụ cùng một bước agent trên Opus 5, với 55,000 trong tổng số 60,000 token đầu vào được phục vụ từ một warm cache.
The data behind this chart
[
{
"label": "No cache",
"input_cost": 0.3,
"output_cost": 0.02,
"total_cost": 0.32
},
{
"label": "55k prefix cache read",
"input_cost": 0.0525,
"output_cost": 0.02,
"total_cost": 0.0725
}
]Chi phí cuộc gọi giảm từ $0.32 xuống còn $0.0725. Dòng chi phí output không thay đổi: $0.02 trước đó, và $0.02 sau đó. Caching cắt giảm hóa đơn và thay đổi cấu trúc chi phí. Output chiếm 6.25% của cuộc gọi đó. Bây giờ nó chiếm hơn một phần tư, điều này làm thay đổi đòn bẩy nào đáng để tối ưu tiếp theo.
Cuộc gọi đầu tiên sẽ chi trả cho việc ghi cache. Một lần ghi cache 5 phút tốn 1.25x giá đầu vào cơ bản, vì vậy nó tự hoàn vốn sau một lần hit. Một lần ghi 1 giờ tốn 2x, nên cần hai lần hit. các hệ số nhân ghi và đọc, và thời điểm caching không còn hiệu quả sẽ giải thích chi tiết các phép tính đó.
Bốn đòn bẩy bạn có thể kiểm soát
- Đặt
max_tokensở độ dài output p95, không phải ở mức tối đa của model. - Chuyển các bước dài dòng sang model rẻ hơn.
- Batch mọi thứ không yêu cầu phản hồi tức thì.
- Xóa các chỉ dẫn làm tăng độ dài phản hồi.
max_tokens là giới hạn cứng, việc đặt mức cao không tốn phí vì bạn chỉ bị tính tiền dựa trên số token thực tế tạo ra chứ không phải dựa trên giới hạn. Một giới hạn rộng rãi giúp tránh việc phản hồi bị cắt cụt khi có sự cố. Hãy trích xuất phân phối output_tokens từ log, đặt giới hạn cao hơn mức phân vị 95 một chút, và xử lý stop_reason: "max_tokens" trong code bằng cách tiếp tục phản hồi hoặc thử lại. Việc phát hiện bị cắt cụt tốn ít chi phí hơn so với việc trả tiền cho 4.000 token rác rồi bỏ đi. Quá trình suy nghĩ mở rộng cũng nằm trong output_tokens, vì vậy hãy đặt ngân sách đó dựa trên cùng dữ liệu này.
Routing hiệu quả khi phần tốn kém của một bước nằm ở khối lượng thay vì khả năng phán đoán. Hãy giữ model mạnh cho việc ra quyết định và giao phần viết nội dung cho model rẻ hơn. Hãy đo lường phiên bản đã route trên tập đánh giá của riêng bạn trước, vì một model rẻ cần thử lại hai lần sẽ tốn kém hơn một lần thử của model đắt tiền.
Batching là đòn bẩy duy nhất giúp giảm giá output. Giảm 50% chi phí cho cả hai phía, kết quả có trong vòng 24 giờ, và mọi tác vụ theo lịch trình đều đủ điều kiện.
Đòn bẩy cuối cùng là thứ mọi người thường bỏ qua. Các cụm từ như "hãy giải thích kỹ" và "giải thích lý do của bạn" sẽ làm tăng độ dài output trên mọi yêu cầu bạn thực hiện. Hãy thay thế chúng bằng định dạng bạn muốn: "Trả lời tối đa ba câu", hoặc "Chỉ trả về đối tượng JSON, không có phần mở đầu". Một system prompt thêm 300 token vào mỗi phản hồi sẽ tốn kém gấp năm lần so với 300 token tương tự trong prompt. kiểm soát chi phí của agent đang chạy bao gồm khía cạnh giám sát, và liệu API hay gói đăng ký cố định rẻ hơn cho mô hình của bạn là điều đáng cân nhắc trước khi bạn dành cả tuần để tối ưu hóa chi phí theo token mà một gói đăng ký có thể đã bao gồm. Đối với một lập trình viên, điều này chủ yếu phụ thuộc vào việc gói Claude Pro 20 đô la một tháng và các giới hạn sử dụng đi kèm có đáp ứng được khối lượng công việc mà bạn đang phải đo đếm hay không. Nếu bạn đã chạm tới các giới hạn đó giữa phiên làm việc, xác định cửa sổ nào bạn đang chờ đợi là ưu tiên hàng đầu, vì giải pháp sau đó là dùng model nhỏ hơn, context nhẹ hơn, mua thêm credit sử dụng, hoặc chuyển công việc đó sang API tính phí theo mức sử dụng. Nếu API tính phí theo mức sử dụng là nơi rẻ hơn cho công việc đó, hạ xuống gói nhỏ hơn hoặc hủy gói hiện tại vẫn giữ nguyên tháng bạn đã thanh toán, nên việc chuyển đổi không tốn thêm chi phí. Nếu gói bạn đang cân nhắc so với Pro là ChatGPT thay vì API tính phí, hai thang giá đăng ký đặt cạnh nhau sẽ cho thấy gói nào rẻ hơn cho công việc lập trình. Nếu câu hỏi này dành cho một nhóm thay vì một lập trình viên, hãy lưu ý rằng Claude Enterprise kết hợp phí mỗi người dùng với token tính theo mức giá API này, vì vậy mọi đòn bẩy trên trang này vẫn áp dụng cho phần hóa đơn tính theo mức sử dụng đó.
FAQ
Tại sao output token lại đắt hơn input token?
Việc tạo ra chúng tốn nhiều thời gian của bộ tăng tốc (accelerator) hơn trên mỗi token. Một prompt được xử lý trong một lượt forward pass duy nhất cho toàn bộ nội dung, vì vậy chỉ cần đọc trọng số của model một lần là xử lý được hàng nghìn token và phần cứng bị giới hạn bởi thông lượng nhân (multiply throughput). Một phản hồi được tạo ra từng token một, mỗi token cần một lượt forward pass riêng và phải đọc lại toàn bộ trọng số của model, do đó phần cứng bị giới hạn bởi băng thông bộ nhớ. Anthropic định giá output gấp năm lần input trên toàn bộ danh mục hiện tại, từ Haiku 4.5 cho đến Fable 5.
Prompt caching có làm output token rẻ hơn không?
Không. Prompt caching chỉ áp dụng cho input. Tính đến tháng 8 năm 2026, chi phí đọc cache bằng 0.1x mức giá input cơ bản, và chi phí ghi cache là 1.25x cho thời hạn 5 phút hoặc 2x cho thời hạn 1 giờ. Output vẫn được tính phí theo mức giá đầy đủ trên mỗi lần gọi, bất kể cache đã hoạt động như thế nào. Đó là lý do tại sao caching làm thay đổi cả cấu trúc lẫn quy mô hóa đơn của bạn: khi chi phí phía input giảm xuống, output trở thành phần chiếm tỷ trọng lớn cần tối ưu.
max_tokens cao có làm tôi tốn tiền nếu phản hồi trả về ngắn không?
Không. Bạn chỉ bị tính phí cho số token mà model thực sự tạo ra, vì vậy max_tokens là mức trần chứ không phải là mức đặt trước. Nó vẫn quan trọng vì đây là giới hạn cứng duy nhất đối với một phản hồi bị lặp vô tận. Hãy đặt nó cao hơn một chút so với phân vị thứ 95 của output_tokens mà bạn quan sát được, sau đó xử lý stop_reason: "max_tokens" trong code thay vì để hệ thống tự động cắt cụt câu trả lời một cách âm thầm.
Làm thế nào để tìm tỷ lệ input trên output token của riêng tôi?
Hãy log input_tokens, output_tokens, cache_read_input_tokens và cache_creation_input_tokens từ đối tượng usage của mỗi phản hồi, sau đó chia tổng số trong một tuần. Nếu tỷ lệ trên 5 input trên 1 output, tiền của bạn nằm ở prompt, vì vậy hãy cache phần ổn định và cắt bớt phần còn lại. Nếu thấp hơn mức đó, tiền của bạn nằm ở phần phản hồi, vì vậy hãy giới hạn độ dài của nó và chuyển các bước tạo ra nhiều token nhất sang một model rẻ hơn hoặc sử dụng Batch API.