Локальные LLM для CRM

Когда нужен локальный AI

Скажу сразу: не всем нужен свой сервер с AI. Если у вас интернет-магазин с тысячей товаров и никто не требует хранить данные внутри — берите облако и не парьтесь. Проще, быстрее, на старте дешевле. Зачем городить инфраструктуру?

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

Требования регуляторов

Банки, страховые компании, медицина, госсектор — все эти отрасли работают с персональными данными и живут под пристальным вниманием регуляторов. 152-ФЗ о персональных данных, отраслевые стандарты, требования Центробанка, HIPAA для медицины — список ограничений длинный и постоянно растёт.

Что это означает на практике? Простой пример: ваш CRM-бот должен помочь клиенту с его кредитной заявкой. Для этого боту нужно знать имя клиента, номер телефона, сумму кредита, возможно — историю платежей. Отправить всё это в OpenAI API? Юридический отдел скажет «нет» быстрее, чем вы успеете договорить предложение. И они будут правы: в случае утечки отвечать будете вы, а не OpenAI.

Политика компании

Иногда регуляторы молчат, но служба безопасности громко возражает. И это тоже разумно. Утечка данных стоит денег — в среднем 2 225 ₸ млн по данным IBM за 2023 год, и эта цифра растёт каждый год. Репутационные потери посчитать сложнее, но они бывают ещё болезненнее.

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

Работа без интернета

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

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

Контроль над моделью

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

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

Обзор локальных LLM в 2025: кого выбрать

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

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

Llama 3.x от Meta — безусловный лидер

Когда говорят «открытая LLM», чаще всего имеют в виду именно Llama. И это справедливо: Meta вложила серьёзные ресурсы в разработку и сделала модели доступными для коммерческого использования практически без ограничений.

Llama 3.1 и 3.2 показывают качество, которое ещё пару лет назад казалось невозможным для открытых моделей. На многих задачах они не уступают GPT-3.5, а версия на 70B параметров приближается к GPT-4 — особенно если хорошо настроить промпт.

Модели доступны в нескольких размерах: 8B для скромного железа, 70B для серьёзных задач, и монструозная 405B для тех, у кого есть доступ к датацентру. Лицензия permissive — можно использовать коммерчески, адаптировать под свои нужды, дообучать. Единственное ограничение: если у вас больше 700 миллионов активных пользователей в месяц, нужна отдельная договорённость с Meta. Но, честно говоря, если у вас такая аудитория, вы, вероятно, уже не читаете статьи о выборе моделей.

Mistral — французская эффективность

Mistral AI — молодой французский стартап, который за короткое время стал серьёзным игроком на рынке. Их фокус — эффективность: максимум качества при минимуме параметров.

Mistral 7B удивляет тем, что модель такого размера вообще способна работать на приличном уровне. Она поместится на одну потребительскую видеокарту и будет генерировать разумные ответы — не гениальные, но вполне рабочие для многих сценариев.

Особого внимания заслуживает Mixtral 8x7B с архитектурой Mixture of Experts. Это, по сути, восемь специализированных моделей по 7B параметров, между которыми роутер распределяет запросы. Общий размер — 46B параметров, но на каждый запрос активируется только около 14B. В результате получается качество большой модели при вычислительных затратах маленькой. Красивое инженерное решение.

Qwen от Alibaba — недооценённый вариант

О Qwen говорят меньше, чем о Llama и Mistral, и это несправедливо. Alibaba создала отличную линейку моделей, особенно если вы работаете на мультиязычном рынке.

Qwen 2.5 доступен в широком диапазоне размеров — от крошечной 0.5B (поместится даже на телефон) до внушительной 72B. Но главное преимущество — поддержка языков. Русский, китайский, японский, корейский — модель обучалась на серьёзном мультиязычном корпусе и показывает достойные результаты там, где другие модели спотыкаются.

Если ваша CRM работает с клиентами на нескольких языках или вам важен именно русский — Qwen стоит протестировать обязательно.

