Serverless GPU 地域延迟测试设计与排障
说明 Serverless GPU 地域延迟测试如何选择节点、固定变量并分层记录网络与推理耗时，结合 MLPerf 的 TTFT、TPOT 定义和服务配置排障，避免只用 Ping 判断体验。
做 Serverless GPU 地域延迟测试，不能用一次 Ping 代替完整测量：应从同一客户端节点向候选地域发送同一负载，分别记录网络、首 token、后续 token 和完整响应耗时。使用算力租赁时，还要把 GPU 可用性、启动错误、配额和存储生命周期分开排查。下面给出测试矩阵、计时口径和排障顺序；具体地域字段与启动方式以供应商当前文档为准。
算力租赁：先搭好可比较的测试矩阵
一个测试单元应由客户端节点、候选地域和一份固定工作负载组成，每轮只改变一个待比较维度。
- 固定模型、版本、量化方式、runtime 镜像和服务配置。
- 固定请求集合、输入输出长度、并发方式、鉴权方式以及流式或非流式模式。
- 固定客户端出口；存在多个用户位置时，分别建立测试组，不混合统计。
- 记录 provider、region、zone 或资源池、GPU 型号。平台没有 zone 字段时留空，不自行推断。
若平台区分首次调用和实例复用请求，应按其当前文档定义分组；失败请求单独记录，不能混入成功请求的延迟分布。
选测试节点和地域时先核对可用性
从与实际用户网络条件相近的节点发起请求，并在相同节点上比较候选地域。AWS 的 Regions and Zones 文档说明，Region 彼此隔离，资源不会自动跨 Region 复制，并建议选择靠近客户或满足法律及其他要求的 Region。
不同地域不一定提供相同 GPU。Google Cloud 的 GPU locations 文档明确指出，具体 GPU 型号在不同 region 和 zone 的可用性不同。如果候选地域缺少目标型号，应记为可用性问题，不能把启动失败解释成低延迟。
把一次请求拆成网络与生成耗时
按 MLPerf Inference 规则，所有提交必须使用 LoadGen；其 latency 从 LoadGen 把 query 交给 SUT 起，到收到 reply 为止；LLM benchmark 还记录 TTFT 和 TPOT，而 Server、Offline、Single stream 的发压方式不同，因此不同场景的结果不能混成同一张延迟表。
Ping 只能作为网络路径的一个观测点，不能说明服务是否已经就绪，也不能暴露流式输出在哪一阶段停顿。客户端应记录请求发送、首个响应、最后响应和各个输出 token 的到达时间；这些是你自己的日志字段，不是平台统一 API 字段。
端到端耗时 = last_response_at - request_sent_at
TTFT = first_response_at - request_sent_at
生成阶段耗时 = last_response_at - first_response_at
TPOT观察值 = 各输出 token 到达时间之差的平均值
网络段只记录客户端工具能够直接观测的 DNS、连接和首字节边界；无法可靠拆分时，就保留端到端数据，不用总耗时反推网络耗时。服务端能够提供接收、排队和生成时间时，再同步两端时钟后进行对照。
固定 API 与存储层
如果 API 层使用 FastAPI，Docker 部署文档的示例采用 exec form，以确保应用能够优雅关闭并触发生命周期事件。测试期间应保持启动方式一致，下面是该文档中的示例命令：
CMD [ "fastapi", "run", "app/main.py", "--port", "80" ]
按 RunPod 的存储说明，Container disk 会在 Pod 停止时清空；Volume disk 中的 /workspace 在停止和重启后保留，但终止 Pod 时删除；Network volume 独立于 Pod，删除 Pod 后仍可保留数据，并替代 /workspace，且必须在创建 Pod 时挂载、不能事后分离。比较首次请求和后续请求前，应先确认模型、缓存及测试数据实际位于哪类存储中。
常见排障按错误类型分流
按 AWS 的 EC2 启动排障文档，InsufficientInstanceCapacity 表示当前 On-Demand 容量不足，创建新实例或重启已停止实例时都可能出现；InstanceLimitExceeded 则表示已达到 Region 内可启动实例的数量上限。对于容量错误，文档建议等待后重试、不指定 Availability Zone，或减少单次请求中的实例数量。
启动失败不是延迟样本，应先归入容量或配额问题。网络边界在不同候选地域明显变化时，检查客户端出口和路由；网络边界稳定但 TTFT、TPOT 变化时，再检查 API 排队、runtime 配置及存储状态。不要把所有异常都归因于地域距离。
怎样确认结果可用
只比较相同客户端、相同工作负载、相同服务配置和相同测试场景下的成功请求。分别汇总错误数量、网络耗时、TTFT、TPOT 和端到端耗时的中位分布与尾部分布，并保留首次请求和后续请求的分组。
不要根据单次最快请求选择地域。网络与服务耗时同时变化时先重跑；只有服务耗时变化时检查服务层；无法提供目标 GPU 的候选地域则应标记为可用性不满足，而不是延迟较差。
使用前复核
本文步骤根据正文所链接的官方文档整理，未运行或测量任何环境；使用前请对照当前版本复核。