ขีดจำกัดอัตรา API Groq และวิธีทำงานของขีดจำกัด 429

บริการที่ขีดจำกัดนี้เป็นของ

ชื่อนี้คล้ายกันจนสับสนได้ง่าย Groq คือบริษัทที่โฮสต์โมเดลบนฮาร์ดแวร์ของตัวเอง Grok คือตระกูลโมเดลจาก xAI เว็บไซต์นี้ไม่ใช่ทั้งสองอย่าง: เป็น API ที่เข้ากันได้กับ OpenAI สำหรับโมเดล open-weight เพียงตัวเดียว (model ID uncensored) โดยผู้ให้บริการที่เป็นอิสระ ดังนั้นสำหรับขีดจำกัดอัตราของ API ของ Groq เอง เช่น จำนวนคำขอหรือโทเคนต่อนาทีตามแผนการใช้งาน ให้เปิดคอนโซลหรือเอกสารของ Groq แล้วอ่านตัวเลขสำหรับบัญชีของคุณ ตัวเลขเหล่านี้เปลี่ยนแปลงได้ และฉันจะไม่คาดเดา

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

สรุปขีดจำกัด

สองอย่างนี้เป็นขีดจำกัดอัตราในแง่ที่แท้จริง คือ คำขอต่อนาทีและความพร้อมกัน สองอย่างที่เหลือเป็นขีดจำกัดขนาดต่อคำขอเดียว และแยกจากขีดจำกัดอัตรา คำขอที่มีพรอมต์ขนาด 90,000 โทเคน นับเป็นหนึ่งคำขอจากขีดจำกัด 300 คำขอต่อนาที เช่นเดียวกับพรอมต์หนึ่งบรรทัด แม้ว่าจะใช้เวลานานกว่าและยึดสล็อตนานกว่าก็ตาม

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

ประเภทของ 429 ทั้งสามแบบ

ข้อผิดพลาดทั้งหมดเกี่ยวกับขีดจำกัดจะส่งกลับมาเป็น HTTP 429 แต่มีความหมายต่างกันและต้องการการตอบสนองที่แตกต่างกัน

• rate_limited: คุณส่งคำขอเกินจำนวนที่อนุญาตต่อนาที ลดความเร็วลง; หน้าต่างเวลาคือหนึ่งนาที ดังนั้นการเว้นระยะคำขออย่างสม่ำเสมอจึงช่วยได้มากกว่าการหยุดพักเป็นเวลานาน
• concurrency: มีคำขอที่กำลังดำเนินการอยู่พร้อมกันมากเกินไป รอให้คำขอที่มาก่อนหน้าเสร็จสิ้นก่อน สิ่งนี้พบได้บ่อยในการสตรีมมิง ซึ่งแต่ละคำขอจะคงอยู่ตลอดกระบวนการสร้าง
• การโอเวอร์โหลดชั่วคราว: เป็น 429 เช่นกัน โดยมี header Retry-After: 5 ไม่ใช่ความผิดของคุณและไม่เกี่ยวข้องกับขีดจำกัดของคีย์ของคุณ รอตามเวลาที่ระบุไว้ 5 วินาทีแล้วลองใหม่

คำขอที่ล้มเหลวจะไม่ถูกคิดเงิน ดังนั้นลูปการลองใหม่จึงมีค่าใช้จ่ายเพียงคำขอเดียวที่สำเร็จในที่สุด การตอบกลับยังประกอบด้วย X-RateLimit-Limit-Requests และ X-RateLimit-Limit-Concurrency เพื่อให้ไคลเอนต์ของคุณอ่านขีดจำกัดของตัวเองได้แทนที่จะกำหนดค่าตายตัว รวมถึง X-Balance-USD สำหรับเครดิตคงเหลือ และ X-Request-Id ซึ่งคุณควรบันทึกและอ้างอิงหากติดต่อฝ่ายสนับสนุน

คณิตศาสตร์ของปริมาณงาน: ทำไม 300 ต่อนาทีจึงเข้าถึงได้ยาก

ขีดจำกัดทั้งสองมีปฏิสัมพันธ์กัน ด้วยสล็อตที่ทำงานพร้อมกัน 8 สล็อต จำนวนสูงสุดที่คุณสามารถดำเนินการเสร็จสิ้นต่อนาทีคือ 8 คูณด้วย 60 หารด้วยระยะเวลาเฉลี่ยของคำขอเป็นวินาที เพื่อที่จะเข้าถึง 300 คำขอต่อนาทีจริงๆ คุณต้องการคำขอที่เสร็จสิ้นใน 8 คูณ 60 หารด้วย 300 = 1.6 วินาทีโดยเฉลี่ย คำขอที่ช้ากว่าจะถูกจำกัดด้วยความพร้อมกันเป็นอันดับแรก

