Подробный разбор · Около 5 мин чтения
SGLang-TorchTPU переносит нативный PyTorch-сервинг на TPU, но уровни поддержки остаются важны
Открытый плагин сохраняет архитектуру SGLang и добавляет ядра TPU, группы скомпилированных форм и перенос KV. Демонстрация обучения с подкреплением остается предварительной.
- Опубликовано здесь
- Дата источника
- Источник проверен
Команда SGLang из RadixArk, Google и Meta представили SGLang-TorchTPU 20 октября. Релиз дает нативный путь PyTorch для обслуживания моделей на TPU Google Cloud. Мы полностью прочитали описание запуска, объявление экосистемы Google Cloud и обновленную архитектурную статью TorchTPU, чтобы разобрать механизм, испытания и пока экспериментальные части.
Слушать новости
Прослушайте эту статью или включите новости подряд.
Подготовка чтения…
Голос устройства
Речь обрабатывает браузер или устройство. AISubHub не отправляет текст в аудио-API. Доступные голоса и работа при заблокированном экране зависят от устройства.
При продолжении короткая фраза может повториться.
Кратко
- Плагин сохраняет планировщик, RadixAttention и API-сервер SGLang; под ними размещаются TPU-ядра, пулы кэша и скомпилированное выполнение.
- На запуске заявлены193 зарегистрированных TPU-теста для15 моделей. Это проверки реализации с уровнями поддержки, а не новый рейтинг качества и не гарантия любой конфигурации.
- Обучение с подкреплением Miles на TPU находится в предварительной версии. Опыт с четырьмя TPU-чипами и эталон с шестью H200 сравнивают раннее обучение, но не доказывают равную скорость или стоимость.
Приложение остается знакомым, а исполнительный backend меняется
SGLang-TorchTPU — плагин вне основного дерева исходников, а не отдельная переработка планировщика сервинга. Он регистрирует TPU-платформу и предоставляет операции внимания, пулы постраничного кэша ключей и значений, ядра смеси экспертов и исполнитель графов. Каждое TPU-ядро запускает собственный процесс PyTorch. Модель проходит через torch.compile в XLA, компиляторный стек TPU. Более широкое объявление Google ставит это рядом с vLLM, TorchTitan и другими интеграциями; их перечисление не означает одинаковую зрелость всех фреймворков и моделей.
Базовая статья TorchTPU различает обычное асинхронное eager-выполнение, синхронную отладку и необязательный DeferAndFuse, объединяющий операции. Это важно: удобная пошаговая отладка и эффективное повторное выполнение в продакшене — разные режимы, а не обещание максимальной скорости неизмененной eager-нагрузки.
Скомпилированные группы меняют разнообразие форм на повторное использование
В сервинге SGLang исполнитель дополняет prefill до групп по количеству токенов, а decode — до групп по размеру пакета. Группа компилируется один раз; следующие шаги используют сохраненную программу при совпадении формы. Pallas предоставляет ядра внимания и экспертных вычислений, зарегистрированные как пользовательские операции PyTorch внутри скомпилированного графа. Так знакомый код модели сочетается с аппаратно-специфичной работой под ним.
По нашей интерпретации, прогрев компиляции нужно измерять отдельно от повторного выполнения. Сервис с меняющейся длиной запросов и временем их прихода должен проверить фактическое покрытие групп и накладные расходы дополнения. Более общий bounded dynamism в статье еще описан как активная разработка; нельзя предполагать, что он устраняет любую перекомпиляцию в развернутой конфигурации.
Повторное использование префиксов и перенос KV устраняют разные узкие места
RadixAttention повторно использует закэшированную обработку общих префиксов запросов. TPU Sync решает другую задачу: перемещает страницы ключей и значений между ускорителем и памятью хоста либо между отдельными хостами prefill и decode. В описанной схеме получения потребителем decode забирает готовые фрагменты, пока следующий фрагмент prefill вычисляется. Страницы, уже имеющиеся в префиксном кэше decode, не пересылаются; различные схемы тензорного параллелизма могут перераспределяться в ходе передачи.
Эти механизмы могут избежать повторных расчетов и лишних перемещений, но не отменяют ограничения памяти и коммуникаций. У агента с повторяющимися запросами и потока несвязанных обращений разные возможности повторного использования. Пользу выгрузки памяти или разделения хостов нужно проверять по реальным задержкам, трафику и емкости, а не выводить из наличия функции кэша.
Цифры совместимости требуют определения тестов и знаменателей
Заявленные на запуске193 теста покрывают15 моделей на одно- и многохостовых TPU v7x, с проверками pull request и ночными прогонами. Структурированный вывод и вызов функций, а также конвейерный параллелизм и выполнение экспертов NVFP4 отмечены в таблице как экспериментальные. Некоторые недавно перечисленные модели также еще проверяются. Название модели само по себе не определяет пригодные сочетания функций или степень оптимизации.
Более широкая статья показывает другое различие знаменателей:4821 из4917 моделей корпуса проходят тест без сбоев, что авторы обозначают как98%;638 из657 представителей архитектур проходят численную эквивалентность, обозначенную как97%. Тесты и совокупности различны. Ни одна цифра не означает, что тысячи моделей получили одинаковую квалификацию точности, качества задач и производственной скорости.
Демонстрация обучения с подкреплением допускает более узкий вывод
Miles связывает траектории, генерируемые SGLang, обучение TorchTitan и синхронизацию обновленных весов. В примере Qwen3-4B обучают GRPO на DAPO-Math-17k: один хост TPU v7x имеет четыре чипа, поровну отданные обучению и генерации траекторий. Эталон использует шесть H200 GPU с той же схемой и гиперпараметрами, с двумя значениями случайного зерна (seed) на каждой платформе. Авторы сообщают о сходных вознаграждении и длине ответа в пределах межсидовой вариации, а различия AIME-24 находятся в шуме оценки.
Это поддерживает ограниченное сравнение раннего обучения, а не равную пропускную способность или расходы этих аппаратных наборов. Реальный запуск передает веса через общую память. Передача чекпойнтов через диск работает между хостами, но названа самой медленной; прямая передача между устройствами по ICI еще запланирована. Многохостовое обучение, длительная проверка и сокращение отставания времени шага от GPU остаются будущей работой.
Полезный пилот миграции проверяет результат, а не только запуск
Практическая рекомендация AISubHub — ограниченный пилот: закрепить чекпойнт и точность, подтвердить требуемый уровень поддержки, сохранить известные входы и измерить компиляцию, повторный throughput, хвостовые задержки, использование кэша и правильность выходов. Следует включить выделенные облачные ресурсы и реальный счет. Предложение общественных мощностей требует заявки от участников разработки, а не дает неограниченного права на бесплатные TPU.
Это релиз сервинга от 20 октября, а не сегодняшнее объявление новой модели. Архитектурная статья впервые появилась 16 октября, прочитанная версия обновлена 20 октября; обнаружение в RSS 21 октября не является первой подачей. Мы объединяем материалы в один анализ реализации. SGLang-JAX продолжает поддерживаться: новый backend нельзя описывать как прекращение старого проекта.
Почему это важно
Анализ AISubHub: сохранение приложения сервинга на PyTorch может уменьшить расхождение программных путей при миграции. Однако решение зависит от конкретного чекпойнта, поддерживаемых функций, компиляции, качества выходов, доступной мощности оборудования и измеренного счета для целевой нагрузки.
Ограничения и доступность
Все рассмотренные результаты производительности и совместимости принадлежат авторам источников. AISubHub не запускал стек, не арендовал TPU и не воспроизводил тесты. Мы прочитали подписи, но независимо не исследовали пиксели графиков. Открытое ПО не включает резервирование облака, бесплатные вычисления для всех или преимущества потребительской подписки.
Источники и подтверждения
Дата источника: · Источник проверен:
Дата источника: · Источник проверен:
Дата источника: · Источник проверен:
Материалы подготовлены с помощью ИИ и сверены с указанными первоисточниками. Заявления поставщиков атрибутированы; публикация не означает рекомендацию.