# Локальный RAG-сервер: какие компоненты размещать рядом с GPU

Локальный RAG-сервер для документов: компоненты индексации и поиска, место GPU, RAM и NVMe, внешние зависимости, обновление корпуса и контроль полезного результата.

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

Локальный RAG-сервер связывает поиск по вашим документам с генерацией ответа моделью. Для выбора оборудования нужно описать весь путь: подготовку текстов, расчёт эмбеддингов, хранение индекса, поиск, повторную оценку и формирование ответа. Покупка GPU решает только ту часть, где выбранный движок действительно использует ускоритель.

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

## Разделите подготовку и пользовательский запрос

[Sentence Transformers Semantic Search](https://www.sbert.net/examples/sentence_transformer/applications/semantic-search/README.html) описывает представление документов и запросов в сопоставимом векторном пространстве. Большую часть документов можно обработать заранее, тогда как пользовательский запрос требует ответа в момент обращения.

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

## Назначьте ресурс каждому этапу

| Этап | Что измерять при выборе сервера |
| --- | --- |
| Извлечение текста | CPU, память и скорость обработки файлов |
| Эмбеддинги | Размер модели, batch и пропускную способность |
| Векторный индекс | RAM, диск, фильтры и задержку поиска |
| Reranking | Число пар и длину передаваемых текстов |
| Генерация | VRAM, контекст, параллелизм и время ответа |

Эта таблица не назначает GPU обязательным для всех строк. Конкретный backend и профиль нагрузки определяют, какой этап выигрывает от ускорителя и где находится фактическое ограничение.

## Проверьте границу локальности

Локальная база не делает весь RAG автоматически автономным. Внешними могут оставаться embedding API, генератор ответа, OCR или скачивание моделей. Составьте карту сетевых обращений и подтвердите, какие данные покидают вашу площадку.

Для пилота используйте искусственные или разрешённые документы. Сохраните модельные файлы и версии, если сценарий требует работы без внешней сети. Автономность нужно проверять отдельным запуском в соответствующих условиях, а не выводить из расположения одного контейнера.

## Оцените поиск отдельно от красивого ответа

[Qdrant Retrieval Relevance](https://qdrant.tech/documentation/search-evaluation/retrieval-relevance/) объясняет метрики релевантности поиска. Подготовьте небольшой набор вопросов с известными полезными фрагментами. Сначала проверьте, попадают ли они в кандидаты, затем оценивайте итоговую генерацию.

Если нужного документа нет в найденном контексте, увеличение модели ответа не исправляет первичную проблему автоматически. Результат такого теста помогает направить бюджет на разбиение документов, индекс или reranker, вместо покупки GPU без подтверждённого основания.

## Проверьте обновление и восстановление

Измените один тестовый документ, удалите другой и повторите поиск. Убедитесь, что устаревшие сведения не продолжают использоваться без отметки. Сохраните соответствие версии корпуса, модели эмбеддингов и индекса: эти компоненты должны восстанавливаться согласованно.

Далее пригодятся [RAM для RAG](/ru/journal/high-ram-rag-servers/) и [повторная оценка кандидатов](/ru/journal/reranker-rag-latency/).