关于设置【模型重定向】的一个提议 about one-api HOT 8 CLOSED

我理解，服务请求过来时，应该是按模型来进行渠道获取的。
重定向则是在向真正上游发送服务时，将服务的模型名改成新的模型名再发给上游。

对应的，key 是模型名。value 是期望发给上游的模型名。

因此，value 里的模型名，应该不需要在模型下拉框里选择，而是可以随意填写。

from one-api.

我理解，服务请求过来时，应该是按模型来进行渠道获取的。 重定向则是在向真正上游发送服务时，将服务的模型名改成新的模型名再发给上游。

对应的，key 是模型名。value 是期望发给上游的模型名。

因此，value 里的模型名，应该不需要在模型下拉框里选择，而是可以随意填写。

改动前的设计是这样的：

1. 管理员更新渠道时，会把所有的【模型】写入 abilities 表
2. 处理前端请求，首先通过 middleware 将 request 中的 model 根据 【重定向】改写为 value
3. 然后从 abilities 表中根据改写后的 model 查询渠道（channel）

所以，重定向的 keys 和 values 都必须写入【模型】字段，才能正常工作（能被写入 abilities 表）。
这在概念上我觉得很容易产生混淆。

改动后

渠道（channel）的【模型】就是指该渠道能够支持的模型。

如果想要为前端扩展支持的模型范围，则通过【重定向】来设置。【重定向】的 keys 仅对前端生效，values 必须出现在【模型】列表内。

我觉得这样的概念是最简单易懂的。

from one-api.

我理解，服务请求过来时，应该是按模型来进行渠道获取的。
重定向则是在向真正上游发送服务时，将服务的模型名改成新的模型名再发给上游。

我觉得不应该，前端想扩展模型，应该通过增加自定义模型实现。

from one-api.

我理解，服务请求过来时，应该是按模型来进行渠道获取的。 重定向则是在向真正上游发送服务时，将服务的模型名改成新的模型名再发给上游。

我觉得不应该，前端想扩展模型，应该通过增加自定义模型实现。

所以分歧点在于：

• 【模型】定义的是面向前端的模型，还是后端 LLM 所支持的模型？
• 【重定向】指的是前端重定向，还是后端 LLM 重定向？

从代码来说，重定向发生于中间件，早于 dispather。以及查询渠道时是基于 abilities 表，而 abilities 表的内容来自于【模型】。因此我倾向于认为【重定向】是前端重定向，【模型】是定义后端所支持的模型。

from one-api.

我理解，服务请求过来时，应该是按模型来进行渠道获取的。 重定向则是在向真正上游发送服务时，将服务的模型名改成新的模型名再发给上游。
我觉得不应该，前端想扩展模型，应该通过增加自定义模型实现。

所以分歧点在于：

• 【模型】定义的是面向前端的模型，还是后端 LLM 所支持的模型？
• 【重定向】指的是前端重定向，还是后端 LLM 重定向？

从代码来说，重定向发生于中间件，早于 dispather。以及查询渠道时是基于 abilities 表，而 abilities 表的内容来自于【模型】。因此我倾向于认为【重定向】是前端重定向，【模型】是定义后端所支持的模型。

或者说，它压根不叫重定向，就叫个重命名算了。
从产品设计还是代码简易性上说，如果希望增加一个模型名，应该是通过自定义模型（并且，自定义模型应该可以全局配置，并且直接可以在渠道里选择，而不是每个渠道里单独通过字符串加，这样才方便复用，也不容易填错）

如果是直接把json字符串key，就直接当作模型，感觉非常奇怪。而且会有2个逻辑，1个是取下拉选择的模型，1个是json的模型，就变复杂了。

from one-api.

我理解，服务请求过来时，应该是按模型来进行渠道获取的。 重定向则是在向真正上游发送服务时，将服务的模型名改成新的模型名再发给上游。
我觉得不应该，前端想扩展模型，应该通过增加自定义模型实现。

所以分歧点在于：

• 【模型】定义的是面向前端的模型，还是后端 LLM 所支持的模型？
• 【重定向】指的是前端重定向，还是后端 LLM 重定向？

