推理成本归因体系构建

可视化演示

展示推理服务成本构成分解、多租户请求级归因分摊与成本趋势异常检测，切换模式观察成本管理全流程。

成本采集体系

物业老手的经验永远是同样一句话：先抄表，再分账。哪个水龙头在漏水、哪家空调彻夜不关，没有计量表，一切都只能靠猜。AI 推理云平台也一样，成本归因体系的地基，就是先把每一类资源的消耗精确量出来——这一步叫成本采集。如果采集的数据不准，后面再精巧的归因模型，也只是精装修的空中楼阁。

推理服务也有自己的“水电气”三种表。第一张是计算表：GPU 跑了几张卡、跑了几小时，折算成“卡时”；第二张是存储表：模型权重、KV 缓存、日志快照占了多少磁盘容量；第三张是网络表：跨节点通信、公网回源走了多少流量。大模型时代千万别小看后两张，在长上下文场景里，存储和网络常常能占到总成本的两三成。

把三张表汇总，就得到全平台某个统计周期的推理总成本：

$$\displaystyle C_{\text{total}} = C_{\text{compute}} + C_{\text{storage}} + C_{\text{network}}$$

GPU 卡时要按型号区分单价，A100 和 L40S 的价格差好几倍；存储按容量乘以时长计费；网络按出向流量计费。除了装表，还要给每块表贴门牌号——通过强制资源标签标识归属项目，并定期巡检、清理由历史遗留资源造成的“无主账单”。

1. 总成本 $C_{\text{total}}$：整个推理平台在一个统计周期内的全部开销，由三类资源成本相加得到。这是后续一切分摊的“成本池”。

$$C_{\text{total}} = C_{\text{compute}} + C_{\text{storage}} + C_{\text{network}}$$

2. 计算成本 $C_{\text{compute}}$：GPU 算力开销，等于每类 GPU 的卡数乘以占用时长，再乘对应单价后累加。

$$C_{\text{compute}} = \sum_{k} G_k \times T_k \times P_k$$

3. 存储成本 $C_{\text{storage}}$：模型权重与 KV 缓存占用的磁盘容量，按容量乘以存储时长再乘单价计算。

$$C_{\text{storage}} = Q_{\text{disk}} \times T_{\text{hold}} \times P_{\text{disk}}$$

4. 网络成本 $C_{\text{network}}$：按出向与入向流量分别乘以各自单价，汇总得到带宽费用。

$$C_{\text{network}} = B_{\text{out}} \times P_{\text{band}} + B_{\text{in}} \times P_{\text{in}}$$

老物业的经验是：表装得越全，账算得越准。采集层做扎实了，后面制定分摊规则、搭建看板才有底气，否则一切归因都是无源之水。

归因模型设计

大楼里那部电梯的电费怎么摊？顶楼住户说按人头，底层住户说按面积，地下室商铺说要免单。物业知道，不管怎么定都会有人不满意，但必须定一套公开的“分摊宪法”，否则每个月都要吵一次。归因模型，就是推理平台的“分摊宪法”——它规定公共成本按照什么规则落到每个模型、每个租户头上。

主流玩法有三种。直接计量法：租户独占的 GPU、独享的带宽直接记账，就像每户水表直连自家水管；间接分摊法：共享资源池按用量占比分摊，就像电梯费按各家居住面积占比摊；混合归因：两条腿走路——独享部分直接计，共享部分按占比摊。绝大多数生产级平台选的都是混合方案。

间接分摊的核心是归一化权重公式：

$$\displaystyle w_i = \frac{U_i}{\sum_{j=1}^{N} U_j}, \qquad C_i = w_i \times C_{\text{shared}}$$

$U_i$ 是第 $i$ 个租户在某共享资源上的实际用量，分母是所有租户用量之和，两者相除得到归一化权重 $w_i$，范围在 0 到 1 之间；最后用权重乘以共享池总成本，就是这家该付的公摊。另外，归因粒度要谨慎选择：请求级适合对外计费，租户级适合预算管理，粒度越细，采集和计算的成本也越高。

1. 分子 $U_i$：第 $i$ 个租户在某共享资源上的实际用量，比如 GPU 卡时数、存储容量或带宽流量，必须先由采集体系准确读出。

$$U_i = \text{租户}_{i} \text{的某共享资源用量}$$

2. 分母 $\sum_{j=1}^{N} U_j$：所有租户同一资源用量的总和，把每个租户的用量放在同一把尺子上度量。

$$\sum_{j=1}^{N} U_j = U_1 + U_2 + \cdots + U_N$$

3. 归一化权重 $w_i$：分子除以分母得到 0 到 1 之间的占比，反映“这家用了整个池子的多大份额”。

