Gemini API Error 429 แก้อย่างไร

Gemini API Error 429 หมายถึงระบบไม่สามารถรับ Request เพิ่มได้ในขณะนั้น เนื่องจาก Application ใช้ทรัพยากรหรือโควตาเกินเงื่อนไขที่กำหนด เช่น ส่ง Request ต่อนาทีมากเกินไป ใช้ Input Tokens ต่อนาทีสูงเกิน Limit ใช้ Daily Quota หมด หรือชน Spend-based Rate Limit

Error ที่พบมักมีลักษณะ เช่น

429 Too Many Requests

หรือ

429 RESOURCE_EXHAUSTED

สิ่งสำคัญคือ อย่าเห็น 429 แล้วสร้าง API Key ใหม่ทันที เพราะ Gemini API Rate Limit ถูกบังคับใช้ในระดับ Project ไม่ใช่ต่อ API Key การสร้าง Key เพิ่มใน Project เดิมจึงไม่ได้ทำให้ Quota เพิ่มขึ้นโดยอัตโนมัติ

วิธีแก้ที่ถูกต้องคือ อ่านข้อความ Error → ตรวจ Rate Limits ใน Google AI Studio → ตรวจ RPM/TPM/RPD → ตรวจ Billing และ Credit → ลด Request Rate → ใช้ Exponential Backoff → ปรับ Context/Output → Upgrade Tier หรือขอเพิ่ม Rate Limit หากจำเป็น

❶ 🚨 Gemini API Error 429 คืออะไร

HTTP Status

429

มีความหมายว่า

Too Many Requests

สำหรับ Gemini API ปัจจุบัน Google แยก Error ที่เกี่ยวข้องกับ 429 ได้หลายลักษณะ เช่น

rate_limit_exceeded
quota_exceeded
too_many_requests

แม้ทั้งหมดอาจคืน HTTP Status 429 เหมือนกัน แต่สาเหตุและวิธีแก้ไม่จำเป็นต้องเหมือนกัน

จึงควรดู

error code
+
error message
+
project usage

พร้อมกัน

❷ 🔴 rate_limit_exceeded คืออะไร

Google ระบุว่า rate_limit_exceeded หมายถึง Application ใช้ Request หรือ Token Rate ต่อช่วงเวลาสูงเกิน Limit

เช่น

RPM เต็ม

หรือ

TPM เต็ม

แนวทางแก้คือ

รอ
↓
Retry
↓
ใช้ Exponential Backoff

พร้อมลด Traffic หากเกิดซ้ำบ่อย

❸ 📅 quota_exceeded คืออะไร

quota_exceeded หมายถึง Quota ที่กำหนดถูกใช้หมดแล้ว

ตัวอย่างที่สำคัญคือ

RPD
=
Requests Per Day

ถ้า Daily Quota หมด การ Retry ทุก 1–2 วินาทีแทบไม่มีประโยชน์

ต้องรอให้ Quota Reset หรือเพิ่ม Capacity/Tier ตามสิทธิ์ของ Project

Google ระบุว่า RPD ของ Gemini API รีเซ็ตที่

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

ไม่ใช่เวลาเที่ยงคืนประเทศไทย

❹ ⚡ too_many_requests คืออะไร

หมายถึงมี Request เข้ามามากเกินไปในช่วงเวลาสั้น

อาจเกิดจาก

• Traffic Burst
• Loop
• Parallel Request จำนวนมาก
• User กด Submit ซ้ำ
• Worker หลายตัวทำงานพร้อมกัน
• Retry Storm

ตัวอย่าง

Normal:
20 requests/minute

เกิด Bug:
2,000 requests ในไม่กี่วินาที

แม้ Total Daily Usage จะยังต่ำก็สามารถเกิด 429 ได้

❺ 📊 สาเหตุหลักของ Gemini API Error 429

โดยทั่วไปควรตรวจอย่างน้อย 7 สาเหตุ

1. RPM เต็ม

Requests per Minute สูงเกิน Limit

2. TPM เต็ม

Input Tokens per Minute สูงเกิน Limit

3. RPD เต็ม

Requests per Day ถูกใช้หมด

4. Spend-based Rate Limit

ค่าใช้จ่ายเพิ่มเร็วเกิน Limit ใน Rolling Window

5. Model-specific Limit

Model มีข้อจำกัดเฉพาะ

6. Preview/Experimental Model

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

7. Billing/Credit

Paid Project มีปัญหาด้าน Billing หรือ Credit

ต้องตรวจให้รู้ว่าเป็นข้อใดก่อนแก้

❻ 🔢 เช็ก RPM ก่อน

RPM คือ

Requests Per Minute

สมมติ Limit ของ Project/Model คือ

20 RPM

หากส่ง

21 Requests

ภายในหนึ่งนาที