Другие игроки на поле

Кроме «большой тройки» есть несколько интересных моделей для специфических сценариев:

• Gemma от Google: компактные модели на 2B и 7B параметров. Идеальны для edge-устройств — когда нужен AI прямо на устройстве пользователя, без обращения к серверу
• Phi от Microsoft: экспериментальные малые модели, которые умнее, чем можно ожидать от их размера. Phi-3 на 3B параметров иногда удивляет качеством рассуждений
• Command R от Cohere: специально оптимизирована для RAG (Retrieval-Augmented Generation) и enterprise-сценариев. Если вы строите систему вопросов-ответов по базе документов — стоит посмотреть

Сравнительная таблица: выбираем под свои ресурсы

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

Обратите внимание на колонку VRAM — это главный ограничитель. Модель должна поместиться в память видеокарты целиком (или почти целиком, если используете офлоад на CPU, но тогда скорость упадёт в разы). Планируйте железо с запасом: если модель занимает 16 GB, карта на 16 GB — это впритык, лучше брать 24 GB.

Требования к инфраструктуре: сколько всё это стоит

Теперь про слона в комнате — железо. Локальные модели прожорливы до неприличия. Если вы надеялись запустить что-то серьёзное на офисном компе — придётся расстроить.

Главный ограничитель — видеокарта, а точнее, её память (VRAM). Модель должна поместиться в неё, иначе либо всё будет очень медленно работать, либо не будет работать вообще. Процессор, оперативная память, диски — это тоже важно, но GPU решает.

GPU для разных бюджетов и амбиций

Давайте разберём варианты — от «попробовать за разумные деньги» до «нам нужен enterprise-уровень»:

RTX 4090 — это игровая карта, которая неожиданно хорошо подошла для AI-задач. Для пилотного проекта или небольшой команды — разумный выбор. Да, придётся ограничиться моделями поменьше, но 7B Mistral или 8B Llama на ней работают отлично.

A100 — рабочая лошадка датацентров. Если нужен Mixtral или модели в диапазоне 30-40B параметров — это ваш вариант. Версия на 80 GB позволяет запустить даже 70B модели, если использовать квантизацию.

H100 — текущий флагман NVIDIA для AI. Быстрее A100 примерно в 2-3 раза на типичных inference-задачах. Цена соответствующая. Имеет смысл для высоконагруженных production-систем, где скорость ответа критична.

Квантизация: магия, которая экономит деньги

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

Вот что происходит: обычно модели хранят веса в формате FP16 (16-битные числа с плавающей точкой). Квантизация конвертирует их в INT8 (8-битные целые) или даже INT4 (4-битные). Размер уменьшается в 2-4 раза, а качество... почти не страдает.

• FP16 (полная точность): максимальное качество, максимальный размер. Используйте, если важен каждый процент точности
• INT8 (8-битная): размер уменьшается вдвое, потеря качества около 1-2%. На большинстве задач разницу не заметите
• INT4 (4-битная): размер уменьшается в 4 раза, потеря качества 3-5%. Уже заметно на сложных задачах, но для простых сценариев — всё ещё отлично
• GPTQ и AWQ: продвинутые методы квантизации, которые умнее распределяют точность между слоями модели. Минимальные потери при максимальном сжатии

Мой совет: начните с INT8. Это оптимальный баланс — модель работает быстрее (меньше данных перемещать), занимает меньше памяти, а качество практически идентично оригиналу. INT4 пробуйте, если INT8 не помещается в вашу карту или если скорость критична и готовы немного пожертвовать качеством.

Покупать или арендовать: экономика GPU

Хорошая новость: необязательно сразу покупать серверы за миллионы. Российские облачные провайдеры — Yandex Cloud, VK Cloud, Selectel — предлагают GPU-инстансы в аренду. Можно начать с арендованного сервера, протестировать гипотезу, и только потом думать о покупке.

