Rate limit และ Error 429 ใน LLM API คืออะไร แก้อย่างไร

สคริปต์ที่ส่งงานให้ LLM ทีละร้อยชิ้นทำงานได้ดีตอนทดสอบสิบชิ้น พอรันจริงกลับล้มกลางทางด้วย 429 Too Many Requests หรือ coding agent ที่ทั้งทีมใช้ API key ขององค์กรเดียวกัน หยุดชะงักพร้อมกันตอนบ่าย ทั้งสองอาการมาจากเรื่องเดียวกันคือ rate limit

Rate limit คืออะไร มีกี่แบบ

Rate limit คือเพดานที่ผู้ให้บริการ API กำหนดว่าบัญชีหนึ่งใช้งานได้มากแค่ไหนต่อช่วงเวลา นับทั้งจำนวนคำขอและจำนวน token ถ้ามิติใดมิติหนึ่งเต็มก่อน คำขอถัดไปจะถูกปฏิเสธด้วย 429 จนกว่าโควตาจะคืนกลับมา

เอกสารของ Anthropic อธิบายว่า Claude API ใช้ token bucket คือโควตาค่อยๆ เติมกลับต่อเนื่อง ไม่ได้รีเซ็ตทีเดียวทุกต้นนาที และ limit 60 RPM อาจบังคับจริงเป็น 1 คำขอต่อวินาที การยิงคำขอรวดเดียวจึงโดน 429 ได้แม้ยอดรวมทั้งนาทียังไม่ถึง

limit ผูกกับองค์กร โปรเจกต์ หรือบัญชี ไม่ใช่ API key การแจก key ให้หลายคนในทีมจึงไม่ได้เพิ่มเพดาน ทุกคนใช้ถังเดียวกัน

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

Error 429 Too Many Requests คือ HTTP status ที่ API ตอบเมื่อคำขอเกินเพดานของบัญชี แต่ 429 ไม่ได้มีแบบเดียว ต้องอ่าน type และ code ในเนื้อ error ก่อนตัดสินใจว่าจะรอแล้วลองใหม่ หรือต้องไปแก้ที่บัญชี

Claude ยังมี acceleration limit ที่ทำให้เจอ 429 เมื่อการใช้งานขององค์กรพุ่งขึ้นกะทันหัน ทางแก้คือเพิ่มปริมาณงานทีละขั้น ส่วน 529 overloaded_error ของ Claude และ 503 ของ OpenAI ไม่ใช่ rate limit ของคุณ แต่เป็นสัญญาณว่าฝั่งผู้ให้บริการรับงานไม่ไหวชั่วคราว

ดู rate limit ที่เหลือจาก response header อย่างไร

ทุกคำตอบจาก OpenAI และ Claude มี header บอกเพดาน จำนวนที่เหลือ และเวลาที่โควตาจะคืน อ่านค่าพวกนี้เพื่อชะลอเองก่อนชน 429 ได้ ชื่อ header ของสองเจ้าไม่เหมือนกัน

ดู header ด้วย curl แบบเร็วๆ

curl -s -D - -o /dev/null https://api.openai.com/v1/chat/completions \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"gpt-6-luna","messages":[{"role":"user","content":"ping"}]}' \
  | grep -i -E "ratelimit|retry-after"

DeepSeek ไม่มีเพดานต่อนาทีแบบเจ้าอื่น แต่นับจำนวนคำขอที่ค้างพร้อมกันต่อบัญชี ระหว่างที่คำขอรอ เซิร์ฟเวอร์จะส่งบรรทัดว่างหรือคอมเมนต์ : keep-alive มาเรื่อยๆ ถ้าเขียนตัวอ่าน HTTP เองต้องข้ามบรรทัดพวกนี้ และถ้ารอ 10 นาทีแล้วยังไม่เริ่มประมวลผล เซิร์ฟเวอร์จะตัดการเชื่อมต่อ

แก้ 429 ด้วย retry แบบ exponential backoff อย่างไร

Exponential backoff คือการรอแล้วลองใหม่ โดยเพิ่มเวลารอเป็นเท่าตัวทุกครั้งที่ยังล้ม และสุ่มเวลา (jitter) เพื่อไม่ให้หลาย worker ยิงกลับพร้อมกัน ถ้าคำตอบมี retry-after ให้รอตามนั้นก่อน และต้องจำกัดจำนวนครั้ง เพราะเอกสารของ OpenAI ระบุว่าคำขอที่ล้มก็ถูกนับเข้า limit ต่อนาทีด้วย

import random, time
from openai import OpenAI, RateLimitError

client = OpenAI(max_retries=0)  # ปิด retry ในตัว แล้วคุมเอง
NO_RETRY = {"credit_balance_exhausted", "organization_spend_limit_exceeded",
            "project_spend_limit_exceeded", "organization_usage_limit_exceeded"}

def ask(messages, attempts=6, base=1.0, cap=60.0):
    for i in range(attempts):
        try:
            return client.chat.completions.create(model="gpt-6-luna", messages=messages)
        except RateLimitError as e:
            if e.code in NO_RETRY or i == attempts - 1:
                raise  # วงเงินหมด หรือครบจำนวนครั้งแล้ว
            ra = e.response.headers.get("retry-after")
            delay = float(ra) if ra else random.uniform(0, min(cap, base * 2 ** i))
            time.sleep(delay)

