纯网关简化版本，专注于 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]

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

[C-L-STARK]

嗯 同样期待一个纯网关；支持自定义扩展功能和请求key映射。

[pepesi]

有相同的需求，希望保留核心relay功能，但是其他部分，认证，鉴权，审计，计量等功能作为可选插件的模式提供。

[ZzzzRyan]

期待一个保留了渠道和优先级设计的网关。

现在使用 One-API 不仅仅是用于管理不同厂商的原生 API 了，有时候还会用于管理同一个厂商但是不同第三方代理 API 的需求（毕竟现在各种第三方兴盛，但便宜的同时也都不算稳定，价格涨幅较大。这时就需要一个可以随时一键更换渠道的网关）。

如果后期有可能的话，或许可以嵌入脚本处理来获取不同渠道的价格实现自动更换低价渠道。

[simonsww]

支持，纯网关版非常需要。

[snakeying]

同样需求，计费等部分对于大多数个人用户来说没有必要。大多数个人用户使用都是为了方便在第三方UI中调用不同的模型。期待更新

[thinking-and-coding]

或者可以考虑基础纯网关版，高级添加计费功能这两种。高级版面向商用本身是不是也能做成有偿付费的形式？

[jinjianming]

有任何计划么，很期待此版本。

[lincocoa]

可以支持Meta的LLaMA吗

[lincocoa]

包括官网的LLaMA3.1, 与本地部署的模型支持

[SDAIer]

有进展吗