企业官网建设流程全解析

说实话，我这两年最深的感受是：在 AI 应用里做成本精算，远比想象中重要。很多团队模型调得不错，功能也跑通了，结果账单一出来，一个月烧掉几万块，一问，谁都不知道钱花在哪。大家最常挂在嘴边的一句就是“LLM 的 token 成本嘛，算一算不就有了”。可真正动手算的时候才发现，这里面的细节远比想象中多，尤其是“输出比输入贵 4 倍”这种说法，听起来挺玄乎，但如果你不搞清楚背后的计费逻辑和实际交互模式，很容易做出错误的成本预估。

这篇文章就是来拆这件事的。我会从 LLM 计费的基本盘讲起，把“输出 token 更贵”的真实原因讲透，再手把手带你走一遍成本计算流程，最后聊一个被很多人忽略却又极其关键的话题——缓存。关于缓存，我有三个亲测出来的“真相”，每一个都让人掉过头发。如果你正在做 Agent、RAG 或任何跑得比较重的 LLM 应用，这篇文章应该能帮你少踩几个坑，也少花几笔冤枉钱。

1. 拆解 LLM 成本结构：为什么输出 Token 这么贵

先别急着套公式。如果连输入和输出的单价分别为多少都没搞清楚，后面的计算全是空中楼阁。我见过不少同行，拿着某个模型的价格表瞄了一眼，就拍脑袋说“输出比输入贵 4 倍”，第二天又在另一个群里看到“其实是 3 倍”，整个人都懵了。为什么会有这种差异，这才是核心问题。

1.1 输出 Token 的“计算压力”

从底层机制来讲，LLM 生成输出 token 的过程，是完全不同的计算模式。输入阶段，也就是把 prompt 喂给模型，本质上是将文本编码为向量并做一次前向传播计算，这个计算可以高度并行化，GPU 的利用率很高。但到了输出阶段，事情就变了。模型必须一个一个 token 地生成，每生成一个 token 都需要等待前一个 token 的结果，这是一个串行过程，不仅无法并行，还要做更多次的矩阵运算、采样操作，并且需要把上一次生成的结果重新放回模型继续推理。你可以把它想象成写一篇文章，输入阶段相当于你把参考资料快速看一遍，输出阶段却要一个字一个字地把文章写出来，每写完一个字还要回读一遍前面的内容来组织下一句。计算量差距不是一个量级。

所以在 API 提供商看来，输出 token 占用的算力和时间成本天然高于输入 token。市面上主流的模型，比如 GPT-4 系列、Claude 系列，输出单价普遍是输入单价的 3 到 5 倍。大家经常说的“4 倍”，其实是最常见的一个典型值，并不是一个普适公式。你在做成本估算时，必须先查清楚你用的那款模型当前的确切定价，甚至同一个模型在不同 tier 的套餐里都可能不一样。

1.2 输入 Token 的“附加成本”

别以为输入 token 便宜，就可以放开手把整本参考书都塞进 prompt。输入 token 的成本虽然是单价低，但它的数量增长极快，尤其是在 Agent 和 RAG 场景里。我在做 Agent 设计时，经常发现 prompt 里不仅有用户的当前问题，还塞进了上下文记忆、工具描述、历史对话、检索到的知识片段，甚至还有各种 system prompt 里设定的角色规则。

这里就不得不提一个现在很多人常用的理解方式，把 token 看成三个点：key 是“我是谁”，就是模型需要知道的角色和身份；query 是“我在找什么”，就是用户当前的具体诉求；value 是“我能提供什么”，就是外部系统能给出的工具、知识或者数据结构。这三部分的 token 数量加在一起，往往远远超过用户那一个问句的长度。例如一个简单的“帮我查一下天气”，如果系统配置了很多工具和详细的城市列表，输入可能膨胀到一千甚至两千 token。而真正让成本翻倍的地方在于，每多一轮对话，前面的全部 content 都会重新作为输入算一遍。这也是为什么很多人觉得看似只是聊了几句，账单却高得吓人。

1.3 定价模型中的“4倍”现象

