AI 应用的成本归因与单位经济学工程 2026:从 token 账单到客户级毛利的闭环架构

一、问题的提出:AI 应用从 PoC 到生产的成本黑洞

几乎所有 AI 应用的工程团队都经历过同一种震荡:产品 demo 阶段,一次对话的成本是 0.01 美元到 0.05 美元区间,业务方拿到首版 demo 时喜形于色,说"这个生意能跑";上线生产三个月后,当真实客户涌入、对话长度远超 demo、长上下文 + 多轮 + Function Calling + RAG 检索 + 结构化输出全部打开时,token 账单会以一种不可思议的速度膨胀。某中型 SaaS 团队的案例(据其工程负责人 2026-06 在社区分享)是最有代表性的样本:客户从 demo 期的 20 个增长到生产期的 1.4 万,月 token 成本从 230 美元暴涨到 11.2 万美元,而 ARPU 仅从 49 美元增长到 78 美元,毛利率从 +82% 直接打到 -19%。这种 PoC 与生产的成本剪刀差,根本不是 prompt 工程或模型选型可以修复的——它是**单位经济学(unit economics)**层面的系统性缺失。

这篇 2026-08-17 晚间 cron 的文章要解决的,正是这个"如何把 token 成本拆解到可解释、可治理、可优化的客户级单位经济学"问题。它与已有的几篇晚间技术文章形成互不交叉的覆盖:第 509 号"AI 应用可观测性商业产品平台工程 2026"讲的是 trace/eval/cost 一体化产品的横向对比;第 494 号"RAG 应用向量数据库全链路可观测性工程 2026"聚焦的是检索环节的可观测性;第 551 号"AI 应用的离线评估体系工程 2026"讲的是质量评估闭环。本文聚焦的是成本归因与单位经济学这条纵深线——从 token 三元组到客户级毛利,讲清楚"为什么亏钱"、"亏在哪"、"怎么止血"。

二、形式化:token 成本三元组 + 客户级单位经济学

我们把 AI 应用的单次请求成本形式化为三元组:

cost_per_request = tokens_in × P_in + tokens_out × P_out + fixed_per_request

其中 tokens_in / tokens_out 区分输入输出 token,因为主流模型(包括 2026 年仍在主导地位的 OpenAI / Anthropic / Google 的旗舰模型)对输入输出采用差异化定价,输入通常便宜 3-5 倍,而长上下文中输出侧的推理计算代价远高于输入侧(对应 KV cache 复用与 attention 计算的不对称);fixed_per_request 涵盖不随 token 线性增长的部分——Function Calling 的 tool description 注入、系统提示的 prefix、embedding 检索的一次性开销、Guardrails 的规则匹配成本。固定成本看似微不足道,但在高频小请求场景(例如客服 agent 的多轮短句)下,固定成本占比可能达到 18-35%,这是单位经济学中常被忽略的"地板成本"。

进一步,把单次请求聚合到客户级单位经济学:

gross_margin_per_tenant = ARPU_tenant - (Σ cost_per_request_tenant + engineering_amortized_tenant + support_amortized_tenant)

这里的关键洞察是AI 应用的边际成本非零且弹性巨大,这与传统 SaaS 软件"边际成本接近零"的常识完全相反。一款传统 SaaS CRM 多服务一个客户的边际成本可能只有 0.1 美元(数据库行 + API 调用);但一款 AI 应用多服务一个客户的边际成本可能就是 1.2-12 美元(对话长度 + 上下文大小 + tool 调用的复合效应),且这个成本会因为客户使用习惯(深度用户 vs 浅度用户)产生 10 倍以上的方差。

为完整刻画客户级成本,我们引入两个关键衍生量:

