大模型的 api 为什么设计成无状态的？

[Need4more]

在看 openai 的 messages api ，发现客户端需要做大量得状态管理，来维护历史消息，为什么不和网站 cookie 一样弄个 sessionId 这样的状态字段。另外，聊天场景下，每次请求都携带重复的历史数据，得浪费多少带宽资源！

请问，从技术角度分析这样设计的好处是啥？

这是官方的 python 客户端示例：

[zhlxsh]

无状态的好处，就是不需要保存状态。谜底就在谜面上。

想象一下，你需要给一百个用户提供打扑克的出牌预测服务，每个人的步骤不一样，你需要保存这 100 个人之前出过的所有状态，如果谁中途掉了你还得一直保存，因为说不定他啥时候连上来。

而如果是无状态的，每个人发出的请求里携带之前出过的人牌就可以了，只需要在客户端保存数据，而服务端每次只需要做都是当前状态的分析，结束就是结束了。你的代码只需要做一件事，已知出过的牌和手里的牌，预测最佳的出牌方法

[beyondstars]

国外宽带资源不那么贵吧，然后，无状态便于水平横向拓展？容易 scale up?

[RedNax]

大概是因为和 AI 计算的消耗比起来，那点带宽根本不算钱吧。

[msg7086]

因为有 session 以后横向扩展更难，你需要维护一个 session storage 。

而且在有 session id 的情况下你计算节点不还是要通过网络去 session storage 读取数据？这不还是要带宽？
从用户的网络传历史数据对企业来说并没有多浪费啊。

[neteroster]

你是否在找：Responses API

[neteroster]

@neteroster 不过我不怎么喜欢 Responses API ，感觉整体还是无状态的设计比较好

[Ljxtt]

感觉是因为大模型本身就是无状态的吧。同时上下文是需要成本的，而且上下文大小也是有限制的，你可以自行决定怎么去处理上下文。

[allplay]

@zhlxsh 这样能理解为什么 ai 在最终给出答案的时候才知道自己说出了不该说的话。用户利用这一点还能规避审查。比如让 ai 在答案中插入字符，拼音表示等等，扰乱。

[cowcomic]

这个问题其实技术不是重点
商业模式才是重点，有状态的话，怎么收费

[zx9481]

为了隐私？

[mumbler]

长期记忆太贵了，支持 32K 上下文就需要 150G 显存

[akorn]

因为大模型本来就没状态。所谓的多轮对话和上下文，都是模拟出来的。你给个简单问题，大模型根据简单问题给个回答；给个带上下文的对话，大模型根据这个对话内容，给个回答。模型只有输入、输出的概念，没有轮的概念。这就是为什么 chat 刚出来的时候限制 50 轮对话了，问题超过 50 轮的拼接，大模型一次处理不过来。

[elevioux]

因为 llm 本身就是必须每次都提供完整的上下文，api 的设计只是反映了这一点而已。

当然，各公司也可以在此基础之上再封装一层（ api 或 sdk ），帮用户维护 session ，就看成本了。

对我来说，提供完整上下文反而可能更灵活些，因为有些场景会对用户的输入或上下文进行修改。

[ckvv]

模型有上下文大小限制 1M 都没有

[zdl0929]

你说的就是 Responses API 吧

https://platform.openai.com/docs/api-reference/responses

[wulili]

应该就是出于成本考虑，如果额外加一层历史消息存储得浪费不少资源，那干脆就将问题抛给前端用户了，省时省力。
不过感觉这种 api 设计迟早得改，不然随着以后上下文越来越长，每次带着一坨屎山一样的历史数据传来传去，带宽成本早晚得超过存储成本。

[Yasuke]

没有什么是加一个中间层不能解决的，如果不行，就加两层

[irrigate2554]

无状态好处很多，我举例一个，比如你和 AI 进行了 5 轮会话，这个时候你感觉从第 3 轮开始有些跑偏了，想从第三轮开始重新对话，如果是有状态 API 这个挺麻烦的，要么设计回滚对话的 API 要么重新从第一轮开始进行对话（由于大模型的不稳定性你不一定能得到一样的对话），如果是无状态则很简单，删除 4 ，5 轮的对话记录继续对话就行。

[wnpllrzodiac]

@mumbler 人脑值几百亿了

[jonsmith]

可能是现在的 LLM 上下文不大，做 session 没有必要。等以后上下文越来越大，可能会做了。

[hwdq0012]

热知识：有状态服务可以通过 redis 之类的服务转换为无状态，弹性扩容更方便

[min]

带宽值几个钱？

[Need4more]

@zdl0929 是的

[mumbler]

@wnpllrzodiac #19 人脑内存并不大，验证码超过 6 位都要分至少两次输入，背单词背课文更是困难，一会就忘了，记忆都是极其精简的摘要和画面，上下文不足 1K ，只不过人脑效率高，而且容错率极高，哪怕真错了也可以不承认

[Need4more]

@min
@RedNax
可是他们现在月活都超 5 亿了呀，这么大的流量不考虑带宽成本吗？
个人感觉是历史遗留问题，早期纯文本对话这样设计不是问题，可是现在支持多模态，输入会包含图片、视频、文件了，带宽成本不容小觑！
他们现在也有带状态的 api ，pdf 上传：
https://platform.openai.com/docs/guides/pdf-files?api-mode=responses

[coefu]

今年都加大权重的堆砌记忆能力了，还需要 web 的状态做什么。

[DTCPSS]

方便 scale

[wyntalgeer]

因为状态在应用层，LLM 你把它理解成一个高级算法。你见过给 SDK/工具类/算法库加状态的？

[ipwx]

大模型的上下文是内部的某种 embedding 输出啊。。。

====

这个 embedding 不同模型都不一样，同一个模型的不同版本都不一样。只有精确到某个版本、某个模型，才有可能存储这个真正的上下文。你调用的是通用接口，所以没办法拿到这个真正的上下文，那你只能把 history 再喂给它一遍，让它重新构造出这个内部上下文。

有些模型有 streaming api ，一个合理的实现方法是客户端只存某个 id ，让服务器去存储这个上下文 context 。用 id 去关联 context 。但用户啥时候弃用这个 context ？多长时间过期？这些问题都很麻烦，特别是互联网场景，用户很多的情况下。所以很多 api 不支持 streaming 也很合理嘛。

更何况如果你用着某个上下文，服务器那边模型更新了，瞬间原来的 context embedding 废了，进去就是一堆乱码，用户这不得骂娘，还不如浪费些算力让大模型重新看一遍历史。

====

当然不得不存储 embedding 的场景也是有的，那种就叫做 rag 。这也算是一种折中：让大模型每次都看一遍整个资料库显然计算开销太大了，但是让大模型每次都把所有对话的 embedding 都存下来那存储（和检索）开销又太大了。那么不得已，就采用资料库的 embedding 存起来、对话不存 embedding 。这不是很合理么

[willchen]

计费透明呗

[Leeeeex]

@Need4more #25 5 亿带宽成本高，那 5 亿的状态保存成本就不高了？

[sakeven]

别给无状态 API 找各种理由了，OpenAI 已经在主推 Responses API 了😁

[garyalen]

因为综合来说 显存和运行性能划算 无状态还能吃你 input tokens