Lỗi 429: cần làm gì khi gọi deepseek-v4-flash thất bại

Mã 429 nghĩa là đã chạm giới hạn tốc độ: số yêu cầu hoặc token trong một khoảng thời gian đã vượt hạn ngạch của gói hiện tại.

429 Too Many Requests là phản hồi giới hạn tốc độ, không phải lỗi. Nghĩa là request hợp lệ nhưng vượt quá tốc độ hoặc số lượng đồng thời mà gói hiện tại cho phép. Chỉ cần chờ theo khoảng thời gian trong response header rồi thử lại, không cần sửa body.

deepseek-v4-flash được DeepSeek cung cấp. Mọi nội dung trên trang này — nguyên nhân, cách xử lý và dữ liệu đo được — đều tổng hợp từ hoạt động thực tế của mô hình này tại lớp gateway.

Tại gateway này, nguyên nhân thường gặp nhất là: Quá nhiều yêu cầu đồng thời. Hành động đầu tiên nên làm là: Giới hạn đồng thời và thử lại với thời gian chờ tăng dần.

Nguyên nhân thường gặp

  • Quá nhiều yêu cầu đồng thời
  • Hết hạn ngạch của gói hiện tại
  • Thử lại ngay không chờ

Cách khắc phục

  • Giới hạn đồng thời và thử lại với thời gian chờ tăng dần
  • Chuyển sang gói hạn ngạch lớn hơn
  • Lưu cache các yêu cầu lặp lại

Ví dụ thử lại với backoff luỹ thừa

Đoạn mã dưới sẽ thử lại khi deepseek-v4-flash trả về 429, tối đa 5 lần, thời gian chờ tăng dần kèm jitter ngẫu nhiên để các request đồng thời không retry cùng lúc. Hãy đọc base URL và API key từ biến môi trường, đừng hardcode vào code.

import os, time, random
import requests

BASE  = os.getenv("OPENAI_BASE_URL")   # e.g. https://<your-gateway>/v1
KEY   = os.getenv("OPENAI_API_KEY")
MODEL = 'deepseek-v4-flash'


def chat(messages, retries=5):
    """Retry with exponential backoff + jitter."""
    for i in range(retries):
        try:
            r = requests.post(
                BASE + "/chat/completions",
                headers={"Authorization": "Bearer " + KEY},
                json={"model": MODEL, "messages": messages, "stream": True},
                timeout=60,
            )
            if r.status_code == 429 or r.status_code >= 500:
                time.sleep(min(2 ** i + random.uniform(0, 1), 30))
                continue
            r.raise_for_status()
            return r.json()
        except requests.exceptions.Timeout:
            time.sleep(min(2 ** i + random.uniform(0, 1), 30))
    raise RuntimeError("gave up after " + str(retries) + " retries")


print(chat([{"role": "user", "content": "hello"}]))

Dữ liệu chính của mô hình này

Điểm cuối APIhttps://api.airai.cc/v1
Tương thích OpenAIOpenAI-compatible
Nhà cung cấpDeepSeek
Ngữ cảnh1M
Khả năngReasoning, Tools, Open Weights
Định dạng APIopenai, openai-response, openai-response-compact, anthropic, gemini, openai-alpha-search
Công thức tính phíp * 0.3 + cr * 0.006 + c * 1.2) : tier("off_peak", p * 0.15 + cr * 0.003 + c * 0.6

Câu hỏi thường gặp

Có cần nâng gói để khắc phục 429 trên deepseek-v4-flash không?

Chủ yếu là vấn đề hạn mức, không phải model bị lỗi. Tăng hạn mức gói hoặc giảm tần suất gọi đều giúp ích. Với cách tính phí p * 0.3 + cr * 0.006 + c * 1.2) : tier("off_peak", p * 0.15 + cr * 0.003 + c * 0.6, các request thất bại không được tính vào mức sử dụng. Khi ước tính chi phí từ p * 0.3 + cr * 0.006 + c * 1.2) : tier("off_peak", p * 0.15 + cr * 0.003 + c * 0.6, hãy tính cả ngân sách thử lại.

Nên dùng exponential backoff hay khoảng cố định?

Thường không cần sửa code nghiệp vụ, chỉ cần điều chỉnh nhịp gọi. Thử lại là bước đầu tiên hiệu quả nhất. Với cách tính phí p * 0.3 + cr * 0.006 + c * 1.2) : tier("off_peak", p * 0.15 + cr * 0.003 + c * 0.6, các request thất bại không được tính vào mức sử dụng. Đặt giới hạn thử lại ở 3–5 lần và thêm jitter. Dùng exponential backoff cho lỗi có thể thử lại, và trả lỗi ngay cho các lỗi còn lại.

Mức concurrency nào là an toàn?

Hãy giảm độ đồng thời trước — hầu hết vấn đề về thông lượng sẽ biến mất. Context 1M nghĩa là input dài sẽ tăng đáng kể độ trễ token đầu tiên. Với đầu ra dài, hãy nâng timeout lên 60 giây hoặc hơn.

Khi báo lỗi nên cung cấp thông tin gì cho hỗ trợ?

Nếu chỉ xảy ra ở môi trường production, thường là khác biệt môi trường chứ không phải mô hình. Mô hình này do DeepSeek cung cấp, vì vậy trạng thái upstream theo thông báo của nhà cung cấp. Ghi lại request ID mỗi lần thất bại — hữu dụng hơn status code. Tái hiện trước trong môi trường thử nghiệm với cùng request body.

Lỗi khác của mô hình này

Các mô hình khác gặp cùng lỗi

Dữ liệu cập nhật: 2026-10-10 12:10

Hỗ trợ kỹ thuậtHỗ trợ trực tuyến
Về đầu trang