1. 归因图(attribution graph):把每一条 trace 通过 tenant_id → feature_id → request_id → cost_components 的有向图串联起来,实现"任何一个客户的任何一笔成本都可以下钻到具体功能的具体调用"。
2. 缓存弹性系数 ε:定义 ε = -∂(cost_per_request)/∂(cache_hit_rate),刻画缓存命中率提升对成本的边际改善率。不同功能、不同上下文长度、不同模型的 ε 值差异极大——长文档问答功能的 ε 通常在 0.6-0.85 之间,而短对话功能的 ε 可能只有 0.15-0.3。

这两个衍生量是后文工程实践中的核心抓手。

三、三层归因架构:trace → feature → tenant

最常见的失败模式是把所有 token 累加到一个全局计数器——"今天花了 X 美元"。这种看板虽然做起来最简单,但它完全无法回答"哪个客户在亏钱"这个核心问题。一个合格的归因架构必须是三层结构:

第一层:单次 trace 的 token 分解。每条 trace 必须明确区分五类 token 消耗:

• prompt_tokens:用户实际输入 + 系统提示 + 工具 schema
• completion_tokens:模型生成输出
• cache_hit_tokens:命中 prefix cache / semantic cache 的部分
• reasoning_tokens:推理类模型(如 o 系列、Claude extended thinking)的内部思考开销
• tool_tokens:Function Calling 中工具描述注入与 tool result 回传

把这五类明确分桶的好处是可归因性:当我们看到 completion_tokens 异常飙升,可以立即下钻到"是不是某条 prompt 让模型生成过长";当我们看到 cache_hit_tokens 比例下降,可以立即归因到"是不是 prompt template 改动导致 prefix 失效";当我们看到 reasoning_tokens 在某个 feature 上爆涨,可以判断"是不是该 feature 错误地启用了扩展思考模式"。OpenTelemetry 在 2025 年发布的 GenAI Semantic Conventions 已经把这五类作为标准属性,2026 年的事实标准是直接采纳这套规范。

第二层:feature 聚合。把所有 trace 按 feature_id(产品功能标识,例如 chat.search、doc.summarize、code.refactor)聚合,得到 per-feature 看板。这一层解决的是"产品哪个功能最烧钱"的问题——通常的发现是,80% 的 token 成本集中在 20% 的功能上,而且这 20% 的功能往往不是收入贡献最大的功能,这正是单位经济学反直觉的地方:产品经理的 KPI(收入)与 SRE 的 KPI(成本)在功能层面是错位的。

第三层:tenant 聚合。按 tenant_id(账号 / workspace / 计费 plan)聚合,得到 per-tenant 看板,这是单位经济学的最终落点。我们关心的核心指标是每个客户每天/每周/每月的 cost / ARPU / GM% / token_count,通过 trend + cohort + funnel 三类分析,回答"这个客户的成本曲线是否健康"、"这个客户的留存是否覆盖其累计 token 成本"等问题。

数据模型层面,推荐使用事件流 + OLAP Cube 的双层架构:trace 完成时写入 Kafka/Pulsar,消费侧构建 ClickHouse / Apache Pinot / Apache Doris 的实时 cube,字段至少包括 tenant_id / feature_id / model_id / cache_hit / cost_components / timestamp。OLAP 引擎的选择上,2026 年的工程实践倾向于 ClickHouse(单节点写入快、列存压缩好、SQL 兼容度高),但 ClickHouse 在 join 性能上略弱于 Doris,如果归因图需要复杂 join 应当优先 Doris。

反例:某团队把 token 成本只记到一个全局 Prometheus counter ai_token_cost_total,结果上线三个月后,当财务追问"X 客户的边际贡献是正还是负"时,工程团队花了整整 14 天才从原始 LLM 日志中手工聚合出来——这 14 天里,他们错过了三次价格调整窗口。这就是没有归因架构的代价。

四、缓存 ROI 与命中率经济学:semantic cache / prompt cache / KV cache 复用

缓存是 AI 应用成本优化的第一杠杆,但缓存本身有一个经济学属性容易被忽略:缓存是有成本的。不是"免费"的性能优化手段。

我们把三种主流缓存归一化到统一经济学:

