企业官网建设流程全解析

1. 多应用共用 AI 时，为什么费用总是一笔糊涂账

团队里同时跑着三四个 AI 应用，这在今天已经不算什么新鲜事了。一个内部知识库问答机器人、一个代码补全助手、一个客服话术生成工具，再加上某个同事自己搭的文档摘要小工具，全都挂在同一个模型服务账号下面。月底账单出来，数字不小，但你要问“哪个应用花了多少钱”，没人答得上来。这就是我最初遇到的局面，也是这篇文章想聊清楚的核心问题：多个 AI 应用如何区分消耗，从建立项目归属开始。

这件事的本质，其实不是技术难题，而是记账维度缺失。模型服务商给你的账单，通常只到“账号”这一层，最多再给你按模型、按天拆一拆。但你的组织架构是按“项目”走的，预算是按“项目”批的，责任是按“项目”追的。账单维度和你的管理维度对不上，中间就出现了一个黑洞。Token 消耗了多少、配额还剩多少、哪个应用在偷偷跑批、哪个应用突然翻了三倍用量，全都看不见。

我见过太多团队在这个阶段的做法是“先跑起来再说”，结果三个月后想优化成本，发现连基线数据都没有。所以这篇文章适合两类人看：一类是正在把 AI 能力接入多个业务场景的技术负责人，另一类是突然被要求“把 AI 费用说清楚”的运维或财务对接人。不管你现在用的是哪家模型服务，思路是通用的——先建立项目归属，再谈消耗区分。

下面我会从整体设计思路讲起，然后拆解归属体系怎么建、Token 怎么归集、配额怎么分配，最后把我踩过的坑和排查技巧一并倒出来。内容偏实操，能直接抄作业的地方我会写清楚。

2. 整体设计思路：先有归属，才有区分

2.1 为什么“按应用分账”这件事不能靠事后猜

很多人第一反应是：账单出来了，我按调用量比例分摊一下不就行了？这个思路在应用数量少、调用模式稳定的时候勉强能用，但只要出现下面任何一种情况，立刻失效。

第一种情况是共享密钥。多个应用图省事，共用同一个 API Key。这时候服务商侧根本不知道请求是谁发的，你拿到的只有一条汇总曲线。想分摊？只能靠猜。

第二种情况是调用模式差异大。应用 A 是高频短请求，每次几百 Token；应用 B 是低频长文本，每次几万 Token。你按“调用次数”分摊，A 背了大部分锅；按“Token 总量”分摊，又说不清 A 的高频是不是合理。没有归属，就没有公平的分摊基准。

第三种情况是突发批量任务。某个应用半夜跑了一次全量数据重处理，烧掉了一大块配额。如果这笔消耗混在总账里，你连“是谁干的”都定位不到，更别提下次预防。

所以我的结论很直接：区分消耗的前提是归属清晰，归属清晰的前提是每个应用有独立身份。这个身份可以是一个独立的 API Key，也可以是一个独立的项目标识，但绝不能是“大家共用一把钥匙”。

2.2 项目归属体系的三个层次

我把归属体系拆成三层来设计，从下往上依次是凭证层、标识层、账目层。

凭证层解决的是“谁在调用”。最干净的做法是每个应用分配独立的 API Key 或访问凭证。这样服务商侧的用量统计天然就按凭证分开了，你不需要做任何额外工作就能拿到分应用的原始数据。如果服务商支持子账号或项目空间，那就更省事，直接在平台侧建项目即可。

标识层解决的是“这次调用属于哪个业务”。有些场景下凭证没法完全隔离，比如多个应用跑在同一个服务实例里，或者用的是同一个网关出口。这时候就要在请求里带上业务标识，常见做法是在请求头或元数据里加一个project_id或app_name字段。网关或代理层负责把这个标识记录下来，落到日志里。

账目层解决的是“怎么算钱”。有了凭证和标识，你还需要一套归集逻辑：把原始用量数据按项目聚合，乘以对应的单价，得出每个项目的费用。这一步可以放在自建的计量系统里，也可以用服务商提供的成本管理功能。关键是归集维度要和你的预算维度一致。

这三层里，凭证层是基础，标识层是补充，账目层是结果。很多人一上来就想做账目层，结果发现底层数据根本分不开，白忙一场。

