모자이크 AI 벡터 검색은 빠르고 확장 가능한 검색을 위해 빌드되었습니다. 벡터 검색 성능은 SKU 선택, 인덱스 크기, 쿼리 유형, 벡터 차원, 인증 방법 및 애플리케이션이 트래픽 급증을 처리하는 방법을 비롯한 여러 요인에 따라 달라집니다. 대부분의 워크로드는 우선적으로 잘 수행되지만 대기 시간을 조정하거나 최적화해야 하는 경우 이 가이드에서는 최적의 벡터 검색 성능을 위해 시스템을 구성하는 데 도움이 되는 실용적인 팁과 일반적인 패턴을 제공합니다.
성능에 영향을 주는 요인
성능은 단일 숫자가 아니라 워크로드 특성, 구성 선택 및 클라이언트 구현에 따라 달라지는 범위입니다. 이 가이드는 모자이크 AI 벡터 검색을 가장 효과적으로 사용할 수 있도록 성능이 작동하는 방식에 대한 명확한 정신 모델을 빌드하는 데 도움이 되도록 설계되었습니다.
다음은 시스템의 작동 방식에 영향을 주는 주요 요소입니다.
- SKU 선택: 표준 또는 스토리지 최적화
- 인덱스 크기: 저장된 벡터 수입니다.
- 임베딩 크기: 일반적으로 384-1536.
- 쿼리 유형: 최근접 이웃 검색(ANN) 또는 하이브리드.
- 요청된 결과 수: 값이 높을수록 검색 시간이 증가합니다.
- 포함 유형: 관리형 또는 자체 관리형입니다.
- 쿼리 로드: 시간이 지남에 따라 엔드포인트에 도달한 트래픽의 양입니다.
- 인증 방법: 앱이 Databricks에 연결하는 방법
이 문서의 나머지 내용은 이러한 각 변수를 튜닝하기 위한 실용적인 팁을 제공하고 실제 배포에서 검색 대기 시간 및 쿼리 처리량에 미치는 영향을 설명합니다.
올바른 SKU 선택
Mosaic AI Vector Search는 워크로드에 따라 대기 시간, 확장성 및 비용 효율성의 균형을 맞추도록 설계된 두 개의 SKU를 제공합니다. 애플리케이션에 적합한 SKU를 선택하는 것은 튜닝 성능을 위한 첫 번째 레버입니다.
일반적으로 다음을 수행합니다.
- 대기 시간이 중요하고 인덱스가 320M 벡터 미만인 경우 표준 엔드포인트를 선택합니다.
- 10M+ 벡터로 작업할 때 스토리지 최적화 엔드포인트를 선택하고, 약간의 추가 대기 시간을 허용할 수 있으며, 벡터당 더 나은 비용 효율성(최대 7배 저렴)이 필요합니다.
다음 표에서는 몇 가지 예상 성능 지침을 보여 줍니다.
| SKU | 지연 | QPS | 인덱스 용량 | VSU(벡터 검색 단위) 크기 |
|---|---|---|---|---|
| 스탠다드 | 20~50ms | 30–200+ | 320백만 벡터 | 2백만 벡터 |
| 스토리지 최적화 | 300~500ms | 30–50 | 1B 벡터 | 64M 벡터 |
인덱스 크기 이해
인덱스가 단일 벡터 검색 단위 내에 맞으면 성능이 가장 높으며 추가 쿼리 로드를 처리할 수 있는 추가 공간이 있습니다. 워크로드가 단일 벡터 검색 단위(즉, 표준의 경우 2M+ 벡터 또는 스토리지 최적화를 위한 경우 64M+ 벡터)를 초과하면, 대기 시간이 늘어나고 QPS가 점차 감소합니다. 결국 QPS(초당 쿼리 수)는 약 30 QPS(ANN)에서 한계에 도달합니다.
성능은 쿼리 패턴, 필터, 벡터 차원, 동시성 등 각 워크로드에 고유한 여러 요인에 따라 달라집니다. 다음 숫자는 참조 지점입니다.
| SKU | Vectors | Dimension | 지연 | QPS | 월별 쿼리 |
|---|---|---|---|---|---|
| 스탠다드 | 10,000 | 768 | 20ms | 200+ | 5억 이상 |
| 10M | 768 | 40ms | 30 | 7800만 | |
| 100M | 768 | 50밀리초(ms) | 30 | 7800만 | |
| 스토리지 최적화 | 10M | 768 | 300ms | 50 | 130M |
| 100M | 768 | 400ms | 40 | 100M | |
| 1B | 768 | 500밀리초 | 30 | 7800만 |
임베딩 크기 최소화
벡터 차원은 각 벡터의 기능 수를 나타냅니다. 일반적인 값은 384, 768, 1024 또는 1536입니다. 차원이 높을수록 품질을 향상시킬 수 있지만 컴퓨팅 비용이 들 수 있는 표현이 더 많이 제공됩니다. 하위 차원 벡터는 검색하는 동안 더 적은 계산이 필요하므로 쿼리 시간이 빨라지고 QPS가 높아집니다. 반대로, 더 높은 차원 벡터는 컴퓨팅 부하를 증가시키고 처리량을 줄입니다.
일반적으로 사용 사례에 대한 검색 품질을 유지하는 가장 작은 차원을 선택합니다.
예를 들어 차원을 2배(예: 768에서 384)로 줄이면 일반적으로 QPS가 약 1.5배 향상되고 인덱스 크기 및 쿼리 패턴에 따라 대기 시간이 약 20%감소합니다. 차원이 매우 낮을 때 이러한 향상이 더욱 두드러집니다. 예를 들어 64차원 벡터를 사용하면 표에 표시된 768차원 벤치마크에 비해 QPS가 훨씬 높고 대기 시간이 훨씬 짧아질 수 있습니다. 따라서 검색 품질이 허용되는 한 384차원 이하는 처리량이 높고 대기 시간에 민감한 사용 사례에 특히 매력적입니다.
효율성을 위해 ANN을 사용하고 필요한 경우 하이브리드 사용
가능하면 언제든지 ANN 쿼리를 사용합니다. 가장 컴퓨팅 효율적이며 가장 높은 QPS를 지원합니다.
필요한 경우 하이브리드 검색을 사용합니다. 하이브리드 검색은 특히 도메인별 키워드가 중요한 일부 애플리케이션에서 회수를 향상시킵니다. 하이브리드 검색은 일반적으로 ANN보다 약 2배 많은 리소스를 사용하며 처리량을 크게 줄일 수 있습니다.
10~100개 결과 사용
각 쿼리에는 반환할 num_results 검색 결과 수인 매개 변수가 포함됩니다. 이 값은 성능에 직접적인 영향을 줍니다. 더 많은 결과를 검색하려면 인덱스를 더 깊이 검색해야 하므로 대기 시간이 증가하고 QPS가 줄어듭니다. 효과는 더 높은 값에서 더 중요해집니다. 예를 들어 10배 증가 num_results 하면 인덱스 크기 및 구성에 따라 쿼리 대기 시간을 두 배로 늘리고 QPS 용량을 3배 줄일 수 있습니다.
애플리케이션에 특별히 더 많은 요구 사항이 없는 한 10~100 범위로 유지하는 num_results 것이 가장 좋습니다. 실제 쿼리를 사용하여 워크로드에 미치는 영향을 이해하기 위해 다양한 num_results 값을 사용해 보세요.
프로덕션 환경에서 자원을 0으로 축소하지 마십시오.
Vector Search는 성능이 서로 다른 두 가지 유형의 포함을 지원합니다.
관리되는 임베딩이 가장 편리합니다. 관리되는 포함을 사용하여 Databricks는 행과 쿼리 모두에 대한 포함을 자동으로 생성합니다. 쿼리 시 쿼리 텍스트는 엔드포인트를 제공하는 모델에 전달되어 포함을 생성하여 대기 시간을 추가합니다. 포함 모델이 외부인 경우 추가 네트워크 오버헤드도 발생합니다.
자체 관리형 포함을 사용하면 임베딩을 미리 계산하고 쿼리 시간에 직접 벡터를 전달할 수 있습니다. 이렇게 하면 런타임 생성을 방지하고 가장 빠른 검색을 사용할 수 있습니다. 이 문서에 포함된 모든 성능 번호는 자체 관리형 포함을 기반으로 합니다.
실시간 프로덕션 사용 사례의 경우 0으로 확장되는 모델 엔드포인트를 사용하지 마세요. 콜드 시작은 응답을 몇 분 지연하거나 쿼리가 도착할 때 엔드포인트가 비활성 상태인 경우 실패를 일으킬 수 있습니다.
쿼리 폭증에 대비한 계획
이 섹션에서는 트래픽이 증가할 때 예상되는 사항과 대기 시간 급증 또는 429 오류(너무 많은 요청)를 트리거하는 중요한 한도 아래로 유지하는 방법을 설명합니다.
부하가 보통일 때 대기 시간은 낮게 유지되고 최대 QPS 용량에 접근하면 점차 증가합니다. 시스템이 100% QPS 용량에 도달하면 429 오류가 반환되기 시작합니다. 적절한 백오프를 설정하지 않은 경우 앱이 응답하지 않을 수 있습니다.
429 오류는 시스템을 보호하기 위한 안전 메커니즘의 역할을 합니다. 갑작스러운 트래픽 급증에도 엔드포인트가 정상적이고 응답성이 유지되도록 클라이언트에 백오프하고 나중에 다시 시도하도록 지시합니다.
기본 제공 백오프 및 재시도 처리를 포함하는 Vector Search Python SDK를 사용하는 것이 좋습니다.
REST API를 사용하는 경우 지터를 사용하여 지수 백오프를 구현합니다. Azure 안티패턴을 참조하세요.
OAuth 토큰과 함께 서비스 주체 사용
최상의 성능을 위해 효율적인 인증 방법을 사용합니다. Databricks는 모든 프로덕션 환경에서 OAuth 토큰과 함께 서비스 주체 를 사용하는 것이 좋습니다. OAuth 액세스 토큰은 보안을 강화하며 네트워크 최적화 인프라를 활용하여 시스템이 전체 용량으로 작동할 수 있도록 합니다.
네트워크 오버헤드가 발생하므로 PAT(개인용 액세스 토큰)를 사용하지 말고 수백 밀리초의 대기 시간을 추가하고 엔드포인트가 유지할 수 있는 QPS를 크게 줄입니다.
Python SDK 사용
최신 버전의 Python SDK를 사용하여 기본 제공 성능 및 안정성 최적화를 활용할 수 있습니다.
쿼리에서 인덱스 개체를 다시 사용합니다. 이 패턴은 불필요한 대기 시간을 추가하므로 모든 요청에서 호출 client.get_index(...).similarity_search(...) 하지 않습니다.
대신 인덱스 한 번 초기화하고 다시 사용합니다.
# Initialize once
index = client.get_index(...)
# Then use it for every query
index.similarity_search(...)
이는 엔드포인트 초기화 시 인덱스 개체를 만든 다음 모든 쿼리에 다시 사용할 수 있는 MLFlow 환경에서 벡터 검색 인덱스를 사용할 때 중요합니다.
이 지침은 실시간 대기 시간에 민감한 애플리케이션에서 특히 유용합니다. 인덱스 선택 또는 자격 증명을 쿼리 시간에만 사용할 수 있는 여러 인덱스 또는 사용자 대신 권한 부여 흐름이 있는 RAG 설정에서는 인덱스 개체를 한 번만 초기화할 수 없습니다. 이러한 시나리오에서는 이 최적화가 필요하지 않습니다.
엔드포인트 간 병렬 처리
Databricks는 시스템의 총 QPS를 늘리기 위해 다음 전략을 탐색하는 것이 좋습니다.
- 엔드포인트 간에 인덱스를 분할합니다. 각각 트래픽의 상당 부분을 수신하는 여러 인덱스가 있는 경우 별도의 엔드포인트에 호스트하여 더 높은 총 대역폭에 도달합니다.
- 엔드포인트 간에 인덱스를 복제합니다. 대부분의 트래픽이 단일 인덱스에 도달하면 여러 엔드포인트에서 복제합니다. 선형 QPS 이익을 위해 클라이언트 수준에서 트래픽을 균등하게 분할합니다.
부하 테스트를 사용하여 엔드포인트의 크기가 올바르게 조정되었는지 확인합니다.
부하 테스트는 다양한 트래픽 수준에서 벡터 검색 엔드포인트의 성능을 측정하여 실제 사용량을 시뮬레이션하고 프로덕션 요구 사항을 충족하도록 엔드포인트 크기를 올바르게 조정하는 데 도움이 됩니다. 부하 테스트를 만들고 실행하는 방법에 대한 자세한 내용은 벡터 검색 엔드포인트 에 대한 부하 테스트 구성을 참조하세요.