Грубая математика: аренда A100 стоит около 100-825 000 ₸ в месяц. Покупка сервера с A100 — 3-4 миллиона. Если планируете использовать его 24/7 больше двух лет — покупка выгоднее. Для пилота или сезонной нагрузки — однозначно аренда.

Есть ещё один вариант: использовать несколько RTX 4090 вместо одной A100. По чистой вычислительной мощности они сравнимы, а по цене — в разы дешевле. Правда, придётся повозиться с настройкой мультигпу и охлаждением (4090 — горячая карта), но для некоторых сценариев это разумный компромисс.

Развёртывание локальной LLM: от простого к сложному

Железо есть, модель выбрали — пора запускать. И вот тут приятный сюрприз: сообщество постаралось на славу. Даже без глубокого DevOps-бэкграунда можно поднять модель за день.

Расскажу про основные инструменты, от самого простого к production-ready.

Ollama — когда нужно быстро попробовать

Если вы хотите запустить локальную модель за пять минут — Ollama ваш друг. Устанавливается одной командой, модели скачиваются автоматически, API поднимается сразу. Буквально: установил, написал «ollama run llama2», и можно разговаривать с моделью.

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

vLLM — когда нужна скорость

vLLM — это проект от Berkeley, который стал де-факто стандартом для production-развёртывания LLM. Главная фишка — технология PagedAttention, которая оптимизирует использование памяти и позволяет обрабатывать запросы значительно быстрее.

Что умеет vLLM: continuous batching (объединение запросов для эффективного использования GPU), работа с несколькими видеокартами, поддержка всех популярных моделей, OpenAI-совместимый API. Если вы строите систему, которая будет обслуживать реальных пользователей — смотрите в сторону vLLM.

Text Generation Inference (TGI) от Hugging Face

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

Выбор между vLLM и TGI — часто вопрос личных предпочтений и специфики проекта. Обе системы зрелые и проверенные в production. Попробуйте обе и посмотрите, что лучше работает в вашем конкретном случае.

LocalAI — для тех, кто уже интегрирован с OpenAI

Особый случай: у вас уже есть работающая интеграция с OpenAI API, и вы хотите заменить его на локальную модель с минимальными изменениями кода. LocalAI создан именно для этого — он предоставляет API, полностью совместимый с OpenAI. Меняете URL эндпоинта — и всё работает.

По производительности LocalAI уступает vLLM и TGI, но для быстрой миграции — отличный вариант.

Kubernetes для серьёзных масштабов

Когда одного сервера становится мало — когда нужно несколько моделей, высокая доступность, автоматическое масштабирование под нагрузку — добро пожаловать в мир Kubernetes.

NVIDIA GPU Operator, KubeFlow, автоскейлеры — всё это позволяет построить полноценную ML-платформу внутри вашей инфраструктуры. Сложнее в настройке, требует DevOps-экспертизы, но для enterprise-уровня — правильный путь.

Интеграция с CRM: практические советы

Модель работает, API отвечает — теперь самое интересное: подключить это к вашей CRM-системе. И тут есть несколько подводных камней, о которых стоит знать заранее.

Замена endpoint — проще, чем кажется

Если ваша CRM уже умеет работать с OpenAI API (а многие современные системы умеют), миграция может быть удивительно простой. vLLM, TGI, LocalAI — все они предоставляют OpenAI-совместимый API. Буквально меняете URL с api.openai.com на адрес вашего сервера, и большинство запросов начинает работать.

Почему «большинство», а не «все»? Потому что некоторые продвинутые фичи OpenAI API (function calling, structured output) могут работать по-другому или не работать вовсе. Проверяйте на ваших конкретных сценариях.

Адаптация промптов — неизбежный этап

Вот что обычно не говорят в маркетинговых материалах: разные модели по-разному реагируют на одни и те же инструкции. Промпт, который отлично работал с GPT-4, может выдавать странные результаты на Llama 70B. И наоборот.

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

Гибридная архитектура: лучшее из двух миров

