Gemini API มีโควตาเท่าไร เช็ก Rate Limit อย่างไร

Gemini API มี Rate Limit หรือข้อจำกัดปริมาณการเรียกใช้งาน เพื่อควบคุมจำนวน Request และ Token ที่แต่ละ Google Cloud Project สามารถส่งไปยัง Gemini ภายในช่วงเวลาหนึ่ง

สิ่งสำคัญคือ Gemini API ไม่มีตัวเลข Rate Limit เดียวที่ใช้กับทุกคน เพราะโควตาขึ้นกับหลายปัจจัย เช่น Model, Usage Tier, Project, Account Status และประเภทการประมวลผลที่ใช้งาน

Google ปัจจุบันแนะนำให้ตรวจ Active Rate Limits ของ Project จริงผ่าน Google AI Studio เนื่องจาก Limit สามารถเปลี่ยนเมื่อ Project เลื่อน Tier หรือสถานะบัญชีเปลี่ยน และ Google ระบุด้วยว่าตัวเลข Rate Limit ที่ระบุไม่ถือเป็นการรับประกัน Capacity เสมอไป

Rate Limit หลักที่ควรรู้ ได้แก่

RPM = Requests per Minute
TPM = Input Tokens per Minute
RPD = Requests per Day

และโมเดลบางประเภทอาจมี Limit เพิ่ม เช่น

TPD = Tokens per Day
IPM = Images per Minute
Spend Rate Limit
Batch Limits

หากชน Limit ใด Limit หนึ่ง Gemini API สามารถตอบกลับด้วย Error 429 RESOURCE_EXHAUSTED

❶ 🚦 Rate Limit คืออะไร

Rate Limit คือข้อจำกัดว่าระบบอนุญาตให้ Project เรียก Gemini API ได้มากเพียงใดในช่วงเวลาที่กำหนด

ตัวอย่างสมมติ

RPM = 20

หมายความว่า Project สามารถส่ง Request ได้ 20 ครั้งต่อนาทีตาม Limit นั้น

ถ้าส่งครั้งที่ 21 ก่อน Window เปลี่ยน อาจได้รับ

429 RESOURCE_EXHAUSTED

แม้จำนวน Token ที่ใช้ยังไม่ถึง TPM ก็ตาม

เพราะ Gemini ตรวจหลาย Limit แยกจากกัน

❷ 📊 Gemini API วัด Rate Limit จากอะไร

Google ระบุ Metric หลัก 3 ตัวคือ

RPM

Requests per Minute

TPM

Input Tokens per Minute

RPD

Requests per Day

Application ต้องอยู่ภายในทุก Limit ที่เกี่ยวข้อง

จึงไม่ใช่แค่ดู RPM อย่างเดียว

❸ 🔢 RPM คืออะไร

RPM ย่อมาจาก

Requests Per Minute

หมายถึงจำนวน API Request ที่อนุญาตในหนึ่งนาที

ตัวอย่าง

RPM = 60

ถ้า Application ส่ง

1 request / second

โดยประมาณก็จะเท่ากับ

60 requests/minute

แต่ Traffic จริงอาจ Burst เป็นช่วงสั้น ๆ จึงต้องออกแบบ Rate Limiter ให้เหมาะสม

❹ 🧮 TPM คืออะไร

TPM คือ

Tokens Per Minute

ในเอกสาร Rate Limit ปัจจุบัน Google ระบุ TPM ในบริบทของ Input Tokens

ตัวอย่างสมมติ

TPM = 1,000,000

Application ส่ง 10 Requests

แต่ละ Request มี Input

100,000 tokens

รวม

1,000,000 tokens

ก็สามารถชน TPM ได้ แม้ RPM ยังเหลืออยู่

❺ 📅 RPD คืออะไร

RPD คือ

Requests Per Day

ควบคุมจำนวน Request ต่อวัน

Google ระบุว่า RPD Reset ที่

เที่ยงคืนตามเวลา Pacific

ไม่ได้ Reset ตามเวลาเที่ยงคืนประเทศไทย

จุดนี้สำคัญสำหรับ Developer ในไทยที่กำลังดู Daily Usage

❻ ⏰ RPD ไม่ได้รีเซ็ตเที่ยงคืนไทย

สมมติอยู่ประเทศไทย

อย่าคิดว่าเวลา

00:00 น. ประเทศไทย

แล้ว RPD จะกลับเป็นศูนย์ทันที

Google ใช้ Midnight Pacific Time สำหรับ Daily Quota ดังกล่าว

เวลาที่ตรงกับประเทศไทยสามารถเปลี่ยนตามช่วง Daylight Saving Time ของสหรัฐฯ

ดังนั้นในระบบ Production ควรอิง Timestamp/Quota Status จริงมากกว่าคำนวณเวลา Reset แบบ Hard-code

❼ ⚠️ ชน Limit ตัวเดียวก็ Error ได้

สมมติ Project มี

RPM = ยังเหลือ
TPM = เต็ม
RPD = ยังเหลือ

Request ใหม่ก็อาจถูกปฏิเสธ

หรือ

RPM = เต็ม
TPM = ยังเหลือ
RPD = ยังเหลือ

ก็เกิดปัญหาได้เช่นกัน

ดังนั้นต้อง Monitoring หลาย Metric

ไม่ใช่เพียงจำนวน Request ทั้งหมด