1. Semantic cache(语义缓存):对 query 做 embedding,与缓存池中的 query 向量做相似度匹配,超过阈值则直接返回缓存的 completion。其经济学是 cache_cost = embedding_cost_per_match × lookups + storage_cost,miss_cost = full_LLM_cost,refresh_cost = embedding_recompute + cache_invalidation。其 ROI 公式 ROI = (miss_cost - cache_cost) × hit_rate - refresh_cost 决定了什么场景下值得启用。

2. Prompt cache / prefix cache(前缀缓存):Claude 与 Gemini 等模型原生支持 prefix 自动缓存,只要同一 prefix(系统提示 + 工具 schema + 长文档)在窗口期内被复用,该部分的 token 单价可以低至原来的 1/10。其经济学是"shared_prefix_tokens × (P_full - P_cached)"的累计节省,但要注意路由抖动会让 prefix cache 命中率骤降——一旦 LLM 流量被负载均衡器分散到多个 region,每个 region 的 prefix cache 都是独立的,综合命中率会从单 region 的 78% 跌到 12 region 的 31%,ROI 直接转负。

3. KV cache reuse(KV 复用):推理引擎内部的 attention KV 缓存,在 prefix 相同的多个请求间复用,这部分经济学对应用层不可见,但会影响端到端延迟与吞吐,进而影响成本曲线的非线性部分。

工程实践上,semantic cache 的 embedding 相似度阈值是一个高度依赖场景的超参数。客服 FAQ 场景下,query 长尾严重、模板化强,阈值设到 0.92 仍然有 60%+ 的命中率;但在代码生成场景下,query 长尾不明显,阈值设到 0.92 的命中率可能只有 8%,得不偿失。正确的做法是把阈值当作产品参数而非系统参数,由产品 owner 决定 trade-off:客服产品愿意用 5% 的误命中率换取 30% 的成本下降,因为误命中只是用户重说一遍;代码生成产品不能容忍 5% 的误命中,因为错误的代码会被用户直接部署。

告警设计上,关键阈值有三层:

• 全局 cache hit rate < 30% → 工程告警(底层缓存机制可能坏了)
• per-feature cache hit rate 出现 > 20% 的单日波动 → 产品告警(可能是 prompt template 改动或 prefix 失效)
• per-tenant cache hit rate < 5% → 客户告警(该客户的 query 类型几乎全部走 LLM,可能是攻击流量或异常使用)

五、模型路由与级联的成本-质量 Pareto

模型路由(model routing)是成本优化的第二杠杆,其经济学可以用成本-质量 Pareto 曲线刻画。2026 年的工程实践中,主流的路由策略已经从单一的"用最好的模型"演化为以下三类:

1. Cascade routing(级联路由):先用小模型(例如 GPT-4.1-mini / Claude Haiku / Gemini Flash)尝试,如果小模型的置信度低于阈值(基于 logprob 或 self-evaluation),再升级到大模型。其经济学是"绝大多数请求走便宜模型、少数疑难请求走贵模型",整体成本可以下降 60-80%,质量下降通常不超过 5 个百分点。路由器的设计关键是置信度阈值的选择:阈值过低会大量漏判(明明小模型能答的也走了大模型,成本没有下降),阈值过高会过度路由(明明大模型能答的也走了兜底,质量没保证)。

2. Speculative decoding(投机解码):小模型先生成候选 token,大模型并行验证,接受率高于阈值则采纳候选。这是一种"用大模型质量和小模型速度拼接"的技巧,其经济学优势是延迟下降 2-3 倍,但成本结构与 cascade 完全不同——投机解码的成本 ≈ 小模型成本 + 大模型验证成本,且验证成本与小模型接受率正相关,实际成本通常是小模型成本的 1.4-1.8 倍。

3. Hybrid routing(混合路由):根据 query 类型路由到不同模型池——代码类 query 走 CodeT5++ / Claude Sonnet,长文档类 query 走 Claude Opus / GPT-5,闲聊类 query 走 GPT-4.1-mini / Gemini Flash。这种路由的关键是 query 分类器的准确率,2026 年主流实现是用一个微调的小模型(例如 1B-3B 参数)做 query 分类,延迟 < 5ms,准确率 90-94%。

