Поделиться
Поделиться

Рынок LLM в 2026 году выглядит как набор сильных, но неравномерно доступных API. Gemini сильен в мультимодальности и длинном контексте — и при этом доступ из РФ часто нестабилен или завязан на обходные схемы, которые нельзя закладывать в SLA продукта. YandexGPT и GigaChat закрывают локальный контур и требования к размещению данных. Open-weight модели на своём железе дают предсказуемость для НИИ и промышленных заказчиков. Вопрос не «какая модель лучшая», а «как не привязать продукт к одному endpoint’у».

В OtherCode мы с самого начала проектируем AI-фичи как слой с адаптерами: смена провайдера — конфигурация и регрессионный набор промптов, а не переписывание бизнес-логики.

Зачем нужна мультипровайдерная стратегия

Один провайдер удобен в пилоте. В production появляются четыре класса рисков:

| Риск | Симптом | Цена | |------|---------|------| | Доступность | 403 / geo-block / деградация API | Простой фичи | | Цена | Резкий рост тарифа или лимитов | Срыв unit-экономики | | Качество | Регрессия после обновления модели | Рост ручных правок | | Комплаенс | Данные нельзя уводить за периметр | Срыв сдачи заказчику |

Стратегия «основной + запасной + локальный для sensitive» закрывает эти риски лучше, чем вечный поиск «лучшей» модели в бенчмарках.

Краткая карта провайдеров для практики в РФ

Gemini (Google)

Сильные стороны: длинный контекст, мультимодальность, качество reasoning на сложных черновиках. Слабые для продуктов в РФ: нестабильный доступ, зависимость от Google-аккаунтов и облака, риск внезапного изменения условий. Для студийных экспериментов Gemini может быть полезен; для критичного контура заказчика — только через осознанный fallback. Инфраструктурный контекст — в статье про альтернативы Google-сервисам.

YandexGPT

Плюсы: доступность из РФ, интеграция с экосистемой Яндекса, предсказуемее с точки зрения юридического контура для многих заказчиков. Минусы: нужно отдельно калибровать промпты (они не «магически» совпадают с GPT-4o), следить за лимитами и стоимостью на длинных документах.

GigaChat

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

OpenAI / совместимые API и open-weight

Где доступен корпоративный контракт — сильный baseline для Content Factory и внутренних инструментов. Где нельзя — локальные Llama / Qwen / аналоги на GPU в self-hosted контуре студии или заказчика. Качество ниже топ-облака на «открытых» задачах часто компенсируется контролем данных и latency внутри периметра.

Абстракция: что выносим из бизнес-кода

Минимальный контракт адаптера, который мы используем в продуктах:

LLMProvider
  - complete(prompt, schema?, temperature?) → text | json
  - embed(texts[]) → vectors[]          // если нужен RAG
  - health() → ok | degraded
  - name / model / pricing_tier         // для метрик

Поверх адаптера — оркестратор:

  1. Выбор маршрута (primary / secondary / local) по политике и health-check.
  2. Кэш идентичных запросов (осторожно с персональными данными).
  3. Валидация JSON-схемы ответа.
  4. Запись в audit: provider, model version, latency, token estimate, prompt_id.

Бизнес-код URAP или Content Factory вызывает complete(), а не SDK конкретного вендора. Смена YandexGPT → GigaChat для одного типа задач — правка конфига и прогон golden-набора.

Golden-набор промптов

Без регрессии «модель обновили — качество уехало» мультипровайдерность бессмысленна. Мы держим набор из 30–100 эталонных входов:

  • документы / тексты с ожидаемым JSON;
  • негативные кейсы (пустой ввод, мусор, двусмысленность);
  • метрики: exact match полей, доля эскалаций к человеку, latency p95.

Прогон — в GitLab CI на ночном пайплайне или перед сменой default-модели. Подход к пайплайнам описан в GitLab CI/CD; для LLM добавляется job с секретами провайдеров из защищённых variables, не из репозитория.