❽ 🧠 Gemini API มีโควตาเท่าไร

คำตอบที่ถูกต้องคือ

ขึ้นอยู่กับ Model และ Usage Tier ของ Project

Google ไม่ได้กำหนดตัวเลขเดียว เช่น

ทุกบัญชี = 100 RPM

ตัวเลข Active Limit ควรตรวจจาก Google AI Studio สำหรับ Project และ Model ที่กำลังใช้งานจริง

เนื่องจาก Limit สามารถเปลี่ยนได้ตาม

• Free Tier
• Tier 1
• Tier 2
• Tier 3
• Model
• Preview/Experimental Status
• Account Status

❾ 🔍 เช็ก Rate Limit ที่ไหน

วิธีที่ Google แนะนำคือดูผ่าน Google AI Studio

เข้า Project ที่ใช้งาน แล้วเปิดหน้า Rate Limits ที่เกี่ยวข้อง

แนวคิดคือ

Google AI Studio
↓
Project
↓
Rate Limits
↓
เลือก Model
↓
ดู Active Limits

ควรดู Project ให้ถูกก่อน เพราะ Rate Limit ถูกบังคับใช้ในระดับ Project

❿ 🗂️ Rate Limit คิดตาม API Key หรือ Project

Google ระบุชัดว่า Rate Limit ใช้ในระดับ

Project

ไม่ใช่ต่อ API Key

นี่เป็นประเด็นสำคัญมาก

สมมติ Project เดียวมี

API Key A
API Key B
API Key C

ไม่ได้หมายความว่าได้ Rate Limit เพิ่มเป็น 3 เท่า

ทั้งสาม Key ยังสามารถใช้ Capacity ของ Project เดียวกัน

🚫 สร้าง API Key เพิ่มไม่ได้ช่วยเพิ่ม Quota

ตัวอย่างแนวคิดที่ผิด

Key A = 100 RPM
Key B = 100 RPM
Key C = 100 RPM

รวม = 300 RPM

ไม่ควรคิดแบบนี้

เพราะ Google ระบุว่า Rate Limits อยู่ระดับ Project

ดังนั้นถ้าต้องการ Capacity สูงขึ้นควร

• ตรวจ Usage Tier
• ลด Traffic
• Optimize Token
• Upgrade Tier
• Request Rate Limit Increase

ตามกรณี

ไม่ใช่สร้าง Key ใหม่เพื่อหลบ Limit

🆓 Free Tier มี Rate Limit เท่าไร

Free Tier มี Rate Limit จำกัดและแตกต่างตาม Model

ตัวเลขของแต่ละ Model ควรดู Active Rate Limits ใน AI Studio เนื่องจาก Google สามารถปรับ Limit ได้

Free Tier เหมาะกับ

• ทดลอง
• เรียนรู้
• Development
• Prototype
• Traffic ต่ำ

ไม่ควรออกแบบ Production Capacity โดยสมมติว่า Free Tier Limit จะคงเดิมตลอด

💳 Paid Tier ได้ Rate Limit สูงขึ้นไหม

โดยทั่วไปได้

Google ระบุว่า Paid Tier ให้

Higher Rate Limits for production deployments

และ Rate Limits จะผูกกับ Usage Tier ของ Project

Tier ปัจจุบันประกอบด้วย

Free
Tier 1
Tier 2
Tier 3

ยิ่ง Tier สูง Capacity โดยทั่วไปจะสูงขึ้นตาม Model และ Limit ที่ Googleกำหนด

🪜 Usage Tier ของ Gemini API

โครงสร้างปัจจุบันคือ

Free

Project ที่ยังอยู่ระดับฟรี

Tier 1

เปิดและเชื่อม Active Billing Account

Tier 2

ต้องมีเงื่อนไข Spending และเวลาหลัง Payment ตามที่ Google กำหนด

Tier 3

ต้องมี Spending และ Payment History สูงขึ้นอีกระดับ

Tier ไม่ได้ดูเพียงว่า

เปิด Billing = Tier สูงสุด

ทันที

💰 Tier 1 ต้องทำอย่างไร

ตามระบบปัจจุบัน Tier 1 ต้อง

Set up Billing
+
Link Active Billing Account

Free → Tier 1 โดยทั่วไป Google ระบุว่าสามารถมีผลได้ทันทีหลังตั้ง Billing สำเร็จ

จากนั้น Rate Limit จะเป็นไปตาม Paid Tier และ Model ที่ใช้

💰 Tier 2 ต้องใช้งานเท่าไร

เกณฑ์ปัจจุบันของ Google คือ

• ชำระเงินสะสมอย่างน้อย $100
• และผ่านอย่างน้อย 3 วันนับจาก Successful Payment แรก

เมื่อผ่านเงื่อนไข Project สามารถถูกเลื่อนไป Tier 2 ตามระบบ Review ของ Google

ไม่ได้หมายความว่าการสร้าง Usage $100 ภายในไม่กี่นาทีแล้วจะได้ Tier 2 ทันที

💰 Tier 3 ต้องใช้งานเท่าไร

เกณฑ์ปัจจุบันคือ

• ชำระเงินสะสมอย่างน้อย $1,000
• และผ่านอย่างน้อย 30 วันนับจาก Successful Payment แรก

จากนั้นจึงมีสิทธิ์เข้า Tier 3 ตามเงื่อนไข

