Cara Membaiki Ralat 429 dan Had Kadar API Meshy

Jika integrasi anda menghadapi ralat 429, RateLimitExceeded, atau NoMoreConcurrentTasks semasa memanggil API Meshy, panduan ini menerangkan mengapa had-had ini wujud dan cara mereka bentuk integrasi anda agar berfungsi dalam had tersebut.

API Meshy terletak di hadapan kuasa pengiraan GPU berkongsi yang digunakan untuk menjana model 3D, tekstur dan aset berkaitan. Had kadar dan had serentak melindungi infrastruktur berkongsi tersebut supaya kualiti penjanaan dan masa siap kekal konsisten untuk setiap pengguna di platform ini. Setiap akaun, berdasarkan pelan semasanya, mempunyai bilangan maksimum permintaan yang boleh dibuat dalam tempoh masa tertentu dan bilangan maksimum tugasan penjanaan yang boleh berjalan (dalam baris gilir atau sedang diproses) pada satu masa.

Terdapat dua had berbeza, dan ia gagal secara berbeza:

• Had kadar permintaan (429 / RateLimitExceeded): ini mengehadkan bilangan panggilan API (cth. penciptaan tugasan, tinjauan status) yang boleh anda buat setiap minit. Melebihinya bermakna anda memanggil API terlalu kerap, tanpa mengira berapa banyak tugasan yang sebenarnya sedang berjalan.

• Had serentak / baris gilir (NoMoreConcurrentTasks): ini mengehadkan bilangan tugasan penjanaan yang boleh anda letak dalam baris gilir atau proses pada masa yang sama. Melebihinya bermakna anda sudah mempunyai bilangan maksimum tugasan aktif dan perlu menunggu satu selesai sebelum menghantar yang lain.

Semak had permintaan dan had serentak semasa pelan anda dalam papan pemuka Meshy anda, kerana ini boleh berbeza mengikut gred pelan.

Apabila anda menerima respons 429 atau RateLimitExceeded, jangan terus mencuba semula permintaan yang sama. Sebaliknya:

• Gunakan exponential backoff: tunggu selang masa yang pendek, kemudian gandakannya pada setiap kegagalan berikutnya, sehingga had maksimum yang munasabah.

• Tambahkan jitter (offset rawak yang kecil) pada selang backoff anda supaya berbilang pekerja dalam sistem anda tidak mencuba semula pada saat yang sama.

• Hormati sebarang pengepala Retry-After atau pengepala had kadar yang dipulangkan dalam respons, jika ada, dan bukannya meneka masa menunggu.

• Hadkan bilangan percubaan semula bagi setiap permintaan supaya kegagalan berterusan tidak berterusan berulang tanpa henti.

Ralat NoMoreConcurrentTasks bermakna anda sudah berada pada siling tugasan aktif akaun anda. Untuk mengelakkan menghadapinya dalam persekitaran pengeluaran:

• Kekalkan baris gilir setempat atau penjadual tugasan dalam aplikasi anda sendiri yang hanya menghantar tugasan penjanaan baharu selepas tugasan sebelumnya selesai atau bilangan aktif anda jatuh di bawah had.

• Tinjau status tugasan (atau gunakan webhook, jika disokong dalam aliran kerja anda) untuk mengetahui bila slot menjadi kosong, dan bukannya menghantar secara spekulatif.

• Kumpulkan dan kawal kadar tugasan penjanaan pukal dan bukannya menghantar semua permintaan sekaligus — ini melicinkan kadar permintaan anda dan bilangan tugasan serentak anda.

• Bina pemantauan/amaran di pihak anda supaya lonjakan ralat 429/NoMoreConcurrentTasks dapat dilihat sebelum ia menjejaskan pengguna anda.

API Meshy buat masa ini tidak menyokong "cuba semula" terbina dalam untuk penjanaan sedia ada bagi pelan individu atau studio — jika hasil tidak memenuhi jangkaan anda, anda menghantar permintaan penjanaan baharu, yang menggunakan kredit seperti biasa. Apabila saluran automatik anda mengendalikan ralat sementara (seperti 429), pastikan logik cuba semula anda hanya menghantar semula permintaan asal selepas backoff, dan bukannya mencipta tugasan penjanaan pendua setiap kali.

Jika anda telah melaksanakan backoff dan baris gilir sedar-serentak tetapi masih konsisten menghadapi had kadar atau had serentak, itu biasanya tanda bahawa keperluan throughput integrasi anda telah melebihi had pelan semasa anda. Semak papan pemuka anda untuk elaun permintaan dan serentak pelan semasa anda, dan pertimbangkan untuk menaik taraf atau menghubungi pasukan jualan Meshy mengenai akses API peringkat perusahaan jika anda memerlukan throughput yang lebih tinggi secara berterusan.

Ia bermakna anda telah melebihi bilangan permintaan API yang dibenarkan dalam tempoh masa tertentu untuk pelan anda. Kurangkan kadar permintaan anda dan gunakan exponential backoff sebelum mencuba semula.

Ia bermakna anda sudah mempunyai bilangan maksimum tugasan penjanaan dalam baris gilir atau sedang berjalan untuk akaun anda. Tunggu tugasan sedia ada selesai, atau kurangkan bilangan tugasan yang anda hantar pada satu masa, sebelum menghantar yang lain.

Semak papan pemuka Meshy anda untuk had yang dikaitkan dengan pelan semasa anda, kerana ini boleh berbeza antara gred pelan.

Tidak, bukan untuk pelan individu atau studio — penjanaan yang gagal atau tidak memuaskan mesti dihantar semula sebagai permintaan baharu, yang menggunakan kredit seperti biasa. Pelanggan perusahaan harus menghubungi jualan mengenai fungsi cuba semula.

Laksanakan baris gilir setempat yang mengawal kadar penghantaran untuk kekal di bawah had serentak anda, tambahkan exponential backoff dengan jitter untuk sebarang respons 429, dan pantau kadar ralat supaya anda boleh bertindak balas sebelum ia menjejaskan pengguna anda.

Jika anda telah melaksanakan backoff dan baris gilir sedar-serentak tetapi masih kerap menghadapi had ini, penggunaan anda kemungkinan telah melebihi pelan semasa anda — semak papan pemuka anda atau hubungi jualan mengenai pelan throughput yang lebih tinggi.

• Bagaimana Saya Menggunakan API Meshy?

• Adakah API Meshy Menyokong Cuba Semula untuk Penjanaan?