Офлайн-ИИ для платформ обмена сообщениями: зачем нужны локальные модели

Почти любая функция ИИ в современном ПО для обмена сообщениями работает на правах арендатора. Она выполняется на чужих серверах, тарифицируется по чужим ценам и работает лишь до тех пор, пока держится связь между вашим зданием и чужим. Для большинства покупателей это приемлемый компромисс. Но для банка, который держит платформу обмена сообщениями в DMZ, для государственного оператора в сети, изолированной от интернета (air-gap), или для реселлера на рынке, где курс валюты за этот год изменился на 30%, такой вариант исключён. Это руководство о том, что на самом деле происходит, если убрать облако: что локальная модель честно умеет, чего она не умеет, и какой архитектурный подход позволяет получить и то и другое, не ставя продукт в зависимость ни от одного из вариантов.

Почему облачный ИИ не подходит для DMZ и регулируемых сред

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

Сетевой барьер. Платформа обмена сообщениями, которая доставляет OTP для банка, не находится в открытом интернете. Она стоит в DMZ или ещё глубже, а политику межсетевого экрана пишет человек, чья работа состоит в том, чтобы отказывать. Исходящее HTTPS-соединение с поставщиком ИИ нельзя включить одной галочкой. Это заявка на изменение, проверка, запись в реестре рисков, а в изолированной сети это просто невозможно, потому что выхода из помещения наружу нет вообще. Любая функция, которой нужно связываться с внешним сервером, для такого заказчика не существует. Это не гипотетический и не редкий случай: именно так обычно устроены самые ценные клиенты в этой отрасли.

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

Коммерческий барьер. Цены на облачный ИИ определяет совет директоров другой компании. Тарифы меняются, бесплатные уровни закрываются, модели выводятся из эксплуатации по графику, который задаёте не вы, а ключ могут отозвать или ограничить в любой день без предупреждения. Если ключевая функция вашего продукта зависит от этого, вы построили бизнес на зависимости, которую не контролируете. Сильнее всего это ощущают операторы на развивающихся рынках, потому что цена в долларах США и выручка в местной валюте меняются несинхронно.

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

Что локальные модели действительно умеют, а чего не умеют

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

Что у них получается хорошо. Небольшая модель, дообученная на инструкциях (примерно от 3 до 8 миллиардов параметров), квантованная и запущенная локально через llama.cpp или Ollama на обычном CPU, действительно хорошо справляется с ограниченной текстовой работой. Переписать сообщение теплее, короче или официальнее. Исправить тон и грамматику. Подготовить черновик перевода, который утвердит человек. Ответить на вопрос поддержки по найденному документу. Определить намерение пользователя для чат-бота и выдать короткий ответ, похожий на заготовленный. Это именно те задачи, которые нужны платформе обмена сообщениями, и у них общий профиль: короткий вход, короткий выход, узкая задача и человек рядом.

Что у них получается плохо. Длинные многошаговые рассуждения. Удержание большого и запутанного контекста. Тонкие творческие тексты, которые должны получиться идеально с первого раза. Всё, где разница между хорошим и отличным ответом стоит реальных денег. Передовая облачная модель во всём этом заметно сильнее, и делать вид, что это не так, никому не поможет.

Ограничение, о котором забывают: скорость. Локальная модель на CPU выдаёт примерно от 10 до 25 токенов в секунду. Поэтому редактура на 200 токенов занимает примерно от 8 до 20 с. Для пользователя, который нажал «переписать» и ждёт, это приемлемо. Для чат-бота, который в реальном времени отвечает клиентам при большом объёме, это на пределе, и именно здесь вы либо добавляете недорогой GPU, либо делаете ответы короче, либо переводите эту одну функцию на облачный движок. Никакая хитрость не превратит CPU в дата-центр.

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

Схема выбора движка: нативный по умолчанию, ваш ключ по желанию

Ошибка в том, чтобы видеть здесь только два варианта. Локально или в облаке: выберите одно и живите с этим. Правильнее сделать движок настройкой, а интерфейс контрактом.

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

Три детали делают так, что это работает на практике, а не только на слайде.

Один формат по стандарту. Интерфейс построен по контракту chat-completions, совместимому с OpenAI, который охватывает и нативный сервер, и подавляющее большинство провайдеров одной веткой кода. Для Anthropic нужен один дополнительный адаптер. Это вся поверхность интеграции, поэтому добавить провайдера можно изменением настроек, а не отдельным проектом.

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

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

