속도 제한은 지정된 기간 내에Voyage AI 에 요청 수 있는 토큰의 빈도와 수에 대한 제한입니다. 속도 제한에 대해 자세히 학습 권장사항을 참조하세요.
Atlas 모델 API 키 사용량(분당 요청(RPM) 및 분당 토큰(TPM))에 따라 속도 제한을 시행합니다. 가장 최근 1분 동안의 요청 또는 토큰 수를 초과하는 경우 API 후속 추가 요청 429 거부하고(Rate Limit Exceeded) HTTP 상태 코드를 반환합니다.
속도 제한 관리
다음 섹션에서는 Atlas UI 에서 속도 제한을 관리 방법을 설명합니다.
필수 권한
프로젝트 수준에서 속도 제한을 설정하다 하고 재설정하려면 Atlas 에 대한 이상의 액세스 있어야 Project Owner 합니다.
요금 한도를 보려면 다음과 같이 하세요:
조직 및 프로젝트 수준에서 Atlas 에 대한 이상의 액세스 있어야
Organization Read Only합니다.프로젝트 수준에서만 Atlas 에 대한 이상의 액세스 있어야
Project Read Only합니다.
속도 제한 설정
프로젝트 수준에서 각 프로젝트 에 대해 서로 다른 한도를 설정하다 수 있습니다. 프로젝트 수준의 비율 한도는 조직 의 비율 한도를 초과할 수 없습니다. 프로젝트 수준에서 설정하다 비율 제한은 프로젝트 의 모든 모델 API 키에 적용 .
Atlas 에 로그인합니다.
요금 한도 보기
조직 및 프로젝트 수준에서 요금 한도를 확인할 수 있습니다.
Atlas 에 로그인합니다.
이 페이지에는 다음 정보가 표시됩니다.
이름 | 설명 |
|---|---|
Model | Voyage AI 임베딩 모델 목록. |
Tokens Per Minute (TPM) | Embedding 및 Reranking API 엔드포인트에서 1분 이내에 요청 수 있는 토큰의 수입니다. |
Requests Per Min (RPM) | 1분 내에 Embedding 및 Reranking API 엔드포인트로 보낼 수 있는 API 요청의 수입니다. |
Atlas 에 로그인합니다.
Rate Limits 왼쪽 탐색에서 를 선택합니다.
이 페이지에는 요금 한도에 대한 다음 정보가 표시됩니다.
열 이름 | 열 설명 |
|---|---|
Model | Voyage AI 임베딩 모델 목록. |
Tokens Per Minute (TPM) | Voyage AI Embedding 및 Reranking API 엔드포인트에서 1분 이내에 요청 수 있는 토큰의 수입니다. |
Requests Per Min (RPM) | 1분 내에Voyage AI Embedding 및 Reranking API 엔드포인트로 전송할 수 있는 요청의 수입니다. |
Actions | 취할 수 있는 조치입니다. 다음을 수행할 수 있습니다.
|
사용자 지정 한도를 설정하다 하면 페이지의 모든 사용자 지정 요금 한도를 조직 의 기본값 으로 되돌릴 수 있는 Reset all limits 버튼도 표시됩니다.
모든 속도 제한 재설정
언제든지 프로젝트 에 설정하다 모든 사용자 지정 제한을 재설정할 수 있습니다. 제한을 재설정하면 프로젝트 의 요금 제한이 조직 의 기본값 요금 제한으로 되돌아갑니다.
Atlas 에 로그인합니다.
사용 계층
요금 한도는 계층화된 시스템을 따르며, 계층이 높을수록 한도가 증가합니다. 계층 의 자격은 청구된 사용량을 기준으로 합니다(무료 토큰 제외). Atlas 각 모델에 대해 200 백만 개의 무료 토큰을 제공합니다. 멀티모달 모델에는 150 0억 개의 무료 픽셀도 포함되어 있습니다. 계층 자격을 갖춘 후에는 다운그레이드되지 않습니다. 사용량 및 지출이 증가하면 Atlas 자동으로 사용자를 다음 사용량 계층 으로 승격시켜 모든 모델에 걸쳐 요금 한도를 상향 조정합니다.
자세한 학습 은 요금 한도 및 사용 티어를 참조하세요.
기본 속도 제한
이 섹션에서는 조직 수준에서 적용되는 각 사용 계층 에 대한 기본값 요금 한도에 대해 설명합니다. 또한 각 프로젝트 에 대해 구성할 수 있는 속도 제한에 대해서도 설명합니다.
조직 속도 제한
다음 표는 각 Voyage AI 임베딩 모델의 사용 계층 에 따른 기본값 속도 제한(TPM 및 RPM )을 보여줍니다.
모델 | Tokens Per Min (TPM) | 분당 요청(RPM) |
|---|---|---|
| 16,000,000 | 2,000 |
| 8,000,000 | 2,000 |
| 3,000,000 | 2,000 |
| 3,000,000 | 2,000 |
| 2,000,000 | 2,000 |
| 4,000,000 | 2,000 |
| 2,000,000 | 2,000 |
사용 계층 2 의 속도 제한은 사용 계층 1의 두 배입니다.
모델 | Tokens Per Min (TPM) | 분당 요청(RPM) |
|---|---|---|
| 32,000,000 | 4,000 |
| 16,000,000 | 4,000 |
| 6,000,000 | 4,000 |
| 6,000,000 | 4,000 |
| 4,000,000 | 4,000 |
| 8,000,000 | 4,000 |
| 4,000,000 | 4,000 |
사용 계층 3 의 요금 한도는 사용 계층 1의 3배입니다.
모델 | Tokens Per Min (TPM) | 분당 요청(RPM) |
|---|---|---|
| 48,000,000 | 6,000 |
| 24,000,000 | 6,000 |
| 9,000,000 | 6,000 |
| 9,000,000 | 6,000 |
| 6,000,000 | 6,000 |
| 12,000,000 | 6,000 |
| 6,000,000 | 6,000 |
프로젝트 속도 제한
기본값 으로 프로젝트는 조직 의 속도 제한에 따라 속도 제한을 상속합니다. 그러나 프로젝트 수준에서 각 프로젝트 에 대해 서로 다른 한도를 설정하다 수 있습니다. 프로젝트 수준의 비율 한도는 조직 의 비율 한도를 초과할 수 없습니다. 프로젝트 수준에서 설정하다 비율 제한은 프로젝트 의 모든 모델 API 키에 적용 . 그러나 조직 요금 한도에 먼저 도달하면 프로젝트의 요금이 더 낮은 요금으로 제한될 수 있습니다. 이는 모든 프로젝트 요금 한도의 합계가 조직 한도를 초과하는 경우 발생할 수 있습니다.
예시
속도 제한이 P,1 P,2 P3 인 세 개의 프로젝트가 있는 조직 속도 제한 O를 가정해 보겠습니다. 아래 표는 프로젝트 요금 한도의 합계가 조직 요금 한도보다 작거나, 같거나, 큰 세 가지 시나리오를 보여줍니다. 각 시나리오에 대해 표에는 조직 제한에 도달할 수 있는지 여부와 한 프로젝트의 사용량이 다른 프로젝트에 영향 수 있는지 여부가 나와 있습니다.
Scenario 1 P1 + P2 + P3 < O | Scenario 2 P1 + P2 + P3 = O | Scenario 3 P1 + P2 + P3 > O | |
|---|---|---|---|
시나리오 설명 | 모든 프로젝트 속도 제한의 합계가 조직 제한보다 작습니다. | 모든 프로젝트 요금 한도의 합계는 조직 한도와 동일합니다. | 모든 프로젝트 요금 한도의 합계가 조직 한도보다 큽니다. |
조직 제한에 도달할 수 있나요? | 아니요, 모든 프로젝트가 요금 한도에 도달하더라도 조직 요금 한도는 초과되지 않습니다. | 예, 모든 프로젝트가 요금 한도에 도달하면 조직 한도에도 도달하게 됩니다. | 예, 모든 프로젝트 요율 한도의 합계가 조직 한도를 초과하므로 개별 프로젝트가 자체 한도에 도달하기 전에 조직 한도에 도달할 수 있습니다. |
한 프로젝트의 사용량이 다른 프로젝트에 영향 수 있나요? | No. | No. | 네. 일부 또는 모든 프로젝트가 개별 제한에 도달하기 전에 프로젝트가 조직 제한에 도달할 만큼 충분한 사용량을 집합적으로 소비하는 경우, 프로젝트의 요금을 개별 제한보다 낮은 요금으로 제한할 수 있습니다. |
모범 사례
속도 제한은 API 리소스를 균형 있고 효율적으로 활용하여 서비스의 전체 성능과 접근성에 영향 수 있는 과도한 트래픽을 방지합니다. 특히 속도 제한은 다음과 같은 중요한 목적을 제공 .
속도 제한은 모든 사용자가 API 에 공평하게 액세스 있도록 합니다. 한 개인이나 조직 과도한 양의 요청을 생성하면 다른 사람들의 API 성능이 잠재적으로 저하될 수 있습니다. 속도 제한을 통해 더 많은 사용자가 성능 문제 없이 API 사용할 수 있도록 보장합니다.
속도 제한을 활성화 Voyage AI 인프라의 워크로드 효과적으로 관리 할 수 있습니다. API 요청이 갑자기 급증하면 서버 리소스에 부하가 걸리고 성능이 저하될 수 있습니다. 속도 제한을 설정하면 Voyage AI 모든 사용자에게 일관적인 되고 안정적인 환경을 효과적으로 유지할 수 있습니다.
이는 API 의 잠재적인 남용 또는 오용으로부터 보호하는 역할을 합니다. 인스턴스 를 들어, 악의적인 행위자가 API에 과부하를 주거나 서비스를 중단시키기 위해 과도한 요청으로 API 포화시키려고 시도할 수 있습니다. Voyage AI 속도 제한을 설정함으로써 이러한 악의적인 활동을 저지할 수 있습니다.
속도 제한 오류를 방지하고 관리 하려면 다음 권장사항 권장합니다.
대규모 배치 사용
임베드할 문서가 많은 경우 요청 당 임베드하는 문서 수를 늘리고 더 큰 배치를 전송하여 전체 처리량 늘릴 수 있습니다. ' 배치 "는 하나의 요청 에 포함하는 문서의 컬렉션 이며, ' 배치 크기'는 배치 에 포함된 문서의 수이며, 이는 문서 목록의 길이를 의미합니다.
예시
문서를 벡터화한다고 가정해 보겠습니다. 배치 크기 를 사용한 512 1 경우에는 512 요청이 필요하며 RPM 제한에 도달할 수 있습니다. 그러나 의 배치 크기를 사용한 128 경우에는 개의 4 요청만 필요하며 RPM 제한에 도달하지 않습니다. 요청 에 제공한 문서 수를 변경하여 배치 크기를 제어할 수 있으며, 배치 크기를 크게 사용하면 주어진 문서 수에 대한 전체 RPM이 감소합니다.
배치 크기를 선택할 때 API 최대 배치 크기와 토큰을 고려해야 합니다. API 최대 배치 크기를 초과할 수 없습니다. 문서가 더 긴 경우 요청 당 토큰 제한으로 인해 배치 크기가 더 작아질 수 있습니다.
대기 기간 설정
요청 빈도를 줄입니다. 요청의 속도를 조정하여 이 작업을 수행할 수 있으며, 가장 간단한 방법은 각 요청 사이에 대기 기간을 삽입하는 것입니다.
지수 백오프 수행
속도 제한에 도달하면(즉, 429 오류 수신) 백오프합니다. 속도 제한 오류를 수신한 후 다시 시도하기 전에 기하급수적으로 증가된 시간 동안 기다릴 수 있습니다. 요청 성공적인 하거나 최대 재시도 횟수에 도달할 때까지 기다립니다.
예시
초기 대기 시간이 1초이고 성공 전에 속도 제한 오류가 세 번 연속 발생한 경우 각 속도 제한 오류가 발생한 후 각각 1초, 2초, 4초 후에 요청 다시 전송해야 합니다.