Penjelasan Batas Rate LLM: RPM, TPM, dan Retry

Batas rate LLM menentukan seberapa banyak traffic yang dapat dikirim aplikasi Anda ke sebuah model dalam satu jendela waktu. Dua batas yang paling sering ditemui engineer adalah RPM (requests per minute) dan TPM (tokens per minute). Satu workload bisa berada di bawah salah satunya, tetapi tetap melampaui yang lain.

Perbedaan itu penting. Jika Anda menganggap setiap 429 sebagai masalah umum jumlah request, Anda mungkin menambahkan retry yang meningkatkan tekanan token, menaikkan latensi, dan membuat gangguan makin buruk. Desain yang aman untuk produksi mengidentifikasi resource yang terbatasi terlebih dahulu, lalu memilih di antara pacing, antrean, retry, pengurangan token, atau routing ke tempat lain.

Panduan ini menjelaskan mekanismenya, menyediakan formula perencanaan kapasitas, dan menyertakan pola retry TypeScript yang dibatasi untuk API yang kompatibel dengan OpenAI.

RPM vs. TPM: jawaban singkatnya

RPM mengontrol frekuensi. TPM mengontrol throughput. Concurrency mengontrol pekerjaan simultan. Ketiganya saling berinteraksi, tetapi tidak bisa saling menggantikan.

Mengapa request bisa gagal di bawah limit utama

Limit yang dipublikasikan seperti 600 RPM tidak selalu berarti client dapat mengirim 600 request pada detik pertama setiap menit. Penyedia umumnya menerapkan limit dengan rolling window atau kontrol bergaya token bucket. Burst singkat dapat menghabiskan kapasitas yang tersedia saat itu juga, meskipun perhitungan untuk satu menit penuh terlihat aman.

Alasan lain 429 dapat muncul lebih awal meliputi:

• Limit berlaku untuk project, organisasi, akun, family model, atau tier layanan, bukan untuk satu API key.
• Token input dan output menggunakan bucket terpisah.
• Beberapa worker, service, atau pengguna berbagi pool kuota yang sama.
• Retry dari kegagalan sebelumnya menghabiskan limit yang sama.
• Penyedia menerapkan limit akselerasi atau burst saat traffic meningkat tajam.
• Pool khusus model penuh meskipun model lain masih memiliki kapasitas.

Karena itu aplikasi tidak boleh menyimpulkan penyebabnya hanya dari penghitung request miliknya sendiri. Baca body dan header respons, simpan request ID dari penyedia, dan log model, akun, estimasi token, nomor percobaan, serta queue delay.

Formula kapasitas praktis

Mulailah dengan dua plafon yang independen.

request_ceiling = RPM × safety_factor

token_ceiling = (TPM × safety_factor) ÷ average_tokens_per_request

safe_requests_per_minute = min(request_ceiling, token_ceiling)

Gunakan faktor keamanan di bawah 1.0—misalnya 0.7 hingga 0.9—untuk menyerap variasi token, retry, konsumen bersama, dan pola kedatangan yang tidak merata.

Contoh

Misalkan sebuah kumpulan model mengizinkan:

• 1.000 RPM
• 2.000.000 TPM
• 4.000 rata-rata total token per request
• Faktor keamanan operasional 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 adalah batas yang mengikat. Menambahkan lebih banyak worker tidak akan meningkatkan throughput yang berkelanjutan; itu hanya akan menciptakan antrean yang lebih besar atau lebih banyak respons 429.

Untuk sistem online, ubah throughput menjadi titik awal concurrency dengan Hukum Little:

target_concurrency ≈ requests_per_second × average_request_seconds

Jika laju aman adalah 400 request per menit (6,67 per detik) dan latensi rata-rata model adalah 3 detik, concurrency awalnya sekitar 20. Tambahkan headroom dengan hati-hati, lalu sesuaikan berdasarkan latensi p95 nyata dan distribusi token.

Batas token sering kali menjadi bottleneck yang tersembunyi

Tim sering memantau jumlah request tetapi mengabaikan volume token. Tekanan TPM meningkat ketika Anda:

