AI推理链路中的网络重试，原本用于掩盖瞬时丢包、连接切换或下游短暂拥塞，但在多跳调用中很容易从容错机制变成延迟放大器。一次用户请求可能依次经过推理网关、模型服务、知识库、向量数据库和工具接口；如果每一层都独立设置重试，前一层看见超时后再次发起请求，后一层也可能同时重试，最终形成大量重复工作。请求虽然可能成功返回，用户却承担了更长的排队、连接占用和响应等待时间。
先控制重试预算，再谈重试策略
重试设计的核心不是“失败后重试几次”，而是整条链路还能为重试分配多少时间。入口应生成统一的截止时间，并沿HTTP/2或gRPC调用向下传递。下游收到请求后，必须根据剩余时间决定是否值得重试；如果剩余时间不足以完成一次完整调用，应立即失败，而不是继续制造无效流量。
重试责任也应尽量集中。通常由最了解业务语义的边界层决定是否重试，内部服务避免层层叠加。对于非幂等操作、流式响应已经开始传输的请求，重试可能造成重复执行或响应状态不一致，不能仅依据网络超时自动重放。服务网格可以提供请求级重试和超时治理，但必须限制覆盖范围，不能把每个Sidecar都配置成独立的“重试点”。
退避机制同样重要。连续立即重试会与原请求争抢连接、线程和下游容量，应采用递增等待并加入随机扰动，避免大量请求在同一时刻再次冲击故障节点。发生持续性拥塞时，熔断、限流和快速失败通常比继续重试更有效；否则网络重试会把单点故障扩散成整条推理链路的排队问题。
用观测数据判断重试是否在帮忙
每一跳都应记录原始请求、重试次数、最终结果、连接复用和背压事件，并使用请求ID、mTLS身份或追踪标识关联入口到Pod的完整路径。只看最终成功率，会掩盖内部已经发生的大量重复调用。排障时需要同时比较端到端延迟、单跳延迟和重试后的额外耗时，确认慢点究竟来自网络丢包、下游处理，还是策略本身。
稳妥的实施顺序是：先统一截止时间和请求标识，再收敛重试责任，随后为关键链路补充退避、熔断和限流，最后通过灰度观察重试率与整体延迟变化。网络重试不是越少越好，而是必须被限制在可解释、可观测、不会突破全链路时间预算的范围内。