Локальные LLM и облачные модели: как выбрать размещение

С чего начать выбор размещения

Если рабочие данные запрещено передавать внешнему AI-сервису, сначала проверяйте вариант внутри разрешённой инфраструктуры. Если передача допустима, включите облачный API в сравнение. Уже используемая облачная платформа тоже может стать кандидатом, но наличие договора с ней ещё не определяет условия конкретной модели.

Рекомендация Dev Crabs: составьте короткий паспорт задачи: входные документы, требуемый ответ, допустимые ошибки, участники процесса, ограничения ИБ, обычная и пиковая нагрузка. Вычеркните варианты, которые не проходят обязательные ограничения. Среди оставшихся выбирайте по измерениям пилота.

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

Что меняет новый облачный анонс

Подтверждённый факт: 21 октября 2026 года OpenAI объявила о планах интеграции моделей и рабочих процессов Codex в Google Cloud Model Garden. В сообщении OpenAI, перепроверенном 29 октября, общая доступность всё ещё обозначена как план на ближайшие недели. Этот источник подтверждает анонс, а не состоявшийся запуск для всех клиентов.

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

Сам анонс не доказывает рост спроса или преимущество облачного варианта. Сравнимой динамики интереса для такого вывода здесь нет.

Три варианта: кто управляет моделью

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

Локальная LLM — модель, вычисления которой выполняются в выбранной вами среде. При этом сервер в арендованном облаке остаётся облачной инфраструктурой, даже если приложение не обращается к внешнему API модели. Для требований ИБ важнее точная схема обработки и доступов, чем слово «локальный».

В качестве технического примера: llama.cpp поддерживает запуск моделей на разных CPU/GPU и квантование для уменьшения потребления памяти. Это возможность инструмента, а не гарантия скорости или качества выбранной модели на вашем оборудовании. Проверять нужно совместимость модели, её лицензию и фактическую конфигурацию.

Что сравнивать до закупки и подключения

В таблице — вопросы для обследования, а не рейтинг поставщиков. Заполняйте ответы для конкретных конфигураций; неизвестное условие оставляйте открытым до проверки.

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

Полная стоимость: считайте принятый результат

Сравнивайте один период, одинаковый объём задач и одинаковые требования к качеству. Для каждого варианта оцените следующие статьи затрат; цены поставщиков подставляйте по проверенным условиям вашего проекта.

Стоимость за период = внедрение + лицензии/API + инфраструктура + эксплуатация + проверка качества + ручная обработка.

• Внедрение: интеграции, перенос данных, настройка доступов и подготовка контрольных примеров. Единовременные работы показывайте отдельно от регулярных расходов.
• Лицензии/API: все вызовы процесса, включая повторные, поиск, распознавание и другие используемые сервисы. Для локальной модели тоже проверьте условия лицензии.
• Инфраструктура: аренда либо согласованная доля стоимости оборудования за период, хранение, энергия, резервирование. Покупку и амортизацию одного сервера не складывайте дважды.
• Эксплуатация и качество: рабочее время команды, мониторинг, обновления, разметка и повторная приёмка.
• Ручная обработка: проверка ответов, исправления, повторная работа и задачи, которые пришлось полностью передать человеку.

Стоимость принятого результата = все затраты за период / число результатов, прошедших одинаковые критерии приёмки. Если принятых результатов нет, вариант пока не решает задачу. Сначала разберите причины отказов, затем оценивайте экономику.

Учебный расчёт с вымышленными числами. Пусть за месяц в обоих вариантах приняты 1 000 задач. У варианта А инфраструктура и сервисы стоят 20 000 ₽, у Б — 45 000 ₽. Условно остальные затраты одинаковы: 30 000 ₽. Если А требует 80 часов проверки и исправлений, а Б — 20 часов при условной стоимости часа 1 000 ₽, суммы составят 130 000 ₽ и 95 000 ₽; на принятый результат — 130 ₽ и 95 ₽.

Если же А потребует 30 часов ручной работы, его сумма станет 80 000 ₽, или 80 ₽ за результат, и порядок изменится. Это арифметическая иллюстрация чувствительности к ручному труду, не тариф, смета, замер моделей или обещание экономии. Для реального решения подставьте измеренные часы, затраты и объём; отдельно проверьте сценарий пика и низкой загрузки.

Как проверить качество и скорость на одной задаче

«Лучшие локальные LLM» для вашего процесса — те конфигурации, которые проходят согласованную приёмку. Публичный рейтинг помогает составить список кандидатов, но не заменяет проверку ваших документов, русского языка, терминологии и допустимых ошибок.

1. Соберите обезличенный контрольный набор: обычные случаи, длинные документы, неполные данные, противоречия и запросы, на которые система должна отказаться отвечать. Для каждого заранее опишите ожидаемый результат.
2. Выделите отдельные примеры для настройки и для итоговой проверки. Зафиксируйте версии моделей, параметры, источники знаний и права доступа. Не подбирайте ответы под контрольный набор.
3. Сравните долю принятых ответов, критические ошибки, время проверки сотрудником и корректность отказов. Если качество требует доступа к документам, обеспечьте сопоставимые источники для всех кандидатов.
4. Повторите проверку при обычной и пиковой одновременной нагрузке. Запишите полное время выполнения задачи, задержку первого ответа, ожидание в очереди и ошибки. Длинные запросы испытайте отдельно.

В документации vLLM раздельно описаны метрики времени до первого токена, полной задержки запроса и ожидания в очереди. Это полезные технические измерения для своего запуска; они не оценивают смысл ответа. Для пользователя дополнительно измеряйте время от отправки задания до готового результата со всеми поисками, проверками и повторами.

RAG помогает организовать поиск по источникам, а fine-tuning — адаптацию поведения модели. Эти решения рассматриваются отдельно от размещения. Если ошибка возникает на этапе извлечения текста или поиска документа, замена модели сама по себе может её не устранить.

Почему локальный запуск ещё не закрытый контур

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

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

Факт из документации: Google отдельно описывает ограничения на обучение и условия хранения данных в документе о zero data retention. Настройки журналирования, кэширования и отдельных функций имеют значение. Поэтому запрет использовать данные для обучения нельзя автоматически приравнивать к отсутствию хранения. Условия этого документа не следует переносить на все продукты и поставщиков.

Для собственного размещения нужны аналогичные ответы о внутренних журналах, доступах и резервных копиях. Согласуйте карту с ИБ и ответственными за данные до передачи рабочих документов. Она помогает проверить техническую схему; сама по себе не подтверждает выполнение всех договорных и нормативных требований.

План пилота и решение о запуске

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

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

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

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

Разобрать требования к AI-контуру →

Частые вопросы