企业官网建设流程全解析

1. 从两个被混用的词说起：latency 和 delay 到底差在哪

刚入行那会儿，我在一次接口联调会上被这两个词坑过。前端同学说“这个接口 delay 有点高”，后端同学回“latency 已经压到 80ms 了”，两个人各说各的，讨论了半小时才发现说的根本不是一回事。后来我带新人，第一课就是把这俩词掰开讲清楚。这篇笔记就是把我这些年积累的 AI 术语理解整理出来，尤其是 latency、delay 这类高频但极易混淆的词，顺带把 AI 领域里其他几个常被误用的术语一并说透。不管你是刚接触 AI 应用开发的测试工程师，还是已经在做 AI Agent 落地的开发者，这些术语的精确理解都会直接影响你和团队的沟通效率，以及你排查问题时的判断方向。

先说结论：latency 和 delay 在中文里都能翻译成“延迟”，但在工程语境下，它们描述的是不同层面的东西。Delay 更偏向“人为设定的等待”或“信号传输的物理耗时”，是一个相对具体的、可配置的量；而 latency 更偏向“从请求发出到响应返回的端到端时间”，是一个系统性的、需要综合优化的指标。你在 STM32 里写delay(1000)，那是 delay；你测一个大模型 API 从发请求到收到第一个 token 的时间，那是 latency。两者有关联，但绝对不能互换使用。

为什么我要花这么大篇幅讲这两个词？因为在实际的 AI 应用开发和测试中，latency 是核心性能指标之一，而 delay 往往是你排查 latency 问题时会遇到的一个具体环节。搞混了，你的优化方向就会跑偏。比如有人抱怨“AI 聊天响应太慢”，你去优化模型推理速度，结果发现瓶颈其实在网络传输的 delay 上，这就白费功夫了。

提示：在团队内部统一术语定义，比任何技术优化都更能提升协作效率。建议在项目文档里专门开一节“术语约定”，把 latency、delay、throughput、response time 这些词的定义写清楚。

2. AI 语境下 latency 的完整拆解：从你按下回车到看到第一个字

2.1 latency 的三个关键分段

在 AI 应用里，latency 不是一个单一的数字，它是一条链路上多个环节耗时的总和。我习惯把它拆成三段来看：

第一段是网络传输 latency。你的请求从客户端出发，经过 DNS 解析、TCP 握手、TLS 协商，到达服务端，这一段的时间取决于物理距离、网络质量和协议开销。国内访问国内节点，这一段通常在 10-50ms；跨区域访问，可能到 100-300ms。

第二段是服务端处理 latency。请求到达后，服务端要做鉴权、路由、排队、预处理，然后才进入模型推理。如果是大模型，还要考虑 tokenization 的时间。这一段波动很大，轻量接口可能 5ms 搞定，大模型推理可能几百毫秒到几秒。

第三段是首 token 返回 latency。对于流式输出的 AI 聊天场景，用户感知最强的不是完整响应时间，而是“第一个字什么时候出来”。这个指标在业内叫 TTFT（Time To First Token），是 AI 产品体验的核心。

把这三段加起来，才是用户感知到的端到端 latency。你在优化的时候，必须先用工具测出每一段各占多少，否则就是盲人摸象。

2.2 为什么 AI 场景的 latency 特别难压

传统 Web 接口的 latency 优化，套路相对成熟：加缓存、加 CDN、优化数据库查询、连接池复用。但 AI 场景多了一层模型推理，这一层的耗时特性完全不同。

模型推理的 latency 跟输入长度、输出长度、模型参数量、硬件算力都强相关。你输入 100 个 token 和输入 1000 个 token，latency 可能差好几倍。输出更是如此，自回归生成是一个 token 一个 token 往外蹦的，输出 500 个 token 的时间远大于输出 50 个 token。这就导致 AI 接口的 latency 不是一个固定值，而是一个随请求内容变化的分布。

我实测过某大模型的 API，同样的问题问两遍，latency 能差 30% 以上，因为服务端负载、批处理调度、GPU 显存状态都在动态变化。所以你在做 AI 测试的时候，不能只测一次就下结论，必须测 P50、P95、P99 分位数，否则你看到的数字没有代表性。

2.3 latency 与 throughput 的权衡

