Bạn triển khai một hàm gọi API GPT. Nó hoạt động tốt trong môi trường staging. Khi hàng trăm người dùng đầu tiên truy cập vào môi trường production, log của bạn tràn ngập lỗi 429 Too Many Requests. Bây giờ bạn đang đoán: đó là số lượng yêu cầu mỗi phút (requests per minute), số lượng token mỗi phút (tokens per minute), hay giới hạn hàng ngày (daily caps)? Bạn vẫn đang ở cấp độ 1 (tier 1) ư? Mô hình bạn chuyển sang tuần trước có giới hạn chặt chẽ hơn mô hình cũ không?
Nếu bạn đã từng làm việc với OpenAI trước đây, bạn biết rằng câu chuyện giới hạn tốc độ ngày càng phức tạp hơn với mỗi mô hình mới. GPT-5.5 có giới hạn khác với GPT-4.1, mô hình hình ảnh tính khác với mô hình văn bản, và cấp độ sử dụng của bạn tự động thay đổi khi chi tiêu của bạn tăng lên. Apidog cung cấp cho bạn một không gian làm việc duy nhất để kiểm tra header phản hồi của mỗi yêu cầu, mô phỏng lưu lượng đồng thời và xác nhận chính xác giới hạn nào bạn đang chạm phải trước khi bạn triển khai mã của mình. Tải Apidog nếu bạn chưa có; quy trình dưới đây hoạt động trên gói miễn phí.
button
Bốn giới hạn thực sự quan trọng
OpenAI áp dụng một số giới hạn tốc độ cho mọi khóa API GPT. Bạn sẽ thấy tất cả bốn giới hạn này được thực thi cho bất kỳ ứng dụng sản xuất nào:
- RPM (requests per minute – yêu cầu mỗi phút): số lượng lệnh gọi API bạn có thể gửi mỗi phút. Giới hạn thấp nhất ở hầu hết các cấp.
- TPM (tokens per minute – token mỗi phút): tổng số token đầu vào và đầu ra bạn có thể xử lý mỗi phút. Giới hạn mà hầu hết mọi người hay quên.
- RPD (requests per day – yêu cầu mỗi ngày): giới hạn hàng ngày cho các khóa miễn phí và cấp 1. Biến mất ở các cấp cao hơn đối với hầu hết các mô hình văn bản.
- IPM / TPD / giới hạn hàng đợi theo lô: giới hạn cụ thể cho từng mô hình đối với việc tạo hình ảnh, âm thanh, nhúng (embeddings) và các điểm cuối theo lô (batch endpoints). Mỗi nhóm điểm cuối có giới hạn riêng.
Khi yêu cầu của bạn bị từ chối, API trả về HTTP 429 và một JSON body như sau:
{
"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"
}
}
Lưu ý rằng phần body cho bạn biết bạn đã vượt qua giới hạn nào: tokens, requests, hoặc đôi khi là tokens_usage_based. Đó là điều đầu tiên bạn đọc khi có gì đó bị lỗi. Lỗi từ việc vượt quá TPM trông khác với lỗi từ việc vượt quá RPM, và cách khắc phục cũng khác. Một lỗi 429 không phải lúc nào cũng giống một lỗi 429 khác.
Để tham khảo toàn diện về ý nghĩa của 429 ở cấp độ HTTP, hãy xem tài liệu MDN 429 và đặc tả RFC 6585. Đối với hành vi cụ thể của OpenAI xung quanh các header thử lại và việc chuyển cấp, OpenAI duy trì trang giới hạn tốc độ chính thức mà bạn nên đánh dấu.
Cách thức hoạt động của các cấp độ và lý do bạn liên tục được nâng cấp (hoặc bị kẹt)
Khóa API GPT của bạn nằm trong một cấp độ sử dụng của OpenAI. Các cấp độ này xác định các con số thực tế đằng sau giới hạn RPM và TPM của bạn. Bạn được nâng cấp dựa trên hai yếu tố: tổng chi tiêu trên tài khoản của bạn, và thời gian kể từ khi bạn thanh toán lần đầu. Có sáu cấp độ, từ miễn phí đến cấp 5, và hình dạng tổng quát như sau đối với các mô hình văn bản:
| Cấp độ | Ngưỡng chi tiêu | Ngưỡng chờ | RPM Văn bản | TPM Văn bản |
|---|---|---|---|---|
| Miễn phí | không có | không có | 3 | 40k |
| 1 | đã thanh toán $5 | không có | 500 | 30k–200k tùy mô hình |
| 2 | đã thanh toán $50 | 7 ngày | 5.000 | 450k |
| 3 | đã thanh toán $100 | 7 ngày | 5.000 | 1M |
| 4 | đã thanh toán $250 | 14 ngày | 10.000 | 2M |
| 5 | đã thanh toán $1.000 | 30 ngày | 10.000 | 2M+ |
Các con số trên chỉ mang tính minh họa; giới hạn chính xác thay đổi theo thời gian và khác nhau tùy theo mô hình. Đọc giới hạn trực tiếp của bạn từ bảng điều khiển hoặc, tốt hơn, từ các header phản hồi API của chính bạn (sẽ được đề cập bên dưới) trước khi bạn tính toán khối lượng công việc.
Hai ý nghĩa thực tiễn:
- Bạn tự động được nâng cấp khi bạn thanh toán. Các cấp độ không phải là tùy chọn. Ngay khi chi tiêu của bạn vượt qua ngưỡng cấp độ và thời gian chờ đã qua, yêu cầu tiếp theo bạn thực hiện sẽ chạy theo giới hạn mới. Không có thông báo, không có bước di chuyển nào.
- Bạn có thể bị hạ cấp. Nếu tài khoản của bạn không hoạt động trong một thời gian dài hoặc phương thức thanh toán của bạn thất bại, bạn có thể bị hạ cấp. Hãy kiểm tra trong môi trường sản xuất sau bất kỳ thay đổi nào về thanh toán.
Để so sánh song song với hệ thống cấp độ của các nhà cung cấp mô hình khác, hãy xem bài giải thích về giới hạn tốc độ người dùng API OpenAI, hướng dẫn giới hạn tốc độ API Claude, và hướng dẫn giới hạn tốc độ API Grok-3. Mô hình tư duy là như nhau giữa các nhà cung cấp; các con số và kích thước cụ thể thì không.
Đọc giới hạn trực tiếp của bạn từ các header phản hồi
Bạn không cần phải lục lọi các bảng điều khiển để tìm giới hạn hiện tại của mình. Mỗi phản hồi API GPT đều chứa chúng trong các header. Hãy tìm bốn header sau:
x-ratelimit-limit-requests: giới hạn RPM của bạn cho điểm cuối này.x-ratelimit-remaining-requests: số lượng yêu cầu bạn còn lại trong phút này.x-ratelimit-limit-tokens: giới hạn TPM của bạn.x-ratelimit-remaining-tokens: số lượng token bạn còn lại trong phút này.
Thường thì cũng có x-ratelimit-reset-requests và x-ratelimit-reset-tokens, cả hai đều cung cấp cho bạn thời lượng dễ đọc cho đến khi giới hạn được đặt lại (ví dụ: 6s, 1m30s).
Cách đơn giản nhất để đọc các thông tin này là gửi một yêu cầu chat-completion duy nhất, theo dõi các header phản hồi, và xác nhận rằng bạn đang ở cấp độ mà bạn nghĩ. Apidog thực hiện điều đó chỉ với một cú nhấp chuột.
Bước 1: cấu hình yêu cầu GPT trong Apidog
Mở Apidog, tạo một dự án mới và thêm một yêu cầu mới vào đó.
Phương thức: POST URL: https://api.openai.com/v1/chat/completions
Trong tab Headers:
| Khóa | Giá trị |
|---|---|
Authorization |
Bearer {{OPENAI_API_KEY}} |
Content-Type |
application/json |
Cú pháp dấu ngoặc kép lấy giá trị từ một biến môi trường của Apidog, có nghĩa là khóa của bạn không bao giờ nằm trong chính yêu cầu. Đặt biến một lần trong Environments, chuyển đổi môi trường để thay đổi giữa khóa cá nhân và khóa nhóm, và phần còn lại của bộ sưu tập sẽ tự động lấy giá trị. Cách tương tự cũng áp dụng cho các ID tổ chức và dự án mà OpenAI cho phép bạn đưa vào để phân bổ thanh toán.
Trong tab Body, chọn JSON và dán:
{
"model": "gpt-5.5",
"messages": [
{"role": "user", "content": "ping"}
],
"max_tokens": 10
}
Nhấn Send. Bạn sẽ nhận được một phản hồi hoàn thành bình thường. Bây giờ nhấp vào tab Headers trong bảng phản hồi và cuộn đến các dòng x-ratelimit-*. Bốn con số đó là sự thật hiện tại của bạn. Chụp ảnh màn hình chúng. Chúng là cơ sở bạn sẽ kiểm tra.
Nếu bạn muốn tìm hiểu chi tiết hơn về cách thiết lập yêu cầu chat-completion, hướng dẫn cách kiểm tra API ChatGPT với Apidog của chúng tôi bao gồm xác thực, streaming và gọi công cụ từ đầu đến cuối.
Bước 2: xác nhận giới hạn bằng một đợt tấn công có chủ ý
Đọc các header cho bạn biết giới hạn. Gửi một yêu cầu không chứng minh được gì về hành vi tại giới hạn đó. Để xác minh rằng việc điều tiết thực sự diễn ra ở mức mà các header chỉ ra, bạn cần một bài kiểm tra tăng đột biến nhỏ.
Apidog đi kèm với một trình chạy kiểm thử có thể gửi cùng một yêu cầu N lần đồng thời. Mở yêu cầu đã lưu của bạn, nhấp vào mũi tên thả xuống bên cạnh Send, và chọn Run in Test Scenario. Đặt:
- Lặp lại (Iterations): 50 (hoặc bất kỳ số nào cao hơn RPM đã nêu của bạn)
- Đồng thời (Concurrency): 10
- Độ trễ giữa các lần lặp (Delay between iterations): 0 ms
Chạy nó. Hai kết quả hữu ích là:
- Một số yêu cầu trả về 429 trước khi đợt kiểm thử kết thúc. Tốt. Điều đó xác nhận rằng giới hạn từ header phản hồi và trạng thái tài khoản của bạn đang đồng bộ.
- Tất cả 50 yêu cầu đều thành công và các header hiển thị
remaining-requestsgiảm dần như mong đợi. RPM của bạn cao hơn bạn nghĩ; kiểm tra bảng phản hồi để biết giá trị chính xác.
Trình chạy kiểm thử của Apidog ghi lại mỗi phản hồi, vì vậy bạn có thể sắp xếp theo mã trạng thái và đưa tất cả các lỗi 429 vào một chế độ xem. Nhấp vào một hàng 429 và đọc phần body của nó. Trường message cho bạn biết liệu bạn đã vượt quá giới hạn RPM, TPM hay giới hạn hàng ngày. Đó là yếu tố bạn cần xem xét trong mã sản xuất của mình.
Để biết thêm về những việc cần làm khi bạn đã chạm giới hạn, hướng dẫn vượt quá giới hạn tốc độ sẽ đi sâu vào mọi bề mặt 429 mà bạn có thể gặp phải.
Bước 3: phân biệt các lỗi RPM và TPM
Đợt kiểm tra đầu tiên ở trên đo lường RPM, vì mỗi yêu cầu đều rất nhỏ. Để thăm dò TPM, bạn cần gửi ít yêu cầu hơn nhưng mỗi yêu cầu lớn hơn. Chỉnh sửa body yêu cầu của bạn để messages mang một payload lớn hơn nhiều:
{
"model": "gpt-5.5",
"messages": [
{"role": "system", "content": "<3,000 tokens of context here>"},
{"role": "user", "content": "Summarise the above in one sentence."}
],
"max_tokens": 200
}
Chạy một kịch bản khác, lần này có thể với 20 lần lặp với đồng thời 5. Nếu bạn ở cấp 1 với giới hạn 30k TPM, bạn sẽ vượt quá giới hạn token rất lâu trước khi vượt quá giới hạn yêu cầu.
Sự phân biệt này rất quan trọng vì cách khắc phục là khác nhau. Nếu khối lượng công việc thực tế của bạn gửi nhiều yêu cầu nhỏ, hãy khắc phục RPM: xếp hàng, xử lý theo lô hoặc phân tán. Nếu nó gửi ít yêu cầu lớn hơn, hãy khắc phục TPM: cắt bớt lời nhắc hệ thống (system prompts), lưu trữ ngữ cảnh bằng cơ chế prompt_cache hoặc chia nhỏ yêu cầu.
Bước 4: mô phỏng người dùng đồng thời
Các bài kiểm tra đột biến đo lường giới hạn của riêng bạn. Lưu lượng sản xuất trông khác: nhiều người dùng, kích thước yêu cầu thay đổi, các đợt tăng đột biến trên một nền ổn định.
Trong Apidog, tạo một kịch bản kiểm thử lặp qua ba hoặc bốn biến thể của yêu cầu (nhỏ, vừa, lớn) với thời gian chờ ngẫu nhiên giữa các lần lặp. Trình chạy hỗ trợ các script JavaScript trước và sau yêu cầu, vì vậy bạn có thể:
- Chọn một độ dài tin nhắn ngẫu nhiên cho mỗi lần lặp.
- Đọc
x-ratelimit-remaining-tokenssau mỗi phản hồi và hủy bỏ kịch bản khi nó giảm xuống dưới một ngưỡng. - Ghi lại độ trễ riêng cho các phản hồi 200 so với 429 để bạn có thể thấy việc điều tiết ảnh hưởng đến p95 như thế nào.
Khi kịch bản kết thúc, báo cáo cung cấp cho bạn một biểu đồ tần suất các mã trạng thái. Biểu đồ tần suất đó là hiện vật hữu ích nhất mà bạn có thể ghim vào sổ tay hướng dẫn. Ngay khi một đồng nghiệp hỏi "chúng ta có đang bị giới hạn tốc độ không?", bạn chạy lại và so sánh.
Làm gì khi bạn bị điều tiết
Khi bạn đã đo được giới hạn là ở đâu, bạn có ba lựa chọn thật lòng.
Giảm tải (Back off). Đóng gói mọi lệnh gọi GPT trong một cơ chế thử lại theo cấp số nhân (exponential-backoff retry). Đọc header x-ratelimit-reset-tokens từ phản hồi 429 và sử dụng nó làm độ trễ thử lại đầu tiên của bạn; header đó là câu trả lời trực tiếp của OpenAI cho câu hỏi "hãy đợi chừng này thời gian." Một lệnh time.sleep(2 ** attempt) đơn giản cũng hoạt động, nhưng nó làm lãng phí những giây bạn không cần phải chờ đợi.
Xếp hàng (Queue). Nếu lưu lượng truy cập của bạn có tính đột biến, hãy đặt các yêu cầu vào một hàng đợi và xử lý chúng với tốc độ thấp hơn giới hạn của bạn. Một bộ giới hạn token bucket được ghim hơi thấp hơn TPM của bạn là mẫu hình tiêu chuẩn. Chúng tôi đi sâu vào các cân nhắc triển khai trong cách triển khai giới hạn tốc độ API và triển khai giới hạn tốc độ trong API.
Xử lý theo lô (Batch). API Batch của OpenAI chạy ở giới hạn cao hơn và với giá bằng một nửa so với các lệnh gọi đồng bộ. Nếu khối lượng công việc của bạn có thể chấp nhận thời gian xử lý 24 giờ (làm giàu dữ liệu qua đêm, phân loại tài liệu, xây dựng lại nhúng), hãy chuyển nó sang Batch và giải phóng hạn mức đồng bộ của bạn cho lưu lượng truy cập người dùng.
Nếu bạn muốn tìm hiểu sâu hơn về sự khác biệt giữa điều tiết (throttling) và giới hạn tốc độ (rate-limiting) trước khi chọn một, throttle vs. rate limit là con đường ngắn nhất để hiểu các thuật ngữ.
Các lỗi GPT 429 phổ biến và ý nghĩa của chúng
Ba loại lỗi 429 bao gồm khoảng 90% các trường hợp thực tế.
Rate limit reached … on requests per min (RPM) có nghĩa là mã của bạn đang gửi quá nhiều lệnh gọi mỗi phút bất kể kích thước. Thêm kiểm soát đồng thời. Đừng xử lý mọi bản ghi trong một map song song; giới hạn nhóm worker của bạn ở RPM chia cho một hệ số an toàn là hai.
Rate limit reached … on tokens per min (TPM) có nghĩa là các lệnh gọi của bạn quá lớn. Kiểm tra lời nhắc (prompt). Hầu hết các lỗi TPM đến từ các lời nhắc hệ thống đã phát triển theo thời gian hoặc từ các pipeline RAG nhồi nhét toàn bộ tài liệu vào ngữ cảnh. Cắt bớt, lưu trữ hoặc chia nhỏ.
You exceeded your current quota, please check your plan and billing details trông giống như một lỗi 429 nhưng thực ra đó là giới hạn thanh toán, không phải giới hạn tốc độ. Tài khoản của bạn đã đạt giới hạn chi tiêu hàng tháng cố định, thẻ đã đăng ký bị lỗi hoặc số dư trả trước đã hết. Cách khắc phục nằm trong bảng điều khiển thanh toán, không phải trong mã của bạn.
Câu hỏi thường gặp
Apidog có tốn phí để kiểm tra giới hạn tốc độ GPT không? Không. Gói miễn phí bao gồm kiểm tra một yêu cầu và các lần chạy kiểm tra đồng thời nhỏ. Bạn chỉ cần gói trả phí nếu muốn tải kiểm thử lớn hơn, không gian làm việc nhóm hoặc các lần chạy theo lịch trình. Xem giá Apidog để biết chi tiết.
Tôi có thể kiểm tra giới hạn tốc độ mà không tốn token thật không? Một phần. Cách kiểm tra cơ bản rẻ nhất là một yêu cầu một lần với max_tokens: 1 và một tin nhắn một ký tự; nó chỉ tốn một phần nhỏ của xu và các header vẫn trả về đầy đủ. Đối với các bài kiểm tra đột biến, bạn vẫn tốn token thật, nhưng bạn có thể giữ cho mỗi lệnh gọi nhỏ. Nếu bạn muốn thực hành hoàn toàn ngoại tuyến, hãy sử dụng máy chủ giả lập của Apidog để mô phỏng hình dạng phản hồi 429 và chứng minh logic thử lại của bạn hoạt động mà không cần gọi OpenAI chút nào.
Tại sao khóa cấp 1 của tôi lại chậm hơn so với khóa cấp 1 của đồng nghiệp? Giới hạn cấp độ là theo tổ chức, không phải theo từng khóa. Nếu khóa của bạn nằm trong một tổ chức dùng chung với những người dùng nặng khác, bạn đang cạnh tranh với lưu lượng truy cập của họ. Apidog có thể hiển thị điều này rõ ràng: chạy cùng một yêu cầu từ cả hai khóa cạnh nhau và so sánh sự suy giảm của x-ratelimit-remaining-tokens.
Làm thế nào để tôi biết mô hình nào có giới hạn nào? Đọc các header phản hồi. Đừng tin vào các bảng chung chung trong các bài đăng trên blog (kể cả bài này). Gửi một yêu cầu rẻ tiền đến mỗi mô hình từ Apidog và ghi lại các header. Các mô hình có cùng tên nhưng phiên bản snapshot khác nhau (ví dụ: gpt-5.5 so với gpt-5.5-0901) có thể có giới hạn khác nhau.
Các yêu cầu streaming có được tính khác không? Có đối với TPM. Một yêu cầu streaming dự trữ token trước dựa trên max_tokens, vì vậy một giá trị max_tokens dài có thể tiêu thụ ngân sách TPM của bạn ngay cả khi kết quả hoàn thành thực tế ngắn. Giảm max_tokens xuống mức giới hạn thực tế chặt chẽ nhất. Chúng tôi đề cập đến hành vi streaming trong cách kiểm tra API ChatGPT với Apidog.
Tôi có thể chia sẻ bài kiểm tra giới hạn tốc độ Apidog của mình với nhóm không? Có. Lưu yêu cầu và kịch bản kiểm thử trong một dự án chia sẻ. Bất kỳ ai trong không gian làm việc của bạn đều có thể chạy cùng một bài kiểm tra đột biến với khóa của riêng họ bằng cách chuyển đổi môi trường. Điều đó làm cho câu hỏi "khóa của tôi hay của họ bị điều tiết?" trở thành một câu hỏi chỉ mất 10 giây.
button