Локальная RAG-система: когда она оправдана, а когда нет

RAG (Retrieval-Augmented Generation) дополняет запрос данными из внутренней базы знаний и передаёт их языковой модели. В локальной системе документы, поиск и LLM работают внутри инфраструктуры организации.

Разберём, когда такой подход оправдан, чем он отличается от облачного API и какое оборудование потребуется для пилота, команды или корпоративного сервиса.

Когда локальная RAG-система оправдана

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

Работа с конфиденциальными данными и коммерческой тайной

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

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

Это особенно важно при работе с внутренними договорами, технической документацией, финансовыми отчётами и другими закрытыми материалами. Однако установка сервисов на собственный GPU-сервер ещё не создаёт режим коммерческой тайны. Организация должна определить перечень защищаемой информации, ограничить доступ и принять другие меры, предусмотренные статьёй 10 Федерального закона № 98-ФЗ.

Перед внедрением необходимо проверить весь маршрут данных. Телеметрия, резервные копии, внешние сервисы для построения эмбеддингов и инструменты мониторинга могут передавать сведения сторонним системам, даже если основная LLM работает локально.

Требования 152-ФЗ и отраслевой комплаенс

Федеральный закон № 152-ФЗ не требует размещать любую RAG-систему на собственном оборудовании. Статья 19 обязывает оператора принимать правовые, организационные и технические меры защиты персональных данных. При их сборе, в том числе через интернет, часть 5 статьи 18 запрещает использовать для записи, систематизации, накопления, хранения, уточнения и извлечения данных граждан РФ базы данных за пределами России, кроме предусмотренных законом исключений.

Локальное развёртывание упрощает контроль над местом хранения, сетевыми подключениями и доступом сотрудников, но само по себе не гарантирует соответствия закону. Необходимо определить категории обрабатываемых данных, актуальные угрозы безопасности, требуемый уровень защищённости персональных данных в ИСПДн и необходимые меры защиты. Российское облако также может соответствовать этим требованиям, если его инфраструктура, договорные условия и средства защиты подходят для конкретной информационной системы.

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

Высокая и стабильная нагрузка

Облачный API удобен при небольшом количестве запросов: организация платит за фактическое использование и не закупает собственные ускорители. По мере роста нагрузки увеличиваются расходы на входные и выходные токены, построение эмбеддингов, хранение индекса и дополнительные сервисы.

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

Универсального количества запросов, после которого локальный ИИ становится выгоднее облака, не существует. Для расчёта TCO нужно сопоставить:

• число запросов за месяц;
• средний объём входных и выходных токенов;
• стоимость используемого облачного API;
• размер и квантование модели;
• стоимость оборудования и срок его эксплуатации;
• расходы на электроэнергию, поддержку и резервирование.

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

Изолированный контур и офлайн-работа

Внешний API не подходит для систем, которым запрещён доступ в интернет или требуется работа при отсутствии связи. В таком случае внутри защищённого контура размещают весь набор компонентов: модель эмбеддингов, векторное хранилище, модуль поиска, модуль повторного ранжирования и LLM.

Такая архитектура позволяет создать приватный ИИ-ассистент для закрытой сети, удалённого объекта или внутренней информационной системы. Обновления моделей и документов при этом нужно переносить контролируемым способом, а мониторинг, резервное копирование и восстановление организовывать собственными силами.

Когда локальная RAG-система не оправдана

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

Пилот, MVP или нерегулярная нагрузка

На этапе пилота важнее проверить не сервер, а сам сценарий:

• подходят ли исходные документы для поиска;
• правильно ли работает чанкинг;
• находит ли модуль поиска релевантные фрагменты;
• нужен ли реранкинг;
• устраивает ли пользователей точность ответов;
• подтверждает ли модель ответы ссылками на источники.

Для такой проверки облачный API позволяет не закупать оборудование до подтверждения пользы проекта. Векторная база данных и другие компоненты при этом могут работать локально, а через API будет вызываться только языковая модель. Конкретную схему выбирают с учётом допустимых каналов передачи данных.

Если приватный ИИ-ассистент используется несколько раз в день или нагрузка резко меняется, собственный GPU может большую часть времени простаивать. В этом случае плата за фактическое использование облачной модели часто рациональнее покупки сервера.

Нет своей DevOps- или MLOps-команды

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

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

Без ответственных специалистов RAG-система постепенно устаревает: документы обновляются не вовремя, права доступа расходятся с корпоративными системами, а сбои остаются незамеченными. В управляемом облачном решении часть инфраструктурных задач берёт на себя провайдер, но качество базы знаний и результатов поиска всё равно контролирует заказчик.

Важна скорость запуска, а не полный контроль

Облачные сервисы предоставляют готовый API и позволяют менять модель без замены собственного оборудования. Это удобно для демонстрации, внутреннего прототипа или проекта с коротким сроком запуска.

Компромиссный вариант — гибридная архитектура. Документы, эмбеддинги и векторная база данных остаются в инфраструктуре организации, а генерация ответа выполняется через внешний API. Перед внедрением нужно проверить, какие именно сведения передаются поставщику: вместе с вопросом модель обычно получает найденные фрагменты документов.

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

Ограничен CAPEX-бюджет

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

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

Закупать сервер заранее рискованно. Если выбранная модель не решит задачу или проект не получит достаточной нагрузки, оборудование окажется избыточным. Переход к локальному развёртыванию стоит планировать после того, как пилот подтвердит пользу системы и позволит оценить будущий TCO.

Локальная RAG-система и облачный RAG/API — сравнение

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

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

Технический стек локальной RAG-системы

В архитектуре Retrieval-Augmented Generation качество ответа зависит не только от языковой модели: ошибка при извлечении текста, чанкинге или поиске передаст LLM нерелевантный контекст.

Типовой конвейер RAG работает так:

1. Документы загружаются из файлового хранилища, корпоративного портала или другой системы;
2. Текст извлекается, очищается и делится на фрагменты — чанки;
3. Модель эмбеддингов преобразует каждый фрагмент в числовой вектор;
4. Векторное хранилище сохраняет векторы и связанные с ними метаданные. Текст чанков можно хранить вместе с ними либо получать по идентификатору из отдельного хранилища.
5. Запрос пользователя также преобразуется в вектор;
6. Модуль поиска находит наиболее близкие фрагменты;
7. Модуль повторного ранжирования при необходимости уточняет порядок результатов;
8. LLM получает вопрос и выбранный контекст, после чего формирует ответ.

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

Чанкинг и подготовка документов

Чанкинг определяет, какие части документа будут доступны семантическому поиску. Слишком крупные фрагменты содержат много лишнего текста, а слишком мелкие могут потерять смысл и связь с соседними абзацами.

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

Вместе с текстом следует сохранять метаданные:

• название и тип документа;
• раздел и номер страницы;
• дату и версию;
• подразделение или владельца;
• уровень доступа;
• ссылку на оригинал.

Метаданные позволяют отфильтровать устаревшие версии и ограничить поиск документами, доступными конкретному пользователю.

Embedding-модели: BGE-M3, E5 и Qwen3-Embedding

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

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

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

Векторные базы данных: Qdrant, Milvus, Weaviate и pgvector

Векторная база данных хранит эмбеддинги и ищет ближайшие элементы. Для корпоративной RAG важен не только поиск по сходству, но и фильтрация по метаданным. Например, система сначала ограничивает выборку подразделением и уровнем доступа, а затем ищет релевантные документы.

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

Ретривер и реранкинг

Ретривер (модуль поиска) быстро отбирает кандидатов по векторному, лексическому или гибридному поиску. Затем реранкер (модуль повторного ранжирования) повторно оценивает небольшое число найденных фрагментов с учётом запроса и меняет их порядок.

Реранкинг увеличивает вычислительную нагрузку и задержку, поэтому нужен не каждой системе. Его целесообразность проверяют на тестовом наборе вопросов. Если правильный фрагмент уже стабильно находится первым, дополнительный этап может не дать заметной пользы. Если нужный документ попадает в общую выборку, но уступает похожим результатам, модуль повторного ранжирования способен улучшить итоговый порядок.

LLM для локального инференса

Языковая модель получает вопрос и фрагменты, найденные модулем поиска. Для корпоративного ассистента важны не только общие возможности LLM, но и качество русского языка, поддерживаемый контекст, точность следования инструкциям и совместимость с выбранным сервером инференса.

Для пилота можно рассматривать несколько семейств:

• Qwen3 — плотные и MoE-модели разных размеров с поддержкой более 100 языков. Например, Qwen3-8B содержит 8,2 млрд параметров и поддерживает 32 768 токенов без расширения контекста.
• Llama 3.1 — семейство Meta с моделями на 8, 70 и 405 млрд параметров и контекстом до 128 000 токенов. Русский язык не входит в заявленный разработчиком список поддерживаемых языков, поэтому качество нужно отдельно проверять на материалах организации.
• DeepSeek-R1-Distill-Qwen — модели на 14 и 32 млрд параметров, полученные дистилляцией DeepSeek-R1 на основе Qwen2.5. Они ориентированы на задачи с рассуждением, но для простых ответов по найденному документу такая сложность может быть избыточна.

Название семейства не определяет качество RAG. Сравнивайте LLM на одном наборе вопросов и одинаковом найденном контексте. В тест обязательно включите вопросы без ответа в базе: модель должна сообщать о нехватке данных, а не дополнять контекст неподтверждёнными сведениями.

Квантование модели

В исходном виде веса локальной LLM обычно хранятся с точностью BF16 или FP16 — по 16 бит на параметр. Квантование модели сокращает разрядность весов, например до 8 или 4 бит. Это уменьшает объём памяти и позволяет запускать более крупные модели на том же оборудовании.

Обозначение Q4 указывает на четырёхбитное представление весов, но не описывает формат полностью. GGUF Q4_K_M, AWQ и GPTQ используют разные методы квантования и поддерживаются разными движками. Поэтому перед загрузкой нужно проверить совместимость файла с llama.cpp, vLLM, Ollama или другой выбранной средой.

Квантование снижает требования к памяти, но может повлиять на качество ответов. Степень изменения зависит от модели, формата и задачи, поэтому Q4-версию необходимо тестировать отдельно. Особенно важны числа, таблицы, точные цитаты и ответы на русском языке.

Требования к VRAM для разных размеров моделей

Теоретический объём четырёхбитных весов рассчитывается так:

Число параметров × 4 бита ÷ 8 = объём весов в байтах.

Например, для условной модели на 8 млрд параметров:

8 млрд × 4 ÷ 8 = 4 млрд байт, то есть 4,0 ГБ или примерно 3,73 ГиБ.

Перевод в гибибайты:

4 000 000 000 ÷ 1 073 741 824 ≈ 3,73 ГиБ.

Это нижняя теоретическая граница. Реальный файл Q4 содержит служебные данные и коэффициенты квантования, а во время работы память также занимают KV-кэш, контекст, промежуточные буферы и сам движок инференса.

Значения в третьем столбце — ориентиры, а не гарантированные требования. Точное потребление зависит от архитектуры модели, формата квантования, длины контекста, размера пакета и программного обеспечения.

Большое контекстное окно увеличивает KV-кэш. Если одновременно обслуживаются несколько пользователей, сервер хранит состояние нескольких последовательностей, поэтому потребление VRAM растёт. Модель, которая запускается на видеокарте в одиночном тесте, может не выдержать нужную параллельную нагрузку.

Часть слоёв можно перенести в оперативную память, если движок поддерживает совместную работу CPU и GPU. Это позволяет запустить модель при нехватке VRAM, но обычно снижает скорость генерации. Для рабочей системы лучше подбирать оборудование по результатам нагрузочного теста, оставляя запас памяти под контекст и одновременные запросы.

Что тестировать перед выбором модели

Проверка должна отвечать на практические вопросы:

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

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

Какое оборудование закрывает какой сценарий

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

Пилот или ассистент для одного специалиста

Для проверки гипотезы обычно достаточно одной рабочей станции. На ней можно разместить модель класса 7–14B в Q4, модель эмбеддингов и векторную базу данных.

Базовые ориентиры:

• одна видеокарта с 12–24 ГБ VRAM;
• от 64 ГБ оперативной памяти;
• NVMe-накопитель для моделей, документов и индекса;
• отдельный резервный носитель или сетевое хранилище для исходных данных.

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

Подобрать систему для пилотного или персонального сценария можно в разделе рабочих станций для локальных LLM. Конкретную видеокарту следует выбирать после проверки модели и требуемого контекста.

[ PERFORMANCE PRO TOWER ]

350D Tower

i9-14900K · RTX 5090 32ГБ · 64GB DDR5 RGB · 1 ТБ

998 000 ₽

74 850 ₽ / мес Примерный ежемесячный платёж. Итоговая сумма рассчитывается индивидуально.

Подробнее

750D Tower

7965WX · RTX 5090 32ГБ · 256GB DDR5 ECC · 1 ТБ NVME 5.0

3 094 500 ₽

232 088 ₽ / мес Примерный ежемесячный платёж. Итоговая сумма рассчитывается индивидуально.

Подробнее

900D Tower

2 x EPYC 9534 · RTX PRO 5000 48GB · 512GB DDR5 ECC · 2 ТБ

6 758 500 ₽

506 888 ₽ / мес Примерный ежемесячный платёж. Итоговая сумма рассчитывается индивидуально.

Подробнее

Внутренний сервис для отдела или небольшой команды

Если ассистентом одновременно пользуются несколько сотрудников, требуется запас VRAM под параллельные последовательности и KV-кэш. Для моделей класса 30–32B в Q4 отправной точкой может стать видеокарта с 24 ГБ памяти, но доступный контекст и число одновременных запросов необходимо проверять экспериментально.

Для более крупной модели или высокой параллельности применяют несколько GPU либо профессиональные ускорители с увеличенным объёмом памяти. Простое сложение VRAM не создаёт единый пул автоматически: движок должен поддерживать распределение модели между устройствами.

Кроме видеокарт, важны:

• производительный процессор для подготовки запросов и фоновых задач;
• оперативная память с запасом под индекс и служебные процессы;
• быстрые NVMe-накопители;
• резервное копирование базы знаний;
• сетевой интерфейс, соответствующий числу пользователей.

Для ускорения развёртывания можно использовать DigitalRazor OneStack. Платформа объединяет драйверы, контейнеры, управление моделями, API и мониторинг. Она сокращает объём первоначальной настройки, но не отменяет тестирование конвейера RAG и настройку прав доступа.

Корпоративный RAG с постоянной нагрузкой

Централизованный сервис для нескольких подразделений требует серверной архитектуры. Здесь важны не только скорость модели и суммарная VRAM, но и отказоустойчивость, управление доступом, наблюдаемость и возможность обслуживать несколько компонентов одновременно.

На одном узле могут работать:

• одна или несколько языковых моделей;
• модель эмбеддингов;
• модуль повторного ранжирования;
• API приложения;
• сервис авторизации;
• инструменты мониторинга.

Размещать всё на одном GPU необязательно. Например, генерацию можно вынести на основные ускорители, а эмбеддинги и реранкинг — на отдельную видеокарту или узел. Такое разделение уменьшает конкуренцию компонентов за память и вычислительные ресурсы.

Для корпоративного инференса и параллельных запросов можно рассматривать GPU-серверы DevBox AI. Число ускорителей и объём памяти выбирают под целевую нагрузку.

Крупная база знаний и несколько ИИ-сервисов

Большая организация может одновременно запускать RAG, обработку документов, построение эмбеддингов и другие модели. В таком сценарии одного сервера может быть недостаточно, особенно если требуется резервирование или обслуживание нескольких подразделений.

Для такой нагрузки применяют GPU-серверы с несколькими ускорителями или кластер. При проектировании учитывают:

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

Для сценариев с несколькими GPU или кластерной архитектурой можно рассматривать HPC-серверы DigitalRazor. Масштабирование имеет смысл, когда его необходимость подтверждена измеренной нагрузкой.

Почему нельзя выбрать сервер только по размеру модели

Две системы с одинаковым объёмом VRAM могут показывать разную скорость из-за архитектуры GPU, пропускной способности памяти и способа распределения вычислений. На результат также влияют движок инференса и параметры обслуживания запросов.

Перед закупкой нужно запустить целевую конфигурацию и измерить:

• время до появления первого токена;
• скорость генерации;
• число одновременных запросов;
• максимальный рабочий контекст;
• использование VRAM и оперативной памяти;
• время индексации новых документов;
• поведение системы при пиковой нагрузке.

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

Как понять, что локальная RAG-система оправдана именно вам

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

1. Ограничения на передачу данных

• 0 баллов — используются открытые данные или организация разрешает их обработку в выбранном облаке.
• 1 балл — документы внутренние, но облачную обработку можно согласовать при соблюдении условий безопасности.
• 2 балла — передача данных внешнему провайдеру запрещена или система должна работать в изолированном контуре.

2. Нагрузка и расходы на API

• 0 баллов — проводится пилот, запросы редкие, фактическая нагрузка неизвестна.
• 1 балл — сервис используется регулярно, но расходы и число пользователей пока нестабильны.
• 2 балла — нагрузка постоянна, а расчёт показал, что облачные токены формируют значительную часть TCO.

3. Требования к автономности и контролю

• 0 баллов — доступ к интернету стабилен, зависимость от внешнего API допустима.
• 1 балл — важны фиксированная версия модели и собственные правила обновления.
• 2 балла — обязательна автономная работа или внешние подключения запрещены.

4. Готовность команды

• 0 баллов — нет специалистов, ответственных за инфраструктуру, безопасность и качество RAG.
• 1 балл — сопровождение можно передать подрядчику или существующей ИТ-команде после обучения.
• 2 балла — определены владельцы системы, регламент обновлений и порядок устранения сбоев.

5. Бюджет и срок эксплуатации

• 0 баллов — CAPEX ограничен, а проект может завершиться после пилота.
• 1 балл — бюджет предусмотрен, но конфигурация ещё не подтверждена нагрузочным тестом.
• 2 балла — есть бюджет, срок эксплуатации и расчёт полной стоимости владения.

Как интерпретировать результат

Высокая сумма не означает, что сервер нужно закупать сразу. Она показывает, что локальный пилот заслуживает рассмотрения. Решение принимают после тестирования качества, производительности и стоимости.

Есть и два критических ограничения:

• если внешняя передача данных запрещена, облачный API нельзя выбирать только из-за низкой стоимости;
• если некому сопровождать систему, запускать промышленный локальный сервис рано независимо от итоговой суммы.

Какие данные собрать перед пилотом

Для расчёта понадобятся:

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

Пошаговая подготовка документов, настройка поиска и оценка качества разобраны отдельно в материале «Локальный RAG по внутренней документации: поиск-ассистент для команды». Здесь достаточно использовать результаты пилота для выбора между облачной, гибридной и локальной архитектурой.

Часто задаваемые вопросы

Короткий вывод

Локальный ИИ с RAG оправдан, если документы нельзя передавать внешнему провайдеру, требуется работа в изолированном контуре или постоянная нагрузка делает облачный API слишком дорогим. Для пилота и редких запросов облако обычно проще: оно позволяет проверить сценарий без крупных первоначальных затрат.

Начинать следует не с закупки максимального GPU-сервера, а с тестового набора документов и вопросов. Пилот покажет, какая модели эмбеддингов, векторная база данных, LLM и конфигурация оборудования обеспечивают нужное качество и время ответа. После этого можно рассчитать TCO и выбрать локальную, облачную или гибридную архитектуру.

Готовые конфигурации представлены в каталоге серверов и рабочих станций DigitalRazor для локальных LLM. Если нужно сопоставить размер модели, число пользователей и требования к инфраструктуре, обратитесь к специалистам DigitalRazor. Они помогут подобрать оборудование под подтверждённую нагрузку без неоправданного запаса.

Rackstation AI

Для каких задач Компактный GPU-сервер до 2 видеокарт для начальных задач в AI и графике. Оптимален для инференса, визуализации, VFX и рендеринга в студиях и лабораториях, где важна гибкость.

Подробнее

Видеокарты

RTX / RTX PRO / H200 NVL

Объем видеопамяти до 282 ГБ

Процессоры

Threadripper PRO

Количество ядер до 96

RAM до 1024 ГБ DDR5

Форм-фактор 4.5U

Devbox AI

Для каких задач Универсальная платформа на 4–6 GPU для локального обучения моделей и генеративных задач. Подходит для команд, которым важна надёжность сервера и свобода выбора графики — от RTX 5090 до PRO RTX 6000.

Подробнее

Видеокарты

RTX / RTX PRO / H200 NVL

Объем видеопамяти до 576 ГБ

Процессоры

Threadripper PRO

Количество ядер до 96

RAM до 1024 ГБ DDR5

Форм-фактор 6.5U

Scale

Для каких задач Сервер промышленного уровня на 8 GPU с кластерной архитектурой. Предназначен для дата-центров и AI-ферм, где требуется масштабируемость и полная загрузка ресурсов под обучение LLM и R&D.

Подробнее

Видеокарты

RTX PRO 6000 / RTX 5090

Объем видеопамяти до 768 ГБ

Процессоры

AMD Epyc, Intel Xeon

Количество ядер до 320

RAM до 3072 ГБ DDR5

Форм-фактор 6U

HPC 4000

Для каких задач Серия серверов для кластеризации на 4 GPU. Предназначены для дата-центров и AI-ферм, где требуется повышенная плотность для обучение LLM и R&D.

Подробнее

Видеокарты

L40s / RTX PRO / H200 NVL

Объем видеопамяти до 564 ГБ

Процессоры

AMD EPYC, Intel Xeon

Количество ядер до 128

RAM до 1536 ГБ DDR5

Форм-фактор 2U

HPC 8000

Для каких задач Серия серверов для кластеризации на 8 GPU. Предназначены для дата-центров и AI-ферм, где требуется повышенная плотность для обучение LLM и R&D.

Подробнее

Видеокарты

L40s / RTX PRO / H200 NVL

Объем видеопамяти до 1128 ГБ

Процессоры

AMD EPYC, Intel Xeon

Количество ядер до 256

RAM до 2048 ГБ DDR5

Форм-фактор 4U

HGX H200

Для каких задач HGX объединяет 8 видеокарт NVIDIA H200, достигая экстремальной плотности производительности. Благодаря внутренней связности NVSwitch мгновенно интегрируется в масштабные вычислительные кластеры.

Подробнее

Видеокарты

NVIDIA H200 SXM

Объем видеопамяти до 1128 ГБ

Процессоры

AMD EPYC, Intel Xeon

Количество ядер до 256

RAM до 2048 ГБ DDR5

Форм-фактор 5U