exploring-llm-costs

探索 LLM 成本

PostHog 会在摄取时为每个 $ai_generation 和 $ai_embedding 事件附加单次调用成本元数据。所有成本问题最终都归结为对这两种事件进行聚合，区别只在于分组、筛选和比较的方式。

本技能涵盖常见的成本调查：总支出、分类明细（模型、提供商、用户、追踪、自定义属性）、Token 和缓存命中分析、回归问题调试，以及将结果物化为洞察、仪表板或告警。

工具

工具	用途
posthog:query-trends	原生成本趋势，支持求和、分类明细和比较
posthog:execute-sql	用于任意成本聚合的临时 HogQL 查询——本技能的主力工具
posthog:query-llm-traces-list	列出包含汇总成本、Token 和错误指标的追踪
posthog:query-llm-trace	显示单条追踪中所有事件的成本明细
posthog:read-data-schema	查找可用于分类明细的自定义属性
posthog:insight-create	将成本图表保存为洞察
posthog:dashboard-create	将成本洞察组合到仪表板中
posthog:alert-create	成本超过阈值时发出告警
posthog:generate-app-url	生成带有区域和项目限定信息的 UI 链接

核心规则

以下三条规则涵盖了大多数常见问题：

• 汇总时对 $ai_total_cost_usd 求和，绝不要对各组成部分求和。 各组成部分会漏掉请求和网页搜索费用。UI 中的成本单元格会对 event IN ('$ai_generation', '$ai_embedding') 范围内的 $ai_total_cost_usd 求和；请采用相同方式。完整架构和原因请参阅成本属性。
• 成本查询始终包含 $ai_generation 和 $ai_embedding，除非能确认项目未使用嵌入；遗漏它们会导致统计值偏低且不会发出提示。$ai_trace 和 $ai_span 不包含可汇总的成本；某些 SDK 封装会将 $ai_total_cost_usd 重复写入 $ai_trace，因此请勿在汇总中包含它，否则会重复计数。
• 始终设置时间范围。 不设置时间范围的成本查询会扫描整个事件表。

$ai_total_cost_usd 在摄取时通过三种路径之一设置（透传、自定义定价、自动查找）。成本看起来不对时，请先读取 $ai_cost_model_source——有关优先级规则和诊断查询，请参阅成本来源。

缓存命中计算取决于提供商报告的缓存 Token 是否包含在 $ai_input_tokens 中。始终根据每个事件的 $ai_cache_reporting_exclusive 标记进行判断，绝不要根据提供商名称判断——独占与非独占的计算公式请参阅缓存核算。

distinct_id 是标准用户维度。客户通常会附加自定义属性（feature、tenant_id、workflow_name）——分组前请使用 posthog:read-data-schema 查找这些属性。不要猜属性名称。

工作流：统计指定时间段内的总支出

posthog:execute-sql
SELECT round(sum(toFloat(properties.$ai_total_cost_usd)), 4) AS total_cost_usd
FROM events
WHERE event IN ('$ai_generation', '$ai_embedding')
    AND timestamp >= now() - INTERVAL 30 DAY

工作流：成本明细

所有成本问题都可以套用同一模板——按某个维度分组，并聚合 $ai_total_cost_usd。可直接运行的示例请参阅分类明细模式：

• 随时间变化的成本（按日）
• 按模型统计成本
• 按用户统计成本（支出最高的用户）
• 按追踪统计成本（成本最高的追踪）
• 按自定义维度统计成本
• 单次调用成本分布
• 输入、输出和缓存成本分析

工作流：检查单条跟踪记录的费用

当用户粘贴跟踪记录 URL 并询问费用时，获取该跟踪记录并展示每个事件的明细：

posthog:query-llm-trace
{ "traceId": "<trace_id>", "dateRange": {"date_from": "-30d"} }

按跨度名称或模型分组，对返回事件中的 $ai_total_cost_usd 求和，以显示哪些步骤推高了费用。跟踪记录响应已包含便于查看的 totalCost。

工作流：调试费用回归

“我们的 LLM 账单突然增加了——为什么？”几乎总是以下原因之一：调用次数增加、提示词变长、使用了新模型，或缓存命中率发生变化。按顺序逐一排查——参阅回归调试了解 5 步操作指南。

工作流：将结果整理为洞察、仪表板或告警

临时查询回答问题后，可将其保存为洞察、汇总到仪表板中，或设置告警。参阅整理查询结果，获取可直接运行的 posthog:insight-create、posthog:dashboard-create 和 posthog:alert-create JSON。

构建 UI 链接

切勿手动编写 https://app.posthog.com/... 链接。该主机名会丢失区域和项目路径前缀，因此用户会被重定向到登录页面，而不是你指定的页面。

