Bạn có một job chạy 5,000 request mỗi đêm, mất hai giờ để xử lý, và chẳng ai xem xét đến kết quả cho đến sáng hôm sau. Vậy mà bạn vẫn trả giá realtime cho nó — bởi vì ở đâu đó dọc theo hành trình phát triển, cái tên “API” đã lặng lẽ trở thành “synchronous API”, còn batch endpoint với mức chiết khấu 50% thì chưa từng được đưa vào kiến trúc.
Đây chính là lỗ hổng chi phí phổ biến nhất trong các ngân sách LLM năm 2026: những workload có thể trì hoãn lại đang phải trả giá realtime. Mọi nhà cung cấp lớn hiện nay đều chiết khấu khoảng 50% cho các workload bất đồng bộ — thị trường batch API LLM đã chuẩn hóa ở mức nửa giá — batch API của OpenAI với khung thời gian hoàn thành ~24 giờ, Message Batches của Anthropic với khung ~1 giờ, batch tier của Gemini, và DeepSeek cũng đưa ý tưởng tương tự vào mô hình giá peak/off-peak của mình. Khoản tiền tiết kiệm đang nằm ngay trên bàn, và bài viết này sẽ giúp bạn nhặt nó lên: batch API là gì, bảng so sánh từng nhà cung cấp, một workflow bạn có thể sao chép, quy tắc quyết định batch-vs-realtime, và phép toán kết hợp để cộng dồn khoản tiết kiệm từ batch với caching và routing.
Batch API là gì
Điểm chính: batch = gửi ngay, thu kết quả sau, trả một nửa giá — mọi nhà cung cấp lớn đều chuẩn hóa theo cùng một mô hình.
Cơ chế hoạt động thống nhất ở mọi nơi: bạn gửi một file chứa các request (JSONL), nhà cung cấp xếp chúng vào hàng đợi, xử lý khi tài nguyên cho phép, và bạn thu kết quả khi batch hoàn thành. Không có streaming, không có độ trễ tương tác — khoản chiết khấu chính là phần bù cho sự linh hoạt này.
Bảng so sánh các nhà cung cấp năm 2026:
| Nhà cung cấp | Mức chiết khấu | Khung thời gian hoàn thành | Ghi chú |
|---|---|---|---|
| OpenAI | ~50% | ~24 giờ | bản triển khai tham chiếu |
| Anthropic | ~50% | ~1 giờ | khung thời gian nhanh nhất trong bốn |
| Gemini | ~50% | tier linh hoạt | batch ánh xạ tới Flex inference tier |
| DeepSeek | giá off-peak | khung giờ peak/off-peak | cùng một ý tưởng nhưng tính theo đồng hồ, áp dụng từ tháng 8 năm 2026 |
Bảng so sánh giữa các nhà cung cấp theo dõi chi tiết; mô hình thì giống hệt nhau — nếu bạn chờ được, bạn trả một nửa giá.
Vì sao batch processing tiết kiệm tiền thật
Điểm chính: giảm 50% khoản chi lớn nhất trong hóa đơn của bạn là một quyết định về giá, không phải một kỹ thuật tối ưu.
Phép toán ở đây cố ý đơn giản đến nhàm chán. Giả sử hóa đơn hàng tháng của bạn là $1,000 và 60% trong đó là các workload có thể trì hoãn (evals, indexing, enrichment, sinh nội dung hàng đêm). Chuyển $600 đó sang batch: tiết kiệm $300 mỗi tháng, $3,600 mỗi năm, chất lượng không đổi. Output tokens hoàn toàn giống nhau; khác biệt duy nhất là thời điểm chúng đến.
Hai lưu ý để phép toán luôn trung thực:
- Khoản chiết khấu áp dụng ở cấp nhà cung cấp, không phải cấp nền tảng. Một endpoint hợp nhất tính phí đúng theo những gì nhà cung cấp phía sau tính — giá batch truyền qua nguyên vẹn như giá batch. Cẩm nang tối ưu chi phí của chúng tôi bao quát toàn bộ các đòn bẩy; batch là đòn bẩy có chi phí kỹ thuật thấp nhất.
- Batch không phải miễn phí. Nó chỉ là nửa giá. Một nửa còn lại vẫn hưởng lợi từ caching và routing — đó chính là phép toán cộng dồn trong phần năm bên dưới.
Cách xây dựng một batch workflow
Điểm chính: workflow gồm bốn mảnh ghép — submission, idempotency, collection, recovery — và recovery là mảnh mà hầu như ai cũng bỏ qua.
Bộ khung dưới đây không phụ thuộc vào nhà cung cấp — định dạng request tuân theo tài liệu chat completions endpoint:
import json
from openai import OpenAI
client = OpenAI() # point at your provider or unified endpoint
# 1. Build the JSONL request file
with open("batch.jsonl", "w") as f:
for i, task in enumerate(tasks):
f.write(json.dumps({
"custom_id": f"task-{i}", # idempotency key — never omit
"method": "POST",
"url": "/v1/chat/completions",
"body": {"model": "gpt-4o-mini", "messages": task["messages"]},
}) + "\n")
# 2. Submit once — the custom_id makes retries safe
batch = client.batches.create(input_file=upload(batch_path), endpoint="/v1/chat/completions")
# 3. Poll or webhook until complete, then map results back by custom_id
# 4. Recover: failed rows get re-queued into the NEXT batch, not re-run inlineBốn quy tắc để giữ cho hệ thống đạt chuẩn production:
custom_idchính là hợp đồng của bạn. Idempotency là thứ làm cho việc retry trở nên an toàn; thiếu nó, một trục trặc mạng trong lúc gửi có thể nhân đôi khối lượng công việc và gấp đôi hóa đơn.- Thu kết quả theo ID, không theo thứ tự. Kết quả batch trả về theo thứ tự bất kỳ; hãy ánh xạ
custom_idvề bản ghi của bạn, nếu không bạn sẽ ghép (join) sai dữ liệu hai lần. - Webhook vượt trội hơn polling khi mở rộng quy mô. Một completion callback thay thế vòng lặp “kiểm tra mỗi 5 phút”; tài liệu tham khảo error codes cho bạn biết lỗi nào có thể retry.
- Recovery là một hàng đợi, không phải một mẹo vặt. Các dòng lỗi được đưa trở lại chu kỳ batch tiếp theo. Những đội ngũ chạy lại các lỗi inline chính là những đội ngũ học được rate limits của batch theo cách đau đớn nhất.
Cách chọn: batch hay realtime
Điểm chính: quyết định chỉ là một câu hỏi — công việc này có thể chờ được không? — với hai ngoại lệ rõ ràng mà câu trả lời luôn là không.
Quy tắc quyết định, nói thẳng ra:
- Công việc có thể chờ một giờ? Hãy dùng batch.
- Có thể chờ một ngày? Hãy dùng batch tại nhà cung cấp có khung thời gian phù hợp với giá rẻ nhất.
- Có người dùng đang chờ? Không bao giờ dùng batch.
- Đó có phải là agent loop? Không bao giờ dùng batch.
Ngoại lệ thứ hai đáng được nhấn mạnh: nhìn vào khối lượng token, agent loops trông giống ứng viên lý tưởng cho batch, nhưng các request của chúng bị ràng buộc nhân quả — mỗi lần gọi phụ thuộc vào lần trước — nên chúng mang tính tương tác ngay từ bản chất. Các kiến trúc voice-agent và support-chatbot trong loạt bài này cũng mang tính tương tác vì lý do tương tự. Batch dành cho những công việc có thể song song hóa với một deadline, và tập hợp đó nhỏ hơn nhiều so với những gì hầu hết đội ngũ vẫn nghĩ — điều này càng khiến mức chiết khấu 50% trở nên giá trị hơn ở những nơi nó thực sự áp dụng.
Cách cộng dồn khoản tiết kiệm: batch × caching × routing
Điểm chính: batch, caching và routing nhân với nhau — một batch job tái sử dụng cached prefixes trên một model giá rẻ chỉ tốn một phần nhỏ so với cách làm chưa tối ưu ban đầu.
Ba đòn bẩy này không chồng chéo lên nhau, và đó chính xác là lý do chúng có thể cộng dồn:
- Batch — giảm 50% giá cơ bản cho các workload có thể trì hoãn.
- Prompt caching — các input prefix được cache ở mức ~0.1×, và batch jobs là workload caching lý tưởng: cùng một template chạy hàng nghìn lần, nên các prefix ổn định theo byte gần như luôn trúng cache. Hướng dẫn về caching trình bày cơ chế chi tiết; sức mạnh cộng hưởng với batch chính là hệ số nhân.
- Routing — chọn model tier cho batch là một quyết định routing: chạy evals trên frontier model vì bạn đang đo lường chính frontier; chạy enrichment trên model giá rẻ vì chẳng ai đọc nó. Tài liệu tối ưu production bao quát cơ chế routing.
Một ví dụ cộng dồn cụ thể: job enrichment chạy hàng đêm với 10M tokens. Giá cơ bản trên một model tầm trung: $30. Với batch: $15. Cùng job đó với các prefix ổn định trúng cache ở mức 0.1× phía đầu vào (giả sử 80% tokens được cache): khoảng $4-6. Cùng một job, cùng chất lượng output, chỉ cần thêm một routing config và một prompt template ổn định. Quickstart giúp bạn nối xong pipeline trong vài phút; hệ số nhân mới chính là phần sinh lời kép.
Những sai lầm phổ biến khiến hóa đơn đội lên
Điểm chính: bốn cách làm mất khoản chiết khấu — mỗi cách âm thầm biến 50% trở lại thành 100%.
- Đánh giá (eval) trên các dòng lỗi. Chỉ chạy eval trên những dòng hoàn thành của batch; các dòng lỗi là vấn đề chất lượng dữ liệu, và việc đưa chúng vào sẽ tạo ra một điểm số giả mà bạn rồi sẽ tối ưu theo. Kỷ luật eval kiểu CI trong bài hướng dẫn testing của loạt bài này cho thấy mô hình chuẩn.
- Để kết quả hết hạn. Kết quả batch có khung thời gian lưu giữ; một job hoàn thành trong lúc bạn đang đi nghỉ và hết hạn trước khi bạn thu về là một job trả full price mà không có output. Hãy gắn việc thu kết quả vào completion event, đừng gắn vào lịch của bạn.
- Bỏ qua rate limits riêng của batch. Hạn mức (quota) của batch tách biệt với hạn mức realtime — những đội ngũ giả định chúng giống nhau sẽ tự phát hiện trần của mình giữa chừng khi batch đang chạy.
- Bỏ qua idempotency. Không có
custom_id, không có retry an toàn, không có đường recovery — đây là bốn ký tự đắt giá nhất mà bạn có thể bỏ sót.
Câu hỏi thường gặp
Batch API thực sự tiết kiệm được bao nhiêu?
Khoảng 50% trên các batch tier của OpenAI, Anthropic và Gemini, còn mô hình peak/off-peak của DeepSeek là phiên bản tương đương tính theo đồng hồ. Khoản tiết kiệm được tính theo từng token, nên nó tăng theo khối lượng workload có thể trì hoãn của bạn — khoản chi lớn nhất trong hầu hết các hóa đơn.
Một batch mất bao lâu để hoàn thành?
Khung thời gian của OpenAI là ~24 giờ, của Anthropic là ~1 giờ, của Gemini gắn với Flex tier của nó, còn các khung off-peak của DeepSeek được định nghĩa theo đồng hồ. Hãy chọn nhà cung cấp có khung thời gian khớp với deadline của bạn; mức chiết khấu là như nhau.
Tôi có thể chạy evals ở chế độ batch không?
Được — evals chính là workload batch kinh điển. Chỉ chạy chúng trên các dòng hoàn thành, giữ prompt template ổn định theo byte để trúng cache, và dùng điểm số của batch hoàn thành làm cổng chặn (gate) cho CI.
Batch có hoạt động tốt với prompt caching không?
Cực kỳ tốt — batch jobs lặp lại cùng một template hàng nghìn lần, đây chính là đặc tính caching lý tưởng. Prefix ổn định + batch = khoản chiết khấu cộng dồn được mô tả trong bài viết này.
Những workload nào không bao giờ nên dùng batch?
Bất cứ thứ gì người dùng đang chờ đợi, và bất cứ thứ gì bị ràng buộc nhân quả — agent loops và voice/chat tương tác về bản chất là realtime. Câu hỏi quyết định cho batch là “có thể chờ được không”, chứ không phải “có lớn không”.
Endpoint hợp nhất có truyền qua khoản chiết khấu batch không?
Có — giá batch chính là giá của nhà cung cấp, và endpoint tính phí đúng theo những gì nhà cung cấp tính, khoản chiết khấu được giữ nguyên. Việc của endpoint chỉ là một key và một dashboard; khoản 50% thuộc về nhà cung cấp và nó truyền qua nguyên vẹn.
Tóm tắt
Bức tranh batch API LLM năm 2026 được chuẩn hóa một cách đáng kinh ngạc: gần như mọi nhà cung cấp lớn đều giảm khoảng 50%, với khung thời gian hoàn thành là điểm khác biệt thực sự duy nhất. Cách vận hành hoàn toàn cơ học — tìm phần workload có thể trì hoãn, chuyển nó sang batch, giữ prefix ổn định, route model tier theo từng loại nhiệm vụ — và sự kết hợp giữa batch, caching và routing thường xuyên đưa hóa đơn xuống thấp hơn 60-80% so với cách làm chưa tối ưu ban đầu. Khoản chiết khấu đang nằm ngay trên bàn; câu hỏi duy nhất là kiến trúc của bạn có nhặt nó lên hay không.
Hãy lấy 60% phần có thể trì hoãn trong hóa đơn của bạn và cắt nó đi một nửa. Nhận TokSpan API key — $5 miễn phí để dùng cho batch đầu tiên — và để chi phí theo từng job tự nói lên khoản tiết kiệm.