用 PostHog 探索 LLM 成本：从总花费、模型/用户/链路分解到回归告警的完整实战指南-二趣网

用 PostHog 探索 LLM 成本：从总花费、模型/用户/链路分解到回归告警的完整实战指南

【免费下载链接】posthog:hedgehog: PostHog is the leading platform for building self-driving products. Our developer tools – AI observability, analytics, session replay, flags, experiments, error tracking, logs, and more – capture all the context agents need to diagnose problems, uncover opportunities, and ship fixes. Steer it all from Slack, web, desktop, or the MCP.项目地址: https://gitcode.com/GitHub_Trending/po/posthog

PostHog 会在采集（ingestion）阶段为每一条$ai_generation与$ai_embedding事件附加逐调用（per-call）的成本元数据，因此一切成本问题最终都归结为对这两类事件的一次聚合查询——差异只在于你如何分组、过滤和对比。本指南以 exploring-llm-costs SKILL 及其六份引用参考文档为主体，结合仓库内 AI 可观测性后端的真实实现，系统讲解如何在 PostHog 中统计总花费、按模型/供应商/用户/链路/自定义维度拆分成本、分析 token 与缓存命中经济学、排查成本突增（regression），并把结论固化到 Insight、Dashboard 与 Alert 中。读完你就能针对“我们在 LLM 上花了多少钱”“哪个模型/用户/功能最贵”“成本为什么飙升”这类问题，直接给出可复现的 SQL 与 MCP 工具调用方案。

成本数据的核心模型：成本属性与事件集规则

所有成本都以美元（USD）计价，在采集时按事件逐条写入。PostHog 根据「模型 + 供应商」与 token 数量推导成本——你不能手工设置并指望它长期可信。成本属性只存在于$ai_generation与$ai_embedding两类事件上，完整属性见 cost properties 参考文档。

属性	出现位置	含义
`$ai_total_cost_usd`	generation、embedding	单次调用的权威总成本，rollup 时必须用它
`$ai_input_cost_usd`	generation、embedding	输入 token 产生的成本
`$ai_output_cost_usd`	generation、embedding	输出 token 产生的成本
`$ai_request_cost_usd`	generation、embedding	每次请求的固定费用（如 Anthropic 的 per-request fee），通常为`0`
`$ai_web_search_cost_usd`	generation、embedding	generation 内部 web-search 工具调用的成本，通常为`0`
`$ai_audio_cost_usd`	generation	模型按单独费率计费的音频模态成本，通常为`0`
`$ai_image_cost_usd`	generation	图像模态成本，通常为`0`
`$ai_video_cost_usd`	generation	视频模态成本，通常为`0`
`$ai_input_tokens`	generation、embedding	发给模型的 token（跨模态总计）
`$ai_output_tokens`	generation	模型返回的 token（跨模态总计）
`$ai_total_tokens`	generation、embedding	输入 + 输出 token
`$ai_cache_read_input_tokens`	generation	由供应商提示词缓存（prompt cache）命中的输入 token
`$ai_cache_creation_input_tokens`	generation	写入供应商提示词缓存的输入 token
`$ai_reasoning_tokens`	generation	推理模型的思考 token（按输出计费）
`$ai_model`	generation、embedding	成本的首要分解维度
`$ai_provider`	generation、embedding	次要分解维度（openai、anthropic…）
`$ai_is_error`	generation	在成本汇总中排除/包含失败调用
`$ai_trace_id`	所有`$ai_*`事件	把成本汇总到链路（trace）层级
`$ai_session_id`	所有`$ai_*`事件	把成本汇总到会话层级（把相关 trace 分组）

汇总时永远 sum`$ai_total_cost_usd`，不要加和分量

