Giải thích giới hạn tốc độ LLM: RPM, TPM và cơ chế thử lại

Giới hạn tốc độ LLM quyết định lượng lưu lượng mà ứng dụng của bạn có thể gửi tới một mô hình trong một khoảng thời gian nhất định. Hai giới hạn mà các kỹ sư thường gặp nhất là RPM (số yêu cầu mỗi phút) và TPM (số token mỗi phút). Một workload có thể vẫn nằm dưới một giới hạn nhưng lại vượt quá giới hạn còn lại.

Sự khác biệt đó rất quan trọng. Nếu bạn coi mọi 429 như một vấn đề chung về số lượng yêu cầu, bạn có thể thêm các cơ chế thử lại làm tăng áp lực token, kéo dài độ trễ và khiến sự cố trở nên tồi tệ hơn. Một thiết kế an toàn cho môi trường production sẽ xác định tài nguyên bị giới hạn trước, rồi mới chọn giữa điều tiết nhịp gửi, xếp hàng, thử lại, giảm token hoặc chuyển hướng sang nơi khác.

Hướng dẫn này giải thích cơ chế hoạt động, cung cấp các công thức lập kế hoạch dung lượng, và bao gồm một mẫu thử lại TypeScript có giới hạn cho các API tương thích với OpenAI.

RPM so với TPM: câu trả lời nhanh

RPM kiểm soát tần suất. TPM kiểm soát thông lượng. Đồng thời kiểm soát công việc diễn ra song song. Chúng có tương tác với nhau, nhưng không thể thay thế cho nhau.

Tại sao một yêu cầu có thể thất bại khi vẫn thấp hơn giới hạn công bố

Một giới hạn được công bố như 600 RPM không nhất thiết có nghĩa là client có thể gửi 600 yêu cầu trong giây đầu tiên của mỗi phút. Các nhà cung cấp thường áp dụng giới hạn bằng cửa sổ trượt hoặc cơ chế kiểu token bucket. Một đợt tăng đột biến ngắn có thể làm cạn dung lượng khả dụng ngay lập tức ngay cả khi phép tính cho cả phút trông có vẻ an toàn.

Các lý do khác khiến 429 có thể xuất hiện sớm bao gồm:

• Giới hạn áp dụng cho một project, tổ chức, tài khoản, họ mô hình hoặc gói dịch vụ thay vì một API key.
• Token đầu vào và đầu ra dùng các bucket riêng biệt.
• Nhiều worker, dịch vụ hoặc người dùng chia sẻ cùng một pool hạn mức.
• Các lần thử lại từ những lần thất bại trước đó đang tiêu thụ cùng một giới hạn.
• Nhà cung cấp đang áp dụng giới hạn tăng tốc hoặc giới hạn bùng phát khi lưu lượng tăng mạnh.
• Một pool dành riêng cho mô hình đã đầy dù một mô hình khác vẫn còn dung lượng.

Đó là lý do ứng dụng không nên suy đoán nguyên nhân chỉ từ bộ đếm yêu cầu của chính nó. Hãy đọc body phản hồi và các header, lưu giữ request ID của nhà cung cấp, và ghi log mô hình, tài khoản, ước tính token, số lần thử, và độ trễ trong hàng đợi.

Công thức dung lượng thực tế

Bắt đầu với hai ngưỡng độc lập.

request_ceiling = RPM × safety_factor

token_ceiling = (TPM × safety_factor) ÷ average_tokens_per_request

safe_requests_per_minute = min(request_ceiling, token_ceiling)

Sử dụng hệ số an toàn nhỏ hơn 1.0—ví dụ 0.7 đến 0.9—để hấp thụ biến thiên token, các lượt thử lại, người dùng dùng chung và mẫu lưu lượng đến không đều.

Ví dụ

Giả sử một cụm mô hình cho phép:

• 1.000 RPM
• 2.000.000 TPM
• 4.000 token tổng trung bình mỗi yêu cầu
• Hệ số an toàn vận hành 80%

request_ceiling = 1,000 × 0.8 = 800 requests/minute

token_ceiling = (2,000,000 × 0.8) ÷ 4,000
              = 400 requests/minute

safe_requests_per_minute = min(800, 400) = 400

TPM là ràng buộc chi phối. Việc thêm nhiều worker hơn sẽ không làm tăng thông lượng bền vững; nó chỉ tạo ra hàng đợi lớn hơn hoặc nhiều phản hồi 429 hơn.

Với hệ thống trực tuyến, hãy chuyển thông lượng thành điểm khởi đầu cho độ đồng thời bằng Định luật Little:

