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 не зависят от одного компонента.