之所以单独把“4 倍”拎出来说，是因为它容易让人误解。有一次我在一个技术群里看到有人争论，一个说“GPT-4 输出是输入的三倍”，另一个说“不对，是五倍”，最后发现他们分别用的不同模型版本和不同计费单位。比如有的套餐按每 1K token 计费，有的按每百万 token 计费，还有的提供批量 API 折扣，单价能差出一大截。

我自己在实际计算时，通常会用一张表格把模型名、输入单价、输出单价、缓存输入单价列清楚，这才不会被表面上的比例带偏。例如某个模型的输入单价如果是 3 美元每百万 token，输出单价是 15 美元每百万 token，那两者的比例确实是 5 倍；但如果换一个版本，输入 5、输出 15，比例又变成了 3 倍。所谓“4 倍”，只是一个行业平均感觉，真正到项目里，你必须以你的账单和价目表为准。这块如果不较真，后面所有精算都建立在一个松动的地基上。

2. 一次请求的 Token 成本怎么算

很多人看到 token 两个字就发怵，觉得它是某种黑盒统计。其实 token 并没有那么神秘，它就是模型把文本切分成的最小语义单元。你可以理解为一个单词、一个子词或一个汉字，具体切法要看模型的分词器。中文场景下，一个中文字符通常大约对应 1 到 1.5 个 token，英文则是 1 个词大约 1.3 个 token，加上空格和标点还会额外占一些。你不需要手动数得那么精确，但至少心里要有这个概念。

2.1 Token 计数的基础逻辑

实际开发中，精确数 token 的方式有两种：一种是直接用模型提供商的官方 tokenizer（比如 OpenAI 的 tiktoken），把 prompt 文本和输出文本分别切分后统计；另一种是调用 API 时看返回结果里的 usage 字段，里面会明确告诉你 prompt_tokens 和 completion_tokens 分别是多少。我建议你把这两者结合起来，因为不同语言的切分结果差异很大。比如中文里，一个字符可能是 1 token 也可能是 2 token，这跟模型训练时的语料分布有关。英文相对稳定，但长单词也可能被拆成多个 token。

如果你只是想快速估算，可以直接按“中文字符数约等于 token 数”来算，英文则按“单词数乘以 1.3”估算。这样的误差通常可以控制在 15% 以内，对于初期成本预估足够了。但到了上线阶段，就必须用官方工具精确统计，因为误差会在百万级 token 的调用量下被无限放大。

2.2 一个 200 字回复的真实成本拆解

我们用一个具体案例来算一遍。假设你要构建一个客服问答机器人，用户问了一个问题，输入 prompt 包含 system 规则、用户问题、历史记忆、检索文档，全部拼起来一共 1000 个 token。模型最终返回了一个 200 字的回答，拆分后大概是 240 个 token。我们按一个常见的定价模型来算：输入 3 美元每百万 token，输出 15 美元每百万 token。

那么这一次请求的成本就是：

输入成本：1000 / 1000000 × 3 = 0.003 美元 输出成本：240 / 1000000 × 15 = 0.0036 美元

你可能会想：总成本才 0.0066 美元，这么点钱有什么可算的。但问题在于，一个线上应用每天可能会有十万次这样的请求，一天就是 660 美元，一个月就是一万九千八百美元。这时候你再看输出 token 的占比：输出只占总 token 数的 240 / 1240 ≈ 19.4%，但它占总成本的 54.5%。你看，输出贵可不只是说着玩的，它用不到五分之一的 token 量，烧掉了超过一半的钱。这就是为什么做成本优化，输出侧往往是重点突破口。

3. 缓存的三个真相

要说 LLM 成本精算里最容易被高估的手段，我觉得就是缓存了。很多人一听“加缓存能省钱”，马上在系统里套了个 Redis 缓存，或者打开了某些 API 平台自带的 prompt caching 功能，就以为万事大吉。但真正上线跑几周之后，我发现事情远没那么简单。Cache 有三个真相，每一个都在真实项目里坑过我。

3.1 真相一：缓存能大幅降低重复计算成本

首先得承认，缓存确实是成本优化的利器。最典型的场景是系统 prompt 和上下文固定的 RAG 应用。如果用户的输入 prompt 里有大段内容是完全相同的，比如固定的 system prompt、固定的产品说明文档、固定的工具定义，那么服务商可以在服务端对这些前缀做缓存。当你第二次发送带有相同前缀的请求时，服务端就不需要重新处理那部分输入了。这样一来，那部分输入 token 的计费会暴跌，有时甚至可以降到原先的 10% 到 25%。