从代码来说，重定向发生于中间件，早于 dispather。以及查询渠道时是基于 abilities 表，而 abilities 表的内容来自于【模型】。因此我倾向于认为【重定向】是前端重定向，【模型】是定义后端所支持的模型。

或者说，它压根不叫重定向，就叫个重命名算了。 从产品设计还是代码简易性上说，如果希望增加一个模型名，应该是通过自定义模型（并且，自定义模型应该可以全局配置，并且直接可以在渠道里选择，而不是每个渠道里单独通过字符串加，这样才方便复用，也不容易填错）

如果是直接把json字符串key，就直接当作模型，感觉非常奇怪。而且会有2个逻辑，1个是取下拉选择的模型，1个是json的模型，就变复杂了。

我也赞同应该有一个全局前端重定向的设计，在渠道里做这个是有点奇怪。

所以改动前的原始设计**是这样的：

改动前的代码会容易导致一个误操作，就是如果【重定向】的 keys 如果没有在【模型】里定义，这个【重定向】实际上是不生效的，但是不会有任何提示。

from one-api.

我理解，服务请求过来时，应该是按模型来进行渠道获取的。 重定向则是在向真正上游发送服务时，将服务的模型名改成新的模型名再发给上游。
我觉得不应该，前端想扩展模型，应该通过增加自定义模型实现。

所以分歧点在于：

• 【模型】定义的是面向前端的模型，还是后端 LLM 所支持的模型？
• 【重定向】指的是前端重定向，还是后端 LLM 重定向？

从代码来说，重定向发生于中间件，早于 dispather。以及查询渠道时是基于 abilities 表，而 abilities 表的内容来自于【模型】。因此我倾向于认为【重定向】是前端重定向，【模型】是定义后端所支持的模型。

或者说，它压根不叫重定向，就叫个重命名算了。 从产品设计还是代码简易性上说，如果希望增加一个模型名，应该是通过自定义模型（并且，自定义模型应该可以全局配置，并且直接可以在渠道里选择，而不是每个渠道里单独通过字符串加，这样才方便复用，也不容易填错）

如果是直接把json字符串key，就直接当作模型，感觉非常奇怪。而且会有2个逻辑，1个是取下拉选择的模型，1个是json的模型，就变复杂了。

重定向需求，我最近也需要到。由于我系统是需要存储对应模型的，但是由于上游模型名经常变（版本之类的），每次都洗数据非常不合理，所以需要重定向操作，前端固定

我理解，服务请求过来时，应该是按模型来进行渠道获取的。 重定向则是在向真正上游发送服务时，将服务的模型名改成新的模型名再发给上游。
我觉得不应该，前端想扩展模型，应该通过增加自定义模型实现。

所以分歧点在于：

• 【模型】定义的是面向前端的模型，还是后端 LLM 所支持的模型？
• 【重定向】指的是前端重定向，还是后端 LLM 重定向？

从代码来说，重定向发生于中间件，早于 dispather。以及查询渠道时是基于 abilities 表，而 abilities 表的内容来自于【模型】。因此我倾向于认为【重定向】是前端重定向，【模型】是定义后端所支持的模型。

或者说，它压根不叫重定向，就叫个重命名算了。 从产品设计还是代码简易性上说，如果希望增加一个模型名，应该是通过自定义模型（并且，自定义模型应该可以全局配置，并且直接可以在渠道里选择，而不是每个渠道里单独通过字符串加，这样才方便复用，也不容易填错）
如果是直接把json字符串key，就直接当作模型，感觉非常奇怪。而且会有2个逻辑，1个是取下拉选择的模型，1个是json的模型，就变复杂了。

我也赞同应该有一个全局前端重定向的设计，在渠道里做这个是有点奇怪。

所以改动前的原始设计**是这样的：

改动前的代码会容易导致一个误操作，就是如果【重定向】的 keys 如果没有在【模型】里定义，这个【重定向】实际上是不生效的，但是不会有任何提示。

我简单补充下流程图。

from one-api.

是的，我之前搞错了一点，【重定向】发生在【模型】后，那我关掉吧。

from one-api.