Не обязательно выбирать что-то одно. Разумная архитектура часто выглядит так: локальная модель обрабатывает запросы с чувствительными данными, а облачная (GPT-4 или Claude) подключается для сложных задач, где нужно максимальное качество.

Роутер между ними может работать по разным правилам: анализировать запрос на наличие персональных данных (PII), проверять тип задачи, учитывать текущую нагрузку на локальный сервер. Fallback на облако при перегрузке локальной модели — тоже разумный паттерн.

Такой подход даёт гибкость: приватность там, где она критична, и мощность облачных моделей там, где она нужна.

Производительность и оптимизация: честные цифры

«А оно не будет тормозить?» — второй вопрос после «сколько стоит». Давайте посмотрим на реальные цифры, без маркетинговой лапши.

Спойлер: да, локальные модели обычно работают медленнее облачных гигантов. У OpenAI и Anthropic огромные кластеры специализированного железа, оптимизированного под их модели. Конкурировать с этим сложно. Но «медленнее» не значит «неприемлемо медленно» — для большинства CRM-сценариев скорости хватает.

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

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

Вот реалистичные ориентиры:

• 7B модель на RTX 4090: около 50-100 токенов в секунду. Быстро. Ответ из 200 токенов — за 2-4 секунды
• 70B модель на A100: около 20-30 токенов в секунду. Помедленнее, но для большинства задач приемлемо. Тот же ответ на 200 токенов — 7-10 секунд
• Типичный ответ CRM-бота: обычно 100-300 токенов. Итого: от 2 до 15 секунд в зависимости от модели и железа

Для сравнения: GPT-4 через API обычно отвечает за 3-8 секунд. То есть разница не драматическая, если правильно подобрать модель под задачу.

Throughput: сколько пользователей потянет

Latency — это время ответа одному пользователю. Throughput — сколько пользователей система может обслуживать одновременно. И тут начинается интересное.

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

С continuous batching (который умеют vLLM и TGI) один сервер может обрабатывать 10-50 запросов параллельно. Latency для каждого немного вырастет, но общая пропускная способность — в разы выше. Для высокой нагрузки добавляйте серверы и балансировщик — горизонтальное масштабирование работает.

Техники оптимизации: что реально помогает

Если скорости не хватает, есть несколько проверенных способов её улучшить:

• Continuous batching: объединение нескольких запросов в один батч. GPU любит работать с большими объёмами данных. Включено по умолчанию в vLLM и TGI
• KV-cache: кэширование промежуточных вычислений внимания. Модель не пересчитывает одно и то же для каждого нового токена. Тоже обычно включено по умолчанию
• Speculative decoding: хитрый трюк: маленькая быстрая модель предсказывает несколько токенов вперёд, большая модель проверяет и корректирует. Ускорение до 2x на некоторых задачах
• Кэширование ответов: самая простая оптимизация. Если один и тот же вопрос задают часто (а в CRM это бывает) — не пересчитывать, а отдавать из кэша

Сравнение качества: локальные vs облачные модели

«Ок, это всё прекрасно, но насколько они хуже GPT-4?» — вопрос на миллион. Честный ответ: смотря для чего. Где-то разницы нет. Где-то она бросается в глаза.

Мы провели собственные тесты на типичных CRM-сценариях. Методология простая: 100 реальных запросов по каждой задаче, оценка качества ответов экспертами по шкале от 0 до 100. GPT-4 взяли как бейзлайн.

Результаты на реальных CRM-задачах

Что бросается в глаза? Llama 70B на большинстве задач показывает 85-90% качества GPT-4. Суммаризация — почти на уровне. Генерация email — небольшое отставание, но клиенты вряд ли заметят разницу. Классификация обращений — и вовсе 89% против 92%, в пределах погрешности.

Где GPT-4 заметно выигрывает? Следование сложным инструкциям. Когда промпт длинный, с кучей условий и исключений — GPT-4 справляется лучше. Локальные модели чаще «забывают» часть инструкций или интерпретируют их по-своему.

