谷歌在Compute Engine的Cloud TPU资源页面里写得很直白：Cloud TPU API已不再积极开发，包括对应的gcloud CLI和Client Libraries，只做必要的bug修复和安全更新。更关键的是，从TPU7x（Ironwood）开始的新一代硬件，只支持通过Compute Engine或GKE使用。没有正式的终止日期，但那句话等于明说：你现在的API，你的下一代芯片用不了。 我手上有一台v6e-1（Trillium）芯片的机器，跑着vLLM服务的gemma-4-E2B-it。为了跟上新要求，我只能把它迁到gcloud compute instances体系下。芯片没换，checkpoint没换，serving参数没换，变的只是控制平面。本以为只是命令替换，结果后面的坑一个接一个：配额模型变了，启动直接死机，某些工具静默失明——而且几乎没有一个环节会大声报错。 先说最直观的命令变化。 旧方式： ``` gcloud alpha compute tpus queued-resources create vllm-gemma4-qr \ --node-id=vllm-gemma4-qr-node \ --zone=us-east5-b \ --accelerator-type=v6e-1 \ --runtime-version=v2-alpha-tpuv6e \ --provisioning-model=flex-start \ --valid-until-duration=2h ``` 新方式： ``` gcloud compute instances create gce-vllm-v6e1-2b \ --zone=europe-west4-a \ --machine-type=ct6e-standard-1t \ --image-family=ubuntu-accel-2204-amd64-tpu-v5e-v5p-v6e \ --image-project=ubuntu-os-accelerator-images \ --maintenance-policy=TERMINATE \ --boot-disk-size=200GB \ --scopes=cloud-platform \ --metadata-from-file=startup-script=/tmp/startup.sh \ --provisioning-model=FLEX_START \ --request-valid-for-duration=2h \ --max-run-duration=4h \ --instance-termination-action=DELETE ``` 命令映射其实是整个过程里最简单的一步。真正耗时间的是后面三件事：配额模型变了，旧配额不通用；启动脚本里某个依赖在新镜像里没装上，导致启动后直接死机；原本依赖Cloud TPU API的工具链，迁移后静默失效，不报错但也不干活。 最大的问题在于静默失败。比如TPU虚拟机的创建，在新体系下看起来成功了，但实例根本没有进入健康状态。查日志也没有明显错误，只是某些状态卡住。如果你不主动对比新老接口的预期行为，根本发现不了问题。 所以，如果你也要做类似的迁移，我的建议是：别只看官方文档推荐的命令，先把镜像启动流程完整验证一遍，确认配额类型匹配，再部署正式的serving负载。另外，所有依赖Cloud TPU API的脚本和工具，都要假设它们已经失效，逐个用新接口验证。 现在这些坑我已经趟平了，但整个过程谈不上愉快。官方虽然没设日落日期，但未来只会越来越向Compute Engine倾斜。早迁移，早省心。
热门跟贴