在采集阶段，$ai_total_cost_usd = input + output + request + web_search（加上任何模态成本）。只对$ai_input_cost_usd + $ai_output_cost_usd求和会悄悄丢掉 request 费用和 web-search 费用——对 Anthropic 的请求费以及任何带工具增强的 generation 而言，这两项真实且非零。UI 中的成本单元格正是按event IN ('$ai_generation', '$ai_embedding')对$ai_total_cost_usd求和，请与它保持一致。这一点在仓库后端也有实现印证：AI 可观测性仪表盘模板在构建 "Total cost (USD)" 与 "Cost per user (USD)" 看板瓦片时，均以$ai_generation事件配合math: "sum"、math_property: "$ai_total_cost_usd"聚合（见 dashboard_templates.py）。

事件集规则：trace 与 evaluation 事件

$ai_trace与$ai_span事件不携带可汇总的成本。要得到某条 trace 的总成本，需按其$ai_trace_id匹配，对其下的$ai_generation与$ai_embedding事件的$ai_total_cost_usd求和。部分 SDK 封装器会出于便利把$ai_total_cost_usd复制到$ai_trace上，但查询执行器依然只按event IN ('$ai_generation', '$ai_embedding')聚合——不要把事件集混用，否则会重复计数。
$ai_evaluation事件也会输出成本属性（采集时与$ai_generation、$ai_embedding一同计费），但内置的/ai-observability汇总与查询执行器不把它们计入成本。只有当用户明确要“含评估的总花费”时，才把$ai_evaluation显式加进事件过滤（如event IN ('$ai_generation', '$ai_embedding', '$ai_evaluation')），并说明这是扩展口径；否则保持 generation + embedding 以对齐 UI。

用户维度

distinct_id是规范的用户维度——客户通常在 SDK 中设置它。需要更丰富的按用户拆分时，使用人员属性（如email、company_tier），先通过posthog:read-data-schema探查存在哪些属性，不要凭空猜测名字。

成本从哪来：三种来源路径与诊断查询

成本可以通过三种方式到达事件上，采集端按以下优先级应用（权威规则见 PostHog 官方文档 "Calculating LLM costs"）：

预计算（passthrough）——SDK/手工采集直接设置$ai_input_cost_usd、$ai_output_cost_usd、$ai_request_cost_usd、$ai_web_search_cost_usd。采集端原样保留并把$ai_total_cost_usd填为它们的和。适用于调用方已知成本的情形。
自定义定价（custom）——SDK 设置$ai_input_token_price/$ai_output_token_price（必选成对），可选$ai_cache_read_token_price、$ai_cache_write_token_price、$ai_request_price、$ai_web_search_price。采集端乘以 token 数得到成本。Token 价格是“每 token”单价，不是每百万 token。
自动模型匹配（自动查找）——采集端按$ai_model+$ai_provider查价（优先 OpenRouter，其次手工表兜底）。

三个元数据属性可以告诉你走了哪条路径——成本看起来不对时先读它们（详见 cost sources 参考文档）：

属性	含义
`$ai_model_cost_used`	定价查找命中的规范模型 id（可能不同于`$ai_model`）
`$ai_cost_model_source`	`openrouter`\|`manual`\|`custom`\|`passthrough`
`$ai_cost_model_provider`	查找所使用的供应商

诊断：按模型和来源统计零成本/空成本调用

当某个模型的$ai_total_cost_usd为 null 或 0 时，同时按模型和$ai_cost_model_source分组，才能看清每个模型的零成本调用分别来自哪条采集路径：只有source = NULL的行说明采集端从未匹配到定价条目（修复方式：添加自定义定价，或修正$ai_model/$ai_provider）；source = 'custom'且成本为 0 则是显式配置的零价格（通常是$ai_input_token_price/$ai_output_token_price配错）。不按来源分组时，这两种情况看起来完全一样。

posthog:execute-sql SELECT properties.$ai_model AS model, properties.$ai_cost_model_source AS source, count() AS calls, countIf(toFloat(properties.$ai_total_cost_usd) = 0 OR properties.$ai_total_cost_usd IS NULL) AS zero_cost_calls FROM events WHERE event = '$ai_generation' AND timestamp >= now() - INTERVAL 7 DAY GROUP BY model, source ORDER BY zero_cost_calls DESC

三条核心规则