Google ระบุว่าการผ่านเกณฑ์โดยทั่วไปเพียงพอ แต่ในบางกรณี Upgrade สามารถถูกปฏิเสธจากปัจจัยอื่นของการ Review ได้

📋 ตาราง Usage Tier

Tier	เงื่อนไขหลักปัจจุบัน
Free	Active Project / Free Trial
Tier 1	เชื่อม Active Billing Account
Tier 2	จ่ายสะสม $100 + 3 วันหลัง Payment แรก
Tier 3	จ่ายสะสม $1,000 + 30 วันหลัง Payment แรก

รายละเอียดสามารถเปลี่ยนได้ จึงควรตรวจหน้า Rate Limits ก่อนวาง Capacity Production

⏱️ Tier Upgrade ใช้เวลานานไหม

Google ระบุว่า

Free → Tier 1

โดยทั่วไปมีผลทันที

Tier ที่สูงขึ้น

หลัง Project ผ่านเงื่อนไข Upgrade โดยทั่วไปสามารถมีผลภายในประมาณ 10 นาที

สามารถตรวจ Tier ปัจจุบันใน AI Studio Projects Page

⚠️ Tier สูงขึ้นไม่ได้แปลว่า Unlimited

แม้อยู่ Tier 3 ก็ยังมี

• Rate Limit
• Spend Limit
• Model Limit
• System Capacity

ไม่ใช่ Unlimited API

Production System จึงยังต้องมี

• Queue
• Retry
• Backoff
• Rate Limiter
• Monitoring

💵 Spend-based Rate Limit คืออะไร

นอกจาก RPM และ TPM แล้ว Google ปัจจุบันมี Spend-based Rate Limits

มีไว้ช่วยป้องกันค่าใช้จ่ายสูงผิดปกติ

ระบบประเมินจากค่าใช้จ่ายในช่วงเวลาแบบ Rolling

ปัจจุบันเป็น

Rolling 10-minute window

💵 Spend Rate Limit ปัจจุบันเท่าไร

ตามเอกสารปัจจุบัน

Tier	Spend Rate Limit ต่อ 10 นาที
Free	ไม่มี
Tier 1	$10
Tier 2	$200
Tier 3	$200

ข้อจำกัดนี้สามารถขึ้นกับ Billing History และ Account Standing

จึงไม่ควรตีความว่า Account ทุกตัวจะมี Behavior เหมือนกันทุกกรณี

🚨 ชน Spend Rate Limit จะเกิดอะไร

Google ระบุว่า API จะคืน

429 RESOURCE_EXHAUSTED

เช่นเดียวกับ Rate Limit อื่น

ทางแก้เบื้องต้นคือ

• รอแล้ว Retry
• ลด Request Rate
• ลด Context
• ลด Output
• ใช้ Model ที่เหมาะสม
• Request Rate Limit Increase

หากเป็น Traffic ปกติของระบบที่ต้องรองรับจริง

💳 Monthly Spend Cap ต่างจาก Rate Limit

อย่าสับสน

Spend Rate Limit

ควบคุมความเร็วของค่าใช้จ่ายในช่วงสั้น เช่น 10 นาที

Monthly Spend Cap

จำกัดค่าใช้จ่ายในรอบเดือนตาม Billing/Tier

เป็นคนละระบบ

💰 Monthly Spend Cap ของ Tier

Billing Account Tier Cap ปัจจุบันคือ

Tier	Monthly Spend Cap
Free	ไม่มี Paid Cap
Tier 1	$250
Tier 2	$2,000
Tier 3	$20,000–$100,000+

Tier 3 Range ขึ้นกับ Account และการอนุมัติที่เกี่ยวข้อง

🔒 ตั้ง Project Spend Cap เองได้ไหม

Google ปัจจุบันมี Project-level Spend Cap ใน AI Studio

Feature นี้ยังถูกระบุว่าเป็น Experimental

ผู้ที่มี Permission ที่เหมาะสมสามารถเข้า

AI Studio
↓
Spend
↓
Monthly spend cap
↓
Edit spend cap

เพื่อกำหนดค่าใช้จ่ายสูงสุดของ Project

มีประโยชน์หาก Billing Account มีหลาย Project

⚠️ Spend Cap ไม่ใช่ Hard Stop แบบทันที 100%

Google ระบุว่า Billing Data อาจมี Delay ประมาณ 10 นาที

ดังนั้นอาจเกิดค่าใช้จ่ายเกิน Cap เล็กน้อยระหว่างที่ข้อมูลยังประมวลผล

งาน Long-running เช่น

• Batch
• Agent Session

ก็สามารถมี Overrun ได้ตามลักษณะงาน

จึงไม่ควรใช้ Spend Cap เป็น Safety Mechanism เพียงอย่างเดียว

🖼️ IPM คืออะไร

โมเดลบางประเภทมี Metric เฉพาะ

เช่น Model สร้างภาพอาจมี

IPM = Images Per Minute

แนวคิดคล้าย RPM/TPM แต่ใช้จำนวนภาพ

ถ้า Application สร้าง Image จำนวนมาก ต้องตรวจ Metric นี้ด้วย

📊 TPD คืออะไร

บาง Model อาจมี

TPD = Tokens Per Day

ดังนั้น Rate Limit ไม่ได้จำกัดเพียง RPM, TPM และ RPD เสมอไป

ต้องดูหน้า Model/Rate Limit ของสิ่งที่ใช้งานจริง

