Chi phí Batch Inference cho AI API: Khi nào các tác vụ bất đồng bộ giúp tiết kiệm tiền

Định giá batch inference (suy luận theo lô) hoạt động dựa trên việc đánh đổi độ trễ phản hồi để lấy mức giá trên mỗi token thấp hơn: bạn gửi một tác vụ, nhà cung cấp xử lý tác vụ đó trong một khoảng thời gian xác định (thường lên đến 24 giờ) và bạn trả ít tiền hơn so với các cuộc gọi đồng bộ, thời gian thực. Việc đánh đổi này có xứng đáng hay không phụ thuộc hoàn toàn vào việc khối lượng công việc của bạn có thể chịu đựng được thời gian chờ đợi hay không.

Bài viết này so sánh batch inference (bất đồng bộ) với các cuộc gọi API đồng bộ tiêu chuẩn, dựa trên tài liệu về Batch API do OpenAI và Google công bố, đồng thời đưa ra khung quyết định để xác định khi nào lộ trình bất đồng bộ thực sự giúp tiết kiệm chi phí cho sản phẩm của bạn.

Những điểm chính cần lưu ý

• Cả OpenAI và Gemini đều cung cấp Batch API chấp nhận các tác vụ xử lý bất đồng bộ với mức giá ưu đãi so với các cuộc gọi đồng bộ; hãy xác nhận tỷ lệ chiết khấu chính xác hiện tại trên trang định giá của từng nhà cung cấp trước khi lập ngân sách, vì mức giá có thể thay đổi.
• Batch inference phù hợp với các khối lượng công việc có thể chấp nhận thời gian chờ đợi thay vì cần phản hồi ngay lập tức: phân loại hàng loạt, tạo embedding, đánh giá ngoại tuyến, dán nhãn tập dữ liệu và các tác vụ cập nhật dữ liệu cũ (backfill).
• Chat thời gian thực, các tác nhân lập trình (coding agents) và các tính năng sản phẩm tương tác thường không phù hợp với định giá theo lô, vì khoảng thời gian xử lý khiến chúng không thể sử dụng cho tương tác người dùng trực tiếp.
• Khoản tiết kiệm tích lũy lớn nhất thường đến từ việc kết hợp chiết khấu theo lô với việc lựa chọn mô hình và tối ưu hóa prompt; xem /models/rankings và hướng dẫn giảm chi phí AI API để biết các đòn bẩy khác.

Batch Inference thực sự có nghĩa là gì

Các cuộc gọi API đồng bộ trả về phản hồi ngay khi mô hình hoàn tất quá trình tạo, thường là trong vòng vài giây. Bạn trả mức giá trên mỗi token gắn liền với sự tức thời đó. Batch inference đảo ngược mô hình này: thay vì trao đổi yêu cầu-phản hồi đơn lẻ, bạn gửi một tệp hoặc danh sách các yêu cầu dưới dạng một tác vụ (job). Nhà cung cấp xếp hàng tác vụ đó, xử lý trong khoảng thời gian họ kiểm soát và cung cấp kết quả để bạn truy xuất sau khi hoàn tất.

Đây không phải là một kỹ thuật suy luận mới bên trong mô hình. Đây là một hợp đồng thương mại và vận hành khác. Nhà cung cấp có thể lên lịch cho khối lượng công việc của bạn dựa trên năng lực dư thừa hoặc ngoài giờ cao điểm, và đổi lại, họ tính phí trên mỗi token thấp hơn so với yêu cầu phải phục vụ ngay lập tức.

Cả OpenAI và Google đều ghi lại mô hình này cho các API tương ứng của họ:

• Tài liệu tham khảo Batch API của OpenAI mô tả việc tạo một đối tượng batch từ tệp yêu cầu đã tải lên, theo dõi trạng thái của nó và truy xuất đầu ra sau khi tác vụ hoàn tất (platform.openai.com/docs/api-reference/batch/object).
• Tài liệu Gemini Batch API của Google mô tả một mô hình tương đương: gửi một lô yêu cầu, tác vụ chạy bất đồng bộ và kết quả được truy xuất sau khi xử lý (ai.google.dev/gemini-api/docs/batch-api).

