Giới hạn tốc độ GPT API: Các cấp, hạn mức sử dụng và cách kiểm tra bằng Apidog

Bạn triển khai một hàm gọi API GPT. Staging chạy ổn, nhưng khi lên production và có vài trăm người dùng đầu tiên, log bắt đầu đầy lỗi 429 Too Many Requests. Vấn đề là RPM, TPM, giới hạn theo ngày, cấp độ tài khoản, hay do mô hình mới có quota chặt hơn?

Thử Apidog ngay hôm nay

Bài viết này hướng dẫn cách kiểm tra giới hạn tốc độ GPT bằng API response headers và một bài test tải nhỏ trong Apidog. Mục tiêu là có một quy trình lặp lại được: gửi request, đọc giới hạn thật, mô phỏng tải, xác định giới hạn nào bị chạm, rồi điều chỉnh code production.

1. Hiểu đúng 4 loại giới hạn quan trọng

OpenAI có nhiều loại rate limit cho API key GPT. Trong production, bạn thường gặp 4 nhóm sau:

Giới hạn	Ý nghĩa	Khi nào dễ gặp
RPM	Requests per minute — số request mỗi phút	Nhiều request nhỏ, nhiều user đồng thời
TPM	Tokens per minute — tổng token input + output mỗi phút	Prompt dài, RAG, context lớn
RPD	Requests per day — số request mỗi ngày	Tài khoản miễn phí hoặc cấp thấp
IPM / TPD / batch queue	Giới hạn riêng cho image, audio, embeddings, batch	Endpoint không phải text completion

Khi vượt giới hạn, API trả về HTTP 429 kèm JSON body tương tự:

{
  "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"
  }
}

Điểm cần đọc đầu tiên là message và type.

Ví dụ:

• tokens thường liên quan đến TPM.
• requests thường liên quan đến RPM.
• tokens_usage_based có thể liên quan đến giới hạn token theo usage.
• quota hoặc thông báo billing thường là vấn đề thanh toán, không phải rate limit thuần túy.

Tham khảo thêm:

• Tài liệu MDN về HTTP 429
• RFC 6585 — 429 Too Many Requests
• Trang rate limits chính thức của OpenAI

2. Hiểu cấp độ tài khoản trước khi debug

API key GPT nằm trong một cấp độ sử dụng của OpenAI. Cấp độ này quyết định giới hạn RPM và TPM thực tế. Việc nâng cấp thường phụ thuộc vào:

1. Tổng chi tiêu của tài khoản.
2. Thời gian kể từ lần thanh toán đầu tiên.

Bảng dưới đây chỉ mang tính minh họa cho các mô hình văn bản. Giới hạn thực tế có thể thay đổi theo thời gian và theo từng model.

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+

Hai điểm quan trọng khi vận hành:

1. Việc nâng cấp cấp độ có thể diễn ra tự động sau khi đủ điều kiện.
2. Tài khoản cũng có thể bị hạ cấp nếu thanh toán lỗi hoặc không hoạt động trong thời gian dài.

Vì vậy, đừng hard-code giả định như “tài khoản này chắc chắn là tier 2”. Hãy đọc giới hạn thật từ response headers.

Bạn có thể so sánh thêm với các nhà cung cấp khác tại:

• Giới hạn tốc độ người dùng API OpenAI
• Giới hạn tốc độ API Claude
• Giới hạn tốc độ API Grok-3

3. Đọc giới hạn thật từ response headers

Mỗi response từ API GPT thường chứa các header rate limit. Khi debug, hãy kiểm tra các header này:

Header	Ý nghĩa
x-ratelimit-limit-requests	Giới hạn request cho endpoint hiện tại
x-ratelimit-remaining-requests	Số request còn lại trong cửa sổ hiện tại
x-ratelimit-limit-tokens	Giới hạn token
x-ratelimit-remaining-tokens	Số token còn lại
x-ratelimit-reset-requests	Thời gian đến khi reset request limit
x-ratelimit-reset-tokens	Thời gian đến khi reset token limit

Ví dụ x-ratelimit-reset-tokens: 6s nghĩa là nên đợi khoảng 6 giây trước khi retry request liên quan đến token limit.

4. Tạo request GPT trong Apidog

Mở Apidog, tạo project mới, sau đó thêm một request mới.

Cấu hình request:

POST https://api.openai.com/v1/chat/completions

Headers:

Key	Value
Authorization	Bearer {{OPENAI_API_KEY}}
Content-Type	application/json

Trong Apidog, {{OPENAI_API_KEY}} là environment variable. Cách này giúp bạn không lưu API key trực tiếp trong request.

Body:

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

Nhấn Send, sau đó mở tab Headers ở phần response.

Ghi lại các giá trị:

x-ratelimit-limit-requests
x-ratelimit-remaining-requests
x-ratelimit-limit-tokens
x-ratelimit-remaining-tokens
x-ratelimit-reset-requests
x-ratelimit-reset-tokens

Đây là baseline để kiểm tra xem production đang chạm RPM hay TPM.

