Batas Rate GPT Image 2 di 2026: Yang Perlu Diketahui para Builder

Hei, semuanya. Ini Dora. Seorang teman di tim produk beranggotakan 3 orang meluncurkan fitur GPT Image 2 pada awal Mei. Peluncuran terbatas, ~200 pengguna diundang. Dalam 90 menit, fitur tersebut sudah rusak — bukan karena modelnya gagal, tetapi karena mereka berada di Tier 2 dan lonjakan dari para pengguna tersebut (rata-rata masing-masing menghasilkan 3–5 gambar) menyentuh batas 20 IPM pada sore pertama mereka.

Itulah masalah dengan rate limit GPT Image 2: batasan itu tidak terasa seperti kendala sampai benar-benar menjadi kendala. Angka tier dalam tabel dokumentasi terlihat abstrak. Menjadi konkret pada saat kedalaman antrean Anda melampaui kapasitas yang bisa dikuras tier tersebut per menit. Tulisan ini ditujukan untuk tim yang memasukkan GPT Image 2 ke dalam produk nyata, bukan untuk orang yang membandingkan prompt tunggal — rate limit OpenAI image api muncul secara berbeda dalam load test dibandingkan saat pengembangan.

Disclaimer: Saya menulis tentang infrastruktur agen dan gambar untuk WaveSpeedAI. Saya membahas pertanyaan evaluasi model dalam postingan sebelumnya — apakah GPT Image 2 cocok untuk alur kerja Anda sama sekali. Postingan ini mengasumsikan Anda sudah memutuskan bahwa itu cocok, dan sekarang Anda mencari tahu apakah ia bisa bertahan menghadapi traffic Anda yang sebenarnya.

Seperti Apa Rate Limit GPT Image 2 di Tahun 2026

Berdasarkan dokumentasi rate limits OpenAI dan halaman model GPT Image 2, model ini diukur dalam dua dimensi: TPM (token per menit, menghitung token input/output gambar dan teks) dan IPM (gambar per menit, batas yang lebih ketat untuk sebagian besar alur kerja).

Struktur IPM dan TPM berbasis tier

Ini adalah batas GPT Image 2 yang dipublikasikan per April 2026. Tier gratis: tidak didukung.

Tier	TPM	IPM	Pengeluaran kualifikasi perkiraan
Tier 1	100.000	5	$5 dibayar
Tier 2	250.000	20	$50 dibayar + 7 hari
Tier 3	800.000	50	$100 dibayar + 7 hari
Tier 4	3.000.000	150	$250 dibayar + 14 hari
Tier 5	8.000.000	250	$1.000 dibayar + 30 hari

Dua hal yang perlu diperhatikan. Tier bersifat di level organisasi, bukan per proyek atau per API key — setiap proyek berbagi anggaran GPT Image 2 ipm yang sama. OpenAI dapat merevisi angka-angka ini tanpa peringatan, sehingga tabel di atas adalah acuan perencanaan. Konfirmasi dengan dasbor batas akun Anda sebelum mengambil keputusan arsitektur.

Apa arti batasan ini dalam praktik

Batas 5 IPM Tier 1 berarti satu gambar setiap 12 detik secara berkelanjutan. Itu cukup untuk pengembangan solo dan prototipe kecil. Tidak cukup untuk fitur yang menghadap publik dengan konkurensi sedang. Batas 250 IPM Tier 5 terdengar tinggi sampai Anda melakukan perhitungan: 250 gambar/menit × 60 menit = 15.000 gambar/jam. Jika tweet peluncuran Anda mendatangkan 5.000 pendaftaran di jam pertama dan setiap pengguna menghasilkan satu gambar, Anda sudah berada di 33% kapasitas dengan asumsi distribusi sempurna — yang tidak pernah terjadi.

Mode kegagalan yang lebih parah adalah traffic yang melonjak secara tiba-tiba. Dokumentasi OpenAI mencatat bahwa batas diterapkan dalam jendela waktu yang lebih pendek dari satu menit. 20 IPM tidak berarti Anda bisa mengirim 20 dalam detik pertama dan istirahat selama 59 detik. Kirim 5 dalam 2 detik dan Anda akan di-throttle meskipun rata-rata menit Anda jauh di bawah batas.

Bagaimana Rate Limit Mempengaruhi Perencanaan Produksi

Evaluasi model membutuhkan dua minggu. Infrastruktur untuk membuatnya tetap berjalan di bawah beban nyata membutuhkan dua minggu lagi, minimal. Sebagian besar tim meremehkan hal ini.

Desain antrean, batching, dan keputusan retry

Tiga lapisan bertumpuk di sini. Sebagian besar tim hanya membangun dua.

