夜雨聆风如果你也关注 AI、芯片和科技产业的真实变化，欢迎关注我。这里不追每一个热词，只拆当天值得看懂的一件事。
一块 AI 芯片再快，如果开发者得重写大量代码、重搭训练流程，它就很难真正抢走英伟达的生意。
7 月 24 日，Google 发布 Ray on TPU 系列的第二篇开发者指南。表面看，这是一篇教人如何在 TPU 上使用 Ray Serve、Ray Data 和 Ray Train 的技术教程。往深一层看，Google 正在处理一个更现实的问题：怎样让习惯 GPU 工作流的团队，少改代码就能试用 TPU。
新变化藏在一行配置里
Ray 是一套开源分布式计算框架。开发者用 Python 写任务，它负责把训练、推理和数据处理分配到多台机器。许多 AI 团队早已用 Ray 管理 GPU 集群，因此他们熟悉的并不是某一块芯片，而是一整套工作方式。
Google 在 7 月 20 日公布，Ray 2.55 已把 Cloud TPU 纳入正式支持范围，提供官方预构建镜像，并覆盖 Ray 的核心组件。7 月 24 日的新指南进一步给出完整用法：Ray Serve 可以部署大模型推理，Ray Data 负责向 TPU 输送已经转换成 JAX 数组的数据，JaxTrainer 则处理分布式训练、检查点和故障恢复。
最直观的变化，是开发者只需声明 TPU 的拓扑形状。例如填写一个 4×4 的 topology，底层便由 Ray 和 GKE 协调资源位置。
图源：Google Developers Blog。上层是开发者使用的 Ray 工具，底层由 Ray Core 与 GKE 管理 TPU 切片。
TPU 的麻烦，不只是换一块芯片
GPU 集群里的计算卡可以按任务分配，但 TPU 有一个特殊约束：芯片以固定的 slice，也就是“切片”连接。一个跨主机模型必须落在完整切片内，否则不同工作节点无法通过高速互联通信，任务可能一直卡在部署状态，却不给出一个干脆的报错。
过去，这类拓扑和调度细节需要团队自己处理。现在，GKE 负责创建并标记 TPU 切片，Ray Core 把完整切片一次性预留给任务。Ray Serve、Data 和 Train 再把这套机制包装成开发者熟悉的接口。
这类改进不太像新模型发布那样抢眼，但它很实用。工程团队评估新硬件时，真正计算的往往不是芯片单价，而是迁移时间、调试风险，以及出问题后谁来负责。
图源：Google Developers Blog。Ray Dashboard 已可查看 TPU 利用率和内存等指标。
Google争的，是CUDA外面的那层护城河
英伟达的优势当然包括硬件性能，但 CUDA 生态更难绕开。训练框架、推理引擎、监控工具和工程经验都围绕 GPU 积累，换芯片常常等于换掉半套生产系统。
Google 这次没有要求开发者先成为 TPU 专家。它选择接入 Ray，让用户沿用 Python、分布式任务和集群管理习惯，再把底层算力换成 TPU。这个思路很务实：先降低试用门槛，才有机会讨论价格、供应和性能。
不过，正式支持不等于大规模迁移已经开始。目前 Google 给出的主要是官方指南和可运行样例，真实生产负载下的兼容性、成本和稳定性，还要由更多客户验证。Ray 的 TPU 接口中也仍有标注为 alpha 的部分，后续版本可能调整。
芯片竞争，最后会落到“不折腾”
未来的数据中心不会只看哪张性能表更漂亮。云厂商和芯片公司都得回答一个朴素的问题：现有团队要花多少力气，才能把工作负载搬过来？
Ray on TPU 给出的答案是，尽量别让开发者感觉自己换了整套世界。短期看，它不会动摇 CUDA 的主导地位；但 Google 已经把竞争推进到软件迁移成本这一层。
硬件决定算力上限，软件决定有多少人愿意真正用它。后一句，可能更影响订单。
参考来源
Run Ray on TPU, Part 2: Ray AI libraries｜Google Developers Blog，2026-07-24 Run Ray on TPU, Part 1: The foundations｜Google Developers Blog，2026-07-20 Ray on TPU 可运行示例｜GoogleCloudPlatform / GitHub