นักศึกษาฝึกงานเผลอรัน Prompt วนลูปข้ามคืน จะกันบิล AI พุ่งแบบนี้ได้ยังไง

เหตุการณ์ที่ทีมวิศวกรรมทีมหนึ่งเจอเริ่มจากเรื่องเล็ก ๆ นักศึกษาฝึกงานที่เพิ่งเข้ามาไม่กี่สัปดาห์เขียนสคริปต์ทดสอบ Prompt สำหรับฟีเจอร์แนะนำสินค้า แล้วตั้งให้มันวนซ้ำเพื่อดูความสม่ำเสมอของคำตอบ ปัญหาคือสคริปต์นั้นไม่มีเงื่อนไขหยุดที่ชัดเจน และเขาลืมปิดเครื่องก่อนกลับบ้านคืนวันศุกร์

เช้าวันจันทร์ทีมเปิดดู Dashboard แล้วพบว่ามี Request เรียกโมเดลภาษาไปมากกว่าปกติหลายเท่าตัวตลอดสองวันที่ผ่านมา โชคดีที่ก่อนหน้านั้นทีมเคยตั้ง Spend Limits ไว้ในระดับ Gateway ทำให้ Request ส่วนเกินถูกปฏิเสธไปตั้งแต่ช่วงเช้าวันเสาร์ ความเสียหายจึงจำกัดอยู่แค่หลักชั่วโมงแรกของคืนนั้น ไม่ใช่ทั้งสองวันเต็ม

เหตุการณ์แบบนี้ไม่ใช่เรื่องแปลกสำหรับทีมที่เปิดให้สมาชิกหลายคนเข้าถึง AI Provider ผ่าน Gateway เดียวกัน เพราะยิ่งทีมโตขึ้น ความเสี่ยงที่จะมีคนเผลอเขียนโค้ดวนลูปผิดพลาด หรือมีการใช้งานผิดปกติจากบัญชีใดบัญชีหนึ่งก็ยิ่งสูงตาม บทความนี้จะพาไปดูว่า Spend Limits ทำงานยังไง ตั้งได้กี่ระดับ และมีจุดไหนที่ทีมมักตั้งพลาดจนป้องกันไม่ได้จริงตามที่ตั้งใจ

Spend Limits คืออะไร ต่างจาก Rate Limit ทั่วไปตรงไหน

Spend Limits คือกลไกใน Cloudflare AI Gateway ที่กำหนดเพดานการใช้งานตามหน่วยที่เกี่ยวข้องกับต้นทุนจริง ไม่ว่าจะเป็นจำนวน Token ที่ประมวลผลได้ จำนวน Request ที่เรียกได้ หรือค่าใช้จ่ายโดยประมาณที่คำนวณจากราคาของแต่ละโมเดล ภายในช่วงเวลาที่กำหนดไว้ เช่น ต่อชั่วโมง ต่อวัน หรือต่อเดือน

หลายคนสับสนระหว่าง Spend Limits กับ Rate Limiting ทั่วไป ทั้งที่สองอย่างนี้แก้ปัญหาคนละแบบ Rate Limiting เน้นควบคุมความถี่ของ Request ในหน่วยเวลาสั้น ๆ เพื่อป้องกันการยิงถี่เกินไปจนระบบรับไม่ไหว ส่วน Spend Limits เน้นควบคุมยอดสะสมของต้นทุนหรือปริมาณการใช้งานในหน่วยเวลาที่ยาวกว่า เพื่อป้องกันไม่ให้ยอดรวมเกินงบที่ตั้งใจไว้ แม้ Request แต่ละครั้งจะไม่ได้ยิงถี่ผิดปกติเลยก็ตาม

ในทางปฏิบัติทีมส่วนใหญ่ควรใช้ทั้งสองกลไกร่วมกัน Rate Limiting ป้องกันการยิงถี่ผิดปกติในระยะสั้น ส่วน Spend Limits ป้องกันยอดสะสมที่ค่อย ๆ ไต่ขึ้นจนเกินงบโดยไม่มีใครสังเกตทันเวลา ซึ่งเป็นสถานการณ์ที่พบบ่อยกว่าการโจมตีแบบยิงรัวจริง ๆ เสียอีก

ทำไมทีมที่เปิด AI ให้หลายคนใช้ถึงต้องมีเพดานงบ

ปัญหาเรื่องบิล AI พุ่งเกินคาดมักไม่ได้มาจากการโจมตีจากภายนอก แต่มาจากความผิดพลาดภายในทีมเองมากกว่า เช่น โค้ดที่มี Loop ไม่มีเงื่อนไขหยุด ฟีเจอร์ทดลองที่เปิดให้ผู้ใช้ทั่วไปทดสอบฟรีโดยไม่มีการจำกัดจำนวนครั้ง หรือแม้แต่การตั้ง Retry อัตโนมัติที่ยิงซ้ำเมื่อ Request แรกล้มเหลวโดยไม่มีเพดานจำนวนครั้งที่ชัดเจน

