纯网关简化版本，专注于 API 适配

[Hkaisense]

真正作为openai接口标准访问所有大模型的一个网关

去掉各种计费管理功能，做高效分发，不要数据库，或者只做日志收集分析

[ye4293]

可以看看这个 https://github.com/Portkey-AI/gateway

[songquanpeng]

周末支持，开启后关闭计费

[songquanpeng]

至于不要数据库，sqlite使用起来并没有什么成本，用户完全无感，不用数据库意义不大

[popdo]

希望支持纯网关。希望可以无需设置渠道即可直接传各厂原生key

[daiaji]

sqlite已经非常轻量了，你存数据也总也要个数据库吧？

[songquanpeng]

本周末没有精力处理了，下周末看时间是否允许

[davidjia1972]

同期待纯网关版，裁剪掉计费、充值、额度、渠道、多用户之类的管理，突出日志、统计、审计的功能，打造一个纯粹的应用系统和大模型之间的中间应用（中台）。这个非常有实战价值，能够大幅度降低应用系统更换模型的代价——既不用修改应用系统访问大模型的代码，更不用去学习新模型 API的变化。

[songquanpeng]

@davidjia1972 理解，根据模型名称选择渠道，然后直接使用传入的 key 对吧？但是有些渠道并不是单个 key 能完成鉴权的。

我的想法是保留渠道的概念。

[songquanpeng]

当然具体可以再讨论。

[MustAPI]

还有一个问题，如果打开日志功能，数据库的读写压力很大，这个能不能优化下？

[ye4293]

这个作者说了 后期会考虑优化 例如分库之类的 MuskPM ***@***.***> 于2024年3月12日周二 14:40写道：

…

还有一个问题，如果打开日志功能，数据库的读写压力很大，这个能不能优化下？ — Reply to this email directly, view it on GitHub <#1105 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BAVUTOZEU2NFRAM5PMHIH4DYX2PPTAVCNFSM6AAAAABEKWOUDCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOJQHA3TAMZTGU> . You are receiving this because you commented.Message ID: ***@***.***>

[songquanpeng]

日志之后分库解决

[davidjia1972]

日志是不是可以像常规做 service 的软件那样用传统 log 文件的方式存储，需要分析的时候再用专门的软件来做？

[xusenlin]

我也建议保留渠道这个功能，每个渠道的配置都不太相同，所需的密钥也不一样。
只是现在渠道分配到组，在将组分配到用户在这种场景下可能会有点繁琐。既然要裁剪掉计费、充值、额度等功能，看可不可以提供一个新功能简化这个过程。比如提供一个新的接口(兼容openai)，传入的不再是令牌，而是我的登陆访问令牌，直接访问到每个渠道。最后在通过【优先使用“优先级数值”高的渠道,相同优先级随机选择渠道】这一个策越来使用渠道。之前的功能和新功能不冲突。

//sqlite
var channels Channel{}
DB.Order("priority DESC, RANDOM()").
    Find(&channels)

//取channels[0]访问

[xusenlin]

我也建议保留渠道这个功能，每个渠道的配置都不太相同，所需的密钥也不一样。 只是现在渠道分配到组，在将组分配到用户在这种场景下可能会有点繁琐。既然要裁剪掉计费、充值、额度等功能，看可不可以提供一个新功能简化这个过程。比如提供一个新的接口(兼容openai)，传入的不再是令牌，而是我的登陆访问令牌，直接访问到每个渠道。最后在通过【优先使用“优先级数值”高的渠道,相同优先级随机选择渠道】这一个策越来使用渠道。之前的功能和新功能不冲突。

//sqlite
var channels Channel{}
DB.Order("priority DESC, RANDOM()").
    Find(&channels)

//取channels[0]访问

最后不管怎样，如果明确的话，我也很乐意贡献😄（可以领取简单任务）

[popdo]

