Переключение между hosted и self-hosted моделью по расписанию

В чем проблема на практике

Днем система живет по одним правилам, ночью - по другим. Если в рабочие часы зависает чат для операторов, поиск по базе знаний или подсказки в CRM, бизнес теряет время сразу. Ночью цена сбоя ниже: пакетная обработка может подождать 10-20 минут, если это не ломает утренний цикл.

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

С данными все еще строже. В банке или телекоме часть запросов содержит PII, внутренние заметки, номера договоров и служебные поля. Такие данные часто разумно держать внутри страны и внутри своего контура. Обезличенные тексты, классификацию обращений или ночные отчеты можно отправлять во внешний LLM API, если там лучше цена или шире выбор моделей.

Поэтому переключение между hosted и self-hosted моделью обычно выглядит не как прихоть архитектора, а как обычная операционная задача. Одна и та же модель редко остается лучшим выбором весь день. Утром нужна стабильность и быстрый ответ. Ночью важнее цена за большой объем. В середине дня может вырасти поток клиентских запросов, и тогда batch лучше временно вынести наружу или поставить на паузу до тихого окна.

Обычно все упирается в три вопроса: какой сценарий нельзя ронять, какие данные нельзя выносить и в какие часы токены обходятся дороже всего. Если не ответить на них заранее, команда либо переплачивает за постоянный внутренний запас GPU, либо тянет чувствительные задачи во внешний контур без понятной причины.

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

Когда внутренний контур оправдан

Внутренний контур нужен не "для солидности", а для вполне понятных задач. Первый частый случай - вы обрабатываете PII, заявки клиентов, медданные, договоры или внутренние документы, которые служба безопасности не хочет выпускать наружу без явной причины. Локальное исполнение снижает риск и упрощает контроль над хранением, маскированием и аудитом.

Второй случай - нужна ровная задержка в рабочие часы. Для чат-ассистента сотрудника, проверки анкет или подсказок оператору разница между ответом за 1,2 секунды и за 4 секунды очень заметна. Внешний LLM API иногда дает хорошие средние цифры, но живой трафик любит неприятные скачки: очередь у провайдера, перегруженный регион, внезапный лимит.

Есть и третий практичный вариант: у вас простаивают GPU в ночное окно. Если железо уже стоит и не занято с 22:00 до 08:00, на нем удобно гонять пакетные задачи - разбор документов, суммаризацию, классификацию обращений, переиндексацию базы знаний. В такой схеме ночная обработка нередко обходится дешевле внешнего API.

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

Для компаний в Казахстане это часто совпадает и с требованиями по размещению данных. Если часть сценариев нужно держать внутри страны, логично оставлять такие запросы на своей инфраструктуре или на локально размещенных open-weight моделях. В этом месте единый шлюз вроде AI Router бывает полезен: он позволяет держать локальные модели и внешних провайдеров под одним API, а для чувствительных сценариев сохранять данные внутри страны и вести аудит.

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

Когда внешний API выгоднее

Внешний API часто дешевле и проще, когда нагрузка живет по часам, а не идет ровной линией весь день. Если утром и вечером у вас всплеск запросов, а днем и ночью тишина, свои GPU будут простаивать заметную часть времени. За это все равно придется платить.

Такой вариант особенно удобен, когда сложные запросы появляются редко, но требуют сильной модели. Например, 90% обращений можно закрыть обычной моделью, а оставшиеся 10% требуют более точного разбора договора, длинного контекста или хорошего качества на смешанном русском и казахском. Держать под такие случаи отдельную внутреннюю инфраструктуру обычно невыгодно.

Редкие сценарии почти никогда не окупают свои серверы. Если команда раз в неделю запускает пакетную проверку документов или эпизодически включает дорогую reasoning-модель для спорных кейсов, внешний LLM API снимает лишние расходы. Вы платите за фактическое использование, а не за ожидание нагрузки.

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

Выигрывает и эксплуатация. Поддерживать инференс 24/7 - это не только GPU. Это мониторинг, очереди, rate limits, обновления, деградация моделей и ночные инциденты. Если бизнесу не нужен постоянный внутренний контур для всех сценариев, переменную и редкую нагрузку проще вынести наружу.

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

