跨区域模型推理：网络延迟排查与优化
将端到端耗时拆分为建连、传输与服务端处理，按部署地域、Route 53 路由、Nginx 流式代理、负载均衡和 vLLM 接口逐层定位瓶颈，并给出对应优化方法。
跨区域模型推理出现延迟时，应把端到端耗时拆成建连、传输和服务端处理，定位瓶颈在客户端到入口、入口到 GPU 实例，还是模型服务。GPU服务器租用时，优先把实例放在靠近主要调用方且满足约束的地域，并核对目标地域的 GPU 资源与配额，再检查代理缓冲、负载均衡和流式接口。
GPU服务器租用后：先确认跨区边界
按 AWS 的 Region 与可用区说明，AWS Regions 相互隔离，资源不会自动跨 Region 复制。因此，不能把创建异地实例理解为模型权重、配置和数据已经同步完成。
部署前应核对：
- 主要调用方所在位置及主要访问时段；
- 模型权重、推理配置和业务数据的复制或发布方式；
- 目标地域的 GPU 型号、资源余量和配额；
- 数据驻留、行业要求及其他业务约束。
具体可售资源会变化，应以供应商当前资源页和配额页为准。
网络延迟排查：按阶段记录耗时
先把端到端耗时写成可比较的组成项：
端到端耗时 = 建连耗时 + 请求传输耗时 + 服务端处理耗时 + 响应传输耗时
从主要调用方网络发起相同配置的请求，保持模型、请求内容和流式设置不变，记录连接完成、请求发送、首个响应块、后续响应块及结束时间。重点判读：
- 连接完成前已经耗时较长：检查地域、网络路径和入口；
- 请求已到入口，但首个响应块迟迟不到：检查 Nginx 到 vLLM 的链路和服务端处理；
- 上游持续返回，客户端却成批收到：检查反向代理是否在缓冲响应。
不要仅凭“首字节慢”断定 GPU 性能不足，也不要只看总耗时而忽略响应是否被批量积压。
优化部署地域：缩短路径而不是盲目迁移
AWS 的 Region 选择建议是靠近客户，同时满足法律或其他要求。你应据此比较主要调用方与候选地域，而不是只按 GPU 报价或资源数量选择。
如果使用 DNS 分流，Route 53 的 latency-based routing 说明指出，它会选择对用户时延最低的 Region；但这些数据反映的是用户与 AWS 数据中心之间的时延，资源位于 AWS 之外时，实际结果可能明显不同。公网路由也会随时间变化，因此 DNS 结果只能作为路由依据，最终仍要从真实调用方网络验证。
优化反向代理：避免把缓冲误判为推理慢
根据 Nginx ngx_http_proxy_module 文档，proxy_buffering 默认为 on；设置为 off 后，响应会在收到时同步传给客户端，适合 token streaming/SSE。上游应用也可以通过响应头逐次控制缓冲：
proxy_buffering off;
proxy_read_timeout YOUR_VALUE;
如果只需针对某个响应关闭缓冲，上游可以返回：
X-Accel-Buffering: no
不要直接照抄 YOUR_VALUE。proxy_connect_timeout 与 proxy_read_timeout 的默认值和计时范围不同：前者默认 60s，且通常不能超过 75 秒；后者默认 60s，计算的是连续读取之间的间隔，而不是整个响应的总时长。关闭缓冲只能消除代理端的批量传递，不能缩短物理网络距离。
优化请求分配与容器运行
当模型请求耗时差异明显时，Nginx 的负载均衡说明指出，默认方式是 round-robin，least-connected 在部分请求完成较慢时更公平；round-robin 和 least-connected 都不保证同一客户端始终命中同一服务器。可按后端负载情况配置：
least_conn;
比较请求时记录后端身份，避免把命中了不同实例误认为网络波动。
FastAPI 的容器部署文档要求使用 exec form，以保证优雅关闭并触发生命周期事件；位于 TLS 终止代理之后时，应加入 --proxy-headers：
CMD [ "fastapi", "run", "app/main.py", "--proxy-headers", "--port", "80" ]
如果由 Kubernetes 集群负责复制，FastAPI 的容器建议是每个容器运行单个 Uvicorn 进程，而不是在容器内继续增加 workers。
用 vLLM 接口验证调用链
vLLM 的 OpenAI-compatible server 文档说明，其 HTTP 服务实现 OpenAI Completions API 和 Chat API，接口路径为：
/v1/completions
/v1/chat/completions
其中，/v1/chat/completions 需要 chat template，并忽略 user 参数；/v1/completions 仅适用于文本生成模型，且不支持 suffix 参数。
验证时从主要调用方网络使用相同 endpoint、模型、请求内容和流式设置，分别观察客户端到 Nginx、Nginx 到 vLLM 的响应块到达情况。若上游持续返回而客户端批量收到，应检查缓冲；若上游本身迟迟没有首个响应块，则继续检查服务端处理与资源路径。
常见误区与收口证据
不要在没有分阶段记录时迁移 Region，也不要用调高 timeout 代替定位缓冲或上游停顿。排查结果至少应保留调用方网络、地域、访问时间、接口与请求配置、各阶段耗时、Nginx 设置及后端身份；每轮只改变一个变量，才能判断优化是否真正作用于瓶颈。
本文步骤均整理自正文所链接的官方文档，使用前请对照当前版本复核。