Когда маленькая задача бронирует большой сервер

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

Поставщик ИИ для поддержки Forethought описал в кейсе AWS, как разделил эти нагрузки. Несколько моделей он разместил на общих конечных точках вывода, а часть небольших классификаторов перевёл на запуск по запросу. По данным опубликованного AWS интервью с компанией, первая мера сократила соответствующие расходы до 66%, вторая — примерно на 80% для перенесённых классификаторов. Это результаты конкретной системы по сравнению с её прежним размещением, а не обещание такой же экономии любому российскому бизнесу.

У компании, согласно источнику, инфраструктурой машинного обучения занимались три инженера, а её продукты обрабатывали более 30 млн клиентских взаимодействий в год. Поэтому здесь особенно показателен не сам масштаб, а управленческий приём: разложить «ИИ в поддержке» на задачи с разными требованиями к времени ответа и выделить каждой подходящий способ исполнения.

Что именно произошло в кейсе

Forethought раньше обслуживала свои модели через Kubernetes в облаке. При росте числа клиентов у компании появлялось больше моделей, в том числе настроенных под конкретные сценарии. По описанию AWS, часть вывода перенесли на SageMaker multi-model endpoints: несколько моделей используют общую инфраструктуру вместо отдельной постоянно работающей конечной точки на каждую. Вендор приводит пример автодополнения текста во время набора сообщения. Для этого направления компания сообщает о снижении затрат до 66% и об улучшении задержки; методика расчёта и исходные счета публично не раскрыты.

Другую часть — небольшие модели классификации, например определение приоритета обращения, — перенесли на SageMaker Serverless Inference. AWS сообщает об экономии около 80% на связанных с ними облачных расходах. Эти две цифры нельзя складывать: они относятся к разным рабочим нагрузкам и разным базовым вариантам размещения. Не стоит также переносить их на стоимость большого языкового ответа: в документации AWS для Serverless Inference прямо указано, что этот режим не поддерживает GPU, а также может испытывать задержку холодного запуска после простоя.

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

Что переносится в локальный контур

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

Для локального пилота полезна такая схема:

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

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

Независимая исследовательская работа Mélange показывает тот же общий принцип на обслуживании языковых моделей: выгодный тип ускорителя зависит от длины и частоты запросов и ограничения на задержку. Авторы сравнивали свои экспериментальные сценарии, поэтому их проценты не следует использовать как прогноз закупки для конкретной компании. Практический вывод скромнее: нельзя выбирать сервер только по максимальным токенам в секунду из рекламного теста.

Какие данные собрать до покупки железа

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

Затем измерьте три варианта на одной и той же выборке: простое правило или малую модель на CPU; общий локальный сервер вывода; внешний API там, где политика данных его допускает. Это сравнение архитектур, а не рекомендация выгрузить клиентскую переписку наружу. Для каждой ветки оцените качество решения, p95 задержки, число ошибок и долю ручных исправлений. Если классификатор сэкономил вычисления, но ошибочно отправляет срочные обращения в общую очередь, его низкая цена мало поможет.

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

Экономика: модельный пример

Допустим, выделенный локальный контур для одной функции обходится условно в 30 000 рублей в месяц с учётом амортизации, электроэнергии, администрирования и резерва на отказ. Это модельная цифра, не цена оборудования и не результат Forethought. При 3 000 подтверждённо полезных обработок фиксированная часть составляет 10 рублей на обработку. Если тот же контур обслужит 6 000 таких обработок без ухудшения качества и задержки, она снизится до 5 рублей. Если поток исчезнет на месяц, фиксированные расходы никуда не денутся.

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

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

Первый безопасный шаг

Не начинайте с закупки ускорителя «для всего ИИ». Разберите один процесс поддержки на отдельные задачи и две недели замеряйте частоту, пик, p95 задержки и долю принятых результатов. После этого испытайте простые правила и малую модель для маршрутизации, а генерацию включайте лишь там, где она действительно помогает оператору. Если выяснится, что гигантский сервер стоит ради одного короткого ярлыка «срочно», у Внутрика найдётся более подходящая тележка.

Источники: опубликованный AWS кейс Forethought — источник заявленных результатов компании; документация AWS по ограничениям Serverless Inference; документация NVIDIA Triton по совместному обслуживанию моделей; исследование Mélange о связи стоимости вывода с характеристиками нагрузки. Архитектурные рекомендации и расчёт в рублях — редакционный анализ и модельный пример.