ขีดจำกัดอัตราการใช้งาน Muse Wonder: 3,000 RPM และ 4M TPM ที่ทั้งทีมใช้ร่วมกัน

ขีดจำกัดอัตราของ Muse Wonder บน Meta Model API คือ 3,000 คำขอต่อนาที และ 4,000,000 โทเค็นต่อนาที ใช้ทั้งสองแบบต่อรุ่นและต่อทีม ไม่ใช่ต่อคีย์ API: ทุกคีย์ที่องค์กรของคุณสร้างขึ้นมาจากกลุ่มเดียวกัน การตอบกลับเบื้องหลังจะได้รับสิทธิ์แยกต่างหากในการส่งใหม่ 600 รายการต่อนาที ไม่มีระดับการใช้งานที่เผยแพร่และไม่มีวิธีการเป็นเอกสารในการขอเพิ่มเติม เมื่อคุณเกินขีดจำกัด คุณจะได้รับ HTTP 429 และคำแนะนำของ Meta คือการถอยกลับแบบเอ็กซ์โพเนนเชียลโดยมีการกระจายสุ่มที่เริ่มต้นประมาณ 500 มิลลิวินาที โดยให้เกียรติ Retry-After เมื่อมีอยู่

ข้อเท็จจริงสี่ประการนี้กำหนดวิธีออกแบบสิ่งใดก็ตามที่เรียก muse-wonder-1.0 ในวงกว้าง โพสต์นี้ครอบคลุมความหมายของขีดจำกัดในทางปฏิบัติ บริบท 1M โทเค็นใช้งบประมาณ 4M TPM อย่างไร วิธีอ่านส่วนหัว วิธีสร้างและทดสอบเส้นทางการลองใหม่ และต้องทำอย่างไรเมื่อ 3,000 RPM ไม่เพียงพอ สำหรับพื้นฐาน API เริ่มต้นด้วยคู่มือ Muse Wonder API

ข้อจำกัด

ตัวเลข 3,000 / 4M เดียวกันใช้กับ Muse Spark 1.3; รุ่น Contributor ของ Spark ถูกจำกัดต่ำกว่าที่ 150 RPM และ 3M TPM แต่ละโมเดลมีกลุ่มของตัวเอง ดังนั้นการใช้งาน Wonder หนักๆ จึงไม่ทำให้ช่องทาง Spark อดอาหารและในทางกลับกัน บริบทการกำหนดทิศทางที่ Meta แทรกไม่ถูกนับรวมใน TPM และไม่ปรากฏใน usage

โทเค็นหมดก่อนที่คำขอจะหมด

ที่ 4M โทเค็นต่อนาที ขีดจำกัดคำขอแทบไม่ใช่ข้อผูกมัดสำหรับเอเจนต์ ตัวอย่างสามกรณี:

ทีมที่รันเอเจนต์ไม่กี่ตัวด้วยบริบทขนาดใหญ่สามารถถึง 4M TPM ด้วยคำขอพร้อมกันสิบสองรายการ อินพุตที่แคชไว้ยังนับรวมใน TPM; ส่วนลดแคชคือส่วนลดการเรียกเก็บเงิน ไม่ใช่ส่วนลดขีดจำกัดอัตรา โทเค็นการให้เหตุผลนับรวมใน max_output_tokens และบิลของคุณ และโทเค็นเอาต์พุตก็นับรวมใน TPM เช่นกัน

ผลลัพธ์เชิงปฏิบัติ: จัดงบ TPM ตามขนาดบริบท ไม่ใช่ตามจำนวนคำขอ เอเจนต์ที่ส่งบทสนทนา 300K โทเค็นซ้ำทุกรอบคือคำขอ 300K โทเค็นทุกครั้ง และเอเจนต์เช่นนี้สิบตัวที่ทำงานครั้งละหนึ่งครั้งต่อนาทีใช้สามในสี่ของโควตาทีม

วางแผนการทำงานพร้อมกันจากตัวเลข

คณิตศาสตร์ความจุคือหนึ่งบรรทัด: เอเจนต์พร้อมกัน คูณโทเค็นต่อรอบ คูณรอบต่อนาที ต้องต่ำกว่า 4,000,000 คำนวณสำหรับเลนที่หนักที่สุดของคุณก่อนปรับใช้

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

