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 内容仅仅是一个字，看完真觉得浪费流量啊，是否我的调用方式不对呢？有其他的参数或调用方式来避免这种浪费吗？

[UIXX]

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

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

[zhwithsweet]

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

[neotheone2333]

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

[byzod]

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

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

[iseki]

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

[iseki]

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

[superares]

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

[vinciarts]

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

[conn4575]

我觉得 websocket 才是解决方案

[yuhangch]

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

[vinciarts]

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

[brader]

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

[vinciarts]

@brader 原来如此