第 69 个主题,共 91 个· 软件工程与数字化交付

云单位经济学 (Cloud Unit Economics,FinOps)

云单位经济学把原始的云支出换算成每单位产出的成本——每客户、每笔交易、每个已处理病例、每个 token。这正是 FinOps 能力把"我们的 AWS 账单是每月 £400k"转化为"服务一位患者花费 £0.83"的关键所在。

为什么重要

总支出数字回答不了真正重要的问题:产品正在变得更高效还是更低效?增长是在改善还是在侵蚀利润率?我们应该如何定价?单位成本可以同时回答这三个问题。就数字健康而言,"每例已处理病例的成本"本身就是一个卫生服务单位成本——可与采购方在其他任何服务上使用的国家成本采集 (National Cost Collection)数据直接比较,这使它成为将数字化路径与传统路径进行定价比较的天然语言。

计算方法

单位成本 = 已分摊的总成本(含共享/平台成本)/ 已交付的单位数

两大类别:
  资源效率单位:每 GB 存储成本、每 vCPU 小时成本、每 token 成本、
                每构建分钟成本
  业务单位:    每客户成本、每笔交易成本、每次问诊成本、
                每例已处理病例成本

边际成本与平均成本的区分同样适用(参见 marginal-vs-average-cost.md):
已承诺/预留的支出会使边际单位成本接近于 0,直到触及下一个
承诺阶梯——在边际层面评估扩容决策,在平均层面评估效率趋势。

算例

某数字分诊服务:云支出每月 £62,000(计算 £30k,数据 £18k,共享平台分摊 £14k),每月处理 380,000 次分诊:

每次分诊的平均成本 = 62,000 / 380,000 ≈ £0.163

与采购方对比:电话分诊约 £8–12/通,全科医生 (GP) 问诊约 £42
→ 数字化分诊的成本约为最便宜的人工替代方案的 2%——这正是
   gds-service-metrics.md 中渠道转移经济学在成本一侧的体现。

趋势检验:去年在 240k 次分诊量下为 £0.21/次 → 规模经济正在改善
(固定平台成本被摊薄),值得写进季度业务回顾 (QBR) 的头条。

与软件工程的关联

单位经济学正是工程决策转化为财务可读语言的地方:一种能把每例成本减半的架构就是一种定价优势;一种呈超线性扩张的架构则是一颗只有在这个指标上才看得见的定时炸弹。可以从卫生成本核算中借鉴的做法:公开分摊规则(在 PLICS 将按患者层面的成本核算标准化之前,共享成本一直在扭曲单位数字——你的平台成本分摊同样需要这种严谨性);选择采购方所思考的单位(采购方购买的是"病例",不是 vCPU);以及把单位成本作为权威的成本分母,输入到每一个 ICER 和预算影响模型中。对于 AI 功能而言,其单位就是 token——参见推理单位经济学。

陷阱

  • 忽略共享成本:不含平台/安全/待命值班分摊的单位成本会低估 30–50%,一旦被审计就会站不住脚。
  • 虚荣分母:"每次 API 调用的成本"看起来漂亮;"每例完成的患者就诊成本"才真正提供信息。
  • 用平均成本为边际决策定价:向团队按平均单位成本收取本质上边际免费的用量,只会催生一种"避免浪费"的表演式行为(参见国家统一收费标准了解这一激励缺陷在 NHS 场景下的版本)。

参考来源