Token、成本和延迟经常挤在同一张图里，看起来像一组指标，其实各自回答不同的问题。Token 说明模型处理了多少内容，成本说明为这些调用付了多少钱，延迟说明用户等了多久。它们互有关联，却不能互相代替。
一段很长的输入可能因为使用低价模型而不贵；多个模型并行调用会消耗很多 Token，但总响应时间未必按调用次数增长；成本没有变化，也不表示性能稳定。分析时如果只盯着 Trace 的总数，很容易把原因看反。
先看一条模型调用
仍以业务问答 Agent 为例。用户询问“昨天哪个广告计划消耗异常”，系统先检索口径，再让分析模型判断异常，最后由另一个模型组织回答。要解释这次请求为什么慢或贵，应先打开其中每个 Generation，而不是直接从项目总成本下结论。
一次 Generation 至少要能看到模型名称、输入与输出用量、开始和结束时间。Token 是模型自己的计量单位，不等于汉字数，也不保证不同模型使用同一种分词方式。输入通常包括系统指令、历史消息、本轮问题和检索上下文；输出是模型生成的内容。现在不少模型还会单独报告缓存、推理、音频或图像用量，所以“输入加输出”只是最简单的情况。
手动上报 usage 时有个容易踩中的坑。Langfuse 将 usage_details 里的每个键视为互不重叠的桶：一个 Token 只能进入一个桶，total 只是这些桶的总和。假如供应商返回的 input 已经包含缓存 Token，而你又把同一批 Token 写进 input_cached_tokens，平台会显示两次，推算成本也会偏高。通过 OpenTelemetry GenAI 属性接入时，Langfuse 会对部分包含式计数做归一化；直接通过 SDK/API 写入 Langfuse 风格的扁平 usage_details 时，值会原样保存，需要接入方先转成不重叠的计数。
成本建立在用量和价格之上。模型服务若直接返回实际 cost，优先记录这个值；没有实际成本时，平台根据模型名称、用量类型和价格表推算。推算结果要核对模型是否匹配，usage 的键能否对应价格项，缓存价、企业折扣和自托管模型成本是否已反映。带隐藏推理 Token 的模型尤其不能只靠可见文本反推费用。
在 Langfuse 中，Generation 和 Embedding 类型的 Observation 可以保存模型、usage_details 与 cost_details。多数官方或框架集成会自动采集，手动接入则需要自己写入。Langfuse 优先使用上报的成本，缺失时再按模型定义推断。项目的 Settings → Models 可以检查默认匹配结果或增加自定义模型价格；价格变更通常只作用于之后进入的数据，不要默认历史记录会自动重算。
延迟要沿着时间线看
Trace 总时长是用户从发起请求到拿到结果经历的时间，Generation 时长只覆盖某次模型调用。流式回答还要关心首 Token 时间（TTFT），因为用户通常从看到第一个字开始感知系统“有响应”。没有记录首个流式 Token 事件，就不能拿完整调用时长冒充 TTFT。
多步骤 Agent 的总耗时也不是所有节点耗时之和。串行工具会一段接一段地增加等待，并行分支则由最晚结束的那条路径决定。如果两次检索各花一秒但同时执行，用户不会因此多等两秒。排查慢请求时，应该沿时间线找关键路径，再判断时间耗在模型排队、网络、工具接口、重试，还是应用自身处理。
回到这次问答：如果“生成用户回答”只用了很少 Token，却占去大部分时间，应查模型响应和网络；如果“判断异常原因”重复执行三次，成本可能来自重试；如果输入 Token 突然翻倍，常见原因是每轮都重复携带完整会话历史，或者检索返回了过多文档。数字只有落到具体步骤和业务条件上，才有解释力。
从单次请求走向 Dashboard
单条 Trace 用于解释个案，Dashboard 用于发现变化。两者不能互相取代。看板上的成本尖峰需要下钻到具体 Trace 才能找到原因，而一次昂贵请求也不一定代表整体系统失控。
第一版生产看板不必放几十张图。它需要让使用者看清流量、错误、响应速度和资源消耗是否发生变化，再补一两个已经定义清楚的质量信号。对于业务问答 Agent，可以从这些问题出发：
- 今天请求量是否异常，生产和测试流量有没有混在一起？
- 错误率和高分位延迟是否上升，集中在哪个场景或模型？
- 总 Token 与总成本的增长来自流量，还是单次请求变贵？
- 用户点踩是否与某个 Prompt 版本、模型或高延迟区间同时出现？
这些问题决定图表，图表不该反过来决定团队看什么。总成本上涨可能只是用户增加，因此还要看单次请求成本；平均延迟会掩盖少数极慢请求，因此至少同时观察中位数和 p95；质量信号若口径尚未稳定，宁可暂时不放，也不要用含义模糊的分数装点页面。
分析维度同样重要。environment 用来分开生产与测试，Trace 名称区分业务场景，模型和 Prompt 版本解释技术变更，用户或租户帮助发现异常消耗集中在哪里。一个指标如果无法按这些条件切开，只能告诉你“变了”，很难告诉你“哪里变了”。
Langfuse 提供预置的 Home 和 curated dashboards，可直接查看延迟、成本和平台使用情况。需要贴合业务时，进入 Dashboards → Widgets 创建组件：选择 Trace、Observation 或 Score 数据源，再配置指标、分组、筛选条件和图表。随后把组件加入自定义 Dashboard。
一个简洁的生产看板可以这样排：最上方是请求量和错误率，用来判断系统是否正常承载流量；中间放中位数、p95 延迟及成本趋势；下方再看模型、Prompt 版本和用户反馈。排列顺序贴近排查顺序，发现波动后能继续筛选并下钻到 Trace。
Langfuse v4 对部分 Dashboard 行为有所调整。Widget 可以带自己的环境筛选；一旦设置，它会覆盖 Dashboard 环境选择器对该 Widget 的影响。复制看板配置或跨项目导入时，要检查这种局部筛选，否则同一页面上的图可能不在看同一个环境。
看板建好后需要做一次人为可控的验算。发送几条测试请求，让其中一条产生已知错误，另一条使用不同 Prompt 版本，再核对时间范围、环境、数量、Token 和成本是否符合预期。图能画出来，只能证明查询执行了；分母、时间窗口或环境错了，趋势仍然会误导人。
做到这一步，团队已经能在两个尺度上工作：从 Generation 解释一笔具体消耗，从 Dashboard 发现值得调查的变化。预算分摊、容量规划和告警门槛属于生产治理问题，可以等基础口径稳定后再做。
参考资料
系列目录：AI 应用可观测性与评估