SGLang: как найти узкое место в tokenizer и detokenizer workers

Если SGLang принимает запросы медленно при простаивающей GPU, проверьте tokenizer и detokenizer workers до изменения GPU memory fraction. Подготовка входа и сборка текста могут ограничивать поток независимо от скорости модели. Для диагностики нужны временные границы CPU обработки и сравнимые запросы. Общая загрузка процессора без распределения по этапам не показывает, где именно возникло узкое место и поможет ли увеличение числа workers.

Найдите границу CPU работы

Tokenizer превращает текст в ID, а detokenizer участвует в преобразовании результата обратно в текст. В server arguments SGLang предусмотрены отдельные параметры workers и tokenizer backend. Следует проверить их семантику в установленной версии, а не считать количество процессов прямым множителем throughput. Даже при свободных CPU cores могут существовать другие ограничители: доставка запросов, сериализация или ожидание внутри scheduler. Поэтому сначала локализуйте время обработки, затем подбирайте число исполнителей для подтвержденного участка.

Снимите профиль нужного процесса

Руководство benchmarking и profiling различает CPU/GPU наблюдения и управление профилем. Убедитесь, что собираете серверную сторону, а не только клиентскую функцию отправки. Сохраните timestamps поступления, подготовки входа, выполнения и выдачи результата. Для streaming отдельно полезны задержка первого фрагмента и ритм дальнейшей детокенизации. Короткий успешный запрос может не выявить проблему, если нагрузка ограничивается обработкой длинных входов или большим количеством маленьких выходных фрагментов одновременно.

Пример двух диагностических наборов

Первый набор содержит длинные текстовые входы с коротким ожидаемым ответом. Второй использует короткие входы и более длинный вывод. Это тестовые профили, не предполагаемый результат работы сервера. Если первая группа тормозит до GPU исполнения, исследуйте входную токенизацию. Если растет задержка доставки уже сгенерированных фрагментов второй группы, посмотрите обратное преобразование и клиентское чтение. Не меняйте одновременно число workers обеих сторон: такая проверка не позволит связать улучшение с конкретным механизмом.

Меняйте параметры последовательно

Сначала сохраните базовый профиль, затем измените только один worker параметр. Оставьте model revision, batch limits и расписание запросов прежними. Записывайте CPU contention и память, потому что дополнительные процессы могут дублировать часть состояния и конкурировать за ресурсы. Если GPU utilization увеличилась, проверьте, улучшилась ли пользовательская задержка, а не только счетчик занятости. При ухудшении сравните очереди и загрузку CPU по процессам, прежде чем возвращаться к настройкам вычислительных ядер модели.

Оформите доказательство bottleneck

Полезный итог содержит профиль этапов до изменения, после изменения и повтор исходного варианта. Такой контроль помогает отделить эффект настройки от прогрева и случайного изменения входов. Укажите backend tokenizer, число workers, host CPU allocation и возможные ограничения контейнера. Не называйте проблему CPU bottleneck только по одному графику utilization. Доказательство должно показывать, что именно этот этап ограничивал прием или выдачу и что изменение его емкости изменило наблюдаемое поведение. Если профиль указывает на клиент или сеть, сохраните этот вывод и не добавляйте серверные workers без причины. Увеличение RAM или VRAM не заменяет такой разбор и не подтверждает, что дополнительные ресурсы будут использованы нужным процессом.

Связанные материалы

Гибридная CPU/GPU-архитектура: как разделить AI-сервис по задачам; SGLang memory fraction: как разбирать нехватку памяти.