• ทีมพัฒนาที่มีสมาชิกหลายคนเข้าถึง API Key เดียวกัน — เมื่อไม่มีการแยกโควตาต่อคน ความผิดพลาดของคนเดียวกระทบงบรวมของทั้งทีมได้ทันที
• ฟีเจอร์ที่เปิดให้ผู้ใช้ปลายทางเรียก AI ได้โดยตรง — เช่น แชทบอทหรือฟีเจอร์สรุปเนื้อหาที่ผู้ใช้กดใช้ได้ไม่จำกัดครั้ง ถ้าไม่มีเพดาน ต้นทุนจะแปรผันตรงกับพฤติกรรมผู้ใช้ที่ควบคุมไม่ได้
• สภาพแวดล้อมทดสอบ (Staging/Development) ที่ใช้ API Key เดียวกับ Production — โค้ดทดสอบที่มีบั๊กสามารถสร้างค่าใช้จ่ายจริงได้เหมือนกับโค้ด Production ทุกประการ
• ระบบ Retry หรือ Fallback ที่ไม่มีเพดานจำนวนครั้ง — ถ้า Provider ตอบช้าหรือ Error ต่อเนื่อง ระบบที่ Retry ไม่จำกัดอาจยิง Request ซ้ำจนสะสมต้นทุนสูงโดยไม่มีใครรู้ทันเวลา

กลไกเบื้องหลัง: นับต้นทุนยังไง และตัดสินใจยังไงว่าถึงเวลาระงับ

เมื่อ Request วิ่งผ่าน Gateway ระบบจะประเมินต้นทุนโดยประมาณของ Request นั้นตามอัตราค่าใช้จ่ายของโมเดลที่เรียก แล้วบวกสะสมเข้ากับยอดรวมของหน่วยที่เกี่ยวข้อง เช่น ยอดรวมของ Gateway ทั้งก้อน ยอดรวมของผู้ใช้คนนั้น หรือยอดรวมของโมเดลตัวนั้นโดยเฉพาะ ขึ้นอยู่กับว่าตั้งเพดานไว้ที่ระดับไหน

เมื่อยอดสะสมใกล้ถึงเพดานที่ตั้งไว้ ทีมสามารถกำหนดพฤติกรรมได้หลายแบบ บางทีมเลือกให้แค่ส่งการแจ้งเตือนแต่ยังปล่อยให้ Request ผ่านต่อไปได้ เหมาะกับกรณีที่ต้องการแค่รู้ทันสถานการณ์แต่ไม่อยากให้บริการหยุดชะงัก ส่วนบางทีมเลือกให้ระงับ Request ถัดไปทันทีเมื่อถึงเพดาน เหมาะกับกรณีที่ความเสี่ยงด้านต้นทุนสำคัญกว่าความต่อเนื่องของบริการ

จุดที่ต้องเข้าใจคือการประเมินต้นทุนแบบนี้เป็นค่าประมาณที่คำนวณจากอัตราที่ทราบล่วงหน้า ไม่ใช่ตัวเลขบิลจริงที่ Provider จะเรียกเก็บเป๊ะเสมอไป เพราะบางกรณี Provider อาจปรับราคาหรือมีค่าธรรมเนียมเพิ่มเติมที่ไม่ได้สะท้อนในสูตรคำนวณของ Gateway ทันที จึงควรใช้ Spend Limits เป็นชั้นป้องกันความเสี่ยง ไม่ใช่แหล่งข้อมูลบิลที่แม่นยำร้อยเปอร์เซ็นต์

ตั้งเพดานได้กี่ระดับ และควรเลือกใช้ระดับไหนกับงานแบบไหน

ความยืดหยุ่นของ Spend Limits อยู่ที่การเลือกระดับที่จะตั้งเพดาน ซึ่งแต่ละระดับเหมาะกับสถานการณ์ต่างกัน

