Rate limit

Rate limit คือเพดานที่ผู้ให้บริการโมเดลกำหนดไว้ว่าบัญชีหนึ่งเรียกใช้ api ได้ถี่แค่ไหนภายในช่วงเวลาหนึ่ง สิ่งที่ถูกนับมักมีสองอย่างคู่กัน คือจำนวนคำขอ (requests) และจำนวน token ที่ไหลผ่านระบบ สิ่งที่เพดานนี้คุมคือความเร็ว ไม่เกี่ยวกับยอดเงินที่องค์กรยอมจ่าย เอกสาร rate limits ของ Anthropic แยกสองเรื่องนี้ออกจากกันตั้งแต่ย่อหน้าแรกว่าเป็น limit คนละชนิด ได้แก่ spend limit ที่คุมค่าใช้จ่ายสูงสุดต่อเดือน กับ rate limit ที่คุมความถี่ในการเรียกใช้ ทั้งสองอย่างชนได้แยกกันและแก้คนละวิธี

แต่ละเจ้านับไม่เหมือนกัน ตามเอกสารทางการที่ตรวจสอบวันที่ 14 สิงหาคม 2026 Anthropic วัด Messages API ด้วยสามแกน คือคำขอต่อนาที (RPM) input token ต่อนาที (ITPM) และ output token ต่อนาที (OTPM) โดยแยกเพดานตามชั้นของโมเดล ใช้ต่างโมเดลพร้อมกันจึงได้เพดานของแต่ละตัวเต็มจำนวน แต่ต้องอ่านเชิงอรรถใต้ตารางด้วย เพราะบางตระกูลนับทราฟฟิกของรุ่นย่อยรวมเป็นก้อนเดียวกัน ฝั่ง OpenAI ระบุแกนการนับไว้มากกว่านั้น คือ RPM, RPD (คำขอต่อวัน), TPM, TPD, IPM (ภาพต่อนาที) และนาทีเสียงต่อนาทีสำหรับบางโมเดลเสียงแบบสตรีม ส่วน Google Gemini นับ RPM, TPM ฝั่ง input และ RPD เป็นหลัก ประเด็นที่คนมักพลาดคือเพดานผูกอยู่กับอะไร OpenAI ระบุว่ากำหนดที่ระดับ organization และ project ไม่ใช่ระดับผู้ใช้รายคน ขณะที่เอกสารของ Gemini เขียนตรงตัวว่าเพดานคิดต่อ project ไม่ใช่ต่อ api-key แปลว่าการแจกกุญแจเพิ่มให้แต่ละทีมถือคนละดอกไม่ได้ทำให้โควตารวมเพิ่มขึ้นแม้แต่นิดเดียว

กลไกที่อธิบายว่าทำไมงานอัตโนมัติซึ่งเคยรันผ่านถึงพังตอนยิงพร้อมกันเยอะๆ อยู่ตรงที่เพดานไม่ได้ถูกบังคับเป็นก้อนรายนาทีอย่างที่ชื่อชวนให้เข้าใจ เอกสารของ Anthropic อธิบายว่าใช้อัลกอริทึม token bucket ซึ่งเติมโควตาคืนให้อย่างต่อเนื่อง ไม่ได้รีเซ็ตเป็นรอบตามเข็มนาฬิกา และยกตัวอย่างไว้ตรงๆ ว่าเพดาน 60 คำขอต่อนาทีอาจถูกบังคับจริงในระดับ 1 คำขอต่อวินาที การยิง 60 คำขอรวดเดียวในวินาทีแรกจึงชนเพดานได้ ทั้งที่ค่าเฉลี่ยทั้งนาทีไม่เกินสักหน่อย กลไกนี้อธิบายเคสที่เจอกันบ่อย เช่น workflow ใน n8n ที่ทดลองกับข้อมูล 20 แถวแล้วผ่านฉลุย แต่พังเป็นแถบตอนกดรันจริง 800 แถว เพราะตัวเครื่องมือวนยิงเร็วที่สุดเท่าที่ทำได้โดยไม่มีใครสั่งให้ชะลอ เอกสารเดียวกันยังเตือนถึง acceleration limit ด้วยว่า ถ้าปริมาณใช้งานขององค์กรพุ่งขึ้นแบบหักศอก อาจเจอการปฏิเสธได้แม้ตัวเลขยังไม่ถึงเพดานในตาราง คำแนะนำคือค่อยๆ เพิ่ม traffic และรักษาแพทเทิร์นการใช้งานให้สม่ำเสมอ

