Refactor ratio

[WqyJh]

close #2023

我已确认该 PR 已自测通过，相关截图如下：

默认倍率

自定义倍率配置

自定义倍率前后对比

[Laisky]

还是统一使用 ctxkey 比较好，你可以让 KeyRequestBody=gin.BodyBytesKey

[Laisky]

请教下这个重构的意义是什么，带来了什么新功能吗或解决了什么问题吗？

[WqyJh]

请教下这个重构的意义是什么，带来了什么新功能吗或解决了什么问题吗？

See #2023

[Laisky]

看了下，感觉很不错。不过我觉得没必要在页面上保留那两个【已废弃】，能自动将历史数据转为新格式就更好了。

[WqyJh]

看了下，感觉很不错。不过我觉得没必要在页面上保留那两个【已废弃】，能自动将历史数据转为新格式就更好了。

Good idea~ 已经实现了

截图中展示旧的倍率

新代码启动之后，自动迁移到新倍率中

导入一次之后，新倍率会写到 options 表中

可以在次基础上修改新倍率

再次重启 one-api，新倍率已持久化，不会被旧倍率覆盖

之后的版本中可以删除 ModelRatio, CompletionRatio 相关代码和配置

[WqyJh]

Hi @songquanpeng, would you please help review and merge the code?

[popdo]

感觉是多此一举，补全倍率很少去配置，这样修改后反而每个模型都要配置补全，反向优化

[Laisky]

DELETED, 详见下面的新回复

[Laisky]

@WqyJh 感觉还是有几个地方可以优化下

加载 Option 的时候，仅当 Ratio 为空时才需要合并旧数据，不用每次启动都合并一次

one-api/model/option.go

Lines 101 to 114 in f2bff58

	for _, option := range options {
	if option.Key == "Ratio" {
	option.Value = billingratio.AddOldRatio(oldModelRatio, oldCompletionRatio)
	err := updateOptionMap(option.Key, option.Value)
	if err != nil {
	logger.SysError("failed to update option map: " + err.Error())
	}
	err = UpdateOption(option.Key, option.Value)
	if err != nil {
	logger.SysError("failed to update option map: " + err.Error())
	}
	logger.SysLog("ratio merged")
	}
	}

Option 内的 Ratio 支持更细粒度的缺省值

解决 @popdo 提到的问题，用户编辑倍率的时候，可能并不需要为每一个模型都写上 Input 和 Output 倍率，而是仅需要编写和默认值不一样的项即可。

在下面的代码里，让读取 ratio 更细粒度一些。在从 billingratio.GetRatio 中读取到 ratio 后，再进一步检查其中的每一个成员项，Input/Output/LongThreshold/LongInput/LongOutput，如果为空的话用 adaptor.Ratio 补上。这样可以最大程度减轻维护的负担

one-api/relay/controller/helper.go

Lines 200 to 211 in f2bff58

	func GetRatio(meta *meta.Meta, adaptor adaptor.Adaptor) ratio.Ratio {
	result := billingratio.GetRatio(meta.OriginModelName, meta.ChannelType)
	if result != nil {
	return *result
	}
	ratio := adaptor.GetRatio(meta)
	if ratio != nil {
	return *ratio
	}
	logger.SysError("model ratio not found: " + meta.OriginModelName)
	return billingratio.FallbackRatio
	}

[songquanpeng]

算是 breaking change，在 One API 不同派生项目中也没办法通用，不过目前的倍率配置确实是有点乱，我先看看哈

[Laisky]

算是 breaking change，在 One API 不同派生项目中也没办法通用，不过目前的倍率配置确实是有点乱，我先看看哈

如果能自动将旧数据转换为新格式存新表的话就还好，升级回滚都可以自动完成。
这个提交还是很必要的，现在模型的计费很复杂，光靠一个 prompt 和 completion 已经无法满足需求了，要想同时支持 text、image、audio、阶梯计划，支持多样化的 struct 定义是必须的。

[Laisky]

@songquanpeng 建议优先处理一下这个问题，计费系统已经到了不得不大改的地步了。不然下游只能选择硬分叉，后期再加新模型就很难合并回来了。

几个痛点：

1. 不同 channel 共用模型名，但是费率不一致
2. 按 tokens 数量阶梯计价
3. 多模态模型对 text、audio、image 有不同的费率

这个 PR 稍微再优化一下，可以很好的解决所有的问题

[chenzikun]

是不是可以将模型列表和倍率建一张表，通过页面、接口去增加模型

[Laisky]

是不是可以将模型列表和倍率建一张表，通过页面、接口去增加模型

因为不同 channel 可能有同名模型，但是费率不同，集中管理会很麻烦。

或者给费率增加一个字段可以绑定到特定 channel，默认不绑定。

[ArcaneWhispers]

像new-api那样 通过令牌分组倍率来区分同名模型的不同价格比较好，不然用户调同个模型 多种价格就很迷惑。用户看的也是一脸懵逼。

[Laisky]

像new-api那样 通过令牌分组倍率来区分同名模型的不同价格比较好，不然用户调同个模型 多种价格就很迷惑。用户看的也是一脸懵逼。

分组倍率这个功能是有的，但是粒度是 channel 级的。