路由器的训练信号必须包含端到端毛利(GM)而非单次质量分。这是非常容易被忽略的反直觉点:如果只用"质量"作为训练目标,路由器会倾向于把任何稍有难度的 query 都路由到大模型,因为大模型的质量分总是更高;但如果用"端到端 GM"作为训练目标,路由器会在"该 query 让大模型处理的边际质量提升"与"该 query 让大模型处理的边际成本"之间做权衡,得到的 Pareto 工作点明显偏向 GM 优化。

Pareto 曲线的实测中,我们通常观察到以下规律:在 cache hit rate = 0 的零缓存基线下,cascade routing 可以把单位成本从 1.0 降到 0.35-0.45(下降 55-65%);在 cache hit rate = 0.6 的高缓存基线下,cascade routing 的边际效益下降到 15-25%,因为大多数请求已经被缓存接管。但 cache + cascade 联合优化时,cost 还可以再下降 8-15%,这是叠加效应。

六、客户级单位经济学:CAC / payback / retention vs LTV

AI 应用的单位经济学比传统 SaaS 复杂得多,核心差异在三点:

1. Token-elastic 用户 vs token-inelastic 用户。传统 SaaS 用户使用产品的频率与 ARPU 强相关(用得越多 = 越深度用户 = 越愿意付费);AI 应用用户的"使用频率"与"token 消耗"非线性相关——一个开发者用户可能一周对话 10 次但单次消耗 50K tokens(深度代码生成),另一个普通用户可能一天对话 50 次但单次只消耗 800 tokens(短句问答)。这两种用户在 ARPU 上可能接近(都是 49-79 美元/月),但 token 成本差异可达 5-10 倍。

2. 毛利率摊薄的多层结构。传统 SaaS 的成本主要是 infra + support,可以摊到 ARR;AI 应用的成本层包括:

   • inference cost(直接 token 成本)
   • engineering amortized(向量库 / 监控 / 推理引擎摊销)
   • support amortized(人工客服兜底 + 客户成功)
   • model upgrade cost(模型升级期的双倍成本)
   • safety amortized(Guardrails / 红队 / 合规审计)

   这五层成本里,只有 inference cost 是 per-request 的,其他四层都是 fixed-amortized,必须按某种 key(ARR / token / request)摊薄到客户。摊薄 key 的选择会显著影响单位经济学数字——按 ARR 摊薄会让小客户看起来"成本低",按 token 摊薄会让重度客户看起来"成本高",没有绝对正确的 key,关键是团队内部对摊薄 key 的一致认可。

3. 大客户 vs 小客户的成本曲线非线性。传统 SaaS 中,大客户与小客户的成本曲线接近线性(主要差异在支持工时);AI 应用中,大客户的 token 消耗往往远超小客户(因为重度使用),且大客户通常要求定制模型路由 / 私有部署 / SLA 保障,这部分成本可能让大客户的 total cost 是其 ARR 的 1.2-1.5 倍——即大客户可能在亏钱,这与"大客户应该更赚钱"的传统 SaaS 直觉完全相反。

隐性补贴维度,2026 年的 AI 应用普遍存在以下几种隐性成本:

• 免费试用:首次 14 天免费,典型首月 token 消耗是付费用户的 2-3 倍
• 首次对话折扣:首单 50% off,边际成本未减半
• 模型升级试吃:自动把新模型推给老用户,新模型通常贵 30-50%
• demo 流量:销售 demo 用真实客户的数据集,消耗大量 token 但不计入 ARR

这些隐性补贴在 demo 阶段看似"必要的获客投入",但累计起来可能让 GM% 虚高 10-15 个百分点。正确的做法是把所有 token 消耗按公允价格归因到 feature / tenant / period,而不是按"售价"或"demo 价"归因。

