流式中断处理：用户喊停的优雅退出

可视化演示

展示系统处理流水线、实时性能指标曲线及多方案对比分析，包含数据流转、吞吐延迟监控与方案评估。

中断触发方式

深夜食堂的直播厨房里，客人有三种方式叫停：举手喊“停”、直接起身离开、或者停止观看直播。大厨并不总能立刻知道客人已经离开，他还在按原计划切菜。流式输出也一样——用户想中断大模型生成，可以有三个入口：点击界面上的“停止”按钮、关闭浏览器标签页、或通过代码里的 AbortController 主动取消请求。所谓 AbortController，就是前端向浏览器喊停的哨子，一声令下，底层请求就会被标记为“取消”。

这三种方式分别对应不同的信号来源，但最终都指向同一个目标：让正在进行的请求进入取消状态。点击停止按钮是最直接的用户动作；关闭标签页会销毁页面上下文，浏览器随即取消请求；AbortController 则让开发者能在任意时刻主动调用 abort()，不需要用户真的去点按钮。

在实际代码里，前端通过 fetch 或 XHR 发起流式请求时，通常会挂一个 AbortController。用户点“停止”时，前端先停止把新到的增量文本渲染到界面，再调用 abort()，让浏览器关闭底层连接。服务端收到连接断开或取消标志后，才会真正停止生成。所以“中断触发”从来不是单一路径，而是多个入口合力发出的刹车信号。

就像客人在第三道菜之后喊停，后厨要记住的是“三道菜”这个节点，而不是从头再数一遍菜单。先明确中断从哪个入口、哪个时刻开始，后面所有优雅退出的动作才有一个可靠的锚点。

信号传递与连接关闭

餐厅里客人的喊声并不会自动传进厨房，需要服务员穿过走廊把话带到。流式场景里也一样，用户点击停止后，“取消”这个信号要穿过网络，让服务端真的知道。SSE 和 WebSocket 是两种常见的流式传输通道，相当于传话的两条走廊。SSE 是服务端到客户端的单向长连接，客户端不能往这条连接里发“停止”消息，只能把连接关掉。WebSocket 是双向通道，客户端可以直接发 Close 帧，相当于拿起电话说“我这边讲完了”。

在 SSE 场景下，前端通常用 AbortController 关闭连接。服务端什么时候才能意识到连接断了？答案是：下一次向这条连接写入数据时。如果一个生成任务卡在 GPU 上做长推理，连接断开事件不会立刻打断推理，而要等这次推理返回、服务端尝试写下一个 chunk 时，才会发现写入失败，从而触发取消。WebSocket 的 Close 帧更明确，服务端收到后可以立即把生成任务标记为取消，但也要等当前这一步计算结束才能安全停掉。

这里有一个容易混淆的“半关闭”语义：一端停止发送，但仍然可以接收对方的消息。就像你先说“我讲完了”，但还拿着电话听对方回应。服务端收到 Close 帧后，不能只清理连接对象，还要把正在运行的生成任务标记为取消，否则模型可能继续在后台计算，白白消耗资源。

服务员不用每时每刻盯着客人，而是在端下一盘菜时发现没人接，才知道客人已经离开。流式服务也不必提前预知中断，只要在下一次“上菜”时检查盘子有没有被接住，就能及时收手。

服务端资源回收

大厨接到“别上了”之后，要立刻关燃气、把切好的菜放回冰箱、把占着的灶台腾出来。在 LLM 服务端，这个动作叫资源回收：取消生成任务、释放显存和内存、清理请求生命周期里挂着的各类资源。一次流式请求往往不是一个孤立函数，前端连接、网关、模型推理服务，甚至下游工具调用都串在一起，中断信号必须沿调用链逐层传递。

对大模型来说，最重的资源是推理过程中缓存的中间状态，通常称为 KV Cache。它就像厨师提前备好的半成品食材，堆在灶台一侧。请求一旦取消，这些缓存必须尽快释放，否则高并发场景下，显存会被堆积的“半成品”占满，后面的请求反而排不上队。工程上常用取消令牌或标志位，让生成循环在下一次迭代前看一眼“要不要退出”。

