Свои модели или облачный API: как компании выбрать без иллюзий

О чём на самом деле выбор

Под «локальной моделью» обычно понимают модель с открытыми весами: файлы модели можно скачать, запустить на своём оборудовании, дообучить и использовать без обращения к чужому серверу. Облачный API — это доступ к модели провайдера по сети: вы отправляете текст, получаете ответ и платите за объём обработанного текста.

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

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

Термины, без которых трудно договориться

• Открытые веса — опубликованные параметры модели, которые можно скачать и запустить. Это не всегда «открытый исходный код» в строгом смысле: лицензии различаются.
• Инференс — работа уже обученной модели: получение ответа на запрос. Именно инференс составляет основную нагрузку в продакшене.
• Контекстное окно — объём текста, который модель учитывает за один запрос: инструкции, документы, история диалога и ответ.
• Квантизация — хранение весов с пониженной точностью, чтобы модель занимала меньше памяти и работала быстрее, иногда ценой качества.
• Дообучение (fine-tuning) — дополнительное обучение модели на ваших примерах, чтобы она лучше решала конкретную узкую задачу.
• Шлюз моделей — внутренний сервис, через который все приложения компании обращаются к моделям: маршрутизация, логирование, лимиты, правила по данным.

Свои модели или API: базовые признаки

Когда нужны свои модели

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

• Данные нельзя передавать третьей стороне: требования закона о локализации персональных данных, договоры с клиентами, коммерческая тайна, внутренняя политика безопасности.
• Нужна работа без внешней сети — в закрытом контуре, на производстве, в изолированной инфраструктуре.
• Нагрузка большая и предсказуемая: оборудование будет загружено постоянно, а не простаивать большую часть суток.
• Нужна полная управляемость: зафиксированная версия модели, которая не изменится без вашего решения, собственное дообучение, контроль над задержкой.
• Задача узкая и хорошо решается небольшой моделью, дообученной на ваших данных: классификация обращений, извлечение полей из документов, маршрутизация, проверка формата.

Когда облачный API разумнее

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

Рамка решения: сценарии и выбор

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

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

Из чего складывается стоимость владения

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

Свои модели

• Оборудование: серверы с GPU, объём видеопамяти под выбранную модель с запасом на контекст и параллельные запросы, резерв на отказ — либо аренда такого оборудования.
• Размещение: электропитание, охлаждение, сеть, место в дата-центре, физическая безопасность.
• Люди: инженеры, которые разворачивают инференс, настраивают масштабирование, следят за обновлениями, безопасностью и инцидентами — включая дежурства.
• Простой: оборудование стоит денег, даже когда запросов нет, например ночью и в выходные.
• Оценка качества: при каждой смене модели или её версии нужно заново проверять, что она справляется с вашими задачами.
• Дообучение: подготовка и разметка данных, вычисления на обучение, хранение версий моделей.

Облачный API

• Оплата за объём обработанного текста, которая растёт вместе с нагрузкой и длиной контекста.
• Работа юристов и специалистов по безопасности: договор, условия обработки данных, соответствие требованиям.
• Зависимость от провайдера: изменение цен и условий, снятие старых версий моделей с поддержки, ограничения на частоту запросов.
• Обезличивание и фильтрация данных перед отправкой, если это требуется, — это тоже код и инфраструктура.
• Миграции: когда старая версия модели снимается с поддержки, промпты и проверки качества приходится обновлять.

Как посчитать без самообмана

1. 01Оцените объём: сколько запросов в день в среднем и в пике, какой средний размер входа и ответа в токенах. Возьмите это из реальных логов пилота, а не из предположений.
2. 02Для API умножьте объём на тарифы выбранной модели и добавьте запас на рост и на повторные запросы при ошибках.
3. 03Для своих моделей определите, какое оборудование выдерживает пиковую нагрузку с нужной задержкой, — это проверяется нагрузочным тестом, а не расчётом на бумаге.
4. 04Добавьте людей: какая доля времени инженеров уйдёт на эксплуатацию, и кто дежурит при сбое.
5. 05Сравните оба варианта на горизонте нескольких лет и проверьте чувствительность: что будет, если нагрузка окажется в разы меньше или больше ожидаемой.

Что придётся решать при запуске своей модели

Размер модели и железо

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

Квантизация

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

Сервер инференса

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

Лицензия

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

Обновления и безопасность

Открытые модели выходят часто, и соблазн «обновиться на новую» велик. Нужен процесс: новая версия проходит проверку качества и безопасности на вашем наборе примеров, сравнивается со старой и только потом заменяет её. Веса скачивайте из официальных источников и проверяйте контрольные суммы — файл модели тоже может быть подменён.

