Xử lý Giới hạn Tốc độ (Rate Limit) của AI API: Backoff, Queue, Fallback, hay Fail Closed

Giới hạn tốc độ (rate limit) không chỉ đơn thuần là lỗi để thử lại. Trong các hệ thống AI sản phẩm, lỗi 429 có thể có nghĩa là một đợt yêu cầu ngắn đã vượt quá token bucket, một dự án đã đạt đến giới hạn yêu cầu mỗi phút, đã đạt đến giới hạn chi tiêu, hoặc nhà cung cấp đang yêu cầu client giảm tốc độ trước khi dung lượng phục hồi. Việc xử lý giới hạn tốc độ AI API tốt sẽ phân tách các trường hợp đó trước khi tiêu tốn thêm token.

Mô hình sai rất đơn giản: mỗi worker thấy lỗi 429, tạm dừng trong cùng một khoảng thời gian cố định, thử lại cùng một lúc, và sau đó chuyển sang một mô hình khác khi các lần thử lại thất bại. Điều đó biến một tín hiệu về dung lượng thành tải trùng lặp, chi phí cao hơn, đầu ra không nhất quán và bằng chứng sự cố yếu.

Mục tiêu của việc xử lý giới hạn tốc độ AI API là giữ cho công việc có giới hạn. Một số yêu cầu nên lùi lại (back off). Một số nên được chuyển vào hàng đợi (queue). Một số có thể chuyển sang một tuyến dự phòng (fallback) đã được phê duyệt. Một số nên thất bại đóng (fail closed) vì việc thay đổi mô hình, hỗ trợ công cụ, ranh giới dữ liệu hoặc chi phí sẽ rủi ro hơn là trả về một lỗi có kiểm soát. Flatkey phù hợp với mô hình hoạt động này vì các nhóm có thể giữ quyền truy cập mô hình, định tuyến, thanh toán, phân tích sử dụng và kiểm soát hoạt động trong một bề mặt cổng (gateway) duy nhất trong khi họ xác thực danh mục hiện tại và bằng chứng yêu cầu.

Xử lý giới hạn tốc độ AI API trong một bảng

Sử dụng bảng này như bước đầu tiên để thiết kế chính sách cho môi trường sản phẩm.

Đây là cốt lõi của việc xử lý giới hạn tốc độ AI API: quyết định thử lại được đưa ra sau khi tín hiệu được phân loại, chứ không phải trước đó.

Đọc tín hiệu của nhà cung cấp trước khi thử lại

Tài liệu lỗi chính thức của OpenAI sử dụng HTTP 429 cho các yêu cầu được gửi quá nhanh và cũng phân biệt giữa hạn ngạch đã cạn kiệt hoặc giới hạn thanh toán với việc điều chỉnh tốc độ yêu cầu. Hướng dẫn về giới hạn tốc độ của OpenAI khuyến nghị sử dụng backoff lũy thừa ngẫu nhiên và lưu ý rằng các yêu cầu không thành công vẫn được tính vào giới hạn mỗi phút. Điều đó quan trọng vì một vòng lặp thử lại quá tích cực có thể làm cho giới hạn trở nên tồi tệ hơn.

Tài liệu về giới hạn tốc độ của Anthropic mô tả các giới hạn về số yêu cầu mỗi phút, số token đầu vào mỗi phút và số token đầu ra mỗi phút. Cũng tài liệu đó cho biết rằng khi vượt quá giới hạn, hệ thống sẽ trả về lỗi 429 với header retry-after cho biết thời gian cần chờ. Tài liệu lỗi của Anthropic cũng ghi nhận rate_limit_error cho HTTP 429 và overloaded_error cho HTTP 529, những lỗi này nên được xử lý khác nhau trong các báo cáo sự cố.

