响应流式传输已成为AI应用的默认UX模式，效仿ChatGPT在生成过程中显示部分响应而非等待完整输出。该技术分为两种主要实现：用于简单单向流传输的Server-Sent Events，以及用于复杂工作流（如多智能体系统或代码助手）中双向通信所需的WebSockets。虽然流式传输改善了感知响应性，但它实际上并不会让模型推理更快。

对流式传输的痴迷暴露了对AI应用性能的根本误解。开发者专注于最后一公里——用户看到文本出现的速度——却忽略了真正的瓶颈。模型选择、prompt优化和智能缓存才能带来实际的延迟改善。流式传输只是用更好的UX掩盖了慢响应，这很重要但不应该是你的首要优化。我们见过太多团队实现复杂的流式传输设置，而他们的应用生成一个简单响应仍需8秒。

大多数关于流式传输讨论中缺失的是它增加的基础设施复杂性。SSE需要维护持久连接、处理网络中断并管理跨部分响应的状态。WebSockets更加复杂，需要双向消息处理和连接生命周期管理。对大多数AI应用来说，这种额外的复杂性并不合理——特别是当适当的prompt缓存和模型路由能以更少的工程开销带来更好的性能提升时。

对构建AI应用的开发者建议：在优化实际模型性能之后再实现流式传输，而不是之前。从响应缓存开始，为简单任务尝试更快的模型，并优化你的prompt。流式传输应该是你的润色，而不是性能策略。用户更能注意到2秒和8秒响应之间的差异，而不是在已经很快的响应上的流式传输效果。