程序员节很适合谈理想，我更愿意谈一张交接表：当维护者休假，另一个人能否根据记录重现一次部署、判断异常并退回旧版本？基础设施工作的价值，常常就在这个平常的问题里。
10 月 20 日，vLLM TorchTPU介绍了通过插件连接 TPU 执行路径的方式。接口保持熟悉，不代表所有模型和特性都在每代硬件上具有相同支持程度。首次编译、缓存复用和算子覆盖，也需要分别验证。这正好提醒我们：兼容性声明只是一张验收单的起点。
表里要留下什么
第一层记录环境：硬件型号、驱动、镜像 digest、模型 revision、依赖锁定文件。latest不能替代版本。第二层记录结果：固定样本能否运行、输出是否满足业务质量要求、结构化输出和工具调用是否符合协议。随机采样不宜只比对一条最终文本，应该按任务定义容差和失败条件。
第三层记录恢复：中断加载、节点失联、缓存失效之后，谁判断失败，谁重试，旧副本能否继续接请求。第四层才是成本：计算的是成功请求还是所有请求，是否计入预热、空闲和失败重做。四层没有通用的一键绿灯。
四层阶梯表示逐层补足证据，不代表每种硬件都已通过这些测试。
先检查交接记录是否缺项
下面的标准库例子仅校验记录结构；它不会证明写进去的结果真实。样本中的值都是教学占位，不能直接拿去采购或上线。
required = {"model_revision", "image_digest", "correctness", "recovery", "cost"} record = {"model_revision": "example-rev", "image_digest": "sha256:example", "correctness": "not_run"} missing = sorted(required - record.keys()) not_run = sorted(k for k, v in record.items() if v == "not_run") print("missing:", ", ".join(missing)) print("not_run:", ", ".join(not_run)) assert missing == ["cost", "recovery"] assert not_run == ["correctness"]运行输出：
missing: cost, recovery not_run: correctness把“是否测过”与“结果是什么”分开，能阻止一种常见误读：字段存在，于是大家默认测试通过。未测项应该明确写not_run，并保留下一步所需环境。对新后端，宁愿先交付一份有限而可信的能力边界，也不要把路线图写成已经支持。
留下能够被反驳的结论
一条有用的结论可以是：“固定 revision 的模型在目标硬件上完成了这组质量回归，但未覆盖多节点恢复。”它给接手者指出了可用范围和下一步工作。反过来，“全栈打通、稳定可靠”既无法重现，也难以追责。
本文 CPU 例子只检查交接表的缺项，未运行 TPU、vLLM 或模型质量评估。1024 之后，值得继续做的是补齐这些证据，而不是把一次发布消息写成自己的项目成绩。
