成本可观测、异常告警与单位业务指标成本（per-task cost）

• 理解总成本与成本/请求的局限
• 掌握单位业务动作成本（per-task cost）与业务价值关联
• 理解用单位业务成本驱动功能取舍

总成本与成本/请求只反映"成本规模"与"请求层面成本"，不反映"业务结果"——一个请求可能没解决用户问题，成本/请求很低但业务价值极低。单位业务动作成本（每解决工单、每份生成报告）把"成本"与"业务结果"关联：不仅看"花了多少钱"，更看"每解决一个业务问题花了多少钱"。关联业务价值：单位业务成本 = 业务动作总成本 / 业务结果数（解决工单数、生成报告数），与业务价值（用户满意度、转化率、客户留存）关联，形成"成本—价值"视图。驱动功能取舍：某功能"单位业务成本高 + 业务价值低"（如每解决工单成本高但解决率低）→ 该功能应降级或下线；"单位业务成本低 + 价值高"→ 增强。因此只监控总成本不够，要监控"单位业务动作成本"并关联价值，才能做对功能取舍。

成本/请求是"成本学"，单位业务成本是"价值学"。前者看"效率"，后者看"价值"。只有把成本除以"业务结果"，才能判断"钱花得值不值"，从而驱动功能增删。这是 FinOps 在 AI 上的核心指标。

• 理解成本异常与合理波动的成因
• 掌握动态基线（相对阈值）而非固定阈值
• 理解事件上下文与告警噪声抑制

成本异常告警的关键是"区分真实异常与合理波动"且"防止噪声"。真实异常：爬虫刷量（成本陡增）、Agent 循环（单 Agent 无限调用）、配置错误（Prompt 膨胀）；合理波动：活动（大促流量增）、版本发布（新功能上线）。区分方法：用动态基线——基于历史（同期、滚动窗口）的均值与标准差计算"期望范围"，当前值超出期望 N 个标准差才告警，而非固定阈值（固定阈值无法适应流量自然波动）。叠加事件上下文：对照"事件日历"（活动、版本发布），已知事件导致的上升视为合理，抑制告警；无事件的突增视为异常。防止噪声：告警要有"持续时间/连续超出"条件（非单点瞬时）、告警分级（p1/p2）、抑制重复告警。动态基线 + 事件标注 + 持续条件，是压噪关键。

固定阈值告警的痛点是"该报的不报、不该报的乱报"。动态基线用"相对偏离"而非"绝对阈值"，适应流量波动；事件上下文解释"为什么升"，持续条件过滤瞬时抖动。三者结合，把告警噪声压到最低。

• 理解失败与重试任务对 per-task cost 的影响
• 掌握异常样本的处理（剔除、分桶、独立归集）
• 理解单位成本的可信度

失败与重试任务会污染 per-task cost：若把失败任务成本混入，成功任务单位成本被抬高（把失败成本摊给成功）；若把重试任务重复计入，成本被重复计算。处理：分层归集——把"成功任务"与"失败任务"分桶，分别算 per-task cost；失败任务成本单独归集（是"缺陷成本/损失"），不混入成功任务；重试任务按"任务 ID"去重归集——一次任务含多次重试，成本按任务累加（重试是一次任务的一部分），而非每次重试算一个任务。剔除异常样本——对极端样本（如超长任务、异常高成本）做识别与标注，可选剔除或单列，避免拉高均值。用"中位数/分位数"而非纯均值，抗异常样本。关键是"失败/重试/异常与正常分开"，让 per-task cost 反映"正常完成任务"的成本。

per-task cost 的可信度取决于"分母干净"。失败与重试成本要单独归集，避免"稀释或抬高"成功任务成本。按任务去重重试、分桶成败、用分位数抗异常，是保证单位成本可信的三招。

• 理解成本告警的下钻定位维度
• 掌握预先埋标签（租户/功能/模型/Prompt 版本）
• 理解下钻定位根因