🧪 Preview Model มี Rate Limit ต่ำกว่าหรือไม่

Google ระบุว่า

Experimental และ Preview Models มี Rate Limit ที่เข้มงวดกว่า

ดังนั้นไม่ควรออกแบบ Production Capacity โดยใช้ Preview Model แล้วคาดหวัง Capacity เท่า Stable Model

Preview เหมาะกับ

• ทดลอง Feature
• Development
• Evaluation

มากกว่า Production Critical Workload

⚠️ Rate Limit ที่เห็นไม่ได้รับประกัน Capacity

Google ระบุว่า Specified Rate Limits

ไม่รับประกัน Capacity

และ Actual Capacity สามารถเปลี่ยนได้

ดังนั้นแม้ Limit บอกว่า Application สามารถใช้ได้ระดับหนึ่ง

ระบบ Production ยังควรรองรับ

• Temporary 429
• Service Load
• Retry
• Queue

ไว้ด้วย

🔄 Rate Limit เปลี่ยนอัตโนมัติได้ไหม

ได้

เมื่อ

• Tier เปลี่ยน
• Account Status เปลี่ยน
• Google ปรับ Limit
• Model เปลี่ยน Lifecycle

Active Rate Limits สามารถเปลี่ยนตามระบบ

นี่เป็นเหตุผลที่ควรตรวจ AI Studio มากกว่าฝังตัวเลขจากบทความลง Configuration ถาวร

📦 Batch API มี Rate Limit แยกไหม

มี

Google ระบุว่า Batch API มี Limit แยกจาก Non-batch API Calls

ข้อจำกัด Batch ปัจจุบันบางรายการคือ

Concurrent batch requests = 100
Input file size = 2 GB
File storage = 20 GB

และยังมี

Enqueued tokens per model

ซึ่งแตกต่างตาม Model/Tier

📦 Concurrent Batch Requests = 100 หมายถึงอะไร

หมายความว่าสามารถมี Batch Request ที่ Active พร้อมกันได้ตามข้อจำกัดนี้

ไม่ได้หมายความว่า

Batch หนึ่งมีได้แค่ 100 prompts

เป็นคนละเรื่อง

Batch Job ภายในยังมีข้อจำกัดข้อมูลและ Token ของตัวเองตาม API

📁 Batch Input File สูงสุด 2 GB

ข้อมูล Input File ของ Batch API ปัจจุบันมี Limit

2 GB

ต่อ Input File ตามข้อกำหนดที่ระบุ

หาก Dataset ใหญ่กว่านี้ต้องแบ่งงานให้เหมาะสม

ไม่ควรสร้างไฟล์ขนาดมหาศาลเพียงไฟล์เดียว

💾 Batch File Storage สูงสุด 20 GB

Google ระบุ File Storage Limit สำหรับ Batch ปัจจุบันคือ

20 GB

จึงต้องจัดการ File Lifecycle

ไม่ควร Upload Dataset แล้วปล่อยไว้โดยไม่ตรวจ Storage

🧮 Enqueued Tokens คืออะไร

Batch Processing มี Limit จำนวน Token ที่สามารถรอประมวลผลอยู่พร้อมกัน

เรียกว่า

Enqueued tokens

ตัวเลขแตกต่างตาม

• Model
• Usage Tier

ดังนั้น Dataset ใหญ่ควรตรวจ Model-specific Batch Limit ก่อนส่ง Job

⚡ Priority Processing มี Rate Limit แยกไหม

Google ระบุว่า Priority Consumption มี Rate Limits ของตัวเอง

Default Rate Limits ปัจจุบันคือประมาณ

0.3 × Standard Rate Limit

สำหรับแต่ละ Model และ Tier

แม้ Priority Consumption ยังถูกนับกับ Interactive Traffic Limits โดยรวม

จึงต้องดูทั้ง Capacity และ Cost ก่อนเลือก Priority

📊 วิธีรู้ว่า App ต้องการ RPM เท่าไร

คำนวณจาก Traffic

สมมติ

1,000 Users

แต่ละคนเรียกเฉลี่ย

2 requests/minute

ในช่วง Peak

จะเท่ากับ

2,000 RPM

หาก Project รองรับต่ำกว่านี้ จะต้อง

• Queue
• ลด Calls
• เพิ่ม Tier
• Request Increase

ก่อนเปิด Traffic จริง

🧮 วิธีคำนวณ TPM

สมมติ Peak

500 requests/minute

Input เฉลี่ย

4,000 tokens/request

ดังนั้น

500 × 4,000
=
2,000,000 TPM

แปลว่าแม้ RPM เพียง 500 แต่ต้องรองรับ Input 2 ล้าน Tokens/Minute

นี่เป็นเหตุผลว่าทำไม RPM อย่างเดียวไม่พอ

📄 File Upload ทำให้ TPM พุ่งได้

Chat ธรรมดาอาจมี

1,000 input tokens

แต่ Request ที่มีเอกสารหรือ Context ใหญ่สามารถมี Token สูงกว่ามาก

สมมติ

100 PDF requests
×
50,000 tokens
=
5,000,000 tokens

ทำให้ TPM เต็มก่อน RPM ได้ง่าย

ระบบวิเคราะห์เอกสารควรวัด Token จริงจาก Production-like Dataset

💬 Conversation History มีผลต่อ TPM

