流式响应能降低模型成本吗？先分清首字延迟与总耗时
流式主要改善等待体验
流式响应让客户端在模型完成全部输出前逐步收到内容，因此通常可以降低用户看到第一段结果的等待时间。它不自动减少生成的 Token，也不保证总任务耗时更短。成本取决于实际模型调用、输入输出、缓存及服务规则，不能把“边生成边显示”理解成免费优化。
需要区分首字延迟、完整生成耗时和用户可完成任务的时间。首字更快但答案反复修改或没有依据，仍然可能降低实际体验。
服务端与代理都可能缓冲
常见方案使用 Server-Sent Events 或其他分块传输方式。后端应及时读取上游并向客户端刷新，反向代理与压缩配置也可能影响数据何时到达浏览器。浏览器看到一次性输出时，不一定是模型没有流式生成。
排查可分别记录上游首块到达、服务端发出和浏览器收到的时间，定位缓冲所在层。不要只根据前端动画判断链路是否真正流式。
客户端断开后怎么办
用户关闭页面或点击停止时，服务端应把取消传播到上游，释放连接和任务资源。但取消不是时光倒流：已经完成的生成可能仍按服务规则计费，有副作用的工具调用也不会自动撤销。
应用需要区分完整完成、用户取消和异常中断。把半截回答保存为“成功”会误导后续会话；直接重试整个任务，也可能重复执行工具或多算费用。只有可安全重试的步骤才能自动重试。
结构化内容别急着执行
自然语言可以逐段展示，但工具参数或 JSON 对象可能直到结束才完整。不能在收到部分字段时就触发支付或写数据库。先缓冲对象，等响应结束并经过结构与业务校验，再执行实际操作。
流式内容还需要正确编码和转义，避免把模型生成的 HTML 直接当作可信页面。展示层与执行层应保持清楚边界。
怎样验证体验和成本
使用相同任务对比流式与非流式，分别记录首块时间、总耗时、输入输出用量和中断情况。再模拟慢客户端、代理缓冲和网络断连，检查取消传播、资源释放和状态显示。服务返回用量的时机可能不同，统计应支持完整完成与异常结束两种情况。
本文没有做模型性能或费用对比，不给出提升百分比。面试时可以说明：“流式优先改善感知延迟；实际成本要计量；断连和副作用必须单独处理。”这比简单回答“开流式就会更快更便宜”更准确。