GPT API อัตราจำกัด: ระดับ, ขีดจำกัดการใช้งาน และวิธีทดสอบด้วย Apidog

คุณส่งฟังก์ชันที่เรียกใช้ GPT API ออกไปใช้งาน มันทำงานได้ดีใน staging แต่เมื่อผู้ใช้ร้อยคนแรกเข้ามาใช้งานใน production log ของคุณก็เต็มไปด้วย 429 Too Many Requests ตอนนี้คุณกำลังเดาว่า: มันเป็นจำนวนคำขอต่อนาที (requests per minute), โทเค็นต่อนาที (tokens per minute) หรือขีดจำกัดรายวัน (daily caps)? คุณยังอยู่ใน Tier 1 อยู่หรือเปล่า? โมเดลที่คุณเปลี่ยนไปใช้เมื่อสัปดาห์ที่แล้วมีข้อจำกัดที่เข้มงวดกว่าโมเดลเก่าหรือไม่?

หากคุณเคยทำงานกับ OpenAI มาก่อน คุณจะทราบดีว่าเรื่องของอัตราการจำกัดนั้นซับซ้อนขึ้นเรื่อยๆ กับโมเดลใหม่ทุกรุ่น GPT-5.5 มีขีดจำกัดที่แตกต่างจาก GPT-4.1 โมเดลรูปภาพมีการนับที่แตกต่างจากโมเดลข้อความ และระดับการใช้งานของคุณจะเปลี่ยนไปโดยที่คุณไม่รู้ตัวเมื่อคุณใช้จ่ายเพิ่มขึ้น Apidog มอบพื้นที่ทำงานเดียวให้คุณเพื่อตรวจสอบเฮดเดอร์การตอบกลับของแต่ละคำขอ จำลองการเข้าชมพร้อมกัน และยืนยันได้อย่างแม่นยำว่าคุณกำลังชนขีดจำกัดใด ก่อนที่คุณจะนำโค้ดไปใช้งานจริง ดาวน์โหลด Apidog หากคุณยังไม่มี; ขั้นตอนการทำงานด้านล่างนี้สามารถใช้ได้กับแผนฟรี

button

สี่ขีดจำกัดที่สำคัญจริงๆ

OpenAI ใช้การจำกัดอัตราหลายอย่างกับคีย์ GPT API ทุกคีย์ คุณจะเห็นทั้งสี่ข้อบังคับสำหรับแอปพลิเคชันที่ใช้งานจริงทุกประเภท:

• RPM (requests per minute หรือ จำนวนคำขอต่อนาที): จำนวนการเรียกใช้ API ที่คุณสามารถส่งได้ต่อนาที เป็นขีดจำกัดที่ต่ำที่สุดสำหรับระดับส่วนใหญ่
• TPM (tokens per minute หรือ โทเค็นต่อนาที): โทเค็นอินพุตและเอาต์พุตที่คุณสามารถประมวลผลได้ต่อนาที เป็นขีดจำกัดที่คนส่วนใหญ่มักจะลืม
• RPD (requests per day หรือ คำขอต่อวัน): ขีดจำกัดรายวันสำหรับคีย์แบบฟรีและ Tier 1 จะหายไปในระดับที่สูงขึ้นสำหรับโมเดลข้อความส่วนใหญ่
• IPM / TPD / batch queue limits: ขีดจำกัดเฉพาะโมเดลสำหรับการสร้างรูปภาพ เสียง การฝัง (embeddings) และเอนด์พอยต์แบบ Batch กลุ่มเอนด์พอยต์แต่ละประเภทมีขีดจำกัดของตัวเอง

เมื่อคำขอของคุณถูกปฏิเสธ API จะส่งคืน HTTP 429 พร้อมกับบอดี้ JSON ดังนี้:

{
 "error": {
 "message": "Rate limit reached for gpt-5.5 in organization org-abc on tokens per min (TPM): Limit 30000, Used 28432, Requested 3120.",
 "type": "tokens",
 "param": null,
 "code": "rate_limit_exceeded"
 }
}

