BigQuery ตั้งโควตาโทเคน AI รายวัน คุมต้นทุนระดับโปรเจกต์และผู้ใช้
Google อธิบายการตั้งโควตา input และ output token สำหรับฟังก์ชัน AI ใน BigQuery พร้อมขอบเขตที่ครอบคลุม วิธีตั้งค่า และข้อแตกต่างจาก spend cap
การใช้ฟังก์ชัน AI ใน BigQuery ช่วยให้ทีมวิเคราะห์ข้อมูลเรียกโมเดลจาก SQL ได้โดยตรง แต่ query เดียวอาจประมวลผลข้อมูลจำนวนมากจนใช้โทเคนสูง Google Cloud เผยแพร่แนวทางเมื่อวันที่ 14 ตุลาคม 2026 สำหรับควบคุมค่าใช้จ่ายของฟังก์ชัน generative AI ด้วยโควตาโทเคนรายวัน ทั้งระดับโปรเจกต์และระดับผู้ใช้ บทความต้นทางระบุว่าความสามารถจัดการต้นทุนด้วยโทเคนเปิดให้ใช้ทั่วไปแล้ว โดยการเผยแพร่วันที่ 14 เป็นบทความอธิบายวิธีใช้ ไม่ควรสับสนกับวันเปิด GA ซึ่งประกาศก่อนหน้านั้น
ทำไมค่าใช้จ่ายจาก SQL จึงคาดยาก
ฟังก์ชันอย่าง AI.GENERATE, AI.IF, AI.CLASSIFY และ AI.SCORE ทำให้การเรียก LLM เป็นส่วนหนึ่งของ query ตัวอย่างเช่นคัดแยก ticket หรือให้คะแนนข้อความในหลายล้านแถว ขณะที่ SQL ปกติอาจประเมินต้นทุนจาก bytes scanned ได้ งานที่ใช้ LLM ยังมีจำนวน input และ output token ของแต่ละแถว รวมถึง thinking token ในบางโมเดล ถ้าตัวกรองข้อมูลไม่ตรงที่ตั้งใจหรือมีการ rerun งานซ้ำ ค่าใช้จ่ายอาจโตเร็วกว่าการทดสอบกับข้อมูลตัวอย่าง
Google จึงเพิ่มโควตา AI input tokens ต่อวันและ AI output tokens ต่อวัน โดยแต่ละประเภทตั้งได้สองขอบเขต คือทั้งโปรเจกต์ และต่อผู้ใช้ภายในโปรเจกต์ รวมเป็นสี่โควตา ผู้ดูแลควรเข้าใจว่าโควตาต่อผู้ใช้ไม่ได้เป็นเพดานร่วมทั่วองค์กร หากบุคคลเดียวทำงานในหลายโปรเจกต์ต้องตรวจแยกแต่ละโปรเจกต์ ส่วนโควตาระดับโปรเจกต์รวมการใช้ทุก region ตามที่ Google อธิบาย จึงช่วยป้องกันไม่ให้ยอดสะสมกระจายอยู่หลายพื้นที่โดยไม่มีใครเห็นภาพรวม
ครอบคลุมฟังก์ชันใด และไม่ครอบคลุมอะไร
รายการในเอกสารครอบคลุม AI.GENERATE, AI.GENERATE_TABLE, AI.GENERATE_TEXT หรือชื่อเดิม ML.GENERATE_TEXT, AI.CLASSIFY, AI.IF, AI.SCORE และ AI.AGG โควตาฝั่ง output นับทั้งข้อความตอบและ thinking token ดังนั้นงาน reasoning อาจชนเพดานแม้คำตอบที่เห็นจะสั้น ส่วนฟังก์ชัน embedding เช่น AI.GENERATE_EMBEDDING และ AI.EMBED ไม่อยู่ภายใต้โควตาชุดนี้ตามประกาศ เพราะใช้โมเดลคนละกลุ่ม ทีมที่มี pipeline ทั้ง generation และ embedding จึงไม่ควรถือว่าโควตาสี่ตัวคุมทุกค่าใช้จ่าย AI ของ BigQuery
ค่าเริ่มต้นที่ Google ระบุไว้สูงมาก: 200 พันล้าน input token ต่อวันในระดับโปรเจกต์, 150 พันล้านต่อผู้ใช้, 20 พันล้าน output token ระดับโปรเจกต์ และ 15 พันล้านต่อผู้ใช้ ค่าเริ่มต้นเหล่านี้เป็นขีดจำกัดระบบ ไม่ใช่งบที่เหมาะกับทุกทีม ถ้าต้องการ guardrail ทางการเงินจริง ต้องลดลงตามปริมาณงานและงบที่ยอมรับได้ ไม่ใช่เปิดไว้ตามค่าเริ่มต้นแล้วหวังว่าจะเตือนทัน
ตั้งค่าและติดตามอย่างไร
ผู้ดูแลเข้า Google Cloud Console ที่ IAM & Admin → Quotas & System Limits แล้วกรองบริการเป็น BigQuery API จากนั้นหาโควตา AI ทั้งสี่ตัวและแก้ค่าได้ สิทธิ์ที่ Google ระบุว่าใช้จัดการได้รวม Owner, Editor, Quota Administrator และ Service Usage Admin การลดโควตามีผลทันที ส่วนการขอเพิ่มอาจต้องผ่านการพิจารณาตามขนาดคำขอ ทีมที่ใช้ infrastructure as code ยังสามารถจัดการผ่าน Cloud Quotas API, gcloud หรือ Terraform เพื่อให้โปรเจกต์หลายชุดใช้เกณฑ์เดียวกัน
หน้าจอเดียวกันแสดงประวัติการใช้โทเคน ช่วยดูว่ามีการพุ่งขึ้นจาก query ใหม่หรือไม่ ก่อนขยายงานควรใช้ AI.COUNT_TOKENS ประเมินขนาด input และรัน sample เล็กก่อนเพื่อวัด output จริง แล้วจึงตั้งเพดานต่อผู้ใช้ให้ต่ำกว่างบรวมของโปรเจกต์ การตั้ง max_output_tokens ในฟังก์ชันที่รองรับช่วยจำกัดความยาวคำตอบ แต่ควรตรวจด้วยว่าคำตอบไม่ถูกตัดจนข้อมูลสำคัญหาย
โควตาโทเคนต่างจาก spend cap
Google อธิบายว่าโควตาโทเคนเป็นตัวควบคุมเชิงป้องกันเฉพาะงาน AI ใน BigQuery ระบบติดตามระหว่าง query และหยุดงานใกล้เพดาน ส่วน Cloud Billing spend cap เป็นการจำกัดยอดเงินระดับโปรเจกต์หรือบริการที่กว้างกว่า และการบังคับใช้ไม่ได้เกิดทันทีเสมอ จึงอาจมียอดเกินเล็กน้อย การใช้ทั้งสองอย่างร่วมกันมีเหตุผล แต่โควตาโทเคนไม่ควรถูกนำไปอธิบายว่าเป็นเพดานค่าใช้จ่ายรวมทั้งคลาวด์
ก่อนใช้กับ production ให้ทดสอบว่าการชนโควตาทำให้ query และงาน downstream แสดง error อย่างไร ตั้งระบบแจ้งเตือน และวางวิธี rerun เมื่อโควตารีเซ็ต อย่าให้ pipeline ที่ล้มกลางทางเขียนผลบางส่วนโดยไม่มีเครื่องหมายบอกว่าไม่ครบ ตรวจสิทธิ์ของผู้ที่ปรับโควตาได้ด้วย เพราะการเพิ่มเพดานโดยไม่ผ่านขั้นตอนทบทวนทำให้ guardrail ที่ตั้งไว้หมดความหมาย
ข่าวนี้มีประโยชน์ต่อทีมที่นำ LLM มาอยู่ใน SQL: ฟังก์ชัน AI ทำให้เริ่มงานได้ง่าย แต่โควตาต่อโปรเจกต์และต่อผู้ใช้ช่วยให้ทดลองบนข้อมูลใหญ่โดยมีขอบเขตที่ตรวจได้ สิ่งที่ต้องทำต่อคือวัดโทเคนจากข้อมูลจริง ตั้งค่าต่ำตามงบ และทดสอบผลเมื่อระบบหยุดงานใกล้เพดาน
แหล่งข่าวและวันที่เผยแพร่: Google Cloud Blog, 14 ตุลาคม 2026