第二次机会也消耗真实资源
企业应用要求AI分析文档。响应太慢，客户端超时重试；中间服务和调用模型的库也会重试。昂贵组件最终收到多少次执行？随机等待能解决吗？三个小型可验证实验分别研究理论可靠性、调用倍增与时间分布，说明每种机制能保证什么，以及哪些问题仍需实测。
摘要。对独立失败概率q与最多N次总尝试，推导期望成本和成功概率。放弃独立假设后，三层各耗尽三次尝试可让一个原始请求产生27次末端调用。100个初始请求配置20次重试、无补充预算，总尝试不超过120。最后100个客户端以固定种子在100毫秒内分散一轮重试，10毫秒分箱峰值由100降至14，总重试仍为100。这是已执行的教学计数，不是服务器或EL-AI产品基准。
先计数：尝试不等于重试
一次尝试是实际调用，重试是第一次之后的尝试。N=3始终表示一次初始加最多两次重试。原始请求是用户目标，可能产生多次调用。区分这些概念可避免跨层计数错误。本文成本仅指尝试数，不是费用、处理token或GPU秒，也不假定供应商计费规则。
Marc Brooker于2019年为AWS撰写的技术指南区分超时、递增等待、随机化与重试限制，并讨论跨层放大。这是有记录的运营经验，不是本文复现的AWS实验。我们以明确假设隔离若干数学效应，不把SDK设置当作所有AI服务的通用行为。实际表现取决于错误语义、取消与资源。
有利情形：独立失败
先假设每次调用以相同概率q失败，且彼此独立；成功后停止。到达第二次需要第一次失败，概率q；到达第三次需要连续两次失败，概率q²。期望尝试数等于到达各次尝试的概率之和，因为仅实际到达时才增加一次计数。公式解决的正是这个问题。
A为无量纲计数，N为总上限，q在0和1之间。q=.5、N=3时，期望1+.5+.25=1.75次，成功概率.875；这不是单个请求实际调用1.75次，而是重复过程的理论均值。q=.9时，期望2.71次仅得到.271成功概率。接近总失败时增加尝试意味着低收益高负载。若重试通过负载改变q，公式就不再描述系统，不能据此预测真实故障。
| q | N | 期望尝试 | 成功概率 |
|---|---|---|---|
| 0.1 | 3 | 1.11 | 0.999 |
| 0.5 | 3 | 1.75 | 0.875 |
| 0.9 | 3 | 2.71 | 0.271 |
三层：三如何变成二十七
现在采用确定性的全失败情形：下层耗尽尝试后上层才知道失败，没有取消。外层三次，每次触发中层三次，每个中层再触发末层三次，共3 × 3 × 3=27。附件递归函数枚举调用树，不随机抽取故障，也不使用上一模型的q。
D统计会重试的层，不是全部软件步骤。只有一层重试时，同一模型计数变为3。这不证明最高层重试总最优：重跑整个流程可能重复已成功工作，局部重试也可能仅恢复一个低成本步骤。因此策略要考虑完整路径。调用者超时后仍运行的工作可能重叠，本顺序调用树没有测量它。
预算限制次数，不保证成功
取100个初始请求，各最多3次，另设共享20个仅供重试的token。窗口内不补充，每次重试原子消耗一个token；初始尝试不消耗。总数最多100+min(20,100 × 2)=120，全失败无预算时为300。代码执行简单分配：100次初始失败，随后20次第二调用也失败；80个请求拿不到第一次重试，任何请求都没有第三次尝试。
120是准入性质，不是服务器容量测量，所有请求仍可失败。十个进程各有20个本地token，可能准入200次，并非全局20。真实系统需规定范围、补充、并发及计数器不可用行为。无补充模型不是完整令牌桶仿真，所选顺序也不保证客户公平；负载限制与优先级解决不同问题。
随机等待：分散人群而不减少人数
第三个实验中100个客户端各重试一次。固定等待100毫秒使到达同步；full jitter从0到100毫秒均匀抽取延迟。使用Python 3.14.0的random.Random、种子20261017，保存全部延迟。10毫秒分箱计数为9、7、9、12、14、14、7、11、6、11，峰值14。固定等待则在100毫秒起始箱集中100次。两种策略总重试都为100。
公式可扩展至多轮：首次重试k=0，B₀与上限B_max单位毫秒。实际只执行B₀=100的一轮，没有测量指数序列后的恢复。均匀延迟均值50而非100毫秒，仅比较峰值会隐藏等待差异。没有仿真队列、服务时间、负载相关错误或模型延迟。每箱14次到达不等于14次同时执行，也不保证99分位改善。
截止时间属于整个任务
单次超时不等于任务截止。三次各最多200毫秒，加50与100等待，最坏750毫秒，尚未含其他成本。若调用者只给600毫秒，两次失败及两次等待已用550，只剩50而非200；第三次须适配剩余时间或不准入。这是模型上界，不是实测。排除DNS、连接或正文读取的计时器不自动等于端到端时间。
AI服务还涉及取消：客户端不再等，不证明GPU已停止生成，重试可能重复仍在进行的工作。操作会修改数据或触发动作时，超时也不证明没有副作用。正确性需幂等语义或结果协调，本文未实现。限制重试可保护资源，但不能让重复修改自动安全；等待也不会自行修复凭据或模式错误。
一个种子不是保证：峰值概率
14是已保存随机序列的结果，不是方法的保证上限。理想模型中十个箱任一至少25次到达的概率多大？各客户端独立以.1概率选择一个箱，单箱计数X服从100次、成功概率.1的二项分布。十个箱的计数却不假定独立，因为总和固定100。这个区别避免无依据地相乘概率。
二项系数统计哪些j个客户端选择此箱，后两个因子表示进入与不进入的概率。程序累加25至100，单箱约.0000130728。联合上界对十个风险求和，得任一箱达到25次的概率不超过.000130728，约.0131%。这不是故障概率，因为服务器容量未知。结论只适用于独立均匀抽样及固定分箱；共享随机序列、粗粒度计时器或额外重试会改变模型。
证据分三层：峰值14是本序列可复现数值观测；均值10与概率上界来自分布假设；能否避免真实过载仍需实证，因为服务时间与资源未建模。区分这些层次可避免把整齐仿真变为运营承诺。箱宽也改变所计峰值，比较必须保持指标定义一致。
真实服务仍需验证什么
三个实验刻意分开：没有把独立q连接队列，也没有把峰值14换算成功率。实际比较需原始到达、调用时长与成本、取消传播、错误代码及各层真实策略。未来测试需区分完成的用户请求与尝试、有用与重复工作、均值与分位、恢复与过载。这是未来测量要求，不是EL-AI或供应商结果。
当恢复有现实可能且额外成本适配资源与期限时，重试才有帮助。随机等待分散到达，预算限制次数，协调策略避免不知情的跨层倍增，三者不能互相替代。可检查的计数支持这一分离：峰值较低仍可能总工作过多，有预算也可能一个请求都未完成。
from experiment import expected, nested
print(expected(.5,3), nested(3,3))代码、数据与说明 · JSON. 教学计算使用 Python 3.14.0，图使用 Matplotlib 3.11.2。分析由 AI 辅助，不声称经过同行评审或人工审核。原创 ImageGen 封面仅作示意，不记录 EL-AI 人员、场所或实际安装。来源查阅于 2026 年 10 月 17 日。