Tài liệu API Gemini của Google mô tả các giới hạn tốc độ theo các chiều như số yêu cầu mỗi phút, số token mỗi phút, số yêu cầu mỗi ngày và chi tiêu. Phần khắc phục sự cố của Gemini ánh xạ HTTP 429 tới RESOURCE_EXHAUSTED và yêu cầu các nhóm xác minh giới hạn tốc độ, chờ và thử lại, giảm tốc độ hoặc kích thước yêu cầu, hoặc yêu cầu tăng giới hạn tốc độ.

Bài học thực tế rút ra là việc xử lý giới hạn tốc độ AI API cần một định dạng lỗi được chuẩn hóa theo nhà cung cấp:

Đừng ẩn các trường này sau một thông báo "lỗi nhà cung cấp" chung chung. Nếu thông tin duy nhất được lưu trữ là một yêu cầu AI đã thất bại, nhóm không thể điều chỉnh đồng thời, ngân sách, quy tắc dự phòng, hoặc kiểm soát chi tiêu.

Backoff: chỉ thử lại khi thời gian chờ có giới hạn

Backoff là phản ứng an toàn nhất khi yêu cầu vẫn có thể hoàn thành trong ngân sách của luồng công việc và việc thử lại sẽ không tạo ra đầu ra hiển thị trùng lặp. Lớp backoff nên tuân theo ba quy tắc:

1. Tôn trọng Retry-After khi nó có mặt.
2. Sử dụng jitter để không phải mọi worker đều thức dậy cùng một lúc.
3. Giới hạn cả độ trễ và tổng số lần thử.

Trường HTTP Retry-After có thể là một ngày HTTP hoặc một độ trễ tính bằng giây. Hướng dẫn thử lại của Google Cloud khuyến nghị sử dụng backoff lũy thừa bị cắt ngắn (truncated exponential backoff) với jitter cho các lỗi có thể thử lại. Để xử lý giới hạn tốc độ của AI API, hãy kết hợp những ý tưởng đó với một thời hạn của luồng công việc:

function retryDelayMs(response: Response, attempt: number, remainingBudgetMs: number) {
  const header = response.headers.get("retry-after");

  let providerDelayMs: number | null = null;
  if (header) {
    const seconds = Number(header);
    providerDelayMs = Number.isFinite(seconds)
      ? seconds * 1000
      : Math.max(0, Date.parse(header) - Date.now());
  }

  const exponentialCapMs = Math.min(60_000, 500 * 2 ** attempt);
  const jitteredDelayMs = Math.floor(Math.random() * exponentialCapMs);
  const delayMs = providerDelayMs ?? jitteredDelayMs;

  if (delayMs <= 0 || delayMs > remainingBudgetMs) {
    return null;
  }

  return delayMs;
}

Hàm trợ giúp đó cố ý trả về null khi việc thử lại sẽ kéo dài hơn luồng công việc. Trong một yêu cầu hướng tới người dùng, điều đó có thể có nghĩa là một thông báo lỗi lịch sự. Trong một luồng công việc hàng loạt, nó có thể có nghĩa là đưa công việc vào hàng đợi. Trong một luồng công việc tài chính hoặc tuân thủ, nó có thể có nghĩa là dừng lại để chủ sở hữu xem xét.

Backoff cũng nên tính đến các lớp thử lại ẩn. Các lần thử lại của SDK, gateway, hàng đợi, và ứng dụng đều nhân lên. Nếu SDK đã thử lại các lỗi 429 và cấp 500, ứng dụng nên giảm số lần thử của chính nó thay vì chồng thêm một vòng lặp thử lại khác lên trên. Sử dụng hướng dẫn của Flatkey về chiến lược thử lại AI API khi bạn cần một danh sách kiểm tra chỉ dành cho việc thử lại.

Queue: hấp thụ nhu cầu khi công việc có thể chờ đợi