成本告警触发后要快速定位"是哪个租户、哪个功能、哪个模型、哪个 Prompt 版本"导致的，前提是预先埋好标签。需埋的标签：租户 ID、用户/业务线、功能模块、模型（用了哪个模型）、Prompt 版本（哪个 Prompt 模板）、事件/流量类型、请求 ID、trace ID、结果状态。若无标签，告警后只能查总量，无法下钻。下钻流程：从"告警触发的维度"（如总成本突增）逐层下钻——先按租户看（哪个租户贡献大？）→ 按功能（哪个功能？）→ 按模型（哪个模型？）→ 按 Prompt 版本（哪个版本？），定位到"某租户 × 某功能 × 某模型 × 某 Prompt 版本"的高成本组合，再结合 trace 看具体请求。这就是"多维下钻 + 标签定位"的根因分析。标签在请求发起时内联写入，保证可下钻。

定位根因的前提是"可下钻的标签"。没有标签，成本告警只是个"数字异常"；有了多维标签，才能像"切片"一样逐层缩小到根因。标签要"预埋、内联、标准"，这是事后快速定位的基础。

• 理解高成本低价值功能的识别
• 掌握"成本 × 使用率 × 价值"评估
• 理解驱动降级/下线决策

识别高成本低价值功能：对每个功能，算"成本/月"与"使用率/价值"（用户使用率、核心程度、对业务贡献）。高成本低价值 = 成本高且使用率低/价值低。方法：成本按功能归集（功能标签），使用率按功能统计（功能调用量、用户数），价值按业务贡献（是否为核心功能、是否创造收入）。识别后驱动决策：对"高成本低价值"功能——降级（降级到小模型、降频、限流）或下线（移除功能，省掉全部成本）；对"低成本高价值"保留增强；对"高成本高价值"优化（设法降本）。决策要量化：该功能"单位价值成本"（成本/价值贡献）高则优先优化/下线。用"成本—价值"矩阵（四象限）可视化，辅助产品决策。

高成本低价值功能是"成本漏水点"。识别靠"成本 × 使用率 × 价值"三维评估，决策靠"成本—价值"矩阵。降级（省成本）或下线（除成本）是这类功能的归宿，把资源让给高价值功能。

• 理解基线管理（动态基线）
• 掌握模型/Prompt 变更后的基线调整
• 理解防止基线漂移导致告警失效

成本观测的基线（用于异常检测的期望范围）要动态管理，否则模型或 Prompt 变更后基线漂移，告警失效（旧基线不匹配新成本分布）。管理方法：基线基于"滚动窗口"（最近 N 天/周）动态计算，而非固定历史，使基线随成本分布自然更新；模型/Prompt 变更后，主动"重置/调整基线"——变更是一个已知事件，变更后重新计算基线（用变更后的数据），避免旧基线把变更后的正常成本误报为异常。防漂移：变更前记录基线（变更前基线），变更后重建基线（变更后基线），并做变更标注（变更期间不告警或抑制，因为成本结构必然变化）。关键是"基线要区分正常演进与变更事件"——正常演进用滚动窗口自动更新，变更事件用"主动重建基线 + 变更抑制"。

基线漂移是"检测失效"的根源。滚动窗口让基线自适应，变更事件要主动重建基线并抑制告警。否则模型/Prompt 一变，成本分布变了，旧基线要么误报（把正常变更当异常）要么漏报（把真实异常当正常）。

• 理解成本与质量指标的联合解读
• 掌握"单位成功成本"等联合指标
• 理解避免片面结论

单独看成本或质量会片面——成本降了可能是质量降了（降本即降质），或质量降了可能是正常的（不同场景）。联合解读：用"单位成功成本"（成本/成功任务数）把成本与质量统一——成本降但成功任务数也降，单位成功成本可能没变甚至升（说明降本是以降质为代价）；成本降且成功任务数不变，单位成功成本降（真降本）。同时看"成本曲线"与"质量曲线"（任务成功率、解决率）的联动：成本降 + 质量不降 = 好降本；成本降 + 质量降 = 需警惕；成本升 + 质量升 = 值不值。模型的"帕累托"视角：只在一个维度上取舍会误导。结论：降本是否可取，要看"单位成功成本"与"质量是否可接受"，而非单纯看"成本降没降"。