Cơ chế khác nhau một chút giữa các nhà cung cấp (gửi tệp, đối tượng tác vụ, thăm dò trạng thái, truy xuất đầu ra), nhưng hình thức cơ bản là nhất quán: gửi bây giờ, thu thập sau, trả ít hơn trên mỗi token so với phiên bản đồng bộ. Hãy kiểm tra tài liệu hiện tại của từng nhà cung cấp để biết khoảng thời gian xử lý chính xác và tỷ lệ chiết khấu áp dụng cho tài khoản và mô hình của bạn, vì các chi tiết này là đặc thù của nhà cung cấp và có thể thay đổi.

Cách thức hoạt động của hai Batch API đã được ghi nhận

Ở cấp độ cơ học, cả hai nhà cung cấp đều tuân theo một vòng đời tương tự:

1. Chuẩn bị yêu cầu. Bạn tập hợp các yêu cầu suy luận riêng lẻ mà bạn muốn xử lý, thường được định dạng dưới dạng tệp (OpenAI chấp nhận tệp yêu cầu được gắn ID tùy chỉnh; Gemini chấp nhận một lô các yêu cầu có cấu trúc).
2. Gửi tác vụ. Bạn tạo một đối tượng batch hoặc tài nguyên tác vụ tham chiếu đến đầu vào đã tải lên của bạn.
3. Thăm dò hoặc chờ hoàn tất. Tác vụ chuyển qua các trạng thái (đang xếp hàng, đang xử lý, đã hoàn tất hoặc thất bại) cho đến khi nhà cung cấp hoàn tất xử lý trong khoảng thời gian được ghi nhận.
4. Truy xuất đầu ra. Sau khi hoàn tất, bạn tải xuống hoặc tìm nạp tệp đầu ra hoặc tập kết quả, khớp từng phản hồi với yêu cầu gốc của nó theo ID.

Không nhà cung cấp nào xử lý các tác vụ batch ngay lập tức. Đó chính là mục đích của mô hình định giá này: tác vụ chạy theo lịch trình của nhà cung cấp, không phải của bạn, và bạn chấp nhận một độ trễ giới hạn để đổi lấy mức giá thấp hơn. Nếu sản phẩm của bạn không thể chấp nhận độ trễ đó, định giá theo lô không dành cho bạn bất kể bạn có thể tiết kiệm được bao nhiêu trên lý thuyết.

Khi nào định giá theo lô giúp tiết kiệm chi phí: Danh sách kiểm tra quyết định

Sử dụng danh sách kiểm tra này trước khi định tuyến khối lượng công việc đến một endpoint batch:

• Khối lượng công việc có hình thái phi tương tác tự nhiên không? Việc phân loại trên một tập dữ liệu, tạo embedding cho một kho tài liệu, quét kiểm duyệt nội dung hoặc các tác vụ tóm tắt hàng đêm đều phù hợp.
• Sản phẩm của bạn có thể chấp nhận khoảng thời gian xử lý được ghi nhận không? Nếu người dùng hoặc hệ thống hạ nguồn cần kết quả trong vòng vài giây hoặc vài phút, batch không phù hợp.
• Khối lượng có đủ lớn để tạo ra sự khác biệt không? Chiết khấu theo lô áp dụng trên mỗi token, vì vậy khoản tiết kiệm tuyệt đối sẽ tăng theo khối lượng. Một vài yêu cầu sẽ không làm thay đổi hóa đơn của bạn một cách đáng kể.
• Tác vụ có tính lũy đẳng (idempotent) hoặc có thể thử lại an toàn không? Vì các tác vụ batch chạy bất đồng bộ và có thể thất bại một phần, pipeline của bạn cần xử lý việc gửi lại hoặc hoàn thành một phần mà không làm hỏng trạng thái hạ nguồn.
• Lớp điều phối của bạn đã hỗ trợ thăm dò tác vụ async chưa? Nếu bạn đang xây dựng mô hình này lần đầu tiên, hãy dự trù thời gian kỹ thuật cho việc gửi tác vụ, thăm dò trạng thái và đối soát đầu ra.

Khía cạnh	Synchronous API	Batch (asynchronous) API
Độ trễ	Thường là vài giây	Vài phút đến vài giờ, giới hạn bởi khoảng thời gian được nhà cung cấp ghi nhận
Định giá	Mức giá tiêu chuẩn trên mỗi token	Mức giá chiết khấu trên mỗi token so với đồng bộ, theo tài liệu nhà cung cấp
Phù hợp nhất	Chat, tác nhân, tính năng sản phẩm trực tiếp	Phân loại hàng loạt, embedding, đánh giá ngoại tuyến, backfill
Xử lý lỗi	Lỗi ngay lập tức khi gọi	Trạng thái cấp tác vụ; có thể thất bại một phần trong lô
Chi phí kỹ thuật	Yêu cầu-phản hồi đơn giản	Yêu cầu logic gửi tác vụ, thăm dò và truy xuất đầu ra
Thứ tự đầu ra	Khớp với thứ tự gọi	Khớp theo ID yêu cầu tùy chỉnh, không phải thứ tự gọi