สัญญาณที่คนทำงานจะเห็นจริงคือ error 429 ซึ่งชื่อเต็มตามมาตรฐาน HTTP คือ Too Many Requests นิยามอยู่ใน RFC 6585 หัวข้อ 4 หมายความว่าฝั่งเราส่งคำขอถี่เกินไปในช่วงเวลาหนึ่ง และเซิร์ฟเวอร์อาจแนบ header ชื่อ Retry-After มาบอกว่าควรรอนานเท่าไรก่อนลองใหม่ เอกสารของ Anthropic ระบุว่าเมื่อชนเพดานจะได้ error 429 ที่บอกด้วยว่าเพดานตัวไหนถูกเกิน พร้อม header ตัวนี้ที่บอกจำนวนวินาทีที่ต้องรอ โดยเอกสารเตือนว่าการรีทรายก่อนครบเวลาจะล้มซ้ำ และ OpenAI อธิบายว่าค่าใน Retry-After คือจำนวนวินาทีขั้นต่ำที่ต้องรอ ทั้งสองเจ้ายังส่งชุด header บอกโควตาคงเหลือกลับมาใน response ของ API ด้วย ชุดของ Anthropic ขึ้นต้นด้วย anthropic-ratelimit- ส่วนของ OpenAI ขึ้นต้นด้วย x-ratelimit- คนดูแลระบบจึงเฝ้าดูได้ว่าเหลือ headroom เท่าไรก่อนจะชน แนวทางแก้ที่เอกสาร OpenAI แนะนำคือ exponential backoff คือรอนานขึ้นเป็นทวีคูณในแต่ละครั้งที่ลองใหม่ บวกกับ jitter คือการสุ่มเวลารอเพิ่มเข้าไปอีกเล็กน้อย บทความสถาปัตยกรรมของ AWS อธิบายเหตุผลของ jitter ไว้ชัดว่า ถ้าทุก client ที่โดนปฏิเสธพร้อมกันคำนวณเวลารอเท่ากันเป๊ะ มันจะกลับมาชนกันใหม่เป็นระลอกซ้ำๆ การสุ่มเวลารอช่วยเกลี่ยคำขอให้กระจายเป็นอัตราที่ค่อนข้างคงที่แทน

สองข้อควรระวังสำหรับคนที่ต้องตัดสินใจเชิงจัดซื้อ ข้อแรกคือตัวเลขในตารางเพดานเปลี่ยนบ่อยและไม่ใช่คำสัญญา เอกสารของ Anthropic ระบุว่าตัวเลขเหล่านั้นคือปริมาณสูงสุดที่อนุญาต ไม่ใช่ปริมาณขั้นต่ำที่รับประกัน ส่วนเอกสารของ Gemini เขียนไว้ตรงๆ ว่าเพดานที่ประกาศไม่ได้รับประกันและกำลังการให้บริการจริงอาจต่างไปจากนั้น การวางแผนความจุจากตัวเลขในหน้าเอกสารเพียงอย่างเดียวจึงเสี่ยง ข้อสองคือถ้าใช้ตัวกลางอย่าง openrouter เพดานจะมาจากสองชั้นซ้อนกัน เอกสารของ OpenRouter อธิบายว่ามีทั้งเพดานของแพลตฟอร์มเอง และเพดานที่ ผู้ให้บริการโมเดล ต้นทางบังคับมาอีกที เอกสารระบุว่า 429 มาได้จากสองทาง ถ้ามาจากผู้ให้บริการต้นทางที่กำลังจำกัดอัตราหรือคิวเต็ม ระบบ fallback routing จะลองผู้ให้บริการรายอื่นของโมเดลเดียวกันให้อัตโนมัติก่อนที่ error จะถึงมือเรา แต่ถ้าเป็นเพดานของแพลตฟอร์ม OpenRouter เอง เช่น โควตาโมเดลฟรีต่อนาทีหรือต่อวัน หรือระบบกัน DDoS กรณีนี้เอกสารบอกว่า 429 ตัวนั้นมาจาก OpenRouter โดยตรง และแนะนำให้รอแล้วค่อยลองใหม่แบบ exponential backoff พร้อมเคารพค่าใน Retry-After ถ้ามีแนบมา ตัวอย่างเพดานฝั่งแพลตฟอร์มที่หน้านั้นระบุไว้ ณ วันที่ 14 สิงหาคม 2026 คือโมเดลฟรีที่ ID ลงท้ายด้วย :free ถ้าบัญชีซื้อเครดิตยังไม่ถึง 10 เครดิต จะถูกจำกัดที่ 20 คำขอต่อนาทีและ 50 คำขอต่อวัน ส่วนบัญชีที่ซื้อครบ 10 เครดิตขึ้นไปได้โควตารายวันขยับเป็น 1,000 คำขอ ตัวเลขชุดนี้เป็นของวันที่ตรวจสอบเท่านั้น ก่อนวางระบบจริงต้องเปิดหน้าเอกสารของเจ้าที่ใช้อยู่ดูซ้ำทุกครั้ง

