Как избежать вендорного лок-ина в AI-разработке: требования к RFP на 2026 год

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

Откуда берётся скрытая налоговая нагрузка

В 2023 году средняя компания эксплуатировала 2,3 отдельные AI-платформы. К 2026 году аналитики ожидают 4,1. Каждый новый провайдер — это свой SDK, своя авторизация, свои способы тюнинга. И всё это надо как-то мирить между собой.

Вот конкретный сценарий. Отдел антифрода построил систему на проприетарной векторной базе и API провайдера A. Отдел поддержки выбрал провайдера B ради более сильных LLM. В итоге два контура эмбеддингов, два дашборда, нет общего хранилища фичей. Чтобы свести данные в единую картину, разработчикам нужно около 600 часов. По консервативной ставке $150 в час это $150 000 долга, порождённого «удобством» первого выбора.

Vendor lock-in работает на трёх уровнях, и каждый следующий выбраться сложнее.

Три уровня ловушки

1. Уровень API

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

2. Уровень данных

Управляемые векторные базы и фича-сторы хранят эмбеддинги в закрытых форматах. Миграция — это терабайты данных и риск деградации моделей при повторной индексации.

3. Уровень оркестрации

Менеджеры рабочих процессов, мониторинг, A/B-тесты — всё прибито к экосистеме вендора. Гибридные или мультимодельные развёртывания становятся операционно опасными и дорогими.

Что требовать в RFP на 2026 год

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

• Мультимодельный рантайм. Платформа обязана показать бенчмарки: как она обслуживает модели из минимум трёх фреймворков (PyTorch, TensorFlow, JAX) и двух провайдеров — например, открытую Llama и проприетарную модель — на одном кластере с общим автоскейлингом.
• Открытые схемы. Inference API должен быть совместим с OpenAI-эндпоинтами или другим признанным стандартом. Фича-сторы должны отдавать данные в Apache Arrow и аналогичных форматах.
• Прозрачный вывод данных. Вендор обязан описать процедуру экспорта: инструменты для миграции эмбеддингов, весов моделей, определений пайплайнов в ONNX или PMML.

Код, написанный под одного вендора, — это приговор. Требуйте абстракцию, которая работает с любым провайдером, а не только с текущим фаворитом.

Цена лок-ина: 36-месячный прогноз

Смоделируем среднюю компанию: 5 AI-приложений сейчас, 20 к 2026 году. Если сидеть на одном вендоре, совокупная стоимость владения за три года будет на 35% выше, чем на переносимой платформе. Откуда берётся разница?

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

Чек-лист проверки платформы

Заставьте вендора доказать переносимость, а не обещать её в презентации. Три проверки:

1. Миграционный тест. Живая демонстрация: перенесите образец модели и её фича-стор из окружения вендора в нейтральный Kubernetes-кластер, используя только задокументированные инструменты.
2. Мультивендорный запуск. PoC, в котором одно и то же приложение обслуживает запросы и через собственную модель вендора, и через внешнюю open-source модель, с едиными метриками наблюдения.
3. Аудит лок-ина. Письменный технический документ: перечислить каждый проприетарный компонент, формат данных и шаги замены. Вендор, уверенный в своей переносимости, отдаст его без колебаний.

Если вендор упирается или говорит, что «всё будет работать само», — это уже ответ.

В 2026 году гибкая AI-инфраструктура — не роскошь, а требование выживания. Иначе к 2027-му вы получите лоскутный стек, который душит инновации и высасывает бюджет. Закладывайте переносимость в RFP сейчас, чтобы завтра выбирать лучшие модели под каждую задачу, а не то, что позволяет ваш текущий провайдер.