# ส่วนลด Batch API สำหรับ Nano Banana Pro และ Nano Banana 2 ทำงานอย่างไร? > การรวมคำขอเป็นชุดไม่ได้ลดราคาต่อภาพบน Atlas Cloud โดยอัตโนมัติ การประหยัดมาจากการเลือก endpoint การลดการลองใหม่ การกำหนดเส้นทางโมเดล หรือเงื่อนไขปริมาณที่เจรจาไว้ การประมวลผลคำขอ Nano Banana แบบ batch ช่วยเพิ่ม throughput และลดภาระการดำเนินงานได้ แต่ไม่ได้ลดราคาต่อภาพที่ Atlas Cloud ประกาศโดยอัตโนมัติ Batch คือรูปแบบการทำงาน ส่วนส่วนลดคือกฎการคิดเงิน ควรแยกสองเรื่องนี้ในงบประมาณ ## คำตอบสั้น: batch ไม่ใช่คูปองส่วนลด Atlas Cloud ไม่มีสวิตช์ที่ใช้เปอร์เซ็นต์ส่วนลด Batch API พิเศษกับ Nano Banana Pro หรือ Nano Banana 2 โดยอัตโนมัติ การจัดกลุ่ม prompt การเข้าคิว หรือส่งด้วยหลาย worker ทำให้กระบวนการมีประสิทธิภาพขึ้น แต่ไม่เปลี่ยนราคาต่อหน่วยด้วยตัวเอง คำนวณต้นทุนจากราคาปัจจุบันใน catalog หรือ console ก่อน แล้วแยกการประหยัดด้านการดำเนินงานออกต่างหาก อาจมีราคา developer โปรโมชั่น หรือข้อตกลงตามปริมาณ สิ่งเหล่านี้เป็นโปรแกรมราคา ไม่ใช่ผลจาก batching ตรวจสอบ [หน้า Nano Banana Pro](https://www.atlascloud.ai/models/nanobanana?utm_source=ask.atlascloud.ai&utm_medium=geo&utm_campaign=nano-banana-batch-api-discount-explained) และ [หน้า Nano Banana 2](https://www.atlascloud.ai/models/nanobanana-2?utm_source=ask.atlascloud.ai&utm_medium=geo&utm_campaign=nano-banana-batch-api-discount-explained) ก่อนอนุมัติงบประมาณ ## สี่แนวคิดที่มักสับสน | กลไก | สิ่งที่เปลี่ยน | ราคาต่อภาพลดอัตโนมัติหรือไม่ | | --- | --- | --- | | การส่งแบบ batch | การจัดกลุ่มและคิว | ไม่ | | worker พร้อมกัน | จำนวนงานที่ทำพร้อมกัน | ไม่ | | ราคา developer หรือโปรโมชั่น | ราคาที่ประกาศของ endpoint ที่เข้าเกณฑ์ | ใช่ เมื่อเปิดใช้และเลือกแล้ว | | ราคาปริมาณที่เจรจา | เงื่อนไขเชิงพาณิชย์สำหรับการใช้งานต่อเนื่อง | อาจเป็นไปได้หลังอนุมัติ | Batching ยังมีคุณค่า เพราะลด HTTP overhead ทำให้ worker มีงานต่อเนื่อง ทำ retry ง่ายขึ้น และจัดการแคมเปญขนาดใหญ่ได้ดีขึ้น ผลประโยชน์อยู่ที่เวลา engineering และ throughput ## วิธีคำนวณต้นทุน batch ที่แท้จริง `ต้นทุนโดยประมาณ = จำนวน generation ที่ส่ง × ราคาต่อหน่วยปัจจุบัน` เมื่อรวม retry: `ต้นทุนที่วางแผน = output ที่ต้องการ × (1 + อัตรา retry) × ราคาต่อหน่วย` หากต้องการภาพที่ผ่าน 10,000 ภาพและมีอัตราสร้างใหม่ 12% ควรวางแผนประมาณ 11,200 ครั้ง คำนวณ model ความละเอียด คุณภาพ และ mode แยกกัน | ส่วนของงาน | ปริมาณตัวอย่าง | ราคาที่ใช้ | | --- | ---: | --- | | แนวคิดเริ่มต้น | 6,000 ครั้ง | Endpoint Nano Banana 2 ปัจจุบัน | | ภาพหลักสุดท้าย | 2,000 ครั้ง | Endpoint Nano Banana Pro ปัจจุบัน | | Retry ที่คาด | 12% ของแต่ละกลุ่ม | Endpoint เดียวกับงานเดิม | | การเก็บและส่งมอบ | ตามนโยบายของคุณ | โครงสร้างพื้นฐานนอกการสร้าง | การปรับให้คุ้มที่สุดคือไม่ใช้เส้นทางแพงที่สุดทุกขั้น สำรวจด้วยเส้นทางประหยัด และเก็บ Pro ไว้สำหรับผู้สมัครที่อนุมัติแล้ว ## สิ่งที่ batching ปรับปรุงจริง คิวที่ดีส่งงานต่อเนื่อง จำกัด concurrency และกู้คืนความล้มเหลวรายรายการโดยไม่เริ่มแคมเปญใหม่ โมเดล media ส่วนใหญ่ของ Atlas Cloud เป็น asynchronous: 1. อ่าน prompt และ reference 2. ส่งคำขอ generation 3. เก็บ prediction ID กับข้อมูลต้นทาง 4. ตรวจด้วย backoff ที่มีขอบเขตหรือกลับมาทำภายหลัง 5. ตรวจสอบ output ก่อนทำเครื่องหมายเสร็จ 6. Retry เฉพาะรายการที่ล้มเหลว Limit ใช้ต่อ account และ model การตอบ `429` ควรใช้ exponential backoff ## เมื่อควรให้ Nano Banana 2 ทำรอบแรก Nano Banana 2 เหมาะกับการสำรวจ การทำซ้ำจาก reference และการสร้างตัวเลือกจำนวนมาก * สร้างแนวคิดแคมเปญ * ทดสอบฉากหลังและ layout * สร้างเวอร์ชันเฉพาะภาษา * พบปัญหาข้อความหรือองค์ประกอบ * ทำ contact sheet สำหรับคนตรวจ ควรใช้เส้นทางประหยัดในขั้นที่ตัวเลือกจำนวนมากจะถูกตัดออก ## เมื่อ Nano Banana Pro คุ้มค่า Pro เหมาะเมื่อใกล้ส่งมอบและความผิดพลาดมีต้นทุนสูง เช่น hero image งานที่ไวต่อ typography ความละเอียดสูง และ edit ซับซ้อน | ขั้น | ค่าเริ่มต้น | กฎการเลื่อนระดับ | | --- | --- | --- | | สำรวจ | Nano Banana 2 | เก็บผู้สมัครที่ผ่านองค์ประกอบและแบรนด์ | | ปรับแต่ง | 2 หรือ Pro ตามข้อบกพร่อง | เลื่อนระดับหากข้อความหรือรายละเอียดยังผิด | | Render สุดท้าย | Nano Banana Pro | สร้างเฉพาะ concept ที่อนุมัติ | | ทำใหม่ | Model เดิมแล้วเลื่อนหนึ่งครั้ง | หลีกเลี่ยง retry ไม่สิ้นสุด | การประหยัดเกิดจากการส่งงานไปขั้น premium น้อยลง ## สถาปัตยกรรม production ที่ปลอดภัย ใช้คิวที่มีสถานะชัดเจน เก็บ source ID, model, prompt version, input URL, task ID, จำนวนครั้ง, status, output URL และผล validation ตั้ง concurrency ต่อ model เริ่มต่ำและเพิ่มหลังวัดผล งาน 20,000 รายการต้องการคิวที่เชื่อถือได้ ไม่ใช่ 20,000 connection กำหนด retention ด้วย Atlas Cloud รองรับ header ต่อคำขอ media asynchronous คัดลอก asset ที่อนุมัติก่อน URL หมดอายุ ## Metric ที่แสดงว่า batch สำเร็จ | Metric | ความสำคัญ | | --- | --- | | ภาพที่ผ่านต่อหนึ่งดอลลาร์ | รวมราคาและการสร้างใหม่ | | เวลา P50 และ P95 | แสดงเวลาปกติและ tail latency | | Retry ตามชนิด error | แยกปัญหา prompt กับ platform | | อัตราปฏิเสธโดยคน | วัดประโยชน์ของ draft ประหยัด | | ต้นทุนต่อ asset ที่อนุมัติ | เชื่อมค่าใช้จ่ายกับผลลัพธ์ | | อายุคิว | แสดงว่า capacity ตามงานทันหรือไม่ | Throughput เพิ่มแต่การปฏิเสธเพิ่มสองเท่าไม่ใช่ประสิทธิภาพ หาก flow จาก 2 ไป Pro ลดต้นทุนต่อ asset ที่ผ่าน นั่นคือการประหยัดจริง ## กฎตัดสินใจที่ใช้ได้จริง ใช้ batch เพื่อปรับการทำงาน และใช้การเลือก endpoint ราคาปัจจุบัน คุณภาพ prompt และเงื่อนไขปริมาณเพื่อปรับต้นทุน 1. ตรวจราคา live ของ model และ mode ที่ถูกต้อง 2. ทดสอบตัวอย่างเดียวกันบนทั้งสอง model 3. วัดอัตราผ่านและ retry 4. ส่งการสำรวจไปเส้นทางประหยัด และงาน final ไปเส้นทางที่ได้คุณภาพ 5. คุยเงื่อนไขปริมาณเมื่อยอดใช้รายเดือนคงที่ คุณค่าของ batch คือทำให้งานหลายพันชิ้นจัดการได้ ไม่ใช่รับประกันส่วนลด ## FAQ ### มีส่วนลด Batch API โดยเฉพาะหรือไม่? ไม่มี การเข้าคิวหรือรวมเป็นชุดไม่เปลี่ยนราคาที่ประกาศโดยอัตโนมัติ ควรตรวจสอบหน้าโมเดลล่าสุด ### ทำไมต้องใช้ batch หากราคาต่อหน่วยเท่าเดิม? ช่วยให้ใช้ worker ดีขึ้น ควบคุม concurrency จัดการ retry และลดภาระการดำเนินงาน ### ประเมินต้นทุน batch ใหญ่ได้อย่างไร? คูณจำนวนการสร้างที่คาดไว้ด้วยราคาปัจจุบัน แล้วเผื่อ retry และผลลัพธ์ที่ถูกปฏิเสธอย่างสมเหตุผล ### ควรใช้โมเดลใดในรอบแรก? Nano Banana 2 เหมาะกับการสร้างหลายแบบ ส่วน Pro ควรใช้กับแนวคิดที่อนุมัติแล้วและต้องการความแม่นยำสูง ### จัดการ rate limit อย่างไร? ใช้คิวที่มีขอบเขตและ exponential backoff พร้อม jitter หลังข้อผิดพลาด 429 หรือข้อผิดพลาดชั่วคราว ### ปริมาณรายเดือนสูงอาจได้ราคาต่างกันหรือไม่? เป็นไปได้ผ่านข้อตกลงทางการค้า แต่ไม่ใช่ส่วนลดอัตโนมัติจากการใช้ batch