• 优先使用工具返回的规范 URL。 query-llm-traces-list 和 query-llm-trace 会返回 _posthogUrl——请展示该值。对于单条跟踪记录，在该 URL 后追加 ?timestamp=<url_encoded_iso>（跟踪记录中最早事件的时间）；返回的链接不包含时间戳，不带时间戳时，跟踪记录页面会从固定的早期日期开始扫描，而不是查看跟踪记录所在的十分钟时间窗口。
• 否则，使用 generate-app-url 构建链接。 它会解析正确的区域主机名和 /project/<id>/ 前缀（例如 https://us.posthog.com/project/2/ai-observability/traces）。通过 params 传入具体 ID，切勿将其直接写入路径。
  • 仪表板：generate-app-url {url: "/ai-observability/dashboard"}
  • 跟踪记录列表（按费用排序）：generate-app-url {url: "/ai-observability/traces"}
  • 生成记录列表：generate-app-url {url: "/ai-observability/generations"}
  • 用户列表（按用户查看费用）：generate-app-url {url: "/ai-observability/users"}
  • 单条跟踪记录：generate-app-url {url: "/ai-observability/traces/{id}", params: {id: "<trace_id>"}}

generate-app-url 无法表示查询参数，因此请自行在单条跟踪记录链接后追加上文所述的 ?timestamp=<url_encoded_iso>。

始终提供 UI 链接，方便用户直观验证。

让此技能保持最新

提供商的报告行为（哪些 token 按包含或不包含方式统计、费用显示在哪里）会随时间变化；同一提供商在不同 SDK 版本中的行为也可能不同。为避免信息过时：

• 根据事件级标记（$ai_cache_reporting_exclusive、$ai_cost_model_source）进行分支判断，而不要硬编码提供商或模型名称。这些标记是采集流程针对具体事件解析得出的结果，是正确的事实来源。
• 汇总时始终以 $ai_total_cost_usd 为准——优先使用它，而不是将各项成本相加；随着新增成本类别，各项成本的合计可能不再准确。
• 对于此处未涵盖的内容（新增成本类别、定价查询方式变更、新增提供商），请先运行 posthog:docs-search 搜索 “calculating costs” 或 “AI observability”，而不要依赖本文件中的硬编码规则。
• 如果发现此技能与 UI 显示不一致，请以 UI 为准，并标记此技能以便更新。

提示

• 始终设置时间范围——不设置时间范围的成本查询会扫描整个事件表
• Token、成本、模型和 $ai_trace_id 属性位于 events 表中，但消息_内容_（$ai_input / $ai_output_choices）仅位于 posthog.ai_events 表中；如果需要同时查看内容和成本，请加载 exploring-llm-traces 技能
• 汇总成本时，始终同时纳入 $ai_generation 和 $ai_embedding；嵌入的单次调用成本很低，但规模扩大后会累积起来
• 成本在数据摄取时写入（参见计算 LLM 成本）——如果 $ai_total_cost_usd 缺失或为零，请先读取 $ai_cost_model_source：passthrough 表示 SDK 提供了成本；custom 表示使用自定义 Token 价格；openrouter / manual 表示自动查询；缺失表示未匹配到该模型（不常见的自定义模型、微调模型）。使用 Grep 查询：按 (model, source) 统计 countIf(properties.$ai_total_cost_usd IS NULL)
• 自定义定价使用的是每 Token价格，而不是每百万 Token 价格——如果采用自定义价格的模型看起来贵了或便宜了约 1M 倍，这几乎总是问题所在
• 仅在明确要求时，才从成本总额中排除出错的调用——许多错误情况下，提供商仍会收费；将其纳入统计才能得出真实账单
• 计算每用户总额时，排除 distinct_id = properties.$ai_trace_id 的行——某些 SDK 在未设置用户时，会默认将 distinct_id 设为 trace ID
• 同一 trace 中的 $ai_generation + $ai_embedding 事件成本可以累加；对 $ai_span 求和会得到零。某些 SDK 封装的 $ai_trace 可能带有 $ai_total_cost_usd——不要将其纳入汇总，否则会重复计数。$ai_evaluation 事件也带有成本，但不属于默认 UI 汇总；仅当用户明确希望将评估支出计入总额时才纳入
• 缓存命中率取决于 $ai_cache_reporting_exclusive——应根据事件级标记进行分支判断，而不是根据提供商或模型名称。提供商行为和 SDK 版本会变化；此标记是数据摄取时针对特定事件确定的最终结果
• 回答“为什么 X 这么贵？”时，请同时展示成本和 Token 拆分——用户几乎总是想知道该缩短提示词、缩短输出，还是切换模型
• 创建自定义仪表板之前，请先检查默认的 /ai-observability/dashboard 图表是否已能回答问题——重新创建只会造成重复工作
• 对于大型租户，将常用成本查询物化为洞察，并通过 insight-query 重用；临时 SQL 适合一次性查询，但每次加载仪表板都重新运行会很耗费资源

参考资料

• 成本属性 — 完整的属性架构、总成本依据和事件集规则
• 成本来源 — 成本如何在数据摄取时设置，以及诊断查询
• 缓存统计 — 独占型与包含型提供商、缓存命中率公式
• 细分模式 — 常见细分方式的 SQL 配方
• 回归问题排查 — 成本激增的 5 步操作指南
• 物化 — 洞察、仪表板和告警 JSON

相关技能

• analyzing-expensive-users — 哪些用户带来了支出，以及他们的使用模式是否能解释这些支出
• exploring-llm-traces — 检查细分结果所指向的高成本 trace