大部分出错场景都被三条规则覆盖（原文见 SKILL.md）：

Rollup 用$ai_total_cost_usd求和，绝不用分量相加。分量会漏掉 request 与 web-search 费用。UI 的成本单元格就是按event IN ('$ai_generation', '$ai_embedding')对$ai_total_cost_usd求和，照做即可。完整属性与理由见 cost properties。
成本查询务必同时包含$ai_generation和$ai_embedding，除非项目可证明不使用 embedding——漏掉它们会静默少算。$ai_trace和$ai_span不携带可汇总成本；部分 SDK 封装器会把$ai_total_cost_usd复制到$ai_trace，所以不要把它纳入 rollup，否则会重复计数。
永远设置时间范围。没有时间范围的成本查询会扫描整张 events 表。

$ai_total_cost_usd在采集时经由三条路径之一写入（passthrough / custom / 自动查找）。当成本看起来不对时，先读$ai_cost_model_source（见 cost sources 的优先级规则与诊断查询）。

缓存命中的数学计算取决于供应商对缓存 token 的报数方式（包含于$ai_input_tokens或独立于它）。永远按事件级标志$ai_cache_reporting_exclusive分支，不要按供应商名字硬编码——公式见 cache accounting。

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

工作流二：成本分解（breakdown）

每个成本问题都是同一个模板的变体——按某个维度分组、对$ai_total_cost_usd聚合。breakdown patterns 参考文档提供了七类可直接运行的 SQL 配方：

按天看成本随时间变化（Cost over time）
按模型看成本（Cost by model）
按用户看成本（Cost by user，头部消费者）
按链路看成本（Cost by trace，最贵链路）
按自定义维度看成本（Cost by custom dimension）
单次调用成本分布（Cost per call）
输入 vs 输出 vs 缓存经济学（Input vs output vs cache economics）

按天看成本（附 token 与调用量）

posthog:execute-sql SELECT toDate(timestamp) AS day, round(sum(toFloat(properties.$ai_total_cost_usd)), 4) AS cost_usd, sum(toInt(properties.$ai_input_tokens)) AS input_tokens, sum(toInt(properties.$ai_output_tokens)) AS output_tokens, count() AS calls FROM events WHERE event IN ('$ai_generation', '$ai_embedding') AND timestamp >= now() - INTERVAL 30 DAY GROUP BY day ORDER BY day

按模型看成本

posthog:execute-sql SELECT properties.$ai_model AS model, properties.$ai_provider AS provider, count() AS calls, round(sum(toFloat(properties.$ai_total_cost_usd)), 4) AS cost_usd, round(avg(toFloat(properties.$ai_total_cost_usd)), 6) AS avg_cost_per_call, sum(toInt(properties.$ai_input_tokens)) AS input_tokens, sum(toInt(properties.$ai_output_tokens)) AS output_tokens FROM events WHERE event IN ('$ai_generation', '$ai_embedding') AND timestamp >= now() - INTERVAL 30 DAY GROUP BY model, provider ORDER BY cost_usd DESC

按用户看成本（头部消费者）

注意排除distinct_id被默认成 trace id 的行——部分 SDK 在没有设置用户时会把 distinct_id 默认成 trace ID：

posthog:execute-sql SELECT distinct_id, count() AS calls, countDistinct(properties.$ai_trace_id) AS traces, round(sum(toFloat(properties.$ai_total_cost_usd)), 4) AS cost_usd FROM events WHERE event IN ('$ai_generation', '$ai_embedding') AND timestamp >= now() - INTERVAL 30 DAY AND ( properties.$ai_trace_id IS NULL OR distinct_id != properties.$ai_trace_id ) -- 过滤掉 distinct_id 被默认成 trace id 的行 GROUP BY distinct_id ORDER BY cost_usd DESC LIMIT 25

想要更丰富的按用户视图（带人员属性），/ai-observability/users页面本身就是这个形态——先去看看它，再决定是否手写。

按链路看成本（最贵链路）

