我们总是假装延迟“只是性能问题”，直到它开始损害用户信任、导致事件数量激增，并悄然吞噬预算。原版ADC06准确地将其定义为应用交付问题，因为延迟很少局限于单一层面，而且绝不会安分守己。AI会进一步放大这一问题，使其代价更高，也更难用加载图标掩盖。
原因很简单。AI体验具有交互性，当人们等待一个像对话一样自然的回答时，对延迟的感受会有所不同。页面加载缓慢令人烦恼，而“助手”响应缓慢则会让人觉得系统出了问题。等待时间越长，用户就越容易在心里将系统从“有帮助”重新归类为“不可靠”，根本不需要通过仪表板来确认。
对性能的影响
在传统应用交付中，延迟通常表现为响应时间变长，让应用显得迟缓。用户开始抱怨，NPS下降，转化率受到影响，大家又会像往常一样争论问题究竟出在网络、应用、数据库，还是“云”上。这个问题一直真实存在，但大家也并不陌生，因此团队知道该如何分析。
在AI应用中，延迟给人的感受不再只是速度慢，而是系统能力不足。用户不会把长时间停顿理解为“分布式系统在执行分布式处理”，而会认为系统在犹豫、困惑或出现故障。一旦形成这种印象，往往很难改变。输出最终或许会出现，但由于系统传递的是不确定性而非信心，您已经处于不利局面。
由Token驱动的行为会让问题进一步恶化，而传统应用从未遇到过这种情况。由于每个人都会“以防万一”而不断添加上下文，提示词可能会越来越长；如果不加以限制，模型往往会持续生成内容，导致输出量大幅增加。即使基础设施运行正常，体验仍可能显得缓慢，因为工作量增加了，而不是系统性能下降了。
对可用性的影响
延迟一直是一个披着性能问题外衣的可靠性问题。当某个依赖项响应变慢时，就会触发超时。超时会引发重试，重试会增加负载。负载增加后，一切都会变得更慢，进而形成级联效应。即使从技术上看没有任何组件完全停止运行，整个系统的表现也如同发生了中断。
AI系统尤其容易让延迟演变为可用性事件，因为其组成部分比一般的应用堆栈更多，包括模型端点、网关、编排层、检索服务、工具执行系统，以及通常与请求同步执行的策略实施机制。当其中一个组件的响应开始变慢时，使用体验会以复杂且难以诊断的方式下降。
智能体工作流还会引入另一种故障模式：即使只是延迟，也会让人感觉系统不可靠。在每次用户交互中，智能体往往会执行多个操作，而且由于下一步取决于上一步的结果，这些操作通常按顺序执行。这意味着，缓慢的工具调用不仅会拖慢系统，还会阻碍流程继续推进。当大量会话受阻时，队列会不断积压，并发处理能力会大幅下降，系统也会开始出现类似停机的症状，包括超时、会话中途放弃，以及越来越多看似不合理的用户投诉，而查看追踪记录后便会发现这些投诉事出有因。
对可扩展性的影响
团队往往只关注请求量，而真正的制约因素通常是每个请求的处理时间，因此容易误解AI系统的可扩展性。随着延迟增加，每个会话保持打开的时间更长，占用计算资源的时间也随之延长，从而降低有效吞吐量。
AI带来的可变性会进一步放大这一问题。有些请求很快，有些请求则包含超长提示词、大量检索、长篇输出和多次工具调用。如果按平均值进行设计，长尾情况就会带来严重影响，而在AI系统中，长尾绝非可以忽略不计的误差。尾部延迟将直接影响用户体验，因为用户不会记得系统曾经给出的最快响应。
并发的表现也有所不同。AI工作负载通常具有交互性，并以会话为中心，因此不像无状态API流量那样简单规整。系统必须保留上下文、处理后续请求，并确保体验连贯。如果延迟逐渐增加，系统不仅每秒能处理的请求数会减少，每分钟能支持的对话数也会减少。当产品价值取决于响应速度时，这一区别至关重要。
对运营效率的影响
延迟会给运维带来额外负担，这种影响既在意料之中，又令人恼火。通常，第一反应是增加容量，因为这是见效最快、也最容易证明合理性的手段。第二反应通常是增加缓存，因为这种做法看似巧妙，而且确实可能有所帮助。第三反应通常是增加重试，因为有人希望提高可靠性。结果，系统在不知不觉中将响应缓慢转化为成倍增加的负载。
久而久之，延迟会形成一种运营模式：团队维护交付系统所花的时间超过交付功能所需的时间。AI让问题更加复杂，因为性能涉及端到端流程并跨越多个领域。最终，故障排查需要横跨多个团队、供应商和服务，而这些服务在设计之初并未考虑作为一条完整管道进行统一调试。每次调查都要梳理依赖关系和各环节的耗时，而答案很少是简单的。
缓解延迟问题的实用做法
首要且最重要的实践是将AI交付视为端到端的交付问题，而不是模型问题。如果只优化推理，就如同只改进引擎，却忽略了车流、道路和交叉路口。需要全面考虑从用户输入到最终答案的整个路径，包括调用模型之前和之后的各个步骤。
路由再次成为重要的调节手段，因为AI工作负载对距离和队列深度十分敏感。推理与检索之间的距离很重要，为不同类型的请求选择合适的容量池也同样重要。如果端点负载过高、距离过远，或与响应缓慢的下游依赖项配合使用，那么即使运行状况良好，也未必是合适的选择。当系统繁忙时，智能路由可能决定用户获得的是可用体验，还是系统逐渐陷入崩溃。
自适应资源分配也必不可少，因为AI需求具有突发性且难以预测，单靠容量规划无法应对这一现实。系统需要相应机制，在压力下控制资源消耗，包括请求整形、优雅降级、模型选择策略，以及限制单次交互可触发的编排规模。这些机制不仅用于控制成本，也用于保障稳定性。
结论
延迟一直是应用交付中的基础性风险，ADC06特别指出这一点并非没有道理。AI只是让这一风险更加明显、危害更大，因为AI体验中的延迟会让人觉得服务不可靠，而不可靠几乎比任何其他因素都更容易阻碍用户采用。
如今，如果您正在构建支持AI的应用，妥善处理延迟至关重要：这不仅能让系统表现得更可靠，还能确保系统在实际环境中保持可用、在扩展时避免成本失控，并让运维团队不必长期陷入取证式调试。原有规则依然适用，但后果更加严峻，因为用户会将AI响应时间视为判断系统是否值得信赖、能否正常运行的信号。
详细了解全球组织面临的十大应用交付挑战。
关于作者
Lori MacVittie是F5首席技术官办公室的杰出工程师兼首席技术布道师，在应用交付、自动化战略和基础设施领域拥有深厚的专业知识。无论是为AI智能体定义防护机制、剖析脆弱的多云架构，还是探索可扩展系统的极限，她都善于化繁为简。她在应用开发、IT架构以及网络和系统运维领域拥有30多年的行业经验。加入F5之前，她曾担任技术编辑，并因出色表现获得奖项。 MacVittie拥有计算机科学硕士学位，著述颇丰，出版作品涵盖安全、云和企业架构领域。她还热衷于桌面游戏和电子游戏，并且对奶酪有着毫不掩饰的鲜明见解。
Lori Mac Vittie 的更多博客文章相关博客文章
