Google Cloud выпустила llm-d 1.0: маршрутизация с учётом кэша для парков TPU и GPU снизила задержку на 85%

До сих пор каждый, кто разворачивал крупную языковую модель на своих серверах, сталкивался с одной и той же проблемой: стандартная балансировка нагрузки (когда запросы раздаются серверам по кругу) не учитывает, какой сервер уже хранит нужный контекст разговора. Запрос улетает на случайную машину, контекст приходится загружать заново, задержка растёт. Проект llm-d, который ведут Google Cloud, Red Hat и IBM при участии более 500 разработчиков из 25 организаций, решает именно это. Релиз представили на конференции PyTorch Conference North America, о нём сообщил портал Marktechpost.

Что именно измеряли?

Суть llm-d проще всего объяснить через аналогию. Представьте колл-центр, где клиент каждый раз попадает на нового оператора и заново рассказывает свою историю. llm-d — это система, которая направляет звонок именно к тому оператору, который уже знает контекст разговора.

Технически это работает так: маршрутизатор отслеживает, на каком сервере хранится кэш предыдущих запросов (KV-кэш, то есть промежуточные вычисления, которые модель уже выполнила). Новый запрос отправляется туда, где контекст уже загружен. Если память ускорителя (GPU или TPU) заполняется, кэш автоматически перемещается на обычную оперативную память сервера, а затем на SSD-диск.

Дополнительно llm-d разделяет два этапа генерации: prefill (первичная обработка промпта, требующая большой вычислительной мощности) и decode (посимвольная генерация ответа, ограниченная скоростью чтения памяти). Каждый этап выполняется на отдельном пуле серверов, настроенном именно под его нагрузку.

Проект работает на Kubernetes (система управления контейнерами, стандарт для облачных сервисов) и поддерживает ускорители NVIDIA, AMD, Intel и Google TPU через серверы моделей vLLM или SGLang.

Что обнаружили?

Все цифры ниже — результаты, опубликованные самой Google и компаниями-пользователями llm-d.

• Ironwood TPU (TPU 7-го поколения): маршрутизация с учётом кэша и выгрузка KV-кэша в оперативную память хоста снизили медианное время до первого токена (TTFT, то есть задержку перед началом ответа) более чем на 85%. Пропускная способность выросла в 2,4 раза по сравнению со стандартным сервисом Kubernetes.

• Платформа Gemini: доля попаданий в кэш префиксов (когда модель находит уже посчитанный контекст) удвоилась — с 35% до 70%. TTFT для кодовых агентов снизилось более чем на 35%.

• Масштабирование на 17 000 узлов GKE: пропускная способность выросла в 2,9 раза при распределении по трём кластерам. Успешность запросов составила 99,9%, накладные расходы на координацию — менее 1%.

• 70-миллиардная модель на A3 Mega: выгрузка KV-кэша на файловую систему Lustre и в оперативную память CPU улучшила TTFT примерно на 40% для промптов длиной 50 000 токенов. Сквозная задержка упала на 30%, расход GPU-часов — почти на 60%.

• RL time-slicing: загрузка ускорителей выросла с примерно 40% до более 70%, но около 30% времени простоя осталось.

Пользователи подтверждают схожую картину. Snap сообщает о попадании в кэш префиксов до 75-80%. Zenteiq зафиксировала рост пропускной способности более чем в 4 раза: с 1,47 до 5,97 миллиарда токенов в день на 1 000 чипов TPU v6e. IBM в демонстрации обслужила 3 000 параллельных кодовых ИИ-агентов (программ, которые самостоятельно выполняют задачи) по цене в 5-10 раз ниже стоимости коммерческих API.

Что это значит для вас?

Автору Дзена и копирайтеру. llm-d — инфраструктурный инструмент, напрямую вы с ним работать не будете. Но именно такие проекты определяют, как быстро и дёшево облачные сервисы отвечают на ваши промпты. Если вы используете API для генерации текстов или работаете с кодовыми агентами, задержка до первого символа ответа — ваше рабочее время. Снижение TTFT на десятки процентов — это заметное ускорение при массовой генерации.

Маркетологу и менеджеру. Демонстрация IBM (3 000 агентов по цене в 5-10 раз ниже API) — ориентир для оценки, когда выгоднее запустить собственный кластер вместо подписки на внешний сервис. Граница окупаемости собственной инфраструктуры смещается вниз.

Разработчику и предпринимателю в РФ. llm-d — открытый проект под Apache 2.0, код доступен на GitHub. Он работает на GPU NVIDIA, AMD и Intel, то есть не привязан только к Google TPU. В России прямого доступа к GKE Inference Gateway нет, но сам стек можно развернуть на собственных серверах с Kubernetes. Из доступных в РФ облаков с GPU-кластерами стоит смотреть на Yandex Cloud и Selectel, хотя готовых интеграций с llm-d там пока нет. Начать команда Google предлагает с простого: подключить маршрутизатор llm-d к уже работающему серверу vLLM и оценить попадание в кэш, без полного перехода на новую архитектуру.

Релиз llm-d 1.0 — не прорыв в качестве моделей, а инженерная работа уровнем ниже: чтобы та же модель отвечала быстрее и обходилась дешевле. Для тех, кто разворачивает языковые модели на своих серверах, это конкретный инструмент с открытым кодом, а не обещание в блоге.

По данным Marktechpost