สังเกตว่าบอดี้จะบอกคุณว่าคุณเกินขีดจำกัดในมิติใด: tokens, requests หรือบางครั้ง tokens_usage_based นี่คือสิ่งแรกที่คุณควรอ่านเมื่อเกิดปัญหา ข้อผิดพลาดจากการเกิน TPM จะดูแตกต่างจากการเกิน RPM และวิธีแก้ไขก็แตกต่างกันด้วย 429 แต่ละครั้งไม่เหมือนกัน

สำหรับข้อมูลอ้างอิงแบบครบวงจรว่า 429 หมายถึงอะไรในระดับ HTTP โปรดดู เอกสาร MDN 429 และ ข้อกำหนด RFC 6585 สำหรับพฤติกรรมเฉพาะของ OpenAI เกี่ยวกับเฮดเดอร์การลองใหม่และการเลื่อนระดับ OpenAI ได้จัดทำ หน้าอัตราการจำกัดอย่างเป็นทางการ ที่คุณควรบุ๊กมาร์กไว้

ระดับชั้นทำงานอย่างไร และทำไมคุณถึงได้รับการเลื่อนขั้น (หรือติดขัด)

คีย์ GPT API ของคุณอยู่ในระดับการใช้งานของ OpenAI ระดับชั้นเหล่านี้กำหนดตัวเลขจริงที่อยู่เบื้องหลังขีดจำกัด RPM และ TPM ของคุณ คุณจะเลื่อนระดับขึ้นอยู่กับสองสิ่ง: ยอดใช้จ่ายทั้งหมดในบัญชีของคุณ และระยะเวลาที่คุณชำระเงินครั้งแรก มีทั้งหมดหกระดับ ตั้งแต่ฟรีไปจนถึงระดับ 5 และรูปแบบคร่าวๆ สำหรับโมเดลข้อความเป็นดังนี้:

ตัวเลขข้างต้นเป็นเพียงตัวอย่างเท่านั้น ขีดจำกัดที่แน่นอนจะเปลี่ยนแปลงไปตามเวลาและแตกต่างกันไปในแต่ละโมเดล โปรดอ่านขีดจำกัดที่คุณใช้งานจริงโดยตรงจากแดชบอร์ด หรือดีกว่านั้นคือจากเฮดเดอร์การตอบกลับ API ของคุณเอง (จะกล่าวถึงด้านล่าง) ก่อนที่คุณจะกำหนดขนาดของเวิร์กโหลด

ผลกระทบในทางปฏิบัติสองประการ:

1. คุณจะได้รับการเลื่อนระดับโดยอัตโนมัติเมื่อคุณชำระเงิน ระดับชั้นไม่ใช่สิ่งที่ต้องเลือก เมื่อยอดใช้จ่ายของคุณผ่านเกณฑ์ระดับชั้นและระยะเวลารอได้ผ่านพ้นไป คำขอถัดไปที่คุณทำจะทำงานภายใต้ขีดจำกัดใหม่ ไม่มีการแจ้งเตือน ไม่มีขั้นตอนการโยกย้าย
2. คุณสามารถถูกลดระดับได้ หากบัญชีของคุณไม่ใช้งานเป็นเวลานานหรือวิธีการชำระเงินของคุณล้มเหลว คุณสามารถถูกลดระดับลงได้ โปรดทดสอบในสภาพแวดล้อมการผลิตหลังจากการเปลี่ยนแปลงการเรียกเก็บเงินใดๆ

สำหรับการเปรียบเทียบระบบระดับชั้นของผู้ให้บริการโมเดลอื่นๆ โปรดดู คำอธิบายอัตราการจำกัดของผู้ใช้ OpenAI API, คู่มืออัตราการจำกัด Claude API, และ คู่มืออัตราการจำกัด Grok-3 API แนวคิดพื้นฐานเหมือนกันในทุกผู้ให้บริการ แต่ตัวเลขและมิติเฉพาะนั้นไม่เหมือนกัน