И одна граница, о которой стоит сказать прямо: ИИ здесь помогает, а не действует самостоятельно. Рассылки по-прежнему утверждает человек. В ответах RAG действует защитное правило «этого нет в документации», и система не выдумывает правдоподобный ответ. Офлайн-модель, которая уверенно сочиняет, хуже, чем полное отсутствие модели, и чем меньше модель, тем важнее это защитное правило.

Единственная задача, которая всегда нативная: спам

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

Проверка на спам выполняется на критическом пути обработки сообщений. Через неё проходит каждое сообщение, а значит, проверка должна почти ничего не стоить и никогда не ждать сетевого запроса. В Smppcube это fastText плюс правила, примерно за десятую долю миллисекунды, и никогда не LLM. При 3 000 000 сообщений в месяц облачный вызов длительностью 200 мс на каждое сообщение становится проблемой не денег, а физики: пропускная способность падает, а очередь копится из-за задержек стороннего сервиса.

Политика так же важна, как и механизм: помечать, а не блокировать. Фильтр помечает то, что похоже на спам, и оставляет решение об отправке за вами. Ложное срабатывание, которое незаметно обрывает OTP-трафик клиента, обходится гораздо дороже, чем помеченное сообщение, на которое человек бросит взгляд. Это общее правило для ИИ на критическом пути, и именно поэтому правильный инструмент здесь быстрый, простой офлайн-классификатор, а не самая впечатляющая модель.

Честный расчёт затрат

Оставьте в стороне общие слова о том, что «ИИ дорогой», и посчитайте, потому что при разных объёмах ответ действительно разный.

Лёгкое вспомогательное использование в облаке обходится дёшево. Пятьдесят пользователей ваших клиентов, каждый из которых делает сорок операций редактуры в день, дают около 60 000 вызовов в месяц. При примерно тысяче токенов на вызов это 60 миллионов токенов, что на модели среднего уровня составит примерно от 30 до 60 $ в месяц. Тот, кто утверждает, что при таком объёме один только счёт за токены оправдывает переход на нативный движок, что-то вам продаёт. В таком масштабе нативный движок выбирают ради DMZ и данных, а не ради счёта.

Чат-боты меняют картину. Теперь поставьте RAG-чат-бот на входящий трафик. Двадцать тысяч диалогов в месяц по шесть реплик дают 120 000 вызовов, и каждый несёт извлечённый контекст, скажем, 4 500 токенов на входе и выходе. Это около 540 миллионов токенов в месяц, примерно от 200 до 400 $ в зависимости от модели, или от 2 400 до 4 800 $ в год. Неприятнее всего направление движения: этот счёт растёт каждый раз, когда растёт бизнес, поэтому успех увеличивает ваши затраты именно в том квартале, когда вы рассчитывали на маржу.

У нативного движка нет счётчика. Нативный вызов стоит ноль. Платить приходится только за сервер: либо это существующий сервер с запасом мощности, либо дополнительные ресурсы примерно от 40 до 80 $ в месяц, и сумма фиксирована независимо от того, делаете вы тысячу вызовов или миллион. Вместе с лицензией на платформу за разовый платёж, которая уже работает на вашем собственном оборудовании, и по той же логике «аренда или владение», что и в руководстве по SMS-шлюзу на собственном сервере, статья расходов на ИИ перестаёт быть переменной и становится частью оборудования, которое вы уже купили.

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

Как выбрать честно

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

Делайте ставку прежде всего на нативный движок, если верно хотя бы одно из условий: ваша платформа работает в DMZ или в сети, изолированной от интернета; ваши заказчики спрашивают о субобработчиках раньше, чем о цене; ваша выручка в валюте, которая не следует за долларом США; или ваша нагрузка на ИИ похожа на нагрузку чат-бота и растёт. И в любом случае начинайте с нативного движка, если поставляете продукт клиентам, чьи среды вы не контролируете: функция, которой нужен выход в интернет, для части вашего рынка просто незаметно перестаёт существовать.

Проектировать стоит не под выбор «локально или облако». Важно, чтобы выбор принадлежал тому, кто владеет серверами, чтобы это была одна настройка, а не переделка системы, и чтобы нижняя планка под ним держала всегда. Отключите кабель, и ИИ продолжит работать. Всё остальное зависит от ваших предпочтений.