Апрельский квартал, в котором провайдеры стали заменимы

8 апреля 2026 года Anthropic выпустил Managed Agents — managed execution loop, persistent memory через /memories, sandboxing и multi-agent orchestration. В тот же месяц OpenAI отгрузил AgentKit с визуальным Agent Builder, Connector Registry и встроенными Evals. Сбер на портале GigaChat API держит публичную тарификацию по пакетам токенов и три варианта развёртывания — облако, гибрид, on-prem. Yandex Cloud в Foundation Models собрал YandexGPT в одну линейку с Object Storage, Logging и managed-инфраструктурой.

Между этими четырьмя анонсами есть общая черта, которую обзоры обычно проходят мимо. Все четыре провайдера в 2026-м продают не модель, а стек: контракт API, managed orchestration, memory, observability. И как только стек становится частью продукта, цена ошибки выбора смещается с цены токена на стоимость переезда между стеками. Ровно поэтому сравнительные таблицы «GigaChat vs YandexGPT vs Claude» в 2026-м измеряют не то, что определяет экономику решения через год.

Дешевизна моноархитектуры — в долг

Базовый сценарий 2026-го у российской B2B-команды выглядит так. Команда выбирает одного провайдера — обычно по сочетанию цены, 152-ФЗ и удобства существующей инфраструктуры — и собирает на нём всё: парсинг входящих, классификацию, агентов с инструментами, summarisation. Это моноархитектура. Она экономит инженерные часы на старте: одна авторизация, один SDK, один формат tool calling, одна managed-память.

Контр-тезис: моноархитектура не дешевле — она дешевле в первый год. На втором году стоимость моноархитектуры — это стоимость миграции, и она конечна, измерима и обычно недооценена. Migration debt появляется не от плохого выбора, а от того, что любая моноархитектура жёстко связывает четыре независимых решения: формат структурированного вывода, протокол tool use, схему памяти и operations-контур. Когда хотя бы одно из четырёх перестаёт устраивать, переезжать приходится сразу всем стеком.

Альтернатива — роутер: внешний слой, который маршрутизирует запросы между провайдерами по типу нагрузки, чувствительности данных и стоимости. Роутер дороже в первый год — нужен evaluator-харнесс, единая schema domain-объектов, контракты между prompt-цепочкой и моделью. Но он линейно масштабирует решения второго года: смена одного провайдера меняет конфиг, а не архитектуру. В терминах предыдущей заметки про harness commodity, роутер — это та часть operating layer, которую provider-стеки в 2026-м начали поглощать, и которую командам выгодно не отдавать вверх по стеку без явного обмена.

Четыре стыка, на которых ломается моноархитектура

Чтобы увидеть, где конкретно моноархитектура накапливает долг, удобно смотреть не на «провайдеров вообще», а на стыки между подсистемами стека.

Structured output: формат входит в каждый prompt

OpenAI в Function Calling с 2023-го фиксирует контракт, при котором модель возвращает строго типизированный JSON по объявленной схеме. Anthropic в tool use реализует тот же контракт через tool_choice и явные input schemas. Это два формата, которые внешне делают одно и то же, но различаются в деталях: имена полей, форма передачи schema, поведение при несоответствии. На стороне Сбера механизм function calling в портале GigaChat API и сопровождающих технических разборах SberDevices на Хабре представлен своим интерфейсом; у Yandex — своим.

Команда, которая выбрала одного провайдера, кодирует именно его формат в каждый prompt и каждый валидатор. Через год, когда возникает сценарий с другим провайдером — например, reasoning-задача, где Claude даёт лучший результат на тех же примерах — миграция перетряхивает все места, где формат tool calling зашит. Это не «переписать промпты», это переписать тесты, евалуаторы, ретраи и логирование.

Команда с роутером изначально держит структурированный вывод как domain-объект, а формат провайдера — как адаптер; миграция меняет адаптер. Конкретно это значит, что в репозитории есть два уровня: типизированные классы доменных объектов (карточка клиента, событие, эскалация, статус) — независимые от провайдера, и тонкий слой провайдер-специфичного кода, который только переводит между этими классами и форматом конкретного API. На длинных горизонтах поддержка двух адаптеров обходится дешевле одного жёстко прошитого формата, потому что оба адаптера обязаны проходить один и тот же evaluator-харнесс.

Tool use: orchestration провайдера против внешнего роутера

Anthropic в инженерной заметке про Managed Agents формулирует суть managed-подхода: «self-evaluates and iterates until it reaches a result» — это описание execution loop, в котором провайдер берёт на себя оркестрацию и возвращает вызывающему коду только финальный результат. OpenAI в AgentKit даёт визуальный Agent Builder с Connector Registry и встроенными Evals. Это два разных способа упаковать одну и ту же задачу: длинная цепочка вызовов инструментов с возвратом контроля внешнему коду. Российские провайдеры в публичных материалах 2026-го тоже движутся в эту сторону, но с разной плотностью документации и разной зрелостью контракта на длинных горизонтах.