อ่านขีดจำกัดที่คุณใช้งานจริงจากเฮดเดอร์การตอบกลับ

คุณไม่จำเป็นต้องค้นหาผ่านแดชบอร์ดเพื่อดูขีดจำกัดปัจจุบันของคุณ การตอบกลับ GPT API ทุกครั้งจะแสดงข้อมูลเหล่านี้ในเฮดเดอร์ มองหาสี่ข้อนี้:

• x-ratelimit-limit-requests: ขีดจำกัด RPM ของคุณสำหรับเอนด์พอยต์นี้
• x-ratelimit-remaining-requests: จำนวนที่เหลือของคุณในนาทีนี้
• x-ratelimit-limit-tokens: ขีดจำกัด TPM ของคุณ
• x-ratelimit-remaining-tokens: จำนวนโทเค็นที่เหลือของคุณในนาทีนี้

โดยปกติแล้วจะมี x-ratelimit-reset-requests และ x-ratelimit-reset-tokens ด้วย ซึ่งทั้งสองจะระบุระยะเวลาที่เข้าใจง่ายจนกว่าจะมีการเติมเต็มโควต้า (เช่น 6s, 1m30s)

วิธีที่ชัดเจนที่สุดในการอ่านข้อมูลเหล่านี้คือการส่งคำขอ chat-completion เพียงครั้งเดียว สังเกตเฮดเดอร์ที่ส่งกลับมา และยืนยันว่าคุณอยู่ในระดับชั้นที่คุณคิดว่าเป็น Apidog ทำให้การทำเช่นนั้นเป็นเรื่องง่ายเพียงคลิกเดียว

ขั้นตอนที่ 1: กำหนดค่าคำขอ GPT ใน Apidog

เปิด Apidog สร้างโปรเจกต์ใหม่ และเพิ่มคำขอใหม่เข้าไป

เมธอด: POST URL: https://api.openai.com/v1/chat/completions

ในแท็บ Headers:

รูปแบบวงเล็บปีกกาคู่ดึงมาจากตัวแปรสภาพแวดล้อมของ Apidog ซึ่งหมายความว่าคีย์ของคุณจะไม่ถูกเก็บไว้ในคำขอเอง ตั้งค่าตัวแปรเพียงครั้งเดียวภายใต้ Environments สลับสภาพแวดล้อมเพื่อเปลี่ยนระหว่างคีย์ส่วนตัวและคีย์ของทีม และส่วนที่เหลือของคอลเลกชันก็จะถูกดึงไปใช้โดยอัตโนมัติ เคล็ดลับเดียวกันนี้ยังใช้ได้กับ ID องค์กรและโปรเจกต์ที่ OpenAI อนุญาตให้คุณรวมไว้สำหรับการระบุแหล่งที่มาของการเรียกเก็บเงิน

ในแท็บ Body เลือก JSON และวาง:

{
 "model": "gpt-5.5",
 "messages": [
 {"role": "user", "content": "ping"}
 ],
 "max_tokens": 10
}

กด Send คุณควรได้รับการตอบกลับที่สมบูรณ์ตามปกติ ตอนนี้คลิกแท็บ Headers ในแผงการตอบกลับและเลื่อนไปที่แถว x-ratelimit-* ตัวเลขสี่ตัวนั้นคือความจริงปัจจุบันของคุณ ถ่ายภาพหน้าจอไว้ สิ่งเหล่านี้คือค่าพื้นฐานที่คุณจะใช้ในการทดสอบ

หากคุณต้องการเรียนรู้การตั้งค่าคำขอ chat-completion อย่างละเอียดเพิ่มเติม คู่มือวิธีทดสอบ ChatGPT API ด้วย Apidog ของเราครอบคลุมการยืนยันตัวตน, สตรีมมิ่ง, และการเรียกใช้เครื่องมือแบบครบวงจร

