跳到主要内容

42 篇博文 含有标签「latency」

查看所有标签

智能体加载状态难题:为 45 秒的 UX 深渊进行设计

· 阅读需 12 分钟
Tian Pan
Software Engineer

你的产品在第 10 秒到第 45 秒之间存在一个“空洞”,在这个时间段内,你设计的任何东西都不再起作用。用户在 10 秒左右就会放弃无响应的 UI —— Jakob Nielsen 在 90 年代就确定了这个阈值,现代的眼动追踪研究显示的偏差也不过一两秒。现代智能体(Agent)的工作通常需要 30 到 120 秒。多步规划、检索、几次工具调用,可能在最终输出前还要经过一轮反思 —— 延迟预算不再只是预算,而是一个巨大的深渊。

大多数团队在第一次发布智能体功能并查看会话录像时都会发现这一点。用户疯狂点击提交按钮。他们将查询粘贴到第二个标签页中。他们关闭窗口并从头开始重试,坚信系统已经崩溃。功能本身没问题,但等待过程出了问题。“加载动画出现”与“答案送达”之间的空白地带是 AI 产品设计中最被忽视的环节,而它正是决定用户认为你的智能体是聪明还是死机的关键。

热路径与冷路径 AI:决定你 p99 延迟的架构决策

· 阅读需 12 分钟
Tian Pan
Software Engineer

你发布的每一个 AI 功能,在成为产品决策之前,都首先是一个架构选择:这个模型调用是发生在用户的请求链路中,还是在用户无需等待的地方运行?这个选择通常由编写第一个原型的人做出,之后便不再被审视,并默默地决定了该功能在余下生命周期中的 p99 延迟。当事后分析(Post-mortem)询问为什么生产环境仪表盘在每周一上午 10 点变得无法使用时,答案几乎总是:某些本应属于冷路径(Cold-path)的东西被焊死在了热路径(Hot-path)中——而在 p50 时表现良好的模型,在流量扇出(Fan out)时,其 p99 的表现会变得极具灾难性。

热路径与冷路径的区别比 LLM 还要早。CQRS、流式架构、Lambda 架构——它们都在“必须立即响应”和“可以最终送达”之间划定了相同的界限。AI 工作负载的不同之处在于,走错方向的代价比以前高出了一个数量级。一个耗时 50 ms 的同步数据库查询变成 200 ms 是一次回归(Regression)。而一个在 p50 时耗时 1.2 秒的同步 LLM 调用在 p99 时变成 11 秒,则是你无意中做出的一项商业决策。

没人调校的 max_tokens 旋钮:将输出截断作为成本杠杆

· 阅读需 12 分钟
Tian Pan
Software Engineer

检查你代码库中每一次 LLM 调用里的 max_tokens 参数。如果你和大多数团队一样,这个参数要么没设置,要么设成了模型的最大值,或者是半年前随便选的一个像 4096 这样的整数,之后就再也没动过。它是 API 请求中一个显眼的预算旋钮,却在默默地为你从未使用过的冗余买单。

在中等商业模型上,输出 token 的成本大约是输入 token 的四倍,而在昂贵模型上甚至高达八倍。生成步骤的经济效益完全是失衡的:你在 max_tokens 中留下的每一分未使用的余量,都是你可能需要支付的成本;而且由于解码是顺序进行的,你生成的每一个 token 都会线性地增加你的 P50 延迟。然而,大多数生产系统都将此参数视为安全阀——设置得高高的,然后忘掉它,继续开发。

设计不拖垮延迟的 AI 安全层

· 阅读需 10 分钟
Tian Pan
Software Engineer

大多数团队引入护栏的方式,和引入日志一样随意:直接挂上去,以为代价很小,然后继续往下走。但代价并不小。一次内容审核检查要花 10–50ms,再加上 PII 检测,又是 20–80ms;再叠上输出 schema 校验和毒性分类器,在第一个 token 到达用户之前,串行开销就已累积到 200–400ms。加上 500ms 的模型响应,你那个"快速"的 AI 功能现在给人的感觉就是迟钝。

把锅甩给 LLM 是错的。护栏才是瓶颈。解决方案不是去掉安全措施,而是停止把安全检查当成一堆无差别的任务,改用架构思维来对待它。

语音 AI 生产落地:构建 300ms 延迟预算

· 阅读需 12 分钟
Tian Pan
Software Engineer

大多数构建语音 AI 的团队都会以同样的方式发现延迟问题:在生产环境中,面对真实用户。演示 (Demo) 感觉不错。原型 (Prototype) 听起来也令人印象深刻。但当有人在实际通话中使用它时,会觉得它很机械——不是因为声音不好听,而是因为每次回复前的微小停顿让整个交互感觉像是和卫星信号不好的人在说话。

这种停顿几乎总是在 600 毫秒到 1.5 秒之间。而目标是低于 300 毫秒。这两个数字之间的差距解释了语音 AI 系统实际构建方式的一切。

AI 流水线中的投机执行:通过押注未来降低延迟

· 阅读需 13 分钟
Tian Pan
Software Engineer

大多数 LLM 流水线在无意中表现出了令人尴尬的顺序执行特征。一个智能体调用天气 API,等待 300 ms,调用日历 API,再等 300 ms,调用流量 API,再次等待 —— 最后才综合出一个答案。如果这三个调用是并行运行的,那 900 ms 的总延迟本可以缩减到 300 ms。没有人故意将系统设计成顺序执行;这只是在编写一个接一个的异步调用时自然而然产生的结果。

推测执行(Speculative execution)是一系列技术的统称,这些技术通过在你确定需要某些工作之前就提前执行它们,来降低感知的延迟 —— 包括运行并行的假设、预取可能的后续步骤以及同时生成多个候选输出。这些技术直接借鉴了 CPU 设计,自 20 世纪 90 年代以来,处理器就一直在推测性地执行未来的指令。应用到 AI 流水线时,这种本能 —— 押注可能的结果、取消失败者、接受偶然的浪费 —— 可以产生显著的加速。但如果你不小心选择应用时机,协调开销也可能会抵消所有的收益。