Как глобальный финтех-сервис масштабировал трафик агентов кодинга с помощью Dedicated Model Inference

Рабочая нагрузка

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

Это ставит инференс на критический путь скорости поставки продуктов компанией, а не просто внутрь отдельной функции для конечного пользователя. Нагрузка работает на GLM-5.2, модели смещения экспертов (MoE), созданной для долгосрочных задач программирования и агентской работы, и развернута на Together. Трафик следует за рабочим днем: пиковый, сосредоточенный в часы работы инженеров, и он растет каждый раз, когда новая команда внедряет агентов в свой рабочий процесс.

Ограничение: планирование мощности не успевало за внедрением

Операционный контроль

Клиент пришел в Together после запуска рабочих нагрузок кодинга с другими провайдерами инференса и сначала консолидировал их на нашем предыдущем выделенном решении. Это решение работало, но не было рассчитано на то, как на самом деле ведет себя данная нагрузка. Трафик помощника по программированию неоднороден; он имеет пиковую нагрузку и относительно низкий показатель TPS, сконцентрирован в рабочие часы инженеров, с резкими всплесками параллелизма и размера промптов по мере того, как все больше команд внедряют агентов в свои ежедневные рабочие процессы. Именно поэтому параллелизм, а не общая пропускная способность, был главным приоритетом при проектировании перехода нагрузки на GLM-5.2.

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

Когда мощности выделяются под вчерашний прогноз, а трафик действительно имеет скачкообразный характер, емкость префилла (prefill) и запас KV-кеша исчерпываются как раз во время пика — то есть в самый ответственный момент, что приводит к многоминутной очереди запросов, которую агентские рабочие процессы кодинга не могут терпеть. Исправление этого постфактум по сравнению с предоставлением собственным командам клиента возможности видеть нагрузку и масштабироваться на опережение — это разница между проблемой координации и инфраструктурной проблемой.

Требования клиента: самообслуживание, наблюдаемость, параллелизм

Клиент предъявил команде Together требования к автономности в дополнение к «сырой» производительности, и специфика самой рабочей нагрузки объясняет почему. Трафик помощника по программированию работает при ISL p50/p90/p95 примерно на уровне 81K/163K/178K токенов и RPS p50/p90/p95 на уровне 3/6/7 — это паттерн пиковой нагрузки с относительно низким TPS, где всплески параллелизма имеют гораздо большее значение, чем чистые токены в секунду. Это и стало фоном для запросов клиента к Together:

• Самостоятельное выделение ресурсов: инженерная команда должна иметь возможность развернуть собственную конечную точку и направить на нее трафик без подачи заявок или ожидания группы платформы. Это кардинальное отличие от прежней модели, где запрос на мощности от каждой новой команды проходил через Together и платформенную команду клиента.

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

• Пропускная способность и быстрое масштабирование при концентрированной нагрузке: стабильная производительность во время пиков в рабочие часы, а не в условиях бенчмарков, с использованием десятков чипов B200 в многорепликационной конфигурации с контекстом 256K, размер которой специально рассчитан на сохранение запаса параллелизма.

• Гибкость моделей: возможность менять модели по мере развития передовых технологий без повторных переговоров, что на практике продемонстрировано переходом с GLM 5.1 на GLM 5.2 в рамках одного аккаунта, а также живой настройкой параметров кеша и балансировки нагрузки как обновлением конфигурации, а не повторным развертыванием.

Что было поставлено: полный контроль над эндпоинтом, API метрик и гибкость моделей

Конфигурация эндпоинта через API, UI или CLI

Dedicated Model Inference предоставляет полный жизненный цикл эндпоинта: создание, определение размера, политику масштабирования и изменение конфигурации. Инфраструктурная команда клиента использовала именно это, когда миграция изменила форму их эндпоинта GLM 5.2, сместив баланс в сторону меньшего числа более крупных реплик при том же общем объеме ресурсов, но с другим соотношением числа реплик к числу чипов на реплику. Когда это изменение привело к загрузке префилла почти на 100% несколько дней спустя, с постановкой запросов в очередь на одну-три минуты и падением пропускной способности декодирования примерно до 5 токенов в секунду, решением стал не новый деплой и не тикет обратно в Together. Это было изменение конфигурации «на лету»: восстановление настроенной политики маршрутизации с учетом сеансов кеширования вместо политики DMI по умолчанию (с учетом кеша по хешу) и увеличение порога max-inflight-per-worker. Все это было внедрено в тот же день без какого-либо простоя.

