周六上班无聊的思考 
：
最近很多中转站的claude都不太稳定，导致我自己的oneapi渠道也不太稳定
于是衍生出了这个贴子：
现在的oneapi类的软件都是用渠道去管理模型，一个渠道被禁用，那么这个渠道的所有模型都不能用。
这个策略在面对各种官方渠道时可能是有效的（刚刚我就碰到了谷歌官方只有1.5-flash用不了的情况），但是现在很多三方站点都是各种套娃，上层上面还有上层，那么用渠道去管理模型就不是很合适了，oneapi里测试一个渠道的是该渠道里的一个模型，它不能用意味着这个渠道直接被禁用，即便该渠道内的其他模型也可能是可用的。
那么是否可以用模型来管理渠道，一个模型下面有多种渠道，一个模型的某个渠道失效那么我们禁用该模型下面的的这个渠道就行，这不影响这个渠道底下其他模型的调用，从而提高我们api整体对外的可用性
17 个赞
#纯水添加
那双向链表岂不是更好，可以精准禁用
比如渠道A的a模型不可用，其他可用，是不是就可以精准禁用渠道A的模型
1 个赞
你好。你的需求我写的 uni-api 可以完美实现。下面是项目介绍：
可以设置当渠道下面的模型出问题时仅冷却该渠道下的模型。
有时间换了试试
很好的思路，我觉得用new-api等聚合就是用来作balance负载均衡的，但事实上并没有做到，测试失败直接把渠道禁用了。
但是这样的后果就是模型多了管理混乱，我觉得只要加强对测试失败的模型的禁用加强负载均衡就好了
可以尝试加个简单的 ui，没有 ui ，增删改查会非常的蛋疼
，未来有时间支持一下。
期待佬的更新，现在的oneapi急需革新，gogogo
1 个赞
还有佬我在你的项目上没有看到与函数调用有关的设置，某渠道某模型是否支持函数调用
目前支持 OpenAI claude Gemini vertex 函数调用。你请求的时候统一使用 OpenAI 格式的 tool use 请求即可。uni-api 对于不同的渠道会自动转换成各自渠道商的原生 tool use 格式，对于不支持 tools use 的模型 uni-api 会自动删除 tools 部分。
万一碰到逆向呢？ 
它自己会忽视 tools，实际使用中没有直接报错的情况发生。你也可以设置 tools: false 来强制 uni-api 删除 tools 请求体。
我的意思是我需要使用 tools，但是碰到了逆向渠道
目前如果刚好碰到了逆向渠道，tool 将用不了，后面我调整一下，改成优先使用有 tools 的渠道。