Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Потоковую выдачу LLM в бессерверной среде удалось сделать ровнее без изменений модели и вычислительных ядер. В препринте команды NIT Karnataka, который не проходил рецензирование и содержит замеры самих авторов, планировщик TWP повысил пропускную способность до 45% относительно ServerlessLLM. Для своей инфраструктуры это означает новый вариант защиты от перегрузки между обычной очередью запросов и наращиванием числа GPU.
Почему новый запрос тормозит уже идущие ответы
Обработка запроса к LLM состоит из двух разных фаз. Сначала модель целиком читает входной текст и заполняет KV-cache — память с промежуточным состоянием внимания. Затем она генерирует ответ по одному токену за шаг.
Первая фаза требует много вычислений, а её стоимость растёт вместе с длиной входа. Во второй фазе GPU постоянно читает KV-cache активных запросов. Пока пакет невелик, память GPU справляется с этим потоком, поэтому добавление запросов почти не замедляет отдельный шаг.
После насыщения GPU каждый новый запрос увеличивает длительность шага для всего пакета. Поскольку активные ответы декодируются синхронно, один тяжёлый вход задерживает токены у всех пользователей. Возникает обратная связь: токены выходят медленнее, запросы дольше остаются активными, пакет растёт и ещё сильнее замедляет следующие шаги.
Обычная очередь видит, сколько запросов ждёт, но не показывает, насколько загружено декодирование. Заполненность KV-cache предупреждает о нехватке памяти, однако не отражает вычислительное насыщение. TWP использует как основной сигнал задержку между соседними токенами, ITL: она меняется уже на следующем шаге и напрямую соответствует паузе, которую видит пользователь.
Как окно токенов закрывает контур управления
TWP переносит решение о допуске с момента прихода запроса на границу между шагами декодирования. После каждого шага планировщик измеряет ITL, сглаживает значение и сопоставляет его с базовой задержкой для свободного GPU.
Если ITL растёт, TWP сужает окно токенов — общий бюджет работы, которую можно держать активной. Новые запросы остаются в очереди, пока часть текущих ответов не завершится. Если задержка остаётся низкой, а очередь увеличивается, окно расширяется и пропускает больше работы.
Одного окна недостаточно, поэтому планировщик отдельно проверяет запас памяти под KV-cache. Запрос должен пройти оба условия: у активного пакета должен оставаться токенный бюджет, а на GPU — место для состояния. Механизм приоритета не позволяет коротким и удобным запросам бесконечно отодвигать давно ожидающий.
Предварительную обработку длинного входа TWP делит на фрагменты по 64 токена и распределяет их между шагами декодирования. Такой запрос начинает отвечать позже, чем при загрузке входа одним блоком, зато не создаёт единственного длинного скачка ITL для уже активных пользователей.
Планировщик работает отдельным слоем над сервером модели. Ему нужны длительность шага, глубина очереди и заполненность KV-cache, но не нужны изменения весов, ядер внимания или формата памяти. Начальный размер окна и порог насыщения GPU определяют предварительным профилированием конкретной модели и оборудования.
Когда TWP меняет план инфраструктуры
Механизм проверяли на одной NVIDIA Tesla V100 с Meta-Llama-3.2-3B, запросами из GSM8K и синтетическим потоком с резкими изменениями нагрузки. TWP встроили в собственный конвейер обслуживания, а ServerlessLLM реализовали заново в той же среде. Поэтому сравнение изолирует работу планировщика, но не воспроизводит готовую многосерверную платформу.
Относительно обычных политик очереди пропускная способность выросла до 58%. На 99-м процентиле время до первого токена составило 66 мс против 78 мс у ServerlessLLM. Распределение ITL также стало плотнее: редкие длинные паузы возникали реже, хотя средняя задержка между токенами изменилась слабее, чем хвостовые значения.
Работа меняет планы команд, которые управляют собственным циклом декодирования и делят GPU между несколькими потоками запросов. Перед добавлением оборудования имеет смысл проверить, не возникает ли перегрузка из-за слишком агрессивного допуска: для этого достаточно записывать ITL по шагам и сопоставлять её с размером активного пакета.
Если сервер уже поддерживает непрерывное формирование пакетов и дробную обработку входа, TWP можно прототипировать как дополнительный контроллер допуска. В план внедрения придётся включить профилирование каждой связки модели и GPU, настройку размера фрагмента и проверку поведения на собственных распределениях длины входов и ответов.
Для приложения поверх внешнего API результат ничего не меняет: там нет доступа к шагам декодирования и KV-cache. Он также не обосновывает переход на бессерверную архитектуру сам по себе. Работа показывает более узкий вывод: внутри управляемого пула GPU обратная связь по задержке токенов может удерживать систему у границы насыщения лучше, чем фиксированный предел пакета или очередь без сигнала от модели.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
