Сколько стоит держать локальную LLM для отдела из 20 человек

MAATRIX

Руководитель отдела из 20 человек, который решил поставить свою LLM вместо ChatGPT по подписке, обычно упирается в один и тот же вопрос: какое железо брать и сколько это будет стоить в месяц. Ответ «зависит» здесь не отговорка, а суть задачи — стоимость определяется не числом сотрудников, а пиковой одновременной нагрузкой и тем, какую модель эта нагрузка реально требует. Разберём методику расчёта по шагам: от оценки параллельности до готовой конфигурации сервера и сравнения с оплатой по токенам.

Сколько человек из 20 нажимают «отправить» одновременно

Первая и самая частая ошибка в расчёте — считать нагрузку по числу сотрудников, а не по числу одновременных запросов. У офисного отдела нагрузка не похожа на call-центр с непрерывным потоком: люди пишут в ассистента пачками — сформулировал вопрос, отправил, читает ответ, что-то делает параллельно, снова пишет. Одновременно активно ждут ответ модели далеко не все 20 человек сразу, даже в пиковый час.

Практическая методика оценки пиковой параллельности для офисного ассистента (не колл-центра и не публичного сервиса):

1. Возьмите долю сотрудников, которые вообще активно используют ассистента в рабочее время — для многих отделов это 60–80% состава, остальные обращаются к нему эпизодически.
2. Из активных пользователей оцените долю, которая одновременно ждёт ответ в конкретную минуту пика — для несинхронизированной офисной работы это обычно 10–20% от активной группы, потому что люди печатают, читают, отвлекаются на встречи не одновременно.
3. Заложите запас на кратковременный всплеск (все вернулись с обеда и разом написали) — на практике это ×1,5–2 к расчётной цифре.

Для отдела из 20 человек по этой логике пиковая параллельность обычно укладывается в диапазон 3–6 одновременных запросов, редко доходя до 8–10 даже во всплеск. Это ориентировочная оценка по общей логике использования чат-ассистентов в командах, а не измеренная цифра — у конкретного отдела с иным характером задач (например, если ассистент используется в конвейере обработки заявок, а не как помощник для отдельных людей) параллельность может быть выше, и тогда нужно считать по факту логов, а не по этой эвристике. Именно эта цифра пиковой параллельности, а не количество сотрудников в штатном расписании, определяет размер GPU дальше по тексту.

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

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

Когда несколько независимых запросов объединяются в один батч, движок инференса (vLLM, TGI и подобные) прогоняет их через ту же самую операцию умножения на веса за один проход — веса читаются из памяти один раз на весь батч, а не по разу на каждого пользователя. Отсюда и нелинейность: обслуживание пяти параллельных диалогов стоит по времени не в пять раз дороже одного, а заметно дешевле — до тех пор, пока в видеопамяти хватает места под KV-кэш (память под контекст каждого активного диалога) всех участников батча одновременно. Подробнее про саму механику батчинга и то, почему один пользователь оставляет GPU недогруженным, — в статье про батчинг запросов.

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

Как выбрать модель и конфигурацию под задачи офисного отдела

Для типичных офисных задач — черновики писем, суммаризация документов, ответы по внутренней базе знаний, помощь с формулировками, базовая аналитика текста — открытая модель классом 7–14B в квантовании Q4/Q5 обычно закрывает большинство сценариев. Для задач с более сложной логикой (разбор кода, многошаговые рассуждения над документами) может понадобиться модель крупнее, 32B и выше — но это отдельная проверка на реальных примерах отдела, а не решение по умолчанию.

Методика подбора конфигурации — три шага:

1. Зафиксируйте минимально достаточную модель. Не берите 70B «про запас», если задачи закрывает 8–14B — переплата за размер модели утяжеляет требования к VRAM сильнее, чем переплата за дополнительный параллелизм.
2. Оцените VRAM под веса. Для Q4-квантования это примерно вес модели в миллиардах параметров, умноженный на 0,5–0,6 ГБ (округлённо, конкретный множитель зависит от архитектуры и точности квантования — проверяйте по факту через nvidia-smi после загрузки, а не по одной формуле).
3. Добавьте VRAM под KV-кэш на пиковую параллельность. Каждый одновременный диалог с типичным контекстом в 2000–4000 токенов добавляет несколько сотен мегабайт-единицы гигабайт поверх весов — точная цифра зависит от модели и движка инференса, поэтому закладывайте запас, а не считаете впритык.