posthog:execute-sql SELECT properties.$ai_trace_id AS trace_id, count() AS llm_calls, round(sum(toFloat(properties.$ai_total_cost_usd)), 4) AS cost_usd, sum(toInt(properties.$ai_input_tokens)) AS input_tokens, sum(toInt(properties.$ai_output_tokens)) AS output_tokens, min(timestamp) AS started_at FROM events WHERE event IN ('$ai_generation', '$ai_embedding') AND timestamp >= now() - INTERVAL 7 DAY AND isNotNull(properties.$ai_trace_id) GROUP BY trace_id ORDER BY cost_usd DESC LIMIT 25

然后用posthog:query-llm-trace深入最贵的几条链路，看哪些 span 与 generation 在驱动成本。

按自定义维度看成本

客户常附加自己的维度（feature、tenant_id、workflow_name）。先探查、再分组：

posthog:read-data-schema，kind: "event_properties"、event_name: "$ai_generation"，找出自定义键；
posthog:read-data-schema，kind: "event_property_values"，抽查取值是否正确；
按发现的属性分组：

posthog:execute-sql SELECT properties.feature AS feature, round(sum(toFloat(properties.$ai_total_cost_usd)), 4) AS cost_usd, count() AS calls FROM events WHERE event IN ('$ai_generation', '$ai_embedding') AND timestamp >= now() - INTERVAL 30 DAY AND isNotNull(properties.feature) GROUP BY feature ORDER BY cost_usd DESC

不要猜自定义属性的名字——它们因项目而异。

单次调用成本分布（用分位数看偏态）

总和会掩盖偏态。用分位数看是否少数调用占大头：

posthog:execute-sql SELECT properties.$ai_model AS model, round(quantile(0.5)(toFloat(properties.$ai_total_cost_usd)), 6) AS p50_cost, round(quantile(0.95)(toFloat(properties.$ai_total_cost_usd)), 6) AS p95_cost, round(quantile(0.99)(toFloat(properties.$ai_total_cost_usd)), 6) AS p99_cost, round(max(toFloat(properties.$ai_total_cost_usd)), 6) AS max_cost FROM events WHERE event = '$ai_generation' AND timestamp >= now() - INTERVAL 7 DAY GROUP BY model ORDER BY p99_cost DESC

输入 vs 输出 vs 缓存经济学

输出 token 通常比输入贵 3–5 倍，缓存读约是输入的 10%。拆分花费以找到优化目标：

posthog:execute-sql SELECT properties.$ai_model AS model, round(sum(toFloat(properties.$ai_input_cost_usd)), 4) AS input_cost, round(sum(toFloat(properties.$ai_output_cost_usd)), 4) AS output_cost, round(sum(toFloat(properties.$ai_request_cost_usd)), 4) AS request_cost, round(sum(toFloat(properties.$ai_web_search_cost_usd)), 4) AS web_search_cost, round(sum(toFloat(properties.$ai_total_cost_usd)), 4) AS total_cost, sum(toInt(properties.$ai_input_tokens)) AS input_tokens, sum(toInt(properties.$ai_output_tokens)) AS output_tokens, sum(toInt(properties.$ai_cache_read_input_tokens)) AS cache_read_tokens, sum(toInt(properties.$ai_cache_creation_input_tokens)) AS cache_write_tokens, round( if( any(properties.$ai_cache_reporting_exclusive) = 'true', sum(toInt(properties.$ai_cache_read_input_tokens)) / nullIf(sum(toInt(properties.$ai_input_tokens)) + sum(toInt(properties.$ai_cache_read_input_tokens)) + sum(toInt(properties.$ai_cache_creation_input_tokens)), 0), sum(toInt(properties.$ai_cache_read_input_tokens)) / nullIf(sum(toInt(properties.$ai_input_tokens)), 0) ), 3 ) AS cache_hit_rate FROM events WHERE event = '$ai_generation' AND timestamp >= now() - INTERVAL 30 DAY GROUP BY model ORDER BY total_cost DESC