更规范的做法是为每个生成请求分配唯一 request_id，并注册取消回调。中断触发时，取消回调会从任务队列、缓存表和计数器里移除这个请求，让它不再占用 GPU、CPU 和网络连接。这样，一次用户取消不只是“停止输出”，而是把整条链路占用的资源还给系统。

就像没有被及时关火的灶台会把锅烧干，没有被回收的 KV Cache 会让整条推理链路越来越慢。优雅退出的第一步，不是嘴上说“停了”，而是真正把火关掉、把台面腾出来。

Token 计费规则

客人喊停后，侍者要结账。账单既不是按整桌菜算，也不是只收还没上的菜，而是按已经端上桌的菜收费。LLM 的计费逻辑也一样：已经消耗的 token 都要计费。一次请求的 token 分为两部分：输入侧的 prompt tokens，也就是用户输入的提示词；输出侧生成的 completion tokens，也就是模型回答的内容。用户中断时，模型可能已经生成了几十上百个 token，这些字已经消耗了 GPU 算力，所以必须计入账单。

未生成的 token 没有产生计算，自然不计费。但“未生成”的边界要注意：客户端可能只收到了 50 个 token，服务端因为网络缓冲实际生成了 60 个。这种情况下，以服务端实际生成并记录的 token 数为准。因此用户越早喊停，能省下的输出成本越多；但已经发生的算力，不会因为取消而消失。

在工程实现上，流式接口返回的增量数据里通常带有 usage 信息，或在请求结束时返回 token 统计。为了成本控制，我们要把每次增量累计到计数器，而不是中断后重新数一遍文本。还要保存 prompt token 数、已生成 token 数和停止位置，方便账单溯源和用户申诉。

账单不是惩罚，而是算力消耗的镜子。让用户看到“已生成 120 个 token，费用约 0.003 元”，比默默扣费更能建立信任。

部分结果处理

中断之后，已经端上桌的菜不应该被倒进垃圾桶。用户虽然没吃到完整套餐，但已经上桌的几道菜可以继续吃。大模型的输出也一样，已经生成的部分内容是有价值的，应当保存并展示。流式输出的原始数据通常是一串增量块（chunk），每个块里是几个 token。中断时，客户端可能只收到了前 k 个块，需要把这些块按顺序拼接起来，形成当前已生成文本。

拼接时要注意顺序不能乱，尤其涉及流式 JSON、Markdown 代码块时，可能出现残缺的括号或未闭合的代码段。比如用户让模型写一段 Python 代码，中断时可能刚写到 def func():，后面还没有函数体。这种半截代码不是错误，而是“生成到一半”的正常状态，前端要给出完整性提示，避免用户误以为系统故障。

保存策略上，不要让客户端等中断后才一次性向服务端要结果，而应在收到每个 chunk 时就增量落盘，写入内存或数据库。这样即使页面刷新、网络抖动，用户也能立刻看到已生成内容。展示策略上，要明确区分“完整回答”和“中断回答”，用“已停止，内容生成到此处”这类提示，让用户知道边界在哪里。

半成品不是失败品。把已上桌的菜摆放整齐，告诉客人“这是三道菜的进度”，用户会觉得整个系统是体面的，而不是在事故中仓皇收场。

上下文会话管理

客人想继续吃，厨房不能重新买菜、重新点火。他要记得“这位客人之前点过什么、已经上过哪几道菜”。对应到 LLM，就是保留会话上下文，让模型在续接时知道前面说了什么。中断发生时，客户端的对话历史里已经有一条用户的原始消息，还可能有一条 assistant 的部分回复。要继续生成时，不能只把原始 prompt 再发一遍。

正确的做法是把系统提示词、用户消息、已生成的 assistant 部分一起放进新的请求。这样模型续写时能接着“本周完成了流式中断模块”往下写，而不是重新开始讲一遍。断点续接的本质是状态恢复：用户说“继续”，前端把保存的 partial_text 和原 prompt 拼成新的对话上下文，发送给模型，模型从中断处继续。

