one-api
one-api copied to clipboard
songquanpeng
纯网关简化版本，专注于 API 适配
同期待纯网关版，裁剪掉计费、充值、额度、渠道、多用户之类的管理，突出日志、统计、审计的功能，打造一个纯粹的应用系统和大模型之间的中间应用（中台）。这个非常有实战价值，能够大幅度降低应用系统更换模型的代价——既不用修改应用系统访问大模型的代码，更不用去学习新模型 API的变化。
@davidjia1972 理解，根据模型名称选择渠道，然后直接使用传入的 key 对吧？但是有些渠道并不是单个 key 能完成鉴权的。
我的想法是保留渠道的概念。
这个作者说了 后期会考虑优化 例如分库之类的
MuskPM @.***> 于2024年3月12日周二 14:40写道：
还有一个问题，如果打开日志功能，数据库的读写压力很大，这个能不能优化下？
— Reply to this email directly, view it on GitHub https://github.com/songquanpeng/one-api/issues/1105#issuecomment-1990870335, or unsubscribe https://github.com/notifications/unsubscribe-auth/BAVUTOZEU2NFRAM5PMHIH4DYX2PPTAVCNFSM6AAAAABEKWOUDCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOJQHA3TAMZTGU . You are receiving this because you commented.Message ID: @.***>
我也建议保留渠道这个功能，每个渠道的配置都不太相同，所需的密钥也不一样。 只是现在渠道分配到组，在将组分配到用户在这种场景下可能会有点繁琐。既然要裁剪掉计费、充值、额度等功能，看可不可以提供一个新功能简化这个过程。比如提供一个新的接口(兼容openai)，传入的不再是令牌，而是我的登陆访问令牌，直接访问到每个渠道。最后在通过【优先使用“优先级数值”高的渠道,相同优先级随机选择渠道】这一个策越来使用渠道。之前的功能和新功能不冲突。
//sqlite
var channels Channel{}
DB.Order("priority DESC, RANDOM()").
Find(&channels)
//取channels[0]访问
我也建议保留渠道这个功能，每个渠道的配置都不太相同，所需的密钥也不一样。 只是现在渠道分配到组，在将组分配到用户在这种场景下可能会有点繁琐。既然要裁剪掉计费、充值、额度等功能，看可不可以提供一个新功能简化这个过程。比如提供一个新的接口(兼容openai)，传入的不再是令牌，而是我的登陆访问令牌，直接访问到每个渠道。最后在通过【优先使用“优先级数值”高的渠道,相同优先级随机选择渠道】这一个策越来使用渠道。之前的功能和新功能不冲突。
//sqlite var channels Channel{} DB.Order("priority DESC, RANDOM()"). Find(&channels)//取channels[0]访问
最后不管怎样，如果明确的话，我也很乐意贡献😄（可以领取简单任务）
我也建议保留渠道这个功能，每个渠道的配置都不太相同，所需的密钥也不一样。 只是现在渠道分配到组，在将组分配到用户在这种场景下可能会有点繁琐。既然要裁剪掉计费、充值、额度等功能，看可不可以提供一个新功能简化这个过程。比如提供一个新的接口(兼容openai)，传入的不再是令牌，而是我的登陆访问令牌，直接访问到每个渠道。最后在通过【优先使用“优先级数值”高的渠道,相同优先级随机选择渠道】这一个策越来使用渠道。之前的功能和新功能不冲突。
//sqlite var channels Channel{} DB.Order("priority DESC, RANDOM()"). Find(&channels)//取channels[0]访问
最后不管怎样，如果明确的话，我也很乐意贡献😄（可以领取简单任务）
既然作为纯网关，应该传各厂原生key
我也建议保留渠道这个功能，每个渠道的配置都不太相同，所需的密钥也不一样。 只是现在渠道分配到组，在将组分配到用户在这种场景下可能会有点繁琐。既然要裁剪掉计费、充值、额度等功能，看可不可以提供一个新功能简化这个过程。比如提供一个新的接口(兼容openai)，传入的不再是令牌，而是我的登陆访问令牌，直接访问到每个渠道。最后在通过【优先使用“优先级数值”高的渠道,相同优先级随机选择渠道】这一个策越来使用渠道。之前的功能和新功能不冲突。
//sqlite var channels Channel{} DB.Order("priority DESC, RANDOM()"). Find(&channels)//取channels[0]访问
最后不管怎样，如果明确的话，我也很乐意贡献😄（可以领取简单任务）
既然作为纯网关，应该传各厂原生key
嗯嗯，可能我考虑的角度比较窄了，我想基于现有系统简单改造，单独给新接口添加日志，成本比较小。但是传各厂原生key可能难以做到一个接口上，我记得科大讯飞是需要多个密钥才能访问，如果也是传组合key会不会增加调用方成本之类的。
然后并不是所有厂商都是直接传一个key就完事了，有些还要刷新你要怎么办
不知道老哥接下来的思路是怎样的？我倒是想到一个，就是超级管理员有一个权限，可以给每个用户打开直连功能。用户拥有直连权限之后就可以通过公共接口直接请求问答（带自己的登陆token,需要把登陆token美化下？）。不知道是否可行，或者有其他更好的方案？
现在系统在初始化时会给 root 用户近乎无限的额度，并且如果你设置了 INITIAL_ROOT_TOKEN 环境变量，会自动给 root 用户创建一个无限额度的令牌。
我也建议保留渠道这个功能，每个渠道的配置都不太相同，所需的密钥也不一样。 只是现在渠道分配到组，在将组分配到用户在这种场景下可能会有点繁琐。既然要裁剪掉计费、充值、额度等功能，看可不可以提供一个新功能简化这个过程。比如提供一个新的接口(兼容openai)，传入的不再是令牌，而是我的登陆访问令牌，直接访问到每个渠道。最后在通过【优先使用“优先级数值”高的渠道,相同优先级随机选择渠道】这一个策越来使用渠道。之前的功能和新功能不冲突。
//sqlite var channels Channel{} DB.Order("priority DESC, RANDOM()"). Find(&channels)//取channels[0]访问
最后不管怎样，如果明确的话，我也很乐意贡献😄（可以领取简单任务）
既然作为纯网关，应该传各厂原生key
作为一个纯粹的 API网关，各厂的原生 Key 最好还是通过配置文件来设置，而不是用 API 传递
作者有时间可以参考一下 litellm 的设计：
- 可用模型列表可以绑定到 team（类似 one-api 中的分组？） 或者 key。
- 日志（logging）功能可扩展，比如 key, user, model, prompt, response, tokens, cost 可以发送给第三方比如 s3/kafka，便于审计。
- 计费功能做为商用提供支持🐶。
我觉得上面说的一些都没必要啊。计费那一套，完全不同管都可以的，而且总要统计一下。还有传各个厂商的key，那还要oneapi干啥，不就是为了统一管理吗？
同期待纯网关版，裁剪掉计费、充值、额度、渠道、多用户之类的管理，突出日志、统计、审计的功能，打造一个纯粹的应用系统和大模型之间的中间应用（中台）。这个非常有实战价值，能够大幅度降低应用系统更换模型的代价——既不用修改应用系统访问大模型的代码，更不用去学习新模型 API的变化。
我写了。但不能开源。
感觉主要是优化下产品即可，现有多用户啥的，忽略即可。。 目前使用体验欠缺的内容：
- 初始化部署没法直接一步到位，绑定Key （这个最近实现了）。
- root用户默认余额太少，不注意就没钱了。
- 选择模型的交互有点难受。
- 建议优化list models接口，让客户端可以拉取已配置的模型（LLM模型、向量模型……）和对应模型的核心参数（上下文长度）。
- 非标准模型，支持直接转发。可以考虑，给自定义模型增加一个特殊前缀之类的进行区分。
场景很有意义，目前我部门就在用oneapi给各个项目分别使用不同的key，纯粹内部使用，所以发现很多功能并不需要
理想中的变化：
-
可以给每个key设置用户组（指定假key使用哪个真key） 目前新增一个项目需要新注册一个用户，再把这个用户划分到一个新的用户组，比较麻烦也不直观， 所以希望root用户创建的key能直接设置用户组（不再和root用户的用户组绑定）
-
root用户可以看到其他用户所有的key（包括key的花费） 有时候希望和其他部门同事共同查看一个项目的token花费情况，需要用非root账号创建key 所以展示root用户能展示非root账号创建key的花费面板，
-
去掉注册功能，充值和额度限制 都是自己的项目，不再需要兑换充值，所有的功能在root账户里直接就可以设置
场景很有意义，目前我部门就在用oneapi给各个项目分别使用不同的key，纯粹内部使用，所以发现很多功能并不需要
理想中的变化：
- 可以给每个key设置用户组（指定假key使用哪个真key） 目前新增一个项目需要新注册一个用户，再把这个用户划分到一个新的用户组，比较麻烦也不直观， 所以希望root用户创建的key能直接设置用户组（不再和root用户的用户组绑定）
- root用户可以看到其他用户所有的key（包括key的花费） 有时候希望和其他部门同事共同查看一个项目的token花费情况，需要用非root账号创建key 所以展示root用户能展示非root账号创建key的花费面板，
- 去掉注册功能，充值和额度限制 都是自己的项目，不再需要兑换充值，所有的功能在root账户里直接就可以设置
希望保留渠道概念，一个项目使用的key涉及负载均衡或者临时切换备用渠道，现在one-api的解耦是所有产品里做的最好的，不应该取消