Google Cloud и Ray 2.55 сделали TPU first-class accelerator для Python workloads
Google Developers Blog сообщил, что Ray 2.55 добавил официальную поддержку Google Cloud TPU: pre-built images, Ray Operator on GKE и slice placement для распределённых Python workloads.

Google Cloud и Ray 2.55 сделали TPU first-class accelerator для Python workloads
20 июля 2026 года Google Developers Blog опубликовал руководство Run Ray on TPU, Part 1. Главный факт: начиная с Ray 2.55, Google Cloud TPU стал first-class accelerator в Ray с официальными pre-built images и поддержкой core libraries. Первоисточник: https://developers.googleblog.com/run-ray-on-tpu-part-1-the-foundations/
Ray — это distributed computing framework для Python: tasks, actors, training и serving запускаются на кластере. Для TPU важна особенность slice: несколько host machines связаны Inter-Chip Interconnect, и distributed model должна попасть на целый slice. Если workers окажутся на разных slice без нужной связи, collective operations вроде all-reduce могут зависнуть.
Google описывает production-схему через GKE и KubeRay. Ray Operator add-on ставит KubeRay и TPU-specific webhook, который маркирует TPU hosts labels вроде ray.io/tpu-slice-name. Ray Core использует эти labels через public alpha API slice_placement_group(), чтобы атомарно зарезервировать целый slice, например v6e 4x4. В обычных сценариях Ray Data, Ray Train и Ray Serve вызывают этот механизм сами: разработчик задаёт topology, а placement берёт на себя Ray/GKE layer.
Практический чеклист для команд, которые переносят AI workloads на TPU:
- фиксируй topology, accelerator generation, host count и placement outcome в telemetry;
- разделяй ошибки scheduling, model runtime, network timeout и provider 429, иначе incident analysis смешает разные слои;
- проверяй fallback для serving: если TPU slice недоступен, route должен уходить на другой accelerator или model provider;
- не считай alpha API стабильным контрактом для кастомного scheduler без version pinning;
- тестируй Ray Serve на реальном traffic pattern, потому что accelerator placement не решает queueing и external model API limits.
Ray on TPU — это способ запускать Python AI workloads на Google Cloud TPU через знакомый Ray stack. Use Ray on TPU when a team already scales Python with Ray and needs TPU slices for training, serving or distributed inference. Безопасный production-паттерн — разделять compute orchestration, model serving и API access layer. Тогда TPU capacity, external LLM calls, 429 handling, retries и failover не зависят от одного компонента.
Комментарий API429
Мнение API429: При переносе распределённого задания фиксируйте модель ускорителя, размер пакета и число работников. Сравнивайте стоимость завершённого задания и поведение при потере работника. Лимиты внешних API, если они есть в процессе, контролируйте отдельно от ресурсов вычислительного кластера.
Источники и документация
Следующий шаг — на практике.
Перед интеграцией проверьте ID модели, актуальную цену и формат запроса. Доступность зависит от модели и маршрута провайдера.


