Phản hồi 429 từ một API AI có thể mang bốn ý nghĩa khác nhau: quá nhiều yêu cầu mỗi phút, quá nhiều token mỗi phút, quá nhiều kết nối đồng thời, hoặc tài khoản đã hết số dư. Cả bốn trường hợp đều trả về cùng một mã trạng thái, vì vậy giải pháp nằm ở việc chẩn đoán đúng giới hạn nào bạn đã chạm tới, thay vì chỉ cố gắng gửi lại yêu cầu. Hướng dẫn này sẽ phân tích các chế độ lỗi, chỉ ra những bằng chứng nào có sẵn (và không có sẵn) về các giới hạn hiện tại, đồng thời cung cấp cho bạn mô hình thử lại và dự phòng (fallback) phù hợp cho môi trường production.
Những điểm chính cần lưu ý
- Mã
429có thể có nghĩa là giới hạn yêu cầu, ngân sách token, giới hạn đồng thời hoặc cạn kiệt số dư tài khoản. Mỗi trường hợp cần một cách xử lý khác nhau, và việc thử lại một cách mù quáng chỉ giải quyết được một trong bốn vấn đề. - Hãy đọc các header giới hạn tốc độ (rate-limit headers) trên các phản hồi thành công, không chỉ sau khi gặp lỗi, và điều tiết lưu lượng trước khi chạm ngưỡng giới hạn.
- Việc đếm token ở phía client chỉ là ước tính, không phải là sự đảm bảo. Sự sai lệch giữa thư viện tokenizer của bạn và cách đếm thực tế của nhà cung cấp có thể khiến biên độ an toàn hẹp hơn bạn nghĩ.
- Các ngưỡng RPM/TPM chính xác cho từng model và từng gói dịch vụ không được công bố trong dữ liệu có sẵn cho bài viết này. Hãy coi bất kỳ con số nào bạn thấy ở nơi khác là dữ liệu cần kiểm chứng với bảng điều khiển tài khoản của chính bạn, không phải là hằng số cố định.
- Việc thử lại (retry) cần có cơ chế exponential backoff (tăng dần thời gian chờ), jitter (thêm độ trễ ngẫu nhiên), giới hạn số lần thử lại tối đa và tuân thủ header
retry-after. Không bao giờ thử lại các thao tác không có tính lũy đẳng (non-idempotent) một cách mù quáng.
Hiểu về giới hạn tốc độ API AI: Bốn chế độ lỗi
Giới hạn yêu cầu (Request limits)
Hầu hết các nhà cung cấp đều đếm số yêu cầu mỗi phút (RPM). Nếu vượt quá, bạn sẽ nhận ngay mã 429, thường kèm theo nội dung phản hồi trống. Một người dùng liên tục chuyển trang kết quả hoặc một cron job chạy mà không có cơ chế điều tiết là những nguyên nhân phổ biến.
Giới hạn token (Token limits)
Đây là cái bẫy mà các đội ngũ thường đánh giá thấp nhất. Các nhà cung cấp thường thực thi giới hạn token mỗi phút (TPM) tách biệt với RPM, vì vậy bạn có thể gặp lỗi 429 ngay cả khi vẫn đang ở dưới ngưỡng giới hạn yêu cầu. Các model có ngữ cảnh lớn làm vấn đề này trầm trọng hơn: theo dữ liệu giá thực tế của TokenLab (quan sát ngày 07/07/2026), cả Claude Opus 4.8 và GPT-5.5 đều hỗ trợ hơn 1.000.000 token ngữ cảnh. Một yêu cầu tải một tài liệu lớn, toàn bộ codebase hoặc lịch sử trò chuyện dài vào cửa sổ đó có thể tiêu tốn phần lớn ngân sách token mỗi phút của bạn chỉ trong một yêu cầu duy nhất. Đây là rủi ro lập kế hoạch năng lực dựa trên kích thước cửa sổ ngữ cảnh, không phải dựa trên số lượng token mỗi lần gọi, vì vậy hãy đối chiếu mức sử dụng thực tế với nhật ký của chính bạn thay vì giả định một con số cố định.
Giới hạn đồng thời (Concurrency limits)
Các nhà cung cấp có thể chấp nhận lưu lượng trung bình mỗi phút của bạn cho đến khi bạn mở cùng lúc năm mươi luồng (stream). Giới hạn đồng thời chặn các yêu cầu hoặc kết nối đang xử lý cùng lúc. Các phản hồi streaming giữ kết nối mở lâu hơn, làm cạn kiệt các khe cắm đồng thời nhanh hơn so với các cuộc gọi đơn lẻ, ngắn hạn. Các tác nhân lập trình (coding agents) xây dựng trên Claude Sonnet 5 hoặc Kimi K2.7 Code, và các giao diện giọng nói streaming từ Gemini 3.5 Flash là những nguyên nhân phổ biến vì chúng giữ nhiều kết nối tồn tại lâu cùng một lúc.
Cạn kiệt hạn mức hoặc số dư (Quota or balance exhaustion)
Lỗi này trông giống hệt giới hạn tốc độ trong bảng điều khiển của bạn: các cuộc gọi ngừng hoạt động. Nhưng cách khắc phục lại khác. Nếu tài khoản của bạn hết tín dụng trả trước hoặc chạm ngưỡng chi tiêu hàng ngày, API sẽ trả về lỗi giống như giới hạn tốc độ. Việc chờ đợi (backoff) không có tác dụng ở đây. Bạn cần nạp thêm số dư hoặc nâng ngưỡng chi tiêu.
Ảnh chụp nhanh nguồn dữ liệu
| Điểm dữ liệu | Nguồn | Thời điểm quan sát |
|---|---|---|
| Cửa sổ ngữ cảnh model và giá mỗi token | Dữ liệu giá model thực tế từ TokenLab | 07/07/2026 |
| Tên model SSOT (Claude Sonnet 5, GPT-5.5, Gemini 3.5 Flash, v.v.) | TokenLab model SSOT | 07/07/2026, hết hạn 14/07/2026 |
| Giới hạn RPM/TPM chính thức của nhà cung cấp | Không có trong tập dữ liệu này | Chưa xác minh, kiểm tra bảng điều khiển tài khoản nhà cung cấp |
| Hành vi chuẩn hóa header gateway của TokenLab | Không có trong tập dữ liệu này | Xác minh trong tài liệu API TokenLab trước khi dựa vào một lược đồ header duy nhất |
Cửa sổ ngữ cảnh và giá model hiện tại (Dữ liệu thực tế từ TokenLab)
Những con số này đến trực tiếp từ ảnh chụp giá thực tế của TokenLab. Chúng không phải là giới hạn RPM hay TPM, mà cho thấy lý do tại sao một cuộc gọi đơn lẻ trên model có ngữ cảnh lớn có thể tiêu tốn ngân sách token một cách không cân xứng.
| Model | Nhà cung cấp | Cửa sổ ngữ cảnh | Đầu vào $/MTok | Đầu ra $/MTok | Nguồn | Quan sát |
|---|---|---|---|---|---|---|
| Claude Sonnet 5 | Anthropic | 1.000.000 | $2.00 | $10.00 | Dữ liệu giá thực tế TokenLab | 07/07/2026 |
| Claude Opus 4.8 | Anthropic | 1.000.000 | $5.00 | $25.00 | Dữ liệu giá thực tế TokenLab | 07/07/2026 |
| Claude Fable 5 | Anthropic | 1.000.000 | $10.00 | $50.00 | Dữ liệu giá thực tế TokenLab | 07/07/2026 |
| GPT-5.5 | OpenAI | 1.050.000 | $5.00 | $30.00 | Dữ liệu giá thực tế TokenLab | 07/07/2026 |
| GPT-5.5 Batch/Flex | OpenAI | 1.050.000 | $2.50 | $15.00 | Dữ liệu giá thực tế TokenLab | 07/07/2026 |
| Gemini 3.5 Flash | 1.048.576 | $1.50 | $9.00 | Dữ liệu giá thực tế TokenLab | 07/07/2026 | |
| GLM-5.2 | Z.ai | 1.048.576 | $0.93 | $3.00 | Dữ liệu giá thực tế TokenLab | 07/07/2026 |
| Kimi K2.7 Code | Moonshot AI | 262.144 | $0.74 | $3.50 | Dữ liệu giá thực tế TokenLab | 07/07/2026 |
| DeepSeek V4 Pro | DeepSeek | 1.048.576 | $0.44 | $0.87 | Dữ liệu giá thực tế TokenLab | 07/07/2026 |
| DeepSeek V4 Flash | DeepSeek | 1.048.576 | $0.09 | $0.18 | Dữ liệu giá thực tế TokenLab | 07/07/2026 |
| Qwen3.7 Plus | Alibaba | 1.000.000 | $0.32 | $1.28 | Dữ liệu giá thực tế TokenLab | 07/07/2026 |
| MiniMax M3 | MiniMax | 1.048.576 | $0.30 | $1.20 | Dữ liệu giá thực tế TokenLab | 07/07/2026 |
Lưu ý về SSOT model: những tên này phản ánh SSOT model của TokenLab được quan sát vào ngày 07/07/2026, hết hạn vào 14/07/2026. Tên gọi và tính khả dụng thay đổi thường xuyên. Trước khi bạn hardcode một chuỗi model vào mã nguồn production, hãy xác nhận rằng nó vẫn tồn tại trong danh mục model của TokenLab hoặc bảng xếp hạng model.
Khắc phục lỗi giới hạn tốc độ mà không cần tự xây dựng logic thử lại
Tất cả những điều trên là chẩn đoán. Công việc khắc phục, quyết định model nào để dự phòng, theo dõi tính đồng thời của mỗi người dùng và duy trì bức tranh trực tiếp về các dòng model nào đang hoạt động tốt, chính là những gì lớp định tuyến (routing layer) của TokenLab được xây dựng để xử lý. Thay vì tự tạo ma trận dự phòng trên năm nhà cung cấp, bạn chỉ cần gửi yêu cầu đến TokenLab và để gateway chọn lựa trong số danh mục model hiện tại dựa trên tính khả dụng và các quy tắc dự phòng của bạn.
Một lưu ý trung thực: TokenLab nằm phía trước nhiều nhà cung cấp thượng nguồn, và mỗi nhà cung cấp trả về bộ header, định dạng lỗi và ngữ nghĩa thử lại riêng. Việc gateway có chuẩn hóa hoàn toàn mọi header giới hạn tốc độ thành một lược đồ nhất quán hay chuyển tiếp một số header thượng nguồn mà không thay đổi, chưa được xác nhận trong dữ liệu có sẵn cho bài viết này. Hãy xác minh hành vi header hiện tại trong tài liệu API của TokenLab trước khi bạn viết logic phân tích cú pháp giả định một lược đồ thống nhất trên mọi model. Hãy xây dựng bộ phân tích header của bạn một cách phòng thủ, kiểm tra sự hiện diện của từng trường thay vì giả định nó luôn tồn tại.
Đọc các header giới hạn tốc độ
Các nhà cung cấp trả về thông tin giới hạn tốc độ trong các header phản hồi, mặc dù tên chính xác thay đổi tùy theo nhà cung cấp. Một mô hình phổ biến trông như sau:
x-ratelimit-limit-requests: 500
x-ratelimit-remaining-requests: 499
x-ratelimit-reset-requests: 12s
retry-after: 0
Hãy đọc các thông tin này trên các phản hồi thành công, không chỉ sau khi gặp lỗi 429. Duy trì một bộ đếm luân phiên về ngân sách còn lại và giảm tốc độ khi bạn xuống dưới ngưỡng an toàn, thường là 10-20% dư địa, mặc dù con số phù hợp phụ thuộc vào mức độ bùng nổ lưu lượng của bạn và không phải là thứ mà tập dữ liệu này có thể chỉ định cho bạn.
Logic thử lại với xử lý lỗi rõ ràng
Một trình trợ giúp thử lại cần xử lý nhiều hơn trường hợp 429. Nó nên phân biệt các lỗi tạm thời (429, 503, timeout) với các lỗi phía client (4xx khác 429) sẽ không bao giờ thành công khi thử lại, và nó nên tôn trọng retry-after khi có mặt.
async function callWithRetry(fn, maxRetries = 4) {
for (let attempt = 0; attempt <= maxRetries; attempt++) {
try {
return await fn();
} catch (err) {
const status = err.status;
// Các lỗi client khác 429 sẽ không thành công khi thử lại
if (status && status >= 400 && status < 500 && status !== 429) {
throw err;
}
// Từ bỏ sau số lần thử lại tối đa bất kể loại lỗi
if (attempt === maxRetries) throw err;
// 429: tôn trọng retry-after nếu có, nếu không thì backoff với jitter
if (status === 429) {
const retryAfter = parseRetryAfterHeader(err);
const delay = retryAfter
? retryAfter * 1000
: Math.pow(2, attempt) * 1000 + Math.random() * 1000;
await sleep(delay);
continue;
}
// 503 hoặc network timeout: backoff và thử lại, log để quan sát
if (status === 503 || err.code === 'ETIMEDOUT' || err.code === 'ECONNRESET') {
await sleep(Math.pow(2, attempt) * 1000 + Math.random() * 1000);
continue;
}
// Lỗi 5xx không xác định: thử lại với backoff, giới hạn số lần thử
if (status && status >= 500) {
await sleep(Math.pow(2, attempt) * 1000 + Math.random() * 1000);
continue;
}
throw err;
}
}
}
Không bao giờ bao bọc các thao tác không có tính lũy đẳng, như thanh toán hoặc ghi dữ liệu có tác dụng phụ, trong một vòng lặp thử lại ngây thơ. Hãy xác nhận tính lũy đẳng hoặc sử dụng idempotency key trước khi thử lại các cuộc gọi đó.
Độ chính xác của ước tính token: Tại sao số đếm cục bộ lệch với số đếm của nhà cung cấp
Các thư viện đếm token phía client chỉ xấp xỉ tokenizer mà một model nhất định thực sự sử dụng. tiktoken khớp chặt chẽ với dòng model của OpenAI nhưng không đảm bảo khớp chính xác với tokenizer của Anthropic, Google hoặc các model mã nguồn mở. Sự khác biệt xuất hiện xung quanh các token đặc biệt, ký tự đa byte và định dạng system prompt, và chúng cộng dồn trong các cuộc trò chuyện dài.
Các bước thực tế để giảm độ lệch:
- Đọc mức sử dụng token thực tế được trả về trong nội dung phản hồi (hầu hết các nhà cung cấp đều bao gồm số lượng token prompt và completion) và sử dụng nó để hiệu chỉnh trình ước tính cục bộ của bạn theo thời gian.
- Giữ một biên độ an toàn, không phải là ranh giới cứng. Nếu giới hạn TPM của nhà cung cấp gần với mức sử dụng ước tính của bạn, hãy trì hoãn hoặc chia nhỏ yêu cầu thay vì gửi nó ngay tại ngưỡng giới hạn.
- Nếu prompt của bạn lớn hoặc lặp đi lặp lại giữa các cuộc gọi, hãy xem phạm vi bao phủ của TokenLab về hành vi token hóa và các chiến lược chia nhỏ prompt để có những cách cụ thể nhằm cắt giảm token mỗi yêu cầu trước khi bạn chạm ngưỡng giới hạn. Giảm token mỗi cuộc gọi thường là cách khắc phục rẻ hơn so với việc đàm phán một gói dịch vụ cao hơn.
Định hình lưu lượng và dự phòng model
Exponential backoff với jitter. Nhân đôi thời gian chờ sau mỗi lần thử lại và thêm jitter ngẫu nhiên để các client đồng thời không thử lại cùng lúc.
Định hình lưu lượng theo người dùng hoặc tác vụ. Giới hạn các cuộc gọi đồng thời mỗi người dùng (ví dụ: 3 cuộc gọi đồng thời, 5 yêu cầu mỗi giây) để một người dùng nặng không thể làm cạn kiệt giới hạn toàn tài khoản và làm giảm hiệu năng của những người khác.
Ước tính ngân sách token trước khi gửi. Đếm token phía client, và nếu một yêu cầu đẩy bạn vượt quá ngân sách TPM đã theo dõi, hãy trì hoãn hoặc chia nhỏ nó thay vì gửi đi và hy vọng.
Dự phòng model như một mạng lưới an toàn. Khi một model chính trả về 429, hãy định tuyến đến một model thay thế với các giới hạn riêng biệt và khả năng tương đương. Một tác vụ lập trình có thể chuyển đổi từ Claude Sonnet 5 sang DeepSeek V4 Pro hoặc Kimi K2.7 Code. Một khối lượng công việc lưu lượng cao, chi phí thấp có thể chuyển đổi giữa DeepSeek V4 Flash, Gemini 3.5 Flash và Qwen3.7 Plus, tất cả đều nằm trong tầng định tuyến chi phí thấp của danh mục model hiện tại.
Danh sách kiểm tra xử lý giới hạn tốc độ
| Danh mục | Những gì cần kiểm tra | Hành động ngay lập tức | Khắc phục dài hạn |
|---|---|---|---|
| Giới hạn yêu cầu | Giá trị header RPM, tần suất bùng nổ | Điều tiết yêu cầu client, thêm giới hạn tốc độ cục bộ | Các gói dịch vụ theo người dùng, xếp hàng phía server |
| Giới hạn token | Ngân sách TPM mỗi model, token trung bình mỗi cuộc gọi, mức sử dụng báo cáo | Đếm trước token, chia nhỏ prompt lớn, trì hoãn cuộc gọi gần ngưỡng | Batching với ngân sách token, định tuyến công việc lưu lượng cao đến model rẻ hơn |
| Giới hạn đồng thời | Số luồng hoặc kết nối đồng thời tối đa | Giới hạn yêu cầu đồng thời mỗi client, đóng luồng nhàn rỗi | Connection pooling, khởi chạy luồng so le |
| Hạn mức / số dư | Số dư tài khoản, giới hạn chi tiêu hàng ngày | Nạp thêm tín dụng, điều chỉnh ngưỡng chi tiêu | Cảnh báo số dư thấp, tự động nạp tiền trả trước |
Các phạm vi giới hạn điển hình: Những gì chúng ta có thể và không thể xác nhận
Các tìm kiếm phụ cho chủ đề này thường muốn một bảng các con số RPM/TPM "điển hình". Chúng tôi sẽ không tự bịa ra. Các giới hạn theo gói dịch vụ đã công bố thay đổi thường xuyên, khác nhau tùy theo lịch sử tài khoản và gói sử dụng, và không phải là một phần của dữ liệu có sẵn cho bài viết này.
| Câu hỏi | Trạng thái | Bước xác minh |
|---|---|---|
| Giới hạn RPM "điển hình" cho một model tiên phong là bao nhiêu? | Không xác nhận trong tập dữ liệu này | Kiểm tra bảng điều khiển tài khoản nhà cung cấp hoặc header phản hồi giới hạn tốc độ trực tiếp |
| Giới hạn TPM "điển hình" cho một model 1M-context là bao nhiêu? | Không xác nhận trong tập dữ liệu này | Ghi nhật ký mức sử dụng thực tế từ header phản hồi trong một tuần để xây dựng đường cơ sở của riêng bạn |
| Gói sử dụng có thay đổi những con số này không? | Có khả năng dựa trên hành vi chung của nhà cung cấp, không được benchmark ở đây | Xác nhận giới hạn gói hiện tại trong console nhà cung cấp |
| Giới hạn tổng hợp của TokenLab có khớp chính xác với giới hạn nhà cung cấp thượng nguồn không? | Không xác nhận trong tập dữ liệu này | Xác minh trong tài liệu API của TokenLab trước khi lập kế hoạch năng lực |
Hạn chế
- Không có số liệu RPM/TPM chính thức nào cho GPT-5.5, Claude Opus 4.8, Gemini 3.5 Flash hoặc bất kỳ model nào được tham chiếu ở đây. Mọi con số trong các bảng giá ở trên đều là kích thước cửa sổ ngữ cảnh và chi phí mỗi token, không phải giới hạn tốc độ.
- Việc gateway của TokenLab có thống nhất hoàn toàn các header giới hạn tốc độ trên mọi nhà cung cấp thượng nguồn hay chuyển tiếp một số header mà không thay đổi, chưa được xác nhận trong tập dữ liệu này. Hãy coi việc phân tích cú pháp header là đặc thù của từng nhà cung cấp cho đến khi bạn xác minh hành vi gateway hiện tại trong tài liệu.
- Tên model trong bài viết này phản ánh SSOT model của TokenLab được quan sát vào ngày 07/07/2026, hết hạn vào 14/07/2026. Xác nhận tính khả dụng hiện tại trong danh mục model trước khi phát hành mã nguồn hardcode chuỗi model.
- Độ chính xác của ước tính token so với việc đếm phía nhà cung cấp không được benchmark trong tập dữ liệu này. Hãy hiệu chỉnh trình ước tính của riêng bạn dựa trên mức sử dụng được báo cáo trong phản hồi thay vì tin tưởng vào một độ lệch cố định.
Câu hỏi thường gặp
Tại sao ứng dụng của tôi gặp lỗi 429 mặc dù số lượng yêu cầu nằm dưới giới hạn? Trước tiên, hãy kiểm tra ngân sách token mỗi phút (TPM). Một prompt lớn đơn lẻ có thể làm cạn kiệt hạn mức token trong khi số lượng yêu cầu vẫn thấp. Ngoài ra, hãy kiểm tra tính đồng thời: các kết nối streaming đang mở có thể chặn các yêu cầu mới ngay cả khi cả RPM và TPM đều trông có vẻ ổn.
Tôi có nên thử lại ngay lập tức khi nhận được lỗi 429 không?
Không. Hãy đợi khoảng thời gian được chỉ định trong retry-after, hoặc sử dụng exponential backoff với jitter nếu header đó không có mặt. Việc thử lại ngay lập tức có nguy cơ gây ra hiệu ứng "thundering-herd" và có thể kéo dài thời gian khóa của bạn.
Làm thế nào để biết liệu số lượng token cục bộ của tôi có khớp với những gì nhà cung cấp thực sự tính phí cho tôi không? Bạn không thể biết chính xác. Các tokenizer phía client chỉ là các phép xấp xỉ. Hãy đọc mức sử dụng token được trả về trong mỗi nội dung phản hồi và sử dụng nó để hiệu chỉnh trình ước tính của bạn theo thời gian, đồng thời giữ một biên độ an toàn thay vì gửi yêu cầu ngay tại ngưỡng giới hạn ước tính của bạn.
TokenLab có hiển thị một bộ header giới hạn tốc độ thống nhất trên mọi model không? Chưa được xác nhận trong dữ liệu có sẵn ở đây. Các nhà cung cấp thượng nguồn khác nhau trả về các định dạng header khác nhau, và mức độ chuẩn hóa mà TokenLab áp dụng là điều cần xác minh trong tài liệu API hiện tại thay vì giả định.
Làm thế nào tôi có thể tránh giới hạn tốc độ mà không cần nâng cấp gói của mình? Kết hợp lập ngân sách token, giới hạn đồng thời cục bộ và dự phòng model. Ước tính token trước khi gửi, chia nhỏ các prompt dài và định tuyến đến một model thay thế, ví dụ từ Claude Sonnet 5 sang DeepSeek V4 Pro, khi giới hạn chính của bạn bị chạm tới.
Bắt đầu
Giới hạn tốc độ là một thực tế khi xây dựng trên các API AI, nhưng chúng không nhất thiết phải gây ra sự cố. Gateway của TokenLab cung cấp cho bạn quyền truy cập vào danh mục model hiện tại và dữ liệu giá và thông lượng thực tế để bạn có thể định tuyến xung quanh các giới hạn thay vì đoán mò. Nếu bạn cũng đang đánh giá các đánh đổi của bộ tổng hợp (aggregator), bài viết so sánh OpenRouter sẽ đề cập sâu hơn về hành vi dự phòng và chi phí vận hành. Hãy lấy API key của bạn tại tokenlab.sh và xây dựng logic thử lại và dự phòng một lần, không phải cho từng nhà cung cấp.
Nguồn
Giá quan sát ngày 2026-07-07
- TokenLab model directoryQuan sát ngày 2026-07-07
