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

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

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

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

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

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

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

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

你是否在找：Responses API

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

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

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

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

为了隐私？

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

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

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

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

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

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

你说的就是 Responses API 吧

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

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

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

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

@mumbler 人脑值几百亿了

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