ขั้นตอนที่ 2: ยืนยันขีดจำกัดด้วยการส่งคำขอแบบฉับพลัน

การอ่านเฮดเดอร์จะบอกคุณถึงขีดจำกัด การส่งคำขอเพียงครั้งเดียวไม่ได้พิสูจน์อะไรเกี่ยวกับพฤติกรรมเมื่อถึงขีดจำกัด หากต้องการยืนยันว่าการจำกัดความเร็วทำงานตามที่เฮดเดอร์ระบุจริง คุณต้องทำการทดสอบแบบส่งคำขอฉับพลันขนาดเล็ก

Apidog มาพร้อมกับ Tests runner ที่สามารถส่งคำขอเดียวกันได้ N ครั้งพร้อมกัน เปิดคำขอที่คุณบันทึกไว้ คลิกดรอปดาวน์ถัดจาก Send และเลือก Run in Test Scenario ตั้งค่า:

• จำนวนรอบ: 50 (หรือจำนวนที่สูงกว่า RPM ที่ระบุของคุณอย่างเหมาะสม)
• การทำงานพร้อมกัน: 10
• การหน่วงเวลาระหว่างรอบ: 0 มิลลิวินาที

เรียกใช้งาน สิ่งที่มีประโยชน์สองประการคือ:

1. คำขอบางส่วนส่งคืน 429 ก่อนที่การส่งคำขอแบบฉับพลันจะสิ้นสุดลง ดี นั่นเป็นการยืนยันว่าขีดจำกัดจากเฮดเดอร์การตอบกลับและสถานะบัญชีของคุณตรงกัน
2. ทั้ง 50 คำขอสำเร็จ และเฮดเดอร์แสดง remaining-requests ลดลงตามที่คาดไว้ RPM ของคุณสูงกว่าที่คุณคิด ตรวจสอบแผงการตอบกลับสำหรับค่าที่ถูกต้อง

Tests runner ของ Apidog จะบันทึกการตอบกลับแต่ละครั้ง คุณจึงสามารถจัดเรียงตามรหัสสถานะและดู 429 ทั้งหมดได้ในมุมมองเดียว คลิกที่แถว 429 แล้วอ่านบอดี้ของมัน ฟิลด์ message จะบอกคุณว่าคุณเกินขีดจำกัด RPM, TPM หรือขีดจำกัดรายวัน นั่นคือมิติที่คุณต้องใช้ในการปรับขนาดในโค้ดที่ใช้งานจริงของคุณ

สำหรับข้อมูลเบื้องต้นเกี่ยวกับสิ่งที่คุณควรทำเมื่อเกินขีดจำกัด คู่มือการเกินอัตราการจำกัด จะอธิบายทุกสถานการณ์ 429 ที่คุณมีแนวโน้มจะพบเจอ

ขั้นตอนที่ 3: แยกการเกิน RPM ออกจากการเกิน TPM

การส่งคำขอแบบฉับพลันครั้งแรกด้านบนวัด RPM เนื่องจากแต่ละคำขอมีขนาดเล็ก ในการตรวจสอบ TPM คุณต้องส่งคำขอน้อยลงแต่แต่ละคำขอมีขนาดใหญ่ขึ้น แก้ไขบอดี้คำขอของคุณเพื่อให้ messages มีเพย์โหลดที่ใหญ่ขึ้นมาก:

{
 "model": "gpt-5.5",
 "messages": [
 {"role": "system", "content": "<3,000 โทเค็นของบริบทที่นี่>"},
 {"role": "user", "content": "สรุปข้างต้นเป็นประโยคเดียว"}
 ],
 "max_tokens": 200
}

เรียกใช้สถานการณ์อีกครั้ง ครั้งนี้อาจมี 20 รอบพร้อมกันที่ 5 หากคุณอยู่ใน Tier 1 ที่มีขีดจำกัด TPM 30k คุณจะเกินขีดจำกัดโทเค็นนานก่อนที่จะเกินขีดจำกัดคำขอ

