vllm开发的优势
1.环境是现成的
2.已经有了当前打包流程
3.已经有一部分写好的代码
4.不影响与ragflow的流式接口
vllm劣势
1.gpu资源有限，在开发时，ragflow的请求会受影响
2.vllm编译时间较长，CPU满负荷运转，执行pip install -e . 初次要15~20分钟
3.vllm属于推理引擎，与模型的关系很近，未来如果想换vllm版本是无法更换的
open web ui 开发优势
1.open web ui开发不影响现有ragflow的请求，开发环境可以选择windows
2.vllm未来升级，只要open ai api不变，就不用处理
3.前端ui本来就要变，业务上本来就要二次开发open web ui的代码
4.一些功能可以直接对接open web ui，如：统计
5.vllm 和 open web ui的代码都是py的，迁移一定是可以的
6.据官网的文档，open web ui有 “滤波功能”，可以在数据发送到大型语言模型（LLM）（输入）之前或从LLM返回（输出）后修改数据。
Filter Function | Open WebUI
open web ui开发的劣势
1.之前的代码要迁移，不过涉及的代码也不多，目前只有敏感词过滤的逻辑
2.对open web ui不熟悉
3.open web ui作为ragflow的中转站会多一次请求，中间的流式衔接好不好搞尚未可知，但open web ui有滤波功能，或许可以参考
我的想法：选择open web ui
1.与业务贴合近
2.开发不影响推理引擎
3.开发不必非要在linux上，调试直接在windows上
4.AI辅助开发
对比方向：
1、开放模型接口是否可以转移到openWebUI; /v1/chat/completion
a、rag接入
b、第三方开放接口
2、敏感词过滤业务：在openWebUI和vllm的效率、作用、性能【敏感词至少W的量级】是否差别
3、开发工作量：未完成功能的开发难易度，已完成部分迁移的时间
a、一些功能可以直接对接open web ui，如：统计
4、补充其他
open web ui：
接口：
前台向后台请求的接口是 api/chat/completions
后台返回有两种情况：
第一种：异步返回，返回给前端json串，json串中带有taskid，然后走websocket
地址是：ws://localhost:8080/ws/socket.io/?EIO=4&transport=websocket
第二种：同步返回，返回的流协议是sse
接口中区分以上两种的类型就是不传递 session_id、chat_id、message_id三个中的任意一个
影响：
1.同步返回的sse，不会统计模型的用量、用户的动态，不会记录用户与模型的问答
新会话的创建会先调用 http://localhost:8080/api/v1/chats/new 获取chat_id 和 message_id
当传递chat_id 与 message_id，平台只记录对话数量，但没有记录用户对话与tokens数值
注意点：
1.token统计功能，需要在模型设置界面，将“用量”打钩
敏感词业务：
内置过滤函数，但这个过滤函数是open webui提供的一项功能，可以在
写了一个日志打印的filter，sse只看到了入模型前的数据，没有看到从模型出来的数据。
前端：
用的不是vue，是svelte