GPU-сервер для RAG и корпоративного чат-бота: что важно кроме видеокарты

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

GPU-сервер для RAG и корпоративного чат-бота нужно выбирать не только по видеокарте: важны объем видеопамяти, скорость работы модели, CPU, RAM, NVMe-диски, векторная база, способ хранения документов, сеть, права доступа, мониторинг и безопасность. Для пилота часто достаточно одной серверной GPU, быстрого NVMe и понятной схемы индексации документов. Для production-сценария, где чат-ботом пользуются отделы компании, база знаний часто обновляется, а данные нельзя отправлять во внешние сервисы, нужна уже полноценная архитектура с резервированием, логированием и планом масштабирования.

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

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

Что такое RAG в корпоративном чат-боте

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

Упрощенно процесс выглядит так:

1. Пользователь задает вопрос.
2. Система превращает вопрос в числовое представление для поиска.
3. Векторная база находит похожие фрагменты документов.
4. Дополнительный модуль может отсортировать найденные фрагменты по полезности.
5. Языковая модель получает вопрос и выбранные фрагменты.
6. Чат-бот формирует ответ.
7. Система сохраняет логи, метрики и, при необходимости, ссылки на источники.

В NVIDIA RAG Blueprint такая архитектура рассматривается как отдельный корпоративный конвейер: загрузка данных, извлечение информации, поиск, генерация ответа и контроль работы системы. Это важно, потому что RAG — не один компонент, а связка сервисов, где каждый влияет на скорость и качество ответа.

Обычно в корпоративной RAG-системе есть несколько частей:

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

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

Почему видеокарта не решает все

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

Чат-бот может работать медленно не из-за GPU, а из-за других узких мест:

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

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

Из чего состоит серверная архитектура для RAG

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

Генерация ответа

Языковая модель — самая заметная часть системы. Именно она формирует ответ для пользователя. Для нее важны:

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

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

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

Поиск по смыслу

Чтобы чат-бот нашел нужный документ, текст вопроса и текст документов переводятся в числовые представления. Это позволяет искать не только по точным словам, но и по смысловой близости.

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

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

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

Векторная база данных

Векторная база хранит фрагменты документов в виде, удобном для поиска по смыслу. Она отвечает за то, какие фрагменты попадут в контекст модели.

Для векторной базы важны:

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

В production нельзя относиться к векторной базе как к временной папке. Если индекс потеряется, устареет или будет собран без учета прав доступа, чат-бот начнет отвечать неправильно или использовать документы, которые не должен видеть конкретный пользователь.

Загрузка и обработка документов

Подготовка документов часто оказывается сложнее, чем кажется. Корпоративная база знаний редко состоит из аккуратно размеченных текстовых файлов. Обычно там есть PDF, сканы, DOCX, таблицы, презентации, HTML-страницы, архивы, старые версии инструкций и дубли.

На этапе загрузки нужно:

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

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

Хранение документов, индексов и логов

Для RAG нужны разные типы данных, и их лучше не смешивать в одну общую папку:

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

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

CPU и RAM

CPU нужен не “для галочки”. Он обслуживает API, обработку документов, извлечение текста, фильтрацию, очереди, фоновые задачи, мониторинг и часть логики поиска. Если на сервере слабый процессор, вся система может тормозить еще до того, как запрос попадет на GPU.

RAM нужна для:

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

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

Сеть

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

Для пилота часто достаточно 10G. Для production с большим объемом документов, отдельным хранилищем и несколькими узлами стоит заранее рассматривать 25G и выше. Для кластерной архитектуры и тяжелых AI-нагрузок сеть быстро становится таким же важным элементом, как GPU и диски.

Безопасность

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

Нужно заранее продумать:

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

OWASP в списке рисков для LLM-приложений отдельно выделяет prompt injection — ситуацию, когда вредоносная инструкция в запросе или документе пытается изменить поведение модели. Для RAG это особенно важно: опасная инструкция может попасть не только от пользователя, но и из документа, который был загружен в базу знаний.