คานควบคุมสองอันช่วยลดด้านซ้ายของสมการ การบีบอัดทำให้โทเค็นต่อรอบไม่เติบโตไม่จำกัด: สรุปหรือทิ้งผลลัพธ์เครื่องมือเก่าเมื่อการรันเกินเกณฑ์ ตามที่โพสต์หน้าต่างบริบทอธิบาย และการเล่นซ้ำแบบเข้ารหัสไร้สถานะบน Responses API ให้คุณควบคุมสิ่งที่ส่งซ้ำได้ละเอียด ขณะที่ประวัติที่เซิร์ฟเวอร์จัดการด้วย previous_response_id ส่งทุกอย่างซ้ำ

หนึ่งพูลสำหรับทุกคีย์

Meta กำหนดขอบเขตขีดจำกัดต่อทีม คีย์สำหรับ staging คีย์สำหรับ production และคีย์บนแล็ปท็อปเพื่อนร่วมทีมดึงจาก 3,000 / 4M เดียวกัน สิ่งนี้มีสองผลลัพธ์

ประการแรก การทดสอบโหลดจากนักพัฒนาหนึ่งคนสามารถจำกัด production ได้ แยกการทดลองตามเวลา หรือในทีมแยกต่างหากหากองค์กรของคุณอนุญาต ประการที่สอง การมอนิเตอร์ต่อคีย์จะไม่แสดงภาพรวมทั้งหมด รวบรวมส่วนหัว x-ratelimit-* ทั้งหมดผู้เรียก มิฉะนั้นคุณจะเห็น 429 บนคีย์ที่ดูเหมือนต่ำกว่าขีดจำกัดมาก

อ่านส่วนหัว

การตอบกลับแบบใช้โทเคนมีส่วนหัว x-ratelimit-* บันทึกทุกการเรียก รูปแบบสำคัญคือความจุที่เหลือลดลงไปที่ศูนย์ทั้งหมดผู้เรียกภายในหนึ่งนาที ซึ่งเป็นสัญญาณให้ชะลอก่อน 429 มาถึง การตอบกลับการถอดเสียงไม่มีส่วนหัวเหล่านี้; ของ Wonder มี

เมื่อ 429 มาถึง เอกสารของ Meta จะมีความเฉพาะเจาะจง: ถอยกลับแบบทวีคูณโดยเริ่มมี jitter ประมาณ 500 ms และหากมี Retry-After ให้รออย่างน้อยนั้น การวนซ้ำที่ละเว้น Retry-After และค้อนในช่วงเวลาที่กำหนดจะทำให้การหยุดทำงานนานขึ้นสำหรับทุกคนในทีมของคุณ

สร้างเส้นทางการลองใหม่

import random, time
from openai import OpenAI, RateLimitError

