谈谈API的成本计算方法

引言

前一段时间，拜访客户的时候，客户提出一个问题：原来他们的AI应用，把不同的模型部署在不同的EC2实例上，不同模型的EC2实例打不同的tag，通过tag来识别不同模型的成本消耗。现在他们想把不同的模型部署到同一个EC2实例上，那么这么混合部署后，如何来识别不同的模型的成本消耗呢？

我们现场讨论了几种方案。后来回来后，我想了想，觉得这个是个挺有意思的话题。多年前，我在网龙工作时，我们曾经试图通过压测的定量分析来指导程序的优化，在类似的方向上有过讨论，有很多的共通之处。这里把思考做一个记录、总结，以供大家参考。

理想的成本

理想情况下，一次API调用的成本可以简单理解为，调用这个API一次，消耗了多少资源，折合多少钱。

但是在实际的执行过程中，通常很难这么衡量。原因在于，大多数的用于保障API执行的基础设施，并不是以这么细的粒度来进行计费和付费的（哪怕是云上serverless lambda的方式，通常也只是计算层可以做到这么细粒度的计费，如果这个计算要用到DB，也很难把DB的消耗细化到每一个API请求）。

从财务的角度

通常时候，只能以一台或者一组服务器作为粒度来计算成本。即便是引入虚拟化或者云化后，也只能以虚机的维度来计算成本。很难进行更细粒度的成本拆分。

这个角度，只是为了让所有的成本有归属，所有的资源使用能找到承担成本和责任的人。

损耗的问题

实际上，系统在运行中，其实是有损耗的，我们很难把硬件设备的性能用尽。比如一台服务器，一天有能力执行100W次的计算，但是实际上，我们只执行了50W次计算。那么实际上就损耗了50%的算力资源，但是我们还是要为这部分没有被利用起来的资源支付费用。

如果这部分的损耗不能正确识别出来，结果会影响我们对系统的负载能力的整体判断。也会对将来的成本预期做出错误的估计。

目的

• 准确识别理想成本
• 准确识别系统损耗
• 预估系统的负载上限、指导系统扩容
• 合理进行成本核算

实施

理想成本的获得

取一个标准环境（比如一台2核4G的EC2，一台2核4G的RDS）。假定它一个小时的价格是P1，把它一个小时的资源记为R1。那么一天的成本就是P1*24，一天的可使用资源量就是R1*24。

实际上，经济成本核资源成本，只是成本的两种表示方式，在资源价格确定的时候，这两个成本是可以换算的。所以后面我们都已经济成本来讨论。

在这个标准环境上，对业务A（可能是单个或一组API）进行多轮压测。得到一个平均TPS值，假定这个值是M1。

那么我们可以计算业务A的经济成本为：P1/(M1*3600)

事实上，我们的系统在实际运行的时候，如果真的达到压测的满载状态，是会存在一定的风险的（比如可能导致系统出现慢请求），所以我们通常应该要设定一个资源使用率阈值，这里假定设这个阈值为90%。那么上面的成本应该修正为：

经济成本为：P1/(M1*3600*0.9)

业务A在一段时间里面的总成本为：P1/(M1*3600*0.9)*业务A总请求量。

所有业务在一段时间（T）里面的总成本为：所有业务的总成本之和 CT。

系统损耗的计算

在一段时间里面，我们支付的总费用是 P1 *  T。

这一段时间，系统的损耗是 P1 * T - CT。

进一步，要看公司的核算里面，损耗部分是作为公共支出，还是要核算为业务成本。如果作为公共支出，是最容易的，把这部分当列就好了。

如果要核算为业务成本，那么要定义业务的分摊规则。比如是按照业务的请求量分担，还是按照业务的理论成本占比分摊。

如果按照业务的理论成本占比分摊，那么一个业务的分摊值为：

(P1 * T - CT) * (P1/(M1*3600*0.9)*业务A总请求量) / CT。

进一步的应用

通过 P1 * T - CT 和 CT的占比，我们也能分析出，此时系统的富余容量，预知系统还可以承受多少的负载增加，进一步推算用户在什么程度的增长水平上，系统可以正常运行，需要在什么时候进行扩容。

在多业务混合使用资源的时候，也可以依据这个推算的数据，结合线上资源的观测，来判断业务混合部署是否能有效使用资源，哪些业务的资源使用是会互相干扰的。

实际使用过程中，还可能出现，压测和实际运行，都会出现系统的性能已经无法提升，但是确观测到CPU，内存都还很空闲，或者其中一种资源空闲的状态。

如果是一种资源空闲，说明系统的配置不合理，我们需要调整配置，来更好地优化性价比。

如果都空闲，那么需要考虑系统是不是有外部依赖，外部依赖拖累了系统的性能发挥，这个时候优化的方向是提升外部依赖系统的响应速度，或者降低本系统的配置，以和外部系统适配，减少资源的浪费。