На практике схема часто получается смешанной. Базовый поток остается внутри, а редкие, дорогие или пиковые запросы уходят наружу.

Как делить сценарии по расписанию

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

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

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

Само расписание без порогов быстро ломается. Нужны хотя бы простые условия:

• длина очереди
• p95 времени ответа
• доля ошибок за последние 5-10 минут
• лимит бюджета на текущее окно

Пример простой логики: днем онлайн-чат идет во внешний API, пока p95 не выше 2 секунд и очередь не растет. Если очередь во внутреннем контуре падает ниже заданного порога, часть трафика можно вернуть туда. Ночью batch-задачи по умолчанию идут внутрь, но если очередь перевалила за лимит и окно начинает сдвигаться, система временно отправляет часть задач наружу.

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

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

Что измерять до переключения

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

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

Потом смотрите на задержку по часам. Средняя задержка полезна, но почти всегда обманывает. Пользователь замечает не среднее значение, а плохие пики. Поэтому снимайте и среднюю, и p95 задержку для каждого часа, отдельно для hosted и внутреннего контура. Если в 10:00-12:00 p95 у self-hosted растет вдвое, расписание уже должно это учитывать.

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

Если вы держите свои модели на GPU, не ограничивайтесь метрикой "сервер жив". Нужны загрузка GPU, длина очереди, доля таймаутов и число повторных запросов после сбоев. Бывает, что сама модель отвечает быстро, но очередь перед ней съедает еще 8-12 секунд. Для пользователя разницы нет: он все равно ждет.

Еще одна частая ошибка - отправлять на сильную модель все подряд. Проверьте, где она действительно нужна. Возьмите выборку запросов и сравните результат дорогой модели с более простой по качеству ответа, числу исправлений оператором и доле успешных завершений сценария. Иногда сложная модель нужна только в 15% случаев, а остальное можно держать внутри заметно дешевле.

Хороший минимум для лога по каждому запросу такой:

• тип сценария
• час и день недели
• hosted или self-hosted маршрут
• токены, цена и задержка
• флаг чувствительных данных и итог по качеству

Если внешние провайдеры и внутренние модели уже сведены в один OpenAI-совместимый шлюз, такие сравнения делать проще. Тогда решение опирается не на догадки, а на понятную таблицу: сколько стоит каждый поток, где проседает p95 и какой трафик обязан остаться внутри.

Как внедрить схему по шагам

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

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

1. Выберите один сценарий с предсказуемым объемом трафика и простой проверкой качества.
2. Собирайте минимум 7 дней метрик по часам: число запросов, среднюю и 95-й перцентиль задержки, цену одного ответа, долю ручных правок, процент сбоев.
3. Задайте простое правило переключения. Например: с 01:00 до 07:00 запросы идут во внутреннюю модель, в часы пика - во внешний API.
4. Подайте на это правило небольшую долю трафика, например 5-10%, и оставьте остальной поток на текущем варианте.
5. Сравните две ветки по трем вещам: стоимость, скорость и качество ответа. Если хотя бы один параметр выходит за ваш допуск, возвращайте старую схему.

Лимиты лучше записать заранее, а не придумывать после теста. Например: задержка не выше 2,5 секунд, не больше 1% таймаутов, экономия не меньше 15%, доля ручной правки не растет. Тогда переключение перестает быть идеей "на глаз" и становится обычным правилом эксплуатации.

План отката нужен в первый же день. Если внутренняя модель перегружена, внешний провайдер меняет поведение или качество проседает на новой партии запросов, команда должна за минуты вернуть весь трафик назад. Чем меньше точек, где нужно что-то менять вручную, тем лучше.

Хороший пилот редко выглядит эффектно. Он просто дает цифры, после которых уже ясно, где держать сценарий внутри, а где платить внешнему API.

Пример для банка с двумя окнами нагрузки

У банка часто есть два разных ритма работы. Днем, когда операторы отвечают клиентам в чате, запросы идут почти без пауз. Люди ждут ответ за секунды, и любая задержка сразу заметна.