โค้ดนี้ลองได้ 6 ครั้ง มีช่วงรอ 5 ช่วง ช่วงที่ i สุ่มระหว่าง 0 ถึง min(60, 2^i) วินาที ช่วงแรกไม่เกิน 1 วินาที ช่วงที่ห้าไม่เกิน 16 วินาที รวมไม่เกิน 31 วินาทีถ้าไม่มี retry-after ครบแล้วยังไม่ผ่านให้โยน error ขึ้นไปให้คิวจัดการต่อ

ลดโอกาสโดน 429 ตั้งแต่ต้นทำอย่างไร

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

1. จำกัดงานพร้อมกัน ใช้ semaphore หรือคิวให้ worker ส่งได้ทีละไม่กี่งาน

   import asyncio
   sem = asyncio.Semaphore(4)  # ส่งพร้อมกันไม่เกิน 4 งาน
   async def run(task):
       async with sem:
           return await call_llm(task)

2. ตั้ง max_tokens ให้พอดี OpenAI ประเมิน TPM จากค่าที่มากกว่าระหว่าง max_tokens กับ token ที่ประเมินจากคำขอ ตั้งเผื่อมากไปก็เปลืองโควตาเปล่าๆ

3. ใช้ prompt caching ITPM ของ Claude คิดเฉพาะ input ที่ไม่ได้อ่านจาก cache ส่วนต้นที่ cache ติดจึงไม่กินโควตา (ดู Prompt caching และ KV cache)

4. งานที่ไม่รีบส่งเป็น batch Batch API ของ OpenAI และ Claude มีโควตาแยก และคิดราคาครึ่งเดียว (ราคาเทียบไว้ใน ราคา LLM API 2026)

5. ขยับ tier ทุกเจ้าเพิ่มเพดานตามประวัติการจ่ายเงิน

ทำไม coding agent ชน rate limit บ่อย

coding agent ชน rate limit บ่อยเพราะแต่ละรอบส่ง context ทั้งก้อน หลายหมื่นถึงแสน token ต่อคำขอ เพดานที่เต็มก่อนจึงมักเป็น token ต่อนาที ไม่ใช่จำนวนคำขอ และยิ่งแตก sub-agent ทำงานขนานกัน ทุกตัวก็ดึงจากถังเดียวกัน

ลองคิดด้วยเพดานของ claude-sonnet-5-5 ใน Start tier ณ พฤศจิกายน 2569 คือ 4,000 RPM, 2,000,000 ITPM และ 400,000 OTPM ถ้า agent ส่ง context 80,000 token ต่อรอบโดยไม่มี cache ทั้งองค์กรจะทำได้ราว 25 รอบต่อนาที ทีม 5 คนที่แต่ละคนเปิด sub-agent 3 ตัวจะชนเพดานได้ง่าย แต่ถ้า 90% ของ context อ่านจาก cache ส่วนที่นับเหลือ 8,000 token ต่อรอบ เพดานเดียวกันรับได้ราว 250 รอบต่อนาที

สิ่งที่ช่วยได้คือให้ agent แต่ละตัวเห็นเฉพาะไฟล์ที่จำเป็น คุมจำนวน sub-agent ที่รันพร้อมกัน และแยก workspace หรือโปรเจกต์ให้งานอัตโนมัติไม่แย่งโควตากับคนที่นั่งทำงาน ส่วนคนที่ใช้ Claude Code ผ่านแพ็ก Pro หรือ Max เพดานรอบ 5 ชั่วโมงและรายสัปดาห์เป็นคนละระบบกับ rate limit ของ API อ่านต่อที่ Claude Code ติด limit ทำอย่างไร

buzzAI จำกัดการใช้งานอย่างไร

buzzAI เป็น API แบบเหมาจ่ายสำหรับ coding agent ใช้กับ Claude Code, Codex CLI และเครื่องมือที่ตั้ง base URL แบบ OpenAI-compatible ได้ ไม่คิดค่า token และไม่มีโควตารายวันหรือรายสัปดาห์ สิ่งที่จำกัดแทนคือจำนวน agent ที่รันพร้อมกัน ขนาด context ตามแพ็ก และคิวในช่วงที่คนใช้เยอะ

แพ็ก Personal รัน agent ได้ทีละ 1 ตัว ถ้าเครื่องมือของคุณแตก sub-agent ก็ยังใช้ได้ แต่ sub-agent จะผลัดกันทำงานทีละตัว แพ็กบริษัทรันได้ 1–8 ตัวพร้อมกันพร้อม context 256K และในเวลาทำการ จันทร์–ศุกร์ 08:00–20:00 น. แพ็กบริษัทและ slot ที่จองไว้ได้คิวก่อน แพ็ก Personal จึงอาจต้องรอ ตอนนี้ API ยังไม่เปิดให้ใช้ทั่วไป กดขอร่วมทดสอบได้ที่หน้าแรก แล้วเราจะส่ง API key ทางอีเมลเมื่อมีผู้สมัครครบโควต้าที่กำหนด ดูแพ็กทั้งหมดได้ที่หน้าราคา