Nếu cần hướng dẫn chi tiết hơn về request chat completion, xem cách kiểm tra API ChatGPT với Apidog.

5. Test RPM bằng một spike nhỏ

Một request đơn lẻ chỉ cho bạn biết giới hạn. Để kiểm tra hành vi khi chạm giới hạn, hãy chạy một test đồng thời nhỏ.

Trong Apidog:

1. Mở request đã lưu.
2. Nhấn mũi tên cạnh Send.
3. Chọn Run in Test Scenario.
4. Cấu hình:

Iterations: 50
Concurrency: 10
Delay between iterations: 0 ms

Nếu RPM của bạn thấp hơn số request gửi trong cửa sổ đó, một số response sẽ trả về 429.

Khi có lỗi 429, mở response body và đọc:

{
  "error": {
    "message": "... on requests per min (RPM) ...",
    "type": "requests",
    "code": "rate_limit_exceeded"
  }
}

Nếu lỗi nói requests per min, vấn đề chính là RPM.

Cách xử lý thường là:

• Giới hạn concurrency.
• Đưa request vào queue.
• Thêm retry với backoff.
• Không chạy Promise.all() không giới hạn trên một tập dữ liệu lớn.

Tham khảo thêm: hướng dẫn xử lý rate limit exceeded.

6. Test TPM bằng payload lớn hơn

RPM thường xảy ra với nhiều request nhỏ. TPM xảy ra khi request chứa quá nhiều token.

Để test TPM, chỉnh body thành prompt lớn hơn:

{
  "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
}

Sau đó chạy scenario nhỏ hơn, ví dụ:

Iterations: 20
Concurrency: 5
Delay between iterations: 0 ms

Nếu response trả về:

Rate limit reached ... on tokens per min (TPM)

thì vấn đề không phải số lượng request, mà là tổng token mỗi phút.

Cách xử lý TPM khác RPM:

Vấn đề	Cách xử lý
Prompt hệ thống quá dài	Rút gọn system prompt
RAG nhồi quá nhiều tài liệu	Chunking, reranking, chỉ đưa context cần thiết
max_tokens quá cao	Giảm xuống mức thực tế cần dùng
Nhiều request lớn chạy cùng lúc	Queue theo token budget
Context lặp lại	Dùng cơ chế cache prompt nếu endpoint/model hỗ trợ

7. Mô phỏng traffic production

Production hiếm khi chỉ là 50 request giống nhau. Thường bạn sẽ có:

• User đồng thời.
• Request nhỏ/vừa/lớn trộn lẫn.
• Spike ngắn.
• Nền traffic ổn định.
• Một số request streaming.
• Một số request có context dài bất thường.

Trong Apidog, bạn có thể tạo test scenario gồm nhiều biến thể request:

1. Request nhỏ: prompt ngắn, max_tokens thấp.
2. Request vừa: prompt có context trung bình.
3. Request lớn: prompt dài, max_tokens cao hơn.

Sau đó dùng script trước/sau request để:

• Chọn payload ngẫu nhiên.
• Đọc x-ratelimit-remaining-tokens.
• Dừng scenario nếu token còn lại xuống dưới ngưỡng an toàn.
• Ghi nhận latency của response 200 và 429.

Ví dụ logic pseudo-code cho post-request script:

const remainingTokens = Number(response.headers.get("x-ratelimit-remaining-tokens"));

if (remainingTokens < 1000) {
  console.log("Token budget is low. Stop or slow down the scenario.");
}

Kết quả quan trọng nhất là phân bố status code:

200 OK: 93%
429 Too Many Requests: 7%

Nếu tỷ lệ 429 tăng khi concurrency tăng, bạn có dữ liệu để quyết định nên queue, giảm payload, hay tăng cấp tài khoản.

8. Thêm retry/backoff trong code production

Khi gặp 429, không nên retry ngay lập tức. Hãy đọc reset header nếu có.

Ví dụ Node.js với exponential backoff đơn giản:

async function sleep(ms) {
  return new Promise(resolve => setTimeout(resolve, ms));
}

function parseResetHeader(value) {
  if (!value) return null;

  if (value.endsWith("ms")) return Number(value.replace("ms", ""));
  if (value.endsWith("s")) return Number(value.replace("s", "")) * 1000;
  if (value.endsWith("m")) return Number(value.replace("m", "")) * 60 * 1000;

  return null;
}

async function callWithRetry(fn, maxRetries = 5) {
  for (let attempt = 0; attempt <= maxRetries; attempt++) {
    try {
      return await fn();
    } catch (err) {
      const status = err?.response?.status;
      const headers = err?.response?.headers;

      if (status !== 429 || attempt === maxRetries) {
        throw err;
      }

      const resetTokens = headers?.["x-ratelimit-reset-tokens"];
      const resetRequests = headers?.["x-ratelimit-reset-requests"];

      const resetDelay =
        parseResetHeader(resetTokens) ||
        parseResetHeader(resetRequests) ||
        2 ** attempt * 1000;

      await sleep(resetDelay);
    }
  }
}

Ý tưởng chính:

1. Nếu API nói nên đợi bao lâu, dùng thời gian đó.
2. Nếu không có header reset, dùng exponential backoff.
3. Giới hạn số lần retry để tránh request treo vô hạn.

9. Queue request thay vì bắn song song không kiểm soát

Nếu traffic có spike, queue thường hiệu quả hơn retry liên tục.

Mẫu triển khai cơ bản:

import PQueue from "p-queue";

const queue = new PQueue({
  concurrency: 5,
  interval: 60_000,
  intervalCap: 300
});

export function enqueueGptJob(payload) {
  return queue.add(() => callGpt(payload));
}

Trong đó:

• concurrency giới hạn số request chạy cùng lúc.
• intervalCap nên thấp hơn RPM thật để có vùng an toàn.
• Nếu bị TPM, bạn cần queue theo token estimate, không chỉ theo số request.

Tham khảo thêm:

• Cách triển khai API rate limiting
• Triển khai rate limiting trong API

Nếu cần phân biệt throttling và rate limiting, xem throttle vs. rate limit.

10. Cân nhắc Batch API cho workload không cần realtime

Nếu workload không cần trả kết quả ngay cho user, xử lý theo batch có thể phù hợp hơn.

Ví dụ phù hợp với batch:

• Làm giàu dữ liệu qua đêm.
• Phân loại tài liệu.
• Tạo embeddings hàng loạt.
• Xử lý lại dữ liệu lịch sử.
• Tóm tắt tập tài liệu lớn không cần realtime.

Cách này giúp tách workload nền khỏi quota đồng bộ phục vụ user.

11. Các lỗi GPT 429 thường gặp

Rate limit reached ... on requests per min (RPM)

Nguyên nhân: quá nhiều request mỗi phút.

Cách xử lý:

• Giảm concurrency.
• Queue request.
• Không dùng Promise.all() không giới hạn.
• Dùng worker pool.
• Retry theo reset header.

Rate limit reached ... on tokens per min (TPM)

Nguyên nhân: tổng token input/output mỗi phút quá cao.

Cách xử lý:

• Giảm prompt.
• Giảm max_tokens.
• Chunk tài liệu.
• Rerank context trước khi gửi vào model.
• Giới hạn số request lớn chạy đồng thời.

You exceeded your current quota, please check your plan and billing details

Nguyên nhân thường là billing/quota, không phải rate limit kỹ thuật.

Cần kiểm tra:

• Monthly spending limit.
• Số dư trả trước.
• Thẻ thanh toán.
• Trạng thái billing của organization.

FAQ

Apidog có tốn phí để kiểm tra rate limit GPT không?

Không nhất thiết. Gói miễn phí có thể dùng để gửi request đơn lẻ và chạy các test đồng thời nhỏ. Nếu cần load test lớn hơn, workspace nhóm hoặc chạy theo lịch, hãy xem giá Apidog.

Có thể kiểm tra rate limit mà không tốn token thật không?

Một phần. Request rẻ nhất là prompt rất ngắn với max_tokens: 1. Header rate limit vẫn được trả về.

Ví dụ:

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

Với spike test, bạn vẫn tiêu thụ token thật. Nếu chỉ muốn kiểm tra retry logic, có thể dùng mock server trong Apidog để mô phỏng response 429 mà không gọi OpenAI.

Vì sao API key cùng tier nhưng tốc độ khác nhau?

Giới hạn thường áp dụng theo organization, không chỉ theo từng key. Nếu nhiều key cùng dùng chung một organization, chúng có thể cạnh tranh cùng quota.

Cách kiểm tra:

1. Tạo cùng một request trong Apidog.
2. Chạy với key A.
3. Chạy với key B.
4. So sánh x-ratelimit-remaining-tokens và x-ratelimit-remaining-requests.

Làm sao biết model nào có giới hạn nào?

Đọc response headers. Đừng chỉ dựa vào bảng trong blog post hoặc tài liệu cũ.

Hãy gửi một request rẻ đến từng model cần dùng và ghi lại:

model
x-ratelimit-limit-requests
x-ratelimit-limit-tokens
x-ratelimit-reset-requests
x-ratelimit-reset-tokens

Các snapshot model khác nhau có thể có giới hạn khác nhau.

Streaming request có tính khác không?

Có thể khác ở TPM. Streaming request có thể giữ trước token budget dựa trên max_tokens. Nếu đặt max_tokens quá cao, bạn có thể tiêu thụ nhiều TPM hơn cần thiết.

Cách xử lý:

• Đặt max_tokens sát nhu cầu thực tế.
• Giới hạn số streaming request đồng thời.
• Theo dõi x-ratelimit-remaining-tokens.

Hành vi streaming cũng được đề cập trong cách kiểm tra API ChatGPT với Apidog.

Có thể chia sẻ test rate limit Apidog với nhóm không?

Có. Lưu request và test scenario trong project dùng chung. Mỗi thành viên có thể chạy cùng scenario với API key của họ bằng cách đổi environment. Cách này giúp xác định nhanh vấn đề nằm ở key, organization, model hay workload.