• ระดับ Gateway ทั้งก้อน — เหมาะเป็นเพดานสุดท้ายเพื่อกันไม่ให้ค่าใช้จ่ายรวมทั้งระบบเกินงบเดือนที่วางแผนไว้ ไม่ว่าปัญหาจะเกิดจากจุดไหนก็ตาม
• ระดับผู้ใช้แต่ละคน (Per-User) — เหมาะกับทีมที่มีสมาชิกหลายคนเรียก AI ผ่าน Gateway เดียวกัน หรือแอปที่มีผู้ใช้ปลายทางจำนวนมาก เพราะป้องกันไม่ให้บัญชีเดียวใช้งบเกินสัดส่วนที่เหมาะสม
• ระดับโมเดลแต่ละตัว (Per-Model) — เหมาะกับทีมที่ใช้หลายโมเดลพร้อมกันและอยากควบคุมว่าโมเดลราคาสูงจะไม่ถูกเรียกเกินความจำเป็น ในขณะที่โมเดลราคาถูกกว่ายังใช้งานได้ตามปกติ
• ระดับ Endpoint หรือฟีเจอร์เฉพาะ — เหมาะเมื่อบางฟีเจอร์มีความเสี่ยงสูงกว่าฟีเจอร์อื่น เช่น ฟีเจอร์ทดลองที่เพิ่งเปิดตัว ควรมีเพดานแยกต่างหากจากฟีเจอร์หลักที่ผ่านการทดสอบมาแล้ว

ขั้นตอนตั้ง Spend Limit ครั้งแรกให้ครอบคลุมและไม่กระทบผู้ใช้จริง

1. สำรวจข้อมูลย้อนหลังก่อนว่าปกติทีมใช้งบต่อวันหรือต่อเดือนอยู่ที่เท่าไร โดยดูจาก Log ที่ AI Gateway เก็บไว้ เพื่อตั้งเพดานที่สมเหตุสมผล ไม่ใช่ตั้งแบบเดาสุ่ม
2. เริ่มตั้งเพดานระดับ Gateway ทั้งก้อนก่อนเป็นชั้นป้องกันสุดท้าย โดยตั้งให้สูงกว่าค่าใช้จ่ายปกติพอสมควรเพื่อไม่ให้กระทบการใช้งานจริงในสถานการณ์ปกติ
3. แยกเพดานระดับผู้ใช้หรือระดับฟีเจอร์สำหรับจุดที่มีความเสี่ยงสูงเป็นพิเศษ เช่น สภาพแวดล้อมทดสอบ หรือฟีเจอร์ที่เพิ่งเปิดให้ผู้ใช้ทั่วไปทดลอง
4. ตั้งค่าการแจ้งเตือนล่วงหน้าก่อนถึงเพดานจริง เช่นแจ้งเตือนเมื่อใช้ไปแล้วแปดสิบเปอร์เซ็นต์ของเพดาน เพื่อให้ทีมมีเวลาตรวจสอบก่อนที่ Request จะถูกระงับจริง
5. ทดสอบพฤติกรรมเมื่อถึงเพดานในสภาพแวดล้อมทดสอบก่อน เพื่อยืนยันว่าแอปพลิเคชันจัดการกับ Response ที่ถูกปฏิเสธได้อย่างเหมาะสม ไม่ใช่แสดง Error ที่ทำให้ผู้ใช้งงว่าเกิดอะไรขึ้น

เทียบพฤติกรรมระบบก่อนและหลังตั้ง Spend Limits

ตัวอย่างสมมติ: ฟีเจอร์ทดลอง AI ที่เปิดให้ผู้ใช้ฟรีใช้แบบไม่จำกัด

ลองดูสถานการณ์สมมติของทีมสตาร์ทอัพที่เพิ่งเปิดตัวฟีเจอร์สรุปบทความอัตโนมัติให้ผู้ใช้แผนฟรีทดลองใช้ โดยตั้งใจให้เป็นฟีเจอร์ดึงดูดผู้ใช้ใหม่ แต่ในช่วงแรกทีมยังไม่ได้ตั้งเพดานการใช้งานต่อผู้ใช้หนึ่งคนไว้เลย เพราะคิดว่าผู้ใช้ทั่วไปคงไม่ได้เรียกใช้บ่อยขนาดนั้น

หลังเปิดตัวได้ไม่กี่วัน มีผู้ใช้กลุ่มหนึ่งเขียนสคริปต์อัตโนมัติมาเรียกฟีเจอร์นี้ซ้ำ ๆ เพื่อทดสอบขีดจำกัดของระบบ ทำให้ยอดการเรียกใช้จากผู้ใช้กลุ่มนี้พุ่งสูงกว่าผู้ใช้ทั่วไปหลายสิบเท่าภายในเวลาไม่กี่ชั่วโมง ทีมตรวจพบความผิดปกตินี้จากการแจ้งเตือนที่ตั้งไว้ล่วงหน้าในระดับผู้ใช้ ก่อนที่ยอดรวมทั้งระบบจะกระทบงบเดือนอย่างมีนัยสำคัญ