ถ้า Chat ส่ง History ยาวขึ้นทุก Request

Input Token ต่อ Request จะเพิ่ม

ตัวอย่าง

Turn 1 = 1,000
Turn 10 = 10,000
Turn 100 = 100,000

โดยประมาณตาม Context ที่เก็บ

ดังนั้น Chatbot ต้องมี Context Strategy

เช่น

• Summarization
• Sliding Window
• Retrieval
• New Session

ตาม Use Case

🧠 Context Caching ช่วย Rate Limit หรือไม่

Caching มีประโยชน์ด้าน Cost และ Context Reuse ตาม Model/API

แต่ไม่ควรสมมติว่า Cached Token จะหลีกทุก Rate Limit โดยอัตโนมัติ

ต้องตรวจ Metric ของ Model และ Usage จริง

ใช้ Caching เพราะ Context ซ้ำและคุ้ม

ไม่ใช่เป็นวิธีหลบ Quota แบบไม่มีข้อจำกัด

🚨 Error 429 หมายความว่าชน Rate Limit เสมอไหม

429 RESOURCE_EXHAUSTED เกี่ยวข้องกับ Resource/Quota Constraint ได้หลายลักษณะ

อาจเป็น

• RPM
• TPM
• RPD
• Spend Rate
• Model-specific Limit

ดังนั้นต้องอ่านข้อความ Error Detail

ไม่ควรเห็น 429 แล้วสรุปทันทีว่า RPM เต็ม

บทความถัดไปลำดับ 398 จะอธิบาย Error 429 โดยละเอียด

🔍 วิธีวิเคราะห์ว่า Limit ไหนเต็ม

ควรตรวจ

Error Response

ดู Message/Metadata

AI Studio Rate Limits

ดู Active Limit

Application Metrics

ดู RPM/TPM

Usage Dashboard

ดู Usage

จากนั้นเปรียบเทียบ

Current Usage
vs
Allowed Limit

เพื่อหา Root Cause

📈 ควรเก็บ Metric อะไร

Production App ควรเก็บอย่างน้อย

timestamp
project
model
request_count
input_tokens
output_tokens
status_code
latency
retry_count

ถ้าใช้หลาย Feature อาจเพิ่ม

search_calls
image_count
batch_jobs

ช่วยวิเคราะห์ Capacity ได้จริง

⏱️ วัด RPM ภายใน Application

สามารถ Aggregate Request ต่อ 1 นาที

ตัวอย่าง

10:00
450 requests

10:01
680 requests

10:02
920 requests

จากนั้นดู Peak

ไม่ควรใช้ Average ทั้งวัน

เพราะ Rate Limit มักเกิดในช่วง Peak

📊 Average Traffic อาจหลอกได้

สมมติทั้งวันมี

144,000 requests/day

Average คือประมาณ

100 requests/minute

แต่ช่วง Promotion อาจพุ่ง

2,000 requests/minute

ระบบจะชน Rate Limit แม้ Daily Average ดูต่ำ

ดังนั้น Capacity Planning ต้องดู Peak Traffic

🧱 ใช้ Queue ช่วยอย่างไร

หากงานไม่ต้องตอบทันที สามารถใช้ Queue

Incoming Jobs
↓
Queue
↓
Worker
↓
Gemini API

Worker จำกัดความเร็วให้อยู่ภายใน Rate Limit

เหมาะกับ

• Generate Content
• Analyze Documents
• Data Classification

ไม่เหมาะกับงาน Real-time ทุกประเภท

🌊 Chatbot ควรทำอย่างไรเมื่อใกล้ Limit

ทางเลือก เช่น

• จำกัด User Request
• Queue ระยะสั้น
• แสดง Busy Message
• ลด Retry
• Route Model ตามนโยบาย
• Request Limit Increase

อย่าปล่อย Backend ยิง Request ต่อเนื่องแล้วเกิด 429 ทุกครั้ง

เพราะ User Experience จะแย่และสร้าง Load เพิ่ม

🔁 Retry 429 อย่างไร

แนวทางทั่วไปคือใช้

Exponential Backoff

เช่น

ครั้งที่ 1
↓
รอ

ครั้งที่ 2
↓
รอนานขึ้น

ครั้งที่ 3
↓
รอนานขึ้นอีก

ควรเพิ่ม Random Jitter ในระบบขนาดใหญ่เพื่อไม่ให้ Worker จำนวนมาก Retry พร้อมกัน

และต้องมี Maximum Attempts

🚫 Retry ทุก 10 ms ไม่ควรทำ

ถ้า Rate Limit เต็มแล้วส่งใหม่ทันที

429
↓
retry
↓
429
↓
retry
↓
429

จะยิ่งสร้าง Traffic

ควรรอให้ Capacity กลับมาก่อน

🎲 Jitter คืออะไร

สมมติ Server 1,000 ตัวได้รับ 429 พร้อมกัน

ถ้าทั้งหมดรอ 1 วินาทีเท่ากัน

จะกลับมายิง Request พร้อมกันอีก

Jitter คือเพิ่มเวลาสุ่ม เช่น

1.0s
1.2s
1.7s
1.4s

ช่วยกระจาย Retry Traffic

🚦 Application Rate Limit ควรต่ำกว่า Gemini Limit

สมมติ Gemini Project รองรับ Capacity ระดับหนึ่ง