这里必须提一个容易被忽略的点：latency 和 throughput（吞吐量）往往是矛盾的。你把批处理大小调大，throughput 上去了，但单个请求的 latency 可能变长，因为它要等凑够一批才处理。反过来，你为了压低 latency 把批处理关掉，throughput 就下来了，单位成本上升。

这个权衡在 AI 推理服务部署时特别明显。我见过团队为了追求低 latency，把并发调得很低，结果高峰期请求排队，实际用户体验反而更差。正确的做法是根据业务场景定优先级：如果是实时对话，latency 优先；如果是离线批量处理，throughput 优先。

3. delay 在工程中的真实面目：不只是“等一会儿”

3.1 delay 的两种典型形态

Delay 在工程里主要有两种用法，理解这两种用法能帮你避免很多坑。

第一种是主动 delay，也就是人为设定的等待。比如你在写爬虫的时候，为了防止请求过于密集，会在每次请求后sleep(1)，这就是主动 delay。在嵌入式开发里，delay_ms(100)让 MCU 空转 100 毫秒再执行下一步，也是主动 delay。这种 delay 是你可控的，目的是协调时序或限流。

第二种是被动 delay，也就是信号或数据在传输过程中不可避免的耗时。比如网络抖动导致的额外等待、队列排队导致的处理推迟、中断响应导致的执行延后。这种 delay 不是你主动加的，但它是客观存在的，而且往往是 latency 问题排查中的“隐形杀手”。

3.2 STM32 延时函数卡死：一个经典的 delay 陷阱

热搜词里有个“stm32延时函数delay卡死”，这个问题我太熟了。很多初学者写 STM32 的延时，用的是空循环for(i=0;i<1000000;i++);这种软件延时。这种写法有几个致命问题：

第一，编译器优化会把你的循环优化掉。你写了个空循环，编译器一看这循环啥也没干，直接给你删了，delay 就失效了。解决办法是加volatile关键字，或者用__NOP()指令。

第二，中断会打断你的延时。如果你的延时函数在中断里被调用，而中断优先级配置不当，就可能出现卡死。因为延时依赖的 SysTick 中断可能被更高优先级的中断抢占，导致计数永远等不到。

第三，不同主频下延时不准。你用 72MHz 主频调好的延时参数，换到 168MHz 的芯片上，实际延时只有原来的三分之一。所以正规做法是用 SysTick 或硬件定时器来做延时，而不是靠空循环数数。

这个例子说明什么？说明 delay 虽然看起来简单，但它的实现方式直接决定了可靠性。你在 AI 应用里遇到的 delay 问题，本质上也一样：不是“等”本身有问题，而是“怎么等”和“等的时候发生了什么”没搞清楚。

3.3 AI 应用中的 delay 从哪来

回到 AI 场景，delay 通常出现在这几个地方：

• 限流 delay：你调用第三方 AI API，对方有 QPS 限制，你必须在请求之间加 delay，否则会被拒绝。
• 重试 delay：请求失败了要重试，重试之间通常要加指数退避 delay，避免雪崩。
• 批处理 delay：为了凑批处理，系统会等一小段时间再一起发送，这个等待就是 delay。
• 流式输出 delay：AI 流式返回时，每个 token 之间可能有微小间隔，累积起来就是可感知的 delay。

这些 delay 有的是必要的，有的是可以优化的。关键在于你要能区分：哪些 delay 是设计使然，哪些是配置不当造成的浪费。

4. 用一张表把 latency 和 delay 彻底分清

光讲概念容易忘，我整理了一张对照表，把这两个词在各个维度上的差异列清楚。这张表我放在团队文档里，新人入职第一周就要看。

这张表不是让你背的，是让你在遇到具体问题时能快速定位：我现在讨论的是系统性的端到端耗时，还是某个具体环节的等待时间？定位准了，讨论才有意义。

注意：有些团队会把 latency 和 delay 混用，甚至在同一个文档里前后不一致。遇到这种情况，不要跟着混，主动澄清定义，这是专业素养的体现。

5. AI 术语学习的实操方法：怎么把这些词真正用起来

5.1 建立自己的术语卡片

学术语最有效的方法不是背词典，而是建卡片。每遇到一个新术语，记三样东西：一句话定义、一个你亲身遇到的例子、一个容易混淆的对照词。比如 latency 这张卡片：