target_concurrency ≈ requests_per_second × average_request_seconds

Nếu tốc độ an toàn là 400 yêu cầu mỗi phút (6,67 mỗi giây) và độ trễ mô hình trung bình là 3 giây, độ đồng thời khởi đầu vào khoảng 20. Hãy tăng headroom cẩn thận, rồi tinh chỉnh theo độ trễ p95 thực tế và phân phối token.

Giới hạn token thường là nút thắt ẩn

Các nhóm thường theo dõi số lượng yêu cầu nhưng bỏ qua khối lượng token. Áp lực TPM tăng khi bạn:

• Thêm nhiều tài liệu truy xuất hơn vào mỗi prompt.
• Giữ lịch sử hội thoại dài.
• Chạy nhiều kết quả hoàn thành ứng viên cho mỗi tác vụ.
• Tăng giới hạn đầu ra.
• Gửi lặp lại cùng một system prompt lớn.
• Khởi chạy các bộ đánh giá song song đối với cùng một hạn mức dự án.

Hãy đo ít nhất bốn giá trị token cho mỗi yêu cầu thành công:

1. Token đầu vào.
2. Token đầu ra.
3. Tổng token.
4. Một p50, p95 và giá trị tối đa theo luồng cuộn cho từng khối lượng công việc và mô hình.

Lập kế hoạch năng lực chỉ dựa trên giá trị trung bình là quá lạc quan. Một bộ lập lịch an toàn hơn sẽ dành trước theo một phần trăm cao hoặc một ước lượng đặc thù cho khối lượng công việc, rồi đối soát mức dự trữ với mức sử dụng thực tế sau khi hoàn tất.

Ý nghĩa của 429 — và điều nó không có nghĩa

HTTP 429 Too Many Requests cho bạn biết máy chủ đã từ chối yêu cầu theo một giới hạn đang áp dụng hoặc chính sách dung lượng. Điều đó không tự động có nghĩa là “ngủ một giây rồi thử lại.”

Phân loại một 429 vào một nhóm vận hành:

Phần thân và các header khác nhau tùy nhà cung cấp. Hãy ưu tiên một tín hiệu Retry-After rõ ràng hoặc tín hiệu đặt lại giới hạn tốc độ nếu được cung cấp. Nếu không, hãy dùng backoff theo cấp số nhân với jitter ngẫu nhiên.

Exponential backoff với jitter

Exponential backoff làm tăng độ trễ sau mỗi lần thử thất bại. Jitter sẽ ngẫu nhiên hóa độ trễ đó để hàng trăm worker không retry cùng một thời điểm.

Một công thức full-jitter phổ biến là:

delay_ms = random(0, min(cap_ms, base_ms × 2^attempt))

Một chính sách retry trong môi trường production cũng cần các giới hạn:

• Số lần thử tối đa: thường là một con số nhỏ, không phải vòng lặp vô hạn.
• Tổng thời gian tối đa đã trôi qua: dừng khi ngân sách độ trễ của bên gọi bị cạn.
• Danh sách trạng thái có thể retry: thường là 429, một số phản hồi 5xx được chọn, và các lỗi mạng an toàn.
• Tín hiệu từ máy chủ: tôn trọng Retry-After khi giá trị đó hợp lệ.
• Hủy bỏ: dừng ngay khi yêu cầu phía trên bị hủy.
• Khả năng quan sát: ghi lại số lần thử, thời gian chờ, trạng thái cuối cùng, và ID yêu cầu của nhà cung cấp.

Các yêu cầu không thành công vẫn có thể tiêu thụ năng lực giới hạn tốc độ. Vì vậy, retry quá mạnh tay có thể kéo dài thời gian bị throttling.

TypeScript: một helper retry có giới hạn

Ví dụ sau sử dụng base URL tương thích OpenAI của Flatkey. Nó chỉ retry trước khi phần thân phản hồi thành công được tiêu thụ và dừng lại khi hết giới hạn số lần thử hoặc tổng ngân sách thời gian.

type ChatRequest = {
  model: string;
  messages: Array<{ role: "system" | "user" | "assistant"; content: string }>;
  max_tokens?: number;
};

const sleep = (milliseconds: number) =>
  new Promise((resolve) => setTimeout(resolve, milliseconds));

function retryAfterMilliseconds(response: Response): number | null {
  const value = response.headers.get("retry-after");
  if (!value) return null;

  const seconds = Number(value);
  if (Number.isFinite(seconds)) return Math.max(0, seconds * 1_000);

  const date = Date.parse(value);
  return Number.isNaN(date) ? null : Math.max(0, date - Date.now());
}