เหล่านี้คือขีดจำกัดทางคณิตศาสตร์สำหรับเวลาของคำขอในอุดมคติ ไม่ใช่การวัดบริการของเรา ให้วัดเวลาคำขอของคุณเอง ข้อสรุปคือ การสร้างเนื้อหาแบบยาว 20 วินาทีด้วยคีย์เต็มรูปแบบ จะถึงขีดจำกัดสูงสุดที่ 24 คำขอต่อนาที ซึ่งต่ำกว่า 300 ที่อนุญาตมาก หากคุณต้องการปริมาณงานมากขึ้น ให้ลดขนาดคำตอบด้วยmax_tokens หรือขอข้อความน้อยลงในแต่ละการเรียก แทนที่จะหวังให้ขีดจำกัดคำขอสูงขึ้น

ไคลเอนต์ที่จัดการทั้งสามกรณี

ไคลเอนต์ Python นี้จำกัดความพร้อมกันของตัวเองด้วย semaphore, อ่านค่า Retry-After เมื่อมีอยู่ และใช้ backoff พร้อม jitter เล็กน้อยเมื่อไม่มี ใช้แพ็คเกจ openai อย่างเป็นทางการ

Copyimport random
import threading
import time
from concurrent.futures import ThreadPoolExecutor

from openai import OpenAI, RateLimitError

client = OpenAI(
    base_url="https://api.groknsfw.top/v1",
    api_key="YOUR_KEY",
    max_retries=0,            # we handle retries ourselves
)

slots = threading.BoundedSemaphore(8)   # use 2 on the trial key

def ask(prompt, tries=6):
    for attempt in range(tries):
        with slots:
            try:
                r = client.chat.completions.create(
                    model="uncensored",
                    messages=[{"role": "user", "content": prompt}],
                    max_tokens=400,
                )
                return r.choices[0].message.content
            except RateLimitError as e:
                wait = e.response.headers.get("retry-after")
                body = e.response.text
        # sleep outside the slot so others can proceed
        delay = float(wait) if wait else min(2 ** attempt, 30)
        if "rate_limited" in body:
            delay = max(delay, 5)
        time.sleep(delay + random.random())
    raise RuntimeError("still rate limited after retries")

with ThreadPoolExecutor(max_workers=8) as pool:
    results = list(pool.map(ask, ["Write one line about the sea."] * 20))
print(len(results))

แนวคิดเดียวกันใน Node.js คือคิวขนาดเล็กที่อนุญาต promise ที่รอดำเนินการได้สูงสุด 8 รายการ และคำสั่ง curl ด้านล่างจะพิมพ์ header ของขีดจำกัดเพื่อให้คุณยืนยันขีดจำกัดของคีย์ของคุณได้:

Copycurl -s -D - -o /dev/null https://api.groknsfw.top/v1/models \
  -H "Authorization: Bearer YOUR_KEY" | grep -i "x-"

สตรีมมิง พรอมต์ยาว และหน้าต่างบริบท

คำขอแบบสตรีมมิงที่มี stream: true จะคงสล็อตการทำงานพร้อมกันไว้จนกว่าเหตุการณ์สุดท้ายจะมาถึง นั่นหมายความว่าผู้อ่านที่ช้าจะส่งผลต่อคุณ: หากโค้ดของคุณหยุดทำงานขณะจัดการแต่ละชิ้นส่วน ช่องนั้นจะยังคงถูกใช้งานอยู่ ให้บริโภคสตรีมมิงทันที

พรอมต์ที่ยาวส่งผลกระทบต่อขีดจำกัดในสองทาง ประการแรก ใช้เวลาประมวลผลนานกว่า จึงลดปริมาณงานของคุณตามสูตรข้างต้น ประการที่สอง ต้องพอดีกับหน้าต่าง 100,000 โทเคนร่วมกับคำตอบ ดังนั้นควรเก็บระยะปลอดภัยไว้ การตัดทอนประวัติแชทเก่าช่วยแก้ปัญหาทั้งสองอย่าง และยังลดค่าใช้จ่ายของคุณด้วย: ที่ $0.15 ต่อโทเคนอินพุต 1M ประวัติความยาว 20,000 โทเคนจะมีค่าใช้จ่าย $0.003 ทุกครั้งที่คุณส่งใหม่

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