Mistral 7B — другая история. Это компромисс между скоростью и качеством. На простых задачах (классификация, короткие ответы) работает достойно. На сложных — заметно уступает. Используйте там, где нужна скорость и простота, а не максимальное качество.

Главный вывод: для типичных CRM-сценариев — генерация писем, ответы по базе знаний, суммаризация разговоров — Llama 70B вполне достаточно. Разница с GPT-4 есть, но она не критична для большинства бизнес-задач. А приватность данных — бесценна.

Экономика локального AI: считаем деньги

Рано или поздно финдиректор спросит: «И сколько это счастье стоит?» Давайте прикинем на пальцах.

Что стоит облачный API

Возьмём GPT-4 как ориентир. Текущие цены OpenAI: около 15 ₸ за 1000 токенов (усреднённо input и output). Один запрос к CRM-боту — это обычно 500-1000 токенов с учётом контекста и ответа.

Считаем: если у вас 100 000 запросов в месяц (не так много для активной CRM), получается примерно 750 000-1 500 000 ₸ в месяц. При курсе495 ₸ за доллар — 135-1 485 000 ₸ ежемесячно. И это только API, без учёта разработки и поддержки.

Claude от Anthropic — сопоставимые цены. Более дешёвые модели (GPT-3.5, Claude Instant) стоят в 10-20 раз меньше, но и качество соответствующее.

Что стоит локальное решение

Сервер с A100 80GB: около27 500 000 ₸ единоразово. Плюс ежемесячные расходы: электричество (эти карты потребляют 300-400 ватт каждая), охлаждение, обслуживание, место в дата-центре. Грубо — 50-100 тысяч в месяц на операционные расходы.

Альтернатива — аренда в российском облаке: 150-1 100 000 ₸ в месяц за аналогичную конфигурацию. Дороже на длинной дистанции, но без капитальных затрат и рисков устаревания железа.

Когда окупается своё железо

Простая математика: если вы тратите на облачный API больше 150-1 100 000 ₸ в месяц, локальное решение начинает иметь экономический смысл. При аренде GPU — сразу. При покупке железа — окупаемость 1-2 года, но потом вы работаете почти бесплатно (только операционные расходы).

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

Реальный кейс: как банк внедрил локальную LLM

Хватит теории — покажу на живом примере. Проект закончили в этом году, цифры свежие.

Практические советы: что мы поняли за десятки внедрений

За десятки проектов с локальными моделями мы натыкались на одни и те же грабли. Делюсь выводами — чтобы вы на них не наступали.

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

То, что спрашивают на каждой второй встрече. Если вашего вопроса нет — пишите, добавлю.

Заключение: пора действовать

Пару лет назад фраза «мы не можем отправлять данные наружу» означала приговор для AI-проекта. Локальные модели были либо беспомощными, либо стоили как крыло самолёта. Сейчас — совсем другая история.

Локальные LLM — это уже не компромисс ради приватности. Это полноценный инструмент, который решает реальные бизнес-задачи. Да, GPT-4 по-прежнему немного лучше на сложных задачах. Но для 80% CRM-сценариев — генерации писем, ответов клиентам, классификации обращений, суммаризации — Llama 70B или Qwen 72B справляются отлично.

Вот что стоит запомнить из этой статьи:

• Локальные LLM — это ответ на регуляторные ограничения. Если 152-ФЗ, политика безопасности или здравый смысл не позволяют отправлять данные наружу — теперь есть реальная альтернатива
• Llama 70B и Qwen 72B — рабочие лошадки для серьёзных задач. 85-90% качества GPT-4 при полном контроле над данными
• Mistral 7B — для быстрых простых задач. Когда нужна скорость и простота развёртывания, а не максимальное качество
• Квантизация — ваш друг. INT8 экономит половину памяти почти без потери качества. Не бойтесь использовать
• Гибридная архитектура часто оптимальна. Локальное для приватного, облачное для сложного — не нужно выбирать что-то одно

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