ไม่ควรตั้ง Application Limit เท่ากับ Maximum พอดีทุกครั้ง

ควรเหลือ Headroom สำหรับ

• Retry
• Background Job
• Admin Use
• Traffic Burst

ตัวอย่างแนวคิด

API Capacity
100%

Application Target
70–80%

ตัวเลขจริงควรมาจาก Load Test และ Requirement

👤 จำกัดต่อ User

Public App ควรมี User-level Quota เช่น

Free
10 requests/day

Paid
100 requests/day

ตาม Business Model

ช่วยไม่ให้ User หนึ่งคนใช้ Project Capacity ทั้งหมด

🌐 จำกัดตาม IP อย่างเดียวพอไหม

ไม่เสมอไป

ผู้ใช้หลายคนอาจอยู่หลัง IP เดียว เช่น

• Office
• University
• Mobile Carrier

ขณะเดียวกัน Bot สามารถเปลี่ยน IP ได้

ระบบจริงควรพิจารณา

Account
+
IP
+
Device/Session
+
Subscription

ตาม Risk

🛡️ Rate Limit ช่วย Security ด้วย

Rate Limiting ไม่ได้ช่วยแค่ Quota

ยังช่วยลด

• Abuse
• Bot Traffic
• Brute Force
• Cost Attack

โดยเฉพาะ Paid AI API

Endpoint ที่ Public และไม่มี Limit สามารถทำให้ API Usage เพิ่มสูงอย่างรวดเร็ว

💸 Cost Attack คืออะไร

ถ้าผู้โจมตีเจอ Public Endpoint

/generate

แล้วส่ง Request จำนวนมาก

ถึงแม้ระบบไม่ถูกเจาะ Database

เจ้าของ App ก็อาจเสียค่า API จำนวนมาก

จึงต้องมี

• Authentication
• Rate Limit
• Budget
• Spend Cap
• Monitoring

ร่วมกัน

🧪 Load Test ก่อน Production

ก่อนเปิดให้ User จำนวนมากควรทดสอบ

10 users
100 users
1,000 users

ใน Environment ที่ได้รับอนุญาต

ดู

• RPM
• TPM
• Latency
• Error Rate
• 429 Rate

แล้วประเมินว่าปัจจุบัน Project Tier เพียงพอหรือไม่

⚠️ อย่า Load Test Gemini แบบไร้ขอบเขต

Load Test คือการสร้าง Usage จริง

สามารถ

• ใช้ Quota
• สร้าง Cost
• ชน Rate Limit

จึงต้องกำหนด

• Maximum Requests
• Duration
• Budget

ก่อน Run

📈 Request Rate Limit Increase ได้ไหม

ได้

Google มีช่องทางสำหรับ Paid Tier เพื่อ Request Rate Limit Increase

แต่ Google ระบุว่า

ไม่มีการรับประกันว่าจะอนุมัติ

การ Review จะพิจารณาตาม Account และ Requirement

จึงไม่ควรสร้าง Production Launch Plan ที่พึ่งการอนุมัติซึ่งยังไม่ได้รับ

📋 ก่อนขอเพิ่ม Rate Limit ควรเตรียมอะไร

ควรรู้

• Project
• Model
• Current Tier
• Current RPM
• Current TPM
• Peak Usage
• Expected Growth
• Use Case
• Desired Limit

และควรมี Metrics จริง

คำขอ

ขอเพิ่มเยอะ ๆ

มีข้อมูลน้อยกว่า

Current peak = X
Expected production peak = Y
Required headroom = Z

🧠 Model Routing ช่วยลด Rate Limit ได้

ไม่จำเป็นต้องส่งทุกงานไป Model เดียว

ตัวอย่าง

Simple Classification
→ Flash-Lite

Complex Analysis
→ Flash/Pro

ช่วยกระจาย Workload ตาม Architecture และ Model Limits

แต่ต้องตรวจว่าการ Route ไม่ทำให้ Quality ลดจนต้อง Retry เพิ่ม

📦 Batch ช่วยลด Interactive Traffic

งาน Background สามารถย้ายไป Batch

แทนใช้ Interactive API

ตัวอย่าง

Nightly Classification
→ Batch

ทำให้ Interactive Capacity เหลือให้ User-facing Requests มากขึ้น

เนื่องจาก Batch API มี Rate Limits แยกจาก Non-batch Calls

⚖️ แยก Workload สำคัญกับไม่สำคัญ

ตัวอย่าง

Real-time

Chat ของลูกค้า

Background

สร้าง Report

ไม่ควรให้ Background Job ใช้ Interactive Capacity จน Chat เกิด 429

สามารถใช้

• Queue
• Batch
• Separate Scheduling

เพื่อควบคุม Workload

🕐 Schedule งานนอก Peak

งาน Background ขนาดใหญ่สามารถ Run ช่วง Traffic ต่ำ

ตัวอย่าง

กลางวัน
→ User Requests

กลางคืน
→ Batch Analysis

ช่วยลด Competition ภายใน Infrastructure ของ Application

แม้ Gemini Batch Capacity จะแยกจาก Interactive ในหลายด้านก็ตาม

📉 ลด Token ต่อ Request

หาก TPM เป็น Bottleneck สามารถพิจารณา

• ลด History
• ส่ง Context เฉพาะที่เกี่ยว
• Retrieval
• Summary
• ลด Duplicate Instructions

