К содержанию
Выпуск №80 · 27 августа 2026 / Новости

TPU догнал GPU по числам для длинных эмбеддингов, но экономику Google пока не доказал

Google встроил поддержку TPU в vLLM и показал почти полное численное совпадение с GPU для Qwen3-Embedding-8B на контексте свыше 15 тысяч токенов. Это уже production-маршрут для мультимодального поиска, но пересчитывать инфраструктуру стоит только после собственного теста пропускной способности и цены запроса.

Редакция 27 августа 2026 г., 08:19 MSK

В Telegram
ускорители Google TPU
Иллюстрация: hegai.media

Google предлагает смотреть на TPU не только как на ускоритель обучения или экзотических моделей, а как на инфраструктуру для постоянного embedding-инференса. Главный результат здесь не очередной порт модели: длинный контекст удалось провести через TPU почти без численного расхождения с эталонным GPU-контуром, а конфигурацию опубликовали для воспроизведения.

Для команд, которые строят мультимодальный RAG и поиск по большим документам, это расширяет выбор архитектуры. Но лишь технически. Google подтвердил сопоставимость результатов, а не преимущество по стоимости, поэтому обещанная альтернатива GPU пока начинается с GitHub и заканчивается вашим нагрузочным тестом.

Что именно собрал Google

Как пишет Google Developers Blog, поддержку TPU нативно интегрировали в движок инференса vLLM. Масштабирование embedding-пайплайнов предлагается строить через Google Kubernetes Engine, а в качестве показательного сценария используется Qwen3-Embedding-8B с контекстом более 15 тысяч токенов.

Обычного переноса оказалось недостаточно. Инженеры добавили безопасное для TPU выравнивание тензоров, предварительный прогрев компиляции JAX/XLA и гибридную архитектуру StepPool, которая управляет chunked prefill. Последний элемент особенно важен для длинных входов: система обрабатывает их частями, а не пытается проглотить весь контекст одним дорогим заходом.

По заявлению Google, эта конфигурация дает почти полное численное совпадение с референсными результатами на GPU. Рецепты развертывания опубликованы в репозитории AI-Hypercomputer на GitHub, поэтому речь идет не только о лабораторной демонстрации, а о контуре, который разработчики могут повторить.

Здесь, однако, полезно не путать два вида точности. Численная близость к GPU означает, что смена ускорителя не должна заметно менять выход модели. Она сама по себе не доказывает качество поиска на ваших документах: это придется проверять на собственном наборе запросов, разметке и метриках retrieval.

Почему TPU добрался до retrieval именно сейчас

Предыдущие примеры Google выглядели скорее как инженерные спецоперации. Для переноса модели Avatar IV от HeyGen на Trillium TPU потребовались torchax, XLA, FSDP, Ulysses sequence parallelism и работа с коммуникациями и sparse attention. Google сообщал об ускорении потоковой генерации в 1,86 раза. В другом проекте обслуживание Qwen 3.5-397B MoE на Ironwood потребовало модульного стека JAX/Pallas и гибридной схемы DP+EP; для нагрузок с тяжелым prefill компания заявляла ускорение до 4,7 раза.

Нынешний кейс отличается точкой входа. vLLM уже знаком командам, которые обслуживают модели, а GKE дает привычный слой оркестрации. TPU-маршрут становится менее похожим на отдельную инфраструктурную профессию. Не исчезают компиляция, выравнивание и управление prefill, но они упакованы в воспроизводимый рецепт, а не оставлены читателю в виде пожелания «оптимизировать под железо».

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

Где проходит граница выгоды

В публикации Google нет стоимости запроса, токенов в секунду, задержки, загрузки ускорителя или прямого сравнения расходов с GPU. Не названы и конкретные форматы мультимодальных данных в тестовом контуре. Поэтому делать вывод «TPU дешевле» из этого анонса нельзя. Компания доказала переносимость вычисления и численную сопоставимость, но не unit-экономику.

Практический порог простой: TPU имеет смысл, если выигрыш в пропускной способности и цене обслуживания длинного контекста перекрывает стоимость отдельной эксплуатации JAX/XLA-контура и GKE. Для небольшого или рваного трафика привычный GPU-маршрут может остаться рациональнее просто потому, что он уже работает. Для крупного retrieval-пайплайна цена инерции выше, и рецепт Google стоит включить в ближайший инфраструктурный bake-off.

Смотреть дальше нужно не на новые слова про enterprise-grade, а на таблицу с четырьмя строками: p95-задержка, пропускная способность, стоимость миллиона обработанных токенов и retrieval-метрика на одном датасете для TPU и GPU. Если независимые прогоны сохранят заявленную численную близость и покажут меньшую стоимость при контексте 15K+, TPU действительно станет конкурентом GPU в embedding-инференсе. Пока Google открыл маршрут, но счет за поездку не показал.

Как процитировать

«TPU догнал GPU по числам для длинных эмбеддингов, но экономику Google пока не доказал». hegai.media, 27 августа 2026 г.. https://hegai.media/novosti/tpu-dognal-gpu-po-chislam-dlya-dlinnyh-embeddingov-no-ekonomiku-google--e944d8ce-4936-4d83-a2fb-ba1451013051

так материал выглядит в мессенджере