Multi-vendor LLM:
зависимость
от поставщика
Export controls и смена политик API — почему single-vendor рискован и какой минимальный hedge: gateway, model mix, абстракция вызова.
Export controls на frontier-модели и внезапные изменения API-политик сделали single-vendor dependency не абстрактным риском, а операционной проблемой. Sakana Fugu продаётся с тезисом AI sovereignty: пул моделей можно менять, маршрут — перестраивать.
Коротко: если критичный процесс завязан на один API одного вендора — вы не владеете инфраструктурой интеллекта, вы арендуете её с условиями, которые меняются без предупреждения.
Типичные сценарии риска
- региональные ограничения и export controls;
- смена цен или лимитов rate limit;
- deprecation модели, на которой собран продукт;
- compliance: данные нельзя отправлять в конкретный облачный контур.
Практический hedge для команд
- Multi-provider gateway — один ключ, несколько upstream (IRI Gateway, OpenRouter-аналоги).
- Модельный микс — flagship на критичных шагах, дешёвые модели на рутине (DeepSeek, Gemini).
- Абстракция вызова — OpenAI-compatible client, смена
modelбез переписывания кода. - Оркестрация — слой, который сам переключает модели (Fugu, собственный runtime).
Для России
Оплата в рублях, договор с юрлицом и единый endpoint снижают трение, но не отменяют vendor risk на upstream. IRI Gateway даёт локальный контур закупки и переключения; ответственность за архитектуру «не один вендор» остаётся у команды.
Итог
Multi-vendor — не паранойя, а зрелая архитектура 2026. Gateway + runtime + осознанный model mix — минимальный набор. Оркестрационные продукты вроде Fugu — следующий уровень автоматизации этого hedge.