看板设计上,推荐建立以下六个 per-tenant 看板:

• per-tenant ARPU:日 / 周 / 月三种粒度 + cohort 切片
• per-tenant token cost:按 model_id 分桶,可看到客户主要用哪个模型
• per-tenant GM%:扣除全部摊薄成本后的真实毛利
• per-tenant churn rate:留存曲线
• per-tenant LTV / CAC:长期价值与获客成本
• per-tenant payback period:回本周期(AI 应用的健康值是 6-9 个月)

七、工程实践:FinOps 平台与告警阈值设计

把前三节的形式化与归因架构落地为生产系统,需要走过以下 7 步:

步骤 1:全量 trace → token 三元组 → 客户级归因。这是基础设施层的工作,在推理网关(inference gateway)上强制记录每条 trace 的 token 三元组与 tenant_id。这一层的关键是强制而非可选:任何未带 tenant_id 的 trace 必须被网关拒绝,不允许全局 trace 的存在。强制字段的代码实现通常是在 LLM SDK 的封装层加 invariant check,任何缺失字段的请求直接 throw,这样可以让"忘记打 tenant_id"这类 bug 在 staging 阶段就被发现。

步骤 2:实时 OLAP cube 写入。trace 完成后写入 Kafka / Pulsar,消费侧构建 ClickHouse / Pinot / Doris 的实时 cube。表设计的关键是按 tenant_id + feature_id + model_id 做主键聚合,所有下游看板直接读 cube 而不读原始 trace。这样可以把查询延迟从分钟级压到秒级,把 dashboard 渲染延迟从 30s 压到 2s。

步骤 3:per-feature cost tag 强制。产品 owner 必须在每次新功能上线前定义 cost tag,没有 cost tag 的功能不允许上线——这是产品流程层面的硬约束,需要在 CI 门禁里加一条 lint 规则:每个 PR 必须包含 cost tag 的定义,否则不能 merge。这种"硬约束"是单位经济学能否真正落地的前提,没有这一条,后续所有看板都会有"漏网之鱼"。

步骤 4:cache ROI dashboard。这是步骤 1 的下游看板,展示 semantic cache / prompt cache / KV cache 的命中率、误命中率、单次成本节省、累计节省金额。dashboard 必须支持 per-feature 下钻,因为不同功能的 cache 经济学完全不同,合并看会掩盖很多问题。

步骤 5:router cost-quality Pareto dashboard。这是模型路由的下游看板,展示 cascade / speculative / hybrid 三类路由的工作点、累计 GM%、不同 query 类型的路由分布。这个 dashboard 是路由器调优的核心工具——PM 调整路由阈值时,可以直接在 dashboard 上看到 Pareto 曲线的移动方向。

步骤 6:per-tenant unit economics 看板 + 周报。这是步骤 1 + 步骤 2 + 步骤 3 的最终聚合看板,展示第六节的六个核心指标。看板必须是 per-tenant 可下钻的——任何一个客户都可以展开看其 30 天成本曲线 + 功能分布 + cache 命中率 + 路由分布 + 模型分布 + GM 趋势。同时,系统每周自动生成一份 GM% 周报给财务与产品 team,周报里必须包含"过去 7 天 GM% 上升 / 下降 > 5pp 的客户名单",以便快速识别异常。

步骤 7:阈值告警。建立三类告警:

• GM% 告警:某客户 GM% < X(健康线以下),触发客户成功 team 介入
• cache hit rate 告警:某 feature 的 cache hit rate < Y(工程基线以下),触发 SRE 介入
• token spike 告警:某客户的日 token 消耗 > 历史 P99 × Z(异常飙升),可能是攻击流量或异常使用,触发自动限流 + 安全 team 介入

团队协作层面,必须建立三方协作机制:

• 平台 SRE:负责 trace 基础设施、cube 写入、cache 引擎、监控告警
• 应用 owner:负责 cost tag 维护、cache 阈值调优、路由策略调优
• FinOps:负责摊薄模型设计、定价策略、GM% 周报、客户级毛利审计