В это окно банк обычно держит основной поток во внутреннем контуре. Туда идут диалоги, где есть ФИО, ИИН, номер договора, остатки по счету и история операций. Такой маршрут помогает не выносить PII наружу и держать поведение системы под более плотным контролем.

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

Схема выглядит просто:

• днем внутренний контур берет клиентский чат с персональными данными
• ночью пакетные задачи уходят на более дешевую или более сильную внешнюю модель
• редкие сложные вопросы операторов, где нужен более глубокий разбор, сразу эскалируются во внешний API

Представим обычный случай. Клиент спрашивает, почему не прошел платеж и почему изменилась комиссия. Диалог содержит личные данные, значит его разбирает внутренняя модель. Но если оператор добавляет свободный вопрос вроде "объясни возможные причины по всей цепочке операций и предложи текст ответа клиенту", система может отправить обезличенную выжимку во внешний API. Так банк не гонит весь поток наружу, а использует внешний ресурс только там, где он действительно нужен.

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

Где чаще ошибаются

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

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

Вторая ошибка кажется мелкой, но бьет больно: команда смотрит только на цену токенов. На бумаге внутренний запуск может выглядеть дешевле, но простой в пиковый час быстро съедает эту разницу. Если сотрудники ждут ответ по 20-30 секунд вместо 3-5, бизнес платит не только за GPU или API, но и за потерянное время людей.

Еще один промах - считать среднюю нагрузку и забывать про худший час дня. Внутренний контур часто живет нормально до первого резкого всплеска. Например, утром и после обеда поток запросов может вырасти почти вдвое. Если запас мощности не заложили заранее, расписание переключения только усилит очередь.

Часто команды строят маршрут только по времени и забывают про тип данных. Это плохой компромисс. Один и тот же слот в 19:00 может быть безопасным для обезличенных запросов и неподходящим для диалогов с персональными данными. Время - лишь один признак. Второй признак - что именно вы отправляете, куда и в каком виде.

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

Один gateway и замена base_url сильно упрощают запуск, но не отменяют проверку. Один и тот же маршрут стоит прогнать отдельно для коротких задач, длинных цепочек и пиковых часов. Иначе вы получите удобное переключение, но неудобные инциденты.

Короткая проверка перед запуском

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

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

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

Отдельно разделите трафик по данным. Если часть запросов содержит PII, банковские данные или внутренние документы, правило маршрута должно учитывать это отдельно от цены. Для таких сценариев нужен понятный маршрут, аудит-лог и маскирование чувствительных полей.

Не сводите цену, качество ответа и ошибки в одну среднюю цифру. Если модель стала дешевле, но выросли отказы или просело качество на реальных задачах, экономия быстро исчезает.

И наконец, проверьте откат. Команда должна уметь быстро вернуть старый маршрут, если внешний провайдер начал сбоить или внутренняя модель не держит нагрузку. Лучше, когда это делается одним переключателем на уровне шлюза, а не правками в нескольких сервисах.

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

Что делать дальше

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

Такой старт проще защитить перед командой и финансами. Вы быстрее поймете, дает ли схема реальную экономию или только добавляет лишние правила.

Сведите решение в одну таблицу. Без нее почти всегда начинается путаница: одна команда думает про цену, другая про данные, третья про SLA. В таблице должны быть конкретные условия для каждого окна нагрузки:

• время работы сценария
• тип данных и можно ли отправлять их во внешний API
• допустимая задержка и минимальный SLA
• лимит бюджета на день, неделю или 1000 запросов
• маршрут по умолчанию и запасной маршрут

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

Если у вас есть и внешний API, и внутренний контур, единая точка входа заметно упрощает жизнь. Для команд в Казахстане это особенно полезно, когда нужно совместить доступ к внешним моделям с локальным размещением данных. В таком случае AI Router может закрыть обе стороны схемы через один OpenAI-совместимый endpoint: внешние провайдеры, локально размещенные open-weight модели, аудит-логи, маскирование PII и маршрутизацию без замены SDK, кода и промптов.

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

Если цифры не меняются, не усложняйте архитектуру. Если ночной трафик стабильно уходит во внутренний контур дешевле, а дневной держит SLA через внешний API, берите следующий сценарий и повторяйте ту же схему с новой таблицей правил.