# 256 ГБ RAM для RAG: когда объём оправдан индексом и нагрузкой

Как оценить 256 ГБ RAM для RAG: число векторов, размерность, тип данных, индексы, payload, реплики, обновление и запас под реальные запросы.

Автор: Команда Retrivium
Обновлено: 2026-11-01
Канонический URL: https://retrivium.ai/ru/journal/server-256gb-ram-rag/
Language: ru

Серверу RAG нужны 256 ГБ RAM только тогда, когда такой объём обоснован индексом, данными, параллельностью и режимом обновления. Сначала считают отдельные структуры и измеряют репрезентативную коллекцию. Само название RAG не задаёт обязательный размер памяти.

Если сервер с такой ёмкостью уже есть, он может стать ресурсом для поискового пилота. При этом большая RAM не превращается в VRAM генеративной модели и не устраняет требования к CPU, накопителям и организации запросов.

## Опишите структуру поиска

Укажите число фрагментов, размерность вектора, тип данных, дополнительные векторы, поля документов и фильтры. Разделите исходные тексты и поисковые представления. Один документ может дать несколько фрагментов и несколько векторов, поэтому число файлов редко равно числу записей индекса.

[Qdrant Capacity Planning](https://qdrant.tech/documentation/capacity-planning/) рассматривает память и диск по отдельным структурам. Такое описание полезнее универсального правила «столько-то RAM на документ»: параметры коллекции и репликация меняют расчёт.

## Соберите бюджет компонентов

| Компонент | Основание оценки | Что уточнить |
| --- | --- | --- |
| Плотные векторы | Число, размерность, байты элемента | Несколько представлений |
| Поисковый индекс | Тип и параметры графа | Фактический размер |
| Поля документов | Размер payload и индексы | Нужные фильтры |
| Реплики | Выбранное число копий | Распределение по узлам |
| Рабочий запас | Обновления и запросы | Пиковую нагрузку |
| Другие процессы | Система и соседние сервисы | Реально доступную RAM |

Не прибавляйте к памяти сервера объём другого узла без описанной распределённой архитектуры. Общая ёмкость нескольких машин и вместимость одного процесса — разные границы.

## Проведите условный расчёт базы

Предположим для примера миллион векторов размерности 768 с элементами по четыре байта. Только исходные значения займут 3 072 000 000 байт до индекса, полей, копий и рабочих расходов. Это арифметическая иллюстрация, а не итоговый размер коллекции.

Из такого числа нельзя сразу заключить, нужны ли 256 ГБ RAM. Сначала добавляют остальные структуры и выбранное размещение. Формат единиц также сохраняют: десятичные гигабайты и двоичные гибибайты дают разные числовые значения.

## Проверьте размещение и обновление

[Документация Qdrant о memory tiers](https://qdrant.tech/documentation/ops-configuration/memory-tiers/) различает способы удержания структур в памяти и обращения к диску. Доступные настройки зависят от версии. Хранение на диске не означает отсутствие влияния RAM, кэша и случайных чтений на задержку.

Измерьте загрузку, построение индекса, типичные запросы и обновление коллекции. Пик во время перестройки может отличаться от спокойного поиска. Проверьте фильтры и число одновременных запросов: одинаковый индекс даёт разные условия работы при другой очереди.

## Примите решение по измерениям

Если память остаётся свободной, оцените возможность отдельных поисковых задач или изолированных коллекций, сохраняя границы данных. Не заполняйте сервер только ради процента использования. Цель — предсказуемый поиск с проверенным качеством и временем ответа.

Материалы о [серверах с большой RAM](/ru/journal/memory-optimized-hosting/) и [GPU для эмбеддингов и reranker](/ru/journal/embeddings-rerankers-gpu/) помогают разделить этапы RAG.