三方缺一不可。常见失败模式是只建立平台 SRE 而无 FinOps,导致单位经济学看板无人解读、告警无人响应、模型升级评审无人拍板。

工具栈层面,2026 年的工程实践倾向于:

• 推理网关:LiteLLM / Portkey / OpenRouter(标准化 trace)
• OLAP:ClickHouse / Apache Doris / Apache Pinot
• 可视化:Grafana + 自研看板 / Langfuse / Helicone 内置看板
• 告警:Alertmanager + PagerDuty / OpsGenie
• 追踪:OpenTelemetry + Langfuse / Phoenix

八、讨论:常见误区与边界

工程实践中,有四类常见误区需要警惕:

误区 1:把 token cost 当作唯一成本。这是最常见的归约错误。一家中型 AI 应用公司的真实成本结构可能是:inference cost 55%、engineering amortized 18%、support amortized 12%、model upgrade cost 8%、safety amortized 7%——只看 inference cost 就会高估 GM% 至少 30 个百分点。正确做法是建立完整的成本摊薄模型,不要单维度报告。

误区 2:用全局平均 GM% 看板。全局平均 GM% 是一个非常有迷惑性的数字——它掩盖了"大客户亏钱、小客户暴利"的不健康结构。一个 30% 的全局 GM% 可能是"50% 大客户 GM% 为负、80% 小客户 GM% 为正"的不健康分布,也可能是"所有客户 GM% 都在 25-35%"的健康分布。同样一个数字,业务含义完全不同。正确做法是必须看 GM% 分布的分位数(P10/P50/P90)和尾部分布,不能只看均值。

误区 3:缓存命中率只看全局。全局 cache hit rate = 60% 这个数字看起来不错,但下钻后会发现:核心 chat 功能 cache hit rate = 85%(健康),边缘 summarization 功能 cache hit rate = 12%(可能是 cache key 设计错了)。全局数字掩盖了功能层面的巨大差异。正确做法是 cache hit rate 看板必须有 per-feature 下钻,功能级别的异常必须独立告警。

误区 4:模型升级只看质量提升。升级到 GPT-5 / Claude Opus-4 确实带来了质量提升(通常 8-15%),但成本通常也上升 30-60%。如果只看质量不看成本,模型升级后 GM% 可能暴跌。正确做法是模型升级评审必须包含成本影响评估,质量提升不能脱离 GM% 单独看。

边界条件有三个值得注意:

• 小客户(< 100 用户):单位经济学看板的统计意义很弱,直接走总成本上限告警更有效
• 私有化部署:cost 是"工程工时"而不是 token,需要另一套摊薄模型
• 模型升级期(vendor migration):cost 是双倍(旧模型 + 新模型并行),单位经济学需要单独建模

九、给产品经理与 SRE 的清单

产品经理必做 3 件事:

1. per-feature cost tag:每个新功能上线前必须有 cost tag 定义,这是单位经济学能否落地的最基本前提
2. 客户 ROI 看板:每个客户都能看到自己的 ARPU / token cost / GM% / churn,这是商业决策的基础设施
3. 模型升级评审:每次模型升级必须评审 cost 影响,不能让"质量提升"脱离"GM%"单独决策

SRE 必做 3 件事:

1. cache ROI dashboard:每种缓存的命中率、误命中率、成本节省必须实时可见
2. router Pareto 告警:cascade / speculative / hybrid 路由的工作点必须可视化,异常自动告警
3. token spike 自动熔断:异常流量(可能是攻击)必须自动熔断,不能让单一客户的 spike 把整个集群拉崩

PM 与 SRE 联合必做 2 件事:

1. 周度 GM% 复盘:每周固定时间复盘 GM% 趋势、识别异常客户、调整路由策略
2. 大客户专属成本审计:每个 ARR > 一定阈值的大客户必须有专属的成本审计报告,频率至少月度

