feature: 增加流式响应API接口

[Fantast616]

使用线程池原理，基于Flask增加了流式响应API接口，可以使用流式响应API使得用户侧体验更佳，同时可以根据开发者硬件条件动态调整处理队列与等待队列长度，以避免显存不足的问题以及推理速度太慢的问题。

[Cherrysaber]

流式响应API接口用websocket实现更好吧

# 类似这样
for response, history in model.stream_chat(tokenizer, query, history=history):
    msg = await ws.recv()
    # 继续或者暂停
    # 处理相关逻辑

惰性生成

[Fantast616]

我考虑过websocket，但是最终还是选了http的形式实现，个人认为的两个优势和原因：

1. 我个人做应用喜欢将算法侧独立起一个服务，而当算法侧和后端逻辑侧是两个服务的时候，websocket会导致让后端逻辑侧需要维护两头的长连接，即既维护和前端的又维护和算法侧的，更何况有时产品级应用可能需要在后端逻辑侧和前端前再叠加网关等东西
2. 和python直接实现的webui不同，前端在实现打字机效果输出的时候往往会有buffer缓冲区，即和算法侧的数据实时性要求没那么强，不需要利用长连接在算法侧每个推理字符出来的时候就即时接收到，举个例子，前端第一次调用查询接口，得到了100个字符的推理结果，它可以选择在逐渐输出90个字符的时候进行下一次查询调用，再次填满缓冲区即可。可以相对而言减轻服务器维护长连接所带来的成本

不过需要承认的是，http调用的形式确实没有websocket简洁明了。

获取Outlook for Androidhttps://aka.ms/AAb9ysg

---

From: Cherrysaber @.> Sent: Wednesday, March 29, 2023 12:19:23 AM To: THUDM/ChatGLM-6B @.> Cc: Lvkesheng Shen @.>; Author @.> Subject: Re: [THUDM/ChatGLM-6B] feature: 增加流式响应API接口 (PR #266)

流式响应API接口用websocket实现更好吧

类似这样

for response, history in model.stream_chat(tokenizer, query, history=history): msg = ws.recv() # 继续或者暂停 # 处理相关逻辑

― Reply to this email directly, view it on GitHubhttps://github.com/THUDM/ChatGLM-6B/pull/266#issuecomment-1487231300, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AK5ZNREQWJBR52K2ZQQ3QU3W6MFQXANCNFSM6AAAAAAWKYJHSQ. You are receiving this because you authored the thread.Message ID: @.***>

[Vinlic]

Hello，你这个方案是SSE传输嘛？

[Fantast616]

不是哈

发自我的手机

-------- 原始邮件 -------- 发件人： Vinlic科技 @.> 日期： 2023年4月13日周四 中午12:15 收件人： THUDM/ChatGLM-6B @.> 抄送： Lvkesheng Shen @.>, Author @.> 主 题： Re: [THUDM/ChatGLM-6B] feature: 增加流式响应API接口 (PR #266)

Hello，你这个方案是SSE传输嘛？

— Reply to this email directly, view it on GitHubhttps://github.com/THUDM/ChatGLM-6B/pull/266#issuecomment-1506318148, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AK5ZNRDIX6WAA5AVZGMFK6DXA54WLANCNFSM6AAAAAAWKYJHSQ. You are receiving this because you authored the thread.Message ID: @.***>