มีอีกจุดที่ช่วยยืดเพดานได้โดยไม่ต้องขอเพิ่ม เอกสารของ Anthropic ระบุว่าสำหรับโมเดล Claude ส่วนใหญ่ token ที่อ่านจาก cache ไม่ถูกนับเข้าเพดาน input ต่อนาที (มีบางรุ่นที่นับ เอกสารกำกับด้วยสัญลักษณ์ไว้ในตาราง) การจัดโครงพรอมต์ให้ส่วนที่ซ้ำเดิมถูก cache ไว้จึงเพิ่ม throughput ที่ใช้ได้จริงโดยที่ตัวเลขเพดานเท่าเดิม ซึ่งเป็นคนละเรื่องกับการอัปเกรด tier

ตัวอย่างจากบทสนทนาจริง

ฝ่ายการตลาด: workflow แปลรายละเอียดสินค้าตอนทดลอง 20 แถวผ่านหมดเลยค่ะ พอกดรันจริง 800 แถว ขึ้น error 429 เกินครึ่ง งานเดียวกันแท้ๆ ทำไมพังคะ

ทีม IT: ตอนทดลองเรากดทีละนิดครับ แต่รอบจริงระบบยิงรวดเดียวทั้งชุด ชนเพดานคำขอต่อนาทีของผู้ให้บริการ ต้องตั้งให้ทยอยยิงและให้ระบบอ่านค่าใน header retry-after แล้วรอตามนั้นก่อนลองใหม่ อย่าให้มันวนลองซ้ำทันทีเพราะจะยิ่งชนหนักกว่าเดิม

ฝ่ายการตลาด: แปลว่าต้องอัปเกรดแพ็กเกจให้แพงขึ้นใช่ไหมคะ

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

ระวังสับสนกับ

• ai-spend-cap : spend cap คือเพดานเงินที่คุมว่าจ่ายได้สูงสุดเท่าไร ชนแล้วต้องเพิ่มวงเงินหรือรอรอบบิลถัดไป ส่วน rate limit คือเพดานความเร็วที่คุมว่ายิงได้ถี่แค่ไหน ชนแล้วรอให้โควตาเติมคืนก็ไปต่อได้ ถ้าเป็นเพดานรายนาทีมักรอแค่ไม่กี่วินาที แต่ถ้าเป็นเพดานรายวันต้องรอถึงรอบวันถัดไป เอกสารของ Anthropic แยกสองอย่างนี้เป็น limit คนละชนิดชัดเจน และองค์กรชนได้ทั้งคู่ในวันเดียวกันโดยไม่เกี่ยวกัน
• context-window : context window คือเพดานความยาวของข้อมูลที่ยัดเข้าไปได้ในคำขอเดียว เกินแล้วคำขอนั้นไม่ผ่านตั้งแต่แรก ส่วน rate limit คือเพดานที่นับข้ามคำขอในหน่วยเวลา คำขอสั้นๆ ที่ผ่าน context window สบายๆ ก็ยังชน rate limit ได้ถ้ายิงถี่เกินไป