Подключить языковую модель к собственным документам на своём сервере — задача на четыре недели и примерно 240 000 ₽ в первый месяц для архива в 12 000 документов. Технически это связка из трёх частей: среда запуска модели, векторное хранилище с нарезанными документами и тонкая прослойка, которая по вопросу пользователя достаёт нужные фрагменты и передаёт их модели вместе с инструкцией. Ни одна из частей не является сложной сама по себе; сложность живёт в документах.
Главный аргумент за локальный вариант — не деньги, а периметр. Модель на своём сервере в России означает отсутствие трансграничной передачи: запрос с фрагментами договора никуда не уходит, и вопрос о зарубежном провайдере просто не возникает. Что именно это меняет в документах по 152-ФЗ и во что обходится покупка железа, мы разбирали в материале про локальную модель под 152-ФЗ. Здесь — инструкция: что приготовить, что делать по шагам, что проверять и где вы застрянете.
И сразу честная рамка, чтобы не тратить ваше время зря. Локальная модель отвечает хуже облачной — заметно хуже на рассуждении и заметно ближе на поиске по документам. Если в ваших документах нет ни персональных данных, ни коммерческой тайны, читать дальше почти наверняка не стоит: российское облако закроет ту же задачу дешевле в десятки раз. Разбор четырёх способов связать модель с данными компании и порог перехода между ними — в отдельном материале про подключение модели к данным.
Что приготовить заранее
Всё, что не готово к началу работ, превращается в простой оплаченного сервера. Список короткий, но каждый пункт стоит закрыть до того, как арендован первый час.
- Ответственный со стороны компании. Один человек, который знает предметную область и может сказать, верен ответ или нет. Без него проект превращается в демонстрацию: модель что-то отвечает, а оценить это некому.
- Тридцать вопросов с эталонными ответами. Настоящие вопросы, которые сотрудники задают друг другу, с указанием документа и раздела, где лежит ответ. Это ваша приёмка, и собрать её надо до запуска, а не после — иначе оценка будет подгоняться под результат.
- Папка с документами и решение про сканы. Что войдёт в первую сборку: сколько файлов, каких форматов, сколько среди них отсканированных. Сканы — отдельная статья расходов, и решить, распознавать ли их, надо заранее.
- Ответ на вопрос о правах доступа. Все ли сотрудники могут видеть все документы. Если нет — это меняет архитектуру: разграничение нужно закладывать в индекс с самого начала, дописать его потом дороже, чем сделать сразу.
- Сервер и доступ к нему. Аренда у российского провайдера, оплаченная на месяц вперёд, и доступ по защищённому каналу. Разворачивать на рабочей машине сотрудника не стоит даже для пробы: вы получите результат, который нельзя воспроизвести.
- Решение о лицензии на веса модели. Лицензии открытых моделей разные и меняются между версиями: часть допускает коммерческое использование, часть ограничивает. Проверять надо лицензию конкретной версии весов, и это вопрос к юристу, а не к инженеру.
Железо: что арендовать и во что это обходится
Размер модели считается по простому правилу: в 4-битном квантовании веса занимают около 0,6 ГБ видеопамяти на миллиард параметров, плюс 15–30 % сверху на контекст и служебные буферы. Отсюда и требования к карте. Для поиска по документам с ответом со ссылкой на источник рабочий класс — 27–32 млрд параметров, то есть 32–48 ГБ видеопамяти.
| Конфигурация | Что тянет | Скорость ответа | Аренда в России, ₽/мес |
|---|---|---|---|
| Без видеокарты: 16 ядер, 64 ГБ оперативной памяти | Модель 7–8 млрд параметров, только для пробы концепции | 20–60 секунд на ответ, работать невозможно | 12 000–20 000 |
| Одна карта на 24 ГБ | Модели 8–14 млрд: классификация, извлечение полей, короткие ответы по регламентам | 2–5 секунд, 3–5 одновременных пользователей | 45 000–75 000 |
| Одна карта на 48 ГБ | Модели 27–32 млрд плюс отдельная модель эмбеддингов: ответы по базе знаний со ссылкой | 3–8 секунд, 8–12 одновременных пользователей | 90 000–140 000 |
| Две карты по 48 ГБ | Модели класса 70 млрд, длинный контекст: договоры и тендерная документация целиком | 10–25 секунд на длинный документ | от 220 000 |
Аренда в пересчёте на месяц дороже владения: покупка средней конфигурации стоит 1 100 000–1 600 000 ₽ и в полной стоимости владения даёт около 89 700 ₽ в месяц. Но на этапе проверки аренда почти всегда правильнее. Во-первых, вы не вкладываете полтора миллиона в гипотезу. Во-вторых, если после замера на тридцати вопросах решение отрицательное, сервер просто не продлевается — а купленная карта остаётся стоять. В-третьих, конфигурацию можно менять: начать с 24 ГБ, упереться в качество и перейти на 48 ГБ, не покупая обе.
Горизонтальная столбчатая диаграмма из четырёх строк. По оси X — видеопамять в гигабайтах от 0 до 96. Строки: «без карты — 0 ГБ, 12 000–20 000 ₽/мес», «одна карта 24 ГБ — 45 000–75 000 ₽/мес», «одна карта 48 ГБ — 90 000–140 000 ₽/мес», «две карты по 48 ГБ — от 220 000 ₽/мес». Каждый столбец разделён штриховкой на «веса модели» и «контекст, 15–30 %». Справа у каждой строки подпись скорости ответа: 20–60 с, 2–5 с, 3–8 с, 10–25 с. Отметка на строке 48 ГБ: «рабочий класс для поиска по документам». Чертёжный стиль, подписи по-русски.
Шесть шагов до первого ответа
Каждый шаг заканчивается проверяемым результатом. Если результата нет, переходить к следующему бессмысленно: ошибка всплывёт через два шага, и искать её придётся вслепую.
- 1Шаг 1. Поднять среду запуска моделей
Ставим Ollama — это самый короткий путь от голого сервера до работающего интерфейса; альтернативы существуют, но на старте они усложняют. Проверяемый результат: запрос к локальному адресу возвращает список установленных моделей, а не ошибку соединения. Отдельно закройте порт от внешнего мира: по умолчанию сервис слушает без пароля.
- 2Шаг 2. Скачать и запустить модель
Берём открытую модель в 4-битном квантовании: Qwen 3, Llama, DeepSeek или Mistral подходящего размера. Проверяемый результат: модель отвечает на вопрос «сколько будет двести плюс триста» за разумное время и не выгружается из памяти между запросами. Сразу зафиксируйте версию весов и сохраните файл у себя — на следующей неделе в реестре может лежать другая сборка под тем же именем.
- 3Шаг 3. Поднять векторное хранилище
PostgreSQL с расширением pgvector — обычно он у компании уже есть, и отдельную специализированную базу заводить не приходится. Проверяемый результат: расширение установлено, таблица с колонкой типа вектор создаётся без ошибки, тестовый поиск по трём вручную вставленным записям возвращает ожидаемый порядок.
- 4Шаг 4. Выбрать модель эмбеддингов и зафиксировать размерность
Отдельная небольшая модель, которая превращает текст в вектор. Проверяемый результат: размерность вектора записана в документации проекта и совпадает с размерностью колонки в базе. Это то место, где ломается больше всего сборок, и ломается молча.
- 5Шаг 5. Загрузить документы и построить индекс
Нарезка, извлечение текста, вычисление векторов, запись в базу. На 12 000 документов индексация занимает от одного до нескольких часов. Проверяемый результат: число записей в базе совпадает с ожидаемым числом фрагментов, а поиск по характерной фразе из середины произвольного документа находит именно этот документ.
- 6Шаг 6. Собрать прослойку вопрос-ответ
По вопросу достаём 4–6 наиболее близких фрагментов, передаём их модели вместе с инструкцией отвечать только по ним и обязательно возвращать ссылку на источник. Проверяемый результат: на пять контрольных вопросов приходят ответы с указанием документа, а на заведомо отсутствующую в базе тему — честное «в предоставленных документах ответа нет».
Схема внутри одной сплошной рамки, подписанной «наш сервер в России». Слева блок «Вопрос сотрудника» → «Модель эмбеддингов» → «pgvector: поиск 4–6 фрагментов» → «Языковая модель 27–32 млрд» → «Ответ со ссылкой на документ». Снизу отдельная ветка подготовки: «Документы» → «Распознавание сканов» → «Нарезка на фрагменты» → «Индексация» со стрелкой в pgvector. За пределами рамки нарисовано облако с перечёркнутой стрелкой и подписью «трансграничной передачи нет». На блоке эмбеддингов пометка «размерность фиксируется здесь». Чертёжный стиль, подписи по-русски.
Подготовка документов: где на самом деле работа
Модель отвечает ровно так, как нарезаны документы. Фрагмент в 300 символов не содержит контекста, фрагмент в 8 000 символов приносит модели вместе с ответом три посторонние темы. Ниже — порядок, который работает на типовом корпоративном архиве.
- 1Отсеять мусор до индексации. Черновики, дубли, версии одного документа за четыре года. Если в базу попадут три редакции одного регламента, модель будет уверенно отвечать по любой из них — и чаще всего по неправильной. Критерий пригодности документа мы разбирали в инструкции про сборку базы знаний.
- 2Нарезать по смыслу, а не по длине. Ориентир — 800–1 500 символов на фрагмент с перекрытием в 100–200 символов. Резать лучше по заголовкам и пунктам: раздел договора, шаг регламента, вопрос инструкции. Слепая нарезка по числу символов разрывает предложения и заметно ухудшает поиск.
- 3Добавить к каждому фрагменту заголовок документа. Фрагмент «срок составляет 14 календарных дней» без названия документа бесполезен. Заголовок и раздел дописываются в текст фрагмента перед вычислением вектора — это самая дешёвая правка с самым заметным эффектом.
- 4Распознать сканы. Изображение без текстового слоя в индекс не попадёт вовсе, и это молчаливая потеря: ошибки не будет, документа просто не станет. Российские инструменты распознавания есть — мы сравнивали Content AI и Smart Engines отдельно. На 900 страниц сканов закладывайте около 9 000 ₽.
- 5Разобраться с таблицами. Извлечённая как плоский текст таблица превращается в поток чисел без привязки к строкам, и модель начинает путать столбцы. Рабочие варианты: превратить таблицу в текстовые строки вида «показатель — значение» либо вынести её в отдельный источник и отвечать на такие вопросы запросом к базе, а не поиском по тексту.
- 6Проставить права доступа на уровне фрагмента. Если не все сотрудники должны видеть все документы, поле доступа кладётся рядом с вектором и используется как фильтр при поиске. Дописывать это после запуска дороже, чем заложить сразу.
Из этого следует главный практический вывод: качество ответа определяется качеством поиска, а не размером модели. Если на вопрос не нашлись правильные фрагменты, самая мощная модель уверенно ответит по тому, что ей дали, — и это будет выглядеть убедительно. Поэтому при разборе плохого ответа первым делом смотрят не на модель, а на то, какие пять фрагментов ей передали. Почему уверенное враньё выглядит правдоподобно, разобрано в материале про галлюцинации нейросети.
Проверка на тридцати вопросах
Замер — единственное, что отличает работающую сборку от впечатления. Он делается на тех самых тридцати вопросах, которые собраны до запуска, и занимает около двух часов вместе с разбором.
- 1Прогнать все тридцать вопросов подряд
Не выборочно и не по одному в течение недели. Проверяемый результат — таблица из тридцати строк: вопрос, ответ системы, ссылка на источник, отметка эксперта.
- 2Разметить ответы по четырём категориям
Верный со ссылкой; верный без ссылки; «не знаю»; неверный. Проверяемый результат — четыре числа в сумме дают тридцать. Категория «верный без ссылки» неслучайна: такой ответ невозможно проверить, и в эксплуатации он опаснее честного «не знаю».
- 3Отдельно проверить поведение на отсутствующих темах
Пять вопросов, ответа на которые в базе заведомо нет. Проверяемый результат — на всех пяти система отвечает «в предоставленных документах ответа нет», а не придумывает. Если хотя бы на одном придумала, правится инструкция, а не модель.
- 4Принять решение по порогу
Рабочий ориентир — не менее 24 верных ответов из 30 со ссылками при нулевом числе выдумок на отсутствующих темах. Проверяемый результат — решение записано: продолжаем, дорабатываем нарезку или останавливаемся.
| Результат первого прогона | Что это означает | Что чинить |
|---|---|---|
| Меньше 15 верных из 30 | Проблема в поиске, а не в модели | Нарезку и заголовки фрагментов; проверить, что сканы распознаны и попали в индекс |
| 15–23 верных | Типичный результат первого прогона | Разобрать неверные по одному: в половине случаев нужный фрагмент вообще не был найден |
| 24 и больше верных, но есть выдумки | Инструкция допускает ответ вне источников | Ужесточить инструкцию и добавить обязательную ссылку; выдумки должны уйти в ноль |
| 24 и больше, выдумок нет | Сборка пригодна к опытной эксплуатации | Открывать доступ ограниченной группе и продолжать замер на живых вопросах |
Две составные горизонтальные полосы по 30 единиц каждая. Верхняя «Первый прогон»: 18 «верный со ссылкой», 4 «верный без ссылки», 5 «не знаю», 3 «неверный». Нижняя «После правки нарезки и заголовков»: 26 «верный со ссылкой», 0 «верный без ссылки», 4 «не знаю», 0 «неверный». Вертикальная линия порога на отметке 24 с подписью «порог решения». Отдельная сноска: «пять вопросов на заведомо отсутствующие темы — выдумок должно быть ноль». Чертёжный стиль, подписи по-русски.
Что пойдёт не так: шесть сообщений об ошибке
Все шесть встречаются на первой сборке почти гарантированно. Ниже — как они выглядят и что означают на самом деле.
- CUDA out of memory. Tried to allocate … — модель вместе с контекстом не помещается в видеопамять. Лечится не докупкой памяти, а уменьшением: взять меньшую модель, более грубое квантование или укоротить контекст. Проверьте заодно, не осталась ли в памяти предыдущая модель — самая частая причина.
- model requires more system memory than is available — не хватает уже обычной оперативной памяти при загрузке весов. На конфигурации без видеокарты это нормальное поведение: 32 ГБ оперативной памяти для модели такого класса мало.
- ERROR: type «vector» does not exist — расширение pgvector не установлено в этой базе. Устанавливается оно в конкретную базу, а не в сервер целиком: типовая ошибка — поставили в одну, подключаетесь к другой.
- expected 1024 dimensions, not 768 — сменили модель эмбеддингов и не переиндексировали документы. Смешивать векторы разных моделей в одной таблице нельзя: индекс придётся пересобрать целиком.
- input length exceeds maximum context length — в модель уходит слишком много: либо фрагменты слишком крупные, либо их берут слишком много. Уменьшайте число фрагментов до четырёх-шести, а не увеличивайте контекст.
- 413 Request Entity Too Large — упирается не модель, а веб-сервер перед ней: ограничение на размер запроса. Возникает при загрузке крупных файлов через интерфейс и правится одной настройкой прокси.
Система отвечает «в предоставленных документах ответа нет», хотя документ в базе есть и вы держите его в руках. Ошибки в журнале нет, всё «работает». В девяти случаях из десяти это одно из трёх: скан не распознан и в индекс не попал, фрагмент нарезан так, что ответ разорван между двумя кусками, или в вопросе используется другая терминология, чем в документе. Проверяется поиском по характерной фразе из этого документа: если поиск его не находит, проблема в индексе, а не в модели.
Сколько это стоит: первый месяц и год
Модельная компания: 12 000 документов, из них 900 страниц сканов; 25 сотрудников с доступом; около 900 вопросов в месяц. Конфигурация — аренда сервера с картой на 48 ГБ. Ставки: инженер-подрядчик 3 000 ₽/час, руководитель направления со стороны заказчика 1 800 ₽/час.
Шесть часов руководителя направления в этой смете — не формальность и не «наши люди поучаствуют в свободное время». Это единственная строка, которую подрядчик не может закрыть за вас: собрать настоящие вопросы и оценить правильность ответов может только тот, кто знает предметную область. Проекты, где эту строку не заложили, обычно и застревают на приёмке.
Сравнивать надо именно эти две строки — «где считает модель», — потому что всё остальное одинаково. Порог, при котором свой контур перестаёт быть дороже, мы считали отдельно: около 86 000 обращений в месяц, то есть примерно 2 900 в день. Компания на 25 пользователей столько не задаёт даже теоретически. Отсюда вывод, который стоит проговорить до аренды сервера: локальную модель покупают под требование, а не ради экономии — специальные категории данных, условие заказчика, позиция службы безопасности, госконтракт. Если требования нет, честный ответ — российское облако.
Сравнение в две колонки на общей шкале рублей. Левая «Свой контур, год»: блок «аренда 1 260 000 ₽», блок «сопровождение 216 000 ₽», итог 1 476 000 ₽. Правая «Российское облако, год»: тонкая полоска «токены 11 232 ₽». Под обеими колонками одинаковый серый блок «сборка, нарезка, проверка — 133 800 ₽» с подписью «одинакова в обоих вариантах». Сбоку вертикальная отметка «порог равенства — около 86 000 обращений в месяц» с указателем, что модельная компания даёт 900. Чертёжный стиль, подписи по-русски.
Где локальная модель слабее облачной
Разница между локальной моделью на 32 млрд параметров и большой облачной есть, но она не равномерная: на одних задачах её почти не видно, на других она принципиальна. Ниже — честное распределение по состоянию на сентябрь 2026 года; из российских облачных вариантов имеет смысл смотреть GigaChat и YandexGPT, они закрывают периметр по 152-ФЗ без своего железа.
| Задача | Разница | Комментарий |
|---|---|---|
| Найти ответ в документах и процитировать | Почти нет | Качество определяется поиском и нарезкой, а не размером модели |
| Сформулировать ответ деловым языком | Небольшая | Локальная формулирует суше и однообразнее, но по сути так же |
| Сравнить два договора и найти расхождения | Заметная | Задача на рассуждение и длинный контекст — здесь облачная модель выигрывает ощутимо |
| Свести данные из десяти документов в связный вывод | Большая | Локальная теряет нить и подменяет источники; надёжнее разбить задачу на шаги |
| Работать со сложными таблицами | Большая | Обеим тяжело, локальной заметно тяжелее; таблицы лучше выносить в отдельный источник |
| Отвечать на редких языках и специальной терминологии | Зависит от модели | Проверяется только на ваших тридцати вопросах, общего ответа нет |
Когда локальная модель не нужна
Четыре ситуации, в которых свой контур — лишние деньги, и об этом стоит договориться до аренды сервера.
- В документах нет ни персональных данных, ни коммерческой тайны. Инструкции по оборудованию, публичные регламенты, обучающие материалы. Периметр защищать не от чего, а разница в стоимости — десятки раз.
- Меньше 3 000 обращений в месяц. Даже с запасом на рост порог равенства не достигается: свой контур стоит фиксированную сумму независимо от нагрузки, и при малом объёме каждое обращение получается неприлично дорогим.
- Некому обслуживать. Обновление моделей, переиндексация, разбор жалоб — это 6 часов в месяц постоянно, а не разовый запуск. Если в компании нет ни своего инженера, ни договора на сопровождение, через полгода вы получите сервер, который никто не трогает, и качество, которое медленно деградирует.
- Задача решается без модели вообще. Если сотрудники ищут в документах одно и то же и вопросов не больше двадцати, дешевле собрать нормальную базу знаний с обычным поиском по тексту. Модель добавляет ценность там, где вопросы формулируются по-разному, а ответ надо собрать из нескольких мест.
И последнее. Всё описанное — по состоянию на сентябрь 2026 года. Цены аренды, состав открытых моделей и условия лицензий на веса меняются быстрее, чем выходят статьи. Поэтому закладывайте в архитектуру одну вещь с самого начала: прослойка, которая обращается к модели, должна уметь переключаться между локальным сервером и российским облаком настройкой, а не переписыванием. Тогда решение «своё или облако» перестаёт быть необратимым, и его можно будет пересмотреть, когда изменятся цифры.
Локальная модель — это покупка периметра, а не экономия. Если требования к периметру нет, вы платите в сто раз больше за то же самое.