• Menambahkan lebih banyak dokumen hasil retrieval ke setiap prompt.
• Menyimpan riwayat percakapan yang panjang.
• Menjalankan beberapa completion kandidat per tugas.
• Meningkatkan batas output.
• Mengirim prompt sistem besar yang sama berulang kali.
• Meluncurkan suite evaluasi paralel terhadap satu kuota proyek.

Ukur setidaknya empat nilai token per request yang berhasil:

1. Token input.
2. Token output.
3. Total token.
4. p50, p95, dan maksimum bergerak berdasarkan workload dan model.

Perencanaan kapasitas hanya dengan rata-rata bersifat terlalu optimistis. Penjadwal yang lebih aman mencadangkan berdasarkan persentil tinggi atau estimasi spesifik workload, lalu merekonsiliasi reservasi tersebut dengan penggunaan aktual setelah selesai.

Apa arti 429—dan apa yang tidak

HTTP 429 Too Many Requests memberi tahu Anda bahwa server menolak request di bawah batas aktif atau kebijakan kapasitas. Itu tidak otomatis berarti “tidur satu detik lalu coba lagi.”

Klasifikasikan 429 ke dalam kategori operasional:

Body dan header berbeda-beda حسب penyedia. Utamakan Retry-After yang eksplisit atau sinyal reset rate-limit jika disediakan. Jika tidak, gunakan exponential backoff dengan random jitter.

Exponential backoff dengan jitter

Exponential backoff meningkatkan jeda setelah setiap percobaan yang gagal. Jitter mengacak jeda tersebut agar ratusan worker tidak retry pada saat yang sama.

Salah satu formula full-jitter yang umum adalah:

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

Kebijakan retry untuk production juga membutuhkan batasan:

• Maximum attempts: biasanya hanya sejumlah kecil, bukan loop tak terbatas.
• Maximum elapsed time: berhenti saat anggaran latensi pemanggil habis.
• Retryable status list: umumnya 429, respons 5xx tertentu, dan kegagalan jaringan yang aman.
• Server hints: patuhi Retry-After ketika valid.
• Cancellation: berhenti segera saat permintaan upstream dibatalkan.
• Observability: catat jumlah percobaan, waktu tunggu, status akhir, dan provider request ID.

Permintaan yang tidak berhasil masih dapat mengonsumsi kapasitas rate-limit. Karena itu, retry yang agresif dapat memperpanjang periode throttling.

TypeScript: helper retry terbatas