2.3 方案选型：自建计量 vs 平台原生

这里有个绕不开的选择：是用服务商自带的项目管理和成本分析功能，还是自己搭一套计量系统？

我的建议是先看服务商能力，再决定自建范围。主流模型服务商这几年都在补项目管理这块的能力，有的支持创建多个项目、每个项目独立配额、独立查看用量。如果你的应用数量不多、用的又是同一家服务，直接用平台原生功能是最省事的，几乎零开发成本。

但平台原生功能通常有两个局限。一是跨服务商归集难，你同时用了两家的模型，两边的项目体系是割裂的，想合并看总账就得自己动手。二是自定义维度有限，平台一般只让你按项目、按模型、按时间看，你想按“业务线”“成本中心”“客户”这些自定义维度归集，平台往往不支持。

所以我的实际做法是混合模式：能用平台原生项目管理的，先用起来，保证基础归属清晰；同时在自己的网关层记录一份带业务标识的调用日志，作为跨服务商归集的统一数据源。这样既不重复造轮子，又保留了灵活性。

3. 核心细节解析：Token 归集与配额分配的关键点

3.1 Token 消耗到底该怎么归集才准确

Token 是 AI 消耗的基本计量单位，但它的归集比想象中麻烦。麻烦点在于一次业务操作可能对应多次模型调用，而每次调用的 Token 数都不一样。

举个实际例子。一个文档问答应用，用户问一个问题，背后可能是：一次向量检索（不消耗模型 Token）、一次上下文组装后的问答调用（消耗输入 Token 和输出 Token）、如果答案需要润色再来一次调用。这三步里只有后两步烧 Token，但业务上它们属于同一次“问答请求”。你归集的时候，是按模型调用次数记，还是按业务请求记？

我的做法是双维度记录：既记录每次模型调用的原始 Token 数（用于和服务商账单对账），也记录它归属的业务请求 ID（用于按业务维度分析）。这样既能精确对账，又能回答“一次用户问答平均花多少 Token”这种业务问题。

具体到字段设计，我一般会记录这些：调用时间、凭证标识、项目标识、业务请求 ID、模型名称、输入 Token 数、输出 Token 数、是否命中缓存、耗时。其中是否命中缓存这个字段很容易被忽略，但它对成本影响巨大。很多服务商对缓存命中的输入 Token 有折扣，如果你不记录，就说不清为什么实际费用比预估低。

注意：不同服务商对 Token 的计算口径不完全一样，有的把系统提示词算进输入 Token，有的对特殊字符有单独计法。做归集前一定要拿几笔真实调用去和服务商账单核对，确认口径一致，否则后面所有分析都是错的。

3.2 配额分配：别把配额当成简单的除法

配额分配是另一个容易踩坑的地方。很多人的做法是：总配额除以应用数量，平均分。这个做法在应用重要性差不多、用量模式相似的时候能用，但现实中往往不是这样。

我见过一个真实案例。团队给三个应用平均分配了配额，结果核心的客服应用因为用量大，月中就撞了限额，服务中断；而另一个实验性应用配额根本用不完，白白浪费。问题出在配额没有和业务优先级挂钩。

我的配额分配思路是分三步走。第一步，先跑两周观察期，不设硬限额，只记录每个应用的实际用量分布，拿到基线和峰值。第二步，按基线加缓冲分配，核心应用给到峰值的 1.5 倍，非核心应用给到基线的 1.2 倍，留出弹性空间。第三步，设置分级告警，用量到 70% 提醒、到 90% 预警、到 100% 才限流，而不是一刀切。

这里有个细节值得说：配额的单位要和计费单位对齐。如果服务商按 Token 计费，你的配额就用 Token；如果按请求数计费，就用请求数。混用单位会导致换算错误，我吃过这个亏，把请求数配额当成 Token 配额算，结果差了两个数量级。

3.3 项目标识的传递：别让标识在链路中丢失

项目标识能不能准确落到日志里，取决于它在整个调用链路中是否被完整传递。这一点在微服务架构里尤其容易出问题。