Ориентировочные конфигурации под отдел из 20 человек с пиковой параллельностью 3–6 запросов (диапазоны, не точные цифры — тестируйте на своих промптах):

Если после теста на реальных запросах отдела пиковая параллельность оказывается выше расчётной (например, всплеск до 10 одновременных диалогов), запас VRAM под KV-кэш — это то, что стоит увеличивать в первую очередь, до перехода на модель крупнее или на вторую карту. Подробный разбор конфигураций GPU под параллельную нагрузку нескольких пользователей — в статье про GPU-сервер под несколько пользователей, там же — про разделение карты между независимыми процессами, если у отдела кроме общего ассистента есть отдельные тяжёлые задачи.

Разовые затраты: сколько времени уходит на первоначальную настройку

Настройка сервера под отдел — не «поставить Ollama за пять минут», хотя базовый запуск действительно быстрый. Разовые трудозатраты складываются из нескольких этапов:

• Развёртывание движка инференса и загрузка модели — установка vLLM или аналога, настройка параметров батчинга (--max-num-seqs, --gpu-memory-utilization), загрузка и проверка выбранной модели.
• Настройка доступа для отдела — авторизация запросов (API-ключи или проксирование через внутренний шлюз), сетевые ограничения, чтобы сервис не торчал в открытый интернет без защиты.
• Интеграция с рабочими инструментами — если ассистент должен быть доступен из чата, внутреннего портала или как надстройка над документами, это отдельная работа поверх голого API инференса.
• Тестирование на реальных задачах отдела — прогон типичных запросов, проверка качества ответов, при необходимости — донастройка промптов или переход на другой квант/модель.
• Настройка мониторинга и базовых алертов — чтобы падение сервиса или исчерпание VRAM не обнаруживалось постфактум от жалоб сотрудников.

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

Ежемесячная поддержка: что реально требует времени постоянно

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

• Мониторинг утилизации и доступности. Нужно видеть, не упирается ли сервис в лимит одновременных запросов в часы пик и не деградирует ли скорость ответа. Как организовать наблюдение за нагрузкой локальной LLM — в статье про мониторинг нагрузки.
• Обновление модели. Открытые модели выходят новыми версиями регулярно, и часть из них ощутимо лучше предшественниц на тех же задачах. Обновление — это не просто скачать новый тег, а протестировать его на тех же промптах, что и текущую версию, прежде чем переключать отдел. Как обновлять модель без простоя для пользователей — в статье про обновление локальных моделей.
• Разбор жалоб и корректировка промптов. Отдел неизбежно найдёт формулировки, на которых модель отвечает плохо — это штатная работа по поддержке качества, а не авария.
• Патчи движка инференса и системы. Обновления vLLM/Ollama и ОС по соображениям безопасности и стабильности, обычно без даунтайма при аккуратном планировании.

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

Сравнение с оплатой по токенам через облачный API

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

Методика оценки объёма токенов отдела в месяц:

токены в месяц ≈ активные_пользователи × запросов_в_день × (токены_на_входе + токены_на_выходе) × рабочих_дней

Пример расчёта (иллюстративный, с округлёнными цифрами — подставьте свои): 16 активных пользователей из 20, по 15 запросов в день на человека, в среднем 600 токенов на входе и 400 на выходе на запрос, 21 рабочий день. Это 16 × 15 × 1000 × 21 ≈ 5 млн токенов в месяц — объём, который для многих офисных сценариев выглядит правдоподобно, но у конкретного отдела может отличаться в разы в любую сторону в зависимости от того, насколько объёмные документы отдел скармливает модели.

Соотнесите свою оценку объёма токенов с текущим прайсом облачного провайдера за миллион токенов (актуальные цены на момент чтения смотрите у провайдера — они меняются чаще, чем стоимость аренды сервера) и сравните итоговую сумму с фиксированной стоимостью выбранной конфигурации сервера. Общая закономерность, которая обычно подтверждается на практике: при относительно небольшом и нерегулярном объёме — как в примере выше — облачный API часто оказывается дешевле в моменте, потому что там нет платы за простой ночью и в выходные. Точка, где аренда сервера начинает выигрывать по деньгам, обычно требует объёма на порядок выше — либо очень активного использования всем отделом, либо дополнительных сценариев поверх чат-ассистента (пакетная обработка документов, RAG по большой базе, встроенный ИИ в внутренние сервисы), которые нагружают модель кроме прямых вопросов сотрудников.

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

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