client = OpenAI(base_url="https://api.meta.ai/v1", [REDACTED CREDENTIAL] call(input_text, attempts=6):
    delay = 0.5
    for i in range(attempts):
        try:
            return client.responses.create(model="muse-wonder-1.0", input=input_text,
                                           reasoning={"effort": "medium"}, max_output_tokens=4096)
        except RateLimitError as e:
            retry_after = e.response.headers.get("retry-after")
            wait = float(retry_after) if retry_after else delay + random.uniform(0, delay)
            time.sleep(wait)
            delay = min(delay * 2, 30)
    raise RuntimeError("rate limited after retries")

ประเด็นการออกแบบสามข้อ จำกัดการถอยกลับเพื่อไม่ให้การขัดข้องนานกลายเป็นการนอน 20 นาที ทำให้การลองใหม่เป็นแบบ idempotent: การเรียก Responses ที่ไม่สร้างอะไรฝั่งคุณปลอดภัยที่จะทำซ้ำ แต่ถ้าการเรียกเครื่องมือของเอเจนต์มีผลข้างเคียง ให้ลองซ้ำการเรียกโมเดล ไม่ใช่เครื่องมือ และแสดงการลองใหม่ใน traces เพื่อแยกโมเดลช้าจากโมเดลที่ถูกจำกัด; คู่มือการติดตามการเรียกเครื่องมือครอบคลุมสิ่งที่ควรบันทึก

ใช้การตอบกลับพื้นหลังสำหรับหางยาว

งานยาวไม่จำเป็นต้องถือการเชื่อมต่อ background: true จัดคิวการตอบกลับ คืน "status": "queued" และให้คุณ poll GET /v1/responses/{id}?stream=true เพื่อดูเหตุการณ์วงจรชีวิต การส่งพื้นหลังมีสิทธิ์เฉพาะ 600 ต่อนาทีเพิ่มจากขีดจำกัดหลัก ดังนั้นการย้ายงานแบบแบตช์ไปที่นั่นจะปลดปล่อย RPM ให้การใช้งานแบบโต้ตอบ ข้อจำกัด: ห้าม stream: true บน POST, ขีดจำกัดเนื้อหา 1 MiB และยกเลิกด้วย POST /v1/responses/{id}/cancel

เมื่อ 3,000 รอบต่อนาทียังไม่เพียงพอ

Meta ไม่เผยแพร่บันไดระดับและแบบฟอร์มขอขยายขีดจำกัด ตัวเลือกของคุณวันนี้:

• ลดโทเค็นต่อคำขอ การแคชพรอมป์ลดบิลแต่ไม่ลด TPM; การตัดบริบททำทั้งสองอย่าง โพสต์หน้าต่างบริบทครอบคลุมการตัดผลลัพธ์เครื่องมือ
• กระจายข้ามโมเดล Spark 1.3 มีพูล 3,000 / 4M ของตัวเองที่ราคาหนึ่งในสาม ส่งงานที่ไม่ต้องการคุณภาพของ Wonder ไปที่นั่น
• ใช้เกตเวย์ Vercel AI Gateway และ Cloudflare Workers AI ให้บริการ meta/muse-wonder-1.0 ว่าจะได้สิทธิ์แยกหรือไม่ขึ้นกับวิธีจัดเตรียมเกตเวย์; ตรวจสอบกับพวกเขาก่อนพึ่งพา
• จัดคิวและทำให้เรียบ ตัวจำกัดโทเค็นบักเก็ตหน้า API ที่รู้งบทั้งหมดของทีมจะทำได้ดีกว่าบริการหกตัวที่ต่างเดา

ทดสอบการจัดการขีดจำกัดใน Apidog

อย่าค้นพบบั๊กการลองใหม่ที่ 3,001 คำขอ ใน Apidog:

1. สร้างคำขอ Responses ด้วย MODEL_API_KEY เป็นตัวแปรลับ และเพิ่ม post-processor ที่อ่านส่วนหัว x-ratelimit-* ลงตัวแปรสภาพแวดล้อมเพื่อให้ซีนาริโอยืนยันความจุที่เหลือไม่ต่ำกว่าระดับขั้นต่ำ
2. สร้าง mock ของ /v1/responses ด้วย mock expectation ที่คืน 429 และส่วนหัว Retry-After: 2 เมื่อคำขอมีส่วนหัวเช่น X-Test-Scenario: throttle ชี้ไคลเอนต์ไปที่ mock และยืนยันว่ารออย่างน้อยสองวินาทีและสำเร็จในความพยายามถัดไป
3. รันการทดสอบประสิทธิภาพที่เพิ่มปริมาณคำขอต่อ mock เพื่อยืนยันว่าตัวจำกัดของคุณทำงานก่อน API
4. ใส่ซีนาริโอใน CI ด้วย Apidog CLI เพื่อไม่ให้การเปลี่ยนแปลงโค้ดการลองใหม่ส่งได้โดยไม่ผ่าน

ดาวน์โหลด Apidog เพื่อตั้งค่า mock และการยืนยันในโปรเจกต์เดียว

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

ขีดจำกัดอัตรา Muse Wonder เป็นแบบต่อคีย์หรือต่อบัญชี? ต่อทีม คีย์ทั้งหมดในทีมแชร์พูล 3,000 RPM / 4M TPM หนึ่งพูลต่อโมเดล

อินพุตที่แคชนับรวมใน TPM หรือไม่? ใช่ การแคชลดราคาโทเค็นเหล่านั้น ไม่ใช่น้ำหนักต่อขีดจำกัดโทเค็นรายนาที

ขอขีดจำกัดที่สูงกว่าได้ไหม? หน้าราคาและขีดจำกัดอัตราของ Meta ไม่ระบุระดับและกระบวนการ ตรวจสอบหน้าเพื่อดูการเปลี่ยนแปลง; การเปิดตัว frontier มักเพิ่มระดับภายในไม่กี่สัปดาห์

จะได้รหัสสถานะและส่วนหัวใด? HTTP 429, อาจมี Retry-After และส่วนหัว x-ratelimit-* บนการตอบกลับแบบใช้โทเคน

ขั้นตอนต่อไป

วัดโทเค็นต่อคำขอของรอบเอเจนต์ที่หนักที่สุด คูณด้วยความพร้อมกัน และเทียบกับ 4,000,000 ถ้าคำตอบใกล้เคียง ให้สร้างตัวจำกัดและการทดสอบ mock สัปดาห์นี้ ก่อนทีมแชร์พูลกับ production