Локальная модель, подписка или BYOK: выбираем маршрут задачи, а не логотип

Вопрос «какая модель лучшая» почти всегда задан слишком широко. Модель, которая хорошо пишет длинный аналитический текст, может быть избыточна для классификации. Локальный вариант может устраивать по приватности, но не помещаться в задержку. Подписочный транспорт удобен, пока лимиты совпадают с нагрузкой. BYOK даёт контроль аккаунта, но переносит на вас договор и счёт за токены.

AiHummer не требует обязательной платной модели. Документация описывает свободные и локальные модели, транспорт через подписку Codex/ChatGPT и собственные ключи провайдеров. Модель можно закрепить за агентом, а маршрутизация по тиру simple, standard или complex решает отдельную задачу — выбор класса на конкретный ход.

Опишите классы задач

Разделите реальные запросы минимум на четыре группы: классификация и извлечение полей; короткие ответы по источнику; сложное рассуждение с инструментами; длинный анализ или генерация документа. Добавьте особые классы: чувствительные данные, голос, изображения и код.

Для каждого класса задайте минимально приемлемое качество, максимальную задержку, допустимую стоимость и разрешённый контур. Тогда сравнение становится измеримым. Одна модель может победить в двух классах и проиграть в остальных — это нормальный результат.

Локальная модель

Главное преимущество — возможность держать обработку внутри контролируемой инфраструктуры. Это важно для сценариев, где внешний маршрут запрещён политикой. Также нет прямого счёта за каждый токен внешнему API.

Цена проявляется в другом месте: CPU или GPU, память, диск, очередь, обновления и наблюдаемость. Небольшая локальная модель может быстро решать классификацию, но ошибаться на сложных инструкциях. Крупная потребует ресурсов и может увеличить время ответа. Проверьте совместимость с вызовами инструментов, структурированным выводом и длиной контекста.

Транспорт через подписку

Подписка удобна, когда у команды уже есть поддерживаемый аккаунт и транспорт снижает порог входа. Но не воспринимайте её как безлимитный API. Условия, лимиты, доступность и политика провайдера могут меняться. Проверьте разрешённый сценарий использования и поведение при исчерпании лимита.

Отдельно измерьте параллельность. Подписка, достаточная для ручного чата, может не выдержать поток автоматических задач. Нужны backoff, понятная ошибка и fallback, который не нарушает политику данных.

BYOK

Собственный API-ключ даёт прямой выбор провайдера, модели и договорных условий. Биллинг токенов становится прозрачным, но его нужно контролировать: бюджеты, лимиты, алерты и ротация ключей. Секрет хранится в vault, а не в профиле агента или промпте.

Проверьте регион обработки, retention, использование данных для обучения, журналирование и порядок удаления. Ключ должен иметь минимальные права и отдельный проект, если провайдер это поддерживает. Не используйте личный ключ разработчика как постоянную производственную учётную запись.

Качество измеряется на ваших данных

Соберите от тридцати до пятидесяти обезличенных или синтетически воспроизведённых запросов, сохраняющих сложность процесса. Для каждого определите эталонные факты, допустимый формат и критические ошибки. Оценка «ответ понравился» слишком субъективна.

Измеряйте точность фактов и ссылок, соблюдение запретов, корректность вызовов инструментов, структурированный JSON, задержку и стоимость. Повторите тест несколько раз: модели недетерминированы, а один удачный прогон ничего не доказывает.

Маршрутизация и модель агента

Собственная модель агента задаёт его базовый выбор. Роутинг по сложности может выбрать другой класс для конкретного хода. Не смешивайте эти механизмы в документации команды. Запишите, что произойдёт, если preferred-модель недоступна.

Fallback должен быть явным. Для чувствительного класса безопасный результат может быть «остановиться», а не отправить запрос внешнему провайдеру. Для типового публичного вопроса допустим переход на другую модель. Решение следует из класса данных и роли.

Стоимость

Для локальной модели считайте инфраструктуру, электричество, амортизацию и время эксплуатации. Для подписки — план, лимиты и число аккаунтов. Для BYOK — входные и выходные токены, кэш, изображения, речь и сетевой трафик. Во всех режимах добавьте ручную обработку ошибок.

Сравнивайте стоимость успешной задачи, а не миллиона токенов. Дешёвый ответ, который человек переписывает, обходится дороже. Дорогая модель на тривиальной классификации тоже тратит бюджет без пользы.

Данные и безопасность

Нарисуйте поток контекста к каждому маршруту. Укажите, какие части диалога, знания и результаты инструментов передаются. Локальный endpoint нужно защищать так же внимательно: аутентификация, сеть, журналирование и доступ к весам не появляются автоматически.

Air-gapped-режим может блокировать публичный egress, но одновременно отключает интернет-зависимые инструменты. Проверяйте весь сценарий, а не только вызов модели.

План пилота

Неделя 1: классы задач, тестовый набор и политика данных. Неделя 2: один локальный и один внешний маршрут, одинаковые метрики. Неделя 3: инструменты, длинный контекст, отказ и лимиты. Неделя 4: выбор дефолта, fallback, бюджеты и runbook.

Перед production повторите тест на текущих версиях. Модели и условия быстро меняются; результат прошлого квартала может устареть.

Чек-лист выбора

• Определены классы задач.
• Заданы качество, задержка и бюджет.
• Нарисованы потоки данных.
• Проверены инструменты и структурированный вывод.
• Измерены длинный контекст и параллельность.
• Условия подписки и BYOK прочитаны.
• Ключи лежат в vault и ротируются.
• Локальные ресурсы наблюдаются.
• Fallback не нарушает политику.
• Есть тесты отказа и исчерпания лимита.
• Решение пересматривается после изменений.

Относитесь к смене модели как к изменению системы

Новая версия провайдера может изменить формат инструментальных вызовов, длину ответа, задержку и склонность к отказам. Поэтому переключение не должно происходить только по названию в настройке. Зафиксируйте текущий baseline, прогоните регрессионный набор, сравните критические ошибки и подготовьте обратный путь.

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

Источники и ограничения

См. введение, «Агенты и персоны», «Роутинг», страницу моделей Web UI и тарифы. Поддерживаемые провайдеры, условия подписки и тарифные ограничения нужно сверять перед запуском.

Начните с одного маршрута и измеримого набора задач. Возможность подключить много моделей ценна только тогда, когда команда понимает, почему конкретный запрос идёт именно туда.