โดยไม่ทำลายคุณภาพ

การลด RPM ไม่ใช่คำตอบเดียวหากปัญหาจริงคือ TPM

✂️ อย่าลด Prompt จนคุณภาพตก

Prompt ที่สั้นเกินไปอาจทำให้ Output ผิดและต้อง Retry

ตัวอย่าง

Prompt สั้น
↓
Bad Output
↓
Retry 3 ครั้ง

อาจใช้ Capacity มากกว่า Prompt ที่ชัดเจนและสำเร็จครั้งเดียว

ควรวัด

Requests per successful task

ด้วย

📊 Dashboard ที่ควรมี

สำหรับระบบจริงควรสร้าง Dashboard เช่น

Current RPM
Peak RPM
Current TPM
429 Count
Retry Count
Latency
Cost

และแยกตาม

Model
Feature
User Tier

ทำให้เห็นว่า Capacity ถูกใช้ตรงไหน

🔔 ควรตั้ง Alert อะไร

ตัวอย่าง

RPM

เกิน 70% ของ Target

TPM

เกิน 70%

429 Rate

เริ่มสูงผิดปกติ

Cost

เพิ่มผิดปกติ

Latency

สูงเกิน SLA

Threshold จริงขึ้นกับ Application

ควรแจ้งก่อนชน Limit ไม่ใช่รอให้ระบบล้ม

🧩 Rate Limit กับ Quota ต่างกันไหม

ในบทสนทนาทั่วไปคนมักใช้คำว่า Quota ครอบคลุมข้อจำกัดทั้งหมด

แต่ในทางปฏิบัติควรแยก

Rate

ปริมาณต่อช่วงเวลา เช่น RPM/TPM

Daily Quota

เช่น RPD

Spend Cap

ข้อจำกัดด้านค่าใช้จ่าย

Batch Limit

ข้อจำกัดของ Batch

การรู้ว่า Limit ประเภทใดเต็มช่วยแก้ได้ตรงจุด

🧭 วิธีเช็ก Gemini API Rate Limit แบบ Step by Step

❶ เข้า Google AI Studio

ใช้ Account ของ Project

❷ เลือก Project

ตรวจให้ถูก Environment

❸ เปิด Rate Limits

ดู Active Limits

❹ เลือก Model

ดู Limit ที่เกี่ยวข้อง

❺ ตรวจ Usage Tier

Free, Tier 1, Tier 2 หรือ Tier 3

❻ เปิด Usage Dashboard

ดูการใช้งานจริง

❼ ตรวจ Application Metrics

เปรียบเทียบ RPM/TPM

❽ ตรวจ 429

อ่าน Error Detail

❾ วาง Capacity

เพิ่ม Headroom

❿ Request Increase

หาก Traffic ปกติเกิน Capacity จริง

สำหรับระบบที่ comsiam พัฒนาด้วย Gemini API วิธีนี้ควรถูกทำก่อนเปิด Feature ให้ User จำนวนมากใช้ เพื่อป้องกันกรณี Application ทำงานดีตอนทดสอบแต่เกิด 429 ทันทีเมื่อ Traffic เพิ่ม

✅ Checklist ก่อนเปิด Gemini API Production

Active Rate Limit

ตรวจใน AI Studio แล้ว

Tier

รู้ว่าอยู่ระดับใด

RPM

คำนวณ Peak แล้ว

TPM

คำนวณจาก Token จริง

RPD

เพียงพอต่อ Daily Traffic

Spend Rate

รู้ Limit ที่เกี่ยวข้อง

Application Rate Limit

มี

Retry

ใช้ Backoff

Queue

มีสำหรับงาน Background

Monitoring

ดู 429 ได้

Budget

ตั้งไว้

Load Test

ทดสอบแล้ว

🚫 10 ข้อผิดพลาดเรื่อง Gemini API Rate Limit

❶ จำตัวเลขจาก Tutorial เก่า

Limit เปลี่ยนได้

❷ ดู RPM อย่างเดียว

อาจชน TPM

❸ สร้าง API Key เพิ่มเพื่อเพิ่ม Quota

Limit อยู่ระดับ Project

❹ ไม่ดู Peak Traffic

Average ทำให้เข้าใจผิด

❺ Retry 429 ทันทีไม่หยุด

ทำให้ปัญหาหนักขึ้น

❻ ไม่มี User-level Limit

User เดียวใช้ Capacity หมด

❼ ใช้ Interactive API กับงาน Background ทั้งหมด

เสีย Capacity โดยไม่จำเป็น

❽ ใช้ Preview Model เป็น Production โดยไม่ตรวจ Limit

Preview มี Limit เข้มงวดกว่า

❾ ไม่ Monitor Token

ชน TPM โดยไม่รู้ตัว

❿ เปิด Paid Key Public โดยไม่มี Rate Limit

เสี่ยงทั้ง 429 และค่าใช้จ่าย

🪜 Workflow จัดการ Rate Limit ที่แนะนำ

❶ วัด Traffic

รู้ Peak RPM

❷ วัด Token

รู้ Peak TPM

❸ ตรวจ AI Studio

ดู Active Limit

❹ คำนวณ Headroom

ไม่ใช้ Capacity 100% เป็น Target

❺ จำกัด User

ตาม Plan

❻ Queue งาน Background

ไม่แย่ง Real-time

❼ ใช้ Batch

ถ้าเหมาะ

