Google представила TPU Sync Google — открытую библиотеку для ускорения инференса больших языковых моделей на Cloud TPU. Компания заявляет, что система сокращает задержку передачи KV-кеша более чем на 90% и в среднем на столько же уменьшает время до первого токена, но эти цифры получены на тяжёлых MoE-моделях в специально подходящем сценарии раздельного обслуживания.
Одновременно с расширением линейки TPU восьмого поколения Google открыла исходный код TPU Sync, сообщает The New Stack. Это нативная библиотека на C++, которая управляет KV-кешем и переносом данных между памятью ускорителя, оперативной памятью хоста, локальными SSD, общим хранилищем и узлами TPU в дата-центре.
Проблема, которую решает библиотека, знакома командам, обслуживающим LLM: при длинном контексте и повторяющихся префиксах вычисления — не единственный узкий участок. KV-кеш быстро разрастается, его приходится перемещать между уровнями памяти и узлами, а задержки сети начинают влиять на ответ модели. Особенно неприятно это в схеме disaggregated serving, где один набор машин выполняет prefill — обработку входного контекста, а другой генерирует токены.
TPU Sync Google использует асинхронные DMA-передачи и старается выполнять перенос данных параллельно с вычислениями. Вместо копирования или блокировки буферов библиотека обращается к ним напрямую. Для инференса она превращает HBM-память TPU, DRAM хоста, SSD и Google Cloud Managed Lustre в многоуровневый KV-кеш: горячие данные остаются ближе к ускорителю, менее востребованные автоматически вытесняются на более дешёвные уровни.
Заявленные «более 90%» относятся не к любой задержке инференса. Google сравнивала конфигурации с TPU Sync и без него в задачах prefix caching и раздельного обслуживания открытых MoE-моделей размером от 235 до 480 млрд параметров. Речь идёт о времени передачи KV-кеша и среднем Time to First Token, а не о гарантированном ускорении генерации каждого следующего токена, не о снижении стоимости сервинга и не о результате для произвольной модели.
Именно здесь находится важная оговорка к эффектной цифре. Если сервис работает с короткими запросами, почти не переиспользует префиксы или целиком укладывает нужный кеш в память ускорителя, выигрыш может быть куда скромнее: переносить попросту нечего. То же касается команд, у которых inference-стек построен вокруг GPU: TPU Sync Google адресована инфраструктуре Cloud TPU и не превращается в универсальный ускоритель для CUDA-кластера простым подключением пакета.
Тем не менее направление показательное. В гонке за низкой задержкой LLM всё чаще оптимизируют не матричные операции, а путь данных: сетевую топологию, обмен между prefill и decode, размещение весов и KV-кеша. Для продуктовых команд это означает, что метрика TTFT становится частью архитектурного выбора. Пользователь не оценит высокий throughput кластера, если интерфейс несколько секунд ждёт первый символ ответа.
Для российских команд новость прежде всего полезна как инженерный ориентир, а не как немедленная инструкция к миграции. Открытый код позволяет посмотреть, как устроены tiering кеша и асинхронный обмен, а в собственных нагрузочных тестах стоит отдельно измерять TTFT, p95/p99 задержки и долю запросов с общими префиксами. Проверять обещанные 90% имеет смысл только на сопоставимой модели, контексте и схеме сервинга.
Google пытается сделать TPU не просто собственным чипом, а более открытой платформой для инференса: вокруг неё уже появляются интеграции с распространёнными движками и PyTorch-инструментами. Главный вопрос не в том, сможет ли библиотека ускорить удачный бенчмарк, а в том, насколько легко её преимущества будут воспроизводиться в реальных сервисах с разнородными моделями, непредсказуемой длиной диалогов и жёсткими SLO. Подробнее о релизе — .
