We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
例行检查
功能描述 我有关非常大胆且拍脑袋的想法不知道作者有没有兴趣,就是一点思考 应用场景 现在的 oneapi 类的软件都是用渠道去管理模型,一个渠道被禁用,那么这个渠道的所有模型都不能用。 这个策略在面对各种官方渠道时可能是有效的(刚刚我就碰到了谷歌官方只有 1.5-flash 用不了的情况),但是现在很多三方站点都是各种套娃,上层上面还有上层,那么用渠道去管理模型就不是很合适了,oneapi 里测试一个渠道的是该渠道里的一个模型,它不能用意味着这个渠道直接被禁用,即便该渠道内的其他模型也可能是可用的。 那么是否可以用模型来管理渠道,一个模型下面有多种渠道,一个模型的某个渠道失效那么我们禁用该模型下面的的这个渠道就行,这不影响这个渠道底下其他模型的调用,从而提高我们 api 整体对外的可用性
虽然管理会更复杂但是稳定性会有较高的的提升
The text was updated successfully, but these errors were encountered:
No branches or pull requests
例行检查
功能描述
我有关非常大胆且拍脑袋的想法不知道作者有没有兴趣,就是一点思考
应用场景
现在的 oneapi 类的软件都是用渠道去管理模型,一个渠道被禁用,那么这个渠道的所有模型都不能用。
这个策略在面对各种官方渠道时可能是有效的(刚刚我就碰到了谷歌官方只有 1.5-flash 用不了的情况),但是现在很多三方站点都是各种套娃,上层上面还有上层,那么用渠道去管理模型就不是很合适了,oneapi 里测试一个渠道的是该渠道里的一个模型,它不能用意味着这个渠道直接被禁用,即便该渠道内的其他模型也可能是可用的。
那么是否可以用模型来管理渠道,一个模型下面有多种渠道,一个模型的某个渠道失效那么我们禁用该模型下面的的这个渠道就行,这不影响这个渠道底下其他模型的调用,从而提高我们 api 整体对外的可用性
虽然管理会更复杂但是稳定性会有较高的的提升
The text was updated successfully, but these errors were encountered: