Batch processing

Batch processing คือวิธีส่งคำขอจำนวนมากไปให้ประมวลผลรวดเดียวเป็นชุด แทนที่จะยิงทีละคำขอแล้วนั่งรอคำตอบกลับมาทันที ผู้ให้บริการโมเดล (model-provider) จะรับชุดงานนั้นไปทยอยทำแบบ asynchronous คือไม่ตอบกลับทันทีแต่ทำอยู่เบื้องหลังแล้วค่อยส่งผลคืนตอนจบ โดยส่วนใหญ่จะได้กลับมาเป็นไฟล์ผลลัพธ์ไฟล์เดียว ข้อแลกเปลี่ยนตรงไปตรงมา คือยอมให้เวลารอ (latency) ยาวขึ้นจากหลักวินาทีเป็นหลักนาทีถึงหลักชั่วโมง เพื่อแลกกับค่าใช้จ่ายที่ถูกลง การใช้งานทำผ่าน api ของผู้ให้บริการ ไม่ใช่หน้าจอแชตที่คนทั่วไปใช้กัน และเอกสารของ anthropic ระบุว่ารูปแบบนี้เหมาะกับกรณีที่ต้องประมวลผลข้อมูลปริมาณมาก ไม่ต้องการคำตอบทันที และอยากคุมต้นทุน

ตัวเลขที่ประกาศไว้ต้องดูเป็นรายเจ้า เอกสาร Message Batches API ของ Anthropic ที่ตรวจเมื่อ 15 สิงหาคม 2026 เขียนว่าคิดค่าใช้งานทั้งหมดที่ 50% ของราคา API ปกติ ทั้งฝั่ง input-tokens และ output-tokens หนึ่งชุดจำกัดไว้ที่ 100,000 คำขอหรือขนาด 256 MB แล้วแต่ว่าอย่างไหนถึงก่อน งานส่วนใหญ่เสร็จภายใน 1 ชั่วโมง ชุดที่ทำไม่เสร็จภายใน 24 ชั่วโมงจะหมดอายุ และผลลัพธ์ดึงกลับมาได้ 29 วันนับจากวันที่สร้าง หลังจากนั้นยังเปิดดูตัว batch ได้อยู่แต่ดึงผลกลับไม่ได้แล้ว ส่วนคู่มือ Batch API ของ openai เขียนว่าลด 50% เมื่อเทียบกับ API แบบ synchronous หนึ่งชุดใส่ได้ไม่เกิน 50,000 คำขอ ไฟล์ input ไม่เกิน 200 MB และแต่ละชุดเสร็จภายใน 24 ชั่วโมงโดยบ่อยครั้งเร็วกว่านั้น ชุดที่ทำไม่ทันจะเปลี่ยนสถานะเป็น expired คำขอที่ยังค้างอยู่ถูกยกเลิก แต่ผลของคำขอที่ทำเสร็จไปแล้วยังเอาออกมาได้จากไฟล์ผลลัพธ์ โดยคู่มือระบุว่า token ที่ใช้ไปกับคำขอที่ทำเสร็จแล้วยังถูกเรียกเก็บเงิน ฝั่ง Google ก็เขียนไว้ในคู่มือ Batch API ของ Gemini ว่าคิดที่ 50% ของราคาปกติเช่นกัน โดยตั้งเป้าเวลาส่งงานคืนไว้ที่ 24 ชั่วโมงแต่ส่วนใหญ่เร็วกว่านั้นมาก

