ModelRatio and CompletionRatio should be maintained by adapter

[WqyJh]

目前 model ratio 和 completion ratio 是集中维护的，这带来几个问题：

1. 不同供应商的同一个模型（例如 llama3）可能名字相同，但是价格不同（例如groq价格低于aws），如何区分并设置不同的费率？
2. GetCompletionRatio 函数冗长，为什么不像 model ratio 一样写一个 map？

更为合理的方案是，参考 ModelList 的维护方法，每个 Adapter 维护一个 RatioMap，在 DoResponse 返回 usage 的时候连带 ratio 一起返回，或者为 adapter 添加一个获取 ratio 的接口。
进一步，ModelList 可以被这个 RatioMap 替代。

涉及到的改动量可能比较大，目前只是提出一个想法，欢迎大家讨论。

[Laisky]

关于你的第一个问题，是可以通过 model_name(channel_type) 的形式区分的，代码在

one-api/relay/billing/ratio/model.go

Line 398 in 3915ce9

model := fmt.Sprintf("%s(%d)", name, channelType)

关于重构，我认为目前面临的主要问题有两个：

1. 厂商可能提供了根据 context 长度的阶梯计价，目前无法支持
2. 多模态内的不同消息类型有不同的单价，比如 gpt-4o-audio 模型内的 text 和 audio 价格是不同的（我在 feat: support gpt-4o-audio #2032 内使用一个比较粗糙的方式解决了这个问题，但是价格是写死在代码里的，用户没法配置）

[WqyJh]

是的 model_name(channel_type) 这个方案是我之前提交的，当时是以比较小的工作量完成这件事，只是一个权宜之计。

本次的重构目标之一就是将计费收敛到 Adaptor 内部，由 Adaptor 来独立完成计费。目前已经实现了根据 context 长度的阶梯计价，可以参考 gemini 模型的 RatioMap https://github.com/songquanpeng/one-api/pull/2038/files#diff-717467816f5fd368bc5e174fbdf8d4050b8f1d6d29753483b1a50a6e103a1177

audio 的计价我认为也可以在 RatioMap 中添加字段来扩展计费方式。目前的统一计费方式很难扩展。

[Laisky]

是的 model_name(channel_type) 这个方案是我之前提交的，当时是以比较小的工作量完成这件事，只是一个权宜之计。

本次的重构目标之一就是将计费收敛到 Adaptor 内部，由 Adaptor 来独立完成计费。目前已经实现了根据 context 长度的阶梯计价，可以参考 gemini 模型的 RatioMap https://github.com/songquanpeng/one-api/pull/2038/files#diff-717467816f5fd368bc5e174fbdf8d4050b8f1d6d29753483b1a50a6e103a1177

audio 的计价我认为也可以在 RatioMap 中添加字段来扩展计费方式。目前的统一计费方式很难扩展。

谢谢解答，我学习一下