Не начинайте с выбора модели
Спор «Qwen или Llama, vLLM или что-то ещё» интересен инженерам. Для предприятия первый вопрос другой: можно ли этим данным выходить наружу и на каком процессе ИИ вообще нужен.
Локальный ИИ — не религия. Это ответ на ограничения.
Когда локальный контур оправдан
- конструкторка, технология, ГОЗ, персональные и коммерческие тайны;
- политика ИБ: «в публичные API — нельзя»;
- нужна предсказуемая среда без «модель обновилась и поведение поплыло»;
- аудит: кто что видел, где крутился инференс.
Если документ нельзя отправить юристу на личную почту — его же нельзя бездумно отправить в чужой чат.
Когда облако или гибрид нормальны
- данные уже обезличены или публичны;
- политика прямо разрешает внешнего провайдера;
- нужен быстрый эксперимент на нечувствительном куске;
- локальный GPU-контур пока не окупается, а риск приемлем.
Гибрид часто честнее, чем «всё только air-gap» на словах и Excel в Telegram на деле.
Цена, о которой забывают
Локальный стек — это не только «поставить контейнер»:
- железо и электричество;
- обновления и мониторинг;
- кто чинит, когда в пятницу вечером «не отвечает»;
- оценка качества ответов, не разовая демка.
Поэтому пилот должен быть узким: один процесс, одна метрика, понятный хозяин.
Процесс важнее железа
Можно купить сервер и всё равно получить мусор: если as-is не собран, модель будет уверенно ошибаться внутри периметра. Безопасный бред — всё ещё бред.
Связка, которая работает:
- разобрать процесс;
- решить, какие данные входят в контур;
- выбрать архитектуру (локально / гибрид);
- пилот → метрика → решение.
См. также: почему ИИ на регламенте не взлетает, определение APRE.
Практичный вывод
Локальный ИИ нужен, когда риск утечки или потери контроля выше, чем экономия на чужом API.
Он не нужен как статусная галочка «у нас свой LLM», если процесс не разобран и эффекта не измерить.
Павел Наумов