Как OtherCode выбирает маршрут на практике

Content Factory

Маркетинговый и редакционный контент: облачный провайдер с лучшим качеством текста на русском + запасной российский API. Промпты версионируются. Публикация — после модерации. Если primary недоступен, очередь не падает: задачи уходят на secondary с пометкой в UI «сгенерировано запасной моделью».

URAP AI (OCR / NLP)

Распознавание зон и классификация — детерминированные и ML-модели ближе к данным. LLM — нормализация и «мягкие» поля. Для заказчиков с запретом на внешний API включаем локальный инференс или российский провайдер. Схема ответа жёсткая: лишние поля отбрасываются, недостающие — в очередь ручной разметки. См. также Python OCR.

Synapse Stream

Потоковая аналитика и книга/проект вокруг платформы требуют предсказуемого latency. Здесь LLM — вспомогательный слой (подсказки, разбор логов для поддержки), не hot-path обработки потока. Hot-path остаётся детерминированным. Контекст продукта: Synapse Stream.

Промышленность: Galvatec, Typhoon (STM32)

Команды на контроллеры, уставки, аварийные сценарии — не через LLM. Модели могут помочь инженеру написать тест прошивки или черновик протокола на стенде. В runtime на объекте — whitelist команд, сегментация сети, без «агента, который сам решит нажать Stop». Для НИИ часто требование — on-prem: веса моделей и логи не покидают контур.

Diom (Flutter) и Next.js-сайты

В мобильном и веб-клиенте LLM почти никогда не вызывается напрямую с устройства с секретом. Вызов идёт через backend студии: ключи на сервере, rate limit, политика провайдера, аудит. Next.js-сайты студии на self-hosted — тот же принцип: контроль периметра важнее «удобного» serverless у одного облака.

Когда on-prem / локальные модели обязательны

| Сигнал | Решение | |--------|---------| | Персданные / госзаказ / NDA на данные | Локальный или аттестованный контур | | Заказчик запрещает внешние API | On-prem GPU + open-weight | | Нужен air-gapped стенд | Офлайн-сборка образов, без phone-home | | Стабильный latency важнее SOTA | Локальный инференс с фиксированной версией весов |

Локальная модель слабее топ-облака на открытых бенчмарках — и часто достаточна, если задача узкая (классификация, извлечение по схеме, короткий paraphrase). Узость задачи важнее громкого имени модели.

Как калибровать промпты под разных вендоров

Ошибка новичка — взять промпт, отлаженный на одной модели, и «просто сменить endpoint». Формат system/user, склонность следовать JSON-схеме, чувствительность к temperature и поведение на русском юридическом тексте отличаются.

Практический порядок калибровки в OtherCode:

  1. Зафиксировать схему ответа (JSON Schema / pydantic) — она важнее формулировок.
  2. Прогнать golden-набор на primary, замерить exact match и долю parse-error.
  3. На secondary подобрать temperature и system-инструкцию, не трогая бизнес-код.
  4. Добавить post-processing: нормализация дат, ИНН, единиц измерения — одинаковый для всех провайдеров.
  5. Включить canary: 5–10% трафика на secondary в staging, затем в prod под флагом.

Для эмбеддингов (если есть RAG) отдельный индекс на каждую модель эмбеддингов: смешивать векторы разных вендоров в одном пространстве нельзя. При смене embed-модели — полная переиндексация и сравнение recall на контрольных запросах.

Стоимость и лимиты: что смотреть в таблице

| Параметр | Зачем смотреть | Типичное решение | |----------|----------------|------------------| | Цена за 1M input/output | Unit-экономика | Дешёвая модель на классификацию, дорогая на сложный draft | | Rate limit RPM/TPM | Пики очереди | Очередь + backoff + secondary | | Max context | Длинные документы URAP | Chunking / map-reduce, не «запихнуть всё» | | Retention / обучение на данных | Комплаенс | Корп. тариф или on-prem | | SLA и статус-страница | Доступность | Health-check в оркестраторе |