แสดงขีดจำกัดให้ผู้ใช้ของคุณ

ขีดจำกัดอัตราเป็นอีกการตัดสินใจหนึ่งของผลิตภัณฑ์ หากแอปของคุณอยู่ระหว่างผู้ใช้ปลายทางและ API คำตอบ 429 แบบดิบไม่ควรไปถึงพวกเขา ตัดสินใจล่วงหน้าว่าพวกเขาจะเห็นอะไรแทน

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

บันทึกสามสิ่งสำหรับข้อผิดพลาดทุกครั้ง: X-Request-Id รหัสข้อผิดพลาด และจำนวนคำขอที่แอปของคุณกำลังดำเนินการอยู่ในขณะนั้น ด้วยสิ่งเหล่านี้ คุณสามารถแยกแยะไคลเอนต์ที่ทำผิดจากโหลดจริงได้ในไม่กี่นาที หากปัญหาดูเหมือนเกิดจากฝั่งเซิร์ฟเวอร์ รหัสคำขอคือสิ่งที่ ฝ่ายสนับสนุน จะถามเป็นอันดับแรก

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

ข้อผิดพลาดทั่วไป

รูปแบบไม่กี่รูปแบบทำให้เกิดปัญหา 429 ส่วนใหญ่ที่ผู้คนรายงาน

1. การลองซ้ำทันที ลูปที่ส่งใหม่ทุกครั้งเมื่อเกิดข้อผิดพลาด จะเปลี่ยนช่วงเวลาเดียวที่เกินขีดจำกัดให้เป็นพายุ ให้รอ เพิ่ม jitter และจำกัดจำนวนครั้งในการลองซ้ำ
2. การลองซ้ำทุกคำขอ มีเพียง 429 และข้อผิดพลาดเซิร์ฟเวอร์ชั่วคราวเท่านั้นที่ควรลองซ้ำ คำขอที่ผิดรูปแบบหรือคีย์ที่ผิดจะล้มเหลวในลักษณะเดียวกันทุกครั้ง
3. ลืมสตรีมในการนับ หน้าต่างแชทที่เปิด 10 หน้าต่างด้วยคีย์เต็มรูปแบบ อาจเป็นสตรีม 10 สตรีม ซึ่งมากกว่า 8 ช่อง
4. ไม่กำหนดเวลาหมดอายุ การเชื่อมต่อที่ค้างทำให้ช่องหนึ่งถูกใช้งานอยู่ กำหนดเวลาหมดอายุที่เหมาะสมให้กับแต่ละคำขอในไคลเอนต์ HTTP ของคุณ
5. การกำหนดขนาดสำหรับค่าเฉลี่ย การจราจรมาแบบเป็นระลอก วางแผนสำหรับนาทีที่หนาแน่นที่สุดของคุณ ไม่ใช่ค่าเฉลี่ยรายวัน

วางแผนความจุก่อนเปิดตัว

ทำงานย้อนกลับจากจุดสูงสุดของคุณ หากคุณคาดว่าจะมีผู้ใช้ 30 คนแชทพร้อมกัน และแต่ละคำตอบสตรีมเป็นเวลาประมาณ 15 วินาที คุณต้องการ 30 ช่องเมื่อพวกเขาทั้งหมดส่งพร้อมกัน และคีย์เต็มรูปแบบมีเพียง 8 ช่อง ให้จัดคิวที่เหลือในแอปของคุณ แสดงเวลาหน่วงสั้นๆ และประมวลผลเมื่อมีช่องว่าง ด้วย 8 ช่องและคำตอบ 15 วินาที คุณสามารถเสร็จสิ้น 8 x 60 / 15 = 32 คำตอบต่อนาที

สำหรับงานแบบแบตช์ ให้รันชุด worker pool ที่คงที่เท่ากับขีดจำกัดการทำงานพร้อมกันของคุณ และให้ลอจิกการลองซ้ำจัดการกับภาระเกินเป็นครั้งคราว แทนที่จะหาทางอ้อมเพื่อหลีกเลี่ยงขีดจำกัด ให้สร้างคิว: มันให้คุณพฤติกรรมที่คาดเดาได้และช่วยให้คุณแสดงเวลาหน่วงจริงให้กับผู้ใช้ของคุณ

คู่มือเพิ่มเติม

• API Grok ไม่เซ็นเซอร์: คู่มือการผสานรวม LLM NSFW