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

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

带宽值几个钱？

@zdl0929 是的

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

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

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

方便 scale

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

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

====

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

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

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

====

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

计费透明呗

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

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

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