labring
可视化方式注册模型
例行检查
- [x] 我已确认目前没有类似 features
- [x] 我已确认我已升级到最新版本
- [x] 我已完整查看过项目 README，已确定现有版本无法满足需求
- [x] 我理解并愿意跟进此 features，协助测试和提供反馈
- [x] 我理解并认可上述内容，并理解项目维护者精力有限，不遵循规则的 features 可能会被无视或直接关闭
功能描述 通过可视化方式进行模型的注册和配置，现在只能通过本地配置文件进行设置，不够灵活。
应用场景 方便进行第三方模型的注册，避免本地文件配置容易带来的语法错误问题。
相关示例
没这个计划，和项目定位不符合。不希望用户自己绑定模型，而是由管理端提供少量稳定模型。
本身就是管理端应该干的事情，而且现在人工去修改JSON文件，特别的不方便（尽管少量），还得重启，可视化配置更便于管理。
没这个计划，和项目定位不符合。不希望用户自己绑定模型，而是由管理端提供少量稳定模型。
本身就是管理端应该干的事情，而且现在人工去修改JSON文件，特别的不方便（尽管少量），还得重启，可视化配置更便于管理。
😂主要是开源版没管理端，只能放配置文件里。
而且已经用了 oneapi，感觉没啥好配置的了。这块我以前想直接从 oneapi 拉取模型，但是由于 oneapi 只有开源版，这块需求作者排不上。
没这个计划，和项目定位不符合。不希望用户自己绑定模型，而是由管理端提供少量稳定模型。
本身就是管理端应该干的事情，而且现在人工去修改JSON文件，特别的不方便（尽管少量），还得重启，可视化配置更便于管理。
😂主要是开源版没管理端，只能放配置文件里。
而且已经用了 oneapi，感觉没啥好配置的了。这块我以前想直接从 oneapi 拉取模型，但是由于 oneapi 只有开源版，这块需求作者排不上。
我也有这种想法，不过fastgpt需要的llm配置太复杂了，让one api提供这样一个接口也有点不太合适
没这个计划，和项目定位不符合。不希望用户自己绑定模型，而是由管理端提供少量稳定模型。
本身就是管理端应该干的事情，而且现在人工去修改JSON文件，特别的不方便（尽管少量），还得重启，可视化配置更便于管理。
😂主要是开源版没管理端，只能放配置文件里。 而且已经用了 oneapi，感觉没啥好配置的了。这块我以前想直接从 oneapi 拉取模型，但是由于 oneapi 只有开源版，这块需求作者排不上。
我也有这种想法，不过fastgpt需要的llm配置太复杂了，让one api提供这样一个接口也有点不太合适
其实没啥配的。唯一特殊的就是分类（是否用于知识库，用于问题分类，用于内容提取），是否支持函数调用、最大上下文这种都是模型本身的，完全可以从OneAPI 拉取这些通用配置，然后自己再加上点特殊的就行。
没这个计划，和项目定位不符合。不希望用户自己绑定模型，而是由管理端提供少量稳定模型。
本身就是管理端应该干的事情，而且现在人工去修改JSON文件，特别的不方便（尽管少量），还得重启，可视化配置更便于管理。
😂主要是开源版没管理端，只能放配置文件里。 而且已经用了 oneapi，感觉没啥好配置的了。这块我以前想直接从 oneapi 拉取模型，但是由于 oneapi 只有开源版，这块需求作者排不上。
我也有这种想法，不过fastgpt需要的llm配置太复杂了，让one api提供这样一个接口也有点不太合适
其实没啥配的。唯一特殊的就是分类（是否用于知识库，用于问题分类，用于内容提取），是否支持函数调用、最大上下文这种都是模型本身的，完全可以从OneAPI 拉取这些通用配置，然后自己再加上点特殊的就行。
这种也是可以的，我主要的点在于可视化配置。
我现在使用一种简单的方法，在fastgpt中增加一个读写配置的api，然后在one-api中增加一个修改配置的页面，相当于在线修改配置文件。
不知道你是否有兴趣给他提个 pr👀