export async function createChatCompletion(
  apiKey: string,
  request: ChatRequest,
  options: { maxAttempts?: number; maxElapsedMs?: number } = {},
) {
  const maxAttempts = options.maxAttempts ?? 4;
  const maxElapsedMs = options.maxElapsedMs ?? 30_000;
  const startedAt = Date.now();

  for (let attempt = 0; attempt < maxAttempts; attempt += 1) {
    const response = await fetch(
      "https://router.flatkey.ai/v1/chat/completions",
      {
        method: "POST",
        headers: {
          Authorization: `Bearer ${apiKey}`,
          "Content-Type": "application/json",
        },
        body: JSON.stringify(request),
      },
    );

    if (response.ok) return response.json();

    const retryable = response.status === 429 || response.status >= 500;
    const finalAttempt = attempt === maxAttempts - 1;
    if (!retryable || finalAttempt) {
      throw new Error(`Yêu cầu LLM thất bại với ${response.status}: ${await response.text()}`);
    }

    const hintedDelay = retryAfterMilliseconds(response);
    const exponentialCap = Math.min(8_000, 500 * 2 ** attempt);
    const jitteredDelay = Math.random() * exponentialCap;
    const delayMs = hintedDelay ?? jitteredDelay;

    if (Date.now() + delayMs - startedAt >= maxElapsedMs) {
      throw new Error("Đã hết ngân sách thử lại LLM");
    }

    await sleep(delayMs);
  }

  throw new Error("Trạng thái thử lại không thể đạt tới");
}

Đối với môi trường sản xuất, hãy thêm thời gian chờ cho yêu cầu, các kiểu lỗi có cấu trúc, số liệu đo lường và tín hiệu hủy của ứng dụng bạn. Nếu thao tác có thể tạo ra tác động bên ngoài — chẳng hạn như gửi email hoặc thực thi một công cụ — hãy làm cho thao tác nghiệp vụ mang tính idempotent trước khi thử lại.

Thử lại, xếp hàng, giảm tải hay định tuyến?

Hãy dùng nguyên nhân, không chỉ riêng mã trạng thái, để chọn cách kiểm soát.

Thử lại

Hãy thử lại khi lỗi chỉ mang tính tạm thời và bên gọi vẫn còn thời gian. Giữ một ngân sách thử lại cho từng yêu cầu và một ngân sách thử lại cấp dịch vụ để sự cố của nhà cung cấp không làm tổng lưu lượng tăng lên nhiều lần.

Xếp hàng

Hãy xếp hàng khi tốc độ đến tạm thời vượt quá tốc độ phục vụ bền vững. Một hàng đợi hữu ích sẽ cung cấp:

• Độ tuổi của mục cũ nhất.
• Thời điểm bắt đầu ước tính.
• Công bằng theo từng tenant.
• Hủy các công việc đã lỗi thời.
• Độ sâu tối đa với hành vi loại bỏ có chủ đích.

Giảm token

Khi TPM là ràng buộc, hãy loại bỏ ngữ cảnh không liên quan, tóm tắt lịch sử, giảm số lượng ứng viên, hạ giới hạn đầu ra, lưu đệm các tiền tố prompt có thể tái sử dụng khi được hỗ trợ, và tách lưu lượng tương tác ngắn khỏi các công việc batch dài.

Chuyển sang nơi khác

Việc chuyển hướng phù hợp khi một mô hình hoặc nhà cung cấp khác đáp ứng cùng hợp đồng và có năng lực khả dụng tốt. Phương án dự phòng phải giữ nguyên các khả năng bắt buộc như đầu ra có cấu trúc, gọi công cụ, độ dài ngữ cảnh, chính sách an toàn và mục tiêu độ trễ. Để có khung triển khai sâu hơn, hãy dùng playbook định tuyến dự phòng API LLM.

Giới hạn tốc độ trong đánh giá mô hình

Điều tiết kém có thể làm vô hiệu hóa một phép đánh giá.

Giả sử mô hình A được kiểm thử với 10 worker trong khi mô hình B được kiểm thử với 100. Nếu mô hình B bị điều tiết nhiều hơn, độ trễ đo được của nó sẽ bao gồm thời gian xếp hàng và độ trễ do thử lại mà mô hình A không gặp. Kết quả có thể mô tả cấu hình bộ kiểm thử của bạn hơn là hiệu năng của mô hình.

Để so sánh một cách đáng tin cậy:

1. Tách riêng độ trễ của mô hình, độ trễ xếp hàng và độ trễ thử lại.
2. Áp dụng cùng một quá trình đến hoặc cùng mức sử dụng đã chuẩn hóa cho mọi nhà cung cấp.
3. Khởi động lưu lượng tăng dần khi nhà cung cấp dùng các cơ chế kiểm soát tăng tốc.
4. Ghi lại số token và số lần thử cho mỗi tác vụ hoàn thành.
5. Báo cáo cả tỷ lệ thành công ở lần thử đầu tiên và tỷ lệ thành công cuối cùng.
6. So sánh chi phí trên mỗi tác vụ được chấp nhận, không chỉ chi phí trên mỗi token.
7. Chạy các bài kiểm tra quá tải tách biệt với các bài đánh giá chất lượng và độ trễ.

Nếu bạn đang đánh giá các nhà cung cấp dựa trên cả độ tin cậy lẫn chi phí, hãy kết hợp quy trình này với so sánh giá API AI.

Kiến trúc giới hạn tốc độ cho môi trường sản xuất

Một đường đi yêu cầu vững chắc thường có năm lớp điều khiển:

1. Điều khiển chấp nhận từ chối hoặc hoãn các công việc không thể đáp ứng thời hạn.
2. Đặt trước token ước tính chi phí hạn ngạch có khả năng phát sinh của yêu cầu.
3. Bộ giới hạn tốc độ điều tiết từng nhà cung cấp, nhóm mô hình, tenant và lớp ưu tiên.
4. Bộ điều khiển thử lại sử dụng ngân sách thử lại có giới hạn cùng jitter.
5. Bộ định tuyến chọn một phương án thay thế tương thích với hợp đồng sau khi ngân sách thử lại hoặc chính sách năng lực yêu cầu chuyển hướng.

client
  → admission control
  → priority queue
  → RPM + token reservation limiter
  → provider/model route
  → bounded retry
  → contract-safe fallback
  → usage and latency logs

Không đặt một vòng lặp thử lại không giới hạn trong mọi worker của ứng dụng. Hãy tập trung hóa chính sách để tất cả bên gọi cùng chia sẻ một cách hiểu về năng lực khả dụng.

Các chỉ số đáng cảnh báo

Theo dõi các chỉ số này theo nhà cung cấp, mô hình, dự án, tuyến, tenant và khối lượng công việc:

• Số yêu cầu mỗi phút và số token mỗi phút.
• Số token ước tính đã đặt trước so với số token thực tế đã dùng.
• Tỷ lệ thành công ở lần thử đầu tiên.
• Số lần thử lại trên mỗi yêu cầu thành công.
• Tỷ lệ 429 theo nguyên nhân đã phân loại.
• Độ sâu hàng đợi và tuổi của mục cũ nhất.
• Thời gian chờ để có năng lực giới hạn tốc độ.
• Độ trễ đầu cuối p50, p95 và p99.
• Tỷ lệ fallback và kết quả fallback.
• Chi phí trên mỗi tác vụ thành công hoặc được chấp nhận.

Cảnh báo chỉ dựa trên tổng số 429 sẽ rất nhiễu. Một tín hiệu tốt hơn là kết hợp tỷ lệ bị giới hạn với tuổi hàng đợi, mức khuếch đại do thử lại và tỷ lệ thất bại cuối cùng.

Các sai lầm thường gặp

Xem RPM như một giới hạn đồng thời

RPM đo số lượt được chấp nhận theo thời gian; đồng thời đo khối lượng công việc đang diễn ra. Các yêu cầu chậm có thể tạo ra mức đồng thời cao dù RPM ở mức vừa phải.

Thử lại mọi phản hồi 429 ngay lập tức

Thử lại ngay sẽ làm các worker đồng bộ với nhau và tiêu tốn thêm năng lực. Hãy tuân theo thời gian của máy chủ khi có và thêm jitter.

Dùng một bộ giới hạn cho mọi mô hình

Các nhà cung cấp có thể dùng các pool riêng hoặc dùng chung. Chính sách theo mô hình cần bám theo phạm vi hạn ngạch được nhà cung cấp tài liệu hóa và các header quan sát được.

Bỏ qua các consumer dùng chung

Một dashboard, job batch và API production có thể dùng chung một hạn ngạch dự án. Hãy dành trước năng lực theo khối lượng công việc và cô lập lưu lượng quan trọng khi có thể.

Thử lại một luồng dang dở

Một khi token đã đến được người dùng, phát lại yêu cầu có thể tạo ra nội dung trùng lặp hoặc các hành động công cụ trùng lặp. Hãy định nghĩa rõ semantics tiếp tục hoặc khởi động lại thay vì âm thầm thử lại.