การแยกนี้สำคัญเพราะวิธีแก้ไขนั้นแตกต่างกัน หากปริมาณงานจริงของคุณส่งคำขอขนาดเล็กจำนวนมาก ให้แก้ไข RPM: ใช้คิว, แบทช์ หรือจัดลำดับ หากส่งคำขอขนาดใหญ่จำนวนน้อย ให้แก้ไข TPM: ตัดแต่ง system prompts, แคชบริบทด้วยกลไก prompt_cache หรือแบ่งคำขอ

ขั้นตอนที่ 4: จำลองผู้ใช้พร้อมกัน

การทดสอบแบบส่งคำขอฉับพลันจะวัดขีดจำกัดสูงสุดของคุณเอง การจราจรในระบบจริงดูแตกต่างออกไป: มีผู้ใช้จำนวนมาก, ขนาดคำขอที่แตกต่างกัน, และการส่งคำขอแบบฉับพลันที่เพิ่มเติมจากฐานข้อมูลที่คงที่

ใน Apidog ให้สร้างสถานการณ์ทดสอบที่วนซ้ำผ่านคำขอสามหรือสี่รูปแบบที่แตกต่างกัน (ขนาดเล็ก กลาง ใหญ่) โดยมีการหยุดพักแบบสุ่มระหว่างรอบ Runner รองรับสคริปต์ JavaScript ก่อนและหลังการเรียกใช้คำขอ คุณจึงสามารถ:

• เลือกความยาวข้อความแบบสุ่มในแต่ละรอบ
• อ่านค่า x-ratelimit-remaining-tokens หลังการตอบกลับแต่ละครั้ง และยกเลิกสถานการณ์เมื่อค่าลดลงต่ำกว่าเกณฑ์
• บันทึกความหน่วงแยกกันสำหรับ 200s เทียบกับ 429s เพื่อให้คุณเห็นว่าการจำกัดความเร็วส่งผลต่อ p95 อย่างไร

เมื่อสถานการณ์เสร็จสิ้น รายงานจะแสดงฮิสโตแกรมของรหัสสถานะ ฮิสโตแกรมนั้นเป็นสิ่งประดิษฐ์ที่มีประโยชน์ที่สุดที่คุณสามารถปักหมุดไว้ใน runbook ได้ ทันทีที่เพื่อนร่วมงานพูดว่า “เราถูกจำกัดอัตราการใช้งานหรือไม่?” คุณก็เรียกใช้งานซ้ำและเปรียบเทียบได้เลย

จะทำอย่างไรเมื่อคุณถูกจำกัดความเร็ว

เมื่อคุณวัดได้แล้วว่าขีดจำกัดอยู่ตรงไหน คุณมีสามทางเลือกที่แท้จริง

• ผ่อนการทำงาน (Back off) ห่อหุ้มการเรียกใช้ GPT ทุกครั้งด้วยการลองใหม่แบบ exponential-backoff อ่านเฮดเดอร์ x-ratelimit-reset-tokens จากการตอบกลับ 429 และใช้เป็นค่าหน่วงเวลาการลองใหม่ครั้งแรก เฮดเดอร์นั้นคือคำตอบโดยตรงของ OpenAI สำหรับ “รอเท่านี้” การใช้ time.sleep(2 ** attempt) แบบง่ายๆ ก็ใช้ได้เช่นกัน แต่จะเสียเวลาไปหลายวินาทีโดยไม่จำเป็น
• จัดคิว (Queue) หากการจราจรของคุณเป็นแบบไม่สม่ำเสมอ ให้ใส่คำขอลงในคิวและระบายออกในอัตราที่ต่ำกว่าขีดจำกัดของคุณเล็กน้อย ตัวจำกัดแบบ token-bucket ที่กำหนดไว้ต่ำกว่า TPM ของคุณเล็กน้อยคือรูปแบบมาตรฐาน เราจะลงรายละเอียดเกี่ยวกับการแลกเปลี่ยนในการนำไปใช้งานใน วิธีใช้งานการจำกัดอัตรา API และ การใช้งานการจำกัดอัตราใน APIs
• แบทช์ (Batch) Batch API ของ OpenAI ทำงานที่ขีดจำกัดที่สูงกว่าและมีราคาครึ่งหนึ่งของการเรียกใช้แบบ synchronous หากปริมาณงานของคุณสามารถทนต่อเวลาดำเนินการ 24 ชั่วโมงได้ (การเสริมข้อมูลข้ามคืน, การจัดหมวดหมู่เอกสาร, การสร้าง embeddings ใหม่) ให้ย้ายไปใช้ Batch และปลดโควต้า synchronous ของคุณสำหรับการจราจรที่ต้องเผชิญหน้ากับผู้ใช้โดยตรง

