AI系统中的延迟可以分解为几个不同的组成部分，理解每个部分有助于诊断实际的瓶颈。首先是网络延迟—请求到达服务提供商服务器并返回响应首字节的往返时间。这通常取决于你与数据中心的地理距离，大约在20-100毫秒之间。然后是排队时间—请求等待GPU可用以处理它的时间。在高峰时段或热门模型上，这可能从零到数秒不等。接下来是预填充时间—模型处理整个输入提示的时间。对于一个包含1000个token的提示，在大型模型上可能需要200-500毫秒。最后，解码阶段开始，你获得第一个token。所有这些阶段的总和就是你的TTFT（首次token时间）。
在第一个token到达后，还有一个同样重要的延迟指标：令牌间延迟，即后续token流速的快慢。这通常以每秒令牌数（tokens per second）来衡量。GPT-4o可能以每秒80-100个token的速度流式传输，而Claude在大多数请求中流速相似。对于聊天机器人来说，每秒超过约30个token时，对人类读者来说感觉是“即时”的—比你阅读的速度还要快。低于每秒15个token时，流式传输开始显得断断续续。这就是为什么一些提供商有时会同时引用TTFT和每秒令牌数—它们衡量的是不同的用户体验瓶颈。一个响应可能开始得很快但流速慢，或者开始稍慢但随后迅速。
提示长度对延迟的影响比大多数开发者预期的更大。对于标准的Transformer模型，预填充阶段的处理时间与输入长度大致呈二次方增长（归功于自注意力机制），因此一个包含10,000个token的提示，所需时间并不只是比1,000个token的提示多10倍—可能会显著更多。这就是为什么像Anthropic这样的提供商对输入和输出token的计费方式不同，以及为什么将整个代码库塞入上下文窗口会带来实际的性能影响。像提示缓存这样的技术在这里帮助极大：Anthropic的提示缓存功能允许你将提示的一部分标记为可缓存的，因此如果你每次请求都发送相同的系统提示（大多数应用程序都是这样），那么这部分的预填充在首次调用后几乎是免费的。
开发者在延迟问题上最常见的错误是在开发阶段使用短提示进行测试，然后对生产环境的性能感到惊讶。一个50个token的测试提示响应时间为300毫秒；而实际生产中的提示包含系统消息、少量示例和对话历史，总共有4000个token，响应时间则需要2秒。另一个容易忽略的问题是地理路由—如果您的服务器位于欧洲，但调用的是美国的API端点，那么每个请求都会增加100-150毫秒的网络延迟。一些提供商提供区域性端点，而更智能的推理代理服务会自动将流量路由到最近的数据中心。对于像语音助手这样的实时应用，总端到端延迟必须保持在500毫秒以下，因此每一个组件都至关重要，最终需要同时优化所有这些组件。