Xếp hàng đợi tốt hơn là thử lại khi yêu cầu hợp lệ nhưng thời điểm hiện tại thì không. Điều này phổ biến đối với việc tóm tắt hàng loạt, trích xuất hàng đêm, các công việc đánh giá, xem xét tài liệu dài, và các tự động hóa không khẩn cấp.

Một chính sách hàng đợi không nên là "thử lại sau mãi mãi." Nó cần một ngân sách:

Hàng đợi cũng là nơi để kiểm soát sự tăng đột biến. Nếu mười worker cùng gặp lỗi 429, hàng đợi nên làm chậm toàn bộ khóa đồng thời, chứ không chỉ mười công việc riêng lẻ. Nếu không, mỗi worker sẽ back off một cách độc lập và làn sóng tiếp theo sẽ lặp lại cùng một sai lầm.

Đối với người dùng Flatkey, đây là nơi định tuyến một khóa và bằng chứng sử dụng trở nên hữu ích về mặt vận hành. Giữ quyết định hàng đợi gắn liền với khóa chủ sở hữu, họ endpoint, model được yêu cầu, model đã phục vụ, và tín hiệu chi phí. Sau đó, nhóm có thể xem xét liệu giới hạn tốc độ đến từ một khách hàng, một tự động hóa, một lớp model, hay một sự tăng đột biến rộng rãi của sản phẩm.

Fallback: chỉ thay đổi tuyến đường khi hợp đồng vẫn còn hiệu lực

Fallback không phải là một kiểu thử lại mạnh hơn. Nó thay đổi một thứ gì đó: nhà cung cấp, model, tuyến đường, chi phí, hồ sơ độ trễ, hành vi công cụ, ranh giới dữ liệu, trạng thái phê duyệt, hoặc chất lượng đầu ra. Do đó, việc xử lý giới hạn tốc độ của AI API nên yêu cầu một hợp đồng fallback rõ ràng.

Sử dụng danh sách kiểm tra này trước khi bật fallback tự động:

Chuyển sang dự phòng (fallback) thường an toàn trước khi bất kỳ đầu ra nào có thể nhìn thấy được xác nhận và rủi ro sau khi đầu ra một phần bắt đầu. Một cuộc trò chuyện hỗ trợ thường có thể hiển thị một lỗi ngắn được kiểm soát một cách gọn gàng hơn là ghép một câu trả lời dự phòng vào giữa một phản hồi đang được truyền trực tiếp (streamed). Nếu streaming là chế độ lỗi chính, hãy kết hợp chính sách này với độ tin cậy của AI API streaming. Một công việc trích xuất có cấu trúc thường có thể thử lại hoặc xếp hàng; một quy trình mua sắm có thể cần phải thất bại đóng (fail closed) vì danh sách mô hình/nhà cung cấp được phê duyệt quan trọng hơn sự tiện lợi.

Kết hợp chính sách này với hướng dẫn của Flatkey về đánh giá mô hình dự phòng khi bạn cần một ma trận phê duyệt lộ trình sâu hơn.

Fail closed: dừng lại khi thử lại có thể tạo ra rủi ro

Thất bại đóng (Failing closed) nghe có vẻ thận trọng, nhưng nó thường là kết quả giới hạn tốc độ rẻ nhất và đáng tin cậy nhất. Dừng lại thay vì thử lại hoặc chuyển sang dự phòng khi:

• Lỗi cho biết đã hết tín dụng, ngân sách hàng tháng, hạn ngạch yêu cầu hàng ngày hoặc các giới hạn dựa trên chi tiêu.
• Retry-After dài hơn yêu cầu của người dùng hoặc thời hạn của công việc.
• Quy trình làm việc đã xác nhận đầu ra một phần.
• Lộ trình dự phòng thay đổi lược đồ, tính khả dụng của công cụ, phương thức, ranh giới dữ liệu hoặc phê duyệt mua sắm.
• Yêu cầu có rủi ro cao: đánh giá tài chính, đánh giá pháp lý, tự động hóa hướng tới khách hàng, dữ liệu được quản lý hoặc các hành động không thể đảo ngược.
• Việc thử lại sẽ nhân đôi một prompt lớn, quy trình công cụ, tạo hình ảnh/video hoặc tác dụng phụ bên ngoài.