Pertama: pembatasan rate di sisi klien. Batasi permintaan yang sedang berjalan secara bersamaan hingga ~80% dari IPM tier Anda, didistribusikan sepanjang menit. Jika Anda berada di Tier 3 (50 IPM), itu sekitar ~40 gambar secara bersamaan yang berkelanjutan, diantrean di belakangnya.

Kedua: retry dengan exponential backoff. OpenAI cookbook merekomendasikan jittered exponential backoff pada 429. Pola standar: tunggu 1d, 2d, 4d, 8d dengan jitter acak, berhenti setelah 6 percobaan. Wajib dilakukan. Retry dalam loop ketat pada 429 akan membuat akun Anda ditandai.

Ketiga — yang dilewati oleh tim — adalah kontrol bentuk permintaan. Tidak setiap gambar membutuhkan quality: high. Tidak setiap alur kerja membutuhkan respons sinkron. Batch API OpenAI memiliki kumpulan kuota terpisah dan harga 50%, dengan SLA 24 jam. Untuk regenerasi thumbnail malam, batch adalah alat yang tepat. Untuk generasi tunggal yang menghadap pengguna, tidak. Sebagian besar tim memiliki campuran keduanya dan mengarahkannya seolah-olah keduanya sama. Perbedaan antara “rate limit adalah masalah” dan “rate limit adalah latar belakang” adalah apakah Anda telah mengarahkan pekerjaan async keluar dari kumpulan IPM sinkron.

Ekspektasi tim untuk waktu penyelesaian dan lonjakan

Inilah bagian yang tidak didokumentasikan siapa pun. Ini adalah percakapan dengan produk dan operasional, bukan dengan model.

Di Tier 2 (20 IPM), latensi p50 kira-kira terikat pada model — 8–25 detik tergantung pada kualitas dan mode penalaran. Tetapi p99 di bawah beban berkelanjutan mencakup waktu tunggu antrean. Seorang pengguna yang mengirimkan permintaan ke-21 dalam satu menit menunggu 60 detik, bukan 12. “Gambar dihasilkan dalam 15 detik” hanya benar ketika tidak ada orang lain yang menghasilkan gambar.

Untuk kampanye pemasaran dan peluncuran, pertanyaan perencanaan bukan tentang throughput rata-rata — ini tentang throughput puncak per menit. Jika Anda memperkirakan traffic 3× normal selama 4 jam setelah kampanye diluncurkan, tier Anda harus mampu menyerap 3× tersebut tanpa rusak, atau Anda perlu melakukan pre-generate, atau Anda memerlukan fallback. Pilih satu sebelum peluncuran. Memilih saat peluncuran tidak pernah berjalan dengan baik.

Ketika Rate Limit Menjadi Masalah Produk

Ada ambang batas di mana throughput GPT Image 2 berhenti menjadi pertanyaan infrastruktur dan menjadi pertanyaan produk. Sinyalnya konsisten: ketika antrean retry Anda cukup dalam sehingga terlihat oleh pengguna, Anda memiliki masalah produk, bukan masalah infrastruktur.

Tanda-tanda bahwa Anda telah melampaui ambang tersebut:

Variasi latensi yang menghadap pengguna melebihi toleransi Anda (misalnya, 80% permintaan selesai dalam 20 detik, 5% membutuhkan 90 detik+ karena diantrean setelah lonjakan)
Anda mempersempit cakupan fitur untuk tetap berada di bawah tier — “tidak ada batch generation di UI” adalah pertanda
Satu aktor jahat atau satu tautan populer dapat memenuhi menit Anda dan menurunkan kualitas layanan semua orang
Aplikasi Tier 5 Anda membutuhkan waktu lebih dari 30 hari sementara peluncuran Anda dalam 14 hari

Jawaban jujur ketika Anda mencapai titik ini: satu provider memiliki batas operasional. Bahkan Tier 5 adalah batas. Tim yang menjalankan volume serius mulai mempertimbangkan pre-generation dan caching, perutean model ke alternatif yang menekan tier lebih rendah untuk jalur non-kritis, atau agregasi/fallback melalui lapisan yang mengumpulkan kapasitas dari berbagai provider. Masing-masing menambah permukaan rekayasa. Masing-masing lebih murah daripada insiden latensi publik.

Saya berhenti sejenak saat menulis bagian ini, karena framing WaveSpeed di sini mudah tergelincir. Pendapat jujur: agregasi adalah salah satu opsi di antara beberapa opsi. Pre-generation dan caching seringkali menyelesaikan lebih banyak masalah daripada yang dihargai orang, dan biayanya lebih rendah. Apakah Anda memerlukan lapisan multi-provider bergantung pada apakah beban kerja Anda benar-benar melebihi Tier 5, atau apakah Anda belum mengoptimalkan. Diagnosa sebelum merancang arsitektur.

Apa yang Harus Dipantau Builder Sebelum Meningkatkan Skala

Tiga hal, dalam urutan ini.

