vLLM TorchTPU 复用 PyTorch 模型，部署验证仍取决于具体 TPU

vLLM TorchTPU 为团队提供了在 Google Cloud TPU 上运行 vLLM 模型的原生 PyTorch 路径。实用价值在于复用：多数现有 vLLM 模型定义可以通过新后端运行，无需为另一个框架重新实现。不过，部署的可靠依据仍取决于 TPU 代际、具体检查点以及使用的功能。

vLLM 发布文章和 Google 公告都将发布日期定为 2026 年 10 月 20 日。Google 说明，此前已经有基于 JAX 的 TPU 后端；这次变化面向希望在 PyTorch 中定制和调试推理服务栈的开发者。

该项目是独立于 vLLM 主仓库的平台插件。按照发布文档，它保留上游的调度器、API 服务器和 KV 缓存管理器，同时通过 TorchTPU 与 XLA 编译模型。TPU 专用的 JAX/Pallas 内核位于这条 PyTorch 执行路径之下。

这种设计将模型的表示方式与高效执行所需的专用工作分开。保留熟悉的服务接口，可能减少集成修改，但不能证明所有模型、量化格式和扩展在另一种加速器上都具有相同行为。

10 月 22 日查阅的仓库要求在 Cloud TPU 虚拟机上使用 Python 3.12。项目推荐 v7x，即 Ironwood，并在拉取请求和每夜任务中进行验证。v6e 被列为受支持但没有持续集成覆盖，v5e/v5p 则属于没有持续集成覆盖的实验性支持。

模型与功能指南还区分了另一层验证：某个检查点可能进入持续集成、每夜验证、组件测试，或仅有示例配置。这些级别提供的依据不同。模型家族出现在列表中，只能作为进一步核对具体检查点和功能组合的起点，不能证明所有配置都通过了端到端服务测试。

发布文章提醒，首次启动需要为配置的形状编译计算图，可能耗时数分钟。评估部署时，应同时考虑这项准备工作，以及预热之后的延迟和吞吐表现。

按照目前的编译指南，原生可执行文件缓存由 TORCH_TPU_TIER3_COMPILATION_CACHE_ROOT 控制，Python 框架产物则由 VLLM_CACHE_ROOT 控制。将其中一种缓存持久化，并不表示另一种也已经覆盖。

工程试验应记录准确的检查点、精度、上下文长度和请求并发度，再检查输出正确性，以及冷启动和预热之后的运行情况。这是此次发布带来的实际下一步。TechKili 尚未对该后端进行基准测试，发布本身也不能证明某一工作负载的运营成本更低或推理速度更快。

相关文章