按功能核算 AI 成本：把总账单拆到每个产品功能上
大部分团队看 AI 成本，看的是月度总账单——这个月在 OpenAI 花了多少、在 Anthropic 花了多少。这个视角能回答”钱花没花超”，但回答不了一个更关键的问题：“哪个功能在赚钱，哪个功能在赔本”。按功能核算成本（cost-per-feature accounting），就是把总账单拆解到产品功能粒度，让每个功能的单位经济学变得可见。这和按租户做成本归因（参考 AI Agent 多租户成本归因）是两条正交的拆分维度：一个回答”谁在花钱”，一个回答”钱花在哪个功能上”，成熟的产品最终两条维度都要有。
一、为什么总账单会掩盖真相
一个典型场景：产品里有智能摘要、智能问答、自动生成周报三个 AI 功能，月度账单是 8000 美元。如果不拆分，团队只知道”AI 成本 8000”，但实际情况可能是：
- 智能摘要：日活 5000，单次调用成本 0.002 美元，月成本 300 美元，功能价值明显覆盖成本
- 智能问答：日活 800，但因为上下文窗口大、经常多轮，单次调用成本 0.15 美元，月成本 3600 美元
- 自动生成周报：日活只有 50，但每次调用触发一整条 Agent 链路（检索 + 多次工具调用 + 长输出），月成本 4100 美元
不拆开看，团队可能会因为总账单”看起来还好”而放松警惕，错过自动生成周报这个功能其实单位成本高到离谱、且用户量小到不成比例的信号。反过来，如果盲目按总账单做降本，很可能优化错了目标，去压缩已经很便宜的智能摘要，而放过真正的大头。
二、核算的最小颗粒度：一次功能调用要落几个字段
要做功能级核算，前提是每次模型调用都要能追溯到具体功能。埋点至少要包含：
{
"request_id": "req-93021",
"feature": "weekly_report_generator",
"model": "claude-sonnet-5",
"input_tokens": 4200,
"output_tokens": 1800,
"cached_input_tokens": 1200,
"tool_calls": 3,
"latency_ms": 8400,
"user_id": "u-1180",
"timestamp": "2026-09-08T09:12:00Z"
}关键是 feature 字段必须在请求发起时就显式传入，而不是事后靠日志内容猜测。很多团队踩的坑是埋点只记了 model 和 tokens，等要做功能核算时才发现历史数据没法回溯归类，只能从当前时间点重新开始积累。
cached_input_tokens 单独记录也很重要，因为命中缓存的 tokens 成本远低于新输入（参考 Prompt Caching 成本优化），如果不分开算，会高估某个功能的真实边际成本。
三、分摊规则：直接成本 vs 共享成本
不是所有成本都能干净地归到某一个功能。实践中分两类处理：
直接成本：功能调用产生的模型调用、工具执行费用，可以精确记账，直接落到该功能名下。
共享成本：比如一个通用的向量检索服务被三个功能共用，或者一次多功能编排的 Agent 调用里，同一次工具执行结果被两个下游功能复用。这类成本需要选一个分摊规则，常见三种：
| 分摊规则 | 计算方式 | 适用场景 |
|---|---|---|
| 按调用次数均摊 | 总成本 ÷ 各功能调用次数 | 各功能对共享资源的消耗强度接近 |
| 按实际 tokens 占比分摊 | 按各功能实际消耗的 tokens 比例分配 | 功能间调用强度差异大 |
| 不分摊，单独核算为”平台成本” | 共享服务成本不下推到功能层 | 共享服务本身也需要独立优化决策 |
建议默认用第三种：把共享基础设施（比如统一的检索服务、统一的模型网关）的成本单独列一项”平台成本”，不强行摊到某个功能头上。分摊规则一旦引入主观分配比例，很容易在团队内部变成”甩锅”的工具，反而破坏核算数据的可信度。
四、核算结果怎么用：三个决策场景
功能级成本数据本身不是目的，能支撑决策才有价值。三个最常见的应用场景：
场景一：功能下线决策。如果一个功能的月成本远超其带来的留存/转化价值，且核算数据能稳定复现（不是单月异常），这是下线或重新设计该功能的直接证据。这比”产品经理觉得这个功能用的人少”要硬得多。
场景二：模型分级路由。发现某个功能大部分请求其实不需要用最贵的模型，可以针对该功能单独做模型降级（参考 模型分级成本策略）。功能级数据能告诉你具体该在哪个功能上做这件事，而不是笼统地说”要降本”。
场景三：定价校准。如果产品是按功能收费或者有功能配额，功能级成本核算能直接告诉你当前定价是否覆盖成本，尤其是那些”免费增值”功能，很容易在核算前完全没人注意到它其实是亏损大户。
五、常见误区：把核算做成了纯财务报表
功能级成本核算容易走偏成一个只有财务和管理层看的报表，工程团队完全不参与迭代。这样做的问题是核算颗粒度会越来越粗、数据新鲜度越来越差，因为没有人在日常工作中依赖这份数据做决策。
更好的做法是把功能级成本做成工程团队日常能看到的仪表盘的一部分,和延迟、错误率放在同一个面板里，让”这个功能这周成本涨了 40%“和”这个功能这周延迟涨了”一样,成为工程 on-call 会主动关注的信号（可结合 LLM 成本异常检测 做自动告警）。当核算数据和日常工程节奏绑定，才会持续保持准确和有用。
六、小结
按功能核算 AI 成本的核心不是搭一套复杂的分摊模型，而是三件事做扎实：调用时就打上功能标签、直接成本精确记账、共享成本单独列项不瞎摊。做到这三点，团队就能从”这个月总共花了多少”升级到”这个功能值不值得做”，这是 AI 产品从”能跑起来”到”能持续经营”必须迈过的一道坎。