--- title: Обновляйте ИИ-модели в приложении без повторного развертывания description: >- Всё время выходят новые ИИ-модели — лучше и дешевле предыдущих. Используйте Haimaker, чтобы обновлять модели в развёрнутом приложении без выпуска нового мобильного релиза или изменения серверной конфигурации. date: 2026-09-16T00:00:00.000Z location: 'Сан-Франциско, Калифорния – 16 сентября 2026 г.' image: /images/change-ai-models-without-redeploying-hero.jpg keywords: >- смена ИИ-моделей без повторного развертывания, динамическая маршрутизация ИИ-моделей, ИИ-модель в мобильном приложении, обновление ИИ-моделей faq: - question: Как сменить ИИ-модель в опубликованном мобильном приложении? answer: >- Настройте приложение так, чтобы оно обращалось к вашему бэкенду, а бэкенд передавал model: 'haimaker/auto' в Haimaker. После этого вы сможете менять модель по умолчанию или правила маршрутизации промптов в дашборде без отправки новой мобильной сборки. Изменения роутера вступают в силу в течение 60 секунд. - question: Требует ли переключение моделей через Haimaker серверного развертывания? answer: >- Нет. Если развёрнутый сервер уже отправляет model: 'haimaker/auto' с API-ключом, привязанным к роутеру, вы можете менять целевые модели роутера в дашборде. Изменения промптов приложения, форматов запросов или кода по-прежнему требуют обычного развертывания. - question: Можно ли направить только простые промпты на более дешёвую модель? answer: >- Да. Добавьте правило с 3–10 примерами промптов для простой задачи и выберите более дешёвую целевую модель. Haimaker проверяет, что целевая модель поддерживает запрос, а промпты, не соответствующие ни одному правилу, обрабатываются моделью по умолчанию. locale: ru-ru translationKey: change-ai-models-without-redeploying --- Всё время выходят новые ИИ-модели — лучше и дешевле предыдущих. Модель, которая подходила на момент выпуска приложения, уже через несколько недель может перестать быть лучшим выбором. Но если идентификатор модели зашит в опубликованное iOS-приложение или в развёрнутый сервер, каждое обновление превращается в очередной релиз. Как поддерживать приложение в актуальном состоянии, пока пользователи работают со старыми сборками? **Haimaker позволяет обновлять модели, которые использует ваше приложение, без повторного развертывания.** Отправляйте `haimaker/auto` в качестве идентификатора модели, а затем меняйте модель по умолчанию или правила для конкретных промптов в дашборде. Эта проблема повторяется с каждым выходом новой модели. Разработчикам нужно проверять качество, стоимость и возможности моделей на своих рабочих нагрузках. Если вынести выбор модели из развёрнутого кода, можно реагировать на результаты тестов без нового релиза приложения или сервера. ## Фиксированный идентификатор модели устаревает после релиза При фиксированном идентификаторе модели каждое обновление модели зависит от процесса релиза приложения. На этапе создания первой версии это ещё терпимо. После запуска каждая перспективная модель или изменение цены может означать правку кода, прогон тестов, развертывание серверов или отправку мобильного обновления. Новые модели могут появляться между релизами приложения. Для iOS-приложения идентификатор модели, встроенный в клиент, не может измениться для пользователей, которые не установили обновление. [Apple проверяет обновления приложений перед распространением](https://developer.apple.com/app-store/review/), и пользователи могут долго оставаться на старых версиях после выхода новой сборки. Перенос API-вызова на бэкенд позволяет не хранить ключ провайдера в приложении, но идентификатор модели, захардкоженный на бэкенде, всё равно требует изменения конфигурации или развертывания. Один только шлюз проблему не решает. Если запрос указывает фиксированную модель, вызывающий код остаётся привязан к этому выбору. OpenRouter, например, поддерживает именованные модели, а также собственный [роутер `openrouter/auto`](https://openrouter.ai/docs/guides/routing/routers/auto-router). Автоматический роутер позволяет вынести выбор модели из развёрнутого кода. Haimaker даёт возможность настраивать политику маршрутизации для ваших классов промптов уже после выпуска приложения. ## Как развёрнутое приложение может успевать за новыми моделями? Отправляйте один стабильный идентификатор модели из приложения и храните политику выбора в Haimaker. У роутера есть модель по умолчанию для запросов без совпадений и правила, которые направляют определённые виды промптов на другие модели. Роутер привязан к API-ключу. Когда вы меняете его целевые модели, последующие запросы могут попадать на разные модели, хотя код на стороне приложения продолжает отправлять `haimaker/auto`. В мобильном продукте приложение должно обращаться к вашему бэкенду, а бэкенд — к Haimaker. Так API-ключ не попадает на устройства пользователей. Серверное приложение может использовать тот же паттерн напрямую: код запросов остаётся на месте, а оператор настраивает роутер. В [документации по настройке](https://docs.haimaker.ai/docs/auto_router) показано, как создать роутер, выбрать модель по умолчанию, привязать API-ключ и протестировать запросы. ```js import OpenAI from "openai"; // Run this on your backend; do not bundle the API key in a mobile app. const client = new OpenAI({ baseURL: "https://api.haimaker.ai/v1", apiKey: process.env.HAIMAKER_API_KEY, }); const response = await client.chat.completions.create({ model: "haimaker/auto", messages: [{ role: "user", content: prompt }], }); ``` Приведённый выше код не требует нового имени модели при смене модели по умолчанию. Haimaker кэширует конфигурации роутера [на срок до 60 секунд](https://docs.haimaker.ai/docs/auto_router), поэтому подождите около минуты, пока изменение в дашборде применится ко всем последующим запросам. ## Обновите модель по умолчанию, затем маршрутизируйте дешёвые задачи отдельно Смена модели по умолчанию обновляет модель для основной массы запросов. Правила позволяют вносить точечные изменения, когда новая модель дешевле или лучше справляется с конкретной задачей. Это различие важно: приложению может быть нужна мощная модель по умолчанию для редактирования длинных текстов, при этом генерацию коротких заголовков можно отправлять на более дешёвую модель. Оба решения можно изменить после релиза, не меняя идентификатор модели в вызывающем коде. Представьте приложение для написания текстов, бэкенд которого отправляет каждый ИИ-запрос через один и тот же роутер. Выходит новая модель, которая лучше справляется с редактированием длинных текстов, — команда тестирует её и меняет модель по умолчанию в роутере. Позже более дешёвая модель оказывается достаточно хорошей для генерации заголовков. Команда добавляет правило с примерами вроде «Предложи пять коротких заголовков для этой заметки» и «Дай этому черновику лаконичный заголовок», затем направляет это правило на более дешёвую модель. Пользователи со старыми версиями приложения получают оба изменения через существующий бэкенд. Для [правил на основе примеров](https://docs.haimaker.ai/docs/auto_router) используйте от 3 до 10 репрезентативных промптов на задачу. При совпадении запрос направляется на целевую модель правила; запросы без совпадения используют модель по умолчанию. Проверки возможностей предотвращают отправку запросов с изображениями, вызовами инструментов или структурированным выводом на модель, которая не может их обработать. В [логах маршрутизации](https://docs.haimaker.ai/docs/auto_router) отображается выбранная модель и правило, которое её определило. О механике сопоставления и фолбэка читайте в нашем [руководстве по маршрутизации](/blog/auto-router-v2-smart-routing/) и [руководстве по маршрутизации по стоимости](/blog/cost-optimization-routing-ai-requests/). ## Что это меняет для команды после запуска? Главное преимущество в том, что выбор модели может определяться нагрузкой, а не календарём релизов. Команда может перейти на новую модель по умолчанию, перенести повторяющийся класс промптов на более дешёвую модель или вернуть прежнюю целевую модель, если результаты ухудшились. Серверный код и установленные мобильные клиенты продолжают отправлять тот же API-запрос. Работа смещается к тестированию и оценке решений маршрутизации. | Изменение после запуска | С фиксированной моделью в коде | С haimaker/auto | | --- | --- | --- | | Появилась лучшая универсальная модель | Изменить идентификатор модели и выпустить код или конфигурацию | Протестировать, затем сменить модель по умолчанию в роутере | | Более дешёвая модель подходит для одного класса промптов | Добавить логику маршрутизации в приложение и развернуть | Добавить или отредактировать правило для этого класса промптов | | Смена модели ухудшила качество вывода | Откатить изменение кода или конфигурации | Вернуть прежнюю целевую модель роутера | | Пользователи всё ещё на старой мобильной сборке | Встроенный идентификатор модели остаётся прежним | Бэкенд может использовать актуальную политику роутера | Это также помогает, когда в очереди на серверный релиз уже есть несвязанные задачи. Решение о выборе модели не должно ждать этого окна развертывания. Раздельные нагрузки могут использовать разные роутеры через привязку к разным API-ключам; Haimaker поддерживает [один роутер на ключ](https://docs.haimaker.ai/docs/auto_router). Изменения маршрутизации по-прежнему требуют той же осмотрительности, что и изменения кода. Песочница в дашборде показывает, какую модель выберет роутер для промпта, но не доказывает, что ответ будет хорошим. Прогоните репрезентативные промпты на предлагаемой модели, проверьте реальный вывод, следите за логами выбранных моделей и вернитесь к предыдущей целевой модели, если качество упадёт. Haimaker меняет выбор модели; изменение промптов, схем инструментов или поведения приложения по-прежнему требует работы на стороне приложения. ## Подготовьте выбор модели к следующему релизу Создайте роутер, выберите модель по умолчанию и привяжите роутер к API-ключу, который использует ваш бэкенд. Отправляйте `haimaker/auto` в запросе, затем протестируйте несколько промптов, характерных для вашей нагрузки. Когда появится новая модель, оцените её на этих промптах, прежде чем менять модель по умолчанию или точечное правило. [Документация Haimaker](https://docs.haimaker.ai/docs/auto_router) охватывает настройку роутера, тестовую песочницу и историю маршрутизации. Новые модели могут появиться раньше вашего следующего релиза приложения. Хранение выбора модели в Haimaker позволяет приложению оставаться актуальным, а разработчики расходуют релизные циклы на изменения, требующие нового кода. ## Часто задаваемые вопросы #### Как сменить ИИ-модель в опубликованном мобильном приложении? Настройте приложение так, чтобы оно обращалось к вашему бэкенду, а бэкенд передавал model: 'haimaker/auto' в Haimaker. После этого вы сможете менять модель по умолчанию или правила маршрутизации промптов в дашборде без отправки новой мобильной сборки. Изменения роутера вступают в силу в течение 60 секунд. #### Требует ли переключение моделей через Haimaker серверного развертывания? Нет. Если развёрнутый сервер уже отправляет model: 'haimaker/auto' с API-ключом, привязанным к роутеру, вы можете менять целевые модели роутера в дашборде. Изменения промптов приложения, форматов запросов или кода по-прежнему требуют обычного развертывания. #### Можно ли направить только простые промпты на более дешёвую модель? Да. Добавьте правило с 3–10 примерами промптов для простой задачи и выберите более дешёвую целевую модель. Haimaker проверяет, что целевая модель поддерживает запрос, а промпты, не соответствующие ни одному правилу, обрабатываются моделью по умолчанию. НАСТРОИТЬ HAIMAKER