Provide a new fast and simple way of accessing APIs (As example: Yi-models,Deepseek)

[Menghuan1918]

考虑到新的大语言模型API普遍兼容OpenAI 的API格式(例如: Groq，Yi01，Deepseek，Moonshot等)

这个PR提供了一种更为简单的方式快速添加此类API，仅需要给程序提供：

• 请求地址
• 每次请求的最大token数(⚠️不是最大上下文数)
• 最大上下文token

这是一个使用这种方法添加DeepseekAPI的示范，其仅需修改config.py与request_llms/bridge_all.py两个文件，仅使用33行代码即可添加"deepseek-chat"以及"deepseek-coder"模型。

PR包含的其他内容：将零一万物的请求格式也替换为这种格式

同时参考这个issue，留下了对代理的开关参数，或许未来可以自定义？

[binaryYuki]

Hi，

是否考虑参考#1763 在参数中添加 API_KEY 呢

我的想法是在传参的时候直接带上该模型的：

• API_KEY
• 请求地址
• 每次请求的最大token数(⚠️不是最大上下文数)
• 最大上下文token

可以最大化的优化现在在添加新模型时的步骤并且尽可能解耦？

当然同时可能会有在使用第三方包的时候需要单独设计部分

[Menghuan1918]

Hi，

是否考虑参考#1763 在参数中添加 API_KEY 呢

我的想法是在传参的时候直接带上该模型的：

* API_KEY

* 请求地址

* 每次请求的最大token数(⚠️不是最大上下文数)

* 最大上下文token

可以最大化的优化现在在添加新模型时的步骤并且尽可能解耦？

当然同时可能会有在使用第三方包的时候需要单独设计部分

请参考新的提交

这样对不同模型设置不同的endpoint以及get_predict_function中API的参数可以实现这个目标

但是如何热重载涉及的部分有点多，我目前没有头绪....

[binaryYuki]

能否麻烦您解释一下您描述的“热重载”的场景？
我目前的想法是

• 引入 sqlite3 既可以解决实时的修改环境 还可以实现对API_KEY的鉴权
• 或者直接运行的时候把 PID 保存成一个文件 然后通过 webhook 实现重启

不知道您有没有更好的想法

[Menghuan1918]

能否麻烦您解释一下您描述的“热重载”的场景？ 我目前的想法是

* 引入 sqlite3 既可以解决实时的修改环境 还可以实现对API_KEY的鉴权

* 或者直接运行的时候把 PID 保存成一个文件 然后通过 webhook 实现重启

不知道您有没有更好的想法

或者可以采取和oneapi接入相似的思路，模型名以"cus-"开头，而API则以"CUS_模型名字"以关键词去查找

不过我目前没什么精力去做这个