สามารถเกิด 429 ได้แม้ Token Usage ยังต่ำ

ดังนั้นให้ตรวจ Application Metrics เช่น

12:00 = 10 requests
12:01 = 18 requests
12:02 = 27 requests

ถ้า Error เริ่มที่ช่วง Traffic พุ่ง มีโอกาสสูงว่า RPM เป็น Bottleneck

❼ 🧮 เช็ก TPM ด้วย

TPM คือ

Input Tokens Per Minute

นี่เป็นสาเหตุที่ Developer มักมองข้าม

สมมติ

RPM Limit
ยังเหลือ

แต่ Application ส่ง PDF หรือ Context ขนาดใหญ่

เช่น

10 Requests
×
100,000 Input Tokens

=
1,000,000 Input Tokens

อาจชน TPM ก่อน RPM

ดังนั้นการดูเพียง

จำนวน Request

ไม่พอ

ต้องดู

Input Tokens

ด้วย

❽ 📄 PDF ทำให้เกิด 429 ได้ง่ายขึ้นอย่างไร

Application วิเคราะห์เอกสารอาจส่ง Input ใหญ่กว่าการ Chat ปกติมาก

เช่น

Chat:
1,500 tokens/request

เทียบกับ

PDF:
50,000–100,000+ tokens/request

ตามเอกสารจริงและวิธีประมวลผล

หากส่ง PDF หลายไฟล์พร้อมกัน TPM สามารถเต็มได้อย่างรวดเร็ว

แนวทางแก้คือ

• จำกัดจำนวนไฟล์
• จำกัดขนาด
• Queue Processing
• ลด Parallelism
• ส่งเฉพาะข้อมูลที่จำเป็น

❾ 💬 Conversation History ก็ทำให้ TPM เต็มได้

Chatbot มักมีปัญหาเมื่อ Conversation ยาวขึ้น

ตัวอย่าง

Turn 1
ใช้ Context เล็ก

แต่เมื่อถึง

Turn 100

Application อาจส่ง History จำนวนมากกลับไปทุก Request

ส่งผลให้ Input Token เพิ่มต่อเนื่อง

ควรพิจารณา

• Sliding Window
• Conversation Summary
• Retrieval
• Session Reset
• Context Management

ตาม Use Case

❿ 📅 ตรวจ RPD

RPD คือ

Requests Per Day

ถ้าใช้ Daily Quota หมดแล้ว

การ Retry แบบ

retry
retry
retry
retry

จะไม่แก้ Root Cause

ควรตรวจ Usage และรอ Quota Reset หรือเพิ่ม Tier/Quota เมื่อเหมาะสม

อย่าลืมว่า Reset ใช้ Pacific Time

💸 Spend-based Rate Limit ก็ทำให้ 429 ได้

Gemini API ปัจจุบันมี Spend-based Rate Limit สำหรับ Paid Tier บางบัญชี

ระบบตรวจค่าใช้จ่ายใน

Rolling 10-minute window

ตัวเลขปัจจุบันคือ

Tier	Spend Rate Limit
Tier 1	$10 / 10 นาที
Tier 2	$200 / 10 นาที
Tier 3	$200 / 10 นาที

หากชน Limit นี้ Google ระบุว่าจะคืน

429 RESOURCE_EXHAUSTED

แม้ RPM หรือ TPM อาจดูยังไม่เต็มก็ตาม

🔍 ทำไม Spend Limit ถึงเต็มเร็ว

Request บางประเภทมีต้นทุนสูง เช่น

• Context ใหญ่
• Output ยาว
• Reasoning สูง
• Image
• Video
• Search
• Media Processing

สมมติเปิด Feature ใหม่แล้ว Request แพงขึ้นหลายเท่า

Traffic จำนวนเดิมก็สามารถชน Spend Rate Limit ได้

จึงควรดู

Cost per request

ด้วย

💳 ตรวจ Billing หากข้อความพูดถึง Credit

ถ้า Error Message ระบุเกี่ยวกับ

prepayment credits

หรือ Credit Balance

ให้เข้า AI Studio ตรวจ Billing โดยตรง

สำหรับบัญชี Prepay ปัจจุบัน Google ระบุว่า Gemini API จะให้บริการ Paid Request ได้เมื่อมี Positive Prepay Credit Balance

เมื่อ Balance เหลือ

$0

Gemini API ของ Project ที่ใช้ Billing Account นั้นสามารถหยุดให้บริการได้

ทางแก้คือเติม Credit และรอให้ Billing Status อัปเดต

💰 เติม Credit ที่ไหน

เข้า Google AI Studio

ตรวจ

Billing

หรือ

Projects

หากขึ้นสถานะ เช่น

No credits

หรือ

Set up Prepay

ให้ทำตาม Billing Workflow ที่ระบบแสดง

Prepay ปัจจุบันมี Minimum Purchase ที่ Google ระบุไว้ที่

$10

สำหรับ Workflow ที่เกี่ยวข้อง

เงื่อนไขสามารถเปลี่ยนได้ในอนาคต

🔄 ตั้ง Auto-reload ช่วยได้

สำหรับ Production Project แบบ Prepay สามารถตั้ง

Auto-reload

เพื่อเติม Credit เมื่อ Balance ต่ำกว่าระดับที่กำหนด

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

Balance ต่ำกว่า $30
↓
เติม $100

ช่วยลด Service Interruption เพราะ Credit หมด

แต่ต้องตั้ง Monthly Auto-charge Limit และ Monitoring ให้เหมาะกับ Budget

⚠️ มีเงินใน Google Cloud ไม่ได้แปลว่า Gemini ใช้ได้เสมอ

ปัจจุบัน Gemini API มีระบบ Prepay/Postpay ของตัวเองตาม Billing Account

และ Google ระบุว่า Google Cloud Welcome Credit บางประเภทไม่สามารถนำมาใช้กับ Gemini API ได้

ดังนั้นถ้าเห็น Credit ใน Google Cloud ไม่ควรสรุปว่า

Gemini API Balance พร้อมใช้งานแน่นอน

ให้ตรวจหน้า Billing ของ AI Studio โดยตรง

🧭 วิธีเช็ก 429 แบบ Step by Step

เมื่อเกิด Error ให้ทำตามลำดับนี้

❶ อ่าน Error Body

อย่าดูเพียง HTTP 429

ดู

code
message
status

❷ ตรวจ Project

API Key อยู่ Project ไหน

❸ เปิด AI Studio Rate Limits

ดู Active Limit ของ Model

❹ ตรวจ RPM

Request ต่อนาที

❺ ตรวจ TPM

Input Token ต่อนาที

❻ ตรวจ RPD

Daily Usage

❼ ตรวจ Spend

Paid Tier อาจชน Spend Rate

❽ ตรวจ Billing

Credit และ Account Status

❾ ตรวจ Model

Preview หรือ Stable

❿ ค่อยแก้ตาม Root Cause

วิธีนี้แม่นกว่าการสุ่มเปลี่ยน API Key หรือ Model

🔑 สร้าง API Key ใหม่แก้ 429 ได้ไหม

โดยทั่วไป ไม่ได้ หาก Root Cause คือ Rate Limit ของ Project

เพราะ Google ระบุว่า Gemini API Rate Limit ถูกใช้ในระดับ

Project

ไม่ใช่

API Key

สมมติมี

Key A
Key B
Key C

อยู่ Project เดียวกัน

ทั้งสาม Key ยังใช้ Capacity เดียวกัน

🚫 อย่าสร้าง Project หลายอันเพื่อหลบ Rate Limit

การสร้าง Project จำนวนมากเพียงเพื่อหลีกข้อจำกัดของบริการไม่ใช่ Architecture ที่ควรใช้

สำหรับ Production ที่ต้องการ Capacity สูงควรใช้

• Paid Tier
• Rate Limit Increase
• Queue
• Batch
• Optimization

ตาม Workflow ที่ Google รองรับ

⏳ วิธีแก้ทันที: รอแล้ว Retry

ถ้าเป็น Rate Limit ระยะสั้น วิธีพื้นฐานคือ

รอ
↓
Retry

แต่ไม่ควร Retry ทันทีทุก Request

Google แนะนำ

Exponential Backoff

สำหรับ Error Rate Limit

📈 Exponential Backoff คืออะไร

แนวคิดคือเพิ่มเวลารอทุกครั้งที่ Retry

ตัวอย่าง

Request
↓
429

รอประมาณ 1 วินาที
↓
Retry

429
↓
รอประมาณ 2 วินาที

Retry
↓
429

รอประมาณ 4 วินาที

จนถึง Maximum Attempts

ไม่ควร Retry ไปเรื่อย ๆ ไม่มีที่สิ้นสุด

🎲 เพิ่ม Jitter

ระบบที่มี Worker จำนวนมากควรเพิ่มเวลาสุ่มเล็กน้อย

แทน

ทุก Worker รอ 2 วินาที

แล้วกลับมายิงพร้อมกัน

ใช้แนวคิด

Worker A = 1.8s
Worker B = 2.3s
Worker C = 2.7s

ช่วยลด Retry Storm

🐍 ตัวอย่าง Exponential Backoff ด้วย Python

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

import random
import time


def backoff_delay(attempt):
    base = 2 ** attempt
    jitter = random.uniform(0, 1)
    return base + jitter


for attempt in range(5):
    try:
        result = call_gemini()
        break

    except RateLimitError:
        if attempt == 4:
            raise

        time.sleep(
            backoff_delay(attempt)
        )

call_gemini() และ RateLimitError เป็นชื่อสมมติเพื่ออธิบายหลักการ

เมื่อเขียน Code จริงให้ใช้ Exception Type ของ SDK/API Version ที่กำลังใช้งาน

⚠️ Retry เฉพาะ Error ที่ Retry ได้

อย่าใช้ Backoff กับ Error ทุกชนิดโดยอัตโนมัติ

ตัวอย่าง

400 Bad Request

มักต้องแก้ Request

Retry 10 ครั้งด้วย Payload เดิมก็ยังผิด

แต่

429 Too Many Requests

เหมาะกับการรอและ Retry ในหลายกรณี

ดังนั้นต้องแยก Error Type

🚫 ตัวอย่าง Retry ที่ไม่ควรใช้

while True:
    try:
        call_gemini()
    except Exception:
        continue

Code แบบนี้อันตรายเพราะ

• Retry ไม่จำกัด
• ไม่มี Wait
• ซ่อน Error ทุกชนิด
• เพิ่ม Traffic
• Debug ยาก

Production ต้องมี

Maximum Retries
+
Backoff
+
Logging

⚡ ลด Parallel Requests

สมมติ Application ทำ

Promise.all(
  10,000 Gemini Requests
)

หรือเปิด Thread/Worker จำนวนมากพร้อมกัน

Rate Limit สามารถเต็มทันที

ควรใช้

Bounded Concurrency

เช่น จำกัดจำนวนงานพร้อมกัน

5
10
20

ตาม Rate Limit และ Workload จริง

ตัวเลขต้องคำนวณจาก Project Capacity

📦 ใช้ Queue

สำหรับงานที่ไม่จำเป็นต้องตอบทันที

ใช้

Request
↓
Queue
↓
Workers
↓
Gemini API

แทนการส่งทุกงานทันที

Worker สามารถควบคุม Request Rate

เช่น

สูงสุด X requests/minute

ช่วยป้องกัน Burst

🗃️ งานจำนวนมากใช้ Batch API

ถ้าต้องวิเคราะห์

100,000 records

ไม่ควรส่ง Interactive Request 100,000 ครั้งพร้อมกัน

Gemini Batch API มี Rate Limit แยกจาก Non-batch Calls

เหมาะกับ

• Classification
• Data Enrichment
• Bulk Content
• Offline Analysis

และยังสามารถมี Pricing ต่ำกว่า Standard Processing ใน Model ที่รองรับ

✂️ ลด Context Size

ถ้า TPM หรือ Spend Rate เต็ม

ควรตรวจว่า Request ส่ง Context ใหญ่เกินจำเป็นหรือไม่

จาก

System Prompt
+
500 Messages
+
Full Document
+
User Prompt

อาจลดเป็น

System Prompt
+
Relevant Context
+
Recent History
+
User Prompt

โดยต้องรักษาข้อมูลที่จำเป็นต่อคุณภาพคำตอบ

📤 ลด Output Length

ถ้า Prompt ต้องการเพียง

positive
neutral
negative

อย่าปล่อย Model สร้างคำอธิบาย 2,000 Tokens

ใช้

• Prompt Constraint
• Structured Output
• Schema

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

ช่วยทั้ง

• Cost
• Latency
• Spend Rate

🧱 ใช้ Structured Output

ตัวอย่างต้องการ

{
  "category": "technical"
}

ใช้ Structured Output แทนให้ Gemini สร้าง

จากการวิเคราะห์โดยละเอียดแล้ว ผมคิดว่า...

ช่วยลด Output ที่ไม่จำเป็นและทำให้ Program Parse ง่ายขึ้น

🧠 เลือก Model ให้เหมาะ

ไม่ควรส่งทุก Task ไป Model ที่ใช้ทรัพยากรสูงที่สุด

ตัวอย่าง

Classification
→ Model ที่เน้น Speed/Cost

และ

Complex Reasoning
→ Model ที่เหมาะกับงานยาก

Model Routing ช่วยลด Spend Rate และ Capacity Pressure ได้

แต่ต้อง Benchmark Quality จริง

🧪 Preview Model เกิด 429 ง่ายกว่าหรือไม่

Google ระบุว่า

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

ดังนั้นถ้า Production ใช้ Preview Model แล้วเกิด 429 บ่อย

ควรตรวจว่า Stable Model ที่ตอบโจทย์งานมีหรือไม่

อย่าคิดว่า Preview Model มี Capacity เท่ากับ Stable Model

🔄 เปลี่ยน Model ช่วยได้ไหม

อาจช่วยในบางกรณีหากปัญหาเป็น Model-specific Capacity หรือ Limit

แต่ไม่ควรทำแบบสุ่ม

ให้ตรวจ

Rate Limit ของ Model A
vs
Rate Limit ของ Model B

รวมทั้ง

• Quality
• Cost
• Feature Support

ก่อนเปลี่ยน

เพราะ Model ใหม่อาจมี Limit ต่างกัน

⚠️ อยู่ต่ำกว่า Quota แต่ยังเจอ 429 ได้ไหม

เป็นไปได้

Google ระบุว่า Rate Limits ที่เผยแพร่

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

และ Actual Capacity สามารถแตกต่างได้

ดังนั้นบางช่วงอาจเกิด 429 แม้ Dashboard ดูไม่ถึง Limit สูงสุด

แนวทางคือ

• Retry ด้วย Backoff
• ลด Burst
• ตรวจ Model
• ตรวจ Usage
• ตรวจ Service/Account Status

หากเกิดต่อเนื่องผิดปกติควรรวบรวม Request ID, Timestamp, Model และ Error Detail ไว้สำหรับ Troubleshooting

📋 ควรเก็บอะไรเมื่อรายงานปัญหา 429

เก็บ

timestamp
project
model
API
HTTP status
error code
error message
request ID
RPM
TPM
retry count

อย่าโพสต์

API Key

ลง Forum หรือ Support Ticket

ข้อมูลเหล่านี้ช่วยแยกได้ว่าเป็น

• Application Traffic
• Rate Limit
• Billing
• Model
• Service Capacity

🔍 ถ้า 429 เกิดกับไฟล์อย่างเดียว

ให้ทดสอบอย่างเป็นระบบ

Test 1

Text Request สั้น

Test 2

ไฟล์ขนาดเล็ก

Test 3

ไฟล์เดิมผ่าน Input Method อื่นที่เอกสารรองรับ

Test 4

Model อื่นที่รองรับ Use Case

หาก Text ผ่านแต่ File Path ใด Path หนึ่งล้มเหลวซ้ำ

อาจเป็นปัญหาเฉพาะ File Processing Pipeline มากกว่าค่า RPM ธรรมดา

อย่าเพิ่ม Retry จำนวนมากโดยยังไม่รู้ Root Cause

🧪 สร้าง Minimal Reproduction

เมื่อ Error ซับซ้อน ให้ลด Request เหลือ

1 Model
1 Prompt
1 API Call

ตัดออก

• Search
• Function Calling
• Files
• Structured Output
• Long History

ก่อน

ถ้า Request พื้นฐานผ่าน ให้ค่อยเพิ่ม Feature กลับทีละอย่าง

นี่เป็นวิธี Debug ที่เร็วมาก

📊 วิธีตรวจว่า RPM หรือ TPM เป็นปัญหา

ถ้า Request จำนวนมากแต่ Prompt สั้น

มีโอกาสเป็น

RPM

ถ้า Request น้อยแต่ Context ใหญ่มาก

มีโอกาสเป็น

TPM

ถ้าหยุดทำงานหลังใช้มาทั้งวัน

ตรวจ

RPD

ถ้าเกิดตอน Traffic ราคาแพงพุ่ง

ตรวจ

Spend Rate

นี่เป็น Shortcut สำหรับเริ่มวิเคราะห์

💸 ถ้าเกิดหลังเปิด Paid Tier

ตรวจ

Billing Account

Active หรือไม่

Billing Plan

Prepay หรือ Postpay

Prepay Balance

เหลือหรือไม่

Project Tier

ถูกต้องหรือไม่

Spend Rate

เต็มหรือไม่

อย่าคิดว่าเปิด Billing แล้วหมายถึง Quota Unlimited

🔔 Monitoring ช่วยป้องกัน 429

ควรติดตาม

RPM
TPM
RPD
429 count
latency
cost
retry count

และตั้ง Alert ก่อนถึง Capacity Target

ตัวอย่าง

60%
75%
90%

ตาม Requirement

ไม่ควรรอให้ 429 เกิดกับ User ก่อนจึงรู้ว่า Traffic เพิ่ม

🚦 Application Rate Limit

สร้าง Rate Limiter ของเราเองก่อน Request ถึง Gemini

ตัวอย่าง

User
↓
Application Rate Limiter
↓
Queue
↓
Gemini API

ช่วยให้ Traffic ถูกควบคุม

ดีกว่า

User
↓
Gemini
↓
429

แล้วค่อยแก้ทีหลัง

👤 จำกัด User แต่ละคน

ตัวอย่าง

Free User
10 requests/day

Pro User
100 requests/day

ตาม Business Model

ช่วยป้องกันผู้ใช้คนเดียวใช้ Project Quota ทั้งหมด

ระบบของ comsiam หากเปิด AI Feature ให้ผู้ใช้ทั่วไป ควรมี Application-level Quota แยกจาก Gemini API Rate Limit เพื่อป้องกันทั้ง Abuse และค่าใช้จ่ายผิดปกติ