cache_hit_rate使用 cache accounting 中供应商感知的公式——它分支于$ai_cache_reporting_exclusive，因此对 exclusive 和 inclusive 两类供应商分母都正确，且无需硬编码任何供应商或模型名。若单个模型在不同事件间混用了两种报数风格（不常见），请在 GROUP BY 里加$ai_cache_reporting_exclusive拆分，而不是用any()。

排名与汇总请基于total_cost——只加 input/output 分量会丢掉 request 与 web-search 费用，并可能与/ai-observabilityUI 产生偏差。如果某模型的request_cost或web_search_cost在total_cost中占比可观，那就是另一个优化杠杆（例如对话更频繁的供应商、重工具 generation）。低cache_hit_rate且该模型支持提示词缓存时，提示词结构调整就能显著改变成本。

工作流三：检查单条链路的成本

用户粘贴一条 trace URL 并询问其成本时，抓取该 trace 并给出逐事件分解：

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

对返回的事件按 span 名或模型分组、对$ai_total_cost_usd求和，以定位是哪个步骤驱动了成本。trace 响应已附带totalCost作为便捷字段。

工作流四：排查成本突增（cost regression）

“我们的 LLM 账单跳涨了——为什么？”几乎总是以下四种原因之一：调用变多、提示词变大、换了新模型、缓存命中率变化。按顺序排查，完整的 5 步剧本见 regression debugging 参考文档。

Step 1 — 确认并圈定突增范围：按天输出 60 天成本、调用量与单调用均成本，对比跳变前后的calls与avg_cost_per_call。调用量翻倍是量的问题；单调用成本上升则是提示词、模型或缓存的问题。

posthog:execute-sql SELECT toDate(timestamp) AS day, round(sum(toFloat(properties.$ai_total_cost_usd)), 4) AS cost_usd, count() AS calls, round(sum(toFloat(properties.$ai_total_cost_usd)) / count(), 6) AS avg_cost_per_call FROM events WHERE event IN ('$ai_generation', '$ai_embedding') AND timestamp >= now() - INTERVAL 60 DAY GROUP BY day ORDER BY day

Step 2 — 观察模型组合漂移：用 breakdown patterns 的“按模型看成本”配方分别跑跳变前一周与后一周，做 diff。新$ai_model值出现、旧值消失都是强信号。

Step 3 — 排查提示词膨胀：按天+模型看平均输入/输出 token：

posthog:execute-sql SELECT toDate(timestamp) AS day, properties.$ai_model AS model, round(avg(toInt(properties.$ai_input_tokens)), 1) AS avg_input_tokens, round(avg(toInt(properties.$ai_output_tokens)), 1) AS avg_output_tokens FROM events WHERE event = '$ai_generation' AND timestamp >= now() - INTERVAL 30 DAY GROUP BY day, model ORDER BY day, model

Step 4 — 排查缓存退化：按天重跑“输入 vs 输出 vs 缓存经济学”配方并跟踪cache_hit_rate。缓存命中率下滑往往跟着一次系统提示词变更（使缓存前缀失效）。

Step 5 — 隔离到功能面：确定机制（调用变多/提示词变大/新模型/缓存变差）后，按能区分功能的自定义属性（如feature、workflow_name）分组，找出是哪个表面在作祟；再用posthog:query-llm-trace深入一条代表性链路。

工作流五：物化为 Insight、Dashboard 与 Alert

临时查询回答完问题后，把它们固化成 Insight，打包进 Dashboard，或接上 Alert。完整可运行的 JSON 见 materializing 参考文档。

保存“按天 LLM 成本”Insight

posthog:insight-create { "name": "Daily LLM cost", "query": { "kind": "TrendsQuery", "dateRange": {"date_from": "-30d"}, "series": [ { "kind": "EventsNode", "event": "$ai_generation", "math": "sum", "math_property": "$ai_total_cost_usd" }, { "kind": "EventsNode", "event": "$ai_embedding", "math": "sum", "math_property": "$ai_total_cost_usd" } ], "trendsFilter": { "formula": "A + B", "aggregationAxisPrefix": "$", "decimalPlaces": 2 } } }

