¿Cómo seleccionar el tipo y tamaño de CU más adecuado para su empresa?
Una Unidad de Cómputo (CU) en Zilliz Cloud se refiere a los recursos de hardware que atienden solicitudes de búsqueda e índices. Zilliz Cloud proporciona tres tipos de CU: Performance-optimized, Capacity-optimized, y Extended-Capacity CU. Cada tipo de CU comprende diferentes combinaciones de recursos de CPU, memoria y almacenamiento para distintas necesidades empresariales. Por lo tanto, seleccionar las opciones y tamaños de CU apropiados es crucial al configurar un clúster de Zilliz Cloud.
CU Performance-optimized
Una CU performance-optimized es ideal para tareas de recuperación por similitud que requieren un tiempo de respuesta rápido en milisegundos con un alto rendimiento de al menos 100 consultas por segundo (QPS). Cada CU puede gestionar alrededor de 1,5 millones de vectores de 768 dimensiones.
Este tipo de CU es esencial para (entre otros) los siguientes casos de uso:
- Aplicaciones de IA generativa
- Sistemas de recomendación
- Motores de búsqueda
- Chatbots
- Moderación de contenido
- Ampliación de la base de conocimientos de los LLM
- Sistemas antifraude
CU Capacity-optimized
Si tu aplicación gestiona decenas de millones de vectores, considera usar una CU capacity-optimized. Cada CU puede gestionar alrededor de 5 millones de vectores de 768 dimensiones. Este tipo de CU puede almacenar muchos más datos que una CU performance-optimized con un costo menor, pero también con un rendimiento menor.
Las CU capacity-optimized son particularmente útiles para (entre otros) los siguientes escenarios:
- Búsqueda en datos no estructurados a gran escala, como texto, imágenes, videos y estructuras moleculares
- Detección de infracciones de derechos de autor
- Verificación de identidades.
CU Extended-Capacity
La CU Extended-Capacity es ideal si no te preocupa el tiempo de respuesta y tienes un presupuesto muy ajustado. Cada CU puede gestionar 20 millones de vectores de 768 dimensiones con un precio relativamente razonable. Aunque tiene una mayor latencia de búsqueda, puede contener hasta 4 veces más datos que una CU capacity-optimized.
Este tipo de CU es perfecto para tareas sin conexión como:
- Etiquetado o agrupamiento de datos
- Deduplicación
- Detección de valores atípicos en conjuntos de datos o equilibrio de clases.
Evaluación de tres tipos de CU
La siguiente tabla proporciona una descripción general de las diferencias entre los tipos de CU de Zilliz Cloud.
| Tipo de CU | Latencia | Rendimiento | Capacidad | Costo por millón de vectores (nota: basado en vectores de 768 dimensiones) |
|---|---|---|---|---|
| Performance-optimized | Baja | Alto | Baja | Desde $65/mes |
| Capacity-optimized | Media | Medio | Media | Desde $20/mes |
| Extended-Capacity CU | Alta | Bajo | Alta | Desde $10/mes |
Comparación de rendimiento
Para medir el rendimiento de diferentes opciones de CU, analizamos dos indicadores clave: latencia de búsqueda y rendimiento. Probamos los tres tipos de CU de Zilliz Cloud usando dos conjuntos de datos con varios valores de topk (10, 100, 250, 1000). El primer conjunto de datos consta de 1.000.000 de vectores con 768 dimensiones, y el segundo tiene 5.000.000 de vectores con la misma dimensión.
| top_k | / | / | 10 | 100 | 250 | 1000 |
|---|---|---|---|---|---|---|
| Latencia | CU Performance-optimized | 1M 768dim | <10ms | <10ms | <10ms | 10-20ms |
| CU Capacity-optimized | 5M 768dim | <50ms | <50ms | <50ms | 50-100ms | |
| Extended-Capacity CU |
La tabla anterior muestra que la CU optimizada para rendimiento es la mejor opción para una baja latencia, superando a la CU optimizada para capacidad. Mantiene una latencia inferior a diez milisegundos para valores típicos de topk de 10-250, de cinco a diez veces más rápida que la optimizada para capacidad. Al tratar con valores de topk en los miles, la latencia de cada tipo de CU varía de 10-20 ms para la CU optimizada para rendimiento y de 50-100 ms para la CU optimizada para capacidad. Sin embargo, vale la pena señalar que, aunque la CU optimizada para rendimiento se ralentiza en las respuestas al realizar tareas con valores detopk en los miles, su latencia de búsqueda sigue siendo adecuada para muchas aplicaciones en tiempo real.
| top_k | 10 | 100 | 250 | 1000 | ||
|---|---|---|---|---|---|---|
| QPS | CU optimizada para rendimiento | 1M 768dim | 520 | 440 | 270 | 150 |
| CU optimizada para capacidad | 5M 768dim | 100 | 80 | 60 | 40 | |
| CU de capacidad extendida |
En cuanto al rendimiento, la CU optimizada para rendimiento es superior. Supera a la CU optimizada para capacidad entre cuatro y cinco veces.
Comparación de capacidad
Probamos los tres tipos de CU de Zilliz Cloud utilizando un conjunto estándar de dimensiones vectoriales: 128, 256, 512, 768 y 1024.
| Dimensiones vectoriales | Número de vectores por CU (millones) | Número de vectores por CU (millones) | Número de vectores por CU (millones) |
|---|---|---|---|
| / | CU optimizada para rendimiento | CU optimizada para capacidad | CU de capacidad extendida |
| 128 | 5 | 25 | Próximamente |
| 256 | 2.96 | 14.87 | Próximamente |
| 512 | 1.63 | 8.22 | Próximamente |
| 768 | 1.5 | 5 | 20 |
| 1024 | 0.86 | 4.34 | Próximamente |
Según el resultado de las pruebas en la tabla anterior, encontramos que:
- Las CU de capacidad extendida tienen las mayores capacidades para almacenar vectores de 768 dimensiones, 13 veces y 4 veces mayores que las CU optimizadas para rendimiento y optimizadas para capacidad, respectivamente.
- A medida que aumentan las dimensiones vectoriales, se necesita más espacio de almacenamiento para contener los datos. Por ejemplo, una CU puede almacenar aproximadamente el doble de vectores de 512 dimensiones en comparación con vectores de 1024 dimensiones.
Nota: Este experimento solo se centró en la clave primaria y los vectores, sin agregar campos escalares. Sin embargo, si hay campos escalares adicionales como id, etiqueta, palabras clave, resumen, URL, etc., la capacidad real de cada tipo de CU puede diferir de la tabla anterior. Por lo tanto, es esencial basarse en mediciones empíricas para lograr precisión.
¡Veamos algunos ejemplos!
Hemos comparado las tres opciones de CU de Zilliz Cloud desde la perspectiva de la latencia, el rendimiento, la capacidad y el costo. Pero ¿cómo eliges la opción más adecuada para tu negocio? Veamos dos ejemplos para ayudarte a tomar la decisión correcta.
Ejemplo 1
Supongamos que estás creando un chatbot aumentado con LLM que adopta Zilliz Cloud para almacenar más de 10 millones de fragmentos de texto de documentos privados con un vector de incrustación de 768 dimensiones. Tu aplicación requiere que Zilliz Cloud admita 1,000 QPS y recupere los 10 mejores resultados con una latencia de extremo a extremo inferior a 30 milisegundos.
Una CU optimizada para el rendimiento es la única forma de lograr una latencia inferior a 30 ms. Dado que cada CU optimizada para el rendimiento puede contener hasta 1,5 millones de vectores de 768 dimensiones, necesitarás al menos siete CUs para gestionar los 10 millones de vectores. Una CU puede alcanzar un QPS máximo de 520 para el rendimiento cuando el valor de topk es 10. Para alcanzar 1.000 QPS, necesitarás dos réplicas.
Por lo tanto, el mejor enfoque para este escenario es usar dos réplicas de una CU optimizada para el rendimiento, cada una con siete CUs.
Ejemplo 2
Supongamos que tu aplicación detecta infracciones de derechos de autor en imágenes y necesita encontrar imágenes similares en un grupo de 100 millones. Cada imagen se incrusta en un vector de 768 dimensiones. No necesitas respuestas en tiempo real, pero esperas los 100 mejores resultados con un rendimiento de 50 QPS.
Tanto la CU optimizada para capacidad como la CU optimizada para rendimiento pueden gestionar 50 solicitudes por segundo cuando recuperas los 100 mejores resultados. Sin embargo, la CU optimizada para capacidad puede almacenar tres veces más vectores que la CU optimizada para rendimiento. Por lo tanto, la CU optimizada para capacidad es la opción más adecuada para tus necesidades.
Según los resultados de las pruebas, una sola CU optimizada para capacidad puede almacenar hasta 5,6 millones de vectores de 768 dimensiones. Para alojar tus 100 millones de vectores, necesitarás un mínimo de 20 CUs. Cuando el valor de topk es 100, una sola CU puede alcanzar un QPS máximo de 80 para el rendimiento. Para 50 QPS, una réplica es suficiente. Por lo tanto, necesitarás un clúster con 20 CUs optimizadas para capacidad.
Resumen
Zilliz Cloud ofrece tres tipos de CUs. Si necesitas que tu aplicación sea ultrarrápida y responda en tiempo real, la CU optimizada para rendimiento es la opción indicada. La CU optimizada para capacidad es la mejor opción para aplicaciones que requieren almacenar y recuperar decenas de millones de vectores. Si tienes un presupuesto ajustado y no te importa sacrificar velocidad y rendimiento, la CU de capacidad extendida es perfecta para ti.
Introducción a Zilliz Cloud
Explora con nuestro nivel gratuito (no se requiere tarjeta de crédito), o prueba nuestra prueba empresarial de 30 días con hasta $200 en créditos. Suscríbete a través de cualquier cloud marketplace y recibe un crédito adicional de $100.
Profundiza en la documentación de Zilliz Cloud.
Sigue leyendo
Zilliz Cloud BYOC Now Available Across AWS, GCP, and Azure
Zilliz Cloud BYOC is now generally available on all three major clouds. Deploy fully managed vector search in your own AWS, GCP, or Azure account — your data never leaves your VPC.
What is the K-Nearest Neighbors (KNN) Algorithm in Machine Learning?
KNN is a supervised machine learning technique and algorithm for classification and regression. This post is the ultimate guide to KNN.
DeepSeek Always Busy? Deploy It Locally with Milvus in Just 10 Minutes—No More Waiting!
Learn how to set up DeepSeek-R1 on your local machine using Ollama, AnythingLLM, and Milvus in just 10 minutes. Bypass busy servers and enhance AI responses with custom data.