Как выбрать наиболее подходящий тип и размер CU для вашего бизнеса?
Вычислительный блок (Compute Unit, CU) в Zilliz Cloud означает аппаратные ресурсы, обслуживающие поисковые запросы и индексы. Zilliz Cloud предоставляет три типа CU: Performance-optimized, Capacity-optimized и Extended-Capacity CU. Каждый тип CU включает различные комбинации ресурсов CPU, памяти и хранилища для разных бизнес-потребностей. Поэтому выбор подходящих вариантов и размеров CU имеет решающее значение при настройке кластера Zilliz Cloud.
Performance-optimized CU
Performance-optimized CU идеально подходит для задач поиска по сходству, требующих быстрого времени отклика в миллисекундах с высокой пропускной способностью не менее 100 запросов в секунду (QPS). Каждый CU может обрабатывать около 1,5 миллиона 768-мерных векторов.
Этот тип CU необходим для следующих вариантов использования (но не ограничивается ими):
- Приложения генеративного ИИ
- Рекомендательные системы
- Поисковые системы
- Чат-боты
- Модерация контента
- Расширение базы знаний LLM
- Системы противодействия мошенничеству
Capacity-optimized CU
Если ваше приложение обрабатывает десятки миллионов векторов, рассмотрите использование Capacity-optimized CU. Каждый CU может обрабатывать около 5 миллионов 768-мерных векторов. Этот тип CU может хранить гораздо больше данных, чем Performance-optimized CU, с меньшей стоимостью, но также с более низкой производительностью.
Capacity-optimized CU особенно полезны для следующих сценариев (но не ограничиваются ими):
- Поиск по крупномасштабным неструктурированным данным, таким как текст, изображения, видео и молекулярные структуры
- Обнаружение нарушений авторских прав
- Проверка личностей.
Extended-Capacity CU
Extended-Capacity CU идеально подходит, если вас не беспокоит время отклика и у вас очень ограниченный бюджет. Каждый CU может обрабатывать 20 миллионов 768-мерных векторов по относительно разумной цене. Хотя у него более высокая задержка поиска, он может хранить до 4 раз больше данных, чем Capacity-optimized CU.
Этот тип CU идеально подходит для офлайн-задач, таких как:
- Разметка или кластеризация данных
- Дедупликация
- Обнаружение выбросов в наборе данных или балансировка классов.
Оценка трех типов CU
В таблице ниже представлен обзор различий между типами CU в Zilliz Cloud.
| Тип CU | Задержка | Пропускная способность | Емкость | Стоимость за миллион векторов (примечание: на основе 768-мерных векторов) |
|---|---|---|---|---|
| Performance-optimized | Низкая | Высокая | Низкая | От $65/месяц |
| Capacity-optimized | Средняя | Средняя | Средняя | От $20/месяц |
| Extended-Capacity CU | Высокая | Низкая | Высокая | От $10/месяц |
Сравнение производительности
Чтобы измерить производительность различных вариантов CU, мы рассмотрели два ключевых показателя: задержку поиска и пропускную способность. Мы протестировали три типа CU Zilliz Cloud, используя два набора данных с различными значениями topk (10, 100, 250, 1000). Первый набор данных состоит из 1 000 000 векторов размерности 768, а второй содержит 5 000 000 векторов той же размерности.
| top_k | / | / | 10 | 100 | 250 | 1000 |
|---|---|---|---|---|---|---|
| Задержка | Performance-optimized CU | 1M 768dim | <10ms | <10ms | <10ms | 10-20ms |
| Capacity-optimized CU | 5M 768dim | <50ms | <50ms | <50ms | 50-100ms | |
| Extended-Capacity CU |
Приведенная выше таблица показывает, что CU, оптимизированный для производительности, является лучшим выбором для низкой задержки, превосходя CU, оптимизированный для емкости. Он поддерживает задержку менее десяти миллисекунд для типичных значений topk от 10 до 250, что в пять-десять раз быстрее, чем у оптимизированного для емкости. При работе со значениями topk в тысячах задержка для каждого типа CU варьируется от 10 до 20 мс для CU, оптимизированного для производительности, и от 50 до 100 мс для CU, оптимизированного для емкости. Однако стоит отметить, что, хотя CU, оптимизированный для производительности, замедляет ответы при выполнении задач со значениями topk в тысячах, его задержка поиска все еще подходит для многих приложений реального времени.
| top_k | 10 | 100 | 250 | 1000 | ||
|---|---|---|---|---|---|---|
| QPS | Performance-optimized cu | 1M 768dim | 520 | 440 | 270 | 150 |
| Capacity-optimized CU | 5M 768dim | 100 | 80 | 60 | 40 | |
| Extended-Capacity CU |
Когда речь идет о пропускной способности, CU, оптимизированный для производительности, превосходит остальные. Он превосходит CU, оптимизированный для емкости, в четыре-пять раз.
Сравнение емкости
Мы протестировали три типа CU Zilliz Cloud, используя стандартный набор размерностей векторов: 128, 256, 512, 768 и 1024.
| Размерности векторов | Количество векторов на CU (миллионы) | Количество векторов на CU (миллионы) | Количество векторов на CU (миллионы) |
|---|---|---|---|
| / | CU, оптимизированный для производительности | CU, оптимизированный для емкости | CU с расширенной емкостью |
| 128 | 5 | 25 | Скоро появится |
| 256 | 2.96 | 14.87 | Скоро появится |
| 512 | 1.63 | 8.22 | Скоро появится |
| 768 | 1.5 | 5 | 20 |
| 1024 | 0.86 | 4.34 | Скоро появится |
На основе результатов тестирования в приведенной выше таблице мы обнаружили, что:
- CU с расширенной емкостью имеют наибольшую емкость при хранении 768-мерных векторов, в 13 раз и 4 раза больше, чем CU, оптимизированные для производительности и емкости, соответственно.
- По мере увеличения размерности векторов требуется больше места для хранения данных. Например, CU может хранить примерно вдвое больше 512-мерных векторов по сравнению с 1024-мерными векторами.
Примечание: Этот эксперимент был сосредоточен только на первичном ключе и векторах без добавления скалярных полей. Однако, если есть дополнительные скалярные поля, такие как id, label, keywords, summary, URL и т. д., фактическая емкость каждого типа CU может отличаться от приведенной выше таблицы. Поэтому для точности важно полагаться на эмпирические измерения.
Давайте рассмотрим несколько примеров!
Мы сравнили три варианта CU Zilliz Cloud с точки зрения задержки, пропускной способности, емкости и стоимости. Но как выбрать наиболее подходящий вариант для вашего бизнеса? Давайте рассмотрим два примера, которые помогут вам сделать правильный выбор.
Пример 1
Предположим, вы создаете чат-бота с дополнением LLM, который использует Zilliz Cloud для хранения более 10 миллионов текстовых фрагментов частных документов с embedding-вектором размерностью 768. Ваше приложение требует, чтобы Zilliz Cloud поддерживал 1 000 QPS и извлекал 10 лучших результатов с end-to-end задержкой менее 30 миллисекунд.
CU, оптимизированный для производительности, — единственный способ достичь задержки менее 30 мс. Поскольку каждый CU, оптимизированный для производительности, может содержать до 1,5 миллиона 768-мерных векторов, вам понадобится как минимум семь CU для обработки всех 10 миллионов векторов. Один CU может достигать пиковой QPS 520 по пропускной способности, когда значение topk равно 10. Чтобы обеспечить 1 000 QPS, вам понадобятся две реплики.
Следовательно, лучший подход для этого сценария — использовать две реплики CU, оптимизированного для производительности, каждая из которых содержит семь CU.
Пример 2
Предположим, ваше приложение обнаруживает нарушения авторских прав в изображениях и должно находить похожие среди пула из 100 миллионов. Каждое изображение встраивается в 768-мерный вектор. Вам не требуются ответы в реальном времени, но вы ожидаете топ-100 результатов с пропускной способностью 50 QPS.
И CU, оптимизированный по емкости, и CU, оптимизированный для производительности, могут обрабатывать 50 запросов в секунду при получении топ-100 результатов. Однако CU, оптимизированный по емкости, может хранить в три раза больше векторов, чем CU, оптимизированный для производительности. Следовательно, CU, оптимизированный по емкости, является более подходящим вариантом для ваших потребностей.
На основе результатов тестирования один CU, оптимизированный по емкости, может хранить до 5,6 миллиона 768-мерных векторов. Чтобы разместить ваши 100 миллионов векторов, вам потребуется минимум 20 CU. Когда значение topk равно 100, один CU может достигать пиковой QPS 80 по пропускной способности. Для 50 QPS достаточно одной реплики. Следовательно, вам понадобится кластер с 20 CU, оптимизированными по емкости.
Итоги
Zilliz Cloud предлагает три типа CU. Если вам нужно, чтобы ваше приложение было молниеносным и отзывчивым в реальном времени, стоит выбрать CU, оптимизированный для производительности. CU, оптимизированный по емкости, — лучший выбор для приложений, которым требуется хранить и извлекать десятки миллионов векторов. Если у вас ограниченный бюджет и вы готовы пожертвовать скоростью и пропускной способностью, CU с расширенной емкостью идеально вам подойдет.
Начало работы с Zilliz Cloud
Изучите наш бесплатный тариф (кредитная карта не требуется) или попробуйте нашу 30-дневную корпоративную пробную версию с кредитами до $200. Оформите подписку через любой облачный маркетплейс и получите дополнительный кредит в размере $100.
Узнайте больше в документации Zilliz Cloud.
Читать далее
My Wife Wanted Dior. I Spent $600 on Claude Code to Vibe-Code a 2M-Line Database Instead.
Write tests, not code reviews. How a test-first workflow with 6 parallel Claude Code sessions turns a 2M-line C++ codebase into a daily shipping pipeline.
Zilliz Cloud Update: Tiered Storage, Business Critical Plan, Cross-Region Backup, and Pricing Changes
This release offers a rebuilt tiered storage with lower costs, a new Business Critical plan for enhanced security, and pricing updates, among other features.
Vector Databases vs. Hierarchical Databases
Use a vector database for AI-powered similarity search; use a hierarchical database for organizing data in parent-child relationships with efficient top-down access patterns.