🤖 Bot สามารถทำให้เกิด 429 ได้

Public Endpoint เช่น

/api/generate

ถ้าไม่มี

• Authentication
• CAPTCHA ตามความเหมาะสม
• Rate Limit
• User Quota

Bot สามารถยิง Request ต่อเนื่อง

ผลคือ

429
+
ค่าใช้จ่ายเพิ่ม

Security และ Rate Limit จึงเกี่ยวข้องกันโดยตรง

🔑 API Key รั่วก็ทำให้ 429 ได้

หาก Key ถูกขโมย

Traffic อาจมาจากระบบอื่นโดยที่เราไม่รู้

สัญญาณ เช่น

• RPM สูงผิดปกติ
• Usage เพิ่มกลางคืน
• Cost เพิ่ม
• Application ตัวเองเริ่ม 429

ควร

1. Rotate API Key
2. ตรวจ Usage
3. ตรวจ Repository
4. ตรวจ Log
5. Restrict Credential

ทันที

📈 Upgrade Tier ช่วยได้ไหม

ถ้าปัญหาเกิดจาก Capacity ของ Free Tier และ Application มี Traffic จริง

การเปิด Paid Tier หรือขึ้น Usage Tier สามารถเพิ่ม Rate Limits ตามเงื่อนไขของ Google

แต่ Tier ที่สูงขึ้นยังไม่ใช่ Unlimited

ควรคำนวณ

Required RPM
Required TPM
Required RPD

ก่อน Upgrade

📬 ขอเพิ่ม Rate Limit ได้ไหม

Paid Tier สามารถส่งคำขอ Rate Limit Increase ได้

แต่ Google ระบุว่า

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

ดังนั้นอย่า Launch ระบบที่ต้องใช้ Capacity สูงกว่าปัจจุบันโดยหวังว่าจะได้รับการอนุมัติภายหลังแน่นอน

ควรได้รับ Capacity ที่ต้องการก่อนเปิด Traffic จริง

📐 คำนวณ Capacity ก่อนเปิด Production

สมมติ

Peak Users = 1,000

แต่ละคนส่งเฉลี่ย

1 Request / 2 นาที

Required RPM ประมาณ

500 RPM

ถ้า Input เฉลี่ย

4,000 Tokens

Required TPM คือ

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

Project ต้องรองรับทั้งสอง Metric

⚠️ Average Traffic ไม่พอ

ทั้งวันอาจเฉลี่ย

100 RPM

แต่ช่วง 20:00 น.

1,000 RPM

Rate Limit เกิดจากช่วง Peak

ไม่ใช่ค่าเฉลี่ยทั้งวัน

ดังนั้นต้องเก็บ

Peak RPM
Peak TPM

📉 ลด Duplicate Request

Frontend ควร Disable ปุ่มเมื่อ Request กำลังทำงาน

ตัวอย่าง

กด Generate
↓
Button Disabled
↓
API Request
↓
Response
↓
Button Enabled

ช่วยป้องกัน User กด

Generate
Generate
Generate
Generate

จนเกิด Request ซ้ำ

🔄 ใช้ Request Deduplication

ถ้า Input เหมือนกันภายในช่วงเวลาสั้น

Application บางประเภทสามารถ Cache Result หรือรวม Request ได้

เช่น

User A: FAQ เดียวกัน
User B: FAQ เดียวกัน
User C: FAQ เดียวกัน

ถ้า Business Logic อนุญาต อาจไม่ต้องเรียก Gemini ใหม่ทุกครั้ง

ช่วยลด

• RPM
• TPM
• Cost

🗃️ Cache คำตอบเมื่อเหมาะสม

ข้อมูล Static เช่น

คำอธิบายสินค้าเดิม

ไม่จำเป็นต้อง Generate ใหม่ทุก Page View

สามารถสร้างครั้งเดียว

Gemini
↓
Database/Cache
↓
Reuse

ต่างจากข้อมูลสดที่ต้องสร้างใหม่

🧠 Context Caching ช่วยได้หรือไม่

ถ้ามี Context ใหญ่ที่ใช้ซ้ำ Context Caching สามารถช่วยเรื่อง Cost และ Processing Efficiency ตาม Model/API

แต่ไม่ควรคิดว่า Caching เป็นวิธีหลบ Rate Limit ทุกประเภท

ต้องตรวจ TPM และ Metric ที่เกี่ยวข้องจริง

🛠️ วิธีแก้ 429 ตามสาเหตุ

RPM เต็ม

• ลด Request Rate
• Queue
• Backoff
• Upgrade Capacity

TPM เต็ม

• ลด Context
• ลด Parallel File Processing
• Queue
• Optimize Prompt

RPD เต็ม

• รอ Reset
• เพิ่ม Tier/Quota

