100 млн векторов в float32 - это примерно 768 ГБ RAM. На AWS такой объём памяти обходится ориентировочно в $6000 в месяц. Рост индекса до 1 млрд векторов увеличивает потребность до 7.68 ТБ и ежемесячный счёт до $60,000. RAM-хранение становится доминирующим фактором стоимости AI-инфраструктуры, опережая затраты на compute в несколько раз. Классический HNSW требует держать весь индекс в памяти, и на масштабах от 100 млн векторов это перестаёт быть экономически оправданным.
Гибридные алгоритмы SPANN и DiskANN решают проблему, вынося сырые векторы на SSD. SPANN снижает затраты на RAM до 50 раз, сохраняя latency около 1 мс в тёплом кэше. DiskANN даёт более стабильную latency при умеренной экономии. Выбор между тремя подходами - HNSW, SPANN и DiskANN - сводится к компромиссу между бюджетом, допустимой задержкой и размером индекса. В этом материале разбираем архитектуру каждого алгоритма, считаем реальную стоимость и даём дерево решений для выбора под вашу задачу.
Цена масштаба: почему RAM становится главной статьёй расходов в векторном поиске
Векторный поиск лежит в основе рекомендательных систем, семантического поиска, детекции аномалий и RAG-пайплайнов. С ростом объёмов данных индексы переваливают за сотни миллионов векторов. Каждый вектор в формате float32 с размерностью 768 (типичная для эмбеддингов BERT) занимает 3 КБ. Умножаем на 100 млн - получаем 300 ГБ чистых данных. С учётом накладных расходов на структуру индекса реальное потребление RAM приближается к 768 ГБ.
На AWS инстанс r6g.16xlarge с 512 ГБ RAM стоит около $3,300/мес. Для 100 млн векторов нужно два таких инстанса - $6,600/мес. Для 1 млрд векторов - 7.68 ТБ - счёт приближается к $60,000 ежемесячно. Это цена только за память, без учёта compute. Для стартапа или продукта на стадии роста такие расходы часто неприемлемы. Проблема обостряется тем, что RAM - дефицитный ресурс в облаках: объёмы свыше 1 ТБ доступны на ограниченном числе инстансов, и их стоимость растёт нелинейно.
Классический HNSW хранит многоуровневый граф связей между векторами целиком в оперативной памяти. Это даёт минимальную latency - менее 10 мс на поиск - но делает стоимость владения индексом прямо пропорциональной его размеру. Когда RAM становится главной статьёй расходов, архитектуру приходится пересматривать. Гибридные подходы - SPANN и DiskANN - разделяют данные между RAM и SSD, радикально меняя экономику векторного поиска. О том, как устроены современные AI-пайплайны и какие ещё факторы влияют на стоимость инференса, мы рассказывали в разборе новых Azure VM на AMD.
Три подхода к приближённому поиску: HNSW, SPANN и DiskANN - архитектура и компромиссы
Три алгоритма образуют спектр по оси «RAM-зависимость - стоимость». HNSW располагается на одном полюсе: весь граф в RAM, минимальная latency, максимальная цена. SPANN - на противоположном: центроиды кластеров в RAM, сырые векторы на SSD, до 50 раз дешевле, но latency зависит от кэша. DiskANN занимает промежуточную позицию: граф Vamana в RAM, векторы на диске, баланс стоимости и предсказуемости. Разберём каждый.
HNSW: эталон скорости, который съедает бюджет
Hierarchical Navigable Small World строит многоуровневый граф, где каждый уровень - приближение к полному графу ближайших соседей. Верхние уровни содержат мало вершин и используются для быстрой навигации, нижний уровень - полный граф всех векторов. При поиске алгоритм спускается с верхнего уровня, на каждом шаге переходя к ближайшим соседям, пока не достигнет целевой области.
Вся структура - и граф, и векторы - находится в RAM. Это даёт latency <10 мс даже на индексах в сотни миллионов векторов. Плата - линейный рост потребления памяти. 100 млн векторов: ~768 ГБ RAM, ~$6000/мес. 1 млрд векторов: ~7.68 ТБ RAM, ~$60,000/мес. HNSW оправдан, когда бюджет не критичен, а задержка жёстко ограничена: real-time рекомендации в e-commerce, финансовый фрод-мониторинг, поиск по лицам в системах безопасности. Для небольших индексов до 10 млн векторов HNSW остаётся стандартом де-факто - простота настройки и предсказуемая производительность перевешивают затраты.
SPANN: как вынести векторы на диск и сэкономить до 50×
SPANN (Space-Partitioned Approximate Nearest Neighbors) разделяет пространство векторов на кластеры методом k-means. Центроиды кластеров и метаданные хранятся в RAM - это компактная структура, занимающая мегабайты даже для миллиарда векторов. Сами векторы лежат на SSD, сгруппированные по кластерам в последовательные блоки.
Поиск работает в два этапа. Сначала алгоритм находит ближайшие центроиды в RAM - это быстро, так как их мало. Затем читает с диска блоки векторов, соответствующие выбранным кластерам, и вычисляет точные расстояния. Поскольку векторы одного кластера лежат на диске последовательно, чтение эффективно - одно обращение к SSD вместо множества случайных.
Экономия радикальна. Для 1 млрд векторов RAM-затраты падают с ~$60,000 до ~$1,200/мес - в 50 раз. Остальная память заменяется SSD: 7.68 ТБ на NVMe-диске обходятся примерно в $500-800/мес. Суммарно - около $2,000/мес против $60,000 у HNSW. Latency в тёплом кэше - около 1 мс. При холодном кэше первый запрос может занять 10-20 мс, пока данные подтянутся с диска в page cache. Для сервисов с устойчивым потоком запросов кэш прогревается быстро, и latency стабилизируется. Для эпизодических запросов холодный старт становится проблемой.
SPANN требует настройки числа кластеров и размера блока. Слишком мало кластеров - большие блоки на диске, долгое чтение. Слишком много - растёт потребление RAM под центроиды и время на первый этап поиска. Типичная рекомендация: 1-5% векторов в роли центроидов, но точное значение подбирается под данные. Тестирование на своём корпусе обязательно.
DiskANN: граф Vamana на диске - баланс стоимости и предсказуемости
DiskANN строит граф Vamana - разреженный граф ближайших соседей, оптимизированный для хранения на диске. В отличие от HNSW, где граф плотный и требует много RAM, Vamana минимизирует количество рёбер, сохраняя достижимость любой вершины за небольшое число шагов. Граф хранится в RAM, векторы - на SSD.
При поиске алгоритм движется по графу в RAM, определяя, какие области диска нужно прочитать. Затем точечно загружает векторы-кандидаты с SSD. Ключевая оптимизация: рёбра графа строятся так, чтобы минимизировать случайные чтения с диска. Векторы, которые часто запрашиваются вместе, располагаются на диске рядом.
Стоимость RAM для 1 млрд векторов: граф Vamana занимает примерно 10-20% от объёма сырых векторов. При 7.68 ТБ данных граф потребует 0.8-1.5 ТБ RAM - около $10,000-15,000/мес. Это дороже SPANN, но в 4-6 раз дешевле HNSW. Latency стабильнее, чем у SPANN, так как граф направляет к нужным областям диска, а не зависит от попадания в кэш. Типичная задержка - 2-5 мс.
DiskANN сложнее в настройке, чем HNSW. Параметры: максимальная степень вершины в графе (влияет на размер RAM и точность), размер beam search при построении графа, число итераций оптимизации. Разработчики Microsoft, создавшие DiskANN, предоставляют референсную реализацию с разумными значениями по умолчанию, но для production-нагрузок параметры требуют тюнинга.
Сравнительная таблица: HNSW vs SPANN vs DiskANN - стоимость, скорость, масштаб
| Параметр | HNSW | SPANN | DiskANN |
|---|---|---|---|
| RAM на 100 млн векторов | ~768 ГБ | ~5-10 ГБ (центроиды) | ~80-150 ГБ (граф) |
| RAM на 1 млрд векторов | ~7.68 ТБ | ~20-50 ГБ (центроиды) | ~0.8-1.5 ТБ (граф) |
| Стоимость/мес (100 млн) | ~$6,000 | ~$120-200 + SSD | ~$1,000-2,000 + SSD |
| Стоимость/мес (1 млрд) | ~$60,000 | ~$1,200-2,000 + SSD | ~$10,000-15,000 + SSD |
| Типичная latency | <10 мс | ~1 мс (тёплый кэш), 10-20 мс (холодный) | 2-5 мс |
| Зависимость от кэша | Нет (всё в RAM) | Высокая | Низкая |
| Сложность настройки | Низкая | Средняя | Высокая |
Цифры по стоимости - ориентировочные, рассчитаны для AWS us-east-1 по состоянию на июль 2026. Реальные значения зависят от провайдера, региона и конфигурации инстансов. Для SPANN и DiskANN к затратам на RAM нужно добавить стоимость NVMe-дисков: ~$500-800/мес за 7.68 ТБ.
Как выбрать алгоритм: дерево решений по размеру индекса, бюджету и latency
Выбор алгоритма сводится к трём вопросам: размер индекса, допустимая задержка, месячный бюджет на инфраструктуру. Дерево решений для типичных сценариев:
- Индекс до 10 млн векторов. HNSW. Затраты на RAM - $300-600/мес, что редко становится проблемой. Настройка тривиальна, latency минимальна. Не усложняйте архитектуру без необходимости.
- Индекс 10-100 млн, бюджет ограничен. DiskANN. Стоимость в 3-6 раз ниже HNSW при latency 2-5 мс. Подходит для e-commerce поиска, где 5 мс - приемлемая задержка, а $6,000/мес за HNSW - перебор.
- Индекс >100 млн, latency не критична (до 20 мс). SPANN. Радикальная экономия: $2,000/мес вместо $60,000. Сценарий: семантический поиск по корпусу документов, где пользователь готов подождать 10-20 мс. Прогрев кэша через фоновые запросы или синтетическую нагрузку решает проблему холодного старта.
- Индекс >100 млн, нужна стабильная низкая latency (<5 мс). DiskANN с оптимизацией размера графа. Дороже SPANN, но latency не скачет при холодном кэше. Сценарий: поиск по изображениям в стоковом сервисе, где задержка напрямую влияет на конверсию.
- Сервис с редкими запросами. Оцените частоту. Если запросы приходят реже, чем раз в несколько минут, кэш SPANN будет постоянно холодным, и latency составит 10-20 мс. DiskANN или даже HNSW (если индекс небольшой) могут быть предпочтительнее.
Примеры сценариев из практики. Рекомендательная система маркетплейса с 50 млн товаров: индексы эмбеддингов товаров и пользователей, latency критична для real-time рекомендаций - HNSW оправдан, $3,000/мес за RAM укладывается в бюджет. Поисковая система по 500 млн научных статей: пользователь вводит запрос и ждёт результаты - SPANN с latency 10 мс в тёплом кэше даёт экономию в десятки тысяч долларов. Система поиска похожих изображений для 200 млн картинок: latency важна, но бюджет ограничен - DiskANN даёт 3-4 мс при умеренных затратах. О том, как сжатие моделей меняет требования к инфраструктуре, читайте в разборе метода REAP от Nota AI.
Подводные камни и ограничения: что нужно знать перед миграцией с HNSW
SPANN и DiskANN решают проблему стоимости RAM, но вносят свои сложности. Холодный кэш - главный недостаток SPANN. Первый запрос после развёртывания или долгой паузы читает векторы с диска, и latency подскакивает до 10-20 мс. Решение: прогрев кэша фоновым потоком запросов, имитирующим реальную нагрузку, или использование NVMe-дисков с высоким IOPS (рекомендуется минимум 100K случайных чтений в секунду).
Кластеризация в SPANN требует подбора числа кластеров. Слишком мало кластеров - большие блоки на диске, каждое чтение дорого. Слишком много - растёт время на поиск ближайших центроидов и потребление RAM. Оптимальное значение зависит от распределения векторов: для равномерного распределения работает правило «число кластеров = sqrt(N)», для кластеризованных данных - больше. Без тестирования на своём корпусе не обойтись.
DiskANN сложнее в настройке, чем HNSW. Параметр max_degree определяет размер графа в RAM и точность поиска. Высокое значение улучшает recall, но увеличивает потребление памяти. Параметр L при построении графа влияет на время индексации: для 1 млрд векторов построение индекса может занять несколько дней на мощном инстансе. Для продакшена DiskANN требует мониторинга recall@k и latency, особенно после добавления новых векторов - граф нужно перестраивать или дополнять инкрементально.
Для индексов меньше 1 млн векторов гибридные решения избыточны. HNSW проще, быстрее в настройке и даёт latency <5 мс без всяких компромиссов. Переход на SPANN или DiskANN оправдан, когда счёт за RAM становится заметной строкой в бюджете - обычно это порог в 10-50 млн векторов, в зависимости от маржинальности продукта.
Заключение: RAM-эффективный векторный поиск как конкурентное преимущество
Счёт за RAM растёт линейно с размером индекса, а для HNSW - с коэффициентом, который делает миллиардные индексы экономически нецелесообразными. Выбор правильного ANN-алгоритма напрямую влияет на юнит-экономику продукта. HNSW - инструмент для небольших масштабов и жёстких требований к latency. SPANN - способ радикально снизить затраты на больших объёмах, принимая риск холодного кэша. DiskANN - золотая середина для тех, кому нужна стабильная latency при ограниченном бюджете.
Цифры из этой статьи - ориентир. Реальные затраты зависят от облачного провайдера, региона, конфигурации инстансов и паттерна нагрузки. Тестируйте на своих данных, замеряйте recall и latency под реальной нагрузкой, считайте TCO с учётом стоимости настройки и поддержки. Технологии не стоят на месте: квантование векторов (int8, двоичные эмбеддинги) снижает требования к памяти ещё в 2-4 раза, а алгоритмы сжатия индексов продолжают эволюционировать. Сравнение актуальных моделей и их требований к инфраструктуре мы даём в тесте Qwen3.5 122B против Qwen3 Next 80B.