Cách khắc phục lỗi 429 và giới hạn tốc độ của Meshy API

Nếu tích hợp của bạn gặp các lỗi 429, RateLimitExceeded hoặc NoMoreConcurrentTasks khi gọi Meshy API, hướng dẫn này sẽ giải thích lý do các giới hạn này tồn tại và cách thiết kế tích hợp của bạn để hoạt động trong phạm vi của chúng.

API của Meshy nằm phía trước hạ tầng GPU dùng chung được sử dụng để tạo mô hình 3D, texture và các tài nguyên liên quan. Giới hạn tốc độ và giới hạn đồng thời bảo vệ hạ tầng chia sẻ đó để chất lượng tạo và thời gian xử lý luôn nhất quán cho mọi người dùng trên nền tảng. Mỗi tài khoản, tùy theo gói hiện tại, có một số lượng yêu cầu tối đa có thể thực hiện trong một khoảng thời gian nhất định và một số lượng tác vụ tạo tối đa có thể chạy đồng thời (đang xếp hàng hoặc đang xử lý) tại một thời điểm.

Có hai loại giới hạn riêng biệt, và chúng gây lỗi theo cách khác nhau:

• Giới hạn tốc độ yêu cầu (429 / RateLimitExceeded): giới hạn số lần gọi API (ví dụ: tạo tác vụ, thăm dò trạng thái) bạn có thể thực hiện mỗi phút. Vượt quá giới hạn này có nghĩa là bạn đang gọi API quá thường xuyên, bất kể có bao nhiêu tác vụ đang thực sự chạy.

• Giới hạn đồng thời / hàng đợi (NoMoreConcurrentTasks): giới hạn số lượng tác vụ tạo mà bạn có thể xếp hàng hoặc đang xử lý cùng lúc. Vượt quá giới hạn này có nghĩa là bạn đã đạt số lượng tác vụ đang hoạt động tối đa và cần đợi một tác vụ hoàn thành trước khi gửi tác vụ khác.

Kiểm tra giới hạn tốc độ yêu cầu và đồng thời hiện tại của gói bạn trong bảng điều khiển Meshy, vì các giới hạn này có thể khác nhau giữa các cấp gói.

Khi bạn nhận được phản hồi 429 hoặc RateLimitExceeded, đừng ngay lập tức thử lại cùng một yêu cầu. Thay vào đó:

• Sử dụng exponential backoff: chờ một khoảng thời gian ngắn, sau đó nhân đôi ở mỗi lần thất bại tiếp theo, tối đa đến một mức hợp lý.

• Thêm jitter (một khoảng lệch ngẫu nhiên nhỏ) vào khoảng thời gian backoff của bạn để các worker trong hệ thống không cùng thử lại tại cùng một thời điểm.

• Tôn trọng bất kỳ tiêu đề Retry-After hoặc giới hạn tốc độ nào được trả về trong phản hồi, nếu có, thay vì tự đoán thời gian chờ.

• Giới hạn số lần thử lại cho mỗi yêu cầu để một lỗi kéo dài không lặp lại vô hạn.

Lỗi NoMoreConcurrentTasks có nghĩa là bạn đã đạt trần số lượng tác vụ đang hoạt động của tài khoản. Để tránh gặp lỗi này trong môi trường sản xuất:

• Duy trì một hàng đợi cục bộ hoặc bộ lập lịch công việc trong ứng dụng của bạn, chỉ gửi một tác vụ tạo mới sau khi tác vụ trước đó hoàn thành hoặc số lượng tác vụ đang hoạt động của bạn giảm xuống dưới giới hạn.

• Thăm dò trạng thái tác vụ (hoặc sử dụng webhooks, nếu được hỗ trợ trong quy trình của bạn) để biết khi nào có một slot trống, thay vì gửi một cách mạo hiểm.

• Gom nhóm và điều tiết các công việc tạo hàng loạt thay vì bắn tất cả yêu cầu cùng lúc — điều này làm mượt cả tốc độ yêu cầu và số lượng tác vụ đồng thời của bạn.

• Xây dựng giám sát/cảnh báo phía bạn để một đợt tăng đột biến của các lỗi 429/NoMoreConcurrentTasks được phát hiện trước khi ảnh hưởng đến người dùng của bạn.

Meshy API hiện chưa hỗ trợ "thử lại" tích hợp sẵn một bản tạo hiện có cho các gói cá nhân hoặc studio — nếu kết quả không đáp ứng kỳ vọng của bạn, bạn phải gửi một yêu cầu tạo mới, và điều này tiêu tốn credits như bình thường. Khi quy trình tự động của bạn xử lý các lỗi tạm thời (như 429), hãy đảm bảo logic thử lại chỉ gửi lại yêu cầu gốc sau khi đã backoff, chứ không tạo các tác vụ tạo trùng lặp mỗi lần.

Nếu bạn đã triển khai backoff và hàng đợi có tính đến giới hạn đồng thời nhưng vẫn liên tục chạm đến giới hạn tốc độ hoặc đồng thời, đó thường là dấu hiệu cho thấy nhu cầu thông lượng của tích hợp đã vượt quá giới hạn của gói hiện tại. Kiểm tra bảng điều khiển để xem giới hạn tốc độ yêu cầu và đồng thời của gói hiện tại, và cân nhắc nâng cấp hoặc liên hệ với đội ngũ bán hàng của Meshy về quyền truy cập API cấp doanh nghiệp nếu bạn cần thông lượng cao hơn một cách ổn định.

Nó có nghĩa là bạn đã vượt quá số lượng yêu cầu API được phép trong một khoảng thời gian nhất định dành cho gói của bạn. Hãy giảm tốc độ yêu cầu và sử dụng exponential backoff trước khi thử lại.

Nó có nghĩa là bạn đã có số lượng tác vụ tạo tối đa đang xếp hàng hoặc đang xử lý đối với tài khoản của mình. Hãy đợi một tác vụ hiện có hoàn thành, hoặc giảm số lượng tác vụ bạn gửi cùng lúc, trước khi gửi thêm.

Kiểm tra bảng điều khiển Meshy để xem các giới hạn liên quan đến gói hiện tại của bạn, vì chúng có thể khác nhau giữa các cấp gói.

Không, không cho các gói cá nhân hoặc studio — một bản tạo thất bại hoặc chưa đạt yêu cầu phải được gửi lại dưới dạng một yêu cầu mới, và điều này sử dụng credits như bình thường. Khách hàng doanh nghiệp nên liên hệ với bộ phận bán hàng về tính năng thử lại.

Triển khai một hàng đợi cục bộ điều tiết việc gửi tác vụ để duy trì dưới giới hạn đồng thời, thêm exponential backoff với jitter cho mọi phản hồi 429, và giám sát tỷ lệ lỗi để bạn có thể phản ứng trước khi chúng ảnh hưởng đến người dùng của bạn.

Nếu bạn đã triển khai backoff và hàng đợi có tính đến giới hạn đồng thời nhưng vẫn thường xuyên chạm đến các giới hạn này, mức sử dụng của bạn có khả năng đã vượt quá gói hiện tại — hãy kiểm tra bảng điều khiển hoặc liên hệ với bộ phận bán hàng về một gói có thông lượng cao hơn.

• Cách sử dụng Meshy API?

• Meshy API Có Hỗ trợ Thử lại cho các Bản tạo Không?