Spend Rate เต็ม

• รอ
• ลด Expensive Requests
• ลด Output/Context
• ขอ Increase หากจำเป็น

Prepay Credit หมด

• เติม Credit
• ตรวจ Billing
• ตั้ง Auto-reload

Preview Model Limit ต่ำ

• ตรวจ Stable Model
• ลด Traffic
• ขอ Capacity หากรองรับ

แก้ตาม Root Cause เท่านั้น

🧪 Checklist Debug 429

✅ Error Type

อ่านแล้ว

✅ Project

ถูก Project

✅ Model

รู้ว่าใช้ Model ไหน

✅ RPM

ตรวจแล้ว

✅ TPM

ตรวจแล้ว

✅ RPD

ตรวจแล้ว

✅ Spend Rate

ตรวจแล้ว

✅ Billing

Credit ปกติ

✅ Retry

มี Backoff

✅ Parallelism

ไม่สูงเกิน

✅ Files

ไม่ได้ส่งจำนวนมากพร้อมกัน

✅ API Key

ไม่มี Traffic ผิดปกติ

✅ Monitoring

มีข้อมูลประกอบ

ถ้ายังไม่พบสาเหตุจึงค่อยพิจารณาปัญหาด้าน Service Capacity หรือ Integration Path

🚫 12 วิธีแก้ Error 429 ที่ไม่ควรทำ

❶ สร้าง API Key เพิ่มทันที

ไม่เพิ่ม Project Rate Limit

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

ทำให้ Traffic หนักขึ้น

❸ Catch Error แล้ว Ignore

User ไม่รู้ว่า Request ล้มเหลว

❹ เปิด Worker เพิ่ม

อาจทำให้ 429 มากขึ้น

❺ เพิ่ม Parallelism

ผิดทางหาก Capacity เต็ม

❻ เปลี่ยน Model แบบสุ่ม

ควรดู Limit ก่อน

❼ ลบ API Key ทั้งหมด

ไม่ใช่ Root Cause ทั่วไป

❽ เปิด Billing โดยไม่ตรวจ Usage

Paid Tier ยังมี Limit

❾ ส่ง Context เดิมมหาศาลทุกครั้ง

เพิ่ม TPM

❿ Retry 400 แบบเดียวกับ 429

400 ต้องแก้ Request

⓫ เปิด Public Endpoint โดยไม่มี Limit

ปัญหาจะกลับมา

⓬ Hard-code Rate Limit จาก Tutorial

Active Limit สามารถเปลี่ยนได้

🪜 Workflow แก้ Gemini API Error 429 ที่แนะนำ

❶ Capture Error

เก็บ Message และ Code

❷ ตรวจ AI Studio

ดู Project, Tier และ Rate Limits

❸ ตรวจ Usage

RPM/TPM/RPD

❹ ตรวจ Billing

Credit และ Spend

❺ ลด Burst

จำกัด Parallelism

❻ เพิ่ม Backoff

Retry แบบมีระยะ

❼ ลด Context

ถ้า TPM สูง

❽ ลด Output

ถ้า Request แพง

❾ Queue Background Work

อย่าแย่ง Interactive Traffic

❿ ใช้ Batch

สำหรับ Bulk Processing

⓫ Upgrade Tier

ถ้า Usage ปกติสูงกว่าปัจจุบัน

⓬ Request Increase

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

⓭ Monitor ต่อ

ดูว่า 429 ลดจริงหรือไม่

แนวทางของ comsiam คือแก้ 429 จากข้อมูล Usage จริง ไม่ใช้วิธีสร้าง Key ใหม่หรือเพิ่ม Retry แบบเดาสุ่ม เพราะสองวิธีนี้มักไม่แก้ปัญหาที่ต้นเหตุและอาจทำให้ระบบหนักกว่าเดิม

💡 ตัวอย่างสถานการณ์ที่ 1: Chatbot คนเข้าเยอะ

อาการ

ปกติใช้ได้
ช่วงเย็นเริ่ม 429

ตรวจพบ

RPM พุ่ง

วิธีแก้

• Application Rate Limit
• Queue ระยะสั้น
• Backoff
• Scale Tier/Quota

นี่เป็น Traffic Problem

💡 ตัวอย่างสถานการณ์ที่ 2: วิเคราะห์ PDF

อาการ

Request ไม่เยอะ
แต่ 429

ตรวจพบว่าแต่ละ Request ใช้ Context ใหญ่มาก

มีโอกาสเป็น

TPM

แก้ด้วย

• ลด Parallel PDF Jobs
• Queue
• จำกัด File
• Optimize Context

ไม่ใช่สร้าง Key เพิ่ม

💡 ตัวอย่างสถานการณ์ที่ 3: ใช้มาทั้งวันแล้วหยุด

อาการ

ตอนเช้าใช้ได้
กลางคืน 429 ทุก Request

ตรวจ

RPD

หาก Daily Quota หมด ต้องรอ Reset หรือเพิ่ม Capacity

💡 ตัวอย่างสถานการณ์ที่ 4: Paid Project แล้ว 429

ตรวจ

• Tier
• Spend Rate
• Prepay Balance
• Billing Status

ถ้า Error ระบุ Credit หมด ให้แก้ Billing

ถ้า Credit เหลือแต่ Spend Rate เต็ม ให้รอ Rolling Window และลด Expensive Traffic

💡 ตัวอย่างสถานการณ์ที่ 5: Usage ต่ำแต่ยัง 429

ให้ทำ

1. Test Prompt สั้น
2. Test Model เดิม
3. ลด Tool/File
4. ใช้ Backoff
5. ตรวจ Active Limit
6. เก็บ Request ID

เพราะ Google ระบุว่า Rate Limit ที่กำหนดไม่ได้รับประกัน Actual Capacity เสมอไป

หากยังเกิดต่อเนื่องควรใช้ข้อมูลเหล่านี้ประกอบการ Troubleshooting

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

Gemini API Error 429 คืออะไร

หมายถึง Gemini API ปฏิเสธ Request เนื่องจาก Rate Limit, Quota หรือ Resource Limit ที่เกี่ยวข้อง เช่น RPM, TPM, RPD หรือ Spend-based Limit เต็ม

Error 429 แก้อย่างไรเร็วที่สุด

อ่าน Error ก่อน จากนั้นตรวจ Active Rate Limits ใน AI Studio หากเป็น Limit ระยะสั้นให้รอและ Retry ด้วย Exponential Backoff พร้อมลด Request Rate

สร้าง Gemini API Key ใหม่แก้ 429 ได้ไหม

โดยทั่วไปไม่ช่วยหากเป็น Rate Limit เพราะ Gemini API ใช้ Limit ในระดับ Project ไม่ใช่ต่อ API Key

ทำไม Request น้อยแต่ยังเจอ 429

อาจชน TPM เพราะ Input ใหญ่ เช่น PDF หรือ Conversation History หรืออาจชน Spend-based Limit, Model-specific Limit หรือ Actual Service Capacity

Error 429 ต้องเปิด Billing ไหม

ไม่จำเป็นทุกกรณี หาก Free Tier ยังเพียงพอสามารถรอ Quota Reset หรือลด Usage ได้ แต่ Production ที่ต้องใช้ Capacity สูงขึ้นอาจต้องพิจารณา Paid Tier

ควร Retry 429 กี่ครั้ง

ไม่มีตัวเลขเดียวที่เหมาะกับทุกระบบ ควรกำหนด Maximum Attempts และใช้ Exponential Backoff พร้อม Jitter โดยพิจารณา SLA และ Use Case ของ Application

🎯 สรุป

Gemini API Error 429 หรือ RESOURCE_EXHAUSTED ไม่ได้หมายความว่า API Key เสีย แต่โดยทั่วไปเกี่ยวข้องกับการใช้ Request, Token, Daily Quota หรือ Resource/Spend Limit เกินเงื่อนไขที่ Project รองรับ

Google ปัจจุบันแยก 429 เป็นหลายกรณี เช่น rate_limit_exceeded, quota_exceeded และ too_many_requests ดังนั้นต้องอ่านข้อความ Error ก่อนแก้

Rate Limit หลักของ Gemini API คือ RPM, TPM และ RPD และถูกบังคับใช้ระดับ Project ไม่ใช่ API Key การสร้าง Key เพิ่มใน Project เดิมจึงไม่เพิ่ม Capacity

แนวทางแก้ที่เหมาะสมคือเปิด AI Studio ตรวจ Active Rate Limits และ Usage จากนั้นลด Request Burst, ลด Parallelism, ลด Context, จำกัด Output และใช้ Exponential Backoff พร้อม Maximum Retry

สำหรับงานจำนวนมากที่ไม่ต้องตอบทันที ควรย้ายไป Queue หรือ Batch API เพื่อลด Interactive Traffic ส่วน Production System ควรมี Application Rate Limit และ User Quota ของตัวเอง

หาก Paid Project มี Error ที่เกี่ยวข้องกับ Prepay Credit ต้องตรวจ Billing และ Credit Balance เพราะบัญชี Prepay ต้องมี Positive Balance เพื่อให้ Paid Gemini API ทำงานต่อได้

เมื่อ Application โตจน Traffic ปกติเกิน Capacity ของ Tier ปัจจุบัน จึงค่อย Upgrade Tier หรือยื่นคำขอ Rate Limit Increase แทนการพยายามหลบ Limit ด้วยการสร้าง API Key จำนวนมาก