หลังเหตุการณ์นี้ทีมปรับมาตั้งเพดานระดับผู้ใช้แยกตามแผนสมาชิก โดยผู้ใช้แผนฟรีมีเพดานต่ำกว่าผู้ใช้แผนเสียเงินอย่างชัดเจน พร้อมตั้งการแจ้งเตือนที่ระดับแปดสิบเปอร์เซ็นต์ของเพดานแต่ละระดับ ทำให้ทีมเห็นสัญญาณล่วงหน้าก่อนที่ปัญหาจะลุกลามในทุกครั้งที่มีพฤติกรรมผิดปกติเกิดขึ้นอีก

ตัวเลขและสัดส่วนในตัวอย่างนี้เป็นกรอบสมมติเพื่อประกอบการอธิบายหลักการเท่านั้น ผลลัพธ์จริงของแต่ละทีมขึ้นอยู่กับลักษณะผู้ใช้ ประเภทฟีเจอร์ และโครงสร้างแผนราคาของแต่ละผลิตภัณฑ์ ไม่ใช่ตัวเลขที่รับประกันว่าทุกระบบจะเจอสถานการณ์เดียวกัน

ทำแบบนี้แล้วพัง เพราะตั้ง Spend Limits ไว้แต่ไม่มีใครดู

• ตั้งเพดานไว้ครั้งเดียวแล้วไม่เคยทบทวนอีก — เมื่อธุรกิจโตขึ้นและปริมาณการใช้งานปกติเพิ่มขึ้นตามธรรมชาติ เพดานเดิมที่เคยเหมาะสมอาจกลายเป็นตัวบล็อกการใช้งานจริงโดยไม่จำเป็น
• ไม่ได้เชื่อมการแจ้งเตือนไปยังช่องทางที่ทีมเห็นจริง — ถ้าแจ้งเตือนไปที่อีเมลที่ไม่มีใครเปิดอ่าน หรือ Dashboard ที่ไม่มีใครเข้าไปดูเป็นประจำ ประโยชน์ของการแจ้งเตือนล่วงหน้าก็แทบไม่มีความหมาย
• ตั้งเพดานเฉพาะระดับ Gateway ทั้งก้อนโดยไม่แยกระดับผู้ใช้ — ทำให้เมื่อมีผู้ใช้คนเดียวใช้งานผิดปกติ ผู้ใช้คนอื่นทั้งหมดพลอยได้รับผลกระทบไปด้วยเมื่อเพดานรวมถูกใช้จนหมด
• ไม่ได้ทดสอบว่าแอปพลิเคชันรับมือกับ Request ที่ถูกปฏิเสธยังไง — ถ้าโค้ดฝั่งแอปไม่ได้ดักจับกรณีนี้ไว้ ผู้ใช้อาจเห็นข้อความ Error ที่ไม่เป็นมิตร แทนที่จะเห็นข้อความอธิบายว่าทำไมฟีเจอร์นี้ใช้ไม่ได้ชั่วคราว

สรุป

Spend Limits ใน AI Gateway ไม่ใช่แค่ตัวเลขเพดานลอย ๆ แต่เป็นกลไกที่ทำงานล่วงหน้าก่อน Request จะไปถึง AI Provider จริง ช่วยป้องกันความเสียหายจากบั๊ก ความผิดพลาดของทีม หรือการใช้งานผิดปกติของผู้ใช้ ก่อนที่ยอดค่าใช้จ่ายจะบานปลายเกินควบคุม

สิ่งที่ควรทำต่อจากนี้คือสำรวจว่าระบบปัจจุบันมีจุดไหนที่เสี่ยงเรื่องการใช้งานผิดปกติมากที่สุด แล้วเริ่มตั้งเพดานที่จุดนั้นก่อน พร้อมทบทวนตัวเลขเพดานเป็นระยะให้สอดคล้องกับการเติบโตของธุรกิจ ไม่ใช่ตั้งครั้งเดียวแล้วปล่อยทิ้งไว้

• Spend Limits ต่างจาก Rate Limiting ตรงที่เน้นควบคุมยอดสะสมของต้นทุน ไม่ใช่ความถี่ของ Request
• ตั้งได้หลายระดับ ทั้งระดับ Gateway ทั้งก้อน ระดับผู้ใช้ ระดับโมเดล และระดับ Endpoint เฉพาะจุด
• ควรตั้งการแจ้งเตือนล่วงหน้าก่อนถึงเพดานจริง และเชื่อมไปยังช่องทางที่ทีมเห็นจริง ไม่ใช่แค่ตั้งแล้วปล่อยทิ้ง
• ตัวเลขที่คำนวณเป็นค่าประมาณ ควรใช้ร่วมกับการตรวจสอบบิลจริงเป็นระยะ ไม่ใช่แหล่งข้อมูลที่แม่นยำร้อยเปอร์เซ็นต์

คำถามที่พบบ่อย