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

流量要花钱？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

我昨天也在看这个 stream ，发现比非流式慢很多。
以下理解不知道对不对：
按照官方说法,free-20RPM,credit card (48hrs)-60RPM,credit card (aft 48hrs)-3500RPM
我现在理解是 60RPM 相当于 1s 吐一个字呗，因为它一次请求就返回一个字的内容。非流式只有在 3500RPM 才有实用价值吧。
问 ai ，它解释非流式默认 600RPM ，那的确就是必须绑卡 48 小时后才有实用价值，否则还不如老老实实非流式了。
另外我想说，stream=True 返回的是生成器，不加应该直接可以用 response['choices'][0]['message']['content'].strip(),但是我发现设定 stream=False 返回的也是生成器，不能取值，不知道是不是我方法不对，第一次接触这类。

@brader 其实不臃肿，你试一下用 gzip 流式压缩这些重复字符串，

我这里 60k 左右的文本数据回答，可以压缩到 2k 之内。

就是 openai 把这项特性关了，只打开了 chunk 传输，贼讨厌。

我又想了一下。

既然 openai 在 http 协议上不支持压缩（ accept-encoding: gzip, deflate, br ），那么干脆换个思路，让 openai 用 HTTPS 代理文本内容的时候，用 SSL 开启压缩功能(HANDSHAKE_SERVER_HELLO 里的 compression flag)就可以了。

这样 openai 的服务器代码，也可以不需要改动。

装个锤子，正常开发人员都会知道带宽根本没影响。
你自己一点测试都不做，凭空优化（不，你根本优化不了。api 的代码你都控制不了。凭空要求 openai 优化）。
最好的情况是，openai 帮你做了优化。
最后响应时间从 100ms 优化到了 100ms 。带宽从 1%占用优化到了 1%占用。
你浪费了大家时间。

楼主的意思是用 stream 是好的，但没必要 stream 里每一份 data 都包一个 json ，可以每个 data 就一个内容字符串就行了
我是认同楼主的想法的，json 重复内容太多了

@youthfire "但是我发现设定 stream=False 返回的也是生成器，不能取值，不知道是不是我方法不对"

我这里可以正常取值，就是普通的 json 。

@brader 同意楼主观点，冗余信息过多

离大谱。想到了，父母让女儿找富二代的笑话。

离大谱。想到了，父母让女儿找富二代的笑话。

@string2020 #24 ?? 我都怀疑你是否是开发人员了？又不是只有一个用户在访问，怎么可能没有影响？

可以理解为元数据。做成长连接也得有基础协议的元数据。

@vishun 什么东西。这里说的带宽是指什么你懂吗？

@string2020 #32 说下指什么？

@vishun 这里说的是楼主的服务器和 openai 之间的下行带宽，和用户关系在哪？

像极了人，人说话也是一个字一个字的说(doge

@string2020 如果有 1000k 的用户同时用，中间做日志存储，如果再有实时分析，怎么可能 IO 没影响。带宽不是问题，你这意思是不够用就加硬件呗，反正不是自己花钱。程序员要都是你这想法，淘宝 JD 都不一定能开起来。

大兄弟。在这个提问中，用户就只有楼主自己，占用的带宽是服务器的下行带宽，下行带宽一般情况下免费的 1%都不会用到。你该不会是在为 openai 考虑吧？

你如果抓一下 ChatGPT 的接口，你会发现每个 data 都会重复前面的内容，还不如 OpenAI 的接口省带宽。

```
event: add
id: 1
data: {"message":{"id":"chatcmpl-6rOOU6qBvhphYF8aL0Rw1VMitV5U8","role":"assistant","user":null,"create_time":null,"update_time":null,"end_turn":null,"weight":0,"recipient":"all","metadata":null,"content":{"content_type":"text","parts":["I"]}},"error":null}

event: add
id: 2
data: {"message":{"id":"chatcmpl-6rOOU6qBvhphYF8aL0Rw1VMitV5U8","role":"assistant","user":null,"create_time":null,"update_time":null,"end_turn":null,"weight":0,"recipient":"all","metadata":null,"content":{"content_type":"text","parts":["I'm"]}},"error":null}

event: add
id: 3
data: {"message":{"id":"chatcmpl-6rOOU6qBvhphYF8aL0Rw1VMitV5U8","role":"assistant","user":null,"create_time":null,"update_time":null,"end_turn":null,"weight":0,"recipient":"all","metadata":null,"content":{"content_type":"text","parts":["I'm sorry"]}},"error":null}

event: add
id: 4
data: {"message":{"id":"chatcmpl-6rOOU6qBvhphYF8aL0Rw1VMitV5U8","role":"assistant","user":null,"create_time":null,"update_time":null,"end_turn":null,"weight":0,"recipient":"all","metadata":null,"content":{"content_type":"text","parts":["I'm sorry,"]}},"error":null}

event: add
id: 5
data: {"message":{"id":"chatcmpl-6rOOU6qBvhphYF8aL0Rw1VMitV5U8","role":"assistant","user":null,"create_time":null,"update_time":null,"end_turn":null,"weight":0,"recipient":"all","metadata":null,"content":{"content_type":"text","parts":["I'm sorry, I"]}},"error":null}

event: add
id: 6
data: {"message":{"id":"chatcmpl-6rOOU6qBvhphYF8aL0Rw1VMitV5U8","role":"assistant","user":null,"create_time":null,"update_time":null,"end_turn":null,"weight":0,"recipient":"all","metadata":null,"content":{"content_type":"text","parts":["I'm sorry, I'm"]}},"error":null}
```

(带宽费用)[!https://imgur.com/HT9oEzk]

阿里云都是免费的，不知道要省啥

OP 的问题可以总结为：能否省略或者压缩流式响应中的元数据。

我的看法倾向于 8L 的观点，这个接口输出被设计成通用性更强、结构更明显的 chunk 形式，方便调用者直接使用。将其他形式的输出实现交给二次开发者。

支持 event source / SSE 的接口是这样的，写得时候图省事，直接把数据体写到 response 里边，出来必要的 { event, id data, retry } 别的感觉是能够压缩

楼主想要的应该是类似 pb 的那种形式
上面有的人可能没用过除了 JSON 以外的数据交换格式

虽然但是，ai 答复的后端资源需求是非常高的，传输带宽只是流程上一个优先级非常低的环节，大概率不是性能热点

正经程序员也不会在业务逻辑耗时 2000ms 的时候扭头去想办法把 parser 的时间从 2.5ms 优化到 1ms 吧，虽然这是 60%的性能提升对于这个环节来说

但是这样的 API 对接起来容易

楼主的关注点可能是每个条目都包含了重复的信息，id object 什么的…只能说优化这个挺麻烦，得在现在这种简单的模式基础上再包装一层了

有没有可能一个流就是一个 token ？

弱弱的问一下，为什么要自己服务器转发，而不是直出啊？

我觉得 websocket 才是解决方案

@vinciarts #48 不想暴露自己的 token

@yuhangch 这样的话那直接用 versel 或者 netlify 部署就可以啊

@vinciarts 在目前 ChatGPT 的 API 采用直传 token 的授权形式的情况下，不管你采用什么方式，要么你有服务端代理来授权，要么你直接客户端访问，你隐藏的再怎么好，还是有暴露 token 的风险。
上面只是其中之一原因，最近开始，最主要的原因还是需要代理的问题，被 GFW 墙了

@brader 原来如此

@yuezk 这个设计真是太差了