降本与降质是"两个变量"，单看一个会误判。单位成功成本把两者统一，是"价值"指标。成本降 + 质量不降才是真降本，成本降 + 质量降要评估是否值得。联合解读避免"降本即降质"或"降质即降本"的片面结论。

• 理解请求级 usage 字段的标准化
• 掌握采集链路（内联埋点 + 事件流）
• 理解支撑租户/功能下钻

支撑租户/功能下钻的 token 成本埋点要"标准化 + 全维度 + 请求级"。标准化 usage 字段：制定统一 schema——请求 ID、租户 ID、功能模块、模型、input/output/cached/reasoning token、价格版本、成本、时间戳、trace ID、结果状态。采集链路：请求发起时内联埋点（在一次请求的多次 LLM 调用上，带统一上下文标签），调用完成后把 usage+标签作为事件写入流（Kafka），异步聚合写入存储。下钻支撑：每个请求都带租户/功能标签，聚合时按租户、功能、模型维度任意下钻（租户→功能→请求→计费项）。关键：字段标准化（统一 schema 保证可比）、标签完整（缺标签无法下钻）、采集异步化（不阻塞请求）。埋点要覆盖所有 LLM 调用与工具，不遗漏。

下钻的前提是"每个请求都带全维度标签且 usage 标准化"。没有统一 schema，数据不可比；没有标签，无法下钻。内联埋点 + 异步事件流 + 统一 schema，是"请求级、可下钻"token 成本采集的标准做法。

• 理解公共成本（缓存、评估、网关）的性质
• 掌握公共成本分摊规则
• 理解公平分摊

公共成本（缓存、评估、网关）是共享的，分摊要"公平 + 可解释"。分摊规则：按"实际用量"分摊——缓存成本按各租户/功能的实际命中量分摊；评估成本按"评估请求量"分摊；网关成本按"调用量/请求量"分摊。区分"固定公共成本"与"可变公共成本"：固定成本（网关基础设施）按比例（如请求量占比）分摊；可变成本（缓存命中、评估）按用量分摊。公平原则：哪个租户/功能用得多，分摊得多；避免"小租户贴大租户"（被平均摊高）。要可解释：分摊规则透明、可复查（提供分摊明细）。缓存命中是"共享收益"，可按"谁命中谁受益"或"按命中量"分摊。关键是"规则透明 + 按用量驱动 + 可复查"，让各租户/功能认为公平。

公共成本分摊的公平 = "按用量 + 规则透明"。固定成本按比例、可变成本按用量，避免平均摊。可复查的分摊明细消除"不公平"的争议。缓存这类共享收益要按实际命中分摊。

• 理解 usage 字段的统一（input/output/cache/reasoning）
• 掌握汇率与价格表版本管理
• 理解成本数据的标准化

成本数据的标准化是"跨 Provider 可比、可追溯"的前提。统一 usage 字段：制定统一 schema，涵盖 input/output/cached/reasoning/thinking token、模型、请求 ID、时间、结果，各 Provider 调用都映射到统一字段（不同 Provider 的字段名差异在采集层归一化）。汇率：多币种统一到基准币种，用"汇率快照"（报表期固定汇率，带版本）而非实时汇率，保证历史可复算。价格表版本：价格表带版本号与生效时间，成本计算按"请求时点 + 当时价格版本"复算，调价不影响历史。收益：统一 usage + 汇率快照 + 价格版本，让成本数据可对比、可复算、可审计，支撑跨 Provider 报表与历史对账。

成本数据标准化是"可比性"的基石。统一 usage 字段消除 Provider 差异，汇率快照保证跨币种可比，价格版本保证历史可复算。三者缺一不可，否则成本数据是一团"口径不一"的数字。

• 理解财务与工程报表的不同目标
• 掌握口径与粒度的差异化
• 理解两套报表的衔接