• 定义：从请求发出到响应返回的端到端耗时
• 例子：某次排查 AI 聊天慢的问题，测出 TTFT 是 1.2 秒，其中网络占 200ms，排队占 300ms，推理占 700ms
• 对照：delay（人为等待或物理传输耗时）

这样记下来的术语，你永远不会忘，因为它跟你的实际经历绑定了。

5.2 在代码和文档里刻意使用精确术语

我有个习惯，写代码注释和提交信息的时候，刻意用精确的术语。比如变量名用networkLatencyMs而不是networkDelay，日志里打ttft_ms而不是first_token_time。看起来是小事，但坚持三个月，你对这些词的理解会深入一个层次。

同样，在写技术方案和复盘文档时，遇到 latency 和 delay 的地方，停下来想一秒：这里到底该用哪个？想不清楚就查，查完再写。这个过程本身就是最好的学习。

5.3 用测试数据验证你的理解

术语理解得对不对，最终要靠数据验证。你可以做一个小实验：写一个脚本，调用某个 AI API，分别记录 DNS 耗时、TCP 握手耗时、TTFT、总耗时。跑一百次，算出各段的 P50 和 P95。做完这个实验，你对 latency 的理解就不再是纸上的概念，而是有数据支撑的认知。

这个实验我推荐每个做 AI 应用开发的人都做一遍。你会发现很多反直觉的现象，比如 DNS 耗时的波动可能比你想象的大，比如 P95 和 P50 的差距可能有两三倍。这些发现会直接改变你的优化策略。

6. 常见问题与排查技巧实录

6.1 AI 接口 latency 忽高忽低怎么排查

这是最高频的问题。我的排查顺序是这样的：

第一步，确认是客户端问题还是服务端问题。在客户端和服务端分别打点，如果客户端测出来 2 秒，服务端日志显示处理只用了 500ms，那问题在网络上。

第二步，看是不是特定请求才慢。如果长输入慢、短输入快，那是推理耗时随输入增长，属于正常现象。如果同样长度的输入，有的快有的慢，那可能是服务端负载不均或批处理调度问题。

第三步，看时间分布。如果慢的请求集中在某个时间段，可能是那个时段流量高峰。如果随机分布，可能是网络抖动或 GC 停顿。

第四步，看 P99。平均值正常但 P99 很高，说明有长尾请求。长尾往往来自超时重试、冷启动、资源竞争，需要针对性处理。

6.2 delay 设置不当导致的连锁问题

我踩过一个坑：在一个批量调用 AI 接口的任务里，为了防止触发限流，我在每次请求后加了 1 秒 delay。结果一万条数据跑完要将近三个小时。后来改成令牌桶限流加动态 delay，同样的任务 20 分钟跑完。

这个教训是：delay 不是越长越安全，而是要跟实际的限流策略匹配。你先测出对方的限流阈值，然后设计一个刚好不触发限流的 delay 策略，而不是拍脑袋定一个保守值。

另一个坑是重试 delay。早期我用固定 1 秒重试，结果对方服务短暂抖动时，所有客户端同时重试，把对方打挂了。后来改成指数退避加随机抖动，就稳多了。

6.3 常见问题速查表

这张表我放在手边，遇到问题先对一遍，能省不少时间。

7. 我个人的术语学习体会

最后说点掏心窝的话。AI 这个领域术语更新太快，今天学的词明天可能就有新含义。但 latency 和 delay 这类基础术语，恰恰是最值得花时间搞透的，因为它们不会过时，而且贯穿你所有的技术工作。

我的体会是，术语学习的终点不是“知道”，而是“条件反射”。当你看到一个问题描述，能立刻判断出对方说的是 latency 问题还是 delay 问题，能立刻想到该测哪些指标、该往哪个方向排查，那才算真正学会了。这个过程没有捷径，就是多遇到、多记录、多验证。

还有一点，别怕问“蠢问题”。我见过太多人因为怕显得不专业，把 latency 和 delay 混着用，结果沟通成本高得离谱。其实你大大方方问一句“你说的 delay 是指人为等待还是传输耗时”，没人会笑话你，反而会觉得你严谨。技术这行，严谨永远比面子重要。