举个直观数字：如果你有一个系统 prompt 是 5000 个 token 的固定内容，每次请求都会带上去，没有缓存时这 5000 token 每次都按输入单价算。有了缓存命中之后，这部分的价格直接降到原来的十分之一，一天跑几万次请求，这部分就能省下几千块。再加上响应时间也明显变快，用户体验也跟着提升。可以说在固定前缀非常稳定的场景下，不用缓存真的是在给平台送钱。

但要注意，缓存并不是自动开启的。每个平台的规则不一样，你需要主动检查你的 API 设置，有的要求同一个前缀重复出现至少若干次才会触发缓存，有的要求请求体结构完全一致。我在项目里踩过这样一个坑：我以为开启了缓存，结果后台查看命中率，发现只有 0.2%，跟没开一样。后来才发现，因为我每次请求里都带了一个时间戳参数，导致整个前缀都会变，缓存根本没法命中。

在预估值之前，最好先用一两周跑出真实命中率，再决定是否把缓存写入成本模型。盲目乐观地假设 80% 命中，会让你的成本预估比实际偏出好几倍。

3.2 真相二：缓存不是免费的

很多人误以为缓存就是纯省钱神器，一分钱成本都不用掏。这话大错特错。先不说构建缓存系统本身需要硬件资源，就算用的是服务商提供的原生缓存能力，也得看它怎么计费。有些服务商对缓存存储单独计费，长期存着大体积的固定 prompt 内容也会产生存储费用。如果你自己用 Redis 做应用层缓存，把整段返回结果存起来，那意味着你要维护一套缓存基础设施，包括内存占用、过期策略、持久化配置，这些都是隐形成本。

更关键的是，过度依赖缓存会让系统复杂度上升。我见过有个团队把缓存放得非常激进，每个用户会话都缓存了完整上下文，结果用户换了设备或者会话过期，缓存里的旧数据污染了新请求，导致模型回答错乱。排查这种问题要比省下来的钱贵得多。所以不要把缓存当成一个零成本的工具，要从存储、维护、一致性三个维度去评估它的真实代价。只有当缓存命中率足够高、实施成本足够低的时候，它才真正划算。

3.3 真相三：缓存命中率受交互动态影响

第三个真相最扎心：在很多真实业务里，缓存命中率并不像想象中那么高。特别是在 Agent 和对话型应用里，用户的输入变化非常频繁，几乎每次都有不同的上下文。如果固定前缀很短，比如只有一段 100 token 的系统提示，剩下全是动态内容，那缓存的意义就比较有限。你在成本计算里拍脑袋假设缓存命中率可以达到 70%，最后实际只有 20%，预算直接崩盘。

我后来总结出一个规律：缓存命中率与业务场景高度相关。如果应用是偏向固定流程的调用，比如“对一段固定格式文本做分类”“把固定模板翻译成英文”，那么缓存能发挥很大作用。如果应用是开放式问答、多轮自由聊天，缓存效果就非常有限。所以在方案设计阶段，不要只在系统架构里加缓存这个开关，而是先去分析 prompt 里静态部分和动态部分的比例，再估算一个保守的命中率区间，比如 30% 到 60%，并把低命中率作为兜底假设，这样才能避免上线后成本失控。

4. 成本优化实操：输入 Token 与输出 Token 的双重瘦身

算清楚成本构成和缓存机制之后，下一步就是动手优化。这一部分我讲讲实际操作中已经验证过的方法，目标只有一个：在不显著影响模型效果的前提下，把 token 用量压下去。核心思路是，从输入和输出两侧分开下手。

4.1 输入侧：prompt 精简、缓存与复用

输入侧的优化逻辑很简单，把“送入模型的每一段内容”都当成钱来对待。第一件事是精简 prompt。很多团队为了规则完善，把 system prompt 写得像一篇技术文档，一条条细则恨不得有两千字。其实很多内容可以压缩，比如用更短的说法表达同一条规则，删掉重复修辞，减少多余的角色背景描述。我把一个项目的 system prompt 从 1200 token 压到 500 token，模型表现几乎没有下降，但输入成本直接省了一半以上，累计下来数目相当可观。