API метрик

Программный доступ к данным об использовании и производительности эндпоинта помог найти первопричину. Служба поддержки Together API проследила один медленный запрос длительностью 192 секунды от начала до конца по данным метрик и выяснила, что он не был ограничен вычислительной мощностью, а провел почти все время в очереди за бэклогом ожидающих префилла запросов объемом 2,3 млн токенов от других запросов, а не из-за собственного промпта на 250 тыс. токенов. В этом и заключается особая ценность наблюдаемости самообслуживания: собственная команда клиента диагностировала проблему очереди, а не проблему емкости, не дожидаясь, пока Together выгрузит логи.

Быстрый доступ к богатой библиотеке моделей

Dedicated Model Inference предоставляет пользователям доступ в режиме самообслуживания к передовым открытым моделям, а также к конфигурациям с учетом производительности, помогая клиентам выбирать любое сочетание TTFT, TPS, TPM и других метрик. Команда клиента тесно сотрудничает с инженерами Together по работе с клиентами для постоянной оптимизации этих конфигураций по мере эволюции использования их ИИ-агентов кодинга.

Это проявилось в переходе с GLM 5.1 на GLM 5.2 и итерациях длины контекста в рамках одной учетной записи и шаблона эндпоинта без каких-либо повторных согласований. Это также проявилось в осознанном компромиссе конфигурации, который команда клиента сделала самостоятельно: учитывая свой профиль трафика, они оценили конфигурацию с контекстом в 1 млн токенов и отказались от нее, потому что удвоение контекста до 1 млн сократило бы запас параллелизма, от которого действительно зависит их нагрузка с пиковым трафиком и низким TPS. Команда предпочла остаться на значении 256K/512K.

Хронология: от ранних нагрузочных тестов до продакшн-эндпоинта в масштабе

Отношения в сфере помощников по программированию начались за несколько месяцев до появления продакшн-эндпоинта GLM 5.2. Команда архитектуры решений Together уже создала выделенную инфраструктуру нагрузочного тестирования, моделирующую реальный паттерн использования клиента, изначально проверенную на предыдущем релизе GLM.

Эта подготовка напрямую перешла в GLM 5.1. В самом начале руководитель проекта со стороны клиента в один из выходных запросил тест на параллелизм в стиле чек-бокса для GLM 5.1 на 8–16 B200, специально для сценария использования в программировании и отдельно от более ранних тестов, которые были ориентированы на потребителей и задержку. Together подготовила тестовую конечную точку в тот же день, и GLM 5.1 успешно прошла проверку и была отправлена в производство: две выделенные конечные точки, разделенные по доступности, работающие в качестве внутреннего помощника по программированию для разработчиков клиента.

• Переход на GLM 5.2: Клиент перенес рабочую нагрузку по программированию на GLM 5.2, и производственная конечная точка начала работать на нем с контекстом 256K на 56 чипах B200 (14 реплик по 4 B200), отдавая приоритет параллелизму, а не максимальной пропускной способности, чтобы соответствовать пиковой нагрузке клиента и относительно низкому уровню трафика TPS.

• Самостоятельная миграция на DMI: Команда CX компании Together перенесла конечную точку GLM 5.2 клиента на платформу самообслуживания DMI, предоставив клиенту контроль над масштабированием, развертыванием пользовательских весов и сине-зеленым тестированием, в то время как команда SA/FDE компании Together готова оказать помощь в любой настройке производительности.

Результаты

Время на изменение конфигурации или выпуск обновления модели

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

В DMI весь этот процесс перешел внутрь компании:

• Масштабирование: клиент настраивает емкость напрямую, без отправки тикета в Together.

• Развертывание пользовательских весов: новые версии моделей задействуются без цикла повторного развертывания.

• Сине-зеленое тестирование: клиент проверяет изменения на производственном трафике по собственному графику.

Что дальше: вторая рабочая нагрузка и регион

Развертывание перестало быть единой конечной точкой и превратилось в платформу для инноваций. Теперь этот паттерн повторяется как конвейер, а не как разовое событие. Команда клиента уже планирует выделенный узел GLM 5.1 в новом регионе под реальную рабочую нагрузку в производстве. Это иной тип рабочей нагрузки по сравнению с исходным ассистентом программирования: чат-бот для клиентской поддержки на базе NLP, а не долгосрочное агентированное программирование, использующее ту же инфраструктуру и шаблон подготовки.