Рабочая нагрузка
Этот клиент поставляет финансовые продукты миллионам пользователей на десятках рынков, и темпы роста не замедляются. Поддержание такого темпа — это прежде всего инженерная задача, и инженеры компании полагаются на агенты кодинга на базе ИИ, чтобы справляться с ней.
Это ставит инференс на критический путь скорости поставки продуктов компании, а не просто внутрь отдельной функции для пользователя. Нагрузка работает на GLM-5.2, моделиmixture-of-experts (микс экспертов), созданной для долгосрочного кодирования и агентских задач, и обслуживается на платформе 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 и итерациях длины контекста в рамках одного аккаунта и паттерна эндпоинтов без каких-либо повторных переговоров. Это также проявилось в осознанном компромиссе конфигурации, на который команда клиента пошла самостоятельно: учитывая свой профиль трафика, они оценили конфигурацию с контекстом в 1M и отказались от нее, поскольку удвоение контекста до 1M сократило бы запас параллелизма, от которого зависит их нагрузка с пиковым трафиком и низким 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 для поддержки клиентов, а не долгосрочное агентическое кодирование, размещаемая на той же инфраструктуре и шаблоне подготовки ресурсов.