常见的丢失场景是这样的：应用 A 调用网关，网关转发到模型服务。如果网关没有把应用 A 传来的项目标识透传下去，或者透传了但日志没记录，那这笔消耗就归不到 A 头上。更隐蔽的是异步任务，比如消息队列触发的批量处理，标识如果没跟着消息走，消费端就不知道这笔消耗属于谁。

我的做法是在链路入口统一注入标识，全链路透传。具体来说，在网关层做一次拦截，从请求头里取出项目标识，写进上下文，后续所有日志和计量都从这个上下文里取。异步场景则在消息体里显式带上标识字段，消费端解析后重新注入上下文。这样无论链路多长，标识都不会丢。

提示：标识命名要有规范，别用“app1”“test”这种随手起的名字。建议用“业务线-应用名-环境”的格式，比如“cs-chatbot-prod”，这样一看就知道归属，排查问题时省很多事。

4. 实操过程：从零搭建一套可用的归属与计量体系

4.1 第一步：盘点现有应用和调用方式

动手之前先盘点。我一般会拉一张表，把每个 AI 应用的信息填进去：应用名称、负责人、调用方式（直连还是走网关）、当前用的凭证、日均调用量、峰值调用量、是否有关键业务依赖。

这张表的价值在于暴露共享凭证的问题。盘点完你大概率会发现，有好几个应用在用同一个 Key。这就是你要优先解决的对象。盘点的时候顺便确认一下每个应用的调用是否都经过统一入口，如果有应用绕过网关直连模型服务，那它的消耗就很难归集，需要单独处理。

4.2 第二步：为每个应用建立独立凭证或项目

盘点清楚后，开始建归属。如果服务商支持多项目，直接为每个应用建一个项目，分配独立凭证。如果不支持，就在网关层为每个应用分配独立的内部凭证，网关再用统一的上游凭证去调用模型服务，同时在日志里记录内部凭证和项目标识的对应关系。

这一步的关键是凭证和项目的映射关系要落库，不能只存在配置文件里。我一般会建一张映射表，字段包括内部凭证 ID、项目标识、应用名称、负责人、创建时间、状态。网关每次收到请求，先查这张表确认凭证有效并取出项目标识，再继续处理。

这里有个性能考量：每次请求都查库会有延迟。我的做法是加一层本地缓存，映射关系变动不频繁，缓存几分钟完全够用。缓存失效时回源查库，同时异步刷新。

4.3 第三步：在网关层记录结构化调用日志

网关是归集数据的黄金位置，因为所有请求都从这里过。我在网关层记录的结构化日志大概长这样：

{ "timestamp": "2025-01-15T10:23:45Z", "credential_id": "cred_abc123", "project_id": "cs-chatbot-prod", "request_id": "req_xyz789", "model": "gpt-4o", "input_tokens": 1520, "output_tokens": 380, "cached_input_tokens": 800, "latency_ms": 2340, "status": "success" }

这份日志是后续所有分析的原料。有了它，你可以按项目聚合 Token、按模型分析成本、按时间看趋势。我通常会把日志先落到本地文件或消息队列，再异步写入分析库，避免日志写入拖慢网关响应。

注意：日志里不要记录完整的请求内容，尤其是用户输入。一是体积大，二是涉及数据安全。只记计量需要的元数据就够了。如果确实需要排查问题，可以单独开一个采样日志，按比例记录，并且做好脱敏。

4.4 第四步：搭建归集与对账流程

日志有了，接下来是归集。我一般用两步：日聚合和月对账。

日聚合是每天凌晨跑一次批处理，把前一天的原始日志按项目、按模型聚合，算出每个项目的输入 Token、输出 Token、缓存 Token、调用次数。聚合结果写入一张日汇总表，供日常查看。

月对账是每月初跑一次，把日汇总表的数据和服务商的月度账单做比对。比对的重点是总量是否一致。如果自建计量的总量和服务商账单对不上，说明有调用没被记录，或者 Token 计算口径有差异。我遇到过几次对不上，最后查出来是某个应用绕过了网关直连，补上之后就对上了。

对账差异的排查顺序我总结成一张表：

4.5 第五步：配置配额与告警

归集跑通后，就可以上配额和告警了。我的配置逻辑是按项目设配额，按阈值分级告警。