Доступ и изоляция

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

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

Гибридная схема и шлюз моделей

Во многих компаниях разумно разделить поток запросов. Чувствительные данные обрабатываются локальной моделью или обезличиваются до отправки. Массовые узкие задачи отдаются небольшой дообученной модели у себя. Сложные задачи без персональных данных — облачному API.

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

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

Пример: как могла бы рассуждать компания

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

• Сортировка обращений — узкая, массовая задача, а в обращениях есть имена и телефоны клиентов. Разумный кандидат — небольшая открытая модель в своём контуре, дообученная на размеченных прошлых обращениях.
• Черновики ответов требуют хорошего понимания текста, но опираются на конкретного клиента. Вариант — обезличить обращение на своей стороне, отправить в сильную облачную модель и подставить реальные данные обратно уже у себя.
• Еженедельный обзор строится по агрегированной статистике тем без персональных данных. Его можно спокойно делать облачной моделью.

Все три задачи идут через один шлюз. Если позже окажется, что локальная модель хорошо справляется и с черновиками, маршрут меняется в одном месте, без переделки интерфейса операторов. Главное в этом примере — решение принималось отдельно для каждой задачи, а не «для компании в целом».

Пилот шаг за шагом

1. 01Классифицируйте данные: что можно отправлять наружу, что только после обезличивания, что нельзя совсем.
2. 02Опишите задачи и требования к качеству, задержке и доступности.
3. 03Соберите набор реальных примеров для проверки — с правильными ответами или критериями оценки. Без такого набора сравнение моделей превращается в обмен впечатлениями.
4. 04Прогоните на этом наборе и облачные, и открытые модели нескольких размеров, включая квантованные версии. Сравнивайте на своих задачах, а не по общим рейтингам.
5. 05Запустите пилот на небольшой группе пользователей через шлюз и соберите реальные данные о нагрузке и качестве.
6. 06Посчитайте стоимость владения для обоих вариантов по реальным цифрам пилота.
7. 07Примите решение по каждой задаче отдельно и запишите, при каких условиях его стоит пересмотреть.

Как оценивать качество на пилоте

Для задач с однозначным ответом — тема обращения, извлечённое поле — качество считается автоматически: доля совпадений с эталоном. Для свободного текста нужны критерии: опирается ли ответ на факты из источника, соблюдён ли формат, нет ли выдуманных деталей. Часть таких проверок можно автоматизировать, но выборку ответов стоит регулярно читать людям, которые знают предметную область. Отдельно проверяйте тексты на узбекском и русском языках и смесь языков: модели нередко ведут себя на них по-разному.

Типичные ошибки и как их заметить

• Выбор модели по общему рейтингу. Как заметить: у команды нет собственного набора проверочных примеров. Как исправить: собрать его до сравнения моделей.
• Расчёт стоимости без людей и простоя. Как заметить: в расчёте есть только железо и тарифы. Как исправить: добавить время инженеров, дежурства и загрузку оборудования по часам.
• Квантизация «на веру». Как заметить: квантованную версию не сравнивали с полной на своих задачах. Как исправить: прогнать оба варианта на одном наборе.
• Прямые вызовы моделей из каждого сервиса. Как заметить: смена модели требует правок в нескольких репозиториях. Как исправить: ввести шлюз.
• Непроверенная лицензия. Как заметить: никто в компании не может сказать, разрешено ли коммерческое использование. Как исправить: юридическая проверка до продакшена.
• Обновление модели без регрессионной проверки. Как заметить: качество «вдруг» упало после обновления. Как исправить: обязательный прогон набора примеров перед заменой версии.

Чек-лист перед решением

1. 01Данные классифицированы по допустимости отправки наружу.
2. 02Для каждой задачи описаны требования к качеству, задержке и доступности.
3. 03Есть набор реальных проверочных примеров с критериями оценки.
4. 04Облачные и открытые модели сравнены на этом наборе, включая квантованные версии.
5. 05Нагрузка оценена по данным пилота: среднее, пик, профиль по времени суток.
6. 06Стоимость владения посчитана для обоих вариантов, включая людей, простой и миграции.
7. 07Проверена лицензия каждой открытой модели.
8. 08Определено, кто эксплуатирует инфраструктуру и дежурит при сбоях.
9. 09Все приложения ходят к моделям через единый шлюз.
10. 10Есть процесс обновления модели с регрессионной проверкой.
11. 11Записано, при каких условиях решение будет пересмотрено.

Итог

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