หากคุณต้องการอ่านรายละเอียดเพิ่มเติมเกี่ยวกับการแยกความแตกต่างระหว่างการจำกัดความเร็ว (throttling) และการจำกัดอัตรา (rate-limiting) ก่อนที่คุณจะเลือกใช้ throttle vs. rate limit เป็นเส้นทางที่สั้นที่สุดในการทำความเข้าใจคำศัพท์

ข้อผิดพลาด 429 ที่พบบ่อยของ GPT และความหมายของมัน

429 สามประเภทครอบคลุมประมาณ 90% ของกรณีที่เกิดขึ้นจริง

• `เกินขีดจำกัดอัตรา … ในจำนวนคำขอต่อนาที (RPM)` หมายความว่าโค้ดของคุณส่งการเรียกใช้มากเกินไปต่อนาทีโดยไม่คำนึงถึงขนาด เพิ่มการควบคุมการทำงานพร้อมกัน อย่าส่งทุกรายการใน map ที่ขนานกัน กำหนดขีดจำกัด worker pool ของคุณที่ RPM ของคุณหารด้วยปัจจัยความปลอดภัยที่สอง
• เกินขีดจำกัดอัตรา … ในโทเค็นต่อนาที (TPM) หมายความว่าการเรียกใช้ของคุณมีขนาดใหญ่เกินไป ตรวจสอบพรอมต์ การเกิน TPM ส่วนใหญ่มาจากการที่ system prompts ขยายขนาดเมื่อเวลาผ่านไป หรือจาก RAG pipelines ที่ใส่เอกสารทั้งหมดลงในบริบท ตัดแต่ง, แคช, หรือแบ่งออก
• คุณเกินโควตาปัจจุบัน โปรดตรวจสอบแผนและรายละเอียดการเรียกเก็บเงินของคุณ ดูเหมือนจะเป็น 429 แต่จริงๆ แล้วเป็นปัญหาการเรียกเก็บเงิน ไม่ใช่การจำกัดอัตรา บัญชีของคุณถึงขีดจำกัดการใช้จ่ายรายเดือน, บัตรที่บันทึกไว้ล้มเหลว, หรือยอดเงินเติมล่วงหน้าเป็นศูนย์ วิธีแก้ไขอยู่ในแดชบอร์ดการเรียกเก็บเงิน ไม่ใช่ในโค้ดของคุณ

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

