Проверьте своё положение одним вопросом: сколько времени займёт перевод вашего ассистента на другого провайдера прямо сейчас? Если ответ «минуту» — дальше можно не читать. Если «надо посмотреть код» — вы в зависимости, о которой не договаривались, и обнаружится она в худший момент: при блокировке аккаунта, при пересмотре цен или при отказе сервиса.
Провайдер модели — это поставщик, а не часть архитектуры. Различие практическое: поставщика меняют по цене и по надёжности, а часть архитектуры меняют релизом. Ниже — как перевести провайдера из второй категории в первую.
#Что должно быть настройкой, а не кодом
Минимальный набор, при котором переезд становится рутиной:
- адрес эндпоинта — потому что сервисы переезжают с домена на домен;
- имя модели — потому что версии снимают и переименовывают;
- ключ — потому что его ротируют;
- выбранный провайдер — потому что их должно быть больше одного;
- лимиты: длина ответа, размер подмешиваемого контекста, число шагов агента.
Если хоть один пункт зашит в код, у вас не настройка, а релиз. Отдельно про адрес: его переопределяемость — не паранойя. У половины сервисов есть по два живых хоста (международный и региональный), и зашитая константа превращает переезд сервиса в баг, который чинится только выпуском новой версии.
#Как выглядит слой абстракции
Идея в одном: приложение знает один внутренний вызов, а разницу между сервисами держит отдельный слой.
приложение
│ один вызов: (сообщения, параметры) → текст ответа
▼
слой провайдера
├── адрес эндпоинта ← настройка
├── имя модели ← настройка
├── ключ ← настройка
└── адаптер формата ← код, по одному на «особенных» вендоров
▼
провайдер A | провайдер B | локальный сервер
Ключевое свойство: адаптеров нужно немного. Большинство сервисов говорят одним и тем же протоколом, поэтому для них хватает одного адаптера и разных настроек — почему так вышло, разобрано в материале про OpenAI-совместимый API. Отдельные адаптеры нужны только тем вендорам, у которых свой формат запроса и ответа.
Второе свойство, менее очевидное: слой должен уметь отвечать «не могу». Приложение, которое падает при недоступности провайдера, не переключаемо — оно просто ломается. Как проектировать деградацию вместо отказа, разобрано в материале про то, как ассистент должен переживать сбой провайдера.
#Чек-лист переноса на другого провайдера
Проходите по порядку, не пропуская пятый пункт.
- Заведите ключ у нового провайдера и проверьте его вне приложения одним запросом.
- Найдите точное имя нужной модели в его документации. Имена не переносятся между сервисами.
- Проверьте адрес эндпоинта — он может отличаться от привычного больше, чем ожидается.
- Сверьте ограничения: длина контекста, максимум ответа, лимиты по частоте. Настройки, работавшие у прежнего провайдера, могут не пройти у нового.
- Прогоните свой набор типовых задач — десяток реальных запросов, а не «привет». Одинаковый протокол не означает одинаковых ответов: у другой модели своя манера, своё качество на русском и своя реакция на длинную инструкцию.
- Сравните формат ответов там, где он вам важен. Если приложение ждёт список или JSON, проверьте именно это: чат совместим почти всегда, структурированный вывод — нет.
- Проверьте расход на новом провайдере после первого дня: соотношение цены на вход и выход у него может быть другим.
- Оставьте старый ключ живым на неделю. Откат должен быть возможен без паники.
- Отзовите старый ключ, когда убедились, что переезд состоялся.
- Запишите, что именно вы поменяли. Через полгода вы будете переезжать снова, и список сэкономит вечер.
#Проверка результата
- Приложение отвечает на новом провайдере.
- В кабинете нового провайдера виден расход по вашему ключу за сегодня.
- Ваши десять типовых задач дают приемлемые ответы — не «другие», а именно приемлемые.
- Обратное переключение на прежнего провайдера выполняется изменением настроек и занимает минуту.
Четвёртый пункт — главный. Переезд, после которого вернуться нельзя, это не переключаемость, а другая зависимость.
#Как это устроено в Persona
Провайдер выбирается на странице /settings/llm радиокнопкой, ключ вставляется в поле рядом. Переключение не удаляет ключи других провайдеров: вы можете держать настроенными несколько и менять активного за пару кликов, не вводя ключи заново.
Для сервисов, которых нет в списке, есть универсальный пункт с тремя полями: адрес, модель, ключ. У готовых пресетов адрес тоже переопределяемый — по той же причине, что описана выше: сервисы переезжают.
Пошаговый разбор экрана, включая случай «ключ вставлен, а чат молчит», — в инструкции про то, как подключить свою модель в Persona.
Ограничение, о котором честно: переключаемость модели не делает переносимой саму переписку. Ответы, сгенерированные разными моделями, остаются в вашей истории такими, какими были, и стиль ассистента после переезда изменится. Это не баг — это следствие того, что модель у вас арендованная, а память своя. Почему архив имеет смысл держать на своей стороне, разобрано в материале про локальную память как принцип.
#Что может пойти не так
- Имя модели скопировано от прежнего провайдера. Ошибка «модель не найдена» на первом же запросе.
- Ключ вставлен в поле другого провайдера. Ошибка авторизации при полностью верном ключе.
- Приложение продолжает использовать старого провайдера. Обычно потому, что настройка сохранена, а процесс не перечитал её; проверяется по расходу в кабинете, а не по интерфейсу.
- Ответы стали хуже, хотя протокол тот же. Это разница моделей, а не поломка переезда. Решается подбором модели, а не настройками клиента.
- Агрегатор выглядит решением всех проблем. Он избавляет от переключения между вендорами, но добавляет зависимость от себя. Что именно вы получаете и чем платите — в гайде по OpenRouter.
#Частые вопросы
#Сколько провайдеров стоит держать настроенными?
Двух достаточно: основной и запасной у другой компании, желательно с другим способом оплаты и другой региональной доступностью. Третий имеет смысл, если у вас разные классы задач — например, дешёвая модель для бытового чата и сильная для сложного.
#Не проще ли взять агрегатор и не думать о переключении?
Агрегатор снимает проблему переключения между моделями и оставляет проблему переключения между поставщиками: если что-то случится с ним самим, вы снова без модели. Разумная схема — агрегатор как основной путь и прямой ключ другого сервиса как запасной.
#Сохраняется ли переписка при смене провайдера?
Если история хранится на вашей стороне — да, она никак не связана с тем, кто генерировал ответы. Если история живёт в кабинете провайдера, при смене вы её теряете. Это один из практических аргументов в пользу приложения, которое держит архив у вас.
#Изменится ли поведение ассистента после переезда?
Почти наверняка: другая модель иначе следует инструкции, иначе пишет по-русски и иначе обходится с длинным контекстом. Поэтому пятый пункт чек-листа — прогон своих типовых задач — не формальность, а единственный способ узнать это до, а не после.
#Что делать, если новый провайдер требует другой формат запроса?
Это тот случай, когда нужен отдельный адаптер в слое провайдера. Их немного: большинство сервисов совместимы между собой, и своим форматом отличаются единицы. Общий обзор провайдеров и их особенностей — в статье о том, где взять ключ к языковой модели.