คนทำงานจะเจอคำนี้ตอนมีงานกองใหญ่ที่ไม่เร่ง เช่น จัดหมวดใบเสร็จทั้งปี สรุปรีวิวลูกค้าย้อนหลังหลายหมื่นรายการ หรือแปลคลังเอกสารทั้งชุด ก่อนตัดสินใจมีสามเรื่องที่ต้องเช็ก เรื่องแรกคือฟีเจอร์ที่ใช้ร่วมกันไม่ได้ เอกสารของ Anthropic ระบุว่าคำขอในชุดใส่ได้เกือบทุกอย่างที่ Messages API ทำได้ เช่น การอ่านภาพ การเรียก tool บทสนทนาหลายรอบ และ extended thinking แต่มีพารามิเตอร์กลุ่มเล็กๆ ที่ใส่ไม่ได้และจะถูกตีกลับเป็น error เช่น stream: true และ max_tokens: 0 เรื่องที่สองคือกรอบเวลาไม่ใช่คำมั่นว่าจะเร็ว หน้าเดียวกันเขียนว่าการประมวลผลอาจช้าลงได้ตามความต้องการใช้งานในระบบขณะนั้นและตามปริมาณคำขอของผู้ใช้เอง และในกรณีนั้นอาจเห็นคำขอหมดอายุหลัง 24 ชั่วโมงมากขึ้น ข้อดีคือเอกสารของ Anthropic ระบุว่าคำขอที่หมดอายุหรือถูกยกเลิกก่อนถูกส่งเข้าโมเดลจะไม่ถูกเรียกเก็บเงิน เรื่องที่สามคือเรื่องงบ หน้าเดียวกันเตือนว่าเพราะ batch ประมวลผลพร้อมกันจำนวนมาก ยอดใช้จ่ายอาจเกินเพดานที่ตั้งไว้ใน Workspace ไปเล็กน้อย ใครที่ตั้ง ai-spend-cap ไว้ชิดเพดานควรเผื่อจุดนี้ด้วย

ตัวอย่างจากบทสนทนาจริง

ฝ่ายการตลาด: ทีม data บอกว่าจะเอารีวิวลูกค้า 40,000 รายการไปให้ AI จัดหมวดแบบ batch แล้วบอกว่าต้องรอถึงพรุ่งนี้เช้า ทำไมไม่ยิงทีละอันให้จบวันนี้เลยล่ะคะ

ทีม data: เพราะราคาต่างกันครึ่งหนึ่งครับ คู่มือของทั้ง Anthropic และ OpenAI เขียนตรงกันว่างานที่ส่งแบบ batch คิดที่ 50% ของราคาปกติ แลกกับการยอมรอ ของเราไม่ได้ต้องใช้ผลเดี๋ยวนี้ รอข้ามคืนได้สบาย แต่ถ้าเป็นงานที่ลูกค้านั่งรอหน้าจออยู่ เช่น แชตตอบคำถามหน้าเว็บ อันนั้นใช้ batch ไม่ไหว เพราะกรอบเวลาที่คู่มือระบุยาวถึงหลักชั่วโมง ต้องยิงตรงเพื่อให้ได้คำตอบทันที

ระวังสับสนกับ

• latency : latency คือเวลาที่รอคำตอบของคำขอเดียว ส่วน batch processing คือการยอมให้เวลารอนั้นยาวขึ้นทั้งชุดเพื่อแลกกับราคาที่ถูกลง งานที่มีคนนั่งรอหน้าจอจึงไม่เหมาะกับ batch
• rate-limit : rate limit คือเพดานจำนวนคำขอหรือ token ต่อช่วงเวลา ส่วน batch processing คือวิธีส่งงาน คู่มือของ OpenAI ระบุว่าเพดานของ Batch API แยกกองจากเพดานรายโมเดลแบบปกติ การส่งงานแบบ batch จึงไม่ไปกิน token ของโควตาปกติ แต่หน้าเดียวกันระบุด้วยว่า Batch API มีเพดานของตัวเองสามแบบ คือจำนวนคำขอต่อชุด จำนวน prompt token ที่รอคิวได้ต่อโมเดล และการสร้าง batch ได้ไม่เกิน 2,000 ชุดต่อชั่วโมง ส่วนเอกสารของ Anthropic ก็เขียนว่ายังมี rate limit ของ Batches API เองอยู่เหมือนกัน
• total-cost-of-ownership : ส่วนลดครึ่งราคาลดเฉพาะค่า token ส่วน total cost of ownership รวมงานที่ต้องเขียนเพิ่มเพื่อเตรียมไฟล์ ตามสถานะ และรวมผลกลับเข้าระบบ ซึ่งไม่ได้ลดตามไปด้วย