Dịch vụ nào sở hữu các giới hạn này
Các tên dễ bị nhầm lẫn. Groq là một công ty lưu trữ các mô hình trên phần cứng riêng của họ. Grok là họ mô hình từ xAI. Trang web này không phải vậy: đây là một API tương thích OpenAI cho một mô hình trọng số mở (ID mô hình uncensored), do một nhà cung cấp độc lập vận hành. Vì vậy, đối với giới hạn tốc độ API của Groq, chẳng hạn như số yêu cầu hoặc token mỗi phút trên một gói cụ thể, hãy mở bảng điều khiển hoặc tài liệu của Groq và đọc các số cho tài khoản của bạn. Chúng thay đổi, và tôi sẽ không đoán.
Những nội dung sau đây chính xác cho API của chúng tôi, và các thói quen này có thể áp dụng cho bất kỳ nhà cung cấp nào: hãy tôn trọng các tiêu đề giới hạn, chỉ thử lại khi gặp lỗi phù hợp, và giới hạn độ đồng thời của riêng bạn trước khi máy chủ làm điều đó thay bạn. Nếu bạn đến đây để thiết lập Grok NSFW, hướng dẫn tích hợp của chúng tôi cũng đề cập đến các lỗi liên quan.
Các giới hạn nhìn chung
| Giới hạn | Khóa đầy đủ | Khóa dùng thử |
|---|---|---|
| Yêu cầu đồng thời | 8 | 2 |
| Yêu cầu mỗi phút | 300 | 60 |
| Thân yêu cầu | 8 MB | 8 MB |
| Cửa sổ ngữ cảnh (prompt cộng với phản hồi) | 100.000 token | 100.000 token |
Hai trong số này là giới hạn tốc độ theo nghĩa chặt chẽ, số yêu cầu mỗi phút và độ đồng thời. Hai giới hạn còn lại là giới hạn kích thước trên một yêu cầu đơn lẻ, và chúng độc lập với các giới hạn tốc độ. Một yêu cầu với prompt 90.000 token được tính là một yêu cầu tính vào giới hạn 300 mỗi phút, tương tự như một dòng prompt ngắn, mặc dù nó sẽ mất nhiều thời gian hơn và giữ slot của nó lâu hơn.
Tín dụng dùng thử trị giá $0.50 được nhận chỉ với một cú nhấp chuột trên trang khóa API sau khi đăng ký, và nó sử dụng các giới hạn dùng thử. Các giới hạn khóa đầy đủ sẽ áp dụng sau khi bạn đã nạp tiền.
Ba loại lỗi 429
Tất cả các lỗi giới hạn đều xuất hiện dưới dạng HTTP 429, nhưng chúng mang ý nghĩa khác nhau và yêu cầu các phản ứng khác nhau.
rate_limited: bạn đã gửi nhiều hơn mức cho phép về số yêu cầu mỗi phút. Hãy giảm tốc độ; cửa sổ thời gian là một phút, nên phân bổ đều các yêu cầu sẽ hiệu quả hơn là tạm dừng lâu.concurrency: quá nhiều yêu cầu đang được xử lý cùng lúc. Hãy đợi một yêu cầu trước đó hoàn tất. Điều này thường xảy ra với streaming, vì mỗi yêu cầu tồn tại trong suốt quá trình tạo nội dung.- Quá tải tạm thời: cũng là lỗi 429, kèm tiêu đề
Retry-After: 5. Đây không phải lỗi của bạn và không liên quan đến giới hạn khóa của bạn. Hãy đợi 5 giây theo tiêu đề và thử lại.
Các yêu cầu thất bại không bị tính phí, nên một vòng lặp thử lại chỉ tốn chi phí cho một yêu cầu cuối cùng thành công. Các phản hồi cũng mang theo X-RateLimit-Limit-Requests và X-RateLimit-Limit-Concurrency để client của bạn có thể đọc các giới hạn của chính mình thay vì mã hóa cứng chúng, cùng với X-Balance-USD để biết tín dụng còn lại và X-Request-Id, mà bạn nên ghi lại và cung cấp khi liên hệ hỗ trợ.
Tính toán thông lượng: tại sao khó đạt 300 mỗi phút
Hai giới hạn này tương tác với nhau. Với 8 slot đồng thời, số lượng bạn có thể hoàn thành mỗi phút tối đa là 8 x 60 chia cho thời gian trung bình của một yêu cầu tính bằng giây. Để thực sự đạt 300 yêu cầu mỗi phút, bạn cần các yêu cầu hoàn tất trong 8 x 60 / 300 = 1,6 giây trung bình. Các yêu cầu chậm hơn bị giới hạn bởi độ đồng thời trước.
| Thời gian yêu cầu trung bình | Tối đa mỗi phút, khóa đầy đủ (8 slot) | Tối đa mỗi phút, khóa dùng thử (2 slot) |
|---|---|---|
| 2 giây | 240 | 60 |
| 10 giây | 48 | 12 |
| 20 giây | 24 | 6 |
Đây là các giới hạn tính toán cho thời gian yêu cầu giả định, không phải là đo lường dịch vụ của chúng tôi; bạn hãy tự đo thời gian yêu cầu của mình. Bài học rút ra là một quá trình tạo nội dung sáng tạo dài 20 giây trên khóa đầy đủ chỉ đạt tối đa 24 yêu cầu mỗi phút, thấp hơn nhiều so với giới hạn 300 cho phép. Nếu bạn cần thông lượng cao hơn, hãy giảm phản hồi bằng max_tokens hoặc yêu cầu ít văn bản hơn mỗi lần gọi thay vì hy vọng vào giới hạn yêu cầu cao hơn.
Một client xử lý cả ba trường hợp
Client Python này giới hạn độ đồng thời của riêng nó bằng một semaphore, đọc Retry-After khi có, và dùng backoff với jitter nhỏ nếu không có. Nó sử dụng gói openai chính thức.
import 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))Ý tưởng tương tự trong Node là một hàng đợi nhỏ cho phép tối đa 8 promise đang chờ, và lệnh kiểm tra curl bên dưới in ra các tiêu đề giới hạn để bạn xác nhận các giới hạn của khóa mình:
curl -s -D - -o /dev/null https://api.groknsfw.top/v1/models \
-H "Authorization: Bearer YOUR_KEY" | grep -i "x-"Streaming, prompt dài và ngữ cảnh
Một yêu cầu streaming với stream: true giữ slot độ đồng thời cho đến khi sự kiện cuối cùng đến. Điều đó có nghĩa là một trình đọc chậm sẽ ảnh hưởng đến bạn: nếu mã của bạn tạm dừng khi xử lý từng chunk, slot sẽ vẫn bận. Bạn hãy tiêu thụ stream ngay lập tức.
Các prompt dài tương tác với các giới hạn theo hai cách. Thứ nhất, chúng tốn nhiều thời gian xử lý hơn, nên chúng làm giảm thông lượng của bạn theo công thức trên. Thứ hai, chúng phải vừa với cửa sổ 100.000 token cùng với phản hồi, vì vậy hãy giữ một biên độ an toàn. Việc cắt bớt các lượt trò chuyện cũ giúp giải quyết cả hai vấn đề, và việc cắt bớt đó cũng giảm hóa đơn của bạn: ở mức $0.15 cho mỗi 1M token đầu vào, lịch sử 20.000 token tốn $0.003 mỗi lần bạn gửi lại.
Chi tiết về định dạng yêu cầu có trong hướng dẫn bắt đầu nhanh, và giá cả có trên trang giá.
Hiển thị giới hạn cho người dùng của chính bạn
Giới hạn tốc độ cũng là một quyết định sản phẩm. Nếu ứng dụng của bạn nằm giữa người dùng cuối và API, lỗi 429 thô không bao giờ nên hiển thị với họ. Bạn hãy quyết định trước xem họ sẽ thấy gì.
- Đối với ứng dụng chat, hãy hiển thị trạng thái "đang viết" ngắn gọn và xếp hàng tin nhắn. Thời gian chờ vài giây là không thể nhận thấy đối với hầu hết người dùng nếu có gì đó đang xảy ra trên màn hình.
- Đối với công cụ batch, hãy hiển thị tiến trình dưới dạng số lượng mục đã hoàn thành và để công việc chạy trong nền. Các lần thử lại là nội bộ và không nên xuất hiện dưới dạng lỗi.
- Đối với các triển khai chia sẻ, hãy cấp cho mỗi người dùng một hạn mức nhỏ cho mỗi người dùng trong mã của riêng bạn để một người dùng dùng quá nhiều không thể chiếm hết 8 slot của những người khác.
Hãy ghi lại ba thứ cho mọi lỗi: X-Request-Id, mã lỗi và số lượng yêu cầu mà ứng dụng của bạn đang xử lý cùng lúc vào thời điểm đó. Với những thông tin đó, bạn có thể phân biệt client gây sự cố với tải thực tế chỉ trong vài phút. Nếu một sự cố có vẻ nằm ở phía máy chủ, ID yêu cầu là thứ mà hỗ trợ sẽ hỏi đầu tiên.
Cuối cùng, hãy kiểm tra đường dẫn lỗi một cách có chủ đích. Chạy client của bạn với bộ semaphore thấp cố định và sau đó với bộ cao, và xem nhật ký hiển thị gì. Một vòng lặp thử lại chưa bao giờ kích hoạt là một vòng lặp thử lại mà bạn không thể tin tưởng. Khóa dùng thử là nơi thuận tiện cho việc này, vì với chỉ 2 yêu cầu đồng thời, bạn dễ dàng gặp lỗi concurrency với một script ngắn và xem mã của bạn phản ứng như thế nào, với chi phí vài phần mười cent cho mỗi yêu cầu.
Những sai lầm thường gặp
Một vài mẫu gây ra phần lớn các vấn đề 429 mà mọi người báo cáo.
- Thử lại ngay lập tức. Một vòng lặp gửi lại sau mỗi lần thất bại biến một khoảnh khắc vượt quá giới hạn thành một cơn bão. Hãy đợi, thêm jitter và giới hạn số lần thử.
- Thử lại mọi thứ. Chỉ lỗi 429 và lỗi máy chủ tạm thời mới đáng để thử lại. Một yêu cầu bị lỗi cú pháp hoặc khóa sai sẽ thất bại theo cách giống hệt nhau mỗi lần.
- Quên streaming trong số lượng. Mười cửa sổ chat mở trên khóa đầy đủ có thể là mười stream, và đó là nhiều hơn 8 slot đến hai.
- Không đặt thời gian chờ. Một kết nối bị treo giữ slot bận. Hãy đặt thời gian chờ hợp lý cho mỗi yêu cầu trong client HTTP của bạn.
- Thiết kế dựa trên giá trị trung bình. Lưu lượng đến theo đợt. Hãy lập kế hoạch cho phút bận nhất của bạn, không phải giá trị trung bình hàng ngày.
Lập kế hoạch năng lực trước khi ra mắt
Làm ngược lại từ đỉnh của bạn. Nếu bạn dự kiến 30 người dùng chat cùng lúc và mỗi phản hồi stream trong khoảng 15 giây, bạn cần 30 slot tại thời điểm tất cả gửi, và khóa đầy đủ chỉ có 8. Hãy xếp hàng số còn lại trong ứng dụng của bạn, hiển thị thời gian chờ ngắn và xử lý chúng khi slot trống. Với 8 slot và phản hồi 15 giây, bạn có thể hoàn thành 8 x 60 / 15 = 32 phản hồi mỗi phút.
Đối với các công việc batch, hãy chạy một nhóm worker cố định bằng với giới hạn độ đồng thời của bạn và để logic thử lại xử lý các quá tải thỉnh thoảng. Thay vì né tránh các giới hạn, hãy xây dựng hàng đợi: nó mang lại hành vi dự đoán được và cho phép bạn hiển thị thời gian chờ thực tế cho người dùng.