❽ ใช้ Backoff

เมื่อ 429

❾ Monitor

เก็บ Metrics

❿ Alert

ก่อนชน Limit

⓫ Upgrade Tier

เมื่อ Usage โต

⓬ Request Increase

เมื่อ Capacity มาตรฐานไม่พอ

แนวทางของ comsiam คือไม่ Hard-code สมมติฐานว่า Project จะมี Rate Limit เท่าเดิมตลอด แต่ให้ระบบ Monitoring อิง Usage จริง และตรวจ Active Limit ใน AI Studio ก่อนปรับ Traffic หรือเปิด Feature ใหม่

💡 สูตรคำนวณ Capacity แบบง่าย

RPM

Peak Users
×
Requests per User per Minute
=
Required RPM

TPM

Peak Requests per Minute
×
Average Input Tokens
=
Required TPM

RPD

Daily Active Users
×
Requests per User per Day
=
Required RPD

จากนั้นเพิ่ม Safety Margin ตาม Risk ของระบบ

📊 ตัวอย่าง Capacity Planning

สมมติ

Peak Users = 2,000
Requests/User/Minute = 0.5

Required RPM

2,000 × 0.5
=
1,000 RPM

ถ้า Input เฉลี่ย

3,000 tokens

Required TPM

1,000 × 3,000
=
3,000,000 TPM

จึงต้องตรวจว่า Model/Tier ของ Project รองรับทั้ง

1,000 RPM
และ
3,000,000 TPM

ไม่ใช่เพียงตัวแรก

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

Gemini API มี Rate Limit เท่าไร

ไม่มีตัวเลขเดียวสำหรับทุก Project เพราะ Limit ขึ้นกับ Model, Usage Tier และสถานะบัญชี ควรตรวจ Active Rate Limits ใน Google AI Studio โดยตรง

RPM, TPM และ RPD คืออะไร

RPM คือ Requests per Minute, TPM คือ Input Tokens per Minute และ RPD คือ Requests per Day หากชน Limit ใด Limit หนึ่ง API สามารถคืน Error 429 ได้

Gemini API Rate Limit คิดต่อ API Key หรือไม่

ไม่ Google ระบุว่า Rate Limit ถูกบังคับใช้ในระดับ Project ไม่ใช่ต่อ API Key ดังนั้นสร้าง Key เพิ่มใน Project เดียวไม่ได้เพิ่ม Quota อัตโนมัติ

RPD รีเซ็ตกี่โมง

Google ระบุว่า Requests per Day Reset ที่ Midnight Pacific Time ไม่ใช่เที่ยงคืนตามเวลาประเทศไทย

Paid Tier ได้ Rate Limit มากกว่า Free Tier ไหม

โดยทั่วไปใช่ Google ระบุว่า Paid Tier มี Higher Rate Limits และ Project สามารถเลื่อนจาก Tier 1 ไป Tier 2 และ Tier 3 ตาม Billing/Payment Criteria ที่กำหนด

Error 429 แปลว่าอะไร

หมายถึง Resource/Quota Constraint เช่น RPM, TPM, RPD หรือ Spend-based Limit อาจเต็ม ต้องอ่านข้อความ Error และดู Usage ก่อนแก้ โดยหัวข้อถัดไปจะอธิบาย Error 429 โดยละเอียด

🎯 สรุป

Gemini API มี Rate Limit หลักคือ RPM, TPM และ RPD และโมเดลบางประเภทอาจมี Limit เพิ่ม เช่น TPD, Images per Minute, Batch Token Limit และ Spend-based Rate Limit

Rate Limit ไม่ได้มีตัวเลขเดียวสำหรับผู้ใช้ทุกคน เพราะขึ้นกับ Model และ Usage Tier ของ Google Cloud Project ดังนั้นวิธีตรวจที่แม่นที่สุดคือเปิด Active Rate Limits ใน Google AI Studio สำหรับ Project ที่ใช้งานจริง

สิ่งสำคัญคือ Limit ถูกใช้ในระดับ Project ไม่ใช่ API Key การสร้าง Key เพิ่มจึงไม่ใช่วิธีเพิ่ม Quota

Paid Tier ปัจจุบันแบ่งเป็น Tier 1, Tier 2 และ Tier 3 โดย Tier สูงขึ้นตาม Billing และ Payment History และให้ Capacity สูงขึ้นตาม Model ส่วน Preview/Experimental Models มักมี Limit เข้มงวดกว่า

นอกจากนี้ Gemini API มี Spend-based Rate Limit แบบ Rolling 10 นาที โดยปัจจุบัน Tier 1 อยู่ที่ $10 ต่อ 10 นาที ส่วน Tier 2 และ Tier 3 อยู่ที่ $200 ต่อ 10 นาทีในบัญชีที่ข้อจำกัดนี้มีผล

สำหรับ Production ควรคำนวณ Peak RPM และ TPM จาก Traffic จริง ตั้ง Application Rate Limit, ใช้ Exponential Backoff เมื่อเกิด 429, แยก Background Work ไป Queue/Batch และสร้าง Alert ก่อน Usage ชน Limit

วิธีนี้ช่วยให้ระบบรองรับการเติบโตได้ดีกว่าการรอให้ Error 429 เกิดขึ้นแล้วค่อยเพิ่ม API Key หรือเปลี่ยน Configuration แบบเดาสุ่ม