未来 6 个月值得跟踪的方向:

• agentic 应用的 tool call cost 归因:tool call 是 AI 应用的新型成本源,如何把 tool cost 归因到 feature / tenant 仍是开放问题
• 多模态(图像 / 音频)cost 单独计价:多模态模型的 cost 与文本模型 cost 差异巨大(通常 5-20 倍),需要单独的归因模型
• 边缘推理与云端推理的成本差:WebGPU / 端侧 LLM 的兴起会让 cost 结构从"云端 token 计费"变为"端侧算力摊薄",单位经济学需要重新建模

截至 2026-08-17,主流 LLM 厂商仍未公开"per-tenant token cost"的官方归因 API,本节描述的所有看板均需团队自研实现。这不是技术问题,而是商业模式问题——LLM 厂商不愿意让客户做单位经济学的精细化治理,因为精细化治理的最终结果往往是"砍掉贵模型的调用",这与 LLM 厂商的利益对立。可以预见的是,自有 trace 基础设施 + 自研归因平台将是 2027 年所有中型 AI 应用公司的标配,这也是本节给出的 7 步实施路径的根本驱动力。

参考文献

1. Anthropic. Claude Token Counting and Prompt Caching Documentation. 2026. https://docs.anthropic.com/en/docs/build-with-claude/prompt-caching
2. OpenAI. OpenAI API Pricing Reference. 2026-08. https://openai.com/api/pricing/
3. Google Cloud. Gemini API Pricing and Context Caching Reference. 2026. https://ai.google.dev/gemini-api/docs/pricing
4. OpenTelemetry. GenAI Semantic Conventions Specification v1.30. 2025-12. https://opentelemetry.io/docs/specs/semconv/gen-ai/
5. Langfuse. Open Source LLM Engineering Platform Documentation v2. 2026. https://langfuse.com/docs
6. Helicone. LLM Observability Platform Architecture Whitepaper. 2026. https://www.helicone.ai/whitepaper
7. ClickHouse. Real-time OLAP for LLM Workloads Engineering Blog. 2026. https://clickhouse.com/blog/llm-olap
8. Apache Doris. Multi-tenant Real-time Analytics for AI Applications. 2026. https://doris.apache.org/docs/lakehouse/ai-scenarios
9. LiteLLM. LLM Gateway with Built-in Cost Attribution. 2026. https://docs.litellm.ai/docs/proxy/cost_tracking
10. Portkey. AI Gateway with Cascade Routing and Cost Optimization. 2026. https://portkey.ai/docs
11. Apache Pulsar. Event Streaming for AI Trace Ingestion. 2026. https://pulsar.apache.org/docs/ai-use-cases
12. Grafana Labs. Dashboard Design Patterns for AI Cost Observability. 2026. https://grafana.com/blog/ai-cost-dashboards
13. PagerDuty. Alert Routing for AI Cost Anomaly Detection. 2026. https://www.pagerduty.com/use-case/ai-cost-monitoring
14. OpenRouter. Model Routing Economics and Cascade Patterns. 2026. https://openrouter.ai/docs/routing-economics
15. Anthropic. Extended Thinking and Reasoning Token Cost Analysis. 2026. https://www.anthropic.com/research/extended-thinking-economics
16. AWS Well-Architected Framework. Generative AI Lens - Cost Optimization Pillar. 2026. https://docs.aws.amazon.com/wellarchitected/latest/generative-ai-lens
17. Gartner. Hype Cycle for AI Engineering Platforms 2026. 2026-07. https://www.gartner.com/en/documents/ai-engineering-hype-cycle-2026
18. a16z. The Unit Economics of AI Applications. 2026-05. https://a16z.com/the-unit-economics-of-ai-applications

一句话摘要:把 AI 应用的 token 成本归因到 trace / feature / tenant 三层,围绕客户级单位经济学建立 FinOps 闭环——这是 2026 年中型 AI 应用公司从 PoC 走向健康毛利的核心基础设施。