流式响应:它为何能改善体验,又是如何做到的

看着别人使用聊天式 AI 工具,你会注意到文字一个词一个词地冒出来,仿佛模型正在打字。这就是流式,它是任何 LLM 产品中最具影响力的体验决策之一。耐人寻味的是,流式一点也没让模型变快——产出完整答案的总耗时分毫未变。它改变的是等待感觉起来如何,而在交互式软件里,这种感知往往比那个原始数字更要紧。本文讲清流式为何有帮助、它如何运作,以及构建它的真实代价。

流式解决的问题

语言模型是一次一个 token、按顺序生成文本的。一个长答案确实需要花些时间产出,这没办法绕开——每个 token 都依赖于它前面的那些。一旦答案变长,这就制造了一个体验问题。

没有流式时,用户提交请求后,只能盯着一片空白或一个转圈图标,直到整个答案就绪,然后它一下子全冒出来。对于一段长响应,这可能是一段长得令人不安的沉默,没有任何动静的迹象。答案越长,等待越糟,也越像是应用卡死了。流式正是冲着这一点来的:与其把答案憋到完整才给,不如模型产出一块就交付一块。

为什么感知速度胜过实际速度

无论你是否流式,总生成时间都一模一样。流式改变的是首 token 时间——用户多久能看到有动静——而单单这一个指标,就驱动了大半的体感。

这是界面设计中一条广为人知的原则:当人们得到"进展正在发生"的反馈时,对等待的容忍度会大大提高。一段几乎立刻就开始冒字、用几秒钟滚动而出的响应,会让人感觉灵敏而鲜活,哪怕它完成的时刻和非流式版本一模一样。同样的内容,在同样的总时间后作为一整块寂静地砸下来,则让人感觉缓慢而不确定。流式本质上是一种把漫长而不透明的等待,转换成一段短暂等待加上可见进展的方法——而对交互式产品来说,这种转换价值连城。

流式在概念上如何运作

通常,一次对模型的请求会在生成结束时返回一份完整的响应。而一次流式请求则保持连接打开,随着内容生成,陆续发送一系列增量更新——也就是答案的若干块——直到一个最终信号表明响应已完整。

模型提供方把这暴露为 API 上的一种流式模式;来自 OpenAI、Anthropic 等提供方的文档,会描述具体机制和这些块的形态。在你这一侧,应用会在这些块抵达时读取它们,并把每一块追加到用户所见之处,产生那种熟悉的打字机效果。心智模型很简单:不再是"提问、等待、一次性收下全部",而是"提问,然后收到一连串碎片并随到随显"。流式中所有更难的部分,都源自这一个改变——你现在处理的是一份随时间陆续抵达、而非一次到齐的响应。一次非流式调用是一个原子事件,你要么拥有它,要么没有;而一次流式调用是一个持续的小过程,你必须从头到尾去管理它。这种从事件到过程的转变,在纸面上很微妙,在实践中却很重大,因为它触及你的客户端、你的服务器,以及两者之间的任何一层。

构建流式要付出什么代价

流式不是免费的,假装它免费会导向半成品式的实现。它把复杂度推送到你的整个技术栈里。

• 端到端的管道。 数据流必须熬过每一跳。如果有一台服务器坐在你的客户端和模型之间,它必须随到随转发这些块,而不是把整个响应缓冲下来——那样就把流式的意义给抵消了。每一层都必须是"流式感知"的。
• 更棘手的错误处理。 流式途中失败,比响应开始前失败要麻烦得多。当出问题时,用户可能已经看到半个答案了,你必须决定如何优雅地处理一个不完整的结果。
• 解析部分输出。 如果你需要结构化输出,你会以碎片的形式收到它。在抵达的内容足够多之前,你无法解析其结构,这让任何在响应流动时就对其动作的逻辑都变复杂了。
• 客户端累积。 界面必须平滑地追加新来的碎片、管理滚动,并处理用户在流式途中离开页面或取消的情况。

这些都不是不可逾越的,但都是实打实的工作,也正因如此,流式是一个深思熟虑的选择,而非每个端点的默认项。

何时流式值得——何时不值

流式在交互式、面向人的场景中才配得上它的复杂度。如果有人正看着输出冒出来,尤其是较长的答案,那感知速度的好处很大,通常是决定性的。聊天界面、写作助手,以及任何对话式界面,都是天然的适配场景。

而在几种常见情形下,它是错误的选择。当消费输出的是机器而非人时——一个后台任务、一条数据管道、另一个服务——没人在看 token 冒出来,所以流式徒增复杂度却毫无收益;消费方反正要的是完整结果。当你在能对响应动作之前需要拿到整份结构化响应时,流式毫无意义,因为你无论如何都得等到结尾。而当响应短到几乎瞬时抵达时,等待短得不值得去感受,流式就成了多余的机械装置。诚实的法则是:当有人正看着一个不简单的答案抵达时就用流式,否则就跳过。它的好处随答案有多长、以及有人多直接地在等它而放大——所以用例越交互、越啰嗦,采用流式的理由就越充分。

流式与你系统的其余部分

流式与 LLM 应用的其他部分以一些值得预先料想的方式相互作用。可观测性必须把它考虑进去:首 token 时间成了一个独立的指标,有别于总完成时间,因为它才是用户真正感受到的东西。缓存与流式的搭配略显别扭——一个被缓存的答案早已完整,所以你可能选择即时返回它,而不是重新模拟一个流,这是一个深思熟虑的体验决策。而任何要对完整响应做后处理或校验的环节,都必须等数据流结束后才能干活,这意味着某些逻辑根本无法"边流边跑"。预先知道这些相互作用,能避免流式悄悄破坏它周围的功能。

总结

流式不会让模型变快;它通过把一段漫长的沉默变成即时、可见的进展,让等待感觉更短。这笔交易——总时间不变,感知灵敏度大幅提升——对那些有人正看着不简单答案抵达的交互式产品是决定性的,而在机器消费输出或响应极小之处则毫无意义。代价是穿透你整个技术栈的真实复杂度,从流式感知的服务器,到更棘手的错误处理和部分解析。当有人正看着字词抵达时,就伸手去用流式,端到端地把它构建好,让任何一层都别把数据流缓冲掉;而在其余一切地方,就痛快地跳过它。