Облачный API или своё железо: как выбрать LLM под задачу

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

Ниже — рабочая схема, по которой можно принять решение за один-два дня, а не за квартал совещаний.

Сначала опишите задачу одной фразой

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

• какие данные пойдут в модель (письма клиентов, внутренние документы, код);
• сколько запросов в день ожидается — десятки, тысячи или сотни тысяч;
• кто ждёт ответа — человек в чате или ночной пакетный процесс;
• насколько дорога ошибка — опечатка в черновике письма или неправильная сумма в счёте.

Эти четыре пункта и есть критерии выбора. Разберём каждый.

Критерий 1. Данные: что можно отдавать наружу

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

Полезно разложить данные на три корзины:

1. Открытые. Публичные тексты, маркетинговые материалы, общие вопросы. Можно отправлять куда угодно.
2. Внутренние. Регламенты, переписка, отчёты без персональных данных. Можно отправлять провайдеру, если условия договора устраивают: данные не используются для обучения, есть понятный срок хранения, понятна юрисдикция.
3. Чувствительные. Персональные данные, финансы, тайна, доступы. Либо обезличивать до отправки, либо обрабатывать только внутри периметра.

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

Критерий 2. Цена: платить за токены или за сервер

У облачного API модель расходов простая: платите за объём текста на входе и на выходе. Нет запросов — нет счёта. У своего железа наоборот: крупный платёж на старте, затем примерно постоянные расходы на электричество, место в стойке и администрирование, независимо от нагрузки.

Отсюда практическое правило: облако выгоднее при низкой и неравномерной нагрузке, своё железо — при высокой и стабильной. Точку перелома нужно считать на ваших объёмах. Грубый способ:

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

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

Критерий 3. Задержка: кто и сколько ждёт

Есть два режима работы с моделью.

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

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

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

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

Критерий 4. Качество: насколько умная модель нужна

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

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

1. Возьмите 30–100 реальных примеров из вашей задачи.
2. Для каждого запишите, какой ответ считается правильным или хотя бы приемлемым.
3. Прогоните через две-три модели-кандидата с одинаковым промптом.
4. Оцените вручную или по простым правилам: совпала категория, нашлось нужное поле, нет выдуманных фактов.

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

Как сложить всё вместе

Удобно свести критерии в простую таблицу решений:

Ситуация	Скорее подойдёт
Данные открытые или внутренние, нагрузка небольшая, нужно высокое качество	Облачный API
Данные чувствительные, задача типовая (классификация, извлечение)	Локальная модель среднего размера
Данные смешанные, нагрузка растёт	Гибрид: маршрутизация запросов между локальной и облачной моделью
Большой стабильный поток однотипных запросов	Своё железо, если есть кому его обслуживать
Задача ещё не понятна, нужно попробовать	Облако на этапе пилота, решение о железе — после

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

Не привязывайтесь к одному поставщику

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

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

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

Короткий чек-лист

Перед тем как выбирать модель, ответьте на вопросы:

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

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