Какие данные влияют на конфигурацию сервера

Перед выбором сервера нужно описать не только модель, но и саму задачу. Две компании могут запускать “корпоративный чат-бот”, но требования к железу будут разными.

Особенно важно оценить рост. Если сегодня база знаний занимает 100 ГБ, а через год будет 2 ТБ документов с ежедневным обновлением, сервер для пилота может быстро стать временным решением.

Требования для пилота, production и multi-user сценария

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

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

Как выбирать GPU для RAG и чат-бота

Выбор GPU начинается не с вопроса “какая видеокарта самая мощная”, а с того, какая модель будет запускаться, какой контекст ей нужен и сколько пользователей будет работать одновременно.

При выборе GPU важны:

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

Для небольших пилотов и корпоративных ассистентов с умеренной нагрузкой можно начинать с общей категории видеокарт NVIDIA для ИИ и нейросетей и выбирать карту под конкретную модель и объем VRAM. Например, для части задач может подойти NVIDIA L40S 48Gb или NVIDIA RTX PRO 6000 Blackwell Server Edition, если сервер совместим по питанию, охлаждению и размерам.

Для более тяжелых локальных моделей, длинного контекста и production-нагрузки стоит рассматривать решения с большим объемом видеопамяти: NVIDIA A100 80Gb, NVIDIA H100 80Gb или NVIDIA H200. Но даже такая GPU не будет хорошим выбором сама по себе, если сервер не выдерживает ее по питанию, охлаждению, слотам и общей архитектуре.

Для RAG часто важнее не пиковая производительность в идеальных условиях, а стабильная работа при реальных запросах. Пользователь не оценивает “теоретические токены в секунду”. Он видит, как быстро чат-бот начинает отвечать, насколько ответ точен и не ломается ли сервис в часы пик.

CPU, RAM и NVMe: где появляются неочевидные ограничения

В RAG-проекте CPU, RAM и диски могут быть такими же важными, как GPU.

CPU участвует в обработке документов, работе API, фильтрации результатов, подготовке запросов, фоновых задачах и мониторинге. Если документы постоянно обновляются, серверу придется регулярно извлекать текст, пересобирать фрагменты и обновлять индекс. Это не всегда GPU-нагрузка.

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

NVMe нужны для активных данных:

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

Если сэкономить на NVMe, GPU может простаивать. Деньги вложены в ускоритель, но данные поступают к модели слишком медленно.

Безопасность корпоративного RAG

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

Перед запуском нужно определить:

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

Если сотрудник не имеет доступа к документу в корпоративной системе, чат-бот не должен использовать этот документ при формировании ответа. Это правило нужно реализовать не на уровне “инструкции для модели”, а на уровне архитектуры: метаданные, фильтры, роли, проверка прав до передачи контекста в модель.

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

Как внедрять RAG и корпоративного чат-бота

Внедрение лучше начинать не с покупки сервера, а с подготовки данных и сценариев.

Собрать источники данных

Нужно определить, откуда чат-бот будет брать знания:

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

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

Подготовить документы

Документы нужно привести к виду, с которым может работать поисковая система:

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

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

Разбить документы на фрагменты

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

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

Построить индекс

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

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

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

Настроить поиск и сортировку

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

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

Настроить генерацию ответа

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

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

Запустить пилот и измерять качество

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

• простые вопросы;
• вопросы с неоднозначной формулировкой;
• вопросы по устаревшим документам;
• запросы с ограниченными правами;
• вопросы, где правильный ответ — “информации недостаточно”;
• попытки обойти ограничения.

После пилота станет понятно, что нужно усиливать: GPU, RAM, диски, поиск, права доступа, подготовку документов или качество промптов.

Какие метрики смотреть

Без мониторинга невозможно понять, справляется ли сервер. Команда может видеть, что “чат-бот тормозит”, но не знать, где именно проблема.

