Локальная нейросеть на своём сервере: когда она нужна бизнесу

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

На практике вопрос почти всегда задают в обратном порядке: сначала «давайте поставим свою нейросеть», потом «а что она будет делать». Это дорогая последовательность. Свой контур — это не разовая покупка, а постоянная эксплуатация: железо, обновления, мониторинг, человек, который поднимет сервис в субботу. Пока не описан конкретный сценарий с конкретными данными, посчитать эту эксплуатацию невозможно, а значит невозможно и сравнить её с альтернативой.

Полезно разделять два разных страха, которые обычно смешивают. Первый — «данные утекут к разработчику модели и обучат её на нашей переписке». Второй — «мы нарушим 152-ФЗ». Первый закрывается выбором поставщика и условиями договора. Второй — местом хранения данных и оформленным порядком обработки. Свой сервер закрывает оба сразу, но это самый дорогой из доступных способов, и берут его тогда, когда более дешёвые не подходят по существу, а не по ощущениям.

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

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

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

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

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

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

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

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

Медицина — самый чистый пример. Сведения о здоровье относятся к специальным категориям персональных данных, требования к ним строже обычных, и отправлять содержимое медкарты во внешний сервис — плохая идея независимо от того, чей это сервис. Здесь локальная модель перестаёт быть вопросом предпочтений: контур проектируется закрытым с самого начала, а не закрывается потом.

Как выглядит такой контур на практике, видно по нашему кейсу МИС — медицинской системы, которую мы делаем с нуля. Перед проектированием мы разобрали существующий аналог: 1613 таблиц базы данных и 1029 роботов, а собственное техническое задание собрано на 1619 требований. Изоляция данных между клиниками сделана не проверкой в коде, а механизмом самой базы — построчной защитой доступа (PostgreSQL RLS): запрос физически не может вернуть чужие строки. Отдельно заложен контур 152-ФЗ: согласия, аудит доступа, сроки хранения. Честно про статус — это MVP собственного продукта, он развивается, а не сдан и забыт.

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

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

Технически это выглядит как слой маршрутизации перед моделями. Запрос сначала проходит проверку: если в нём есть данные закрытого класса, он идёт на локальную модель и остаётся внутри периметра. Если данных нет или они обезличены — уходит в облако, где модель сильнее. Правило принимается один раз и исполняется системой, а не памятью сотрудника: именно в этом месте разваливаются схемы, построенные на инструкции «не вставляйте в чат персональные данные».

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

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

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

Что смотреть дальше на сайте. Услуга AI-стратегии и обучения — про сам разбор: где AI окупится, а где нет, и какая дорожная карта из этого следует. Услуга отраслевых систем — про случаи, когда коробочных решений не хватает и контур с данными в РФ проектируется под отрасль. Выделенный AI-инженер — формат, когда инженер работает внутри вашей команды и доводит контур на месте. Кейс МИС показывает, как закрытый контур с изоляцией данных выглядит в реальном продукте. В журнале тему продолжают статьи «Можно ли использовать ChatGPT в компании: 152-ФЗ» и «Внедрение ИИ и 152-ФЗ: безопасно ли для персональных данных». Начать разумнее всего с бесплатного экспресс-аудита на 30 минут: его задача — понять, нужен ли вам свой сервер вообще, а не продать самый большой проект. Стоимость работ называем после него, когда понятен сценарий и объём данных.