IPM nyata saat puncak, bukan rata-rata. Log header x-ratelimit-remaining-images dan x-ratelimit-remaining-tokens pada setiap respons. Perhatikan minimum, bukan rata-rata. Jika sisa pada menit puncak turun di bawah 20% dari tier, Anda hanya satu lonjakan traffic lagi dari 429.

Distribusi mode kegagalan. Lacak 429 sebagai persentase dari total permintaan, dipecah berdasarkan jam dalam sehari. Tingkat 429 sebesar 0,5% terdengar baik-baik saja sampai Anda menemukan bahwa angkanya 8% selama jendela email pemasaran. Metrik yang di-bucket berdasarkan waktu menangkap ini; metrik agregat tidak.

Waktu-hingga-upgrade-tier. Tier 5 memerlukan pengeluaran $1.000 ditambah 30 hari usia akun. Jika proyeksi Anda mencapai kebutuhan Tier 5 dalam 2 bulan, mulailah pengeluaran sekarang, atau terima bahwa 30 hari pertama Anda dalam skala besar akan terbatas kapasitasnya.

Di sinilah data saya berakhir — saya telah mengoperasikan GPT Image 2 di Tier 2 dan Tier 3, bukan Tier 5. Tim Tier 5 melaporkan bahwa dinamika berubah lagi, di mana batasnya berhenti menjadi IPM dan mulai menjadi efisiensi bentuk permintaan.

FAQ

Apa saja rate limit GPT Image 2 per tier?

Berdasarkan dokumentasi OpenAI per April 2026: Tier 1 adalah 100.000 TPM / 5 IPM, Tier 2 adalah 250.000 / 20, Tier 3 adalah 800.000 / 50, Tier 4 adalah 3.000.000 / 150, Tier 5 adalah 8.000.000 / 250. Tier gratis tidak didukung. Batas bersifat di level organisasi, dibagi di seluruh proyek. OpenAI dapat merevisi ini, jadi verifikasi di dasbor akun Anda.

Bagaimana rate limit mempengaruhi alur kerja gambar dalam skala besar?

Tiga hal: desain antrean (Anda memerlukan pembatasan di sisi klien sebelum milik OpenAI), distribusi latensi (p99 mencakup waktu tunggu antrean, bukan hanya waktu model), dan roadmap (Anda mungkin menunda fitur yang menghasilkan lonjakan yang tidak bisa Anda serap). Pola umum: tim membangun untuk beban rata-rata, kemudian menemukan bahwa beban puncak menentukan pengalaman pengguna.

Apa yang harus dilakukan tim sebelum meluncurkan fitur volume tinggi?

Empat langkah. Perkirakan volume generasi puncak per menit, bukan rata-rata harian. Verifikasi tier Anda mencukupi dengan headroom ~30%. Implementasikan exponential backoff dengan jitter dan circuit breaker. Tentukan fallback untuk kasus di mana Anda menghabiskan kapasitas — pre-generation, model alternatif, atau degradasi yang baik. Mode kegagalan pada hari peluncuran yang tidak bisa Anda perbaiki adalah yang tidak Anda rencanakan.

Kapan satu provider tidak cukup secara operasional?

Ketika permintaan puncak per menit secara konsisten melebihi kapasitas Tier 5 provider tunggal, ketika SLA Anda tidak bisa mentolerir jendela gangguan satu provider, atau ketika variasi latensi dari waktu tunggu antrean tetap terlihat oleh pengguna meskipun sudah dioptimalkan. Sebagian besar tim tidak mencapai ini. Tim yang mencapainya — biasanya produk konsumen dengan pola viral atau pipeline enterprise dengan SLA ketat — menambahkan pre-generation, perutean multi-provider, atau keduanya. Keputusan harus berasal dari log beban puncak Anda, bukan dari halaman pemasaran vendor.

Kesimpulan

Ringkasan singkat tentang rate limit GPT Image 2: Tier 1 dimulai dari 5 IPM, Tier 5 dibatasi 250 IPM, dan traffic yang melonjak tiba-tiba mencapai batas ini jauh lebih cepat dari yang disarankan matematika steady-state. Ringkasan yang lebih panjang: rate limit adalah kendala desain operasional, bukan catatan kaki dokumentasi. Mereka membentuk antrean, SLA, cakupan fitur, dan rencana peluncuran Anda.

Pertanyaan yang tepat bagi builder bukan “tier berapa yang saya gunakan” — melainkan “seperti apa menit puncak saya, dan apakah tier saya menyerapnya dengan margin.” Sebagian besar tim menemukan jawabannya dengan cara yang salah, setelah peluncuran sudah berjalan.

Akan ada lagi setelah saya mengoperasikan GPT Image 2 di Tier 5. Angka-angka di atas adalah milik OpenAI, framing adalah milik saya, dan kebijakan kapasitas diperbarui lebih cepat dari postingan blog.

Postingan Sebelumnya: