Локальная LLM или облако: как принять решение, если у вас чувствительные данные

На прошлой неделе ко мне пришёл директор медицинского центра. Они хотели запустить AI-бота для консультаций по записи и подготовке к процедурам. Идея отличная — разгрузить регистратуру, сократить время ожидания. Но первый же вопрос безопасника поставил проект на паузу: «А данные пациентов будут уходить в ChatGPT?»

Другой случай — финтех-компания, которая хотела сделать AI-ассистента для внутренней аналитики. Модель должна была работать с отчётами о транзакциях, остатках на счетах, подозрительных операциях. Когда я упомянул, что можно использовать GPT-4 через API, мне показали регуляторные требования — данные не должны покидать контур компании. Точка.

Оба кейса подтолкнули к одному вопросу: когда действительно нужна локальная LLM, а когда облако — вполне рабочий вариант? Эта статья — попытка дать структурированный ответ. Без фанатизма в сторону «всё на своих серверах» или «облако решит все проблемы».

Коротко для занятых

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

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

Второй — что говорит регулятор? Если есть требования хранить данные в пределах Казахстана или запрет на передачу третьим лицам — тут без вариантов. Либо локально, либо ЦОД в РК.

Третий — сколько готовы вложить? Своё железо — это капитальные затраты плюс зарплата тех, кто будет это поддерживать. Облако — это операционные расходы, но зато предсказуемые и без головной боли.

Четвёртый — нужна ли мгновенная реакция? Для голосовых ботов и real-time систем каждая миллисекунда на счету. Локальная модель в том же дата-центре выигрывает просто за счёт физики.

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

Когда облако — правильный выбор

Давайте сначала разберёмся с мифами. Я часто слышу: «Облако — это ненадёжно, данные утекут». Но OpenAI, Anthropic, Google — это не студенческие стартапы в гараже. У них сертификации, которые многие банки не прошли бы: SOC 2, ISO 27001, контракты для медицины (HIPAA), соглашения по GDPR.

Вот реальная история. Ко мне приходит владелец сети кофеен — хочет бота для бронирования и ответов на вопросы. Безопасник в компании начинает требовать локальную инфраструктуру. Я спрашиваю: «Какие у вас чувствительные данные?» Оказывается — имя клиента и предпочитаемый напиток. Это не персональные данные в юридическом смысле. Это предпочтения. Потратили бы $30k на серверы ради защиты информации о том, что Марат любит раф с лавандой.

Облако отлично работает, когда вы отвечаете на общие вопросы о продуктах, генерируете маркетинговые тексты, помогаете клиентам найти нужную услугу. Даже если в разговоре мелькают имена — можно их маскировать перед отправкой. Вместо «Иванов Пётр, ИИН 850101» отправляем «Клиент #7842». Модель отвечает, мы подставляем реальные данные обратно. Просто? Да. Работает? Отлично.

А ещё облако — это скорость. API OpenAI можно интегрировать за день. Буквально: утром начали, к вечеру бот работает. Локальную инфраструктуру будете разворачивать месяц, а потом ещё месяц дебажить.

Кстати, если ваш безопасник до сих пор пересылает страшилки про «данные утекают в ChatGPT» — покажите ему материал про DLP для AI и официальные Data Processing Agreements. У Enterprise-тарифов данные вообще не используются для обучения моделей — это в контракте чёрным по белому.

Когда нужна локальная LLM

А теперь про случаи, когда облако действительно не вариант. И дело тут не в паранойе, а в объективной реальности.

Помните финтех-компанию из начала? Там всё просто: регулятор сказал «нет» — значит нет. Никакие сертификаты OpenAI не помогут, если в требованиях написано: «данные не покидают контур компании». Точка. Это касается банков, страховых, госструктур, части медицинских организаций. В Казахстане это особенно актуально для операторов персональных данных определённых категорий.

Другой случай — коммерческая тайна. Один мой клиент разрабатывает промышленное оборудование. Хотел, чтобы AI помогал инженерам искать информацию по технической документации. Только вот эта документация — это годы R&D и миллионы долларов инвестиций. Отправлять чертежи нового продукта на серверы в США? Даже обсуждать не стали.

Есть и более прозаичные причины. Производственный объект где-нибудь в Мангистау с нестабильным интернетом. Или голосовой бот, которому нужно отвечать за 200 миллисекунд — иначе разговор становится неестественным. Физика не обманешь: сигнал до Калифорнии и обратно — это уже 250-300 мс только на пинг.

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

Экономика: давайте честно посчитаем

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

Чтобы запустить приличную локальную модель (скажем, Llama 3 70B), нужен сервер с серьёзными GPU. Это $15,000–50,000 только на железо. OpenAI берёт ноль долларов на старте — платишь только за использование.

Дальше — стоимость токенов. В облаке это $2.50–15 за миллион (зависит от модели). На своём железе — $0.10–0.50 (электричество плюс амортизация). Выглядит как победа локального решения, правда?

Но теперь добавим то, что обычно забывают. Локальная инфраструктура требует людей. Не 0.1 FTE на интеграцию, как с API, а 0.5–1 FTE постоянно. DevOps или MLOps, который следит за сервером, обновляет модели, чинит когда что-то падает. А падать будет — в самый неподходящий момент, в 3 ночи перед важной демо.

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

Есть ещё скрытые расходы, о которых не думают в начале. Резервный сервер (а если основной сгорит?). Охлаждение серверной — GPU греются как утюги. Лицензии на ПО. Апгрейды, когда памяти вдруг перестаёт хватать.

Когда же локальное решение окупается? Примерно при 50–100 миллионах токенов в месяц. Это около 500–1000 полноценных диалогов ежедневно. Для большинства среднего бизнеса в Казахстане — это очень много. Если у вас не такие объёмы, облако будет дешевле даже с учётом стоимости токенов. Больше про реальную стоимость внедрения AI-решений.

А что если не выбирать?

В реальной жизни «или-или» — это редкость. Обычно самое умное решение — гибрид. Разные задачи, разные инструменты.

Расскажу, как мы сделали для одной страховой компании. У них бот отвечает на вопросы клиентов. Когда человек спрашивает «какие у вас виды страхования?» или «сколько стоит КАСКО?» — это уходит в облако, на GPT-4. Никаких чувствительных данных, быстро, качественно.

Но когда клиент спрашивает «какой у меня лимит по полису?» — тут уже другая история. Нужен доступ к CRM, к данным конкретного человека. Этот запрос автоматически перенаправляется на локальную модель. Данные клиента не покидают контур компании, регулятор доволен, клиент получает ответ.

Как это технически реализуется? Есть несколько подходов. Самый простой — маршрутизация по ключевым словам: видим в запросе «мой полис», «мой лимит», «моя история» — отправляем локально. Более продвинутый — маскирование данных: локальный сервис заменяет ИИН на «@IIN@», имя на «@NAME@», отправляет в облако, получает ответ, подставляет реальные значения обратно. Облачная модель вообще не видит настоящих данных.

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

Какую модель ставить локально?

Допустим, решили идти в сторону своей инфраструктуры. Какую модель выбрать? На начало 2025 года ландшафт выглядит так.

Llama 3.1 70B — это рабочая лошадка для большинства. Хорошо понимает русский, справляется с продажами и поддержкой, не требует космических ресурсов. Два GPU A100 80GB или четыре A10 — и поехали. Для 90% бизнес-задач её более чем достаточно.

Llama 3.2 8B — вариант для тех, кто хочет попробовать с минимальными затратами. Одна RTX 4090 (геймерская видеокарта!) или A10 — и модель работает. Подходит для простых задач: FAQ, маршрутизация запросов, базовая классификация. Но не ждите от неё чудес в сложных диалогах.

Mistral Large — топовое качество, ближе всего к GPT-4 среди открытых моделей. Но и запросы соответствующие: четыре A100 80GB. Это уже серьёзная инвестиция, оправданная только для крупных проектов.

Qwen 2.5 72B — интересный выбор, если работаете с казахским языком или азиатскими рынками. Мультиязычность у неё отличная.

Честно скажу: локальные модели пока отстают от GPT-4 и Claude 3 Opus процентов на 15–25 в сложных задачах — там, где нужно многошаговое рассуждение или понимание тонкостей языка. Для стандартных сценариев поддержки и продаж разница почти незаметна. Но если вам нужно, чтобы AI проводил сложные B2B-переговоры — это может быть критично.

Быстрый тест: что выбрать вам?

Вот простой алгоритм, который мы используем при консультировании. Ответьте на пять вопросов — и картина станет ясной.

Облако — ваш вариант, если:

Регулятор не запрещает передачу данных за пределы компании. Чувствительные данные можно маскировать перед отправкой. Объёмы небольшие — меньше 50 миллионов токенов в месяц. Нужно запуститься быстро — за недели, а не месяцы. И главное — нет своей команды, которая будет поддерживать серверы.

Локальное решение — ваш вариант, если:

Регулятор требует хранить данные в контуре. Работаете с гостайной или критичными коммерческими секретами. Объёмы серьёзные — больше 100 миллионов токенов в месяц. Нужна мгновенная реакция для голоса или real-time сценариев. И есть DevOps или MLOps, который возьмёт это на себя.

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

Грабли, на которые наступают все

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

«У нас чувствительные данные» — и на этом анализ заканчивается. Фраза красивая, но бесполезная. Какие именно данные чувствительны? Можно ли их маскировать? Какой закон запрещает их передачу? Когда начинаешь разбираться, часто выясняется, что 90% данных спокойно можно обрабатывать в облаке, а для оставшихся 10% — делать исключение. Но вместо этого покупают сервер за $50k «на всякий случай».

Купили железо — и думают, что всё. Сервер за $30k, модель запустили, демо показали руководству. Победа? Через месяц выходит новая версия модели — нужно обновлять. Сервер начинает подвисать под нагрузкой — нужен DevOps. Памяти не хватает — апгрейд. Latency выросла — оптимизация. Это не разовая покупка, это ongoing commitment. К этому готовы единицы.

Сравнивают тёплое с мягким. Тестируют облако на GPT-4, а для локального решения берут Llama 8B — «чтобы сэкономить на железе». Потом удивляются, что качество отличается в разы. Ну да, модель в 10 раз меньше работает хуже — кто бы мог подумать? Если сравниваете — сравнивайте честно: GPT-4 vs Llama 70B или Mistral Large.

Упёртость в «или-или». Выбирают один вариант и держатся за него, хотя оптимальный путь — комбинация. Простые запросы — в облако (дешевле, качественнее). Сложные с приватными данными — локально. Да, это требует больше архитектурной работы. Зато получается решение, которое реально работает, а не компромисс со всеми недостатками обоих подходов.

А что у нас в Казахстане?

Несколько нюансов, специфичных для нашего рынка.

С инфраструктурой всё не так плохо. В Казахстане есть крупные ЦОД — KT Cloud, Kaztelecom — которые могут разместить GPU-серверы. Если ваш регулятор требует, чтобы данные не покидали РК, это решаемо. Не нужно строить собственную серверную.

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

Физика работает против облака. Из Алматы до серверов OpenAI в США — 200-300 мс только на пинг. Для текстовых ботов это терпимо: пользователь подождёт секунду, ничего страшного. Но если вы делаете голосового бота или real-time подсказки — эта задержка будет заметна. Разговор с паузами — это не разговор.

Главная проблема — кадры. MLOps-инженеров с реальным опытом работы с LLM в Казахстане — единицы. Буквально можно пересчитать по пальцам. Если планируете локальное развёртывание, заложите в бюджет либо обучение своей команды, либо привлечение специалистов из-за рубежа. Иначе сервер будет стоять, а поддерживать его будет некому.

Чем закончились те истории

Помните кейсы из начала? Вот чем они закончились.

Медицинский центр пошёл на гибридный вариант. Когда человек спрашивает «как подготовиться к МРТ?» или «где вы находитесь?» — отвечает облачная модель. Быстро, качественно, дёшево. Но как только в разговоре появляется конкретный пациент — его анализы, записи, рекомендации врача — всё переключается на локальную Llama 3.1 70B. Сервер стоит прямо у них в серверной, данные пациентов никуда не уходят. Безопасник счастлив, проект работает.

Финтех-компания пошла на полностью локальное решение. Там регуляторика не допускает компромиссов — или всё внутри, или никак. Развернули Mistral Large на выделенном сервере в ЦОД партнёра в Астане. Да, дороже. Да, дольше. Но других вариантов для них просто не было.

Какой из этого вывод? Не бывает универсального ответа «локально лучше» или «облако лучше». Это как спрашивать, что лучше — седан или внедорожник. Зависит от того, куда ехать. У вас есть конкретные требования бизнеса, конкретные регуляторные ограничения, конкретные клиенты. Честно проанализируйте их — и правильное решение станет очевидным.

Что ещё почитать

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

Локальные LLM для CRM: Llama, Mistral и приватность данных — там подробнее про настройку конкретных моделей и интеграцию с вашими системами.

Self-hosted LLM: инфраструктура, GPU, эксплуатация — техническая сторона вопроса: какое железо нужно, как настраивать, что может пойти не так.

Где хранить данные для AI: on-premise vs облако — ещё один взгляд на выбор инфраструктуры, но с фокусом на хранение данных.