两条 series 都必需——漏掉$ai_embedding会静默丢失 embedding 花费。若项目可证明不用 embedding（相关窗口内$ai_embedding的count()为 0），可去掉 series B 和公式，得到更简单的 Insight。

做“按用户成本”时，加第三条math: "dau"的 series 并把公式改为(A + B) / C。做分解时加breakdownFilter，breakdown: "$ai_model"或任意其他维度。这与仓库内置模板的结构一致：AI 可观测性默认仪表盘的成本瓦片以$ai_total_cost_usd为math_property（见 dashboard_templates.py），构建自定义看板时照此镜像即可。

加入 Dashboard

保存 Insight 后，用posthog:dashboard-create（或-update）打包。默认的/ai-observability/dashboard已包含 Cost、Cost per user、Cost by model 瓦片——构建自定义看板时镜像这一结构。

设置成本阈值告警

posthog:alert-create { "insight": <insight_id>, "name": "Daily LLM cost over $100", "subscribed_users": [<user_id>], "threshold": { "configuration": { "bounds": {"upper": 100}, "type": "absolute" } }, "condition": {"type": "absolute_value"}, "config": {"series_index": 0}, "enabled": true }

该 Insight 必须是单值趋势查询（例如粗体数字的每日成本）。subscribed_users必填且至少包含同一团队的一个用户 id。threshold.configuration.type取值"absolute"或"percentage"；condition.type取值"absolute_value"、"relative_increase"或"relative_decrease"。如果 MCP 工具拒绝该载荷，运行posthog:docs-search搜索 "alerts" 获取当前 schema——告警 API 可接受的枚举值会变化。

构造 UI 链接的规范

永远不要手写https://app.posthog.com/...链接。该主机名会丢掉区域（region）与项目前缀，导致用户被重定向到登录页而不是你想要的页面。正确做法：

优先使用工具返回的规范 URL。query-llm-traces-list和query-llm-trace会返回_posthogUrl——直接展示该值。对单条 trace，向该 URL 追加?timestamp=<url_encoded_iso>（即该 trace 最早事件的时间）；返回的链接不带时间戳，而没有时间戳时 trace 页面会从某个固定早期日期扫描，而不是围绕该 trace 的十分钟窗口。
否则用generate-app-url构造链接。它解析正确的区域主机与/project/<id>/前缀（例如https://us.posthog.com/project/2/ai-observability/traces）。具体 id 通过params传入，绝不内联进路径：
- Dashboard：generate-app-url {url: "/ai-observability/dashboard"}
- Traces 列表（按成本排序）：generate-app-url {url: "/ai-observability/traces"}
- Generations 列表：generate-app-url {url: "/ai-observability/generations"}
- Users 列表（按用户成本）：generate-app-url {url: "/ai-observability/users"}
- 单条 trace：generate-app-url {url: "/ai-observability/traces/{id}", params: {id: "<trace_id>"}}

generate-app-url无法表达查询参数，所以上面描述的单 trace 链接需要你自己追加?timestamp=<url_encoded_iso>。始终向用户展示一条 UI 链接，以便可视化验证。

让这份技能保持不过时

供应商的报数行为（哪些 token 是 inclusive/exclusive、哪些成本出现在哪里）会随时间漂移，同一供应商在不同 SDK 版本下也可能不同。为避免腐化：

分支于事件级标志（$ai_cache_reporting_exclusive、$ai_cost_model_source），而不是硬编码供应商或模型名——这些标志是采集端对该具体事件的最终解析答案，是唯一正确的事实来源。
$ai_total_cost_usd对 rollup 始终是权威的——优先用它，而不是加和分量，后者会随着新成本类别加入而漂移。
本文未覆盖的内容（新成本类别、定价查找变更、新供应商接入），先用posthog:docs-search搜索 "calculating costs" 或 "AI observability"，不要信任本文件中的硬编码规则。
如果发现本技能与 UI 矛盾，以 UI 为准，并标记本技能需要更新。

企业官网建设流程全解析