lowpoly는 2026. 10. 30.에 지원 종료됩니다. 요청 오류를 피하려면 해당 날짜 전에 모델을 전환하세요.

속도 제한

속도 제한이란 사용자나 클라이언트가 지정된 기간 동안 저희 서비스에 접근할 수 있는 횟수에 대해 API가 부과하는 제약을 의미합니다.


제한을 두는 이유

저희는 모든 사용자에게 최상의 경험을 제공하기 위해 API에 속도 제한을 두고 있습니다. 그 이유는 다음과 같습니다:

  • 서비스를 안전하고 건전하게 유지하기 위해서입니다! 속도 제한은 친절한 안내 요원과 같습니다 - 한 번에 너무 많은 요청이 API에 몰려 과부하가 걸리지 않도록 해줍니다. 이는 서비스를 잠재적인 오남용으로부터 보호하고 모든 것이 원활하게 돌아가도록 도와줍니다.

  • 모든 사용자가 공평한 몫을 누릴 수 있도록 하기 위해서입니다. 놀이터에서 장난감을 나눠 쓰듯이, 저희는 모든 사용자가 API에 동등하게 접근할 수 있도록 하고 싶습니다. 각 사용자가 만들 수 있는 요청 수를 적절히 제한함으로써, 아무도 자신의 차례를 너무 오래 기다리지 않도록 보장합니다.

  • 성능을 빠르고 안정적으로 유지하기 위해서입니다. 전체 요청 흐름을 관리함으로써, 모든 소중한 사용자분들께 빠른 응답 시간과 안정적인 서비스를 제공할 수 있습니다. 마치 고속도로가 너무 혼잡해지지 않도록 하는 것과 같습니다 - 정체를 방지하면 교통 흐름이 더 원활해집니다!


제한이 작동하는 방식

속도 제한은 2가지 방식으로 측정됩니다:

  • 초당 요청 수: 초당 보낼 수 있는 네트워크 요청의 수입니다.
  • 대기열 작업: 특정 시점에 대기열에서 동시에 실행할 수 있는 생성 작업의 수입니다.

대기열 작업은 계정에서 PENDING 또는 IN_PROGRESS 상태인 작업입니다. 작업을 생성하는 모든 엔드포인트(예: 텍스트로 3D, 이미지로 3D, 멀티 이미지로 3D, 리텍스처, 리메시, Rigging, 애니메이션, 텍스트로 이미지, 3D 프린팅 엔드포인트, Creative Lab)는 새 작업을 수락하기 전에 이 제한을 확인합니다. Balance, Usage, 그리고 작업 조회, 목록 가져오기 또는 스트리밍과 같이 작업을 생성하지 않는 요청은 이 제한에 포함되지 않지만, 초당 요청 수에는 여전히 포함됩니다.

이 제한은 계정 단위로 적용되므로, 귀하의 모든 API key와 Playground에서 공유됩니다. Meshy 웹 앱에서 시작한 작업 또한 대기열 작업에 포함됩니다.

속도 제한 외에도, 작업 처리 우선순위 역시 작업 속도에 영향을 미칩니다.

각 사용자 등급에는 해당 등급의 필요에 맞게 설계된 특정 속도 제한과 우선순위 수준이 있습니다. 등급별 현재 제한은 다음과 같습니다:

사용자 등급초당 요청 수대기열 작업우선순위 수준
Pro2010기본값
Premium2030Pro보다 높음
Ultra20100최고
Studio2020Pro보다 높음
Enterprise100기본값 100, 맞춤 설정 가능최고

이러한 제한을 초과하면, API로부터 429 Too Many Requests 응답을 받게 됩니다. 이를 발생시킬 수 있는 두 가지 유형의 히트가 있으며, 각각 다른 응답을 반환합니다:

  • Request Hit: 초당 너무 많은 요청을 보냈을 때 발생합니다. Rate limit exceeded 메시지와 함께 429 Too Many Requests 응답을 받게 됩니다.
  • Queue Hit: 동시에 실행 중인 생성 작업이 너무 많을 때 발생합니다. NoMorePendingTasks 메시지(또는 크레딧이 소진된 경우 NoMoreConcurrentTasks)와 함께 429 Too Many Requests 응답을 받게 됩니다. 이 429에는 Retry-After가 포함되지 않습니다: 작업 중 하나가 끝날 때까지 기다린 후 새 작업을 생성하세요.

속도 제한 헤더

API 응답에는 요청 속도를 조절할 수 있도록 다음 헤더가 포함됩니다:

헤더설명
X-RateLimit-Limit사용자 등급에서 초당 허용되는 요청 수입니다.
X-RateLimit-Remaining현재 1초 동안 남은 요청 수입니다.
X-RateLimit-Reset할당량이 다시 가득 찰 때까지 남은 초입니다.
Retry-After다음 요청까지 기다려야 하는 초입니다. Request Hit 429와 함께 전송되며, 아직 PENDING 또는 IN_PROGRESS 상태인 작업을 조회할 때도 전송됩니다.

Retry-After가 존재하면, 다음 요청을 보내기 전에 해당 초만큼 기다리세요.