По инфраструктуре нужно смотреть:

• загрузку GPU;
• использование видеопамяти;
• температуру GPU;
• загрузку CPU;
• использование RAM;
• скорость дисков;
• задержки сети;
• свободное место;
• ошибки контейнеров и сервисов.

По RAG-пайплайну:

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

По качеству:

• точность ответа;
• наличие ссылок на документы;
• долю ответов “информации недостаточно”;
• пользовательские оценки;
• повторные вопросы;
• жалобы на устаревшие данные.

По безопасности:

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

Если эти метрики не собирать с самого начала, production-запуск превращается в догадки. Команда будет менять модель, GPU или базу данных, не понимая, где настоящее узкое место.

Один сервер или несколько узлов

Один сервер может быть хорошим решением для пилота или первого production-запуска. Это проще в закупке, обслуживании и отладке.

Один сервер подходит, если:

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

Несколько узлов нужны, когда система становится частью реального бизнес-процесса:

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

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

Главное — не строить кластер раньше времени, но и не покупать сервер без возможности роста.

Частые ошибки при выборе сервера для RAG

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

Часто компании:

1. Выбирают сервер только по GPU.
2. Не считают длину контекста.
3. Не учитывают одновременных пользователей.
4. Хранят документы, индексы и логи на одном диске.
5. Не закладывают RAM под векторную базу.
6. Не проверяют скорость переиндексации.
7. Не продумывают права доступа.
8. Не учитывают рост базы знаний.
9. Не измеряют качество поиска.
10. Тестируют только удобные демонстрационные вопросы.
11. Не планируют обновления моделей и драйверов.
12. Запускают production без резервного копирования.
13. Не проверяют питание, охлаждение и место в стойке.
14. Не собирают метрики с первого дня.

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

Что указать в ТЗ на GPU-сервер

Перед закупкой сервер лучше описывать от задачи, а не от списка комплектующих. В ТЗ стоит указать:

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

Пример формулировки:

Нужен сервер для корпоративного RAG-чат-бота по внутренним документам компании. На старте — до 50 пользователей, база знаний до 500 ГБ, обновление документов ежедневно, работа в закрытом контуре, хранение персональных и коммерческих данных, ожидаемое время ответа для большинства запросов — до 5–8 секунд, возможность расширения GPU, RAM и NVMe в течение 12 месяцев.

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

Частые вопросы

Нужна ли GPU для RAG?

Да, если языковая модель запускается локально и должна отвечать быстро. Но RAG-пайплайн нагружает не только GPU. Поиск, обработка документов, векторная база, фильтрация, API и мониторинг требуют CPU, RAM, быстрых дисков и стабильной сети.

Можно ли начать с одной GPU?

Можно, особенно если это пилот, небольшая база знаний и ограниченное число пользователей. Но лучше заранее проверить, можно ли добавить вторую GPU, увеличить RAM и поставить дополнительные NVMe-диски.

Что важнее: GPU или RAM?

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

Почему чат-бот медленно отвечает на мощной GPU?

Причина может быть в длинном контексте, медленной векторной базе, слабом CPU, нехватке RAM, медленном хранилище, очередях запросов или плохой настройке инференса.

Нужен ли отдельный сервер для векторной базы?

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

Что лучше: большая модель или хороший поиск?

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

Что обязательно проверить перед покупкой?

Нужно проверить объем видеопамяти, RAM, CPU, NVMe, сеть, питание, охлаждение, совместимость драйверов, возможность апгрейда, мониторинг, резервное копирование, права доступа и требования к хранению данных.

Итог

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

Хороший сервер под RAG — это сбалансированная система: GPU для генерации, CPU для обработки, RAM для индексов и кэшей, NVMe для быстрых данных, сеть для интеграций, мониторинг для контроля качества и безопасность для защиты корпоративной информации. Если эти части продуманы заранее, чат-бот проще запустить, масштабировать и поддерживать в production.