[Feature] 为支持多类型请求的渠道增加自动的渠道类型切换功能

[Doraemonsan]

验证步骤

• 我已经阅读了 README.md，确认了该功能没有实现
• 我已在 Issue 中寻找过我要提出的功能请求，并且没有找到
• 此Issue仅包含一个功能请求，而不是多个功能请求

描述

当前版本在使用支持多种API兼容的渠道时无法智能的切换上游API所支持的API类型，例如阿里云同时支持 Completions API (https://dashscope.aliyuncs.com/compatible-mode/v1) 和 Responses API (https://dashscope.aliyuncs.com/api/v2/apps/protocols/compatible-mode/v1) 虽然从官方给出的说明文档中两个API的调用路径不同，但是实际测试两个端点都同时支持两种调用方法，唯一的不同是 Responses API端点不支持 /models 路径，而且阿里云对于不同的调用方法支持的模型是不同的，如 deepseek-v3.2 两个端点使用 Responses 方法都无法调用该模型，只能使用 Completions 方法调用，而有的模型又可以同时使用两种方法调用，所以我希望可以设置渠道支持的API类型并按照优先级排序，检测到模型调用失败而自动回退到低优先级的API类型，而不是一个渠道只能选择一个支持的API类型；目前只能通过添加相同渠道不同的API类型来暂时解决该问题，但是这样的办法也有一定问题，如 Responses API 端点不支持模型获取，即使先获取了模型ID再手动编辑保存ID也会存在大量重复，在渠道模型ID较多的情况下根本没有办法快速判别哪些模型支持使用什么方法调用，手动编辑模型ID在这种情况下不易操作，所以希望增加此功能。

附：阿里云API端点区别

支持的路径	Completions API	Responses API
/models	YES	NO
/chat/completions	YES	YES
/responses	YES	YES

[bestruirui]

你的意思是通过 Completions API 的 /models 接口获取到的模型,实际上可能不支持 Completions API 而是仅支持 Responses API ?
所以在请求时需要两种都尝试一下?

[Doraemonsan]

对的，粗略就是这个意思，实际上从/models获取到的模型列表不一定就支持当前的渠道类型设置，主要还是部分模型提供商同时支持多种API类型，但是实际调用模型的时候不同模型对不同API的调用方式支持度不一样，这时候增加一个选项设置，控制提供商支持那些API请求方式，按优先级调用;
具体效果解释：假设我设置一个新的提供商，我希望有一个列表开关控制该提供商支持那些请求方式，可以让它支持多种API请求方式，比如A模型不支持优先度最高的调用方式，在调用失败后自动回退到低优先度的请求方式，这样可以保证每次请求都可以尽量达成，而不是现有的单一渠道类型，调用失败后直接报错，我想这样的方法可用性会更高

[bestruirui]

你这创建俩渠道不就好了

[Linaom1214]

我也刚好想问这个问题，现在就是要创建多个渠道，公益可能支持多种请求端点，能不能一个渠道支持多个端点请求方式

[bestruirui]

我也刚好想问这个问题，现在就是要创建多个渠道，公益可能支持多种请求端点，能不能一个渠道支持多个端点请求方式

这感觉需要一个很大的重构,我计划计划

[Doraemonsan]

你这创建俩渠道不就好了

对的，目前我也是创建多个渠道来暂时解决的，但是这样也有一个弊端，模型提供商的模型很多，没办法快速判别哪些模型支持什么样的请求方法，最传统的笨办法在添加分组时就去模型提供商那挨着查询模型支持的调用方法；在同一个分组里把两个渠道都加上在除了故障转移的场景下基本上都是有弊无利，目前在不知道模型支持的调用方式前都只能在使用中不断调整分组设置才能减少报错提高可用性

[bestruirui]

你这创建俩渠道不就好了

对的，目前我也是创建多个渠道来暂时解决的，但是这样也有一个弊端，模型提供商的模型很多，没办法快速判别哪些模型支持什么样的请求方法，最传统的笨办法在添加分组时就去模型提供商那挨着查询模型支持的调用方法；在同一个分组里把两个渠道都加上在除了故障转移的场景下基本上都是有弊无利，目前在不知道模型支持的调用方式前都只能在使用中不断调整分组设置才能减少报错提高可用性

我感觉这更像是阿里云不规范,我后面看看吧

[Doraemonsan]

你这创建俩渠道不就好了

对的，目前我也是创建多个渠道来暂时解决的，但是这样也有一个弊端，模型提供商的模型很多，没办法快速判别哪些模型支持什么样的请求方法，最传统的笨办法在添加分组时就去模型提供商那挨着查询模型支持的调用方法；在同一个分组里把两个渠道都加上在除了故障转移的场景下基本上都是有弊无利，目前在不知道模型支持的调用方式前都只能在使用中不断调整分组设置才能减少报错提高可用性

我感觉这更像是阿里云不规范,我后面看看吧

更新：今天测试除了阿里云外还有 SiliconFlow 也同时支持多种请求类型，包括 /rerank 和 /embeddings ，不过由于 SiliconFlow 的 API Base 路径相对统一，不会出现阿里云一样使用 Responses API 无法获取模型列表的问题，所以增加同一渠道的不同的渠道类型也可以正确获取模型列表，但是相同模型提供商多次添加后，模型ID重复的问题只会随着添加渠道的支持的请求方法越多而越来越严重

建议&思路：如果添加此功能，可以去掉目前的渠道类型选择框，直接更改目前渠道编辑面的 Base URLs 功能，在 Base URLs后方添加渠道类型选择，可以同时解决对于支持多类型请求的渠道模型自动切换回退的问题，和反向代理的URL 渠道类型控制问题，还有阿里这种有多个 API BASE 的渠道支持都能得到很好的解决，对于单类型的渠道也不会有任何影响

[Doraemonsan]

你这创建俩渠道不就好了

对的，目前我也是创建多个渠道来暂时解决的，但是这样也有一个弊端，模型提供商的模型很多，没办法快速判别哪些模型支持什么样的请求方法，最传统的笨办法在添加分组时就去模型提供商那挨着查询模型支持的调用方法；在同一个分组里把两个渠道都加上在除了故障转移的场景下基本上都是有弊无利，目前在不知道模型支持的调用方式前都只能在使用中不断调整分组设置才能减少报错提高可用性

我感觉这更像是阿里云不规范,我后面看看吧

更新：今天测试除了阿里云外还有 SiliconFlow 也同时支持多种请求类型，包括 /rerank 和 /embeddings ，不过由于 SiliconFlow 的 API Base 路径相对统一，不会出现阿里云一样使用 Responses API 无法获取模型列表的问题，所以增加同一渠道的不同的渠道类型也可以正确获取模型列表，但是相同模型提供商多次添加后，模型ID重复的问题只会随着添加渠道的支持的请求方法越多而越来越严重

建议&思路：如果添加此功能，可以去掉目前的渠道类型选择框，直接更改目前渠道编辑面的 Base URLs 功能，在 Base URLs后方添加渠道类型选择，可以同时解决对于支持多类型请求的渠道模型自动切换回退的问题，和反向代理的URL 渠道类型控制问题，还有阿里这种有多个 API BASE 的渠道支持都能得到很好的解决，对于单类型的渠道也不会有任何影响

补充1：今天测试了一些比较大的模型供应商后发现，在对于不同API调用方法的支持上，大部分厂商都设置了不同的 API Base 而且几乎都不能从除了 OpenAI 以外的调用方法中获取到模型列表，下面我列出了这部分厂商的差异，希望对您有帮助

附表一：各提供商支持的 API 调用方式 (差异标注以 Completions API 为基准)

供应商 / API 类型	OpenAI (Completions)	OpenAI (Responses)	OpenAI (Embedding)	Anthropic
Aliyun	YES	YES (different)	YES	YES (different)
DeepSeek	YES	NO	NO	YES (different)
MiniMAX	YES	NO	NO	YES (different)
Nvidia	YES	NO	NO	NO
SiliconFlow	YES	NO	YES	YES
智普(国内版)	YES	NO	YES	YES (different)

---

附表二：各提供商完整的 API 端点

供应商 / API 类型	OpenAI (Completions)	OpenAI (Responses)	OpenAI (Embedding)	Anthropic
Aliyun	https://dashscope.aliyuncs.com/compatible-mode/v1/v1/chat/completions	https://dashscope.aliyuncs.com/api/v2/apps/protocols/compatible-mode/v1/responses	https://dashscope.aliyuncs.com/compatible-mode/v1/embeddings	https://dashscope.aliyuncs.com/apps/anthropic/v1/messages
DeepSeek	https://api.deepseek.com/v1/chat/completions	NO	NO	https://api.deepseek.com/anthropic/v1/messages
MiniMAX	https://api.minimaxi.com/v1/chat/completions	NO	NO	https://api.minimaxi.com/anthropic/v1/messages
Nvidia	https://integrate.api.nvidia.com/v1/chat/completions	NO	NO	NO
SiliconFlow	https://api.siliconflow.cn/v1/chat/completions	NO	https://api.siliconflow.cn/v1/embeddings	https://api.siliconflow.cn/v1/messages
智普(国内版)	https://open.bigmodel.cn/api/paas/v4/chat/completions	NO	https://open.bigmodel.cn/api/paas/v4/embeddings	https://open.bigmodel.cn/api/anthropic/v1/messages

[charlie-captain]

我建议是分组加上渠道类型，渠道那里支持多选渠道，目前我自己本地vibe coding了一版能跑起来。

[dyedd]

我感觉这个应该区分下，首先是渠道，编辑渠道里面的渠道类型应该变成“端口类型”，然后支持同一个渠道可以增加不同的端口类型 @bestruirui 不知道这样的想法怎么样

[Doraemonsan]

我找到了一个项目实现了与我想象中接近的效果，可以用作参考：https://github.com/sxueck/llm-gateway