财务与工程报表目标不同，口径与粒度要差异化。面向财务（月度对账）：口径用"实际含税、实际费率、汇率快照、按计费主体"，粒度粗（月度汇总、按租户/计费主体/大功能），用于对账、入账、合规，强调"精确、可审计、与 Provider 账单一致"。面向工程（日常优化）：口径用"估算、不含税、实时汇率、按请求/功能/模型"，粒度细（请求级、按功能/模型/Prompt 下钻），用于日常优化、定位高成本点、评估优化效果，强调"及时、可下钻、可对比"。两套报表各司其职，但底层数据同源（同一 usage 数据），只是聚合口径不同。衔接：财务报表用"实际口径"校准，工程报表用"估算口径"驱动，两者通过差异报告对齐。关键是"目标不同则口径不同"。

财务报表要"精确对账"，工程报表要"及时优化"，两者天然口径不同。底层数据同源，只是口径与粒度差异。把两套报表分开设计，避免"为对账而牺牲实时、为优化而牺牲精度"。

• 理解从请求级成本汇总到单位业务成本
• 掌握任务与订单的统计口径统一
• 理解聚合链路

单位业务成本从请求级成本汇总而来：一个业务任务/订单可能对应多个请求（多次 LLM 调用、工具调用），先按"任务/订单 ID"把所有请求的成本汇总成"任务成本"，再除以任务/订单数，得到"单位业务成本"。统计口径统一的关键：定义"任务/订单"的边界——一个任务/订单包含哪些请求（含重试、工具调用、后处理），边界要统一（否则统计口径漂移）；任务/订单 ID 与请求 ID 的关联关系要完整（请求都带任务/订单 ID，能聚合）；失败/重试任务是否计入要统一。聚合链路：请求级 usage → 按任务 ID 聚合 → 任务/订单成本 → 除以业务量 → 单位业务成本。统一口径：任务/订单的"完成标准"（成功、含重试、含失败）要一致，否则单位成本不可比。

单位业务成本是"聚合指标"，依赖"请求→任务"的关联与"任务边界"的统一。口径不一致（任务边界不同、失败是否计入）会导致数值不可比。关键是"请求带任务 ID、任务边界统一、成功/失败口径一致"。

• 理解成本异常的常见根因（模型回退、Prompt 改版、缓存失效）
• 掌握自动定位根因
• 理解给出处置建议

成本异常告警后要自动定位根因，常见的根因有：模型回退（路由逻辑导致某模型用量激增）、Prompt 改版（Prompt 变长导致 token 激增）、缓存失效（命中率下降导致成本回升）。自动定位方法：告警触发时，自动比对各维度的"变化"——模型维度（各模型成本/用量对比，看哪个模型异常增长）、Prompt 版本维度（token 用量对比，看哪个版本 token 膨胀）、缓存维度（命中率变化，看是否命中率下降）。定位到根因后给出处置建议：模型回退→检查路由/回退路由配置；Prompt 改版→检查新版 Prompt 的 token 用量、回滚 Prompt；缓存失效→检查缓存失效原因（前缀变化、失效策略）、恢复缓存命中。定位靠"变更标注 + 多维对比"：记录模型/Prompt/缓存的变更事件，告警时关联变更，快速定位"哪个变更导致异常"。

自动定位的关键是"关联变更 + 多维对比"。成本异常通常是"某个变更"（模型、Prompt、缓存）引起的，把告警与变更关联，能快速定位根因。处置建议基于根因（回退/修正/恢复），而非盲目降级。

• 理解三类降本手段的作用点
• 掌握实施顺序与叠加收益评估
• 理解避免重复优化

三类降本手段作用点不同：模型路由（降低单价，选便宜模型）、缓存（降低重复输入成本，命中省输入）、上下文压缩（降低输入量，减少 token）。实施顺序与叠加收益：先做"零/低成本、低风险"的（缓存、上下文压缩——不改变模型质量），再做"有风险"的（模型路由——有质量风险）。避免重复优化：三类手段作用于不同成本面，但可能重叠——如上下文压缩已减了输入，缓存命中再省输入，若已压缩过的输入命中率低，叠加收益有限。评估叠加：分别做"单独收益"与"组合收益"，看是否为简单相加还是边际递减（组合收益可能小于单收益之和，因为作用面重叠）。用"单位成功成本"统一评估，避免局部优化（如只优化单价而忽略缓存/压缩）。实施顺序逻辑：先做不影响质量的手段（缓存、压缩），再评估路由（有质量风险）。