Команда, которая поверила, что «agent harness — это просто фича провайдера», и спроектировала flow внутри managed-конструкции, на втором году получает классическую vendor lock-in проблему. Смена провайдера здесь — это не «переключить ключ», это переписать саму форму orchestration: где живёт состояние, как оформлены retry, кто owns memory между шагами, как описан контракт инструмента. У каждого провайдера эти ответы разные, и в managed-продукте они зашиты в SDK, а не в коде команды.

Команда с внешним роутером — наоборот, держит orchestration снаружи, а провайдерский harness использует только там, где экономия на инфраструктуре оправдывает связанность. На практике это означает, что роутер берёт на себя три роли: классификатор запроса по типу нагрузки и чувствительности данных, владелец схемы domain-объектов и evaluator. Managed harness провайдера в такой архитектуре — один из исполнителей, не источник правды.

152-ФЗ как архитектурный, а не комплаенс-вопрос

Большинство обзоров обсуждают 152-ФЗ как фильтр между двумя множествами провайдеров: «российские можно, зарубежные нельзя для ПД». Это правда, но это не самый интересный уровень. Архитектурный уровень — что именно в стеке считается «обработкой ПД», и где проходит граница изоляции.

Документация GigaChat API предлагает три варианта развёртывания: облако Сбера, гибрид с данными на стороне клиента, on-prem. Yandex Cloud Foundation Models даёт data residency «в РФ» как умолчание. Команда, которая делает 152-ФЗ-чувствительный продукт на моноархитектуре одного из этих провайдеров, имплицитно принимает решение: весь продукт работает в одном комплаенс-периметре. На горизонте года это означает, что если в продукт добавляется задача, требующая reasoning-возможностей зарубежной модели — а такие задачи в 2026-м появляются регулярно — переезд требует разделить пайплайн на ПД-чувствительный и обезличенный, что архитектурно эквивалентно построению роутера задним числом, только в стрессе и под deadline.

Команда, которая с самого начала проектировала разделение по чувствительности данных как отдельную ось маршрутизации, ту же задачу решает добавлением ветки. 152-ФЗ перестаёт быть constraint на выбор провайдера и становится одним из measurable атрибутов запроса.

SLA и поведение под нагрузкой

У Anthropic и OpenAI публичные status-страницы и rate-limit-политики, описанные на уровне tier’ов. У GigaChat и Yandex Cloud публичная часть SLA на инференс LLM в 2026-м заметно беднее — корпоративные условия идут в индивидуальных договорах. Это не утверждение про качество, это утверждение про объём публичной информации, на которую может опираться внешний выбор.

Моноархитектура на любом из четырёх провайдеров делает SLA провайдера потолком SLA продукта. Если у провайдера падает регион или меняется rate-limit-политика, продукт деградирует синхронно, без степеней свободы. Роутер — наоборот, делает SLA продукта функцией политики маршрутизации: при деградации одного провайдера запросы уходят на резерв, latency p95 поднимается, но контур не останавливается. Цена этой устойчивости — поддерживать как минимум двух работающих провайдеров и единый evaluator-харнесс, на котором обе стороны проверяются на одинаковом наборе кейсов. Дешёвой эта устойчивость не бывает; вопрос в том, что обходится дороже — её отсутствие или её содержание.

На фоне этого Сбер в карточке GigaChat API пишет о ·«едином API для приложений и агентов», это сигнал: российские провайдеры движутся в ту же сторону. Как отмечают в блоге SberDevices, «функциональный вызов и инструменты — это не фича, а основной режим работы модели в production-контуре» — формулировка, которая почти дословно повторяет Anthropic и OpenAI. Одна и та же идея, реализованная четырьмя разными способами, и каждый из этих способов — будущая точка миграции.

Конкретные тесты для трёх ролей

Для CTO. Возьмите три задачи из текущего бэклога: одну со structured output, одну с tool use на 5+ шагов, одну с длинным контекстом. Зафиксируйте, в скольких местах кода и в скольких тестах прописан конкретный формат текущего провайдера — имена полей tool calling, формат сообщений, идентификаторы моделей. Если число таких мест превышает несколько десятков на одну задачу, у вас моноархитектура, и стоимость её замены через год — это столько же изменений, помноженное на число задач. Решение — не «срочно мигрировать», а вынести формат провайдера в адаптер и держать domain-объекты типизированными.

Для Head of Product. Запишите, какие фичи продукта зависят от поведенческих гарантий конкретного провайдера: структуры JSON, длины контекста, поведения tool calling на длинных горизонтах. Если таких фич больше трёх и все они сидят на одном провайдере, продукт зависит от его roadmap’а сильнее, чем от собственного. Тестовый сценарий: если завтра ваш текущий провайдер поднимет цену на 30% или удалит конкретную фичу — какие функции продукта перестают работать в течение недели. Это и есть продуктовая стоимость моноархитектуры, выраженная в feature-availability.

Для Tech Lead. Постройте один проект так, чтобы провайдер был заменим: единая schema domain-объектов, адаптеры под форматы провайдеров, evaluator-харнесс на 200–500 типичных кейсов с эталонными ответами. Это инвестиция в недели, а не в дни. Признак, что харнесс реальный, а не на бумаге: вы можете прогнать новую модель на нём за ночь и получить численный ответ — лучше, хуже, на каких подмножествах. Без такого харнесса любая дискуссия о смене провайдера ведётся в терминах ощущений, что само по себе — диагностика степени lock-in.