$$0 \le w_i \le 1, \qquad \sum_{i=1}^{N} w_i = 1$$

4. 分摊成本 $C_i$：用权重乘以共享池总成本 $C_{\text{shared}}$，得到该租户应承担的公摊金额。

$$C_i = w_i \times C_{\text{shared}}$$

“分摊宪法”越透明，租户越愿意认账。规则一旦公开讲清，物业就不必天天当裁判，大家自己就能算出自家账单。

模型级归因

机房里有几台“公共服务器”，同一块 GPU 上挤着两三个模型。物业要给每个模型单独开一张“机房租金单”，怎么算？最朴素的逻辑是：谁占的地方大、谁耗的电多，谁就多出钱。模型级归因正是沿着这个思路，把 GPU 机房的总成本拆到每个模型头上。

分摊主要看两块。一块是显存占用：模型权重加计算图占了多少显存，占池子多大比例，就按这个比例摊 GPU 成本，这对应“占座面积”；另一块是 KV 缓存：随着并发请求数增长，每个请求的上下文都要单独缓存，这部分随业务波动，必须单独计量再叠加，这对应“实际用电量”。

模型级归因公式如下：

$$\displaystyle C_{\text{model}} = \frac{M_{\text{model}}}{M_{\text{total}}} \times C_{\text{gpu}} + C_{\text{kv}}$$

$M_{\text{model}}$ 是模型在 GPU 显存中的占用，$M_{\text{total}}$ 是整个 GPU 池的显存容量，$C_{\text{gpu}}$ 是这个池子当期的 GPU 总成本，$C_{\text{kv}}$ 是该模型的 KV 缓存消耗。两个模型共享一张卡时，显存占比越高分摊越重；长上下文模型因为 KV 涨得快，账单往往很厚。

1. 显存占比 $M_{\text{model}} / M_{\text{total}}$：先算出模型占用的显存占整个 GPU 池的比例，这是“按占座面积收费”的依据。

$$\frac{M_{\text{model}}}{M_{\text{total}}} = \frac{\text{模型占用显存}}{\text{GPU池总显存}}$$

2. GPU 成本分摊：用显存占比乘以 GPU 池总成本 $C_{\text{gpu}}$，得到模型在算力维度的基础账单。

$$\frac{M_{\text{model}}}{M_{\text{total}}} \times C_{\text{gpu}}$$

3. KV 缓存成本 $C_{\text{kv}}$：KV 缓存随并发请求数动态增长，属于“用电量”式的变量成本，单独计量后叠加。

$$C_{\text{kv}} = \text{缓存容量} \times \text{缓存时长} \times \text{单位价格}$$

4. 模型总成本 $C_{\text{model}}$：显存分摊与 KV 缓存两项相加，就是该模型当期的完整机房账单。

$$C_{\text{model}} = \frac{M_{\text{model}}}{M_{\text{total}}} \times C_{\text{gpu}} + C_{\text{kv}}$$

“机房租金单”做得越细，模型团队就越有动力做显存优化、缩短上下文——物业几乎不用催，账单自己会说话。

租户级归因

模型只是“楼层”，每个模型下面还住着许多租户——不同业务线、不同客户团队。物业不可能只把账单收到楼层，还得再往下拆一层，落到每一户头上，顺便管住每户的用水上限，免得哪家半夜水管爆了全楼遭殃。

租户级归因由三块拼成：一是直接资源成本，比如租户独占的推理实例、预留带宽，直接记账到户；二是共享池公摊，把多租户共用的资源按用量占比分配；三是配额与预算管控——给每户设月度预算和成本封顶，超了自动告警甚至限流。

租户级归因公式：

$$\displaystyle C_{\text{tenant}} = C_{\text{direct}} + \frac{U_{\text{tenant}}}{U_{\text{total}}} \times C_{\text{shared}}$$

$C_{\text{direct}}$ 是该租户独享资源的直接成本，第二项是它在共享池中的公摊。要支撑这套拆账，项目标签是硬约束：创建资源时标签缺失就拒绝创建，避免“无主资源”变成糊涂账；还要定期清理垃圾标签，防止串账。

1. 直接成本 $C_{\text{direct}}$：租户独占的 GPU 实例、预留带宽等资源的开销，直接记到该户头上，对应“自家水表直读”。

$$C_{\text{direct}} = \sum \text{独占资源量} \times \text{单价}$$

2. 用量占比 $U_{\text{tenant}} / U_{\text{total}}$：租户在共享池中的用量除以所有租户用量之和，得到它在公共资源中的份额。

$$\frac{U_{\text{tenant}}}{U_{\text{total}}} = \frac{\text{该租户共享用量}}{\text{共享池总用量}}$$