三类手段是"成本面的不同杠杆"，但可能重叠。避免重复优化是"看叠加收益是否边际递减"——若压缩与缓存作用面重叠，别重复投入。实施顺序上"先安全后风险"，用单位成功成本统一衡量，避免局部最优。

• 理解成本预算的落地（配额、阈值、降级动作）
• 掌握配置与定期复审
• 理解成本治理的持续运营

成本预算落地要配置好"配额、告警阈值、自动降级动作"。配额分配：按租户/功能/模型分配预算配额（谁有多少预算），明确超限责任；告警阈值：按预算比例设软告警（70%/80%）与硬限制（100%），阈值要与业务容量匹配；自动降级动作：配置超限后的动作（降级模型、限流、熔断、固定模板），按价值分级。配置后要"定期复审"：预算额度随业务变化要调整（业务增长/收缩）；阈值要基于实际成本分布校准（防止误报/漏报）；降级动作要验证是否有效与是否伤核心。复审周期（如每月/每季度）：Review 配额是否合理、告警是否该报的报、降级是否适得其反。成本治理是"持续运营"——配置 + 复审 + 调整，循环优化，而非一次性设置。

成本预算落地是"配置 + 运营"两件事。配置（配额/阈值/降级）是基础，复审是"让配置不陈旧"。业务变了、成本分布变了，配额/阈值/降级也要跟着调，否则预算治理失效。定期复审是成本治理的"保鲜"机制。

• 理解成本看板的三类视图（趋势、占比、预测）
• 掌握预测模型的校准
• 理解预测支撑预算编制

成本看板三类视图：趋势视图（成本随时间变化，看增长/异常）、占比视图（成本按租户/功能/模型占比，看结构）、预测视图（成本未来走势，看预算够不够）。预测模型校准：预测基于历史趋势 + 业务驱动（流量、活动、新功能），要校准——用历史数据回测预测准确性（预测误差），调整模型参数（季节性、趋势、异常）使预测更准；预测要区分"基线增长"与"事件影响"（活动、版本发布），避免误预测。预测支撑预算编制：用预测的成本给下月/下季预算提供依据，预测准才能定合理的预算额度；预测误差要监控，误差大则调整模型或预算。三类视图联动：趋势看实际、占比看结构、预测看未来，共同支撑预算规划与预警。

成本看板是"看现在（趋势/占比）+ 看未来（预测）"。预测的价值是"为预算编制提供依据"，但预测要校准（回测误差、区分事件）才可信。预测准，预算才定得准；看板三类视图构成完整的成本决策视图。

• 理解基于流量趋势的 token 消耗预测
• 掌握预算预警
• 理解容量预留策略

成本预测与容量规划要"预测 token 消耗 → 预警预算 → 规划预留"。token 消耗预测：基于流量趋势（请求量 × 单请求 token 分布）预测未来 token 消耗——流量预测（按历史趋势、活动、版本）乘单请求平均 token（含输入/输出/缓存），得到预测 token 消耗与成本。预算预警：预测 token/成本到达预算阈值时提前预警（如预测 X 天后超预算），让运营提前处置（降级、提预算、优化）。容量预留：基于预测的峰值/长尾 token 消耗规划资源——自建推理按预测峰值预留 GPU（或用 API 弹性），预留过多浪费、过少不够；用"预测 + 缓冲区"规划预留，低成本预留（API 弹性）与高成本预留（自建）结合。关键：预测驱动"预算预警 + 容量预留"，避免"超预算才知道"或"容量不够才扩容"。

预测是"前瞻"能力——把"事后止损"变成"事前规划"。token 预测驱动预算预警（提前知道要超）与容量预留（提前备资源）。预测准 + 预警早 + 预留合理，是 FinOps 主动管理的核心。