配额值参考前面说的基线加缓冲来定。告警我一般设三档：70% 发通知给应用负责人，90% 发通知给技术负责人，100% 触发限流并通知所有人。限流策略要提前想好，是直接拒绝请求，还是降级到更便宜的模型，还是排队等待。这个取决于业务容忍度，核心业务我一般选降级而不是拒绝。

告警渠道用团队现有的就行，邮件、群消息都可以。关键是告警信息要包含足够上下文：哪个项目、当前用量、配额上限、预计多久用完。信息不全的告警等于没告警，收到的人还得自己去查。

5. 常见问题与排查技巧实录

5.1 用量突然暴涨，怎么快速定位

用量暴涨是最常见的紧急情况。我的排查顺序是先看总量，再看分布，最后看单点。

先看总量曲线，确认是全局涨还是局部涨。如果是全局涨，可能是某个批量任务在跑，或者有异常调用。再看按项目的分布，找出涨幅最大的项目。最后看该项目的调用明细，定位到具体的请求特征：是某个接口调用量激增，还是单次请求的 Token 数变大。

我遇到过一次暴涨，最后查出来是某个应用的重试逻辑有 bug，请求失败后无限重试，短时间内打了几万次调用。这种问题光看总量是看不出来的，必须下钻到调用明细。所以日志的保留粒度要足够细，至少保留最近 7 天的原始记录，方便随时下钻。

5.2 项目标识丢失导致归集失败

标识丢失是归集不准的头号原因。表现是某些调用在日志里项目标识为空，或者归到了“未知”分类。

排查思路是沿着链路逐段检查。先确认应用侧有没有注入标识，再确认网关有没有正确解析，然后确认透传过程中有没有被覆盖或丢弃。异步场景还要检查消息体里有没有带标识。

我踩过的一个坑是网关的默认值覆盖。网关配置里有个默认项目标识，当请求没带标识时就用默认值。结果有些应用忘了带标识，全被归到了默认项目，看起来像是那个项目用量异常。后来我把默认值改成“未分类”并加了告警，一旦出现就提醒，问题就暴露出来了。

5.3 配额撞限导致业务中断

配额撞限本身不可怕，可怕的是撞限了没人知道。我见过最糟的情况是核心应用半夜撞限，第二天早上用户反馈才发现。

预防措施有三条。一是告警要提前，别等到 100% 才告警，70% 就该有动静。二是限流要有降级，撞限后不是直接拒绝，而是降级到备用方案，保证业务不中断。三是配额要定期复核，业务量涨了配额没涨，迟早撞限。我一般每季度复核一次配额，根据实际用量调整。

5.4 跨服务商归集的统一口径问题

同时用多家模型服务时，归集的最大障碍是口径不统一。同样是“输入 Token”，不同服务商的计算方式可能不同；同样是“缓存命中”，折扣比例也不一样。

我的做法是在归集层做归一化。定义一个内部统一的计量口径，把各服务商的原始数据转换成统一口径后再聚合。比如统一按“计费 Token”归集，把各家的折扣、免费额度都折算进去，得出实际成本。这样跨服务商比较才有意义。

归一化的规则要文档化，写清楚每家服务商的换算方式。不然过几个月你自己都忘了当初是怎么算的。

5.5 常见问题速查表

6. 我在实际项目里的一些体会

这套体系我从零搭过两次，第二次比第一次顺很多，差别主要在对细节的预判上。第一次做的时候，我以为把凭证分开就万事大吉，结果发现日志里没有业务标识，按项目分析还是做不了。第二次我一开始就把标识注入和日志结构设计好，后面省了大量返工。

还有一个体会是别追求一步到位。归属和计量体系是可以迭代的。先做到“能分开”，再做到“分得准”，最后做到“分得细”。我见过有人一上来就想做实时计量加智能预警，结果基础数据都没打通，做了个花架子。先把日聚合跑通，能和服务商账单对上，这一步的价值就已经很大了。

最后分享一个小技巧：把归集结果定期同步给应用负责人。不用很频繁，每月一次就行。让每个负责人看到自己应用的用量和费用，他们自然会去优化。这比技术团队单方面推优化有效得多，因为花的是他们自己的预算，疼的是他们自己。我推行这个做法之后，有两个应用的用量自己就降下来了，问了一下，是负责人发现某个调用可以合并，顺手就改了。