3. 公摊成本：用量占比乘以共享池总成本 $C_{\text{shared}}$，算出该租户应付的公共资源部分。

$$\frac{U_{\text{tenant}}}{U_{\text{total}}} \times C_{\text{shared}}$$

4. 租户总成本 $C_{\text{tenant}}$：直接成本与公摊成本相加，得到该租户当期的完整账单。

$$C_{\text{tenant}} = C_{\text{direct}} + \frac{U_{\text{tenant}}}{U_{\text{total}}} \times C_{\text{shared}}$$

一户一单、超支预警——租户们的月度账单清清楚楚，谁也不会再质疑物业偏心。

请求级归因

小区门口新装了一台扫码直饮机，每一杯水卖给谁、收多少钱，后台一清二楚，再也没人投诉水费。请求级归因就是这个精度：把成本精确到一次 API 调用上，回答“这一条对话到底花了多少钱”。

一次推理请求分两段：预填充阶段处理输入提示词，把上下文编码成缓存；生成阶段逐字自回归地吐出新 Token。输入 Token 处理一次就完事，输出 Token 要一步步生成，资源消耗高一个量级，所以两者的单价天然不同。多个请求还会拼在同一个 GPU batch 里跑，分摊时要按 Token 数分配显存与算力，再做公平折算。

请求级归因公式：

$$\displaystyle C_{\text{req}} = N_{\text{in}} \times P_{\text{in}} + N_{\text{out}} \times P_{\text{out}}$$

$N_{\text{in}}$、$N_{\text{out}}$ 分别是一次请求输入和输出的 Token 数，$P_{\text{in}}$、$P_{\text{out}}$ 是两类 Token 的单价。为了算准单价，还要记录请求的完整生命周期：排队时长、推理时长、回传时长——每个阶段消耗什么资源、按什么单价计费，都写进日志，才能从账单反查到任意一次请求。

1. 输入 Token 数 $N_{\text{in}}$：用户提示词的长度，决定预填充阶段要处理多少上下文。

$$N_{\text{in}} = \text{提示词切分后的Token数量}$$

2. 输入单价 $P_{\text{in}}$：预填充阶段每个输入 Token 的处理成本，一次编码，单价较低。

$$P_{\text{in}} = \text{预填充处理成本} / N_{\text{in}}$$

3. 输出 Token 数与单价：生成阶段逐字生成，资源占用高，因此 $P_{\text{out}}$ 通常远高于 $P_{\text{in}}$。

$$P_{\text{out}} \gg P_{\text{in}}$$

4. 请求总成本 $C_{\text{req}}$：输入与输出两部分费用相加，就是一次请求的完整账单。

$$C_{\text{req}} = N_{\text{in}} \times P_{\text{in}} + N_{\text{out}} \times P_{\text{out}}$$

扫码买水麻烦吗？一点都不麻烦，查账的时候才真香。请求级账单也这样——平时静默，出问题时能精确到“哪一个请求吃掉了最多钱”。

成本看板设计

物业在大厅挂了块电子屏，实时滚动每户的用水用电和公摊排名。没人想翻一摞厚厚的 Excel，大家只想一眼看到趋势、排名和异常。成本看板就是推理平台的那块大厅屏，它是归因体系的“仪表盘”。

一块合格的看板要做三件事。多维透视：按时间、模型、租户任意切片下钻，点开一个数字就能看到构成；趋势分析：用环比、同比发现成本拐点，比如某模型突然贵了 30%；异常告警：成本突增时立刻触发通知，联动缩容或回滚，而不是月底结账时才发现巨款流失。

环比增长率公式：

$$\displaystyle \text{MoM} = \frac{C_t - C_{t-1}}{C_{t-1}} \times 100\%$$

$C_t$ 是本期成本，$C_{t-1}$ 是上期成本，二者差值除以上期成本再乘 100%，就是环比增长率。看板还要把每周、每月的数字沉淀成成本报表，归档留痕，作为后续 FinOps 复盘的依据。

1. 本期成本 $C_t$：当前统计周期（本周或本月）的总成本，是增长分析中的“被比较对象”。

$$C_t = \text{当期归因总成本}$$

2. 上期成本 $C_{t-1}$：上一统计周期的总成本，作为对比基准。

$$C_{t-1} = \text{上一期归因总成本}$$

3. 成本增量 $C_t - C_{t-1}$：本期相对上期的变化量，正数表示成本上升，负数表示下降。

$$C_t - C_{t-1} = \text{成本增减额}$$

4. 环比增长率 MoM：增量除以上期成本再乘 100%，得到相对变化百分比，消除规模差异。

$$\frac{C_t - C_{t-1}}{C_{t-1}} \times 100\%$$

大厅屏不是摆设，它得会“喊”——数据一旦异常，值班物业能在 3 小时内站到“事故现场”，把成本堵回去。