Xử lý thất bại đóng vẫn cần một trải nghiệm cho người dùng và người vận hành. Hiển thị một trạng thái lỗi hữu ích, ghi lại nguồn gốc của giới hạn, bảo toàn ID yêu cầu và cho chủ sở hữu biết ngân sách nào đã dừng yêu cầu. Mục tiêu không phải là che giấu thất bại; mục tiêu là dừng công việc không kiểm soát được trong khi vẫn giữ đủ bằng chứng để khắc phục nguyên nhân.

Một chính sách xử lý giới hạn tốc độ AI API thực tế

Bắt đầu với một tệp chính sách nhỏ trước khi viết mã thử lại. Các con số chính xác nên đến từ lưu lượng truy cập sản xuất, nhưng cấu trúc nên tồn tại trước sự cố đầu tiên:

workflow: customer_support_chat
rate_limit:
  classify:
    fields:
      - http_status
      - provider_error_type
      - retry_after_ms
      - limit_dimension
      - requested_model
      - served_model
      - endpoint_family
  backoff:
    max_attempts_total: 2
    respect_retry_after: true
    jitter: full
    max_delay_ms: 30000
    retry_only_before_partial_output: true
  queue:
    enabled_for:
      - batch_summary
      - offline_extraction
      - evaluation_job
    max_queue_age_ms: 900000
    concurrency_key:
      - owner_key
      - endpoint_family
      - requested_model
  fallback:
    allowed_before_first_token: true
    require_equivalent_tools: true
    require_cost_cap: true
    require_data_boundary_match: true
  fail_closed_when:
    - quota_or_spend_exhausted
    - retry_after_exceeds_deadline
    - partial_output_committed
    - fallback_contract_mismatch
    - high_risk_workflow

Mẫu này làm cho các điều kiện dừng trở nên rõ ràng. Nó cũng giúp người đánh giá thấy rằng việc xử lý giới hạn tốc độ AI API không chỉ là một cài đặt SDK; đó là một chính sách về sản phẩm, độ tin cậy và kiểm soát chi phí.

Các trường quan sát cho sự cố giới hạn tốc độ

Một sự cố giới hạn tốc độ chỉ có thể gỡ lỗi được nếu nhật ký có thể trả lời điều gì đã bị giới hạn và ứng dụng đã làm gì tiếp theo.

Trang web công khai hiện tại của Flatkey định vị sản phẩm như một cổng duy nhất để truy cập mô hình, định tuyến, thanh toán, phân tích sử dụng và kiểm soát hoạt động. Ảnh chụp nhanh API giá vào ngày 3 tháng 7 năm 2026 đã trả về success: true, phiên bản giá a42d372ccf0b5dd13ecf71203521f9d2, 45 hàng mô hình, 48 hàng nhà cung cấp và các họ điểm cuối được hỗ trợ bao gồm openai, anthropic, gemini, image-generation, openai-video, và video. Hãy xem những thông tin này là bằng chứng tại thời điểm đó, không phải là tuyên bố về tính khả dụng vĩnh viễn. Luôn xác thực danh mục hiện tại và chạy thử nghiệm định tuyến trước khi triển khai sản phẩm.

Danh sách kiểm tra triển khai

Sử dụng lộ trình triển khai này khi bạn thêm hoặc sửa đổi cách xử lý giới hạn tốc độ AI API:

1. Chọn một quy trình làm việc và chỉ định người chịu trách nhiệm.
2. Chuẩn hóa lỗi của nhà cung cấp thành một định dạng giới hạn tốc độ nội bộ duy nhất.
3. Phân tích cú pháp Retry-After dưới dạng giây trì hoãn hoặc ngày HTTP.
4. Thiết lập backoff có giới hạn và jitter với ngân sách tổng số lần thử.
5. Chuyển công việc không tương tác vào hàng đợi với tuổi tối đa và khóa an toàn (idempotency keys).
6. Xác định các hợp đồng dự phòng theo hình dạng điểm cuối, khả năng của mô hình, chi phí và ranh giới dữ liệu.
7. Xác định các điều kiện fail-closed trước khi bật dự phòng.
8. Thêm nhật ký cho chiều giới hạn, độ trễ thử lại, tuổi hàng đợi, lý do dự phòng và chi phí.
9. Kiểm tra lỗi 429 có và không có Retry-After, tình trạng hết hạn ngạch, lưu lượng truy cập đột biến, đầu ra streaming một phần và quá tải của nhà cung cấp.
10. Xem lại bằng chứng sử dụng và định tuyến trong Flatkey trước khi mở rộng chính sách sang quy trình làm việc tiếp theo.

Cách xử lý giới hạn tốc độ AI API tốt nhất sẽ khiến áp lực về dung lượng trở nên đơn giản. Ứng dụng sẽ đợi khi việc chờ đợi là an toàn, xếp hàng công việc khi có thể đợi, chỉ thay đổi tuyến đường khi hợp đồng vẫn còn hiệu lực và dừng lại khi việc tiếp tục sẽ tạo ra chi phí hoặc rủi ro tiềm ẩn.

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

Xử lý giới hạn tốc độ AI API là gì?

Xử lý giới hạn tốc độ AI API là chính sách và mã nguồn dùng để phân loại các tín hiệu giới hạn tốc độ, tôn trọng gợi ý chờ của nhà cung cấp, áp dụng backoff có giới hạn, xếp hàng công việc khi thích hợp, kiểm soát dự phòng và dừng lại một cách an toàn khi việc thử lại sẽ tạo ra chi phí hoặc rủi ro.

Có nên thử lại mọi lỗi 429 không?

Không. Chỉ thử lại khi yêu cầu vẫn có thể hoàn thành trong ngân sách của quy trình làm việc và lỗi có khả năng là tạm thời. Các trường hợp hết hạn ngạch, chi tiêu, giới hạn hàng ngày, đầu ra một phần và không khớp hợp đồng thường nên được xếp hàng hoặc fail-closed.

Exponential backoff có đủ cho các khối lượng công việc AI không?

Không. Exponential backoff với jitter rất hữu ích, nhưng các khối lượng công việc AI cũng cần nhận biết về token và chi tiêu, ngân sách hàng đợi, hợp đồng dự phòng, bảo vệ đầu ra một phần và khả năng quan sát ở cấp độ yêu cầu.

Khi nào một yêu cầu AI bị giới hạn tốc độ nên chuyển sang mô hình dự phòng?

Chỉ khi tuyến đường dự phòng vẫn giữ được hình dạng điểm cuối, cấp chất lượng, hành vi công cụ, ranh giới dữ liệu và giới hạn chi phí bắt buộc. Việc chuyển sang dự phòng thường nên xảy ra trước khi bắt đầu có đầu ra hiển thị.

Flatkey giúp xử lý giới hạn tốc độ AI API như thế nào?

Flatkey cung cấp cho các nhóm một bề mặt cổng duy nhất để truy cập mô hình được kết nối, định tuyến, thanh toán, phân tích sử dụng và kiểm soát hoạt động. Sử dụng nó để giữ cho các quyết định về giới hạn tốc độ gắn liền với mô hình, họ điểm cuối, khóa chủ sở hữu, bằng chứng định tuyến và đánh giá chi phí.

Bắt đầu với bảng giá Flatkey, chọn một quy trình làm việc, sau đó nhận khóa và kiểm tra chính sách xử lý giới hạn tốc độ AI API của bạn trước khi gửi lưu lượng sản xuất qua đó.