SGLang-TorchTPU ускорил выдачу токенов Muse Spark Open почти вдвое

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

Команда SGLang-TorchTPU описала запуск Muse Spark Open с 816 млрд параметров на одном хосте с четырьмя TPU v7. Главный результат для одного запроса: время на выходной токен снизилось с 3,78 до 1,95 мс. Замеры и устройство реализации опубликованы в блоге PyTorch.

Ускорителю нужно вовремя подвозить данные

Представьте кухню, где повар перед каждым действием останавливается и ждёт следующую корзину продуктов. Можно купить плиту мощнее, но ожидание от этого не исчезнет. Другой путь — организовать доставку так, чтобы следующая корзина приезжала во время приготовления текущего блюда.

Здесь применили похожую идею: объединили выполнение 62 слоёв в одну программу и совместили передачу данных с вычислениями. Это позволяет заранее готовить то, что понадобится следующему участку работы.

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

У массового сервиса другая задача: обслужить очередь без резкого роста задержки. Поэтому один красивый показатель скорости ещё не отвечает на вопрос, сколько пользователей выдержит система. Нужна серия замеров с разной нагрузкой и одинаковыми условиями.

Пауза агента — повод сохранить контекст

Второй результат касается памяти. Дополнительный кэш в оперативной памяти хоста увеличил пропускную способность на агентной нагрузке до 77%.

Возьмём помощника, который ищет ошибку в проекте. Он читает файлы, запускает тесты, получает вывод и возвращается к рассуждению. Значительная часть разговора между этими действиями остаётся прежней. Если сервер сохранил подготовленные данные контекста, следующий ход можно начать с меньшим объёмом повторной работы.

Для продуктовой команды отсюда следует полезный вопрос: что происходит с состоянием сессии, пока пользователь или инструмент молчит? Пауза сама по себе не означает, что разговор закончился. Особенно если агент ждёт сборку, внешний поиск или результат длительной команды.

Проверять это удобно отдельным сценарием. Дайте агенту большой документ, сделайте несколько коротких ходов с паузами и сравните время начала ответа. Затем повторите опыт при заполненной памяти. Так станет понятнее, насколько поведение сервиса зависит от сохранения контекста и что происходит при вытеснении старых сессий.

Что переносить в свой сервис

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

Разработчику стоит начать с трёх измерений: ожидание первого токена, интервалы между следующими токенами и число завершённых запросов при заданной задержке. Продакту — добавить реалистичный пользовательский маршрут с инструментами и паузами. Основателю — считать стоимость успешной задачи при приемлемом времени ответа.

Есть и отдельный сценарий для проверки очереди: один пользователь присылает огромный документ, а другой задаёт короткий вопрос. Посмотрите, сколько ждёт второй. Такой опыт быстро показывает, соответствует ли распределение ресурсов обещанному качеству сервиса.

Ценность публикации — в наборе проверяемых инженерных решений. Прежде чем менять железо, полезно выяснить, где именно сервер простаивает, какую работу повторяет и кому позволяет занимать очередь слишком долго.