FinOps运营

物业经理半夜巡逻，发现地下室的灯亮了一整夜，顺手关掉，这个月电费省了两百块——省下的钱不多，但积少成多。成本归因也不能停在“出账单”，必须进入“发现—行动—复盘”的经营循环，这就是 FinOps。

典型动作有四个。优化建议：看板定位到某模型成本高企，顺藤摸瓜发现是超长输出导致 KV 缓存爆炸，于是引导瘦身提示词；弹性伸缩：低峰期把推理副本缩到最小，高峰期提前扩容；空闲资源回收：清理没人用的 GPU Pod、孤儿快照和废弃模型版本；复盘迭代：每周沉淀一份成本周报，对比优化前后的曲线，持续迭代归因规则。

节省成本公式：

$$\displaystyle S = \Delta R \times P \times T$$

$\Delta R$ 是本次回收的资源量，比如 2 张 GPU；$P$ 是资源单价，比如每小时 12 元；$T$ 是回收持续的小时数。三者相乘就是省下的钱。每个优化动作做完都要用这个公式复盘，算出“真金白银”，再决定下一轮投入。

1. 回收资源量 $\Delta R$：弹性缩容或清理闲置资源释放出的 GPU、内存、磁盘数量。

$$\Delta R = \text{回收的实例数} \times \text{单位实例资源量}$$

2. 资源单价 $P$：单位资源每个计费周期的价格，通常按“元/卡时”或“元/GB时”计。

$$P = \text{单位资源每小时价格}$$

3. 回收时长 $T$：本次回收状态持续了多少个计费周期，回收时间越长省得越多。

$$T = \text{回收持续小时数}$$

4. 节省成本 $S$：三量相乘得到本次优化动作的直接收益，用于复盘和决策。

$$S = \Delta R \times P \times T$$

物业靠一次次深夜关灯省出了整年的物业费，你的平台也会靠 FinOps 把推理成本一条条抠回来——省下的每一分钱，都是归因体系存在的意义。

AI 应用场景

Python 演示

"""Inference cost attribution demo.Allocate shared inference cluster costs to tenants by usage ratio."""  class CostAttributor:    """Cost attributor that splits shared pool costs by tenant usage."""     def __init__(self, sources):        # sources example: {"compute": 60000, "storage": 12000, "network": 8000}        self.sources = sources        self.usage_map = {}        self.result_map = {}     def register_tenant(self, name, usage):        # usage example: {"compute": 300, "storage": 80, "network": 60}        self.usage_map[name] = usage     def allocate(self):        # compute total usage per source, then split cost by ratio        totals = {}        for src in self.sources:            totals[src] = sum(row.get(src, 0) for row in self.usage_map.values())        for name, usage in self.usage_map.items():            cost = 0.0            for src, price in self.sources.items():                if totals[src] <= 0:                    continue                ratio = usage.get(src, 0) / totals[src]                cost += round(price * ratio, 2)            self.result_map[name] = cost        return self.result_map     def report(self):        if not self.result_map:            self.allocate()        grand = sum(self.result_map.values())        rows = ["%s  %.2f  %.1f%%" % (name, cost, cost / grand * 100)                for name, cost in sorted(self.result_map.items(),                                         key=lambda x: -x[1])]        return "\n".join(rows)  def request_cost(tokens_in, tokens_out, price_in, price_out):    """Per request cost = input cost + output cost."""    return tokens_in * price_in + tokens_out * price_out  if __name__ == "__main__":    sources = {"compute": 60000, "storage": 12000, "network": 8000}    attributor = CostAttributor(sources)    attributor.register_tenant("tenant-a", {"compute": 300, "storage": 80, "network": 60})    attributor.register_tenant("tenant-b", {"compute": 180, "storage": 60, "network": 50})    attributor.register_tenant("tenant-c", {"compute": 120, "storage": 40, "network": 30})    print("Tenant cost attribution report:")    print(attributor.report())    print("single request cost:", request_cost(120, 80, 0.002, 0.006))

1. self.usage_map[name] = usage注册租户及其在各成本来源上的用量，相当于给每户登记水表读数。
2. totals[src] = sum(row.get(src, 0) for row in self.usage_map.values())先算出所有租户在某类资源上的总用量，这是分母。
3. ratio = usage.get(src, 0) / totals[src]计算该租户在某类资源上的占比，即归一化权重。
4. cost += round(price * ratio, 2)用占比乘以该类资源总价并累加，得到该租户分摊到的真金白银。
5. request_cost(120, 80, 0.002, 0.006)输入 120 个 Token、输出 80 个 Token，按输入单价 0.002、输出单价 0.006 算出单次请求成本。

常见误区

面试题