В этом материале
Schedule conservativeness в SGLang регулируют по неопределенности длины будущих ответов, а не вместо общего бюджета GPU памяти.
Schedule conservativeness в SGLang регулируют по неопределенности длины будущих ответов, а не вместо общего бюджета GPU памяти. Большой max_new_tokens может сочетаться с фактически коротким выводом, поэтому оценка резерва способна оставлять емкость неиспользованной. С другой стороны, слишком агрессивное планирование может приводить к retractions. Настройку принимают по наблюдаемым очередям и выполнению, сохраняя конкретный профиль длины входа и ответа.
Что резервирует scheduler
Движок должен учитывать не только текущие токены, но и возможное продолжение принятых запросов. Руководство SGLang по tuning описывает консервативность планирования через сочетания token usage, очереди и retractions. Это отличается от физической доли памяти, выделяемой runtime. Один параметр меняет ожидания scheduler о работе, другой — ресурсную границу. Их нельзя считать двумя эквивалентными способами получить один результат, даже если оба изменения внешне отражаются на количестве одновременно обслуживаемых запросов.
Сохраните распределение вывода
Для каждого запроса запишите заявленный output limit и фактическое число сгенерированных токенов. Если приложение всегда задает большой потолок, но модель обычно завершает ответ по EOS раньше, это важная характеристика набора. Не сокращайте предел только ради красивого benchmark: изменение может нарушить реальные требования. Разделите короткие и длинные завершения и сохраните их доли. При повторении проверяйте, что случайные ответы не изменили профиль настолько, что сравнение двух настроек потеряло смысл.
Пример диагностической развилки
Предположим, очередь растет, использование токенов остается невысоким, а большинство запросов заканчивается существенно раньше заявленного бюджета. Это повод исследовать резервирование, но не готовый диагноз. Если же появляются частые retractions при высокой заполненности, исследуйте противоположную сторону компромисса. Заполните таблицу из наблюдений: queued work, token usage, завершения, retractions и задержки. Все значения должны относиться к одному временному интервалу и одной конфигурации, иначе корреляция разных этапов эксперимента будет ошибочной.
Проверьте причинность профилем
Используйте официальное руководство profiling, чтобы дополнить счетчики временной картиной исполнения. Меняйте conservativeness отдельно от memory fraction, числа активных запросов и chunked prefill. Для каждой серии сохраните одинаковое расписание поступления. Если throughput вырос, проверьте хвосты задержки и число повторно выполняемых действий. Агрессивный вариант может улучшить один агрегат, но сделать обслуживание менее устойчивым. Также проверьте, не стали ли ответы короче: меньший фактический объем работы не является доказательством более эффективного scheduler.
Сформулируйте рабочую границу
Выберите настройку, удовлетворяющую требованиям к очереди и допустимым задержкам на исследованном профиле. Сохраните значение, engine version, распределения длины и признаки отклоненных вариантов. Не объявляйте найденное число универсальным для любой модели: другая структура памяти и иной характер завершения изменят компромисс. При изменении output policy приложения повторите проверку. Итоговый артефакт должен связывать наблюдаемое резервирование с поведением scheduler и явно отделять его от ограничения памяти. Это позволяет следующему оператору понять, почему выбран осторожный или более агрессивный режим, и не повторять бесконечное повышение memory fraction, когда причина неиспользованной емкости связана с оценкой будущей длины ответа, а не с отсутствием доступной VRAM у процесса.
Связанные материалы
SGLang memory fraction: как разбирать нехватку памяти; Планирование GPU-пула: когда действительно нужен следующий сервер.