ChatGPT 的/v1/chat/completions 接口流式响应设计有点不科学

[brader]

当启用 stream=true 的时候，以流响应，返回的数据大体如下：

data: {"id":"chatcmpl-6r3B875xFqmzK9lMm8sousVO3iBN4","object":"chat.completion.chunk","created":1678101622,"model":"gpt-3.5-turbo-0301","choices":[{"delta":{"role":"assistant"},"index":0,"finish_reason":nul
l}]}

data: {"id":"chatcmpl-6r3B875xFqmzK9lMm8sousVO3iBN4","object":"chat.completion.chunk","created":1678101622,"model":"gpt-3.5-turbo-0301","choices":[{"delta":{"content":"\n\n"},"index":0,"finish_reason":null}
]}

data: {"id":"chatcmpl-6r3B875xFqmzK9lMm8sousVO3iBN4","object":"chat.completion.chunk","created":1678101622,"model":"gpt-3.5-turbo-0301","choices":[{"delta":{"content":"作"},"index":0,"finish_reason":null}]}

data: {"id":"chatcmpl-6r3B875xFqmzK9lMm8sousVO3iBN4","object":"chat.completion.chunk","created":1678101622,"model":"gpt-3.5-turbo-0301","choices":[{"delta":{"content":"为"},"index":0,"finish_reason":null}]}

data: {"id":"chatcmpl-6r3B875xFqmzK9lMm8sousVO3iBN4","object":"chat.completion.chunk","created":1678101622,"model":"gpt-3.5-turbo-0301","choices":[{"delta":{"content":"一个"},"index":0,"finish_reason":null}}

...

data: [DONE]

每一个 event data 的 json 串，得到的 content 内容仅仅是一个字，看完真觉得浪费流量啊，是否我的调用方式不对呢？有其他的参数或调用方式来避免这种浪费吗？

[string2020]

流量要花钱？

[brader]

@string2020 更多思考的是技术方面的东西，这样 API 的传输效率不好

[orangie]

传输效率不高，但是用户体验确实很好的，追求的是响应时间更短，而不是吞吐量更高，不过感觉其他的 id 和标记可以再简化一下，一个会话用一个简单的 id 。

[string2020]

api 提供商都不在乎的东西你个外人跑来在乎。有这功夫，优化下前端，帮用户省点磁盘内存

[brader]

@string2020 这和我是相关的，我们并不想暴露 token 等敏感信息，不是由前端直接调用的 chatgpt ，中间有一层我们的服务端在代理，所以这情况同样会影响到我们服务端的带宽和响应时间

[Kinnice]

那关闭 stream 呗

[ibegyourpardon]

我认为恰恰是楼主想提供更好的方式和体验，才试图找到更好的方法来优化。
而不是像有的人说的很搞笑，花不花钱，提供商在不在乎。

[ideacco]

这可能是未来一段时间 AI 接口请求的基础“通病”了，因为之前的 ai 接口，不太依靠上下文，所以直接请求即可。而现在是非常依赖上下文的，那你怎么办？就是你想请求的问题，必须是在上线问基础上它才能回答的更好，SO ，现在有些大佬的方案是，每过一段时时间，对上面的问题进行总结（同样使用 gpt 接口）。然后删掉旧的上下文，使用总结后的上下文继续请求。
另外需要 API 接口这边做一些中间件，比如把会话内容存在数据库中，然后前端用的时候可以中间插入或修改某些回话，就像 GPT 网页端做的那样。

[tool2d]

我昨天还想发帖来着，就是很浪费流量。

关键点还不是 data:这种格式，因为这种格式不是 openai 发明的，而是 firefox 发明的。

而是 openai 服务器，无法进行任何的压缩传输！！我试了所有的压缩方法，都没有能开启文本压缩功能（ content-encoding 始终不生效）。

[locoz]

当时抓包看到这返回方式的时候就感觉很蠢...明明可以分开两部分传输，却非要放在一个 json 里返回，导致流量浪费极大。只能说做术业有专攻，做 AI 的并不懂后端和网络。

[brader]

@Kinnice 经测试，关闭 stream ，在提问某些问题的时候，AI 思考需要的时间太久了，响应的 20s 以上，我想用户是无法等待的

[brader]

@ideacco 这里我讨论的不是上下文的问题，请求入参传递的 messages 数组上下文对话，才是你说的东西。
这里质疑的是它的响应报文，该响应报文是单次回答的，只是流式响应的时候，拆分后数据格式太臃肿

[zhang77555]

就是原 API 返回的字符串结果改成了用 stream 返回，方便实现前端单个字吐出来的效果，我做 demo 的时候也是这么干的😂

[string2020]

离谱。大兄弟，传送 10b 和传送 100b 的响应时间差别有多大 有测试过？

[string2020]

服务端的带宽，我想知道你们服务端最大带宽是多少，平常用到了 1%没有？

[brader]

@string2020 作为一个 5 年以上的服务端开发人员，虽然我的大部分菱角和追求都被磨灭了，但我依然很不认可你的这个心态。
一个有一定发展历史的系统，它的 API 接口非常多，不仅仅只这一个，如果每一个接手项目的人，做东西的心态都是：这个接口 100ms 和 150ms 的响应时间有什么区别，没关系、不理他。系统多年堆积下来，整体的响应时间、并发率，是非常堪忧的

[8520ccc]

宽带影响不大吧，自己二次开发一下，然后减少返回的信息就行

[lambdaq]

@brader 你以为这样效率不好。。实际上，gpt 模型就是这样一字一字输出的。。

[brader]

@8520ccc 目前我也是有这方面的想法，就是服务端似乎很少有像 js 解析 Event stream format 数据的扩展包，正打算自己写一个解析工具

[brader]

@lambdaq 我认可这种一字一字输出的行为的，我意思是它的 API 设计，在流传输的时候，传一个字过来，附带大量其它臃肿的信息