• Apidog มีค่าใช้จ่ายในการทดสอบขีดจำกัดอัตรา GPT หรือไม่? ไม่มี แผนฟรีครอบคลุมการทดสอบคำขอเดี่ยวและการทดสอบแบบพร้อมกันขนาดเล็ก คุณจะต้องใช้แผนแบบชำระเงินก็ต่อเมื่อคุณต้องการโหลดทดสอบที่ใหญ่ขึ้น, พื้นที่ทำงานของทีม, หรือการเรียกใช้งานตามกำหนดเวลา ดู ราคา Apidog สำหรับรายละเอียด
• ฉันสามารถทดสอบขีดจำกัดอัตราโดยไม่ใช้โทเค็นจริงได้หรือไม่? ได้บางส่วน การตรวจสอบพื้นฐานที่ถูกที่สุดคือการส่งคำขอครั้งเดียวด้วย max_tokens: 1 และข้อความหนึ่งตัวอักษร ซึ่งมีค่าใช้จ่ายเพียงเสี้ยวเซ็นต์ และเฮดเดอร์จะกลับมาครบถ้วน สำหรับการทดสอบแบบส่งคำขอฉับพลัน คุณต้องใช้โทเค็นจริง แต่คุณสามารถทำให้แต่ละการเรียกใช้มีขนาดเล็กได้ หากคุณต้องการฝึกซ้อมแบบออฟไลน์ทั้งหมด ให้ใช้ mock server ของ Apidog เพื่อจำลองรูปแบบการตอบกลับ 429 และพิสูจน์ว่าตรรกะการลองใหม่ของคุณทำงานได้โดยไม่ต้องเรียกใช้ OpenAI เลย
• ทำไมคีย์ Tier 1 ของฉันถึงรู้สึกช้ากว่าของเพื่อนร่วมงานใน Tier 1? ขีดจำกัดระดับชั้นเป็นแบบต่อองค์กร ไม่ใช่ต่อคีย์ หากคีย์ของคุณอยู่ในองค์กรที่ใช้ร่วมกันกับผู้ใช้ที่ใช้งานหนักคนอื่น ๆ คุณกำลังแข่งขันกับการจราจรของพวกเขา Apidog สามารถแสดงสิ่งนี้ได้อย่างชัดเจน: เรียกใช้คำขอเดียวกันจากทั้งสองคีย์พร้อมกันและเปรียบเทียบการลดลงของ x-ratelimit-remaining-tokens
• ฉันจะรู้ได้อย่างไรว่าโมเดลใดมีขีดจำกัดใด? อ่านเฮดเดอร์การตอบกลับ อย่าเชื่อถือตารางทั่วไปในบล็อกโพสต์ (รวมถึงโพสต์นี้ด้วย) ส่งคำขอราคาถูกหนึ่งครั้งจาก Apidog ไปยังแต่ละโมเดลแล้วบันทึกเฮดเดอร์ โมเดลที่มีชื่อเดียวกันแต่เวอร์ชันสแนปช็อตต่างกัน (เช่น gpt-5.5 เทียบกับ gpt-5.5-0901) อาจมีขีดจำกัดที่แตกต่างกัน
• คำขอแบบสตรีมมิ่งนับแตกต่างกันหรือไม่? ใช่สำหรับ TPM คำขอแบบสตรีมมิ่งจะสงวนโทเค็นล่วงหน้าตาม max_tokens ดังนั้นค่า max_tokens ที่ยาวอาจทำให้งบประมาณ TPM ของคุณถูกใช้ไป แม้ว่าการตอบกลับจริงจะสั้นก็ตาม ลด max_tokens ให้เหลือขีดจำกัดสูงสุดที่เป็นจริงที่สุด เราครอบคลุมพฤติกรรมการสตรีมมิ่งใน วิธีทดสอบ ChatGPT API ด้วย Apidog
• ฉันสามารถแบ่งปันการทดสอบขีดจำกัดอัตรา Apidog ของฉันกับทีมได้หรือไม่? ได้ บันทึกคำขอและสถานการณ์ทดสอบในโปรเจกต์ที่ใช้ร่วมกัน ใครก็ตามในพื้นที่ทำงานของคุณสามารถเรียกใช้การทดสอบแบบส่งคำขอฉับพลันเดียวกันกับคีย์ของตนเองได้โดยการเปลี่ยนสภาพแวดล้อม นั่นทำให้คำถามที่ว่า “คีย์ของฉันถูกจำกัดความเร็วหรือของพวกเขา?” เป็นคำถามที่ใช้เวลาเพียง 10 วินาที

button