К 2026 году российский рынок LLM повзрослел: у крупных вендоров возможности сопоставимы, а различия лежат в деталях — режимах размещения, интеграциях и условиях для конкретной задачи. Поэтому вопрос «кого выбрать» постепенно сменяется вопросом «сколько вендоров держать». Это решение не про качество конкретной модели, а про управление зависимостью: что произойдёт с вашим процессом, если у единственного поставщика изменится тариф, лимит или доступность.
Эта страница сводит выбор в таблицы «когда что» и критериев: стоимость, сроки, риски, поддержка, комплаенс и режим данных. Конкретное сравнение возможностей двух крупнейших российских экосистем — в отдельном гиде «GigaChat или YandexGPT для бизнеса»; здесь — стратегия количества поставщиков.
Кратко: когда что выбирать
Прямой ответ — в таблице: слева ситуация, справа разумное решение по состоянию на сентябрь 2026 года. Если узнали свою компанию в одной из строк — дальше достаточно проверить решение по чек-листу в конце страницы, а не перечитывать весь интернет.
| Ситуация | Стратегия | Почему |
|---|---|---|
| Первый ИИ-проект, пилот, одна узкая задача | один вендор | скорость и экономия важнее страховки, которой пока нечего страховать |
| ИИ-процесс стал критичным для выручки или сервиса | основной + резервный | переключение за минуты дешевле простоя критичного процесса |
| Госзаказчик, КИИ, регулируемая отрасль | мультивендорность в политике ИИ | зависимость от одного поставщика — находка аудиторов и риск закупки |
| Переменная нагрузка с пиками (сезонность, кампании) | один основной + резерв на пиках | лимиты одного API не приходится «протягивать» авралом |
| Малый бизнес без ИИ-команды | один вендор | два интеграционных контура не обслуживать силами двух человек |
| Миграция с зарубежного API на российский | один вендор + абстракция | слой-адаптер важнее второго вендора: он же позволит добавить третьего |
Критерии сравнения
Развёрнутая матрица по критериям, которые заказчики проверяют перед решением: стоимость, сроки, риски, поддержка, комплаенс и режим данных. Каждая строка матрицы ниже раскрыта отдельным разбором — с пояснениями, откуда берутся цифры и на что смотреть в вашей ситуации.
| Критерий | Один вендор | Мультивендорная стратегия |
|---|---|---|
| Стоимость входа | пилот от 480 000 ₽, один контракт и одна настройка | резервный контур — от 690 000 ₽; паритет моделей кратно дороже |
| Сроки запуска | 4–6 недель на пилот | пилот так же, но +2–4 недели на резервный канал и тесты переключения |
| Риски | полная зависимость от тарифов, лимитов и доступности одного API | зависимость снижена; растёт сложность и число точек отказа конфигурации |
| Миграция | тяжёлая: вызовы вендора размазаны по коду | лёгкая при слое абстракции: переносится конфиг, а не проект |
| Комплаенс и 243-ФЗ | один реестровый объект учёта, один набор документов | два комплекта интеграционной документации и записей в реестре ИИ-активов |
| Режим данных | один договор поручения обработки, один контур | контролировать, какие данные какому вендору можно отправлять |
| Поддержка | один SLA, одна линия вендора | два SLA; при инциденте важно, чей канал выключился |
Матрица выше — навигация: каждая строка раскрыта разбором ниже, а решения стоит проверять на своих цифрах и своей отрасли.
Разбор критериев
Стоимость и скрытая цена паритета
Полный паритет — когда каждый запрос умеет выполнять любой из вендоров — означает двойную интеграцию, двойное тестирование и двойной контроль качества. Для большинства задач это избыточно: рабочая схема 2026 года — основной вендор плюс резервный канал на критичных сценариях. Пилот на одном вендоре — от 480 000 ₽; добавление резервного контура с тестами переключения — от 690 000 ₽. Как складывается цена интеграции, разбирает ответ на вопрос «как считается цена LLM-интеграции».
Риск зависимости: что именно ломается
Зависимость от одного вендора — это не абстракция, а конкретные сценарии: изменились тарифы и экономика процесса уехала; ужесточились лимиты запросов в час; API недоступен в момент пиковой нагрузки; изменился формат ответа после обновления модели. Ни один из них не является «виной» вендора — это нормальная жизнь любого облачного API. Вопрос лишь в том, сколько стоит простой вашего процесса и сколько стоит страховка от него.
Миграционная готовность
Ключевая инженерная практика — слой абстракции над вызовами модели: единый интерфейс, в котором промпты, формат ответа и обработка ошибок живут у вас, а специфичные вызовы вендора — в заменяемых адаптерах. Техническую сторону распределения запросов между моделями разбирает гид «LLM-роутинг или одна модель». Без такого слоя смена вендора превращается в переделку половины системы; со слоем — в замену конфигурации и неделю тестов.
Комлаенс, 243-ФЗ и реестр активов
С сентября 2026 года базовые положения 243-ФЗ уже действуют, а с 1 марта 2027 появляются обязанности для разработчиков больших моделей — у заказчиков же появляется документационная нагрузка. Каждый подключённый вендор — это отдельная запись в реестре ИИ-активов, свой договор поручения обработки данных и свой набор оценок рисков. Два вендора — двойной объём документов, зато аудиторский вопрос «а что, если этот поставщик исчезнет» уже закрыт. Как вести учёт, разбирает гайд «как вести реестр ИИ-активов по 243-ФЗ».
Режим данных и контуры
Мультивендорность не отменяет главный вопрос: какие данные какому поставщику можно отправлять. Часто разумнее держать двух вендоров под разные классы данных: обезличенные маркетинговые тексты — в облако, кадровые документы и договоры — только в локальный контур одного вендора или свою инфраструктуру. Такое разделение по классам данных даёт большую часть выгод мультивендорности без двойной цены полного паритета.
Команда и эксплуатация
Один вендор обслуживается силами небольшой команды; два контура требуют уже выстроенного LLMOps: мониторинга обоих каналов, регламента переключения и регулярных проверок резерва. Если команды нет, резерв «на бумаге» опаснее его отсутствия: в момент аварии выяснится, что ключи истекли, а промпты не совместимы. Подготовку команды к эксплуатации ИИ стоит планировать одновременно с резервным каналом.
Вердикты по трём сценариям
Сценарий 1. Первый проект и малый бизнес
Один вендор, но с инженерной дисциплиной: слой абстракции, вынесенные промпты и эталонные тестовые наборы с самого первого пилота. Это стоит копейки на старте и превращает будущую смену вендора из катастрофы в плановую работу. Добавлять второго поставщика имеет смысл после того, как процесс пережил хотя бы одно обновление модели.
Сценарий 2. Критичные процессы среднего и крупного бизнеса
Основной вендор плюс проверенный резервный канал на сценариях, где простой недопустим: клиентская поддержка, обработка документов с дедлайнами, мониторинг. Резерв тестируется ежемесячными прогонами, а не существует в договоре. Промышленный контур с резервированием — от 690 000 ₽; полный договор с несколькими ИИ-процессами — 0,9–1,2 млн ₽.
Сценарий 3. Госзаказчики и регулируемые отрасли
Мультивендорность фиксируется в политике использования ИИ и закупочной документации: критерии выбора, порядок резервирования, требования к режиму данных. Для тендерных процедур это превращает зависимость от поставщика в управляемый риск с бумажным следом. Полный разбор выбора ИИ-вендора по 243-ФЗ — в гайде «как выбрать ИИ-вендора по 243-ФЗ».
Типичные ошибки выбора
Ошибки этого выбора повторяются от проекта к проекту и почти всегда дорого обходятся при первом же инциденте.
- Мультивендорность «для галочки»: резерв записан в договоре, но ни разу не тестировался переключением.
- Полный паритет моделей там, где хватило бы резерва на одном критичном сценарии — двойная цена без двойной пользы.
- Вызовы вендора захардкожены в бизнес-логику: сменить поставщика нельзя, не переписав систему.
- Эталонных тестов нет ни по одному вендору: после миграции «стало вроде нормально» — не результат.
- Смена вендора без обновления реестра ИИ-активов и оценок рисков — документационный долг перед ближайшим аудитом.
Итог
Мультивендорность — страховка критичных процессов, а не мода: один вендор для старта, основной плюс проверенный резерв для критичных сценариев, фиксация в политике ИИ для регулируемых отраслей. Решение стоит перепроверить на своих цифрах: разбор задачи бесплатный, ответ — за 1 рабочий день.
Чек-лист решения
Семь пунктов, которые стоит закрыть до выбора: они одинаково полезны обоим вариантам и закрывают большинство ошибок из списка выше. Пройдите список с командой — обычно это один рабочий час, который экономит недели переделок.
- Определите, какие ИИ-процессы критичны: простой чего недопустим ни на час?
- Проверьте наличие слоя абстракции над вызовами модели в текущем коде.
- Соберите эталонный тестовый набор: входы, ожидаемые выходы, замер по текущему вендору.
- Зафиксируйте классы данных: что можно в облако, что только в изолированный контур.
- Выберите резервного вендора под те же классы данных и режим размещения.
- Проведите тестовое переключение и запишите время восстановления.
- Отразите обоих вендоров в реестре ИИ-активов и договорах поручения обработки.
Смежные материалы
Сравнение конкретных экосистем — «GigaChat или YandexGPT для бизнеса»; технический роутинг запросов — «LLM-роутинг или одна модель»; аргументы за российские модели — «почему заказчики выбирают российские LLM». Форматы работ — интеграции LLM.
Полный каталог разборов «или — или» — в разделе Сравнения; форматы работ, сроки и цены «от» — в каталоге услуг.