Cách Flatkey thay đổi mô hình vận hành

Flatkey cung cấp một API key và một base URL tương thích với OpenAI để truy cập trên các nhà cung cấp mô hình được hỗ trợ. Điều đó mang lại cho ứng dụng một bề mặt tích hợp duy nhất, đồng thời vẫn cho phép chính sách định tuyến xem xét mức độ phù hợp của mô hình, năng lực, độ tin cậy và chi phí.

Gateway không loại bỏ các giới hạn ở upstream. Nó giúp dễ triển khai các kiểm soát nhất quán xung quanh chúng: một tích hợp client duy nhất, nhật ký yêu cầu tập trung, và tùy chọn chuyển lưu lượng đủ điều kiện khi một tuyến bị hạn chế. Hãy xem hướng dẫn kiến trúc AI API gateway để hiểu rộng hơn về thiết kế định tuyến, hoặc xem bảng giá Flatkey hiện tại trước khi chọn các tuyến production.

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

Sự khác nhau giữa RPM và TPM là gì?

RPM giới hạn số lượng yêu cầu được chấp nhận theo thời gian. TPM giới hạn số lượng token đầu vào và/hoặc đầu ra được chấp nhận. Các prompt nhỏ thường gây áp lực lên RPM trước; các workload có ngữ cảnh lớn hoặc đầu ra cao thường gây áp lực lên TPM trước.

Tại sao tôi nhận lỗi 429 dù chưa chạm giới hạn RPM?

Nhà cung cấp có thể áp dụng các cửa sổ trượt ngắn hơn, token bucket, hạn ngạch dự án dùng chung, giới hạn token riêng, giới hạn tăng tốc, hoặc các pool theo từng model. Bộ đếm yêu cầu cục bộ của bạn có thể không phản ánh đầy đủ phạm vi hạn ngạch.

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

Không. Hãy thử lại các trường hợp throttling ngắn hạn với ngân sách nhỏ và jitter. Đừng lặp lại việc thử đối với trường hợp hết hạn ngạch hằng ngày, hạn chế thanh toán, hoặc quá tải kéo dài không có thời gian phục hồi.

Exponential backoff có đảm bảo thành công không?

Không. Backoff giúp giảm va chạm và cho năng lực tạm thời thời gian phục hồi. Nó không thể tạo thêm hạn ngạch. Tình trạng cạn kiệt kéo dài đòi hỏi giảm nhu cầu, tăng năng lực, trì hoãn công việc, hoặc dùng tuyến đủ điều kiện khác.

Một yêu cầu LLM nên thử lại bao nhiêu lần?

Không có con số सार्व quát. Hãy đặt số lần thử dựa trên ngân sách độ trễ mà người dùng nhìn thấy và chế độ lỗi. Nhiều ứng dụng tương tác chỉ nên cho phép vài lần thử ngắn trước khi báo lỗi hoặc chuyển sang nơi khác; các job offline có thể chấp nhận hàng đợi dài hơn.

Các lần thử lại có được tính vào giới hạn tốc độ không?

Có thể. Nhà cung cấp có thể tính các lần thử không thành công vào giới hạn đang hoạt động, vì vậy việc khuếch đại do thử lại phải được giám sát và giới hạn.

Danh sách kiểm tra cuối cùng

• Mô hình hóa RPM, TPM, giới hạn hằng ngày và đồng thời một cách riêng biệt.
• Tính năng lực từ giá trị nhỏ nhất giữa trần theo yêu cầu và trần theo token.
• Vận hành thấp hơn mức tối đa công bố với một hệ số an toàn.
• Sử dụng hàng đợi và điều tiết nhịp cho tải kéo dài.
• Tôn trọng Retry-After và dùng exponential backoff với jitter.
• Giới hạn số lần thử và tổng thời gian thử lại.
• Không tự động phát lại các luồng chưa hoàn tất hoặc các side effect.
• Chỉ định tuyến tới các model bảo toàn contract bắt buộc.
• Tách độ trễ hàng đợi và retry khỏi độ trễ của model trong các đánh giá.
• Cảnh báo về khuếch đại do thử lại và độ tuổi hàng đợi, không chỉ dựa trên số đếm 429 thô.

Giới hạn tốc độ trước hết là một bài toán lập kế hoạch năng lực, sau đó mới là bài toán thử lại. Khi bạn đo riêng tần suất yêu cầu, thông lượng token, đồng thời và khuếch đại do thử lại, các lỗi 429 sẽ trở thành tín hiệu có thể hành động thay vì tiếng ồn sản xuất khó đoán.