Content Factory на длинных статьях часто выигрывает от связки «дешёвый outline + дорогой polish», а не от одной самой дорогой модели на весь пайплайн. URAP на коротких полях — наоборот, стабильная mid-tier модель с жёсткой схемой дешевле каскада из трёх вызовов.

Self-hosted инференс: когда железо окупается

Студия держит возможность поднять open-weight модели на своём GPU-контуре для пилотов и для заказчиков с air-gapped требованиями. Окупаемость появляется, когда:

  • стабильный поток запросов (не «три чата в неделю»);
  • данные нельзя отдавать наружу;
  • нужна фиксированная версия весов на годы сопровождения (типично для НИИ).

Минусы честно закладываем в оценку: MLOps (обновление драйверов, мониторинг VRAM, очереди), отставание качества от топ-облака, отдельный контур безопасности хоста. Для Galvatec/Typhoon локальная модель всё равно не управляет контроллером — только помогает инженеру off-path.

Связка с инфраструктурой студии: образы собираем через GitLab CI, секреты провайдеров — в protected variables, деплой адаптеров на те же self-hosted runners, что и остальные сервисы. Это согласуется с подходом к Dockerfile и пайплайнам GitLab: AI-слой не живёт «на ноутбуке тимлида».

Связь с разработкой продукта, а не только с чатом

Мультипровайдерность нужна и тогда, когда LLM — часть разработки с AI внутри продукта: RAG, классификация, черновики. Если пилот сделан «в лоб» на одном SDK, через полгода смена провайдера превращается в проект на спринт. Дешевле заложить интерфейс на первой неделе.

Для команды разработки (IDE, Cursor) тоже имеет смысл не привязывать всех к одному облаку: часть инженеров работает через корпоративный endpoint, часть — через российского провайдера при ограничениях сети. Политика данных одна: никаких секретов и prod-дампов, независимо от того, Gemini это или GigaChat.

Анти-паттерны привязки к провайдеру

  1. Промпты с синтаксисом одного вендора в бизнес-коде (system/tool вызовы без обёртки).
  2. Жёстко прошитая model id в десяти сервисах без feature flag.
  3. Нет бюджета на secondary — экономия до первого geo-block.
  4. Оценка только на демо-промпте CEO, без golden-набора домена.
  5. Клиентский SDK с API-ключом в Flutter/JS — ключ утечёт, ротация болезненна.
  6. Общий индекс эмбеддингов после смены модели без переиндексации.
  7. Один счетчик биллинга на все продукты — невозможно понять, кто съел квоту.

Чеклист перехода на мультипровайдерность

  1. Вынести вызовы LLM за интерфейс провайдера.
  2. Описать политики маршрутизации (primary/secondary/local) в конфиге.
  3. Собрать golden-набор и гонять в CI.
  4. Логировать provider + model version на каждый ответ.
  5. Отдельно калибровать temperature и схемы под каждого вендора.
  6. Для критичных заказчиков заранее согласовать on-prem вариант.
  7. Не строить единственный путь релиза на недоступном из РФ Gemini без запасного канала.
  8. Разделить биллинг и квоты по продуктам (Content Factory ≠ URAP ≠ внутренние тулы).
  9. Документировать runbook: что делает дежурный при 24 часах недоступности primary.

Итог

Выбор между Gemini, YandexGPT и GigaChat — это выбор маршрута под доступность, комплаенс и качество на ваших данных, а не под хайп бенчмарка. OtherCode держит адаптеры провайдеров, golden-наборы и запасные маршруты в Content Factory, URAP и внутренних инструментах; для НИИ и промышленного контура оставляем путь к локальным моделям, не отдавая LLM управление оборудованием. Diom и Next.js-клиенты ходят в модели только через backend с ключами на сервере.

Если проектируете AI-фичу и не хотите заложить vendor lock на год вперёд, напишите нам — поможем с архитектурой адаптеров и политикой маршрутизации под ваш контур.