Что покажет 2026-й, и какие сигналы стоит фиксировать?

Тренд имеет несколько проверяемых сигналов. Первый — появление managed-роутеров в публичных продуктах: внешних сервисов, которые принимают единый API и сами решают, какому провайдеру отправить запрос. Если такие продукты выходят в GA, моноархитектура становится анахронизмом, а вопрос смещается на политику маршрутизации. Второй — публикация официальных кейсов перевода production-нагрузок между российскими и зарубежными провайдерами без потери качества. Такой кейс — публичное доказательство, что архитектурно стек уже переносим, и оценочная стоимость миграции из моноархитектуры в роутер становится прозрачной величиной. Третий, обратный, — появление команд, которые публично возвращаются с роутера на моноархитектуру, объясняя это операционной сложностью. Это будет означать, что граница применимости роутера выше, чем сейчас принято считать, и что для значительной части B2B-задач достаточно одного провайдера и грамотных адаптеров.

В любом сценарии вопрос «GigaChat или Claude» — не главный. Он выглядит как закупочный, но за ним стоит архитектурный, и именно архитектурный определяет, сколько будет стоить второй год.

Главное

  • Сравнения LLM-провайдеров по цене и фичам в 2026-м воспроизводят ошибку обзоров BPM десять лет назад: они отвечают на закупочный вопрос вместо архитектурного.
  • Реальная развилка — моноархитектура или роутер. Моноархитектура дешевле в первый год и дороже на втором за счёт стоимости миграции; роутер — наоборот.
  • Стоимость моноархитектуры скрыта в четырёх стыках: формат structured output, протокол tool use на длинных цепочках, граница 152-ФЗ-изоляции, поведение под нагрузкой.
  • Минимальная архитектура, которая делает провайдера заменимым: единая schema domain-объектов, адаптеры под форматы провайдеров, evaluator-харнесс на 200–500 кейсов.
  • Сигналы 2026-го, на которые стоит смотреть: managed-роутеры в GA, публичные кейсы переноса production-нагрузок, обратные кейсы возврата на моноархитектуру.

FAQ

Чем моноархитектура отличается от vendor lock-in?

Моноархитектура — это осознанный выбор одного провайдера ради скорости в первый год; vendor lock-in — следствие того, что при этом выборе команда не выделила domain-слой, и формат провайдера разлился по всему коду. Можно иметь моноархитектуру без lock-in, если domain-объекты типизированы и evaluator-харнесс реальный — это и есть разница между рабочей сборкой и долгом. Тест: сколько мест в коде нужно изменить, чтобы поменять провайдера? <100 — нормальная моноархитектура. >1000 — lock-in.

Когда роутер — переинжиниринг?

Роутер переинжиниринг, когда в продукте меньше трёх разных типов запросов, нет 152-ФЗ-чувствительных данных и объём инференса ниже ~10 000 запросов в день. Для таких команд правильный путь — один провайдер плюс правильные адаптеры. Роутер окупается от двух и более дифференцирующих факторов: хотя бы две роли LLM в продукте, две зоны чувствительности данных, или два критерия SLA.

Как оценить стоимость миграции с моноархитектуры?

Подсчитайте три числа: (1) сколько prompt-шаблонов содержат провайдер-специфичный формат, (2) сколько тестов предполагают конкретные имена полей tool calling, (3) сколько мест в коде ссылаются на идентификаторы моделей напрямую. Сумма этих трёх чисел, умноженная на ~2 часа на каждое место (типичная оценка для рефакторинга с проверкой тестами), даёт оценку миграционного долга в инженер-часах. Часто получается 500–1500 часов на средний продукт — то есть 3–9 человеко-месяцев.

Что выбрать команде, которая стартует сегодня — моно или роутер?

Стартовать с моноархитектуры на одном из российских провайдеров (152-ФЗ требует РФ-инфраструктуры в большинстве B2B-сценариев), но сразу заложить три инвестиции: типизированные domain-классы (карточка клиента, событие, эскалация), адаптер-слой между ними и API провайдера, evaluator-харнесс на 50–100 кейсов. Это превращает будущий переход в роутер в добавление второго адаптера, а не пересборку. Стоимость этих трёх инвестиций при старте — 2–4 недели, экономия на горизонте 12 месяцев — порядок тех же 500–1500 часов.

Какие задачи в B2B РФ-стеке оправданно отдавать зарубежным моделям через роутер?

Reasoning-задачи на длинных горизонтах (планирование, decomposition сложных кейсов, анализ длинных документов) — у Claude и GPT-5.5 в 2026-м преимущество подтверждается на публичных бенчмарках. Чувствительность данных снижается обезличиванием на стороне роутера: запрос уходит в зарубежную модель без ПД, ответ применяется в РФ-контуре с ПД. Для классификации входящих, summarisation отчётов, генерации шаблонных писем — российские провайдеры в 2026-м конкурентоспособны и выгоднее по стоимости и латентности.