F
Member
站务组整理流式生成的一个工程细节：用户关闭页面或点下停止，并不自动意味着模型推理已经结束。浏览器、网关、应用服务和推理引擎是不同层，连接断开可能只发生在其中一层。如果取消信号没有传递到底，后台仍可能继续消耗计算与上下文资源。
先定义“取消成功”表示什么。它可以表示前端不再展示、应用不再等待、推理请求被移出调度，或资源已经回收，这些状态不能混用。接口应明确取消请求的标识、幂等语义和查询方式；重复取消已结束的任务，应返回可解释状态，而不是触发新任务或报出模糊错误。
流式通道通常经过代理和缓冲。服务端写入成功不代表用户已经收到，客户端断开也可能延迟被发现。应检查心跳、写入失败、应用超时和任务取消的关联，并在每一层保留同一个请求标识。不能只根据页面上的“已停止”按钮状态，就认定底层队列已经清空。
后端还需要处理竞态：取消信号到达时，任务可能刚完成，或者下一段输出已经进入缓冲。应规定结束状态只提交一次，明确最后一段文本是否保留。资源回收包括调度位置、会话状态和临时文件等，不只是关闭网络连接。实际能力取决于推理后端的实现，应在当前部署上核对，不能假定通用协议都支持相同行为。
若生成过程中同时调用工具，取消文本生成不等于撤销已经发生的操作。查询可以停止等待，已提交的外部写入则需要独立对账，不能重新发一次“取消”就当作从未发生。应用界面应区分停止后续工作与撤回既有结果，涉及不可逆动作时尤其不能给出虚假的撤销承诺。
验证建议覆盖生成前排队、生成中、输出完成但连接未关闭等阶段，并观察取消后队列、显存占用和后台任务是否在合理时间内恢复。客户端主动断网、网关超时和用户按钮取消也应分别测试。计费或内部成本统计需要明确截止点，避免用户停止后产生的后台消耗被误算为有效服务。
讨论问题：
1. 当前停止按钮能把取消信号传到哪一层？
2. 取消与正常完成同时发生时，最终状态如何确定？
3. 已发生的工具副作用是否有独立对账，而非随连接一起丢失？
先定义“取消成功”表示什么。它可以表示前端不再展示、应用不再等待、推理请求被移出调度，或资源已经回收，这些状态不能混用。接口应明确取消请求的标识、幂等语义和查询方式；重复取消已结束的任务，应返回可解释状态，而不是触发新任务或报出模糊错误。
流式通道通常经过代理和缓冲。服务端写入成功不代表用户已经收到，客户端断开也可能延迟被发现。应检查心跳、写入失败、应用超时和任务取消的关联，并在每一层保留同一个请求标识。不能只根据页面上的“已停止”按钮状态，就认定底层队列已经清空。
后端还需要处理竞态：取消信号到达时，任务可能刚完成，或者下一段输出已经进入缓冲。应规定结束状态只提交一次，明确最后一段文本是否保留。资源回收包括调度位置、会话状态和临时文件等，不只是关闭网络连接。实际能力取决于推理后端的实现，应在当前部署上核对，不能假定通用协议都支持相同行为。
若生成过程中同时调用工具，取消文本生成不等于撤销已经发生的操作。查询可以停止等待，已提交的外部写入则需要独立对账，不能重新发一次“取消”就当作从未发生。应用界面应区分停止后续工作与撤回既有结果，涉及不可逆动作时尤其不能给出虚假的撤销承诺。
验证建议覆盖生成前排队、生成中、输出完成但连接未关闭等阶段，并观察取消后队列、显存占用和后台任务是否在合理时间内恢复。客户端主动断网、网关超时和用户按钮取消也应分别测试。计费或内部成本统计需要明确截止点，避免用户停止后产生的后台消耗被误算为有效服务。
讨论问题：
1. 当前停止按钮能把取消信号传到哪一层？
2. 取消与正常完成同时发生时，最终状态如何确定？
3. 已发生的工具副作用是否有独立对账，而非随连接一起丢失？