Khi nào định giá theo lô không phù hợp

Batch inference không phù hợp cho bất kỳ trường hợp nào mà con người hoặc hệ thống hạ nguồn đang chờ phản hồi. Điều này bao gồm:

• Các tác nhân hội thoại và sản phẩm chat. Người dùng mong đợi phản hồi trong vài giây, không phải sau một khoảng thời gian xử lý.
• Trợ lý lập trình và quy trình lập trình tác nhân. Các công cụ được xây dựng dựa trên các mô hình như Claude Sonnet 5 hoặc Kimi K2.7 Code phụ thuộc vào các vòng lặp phản hồi chặt chẽ giữa nhà phát triển và mô hình; việc xử lý theo lô sẽ phá vỡ hoàn toàn sự tương tác.
• Tạo nội dung thời gian thực cho các tính năng hướng người dùng, bao gồm tạo hình ảnh hoặc video theo yêu cầu thông qua các API như Nano Banana Pro hoặc Veo 3, nơi người dùng đang theo dõi chỉ báo tiến trình.
• Bất cứ thứ gì có yêu cầu về độ trễ cấp dịch vụ, ngay cả khi yêu cầu đó lỏng lẻo (ví dụ: dưới một phút). Các khoảng thời gian batch thường được đo bằng giờ, không phải giây.

Nếu một phần pipeline của bạn là thời gian thực và một phần không, hãy tách công việc ra. Định tuyến phần tương tác thông qua API đồng bộ và đẩy phần khối lượng lớn, chấp nhận độ trễ (tái lập chỉ mục hàng đêm, dán nhãn lại tập dữ liệu, chạy đánh giá) đến endpoint batch.

Hình thái yêu cầu thực tế

Lược đồ chính xác khác nhau giữa đối tượng batch của OpenAI và Batch API của Gemini, vì vậy hãy coi phần sau đây là một hình thái minh họa thay vì bản sao chính xác của định dạng yêu cầu từ bất kỳ nhà cung cấp nào. Hãy xác nhận tên trường và endpoint chính xác so với tài liệu hiện tại trước khi bạn triển khai.

# 1. Chuẩn bị tệp yêu cầu, mỗi yêu cầu có một ID tùy chỉnh
{"custom_id": "req-001", "method": "POST", "url": "/v1/chat/completions",
 "body": {"model": "your-selected-model", "messages": [{"role": "user", "content": "Classify this ticket."}]}}
{"custom_id": "req-002", "method": "POST", "url": "/v1/chat/completions",
 "body": {"model": "your-selected-model", "messages": [{"role": "user", "content": "Classify this ticket."}]}}

# 2. Gửi tác vụ batch
POST /v1/batches
{
  "input_file_id": "file-abc123",
  "endpoint": "/v1/chat/completions",
  "completion_window": "24h"
}

# 3. Thăm dò trạng thái tác vụ
GET /v1/batches/{batch_id}
# trả về trạng thái: queued | in_progress | completed | failed

# 4. Truy xuất đầu ra sau khi hoàn tất
GET /v1/files/{output_file_id}/content
# khớp từng phản hồi với yêu cầu của nó theo custom_id

Mô hình kỹ thuật cốt lõi là như nhau bất kể nhà cung cấp nào: xây dựng tệp yêu cầu của bạn với các ID ổn định, gửi tác vụ, thăm dò hoàn tất và đối soát đầu ra với danh sách yêu cầu gốc của bạn. Xây dựng logic thử lại xung quanh các lỗi một phần ở cấp độ tác vụ, vì một lô có thể hoàn thành với một số yêu cầu riêng lẻ bị lỗi ngay cả khi bản thân tác vụ đó thành công.

Kết hợp chiết khấu theo lô với lựa chọn mô hình

