Локальные LLM против OpenAI. Как финтеху внедрять ИИ без нарушения NDA.

Локальные модели против OpenAI API: сравнение в цифрах

Разберём оба пути по критериям, которые реально влияют на решение совета директоров.

• Приватность. On-Premise: данные физически не покидают контур — 0% риска нарушения NDA и банковской тайны. Публичный API: каждый запрос — передача клиентских данных третьей стороне, требующая юридического анализа каждого сценария.
• Стоимость на горизонте 3 лет. API дешевле на старте (0 рублей железа), но платежи за токены растут линейно с нагрузкой. Локальная модель требует CAPEX на серверы (1–2 узла с GPU), после чего маржинальная стоимость запроса стремится к нулю. При стабильной нагрузке от нескольких тысяч запросов в день локальный контур выходит дешевле.
• Качество ответов. На типовых задачах поддержки и работы с документами современные open-source модели (Llama 3, Qwen, Mistral) после fine-tuning на ваших регламентах закрывают 80%+ сценариев сопоставимо с флагманскими API. Там, где нужен максимум качества на сложной логике, гибрид допустим: локальная модель отвечает первой, эскалация — по правилам, а не по умолчанию.
• Зависимость. Локальный контур не блокируется, не меняет цены задним числом и не прекращает поддержку версии, на которой работает ваш прод. Это аргумент уровня risk committee, а не IT-отдела.

Типичные ошибки при внедрении локальных LLM

Ошибка 1. Покупка железа до определения нагрузки. Мы видели проекты, где закупили 8 GPU-серверов «с запасом» при реальной потребности в одном. Hardware sizing делается по пиковой нагрузке (RPS × средняя длина ответа), а не по амбициям презентации.

Ошибка 2. Fine-tuning там, где хватит RAG. Дообучение модели на документах, которые меняются каждый квартал, — это конвейер переобучения и рассинхронизации. Знания, которые обновляются, живут в RAG-базе; fine-tune нужен для стиля, формата и доменной логики.

Ошибка 3. Экономия на оценке качества. Локальную модель без eval-контура нельзя выпускать к клиентам: качество open-source весов сильно зависит от квантизации и промптинга. Замер точности на реальных кейсах обязателен до боевой эксплуатации.

Ошибка 4. Игнорирование инфраструктуры инференса. Разница между «модель запустилась» и «модель держит продовую нагрузку» — это vLLM, батчинг запросов и мониторинг латентности. Голый запуск в ноутбуке Jupyter не считается внедрением.

Сколько стоит развернуть локальную LLM?

Ориентир для задачи уровня поддержки или анализа документов: пилот на ваших данных занимает 4–6 недель, полный цикл внедрения — 2–4 месяца. Железо — от одного GPU-сервера класса A100/H100; точная конфигурация определяется после замера пиковой нагрузки. Окупаемость типичного проекта — около 6–8 месяцев за счёт исключения платежей за API-токены и сокращения ручного труда: алгоритм берёт на себя до 70% рутинных операций.

Как быстро модель начнёт отвечать по вашим регламентам?

Первый рабочий прототип на вашей документации мы показываем в течение первой недели: подключаем базу знаний через RAG, и модель отвечает со ссылками на ваши документы уже на пилоте. Выход на целевую точность (для задач поддержки мы доводим ответы до 99.9% подтверждённых ответов) занимает ещё несколько недель калибровки на реальных обращениях.

Что если у нас смешанная нагрузка?

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

Чеклист готовности компании к On-Premise LLM

Прежде чем считать бюджет, ответьте на пять вопросов — их мы задаем на первом звонке.

1. Есть ли у вас документы, на которых модель должна отвечать? Регламенты, договоры, база знаний в любом формате. Если всё существует только в головах сотрудников — первый этап это Data Pipeline: сбор и очистка знаний.
2. Каков объем и характер обращений? Нужна статистика: сколько запросов в день, средняя длина диалога, пиковые часы. От этого зависит конфигурация железа и экономика проекта.
3. Какие данные категорически нельзя выпускать наружу? Список чувствительных категорий определяет архитектуру маршрутизации между локальным контуром и (при допустимости) внешними API.
4. Кто отвечает за качество со стороны бизнеса? Модель калибруется на реальных кейсах — нужен владелец процесса, который подтверждает эталонные ответы и принимает результат.
5. Где модель будет жить физически? Ваш серверная, дата-центр или выделенное облако с физической изоляцией — все три варианта рабочие, но требования к безопасности различаются.

Если на четыре вопроса из пяти есть ответ — вы готовы к пилоту. Если меньше — начните с аудита данных: это дешевле, чем закупка железа вслепую.

Что происходит с командой после внедрения?

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

Как проходит пилот: первые 30 дней

Неделя 1 — аудит: собираем документы, замеряем нагрузку, фиксируем эталонные вопросы и ответы. Недели 2–3 — развертывание: модель поднимается в вашем контуре, подключается база знаний, настраивается маршрутизация запросов. Неделя 4 — калибровка на живых обращениях: команда DS разбирает ошибки, пополняет базу знаний, замеряет точность. На выходе вы получаете прототип, отвечающий по вашим регламентам, и математическую модель ROI для решения о масштабировании — без слепых инвестиций в железо до подтверждения качества.