第二件事是设计好缓存策略。前面提到缓存命中率依赖静态前缀，所以在设计系统时，尽量把固定内容放在 prompt 的最前面，包括 system prompt、工具定义、固定知识片段。动态内容尽量放后面，比如用户 query、实时检索结果。这样服务端前缀缓存会更容易命中。另外还可以在应用层面做历史对话摘要缓存，把用户过去的历史总结存在 Redis 里，不用每条请求都回传全部原始对话，这也能大幅削减输入 token。

第三件事是复用上下文。有些业务里，同一批用户会被反复问到相似问题，你可以把标准答案做成本地模板，只有模板内容无法覆盖时才调用模型。这虽然不算严格意义上的 token 缓存，但确实能让一大批请求完全不用进入模型，直接省掉百分之一百的 token 成本。

4.2 输出侧：max_tokens 限制、模型选择与后处理

说到输出侧，很多人第一反应是设置 max_tokens，但这里有个误区：max_tokens 设得太低可能导致模型回答被截断，反而引发更多轮重试，整体成本更高。正确做法是先分析任务需要的合理输出长度，给模型留出稍微富余的范围，再在代码里做截断处理。比如要求模型只做关键词抽取，那 max_tokens 设 100 就够了，如果设成 1000，模型很容易把回答扩得很长，生成一堆你根本用不上的废话，费用就这么白白烧掉了。

还有一个思路是分场景选择模型。不要一个模型吃遍全部任务。对于那些简单分类、实体抽取、格式转换类的任务，用便宜的小模型完全够用。我做过测试，在情感分类任务上，小模型的准确率只比大模型低了不到两个百分点，但成本可能低了十五倍。所以我会在系统中做一个路由层，根据任务难度动态决定调用哪档模型。复杂推理、长文本摘要走贵模型；简单任务全部走便宜模型。这个策略实施后，整体成本下降了接近 40%。

另外一个容易被忽略的优化点是后处理环节。如果模型经常输出一段冗长回答，但下游只需要其中某一个字段，你大可以在 prompt 里要求“只返回 JSON”，然后在代码里直接解析，而不是让模型额外生成英文解释或过渡语句。控制输出格式，本质上就是在控制输出 token 的上限。刚开始我做 Agent 的时候没有这个意识，模型经常在前面说一大段“好的，我来帮你分析一下，首先……”，这句废话可能就有几十个 token，日积月累，这几十个 token 乘以上万次请求，就是一笔不小的开销。

5. 真实项目的成本估算与优化案例

理论聊完，拿一个我实际参与过的项目来做一次完整复盘。这是一个企业内部的知识库问答系统，用户量不大，但每次调用都涉及长文档检索和模型生成，上线第一个月账单吓了我一跳，然后就开始了系统性的成本治理。

5.1 从账单反推成本结构

接到账单后，我没有急着调整代码，而是先从 API 后台导出所有请求记录，把 token 用量按天拆开。统计发现，每天大约有 8000 次请求，平均每次请求输入 token 是 3200，输出 token 是 420。我按单价一算：输入成本约 76.8 美元一天，输出成本约 50.4 美元一天。也就是说，即使输出单价贵 5 倍，因为输入 token 数量极大，输入费用仍然占了 60% 以上。这个结论推翻了我最初的预期。我原以为输出贵，成本大头应该在输出，结果实际账单告诉我，这个项目的瓶颈在输入炖肉。

这个案例给了一个重要启发：成本优化不能只盯着“单价贵”的 token 类型，要看自己项目里输入输出比例。如果输入输出比高达 8 : 1，那么哪怕输出单价是输入的 5 倍，输出总成本还是低于输入。这时候优化输入 token 才能抓到矛盾的主要方面。

5.2 优化方案组合：分级模型与流量管控

于是我做了三件事。第一，把系统 prompt 里的规则压缩了一半，只保留必要指令，输入 token 从 3200 降到 2100 左右。第二，在文档检索阶段做了更严格的相似度过滤，只把最相关的 3 段内容拼进 prompt，而不是固定的 5 段，输入 token 又降了 20%。第三，引入了便宜小模型做初次预回答，只有当小模型置信度过低时才升级到大模型。最终统计下来，每请求平均输入 token 降到了 1350，输出 token 保持不变。

成本模型重新计算之后，每天输入成本降到 32.4 美元，输出成本还是 50.4 美元，总成本从 127.2 美元降到了 82.8 美元，整体下降了 35% 左右。如果再把缓存命中率加进去，系统 prompt 那部分还能进一步打折。后来我把同样一套策略复制到另一个项目上，效果依然很明显。

5.3 经验总结：实时监控与阈值告警

现在我在做 LLM 应用时，一定会做成本监控看板。不光是看总账单，还会按天、按时甚至按用户维度去看 token 消耗情况。设置一个阈值告警，比如单日成本超过一定金额就推送提醒，这样预算失控不会等到月底才发现。还可以把各请求的 token 用量打到日志里，定期跑 SQL 分析哪些功能模块最烧钱，对照业务流程做定向优化。

我见过太多团队，上线前完全没有成本意识，上线后每个月收到账单才开始到处问“怎么降本”。这时候临时抱佛脚往往要动大手术，牵一发动全身，风险高得多。不如从第一天就把成本精算纳入开发流程，在每一步都问一句：这个 prompt 能不能更短？这个任务能不能用更便宜的模型？这个输出格式能不能更紧凑？这些问题看着琐碎，累积起来就是天壤之别。

6. 常见问题与避坑指南

最后整理一下我在做成本精算和数据调优时经常踩的坑，以及一些真实排查问题的经验。写在这里不是为了罗列知识点，而是希望你在做方案的时候直接避开这些深坑。

6.1 成本预估偏差为何这么大

我经常见到一种情况：开发者拿 prompt 字数乘上单价，一算觉得成本很低，结果一上线翻了好几倍。为什么？因为大多数人忽略了重试和分支。在大模型链路里，一次用户请求可能会触发多次模型调用，比如 Agent 要调用多个工具、做多轮推理，每次调用都算一次请求。还有，模型输出有时不符合预期，代码里设定了自动重试，一次失败就会再把同样长的输入送进去一遍。这些隐藏调用次数不去统计，成本预估必然失真。

所以我建议你在计算预期成本时，不要按“一次交互 = 一次调用”来算。先画出用户场景，数清楚一次完整交互里平均需要多少次模型调用，再把失败重试率考虑进去，最后乘一个 1.2 到 1.3 的保险系数，这才是更接近真实数字的成本预估。

6.2 缓存策略常见的三个误区

关于缓存的问题，再补充几个实际经验。误区一：以为只要打开缓存就自动省钱。实际上，缓存命中与 prompt 前缀顺序强相关，不同平台的实现细节不同，必须主动设计 prompt 排列。误区二：把所有内容都塞进缓存，包括用户的实时信息。这会导致缓存污染，模型下次命中到过期的数据，给出错误回答。解决方法是给缓存内容加上版本号或时间戳标记，但注意不能把它放在固定前缀前段，要放在动态部分独立处理。误区三：把缓存命中率当作固定参数写进成本模型。应当用低、中、高三档命中率分别做预算，再对照实际数据校准。

6.3 一个容易忽略的细节：连续调用中的累计费用

最后一个坑，是我在一次账单分析中发现的。当时有个 Agent 任务，单个步骤调用成本都很低，每步可能只有零点几美分，但整个任务要做 12 步，其中有 10 步是把前一步的输出拼到新的输入里。这样一来，到第 10 步的时候，输入里已经包含了前面所有历史输出，输入 token 数量随轮次线性增长。最终一次完整任务的成本，远高于最初预估的一步成本。

解决办法是把历史对话做摘要，每几轮就把早期内容压缩成摘要，只保留关键信息。或者把静态内容拆出去，让真正需要传递的动态内容保持精短。这种优化对多轮 Agent 场景效果非常显著。如果你正在做复杂的 Agent 应用，一定要关注输入 token 随轮次的膨胀，不然账单会让你措手不及。

我个人在实际操作中的体会是，LLM 成本精算不是一次性工作，而是一个持续迭代的过程。模型定价会变，缓存命中率会变，业务负载模式也会变，所以每隔一段时间就要重新做一次成本复盘。把成本精算融入到日常开发习惯里，才能让你的 AI 应用在效果和钱包之间找到真正健康的平衡点。