Định giá theo lô là một đòn bẩy. Nó kết hợp với, thay vì thay thế, các quyết định ở cấp độ mô hình và prompt được đề cập trong AI model routing benchmark và hướng dẫn giảm chi phí AI API. Một khối lượng công việc vừa đủ điều kiện cho batch vừa được phục vụ bởi một mô hình chi phí thấp hơn, chẳng hạn như DeepSeek V4 Flash, GLM-5.2 hoặc Gemini 3.5 Flash cho các tác vụ thân thiện với định tuyến, thường sẽ thấy khoản tiết kiệm tuyệt đối lớn hơn so với việc chỉ áp dụng một đòn bẩy. Trước khi cam kết một tác vụ lớn cho một mô hình và bậc giá duy nhất, hãy kiểm tra định giá và vị thế theo mô hình hiện tại tại /models/rankings, vì định giá tương đối giữa các mô hình tiên phong và chi phí thấp thay đổi khi các nhà cung cấp cập nhật dòng sản phẩm của họ.

Đối với các nhóm đang đánh giá xem có nên xây dựng hỗ trợ batch hay không, phép tính rất đơn giản: ước tính khối lượng token hàng tháng của bạn cho các tác vụ chấp nhận độ trễ, so sánh chiết khấu batch được ghi nhận với chi phí đồng bộ hiện tại của bạn trên cùng khối lượng đó và cân nhắc với chi phí kỹ thuật để xây dựng logic gửi tác vụ và thăm dò. Nếu khối lượng nhỏ, chiết khấu có thể không bù đắp được sự phức tạp tăng thêm.

Hạn chế

So sánh này dựa trên các cơ chế chung được OpenAI và Google ghi lại cho Batch API của họ tính đến ngày 14-07-2026. Tỷ lệ chiết khấu chính xác, độ dài khoảng thời gian xử lý, tính khả dụng theo mô hình và yêu cầu định dạng tệp là đặc thù của nhà cung cấp, thay đổi theo thời gian và không được nêu lại ở đây dưới dạng các con số cố định. Hãy xác minh định giá và các điều khoản batch hiện tại trực tiếp với tài liệu của từng nhà cung cấp trước khi lập ngân sách hoặc xây dựng. Bài viết này cũng không bao gồm hỗ trợ batch từ mọi nhà cung cấp mô hình; hãy kiểm tra xem mô hình và nhà cung cấp bạn chọn có xuất bản endpoint batch hay không trước khi lập kế hoạch xung quanh nó.

Câu hỏi thường gặp

Batch inference rẻ hơn bao nhiêu so với các cuộc gọi đồng bộ? Cả OpenAI và Google đều ghi nhận chiết khấu cho xử lý batch so với mức giá đồng bộ tiêu chuẩn của họ, nhưng tỷ lệ phần trăm chính xác là đặc thù của nhà cung cấp và thời điểm. Hãy kiểm tra trang định giá hiện tại cho nhà cung cấp và mô hình của bạn trước khi ước tính khoản tiết kiệm.

Điều gì xảy ra nếu tác vụ batch của tôi không hoàn thành trong khoảng thời gian xử lý? Tài liệu của nhà cung cấp mô tả các trạng thái của tác vụ (chẳng hạn như queued, in progress, completed và failed). Hãy xem lại tài liệu của từng nhà cung cấp về cách họ xử lý các tác vụ vượt quá khoảng thời gian hoàn thành, vì hành vi có thể khác nhau tùy theo nhà cung cấp và có thể thay đổi.

Tôi có thể sử dụng batch inference cho các tính năng chat thời gian thực không? Không. Các tác vụ batch được xử lý bất đồng bộ trong một khoảng thời gian có thể kéo dài từ vài phút đến nhiều giờ, điều này khiến chúng không phù hợp với bất kỳ khối lượng công việc nào mà người dùng hoặc hệ thống đang chờ phản hồi ngay lập tức. Sử dụng API đồng bộ cho các tính năng tương tác và dành riêng các endpoint batch cho các tác vụ có khối lượng lớn, chấp nhận độ trễ.

Nếu bạn đang đánh giá xem định giá theo lô có phù hợp với khối lượng công việc của mình hay không, hãy so sánh các mức giá và xếp hạng theo mô hình hiện tại, sau đó bắt đầu bằng cách lập bản đồ các tác vụ chấp nhận độ trễ của bạn dựa trên danh sách kiểm tra ở trên trước khi bạn cam kết thời gian kỹ thuật cho logic gửi tác vụ và thăm dò.