上下文管理还要考虑上下文窗口和会话过期。已保存的部分结果要设置生命周期：短时间内的“继续生成”可以复用；超过一定时间或用户主动关闭会话，就要清理，避免占用存储和 context 空间。系统可以通过会话 ID 关联消息，也可以记录最后活跃时间，定期把过期会话归档或删除。

像保留点菜单一样保留上下文，用户隔几分钟回来说“继续”，系统就能无缝接上；如果这单太久没人认领，再把菜单收进文件柜，等下次重新点菜。

产品交互体验

优雅退出还差最后一块拼图：让客人看见“厨房已经收到指令、现在是什么状态”。好的服务员不会在客人喊停后消失，而是告诉他“已经上了三道菜，剩下两道退掉了”。产品交互上，要有明确的停止态提示：显示“已停止生成”、保留的部分内容、本次已消耗的 token 和费用，以及“重新生成”按钮。

对成本较高的长文本请求，可以在用户点击停止时加一次二次确认，防止误触。停止按钮也不应紧挨着“发送”按钮，否则很容易手滑。产品设计上，要区分“主动停止”和“被动断开”：主动停止有明确的状态和账单；被动断开要提示用户“连接已断开，已生成内容已保存”，并提供恢复入口。

从工程角度看，产品交互是中断流程的最后一环：中断信号触发后，前端要更新按钮状态、隐藏加载动画、展示部分结果；后端要上报取消事件、写入计费日志。产品经理可以把“用户平均取消率”“取消后会话续接率”当作体验指标，持续优化防误触和续接入口。

服务员的一句“好的，马上停”，比沉默的等待更让人安心。产品交互就是把这份安心做成可见状态：让用户知道自己的喊停被听见、被处理、被记录。

AI 应用场景

Python 演示

import time  class StreamingSession:    """模拟一个支持中断和续接的流式生成会话."""     def __init__(self, prompt, price_per_token=0.02):        self.prompt = prompt        self.partial_text = ""        self.generated_count = 0        self.billed_tokens = 0        self.price_per_token = price_per_token        self._stopped = False     def request_stop(self):        self._stopped = True     def _bill(self):        self.billed_tokens = len(self.prompt) + self.generated_count     def stream(self, chunks):        try:            for chunk in chunks:                if self._stopped:                    break                self.partial_text += chunk                self.generated_count += 1                yield chunk                time.sleep(0.05)        finally:            self._bill()     def resume(self, chunks):        self._stopped = False        try:            for chunk in chunks:                if self._stopped:                    break                self.partial_text += chunk                self.generated_count += 1                yield chunk                time.sleep(0.05)        finally:            self._bill()     def cost(self):        return round(self.billed_tokens * self.price_per_token, 4)  def main():    session = StreamingSession("请写一份周报", price_per_token=0.02)    chunks = ["本周完成", "了流式", "中断模块", "联调", "下周计划", "做性能", "压测"]     gen = session.stream(chunks)    for token in gen:        if session.generated_count >= 3:            session.request_stop()            gen.close()            break     print("已保存部分结果:", session.partial_text)    print("已计费 token 数:", session.billed_tokens)    print("当前费用:", session.cost())     for token in session.resume(chunks[3:]):        pass     print("续接后的完整结果:", session.partial_text)    print("最终费用:", session.cost())  if __name__ == "__main__":    main()

1. self.partial_text += chunk每收到一个增量块就存进半成品文本，中断后不会丢内容。
2. if self._stopped: break每次产出新块前检查取消标志，用户喊停就立刻退出生成循环。
3. gen.close()关闭生成器，触发 finally 里的记账逻辑，让计费立即生效。
4. self._bill()按“prompt 长度 + 已生成数量”更新计费，未生成的块不计费。
5. session.resume(chunks[3:])用保存的上下文继续生成，模拟用户说“继续”后的断点续接。

常见误区

面试题