Contoh berikut menggunakan base URL Flatkey yang kompatibel dengan OpenAI. Contoh ini hanya retry sebelum body respons yang sukses dikonsumsi dan berhenti saat batas percobaan atau anggaran waktu total habis.

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(`Permintaan LLM gagal dengan ${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("Anggaran retry LLM habis");
    }

    await sleep(delayMs);
  }

  throw new Error("Keadaan retry tidak dapat dijangkau");
}

Untuk penggunaan produksi, tambahkan timeout permintaan, tipe error terstruktur, metrik, dan sinyal pembatalan aplikasi Anda. Jika operasi dapat menimbulkan side effect eksternal—seperti mengirim email atau mengeksekusi tool—buat operasi bisnis menjadi idempotent sebelum mencoba ulang.

Retry, antre, kurangi, atau alihkan?

Gunakan penyebabnya, bukan status code saja, untuk memilih kontrol.

Retry

Gunakan retry ketika kegagalan bersifat transient dan pemanggil masih punya waktu. Simpan anggaran retry per permintaan dan anggaran retry tingkat layanan agar insiden pada provider tidak menggandakan lalu lintas total.

Queue

Gunakan queue ketika laju kedatangan sementara melebihi laju layanan yang berkelanjutan. Queue yang berguna menyediakan:

• Usia item tertua.
• Perkiraan waktu mulai.
• Keadilan per tenant.
• Pembatalan untuk job yang sudah usang.
• Ukuran maksimum dengan perilaku shedding yang eksplisit.

Kurangi token

Ketika TPM menjadi batas, hapus konteks yang tidak relevan, ringkas riwayat, kurangi jumlah kandidat, turunkan batas output, cache prefix prompt yang dapat digunakan kembali jika didukung, dan pisahkan traffic interaktif singkat dari job batch yang panjang.

Arahkan ke tempat lain

Routing sesuai ketika model atau provider lain memenuhi kontrak yang sama dan memiliki kapasitas yang sehat. Fallback harus mempertahankan kapabilitas yang diperlukan seperti output terstruktur, pemanggilan tool, panjang konteks, kebijakan keamanan, dan target latensi. Untuk kerangka implementasi yang lebih mendalam, gunakan LLM API fallback routing playbook.

Batas rate dalam evaluasi model

Throttling yang buruk dapat membatalkan sebuah evaluasi.

Misalkan model A diuji dengan 10 worker sementara model B diuji dengan 100. Jika model B menghabiskan lebih banyak waktu dalam keadaan throttled, latensi yang diukurnya mencakup waktu antre dan delay retry yang tidak pernah dihadapi model A. Hasilnya mungkin menggambarkan konfigurasi harness Anda, bukan performa model.

Untuk perbandingan yang dapat dipertanggungjawabkan:

1. Pisahkan latensi model, delay antre, dan delay retry.
2. Terapkan proses kedatangan yang sama atau tingkat utilisasi ternormalisasi ke setiap provider.
3. Panaskan traffic secara bertahap ketika provider menggunakan kontrol akselerasi.
4. Rekam token dan percobaan per tugas yang selesai.
5. Laporkan tingkat keberhasilan pada percobaan pertama dan tingkat keberhasilan akhir.
6. Bandingkan biaya per tugas yang diterima, bukan hanya biaya per token.
7. Jalankan uji overload secara terpisah dari benchmark kualitas dan latensi.

Jika Anda mengevaluasi penyedia berdasarkan keandalan dan biaya, padukan proses ini dengan perbandingan harga API AI.

Arsitektur rate limit untuk produksi

Jalur request yang andal biasanya memiliki lima lapisan kontrol:

1. Admission control menolak atau menunda pekerjaan yang tidak dapat memenuhi tenggat waktunya.
2. Token reservation memperkirakan biaya kuota yang mungkin diperlukan untuk request.
3. Rate limiter mengatur laju setiap provider, pool model, tenant, dan kelas prioritas.
4. Retry controller menghabiskan anggaran retry yang terbatas dengan jitter.
5. Router memilih alternatif yang kompatibel dengan kontrak setelah anggaran retry atau kebijakan kapasitas menyatakan perlu pindah.

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

Jangan menempatkan loop retry tak terbatas di setiap worker aplikasi. Sentralisasikan kebijakan agar semua pemanggil memiliki pemahaman yang sama tentang kapasitas yang tersedia.

Metrik yang layak untuk di-alert

Lacak metrik ini per provider, model, project, route, tenant, dan workload:

• Request per menit dan token per menit.
• Token yang diperkirakan dipesan versus token aktual yang digunakan.
• Tingkat keberhasilan pada percobaan pertama.
• Jumlah retry per request yang berhasil.
• Tingkat 429 berdasarkan penyebab yang diklasifikasikan.
• Kedalaman antrean dan usia item tertua.
• Waktu yang dihabiskan menunggu kapasitas rate.
• Latensi end-to-end p50, p95, dan p99.
• Tingkat fallback dan hasil fallback.
• Biaya per tugas yang berhasil atau diterima.

Alert pada total jumlah 429 saja bersifat bising. Sinyal yang lebih baik menggabungkan tingkat throttling dengan usia antrean, amplifikasi retry, dan tingkat kegagalan akhir.

Kesalahan umum

Menganggap RPM sebagai batas concurrency

RPM mengukur admissions dari waktu ke waktu; concurrency mengukur pekerjaan yang sedang berjalan. Request yang lambat dapat menciptakan concurrency tinggi pada RPM yang moderat.

Men-retry setiap 429 secara langsung

Retry langsung menyinkronkan worker dan menghabiskan lebih banyak kapasitas. Patuhi timing server jika tersedia dan tambahkan jitter.

Menggunakan satu limiter untuk setiap model

Provider dapat menggunakan pool yang terpisah atau bersama. Kebijakan khusus model harus mengikuti cakupan kuota yang didokumentasikan oleh provider dan header yang diamati.

Mengabaikan konsumen bersama

Dashboard, job batch, dan API produksi dapat berbagi satu kuota project. Cadangkan kapasitas per workload dan isolasi traffic kritis bila memungkinkan.

Men-retry stream parsial

Begitu token sudah sampai ke pengguna, mengulang request dapat menggandakan konten atau tindakan tool. Definisikan semantik kelanjutan atau mulai ulang secara eksplisit, alih-alih men-retry secara diam-diam.

Cara Flatkey mengubah model operasional

Flatkey menyediakan satu API key dan base URL yang kompatibel dengan OpenAI untuk akses lintas provider model yang didukung. Itu memberi aplikasi satu permukaan integrasi sambil tetap memungkinkan kebijakan routing mempertimbangkan kecocokan model, kapasitas, keandalan, dan biaya.

Gateway tidak menghapus batasan upstream. Gateway mempermudah penerapan kontrol yang konsisten di sekelilingnya: satu integrasi klien, log permintaan terpusat, dan opsi untuk memindahkan traffic yang memenuhi syarat ketika suatu route dibatasi. Tinjau panduan arsitektur AI API gateway untuk desain routing yang lebih luas, atau lihat harga Flatkey saat ini sebelum memilih route produksi.

FAQ

Apa perbedaan antara RPM dan TPM?

RPM membatasi berapa banyak request yang diterima dari waktu ke waktu. TPM membatasi berapa banyak token input dan/atau output yang diterima. Prompt kecil biasanya memberi tekanan pada RPM terlebih dahulu; workload dengan konteks besar atau output tinggi sering kali memberi tekanan pada TPM terlebih dahulu.

Mengapa saya mendapat error 429 di bawah batas RPM saya?

Penyedia mungkin menerapkan rolling window yang lebih pendek, token bucket, kuota proyek bersama, batas token terpisah, batas akselerasi, atau pool khusus model. Penghitung request lokal Anda mungkin tidak merepresentasikan cakupan kuota secara penuh.

Haruskah saya retry setiap 429?

Tidak. Retry throttling yang bersifat singkat dengan anggaran kecil dan jitter. Jangan berulang kali mencoba lagi saat kuota harian habis, ada pembatasan billing, atau overload berkepanjangan yang tidak memiliki waktu untuk pulih.

Apakah exponential backoff menjamin keberhasilan?

Tidak. Backoff mengurangi collision dan memberi waktu kapasitas sementara untuk pulih. Backoff tidak dapat menciptakan kuota. Kehabisan yang persisten memerlukan penurunan permintaan, kapasitas lebih besar, penundaan pekerjaan, atau route lain yang memenuhi syarat.

Berapa kali retry yang sebaiknya digunakan oleh request LLM?

Tidak ada angka universal. Tentukan percobaan berdasarkan anggaran latensi yang terlihat oleh pengguna dan mode kegagalan. Banyak aplikasi interaktif sebaiknya hanya mengizinkan beberapa percobaan singkat sebelum gagal atau dialihkan ke tempat lain; pekerjaan offline dapat mentoleransi antrean yang lebih lama.

Apakah retry dihitung terhadap rate limit?

Ya, bisa. Penyedia dapat menghitung percobaan yang gagal terhadap batas aktif, sehingga amplifikasi retry harus dipantau dan dibatasi.

Daftar periksa akhir

• Modelkan RPM, TPM, batas harian, dan concurrency secara terpisah.
• Hitung kapasitas dari nilai minimum antara batas request dan token.
• Beroperasi di bawah maksimum yang dipublikasikan dengan faktor keamanan.
• Gunakan antrean dan pacing untuk beban yang berkelanjutan.
• Hormati Retry-After dan gunakan exponential backoff dengan jitter.
• Batasi jumlah percobaan dan total waktu retry.
• Jangan secara otomatis memutar ulang stream parsial atau efek samping.
• Routing hanya ke model yang mempertahankan kontrak yang diperlukan.
• Pisahkan penundaan antrean dan retry dari latensi model dalam evaluasi.
• Pasang alert pada amplifikasi retry dan usia antrean, bukan hanya jumlah 429 mentah.

Batas rate adalah masalah perencanaan kapasitas sebelum menjadi masalah retry. Setelah Anda mengukur frekuensi request, throughput token, concurrency, dan amplifikasi retry secara independen, error 429 menjadi sinyal yang dapat ditindaklanjuti, bukan noise produksi yang tak terduga.