我也建议保留渠道这个功能，每个渠道的配置都不太相同，所需的密钥也不一样。 只是现在渠道分配到组，在将组分配到用户在这种场景下可能会有点繁琐。既然要裁剪掉计费、充值、额度等功能，看可不可以提供一个新功能简化这个过程。比如提供一个新的接口(兼容openai)，传入的不再是令牌，而是我的登陆访问令牌，直接访问到每个渠道。最后在通过【优先使用“优先级数值”高的渠道,相同优先级随机选择渠道】这一个策越来使用渠道。之前的功能和新功能不冲突。

//sqlite
var channels Channel{}
DB.Order("priority DESC, RANDOM()").
    Find(&channels)

//取channels[0]访问

最后不管怎样，如果明确的话，我也很乐意贡献😄（可以领取简单任务）

既然作为纯网关，应该传各厂原生key

[xusenlin]

我也建议保留渠道这个功能，每个渠道的配置都不太相同，所需的密钥也不一样。 只是现在渠道分配到组，在将组分配到用户在这种场景下可能会有点繁琐。既然要裁剪掉计费、充值、额度等功能，看可不可以提供一个新功能简化这个过程。比如提供一个新的接口(兼容openai)，传入的不再是令牌，而是我的登陆访问令牌，直接访问到每个渠道。最后在通过【优先使用“优先级数值”高的渠道,相同优先级随机选择渠道】这一个策越来使用渠道。之前的功能和新功能不冲突。

//sqlite
var channels Channel{}
DB.Order("priority DESC, RANDOM()").
    Find(&channels)

//取channels[0]访问

最后不管怎样，如果明确的话，我也很乐意贡献😄（可以领取简单任务）

既然作为纯网关，应该传各厂原生key

嗯嗯，可能我考虑的角度比较窄了，我想基于现有系统简单改造，单独给新接口添加日志，成本比较小。但是传各厂原生key可能难以做到一个接口上，我记得科大讯飞是需要多个密钥才能访问，如果也是传组合key会不会增加调用方成本之类的。

[songquanpeng]

然后并不是所有厂商都是直接传一个key就完事了，有些还要刷新你要怎么办

[xusenlin]

然后并不是所有厂商都是直接传一个key就完事了，有些还要刷新你要怎么办

不知道老哥接下来的思路是怎样的？我倒是想到一个，就是超级管理员有一个权限，可以给每个用户打开直连功能。用户拥有直连权限之后就可以通过公共接口直接请求问答（带自己的登陆token,需要把登陆token美化下？）。不知道是否可行，或者有其他更好的方案？

[xusenlin]

选择渠道

关于请求时选择的渠道

1. 优先通过用户请求的模型
2. 在符合的渠道中通过优先级排序
3. 优先级相同随机选择

[songquanpeng]

现在系统在初始化时会给 root 用户近乎无限的额度，并且如果你设置了 INITIAL_ROOT_TOKEN 环境变量，会自动给 root 用户创建一个无限额度的令牌。

[davidjia1972]

我也建议保留渠道这个功能，每个渠道的配置都不太相同，所需的密钥也不一样。 只是现在渠道分配到组，在将组分配到用户在这种场景下可能会有点繁琐。既然要裁剪掉计费、充值、额度等功能，看可不可以提供一个新功能简化这个过程。比如提供一个新的接口(兼容openai)，传入的不再是令牌，而是我的登陆访问令牌，直接访问到每个渠道。最后在通过【优先使用“优先级数值”高的渠道,相同优先级随机选择渠道】这一个策越来使用渠道。之前的功能和新功能不冲突。

//sqlite
var channels Channel{}
DB.Order("priority DESC, RANDOM()").
    Find(&channels)

//取channels[0]访问

最后不管怎样，如果明确的话，我也很乐意贡献😄（可以领取简单任务）

既然作为纯网关，应该传各厂原生key

作为一个纯粹的 API网关，各厂的原生 Key 最好还是通过配置文件来设置，而不是用 API 传递

[youmengme]

同期待纯网关 不带数据库的版本 这样就可以用vercel部署了

[kaktos]

作者有时间可以参考一下 litellm 的设计：

1. 可用模型列表可以绑定到 team（类似 one-api 中的分组？） 或者 key。
2. 日志（logging）功能可扩展，比如 key, user, model, prompt, response, tokens, cost 可以发送给第三方比如 s3/kafka，便于审计。
3. 计费功能做为商用提供支持🐶。

[pangjianxin]

跪求支持部分厂商现已支持的function call等核心功能

[manjieqi]

我觉得上面说的一些都没必要啊。计费那一套，完全不同管都可以的，而且总要统计一下。还有传各个厂商的key，那还要oneapi干啥，不就是为了统一管理吗？

[xkzhud]

同期待纯网关版，裁剪掉计费、充值、额度、渠道、多用户之类的管理，突出日志、统计、审计的功能，打造一个纯粹的应用系统和大模型之间的中间应用（中台）。这个非常有实战价值，能够大幅度降低应用系统更换模型的代价——既不用修改应用系统访问大模型的代码，更不用去学习新模型 API的变化。

我写了。但不能开源。

[c121914yu]

感觉主要是优化下产品即可，现有多用户啥的，忽略即可。。
目前使用体验欠缺的内容：

1. 初始化部署没法直接一步到位，绑定Key （这个最近实现了）。
2. root用户默认余额太少，不注意就没钱了。
3. 选择模型的交互有点难受。
4. 建议优化list models接口，让客户端可以拉取已配置的模型（LLM模型、向量模型……）和对应模型的核心参数（上下文长度）。
5. 非标准模型，支持直接转发。可以考虑，给自定义模型增加一个特殊前缀之类的进行区分。

[liuhetian]

场景很有意义，目前我部门就在用oneapi给各个项目分别使用不同的key，纯粹内部使用，所以发现很多功能并不需要

理想中的变化：

1. 可以给每个key设置用户组（指定假key使用哪个真key）
   目前新增一个项目需要新注册一个用户，再把这个用户划分到一个新的用户组，比较麻烦也不直观，
   所以希望root用户创建的key能直接设置用户组（不再和root用户的用户组绑定）

2. root用户可以看到其他用户所有的key（包括key的花费）
   有时候希望和其他部门同事共同查看一个项目的token花费情况，需要用非root账号创建key
   所以展示root用户能展示非root账号创建key的花费面板，

3. 去掉注册功能，充值和额度限制
   都是自己的项目，不再需要兑换充值，所有的功能在root账户里直接就可以设置

[liuhetian]

场景很有意义，目前我部门就在用oneapi给各个项目分别使用不同的key，纯粹内部使用，所以发现很多功能并不需要

理想中的变化：

1. 可以给每个key设置用户组（指定假key使用哪个真key）
   目前新增一个项目需要新注册一个用户，再把这个用户划分到一个新的用户组，比较麻烦也不直观，
   所以希望root用户创建的key能直接设置用户组（不再和root用户的用户组绑定）
2. root用户可以看到其他用户所有的key（包括key的花费）
   有时候希望和其他部门同事共同查看一个项目的token花费情况，需要用非root账号创建key
   所以展示root用户能展示非root账号创建key的花费面板，
3. 去掉注册功能，充值和额度限制
   都是自己的项目，不再需要兑换充值，所有的功能在root账户里直接就可以设置

希望保留渠道概念，一个项目使用的key涉及负载均衡或者临时切换备用渠道，现在one-api的解耦是所有产品里做的最好的，不应该取消

[proxyxai]

同期待纯网关版，裁剪掉计费、充值、额度、渠道、多用户之类的管理，突出日志、统计、审计的功能，打造一个纯粹的应用系统和大模型之间的中间应用（中台）。这个非常有实战价值，能够大幅度降低应用系统更换模型的代价——既不用修改应用系统访问大模型的代码，更不用去学习新模型 API的变化。

Is it ? https://github.com/proxyxai/xai

[AinzLimuru]

非常需要这个功能，虽然上面有人提到了其他的项目，但这些项目对于国内的模型服务提供商是完全不支持的。真的非常希望能够推出一个纯网关的版本。