企业官网建设流程全解析

1. 1.73 亿 token 到底是个什么量级

先把结论摆在前面：1.73 亿 token 这个数字，放在个人开发者或者小团队的使用场景里，属于“重度但并非离谱”的区间。它既不是那种一天烧掉几千万的工业化流水线，也不是随手聊几句就能攒出来的量。要理解这个数字的分量，得先搞清楚 token 在计费体系里到底怎么算。

Token 是模型处理文本的最小单位。英文里一个 token 大约对应 0.75 个单词，中文里一个汉字通常要占 1 到 2 个 token，具体取决于分词器的设计。你可以把它理解成“模型眼里的字数”，但这个字数和人类习惯的字数不是一回事。一段 1000 字的中文技术文档，喂给模型之后可能被切成 1500 到 2000 个 token，因为标点、代码符号、换行、缩进都会被单独计算。

1.73 亿 token 是什么概念？如果按中文粗略换算，大约相当于 8000 万到 1.2 亿个汉字。一本 30 万字的长篇小说，大概能装下 300 到 400 本。如果换成代码，一个中等规模的项目仓库，全部源码加上注释、文档、issue 记录，可能也就几百万 token。所以 1.73 亿这个量级，基本可以确定不是单纯的手动对话产生的，背后一定有自动化流程、批量处理或者高频调用。

这里就引出了第一个关键问题：这 1.73 亿 token 是怎么构成的。在按量计费的 API 体系里，token 通常分为三类——输入 token、输出 token、缓存命中 token。这三类的单价完全不同，输出 token 最贵，输入 token 次之，缓存命中的输入 token 往往有大幅折扣。如果不把这笔账拆开，直接拿总量乘以一个单价，算出来的数字会严重失真。

我见过太多人算账时犯这个错误：拿总 token 数乘以最贵的那个单价，然后惊呼“怎么这么贵”。实际上，如果你的工作流里有大量重复的系统提示词、固定的上下文模板、反复引用的知识库内容，缓存命中率可能占到输入 token 的 60% 甚至 80% 以上。这部分 token 的单价可能只有正常输入价的十分之一到四分之一。所以算账的第一步，永远是先把 token 按类型拆开。

2. 官方定价体系里的隐藏变量

要算清楚这笔账，得先理解主流 API 平台的定价结构。虽然各家厂商的具体数字不同，但底层逻辑是相通的：按 token 类型分档计价，按模型能力分层定价，按使用方式给予折扣。

2.1 输入、输出、缓存三档价差

以目前市面上常见的定价模式为例，假设某个中高端模型的官方标价是：输入 10 元/百万 token，输出 30 元/百万 token，缓存命中输入 2 元/百万 token。这三个数字之间的差距不是随便定的，背后有明确的成本逻辑。

输出 token 贵，是因为生成过程需要模型逐个 token 做前向推理，计算量大且无法并行优化。输入 token 便宜一些，是因为预填充阶段可以批量并行处理，GPU 利用率更高。缓存命中更便宜，是因为这部分内容已经被计算过一遍，系统只需要读取缓存状态，不需要重新跑一遍注意力计算。

这个价差结构直接决定了省钱的方向：能缓存的绝不重复计算，能少输出的绝不多说废话。很多工作流在设计时忽略了这一点，把大量固定内容反复塞进输入，又不做缓存标记，结果就是白白多花几倍的钱。

2.2 模型分层与任务匹配

另一个容易被忽视的变量是模型选择。同一个平台往往提供多个档位的模型，从轻量级到旗舰级，价格可能差几十倍。轻量模型可能只要 0.5 元/百万 token，旗舰模型可能要 50 元/百万 token。如果你的任务只是做文本分类、关键词提取、格式转换，用旗舰模型就是纯粹的浪费。

我自己的经验是，一个成熟的工作流应该做模型路由：简单任务走轻量模型，复杂推理走旗舰模型，中间层任务走中档模型。这样整体成本能压下来 50% 到 70%，而效果损失往往在可接受范围内。1.73 亿 token 如果全部走旗舰模型，和经过路由分配之后的账单，可能是两个完全不同的故事。

2.3 批量折扣与阶梯定价

部分平台还提供批量 API 或者阶梯定价，用量越大单价越低。如果你的月用量稳定在亿级 token，很可能已经触发了某些折扣档位。这些折扣不会自动生效，需要你主动申请或者使用特定的调用方式。很多人算账时用的是标准价，实际账单却因为折扣低了一截，反过来也有人用了批量接口却按实时价估算，导致预算偏差。

3. 把 1.73 亿 token 拆开算一笔细账

现在进入正题。假设这 1.73 亿 token 的构成如下（这是基于常见工作流模式的合理推测，实际数字需要看后台账单）：

按这个模型算下来，总花费大约在 1660 元左右。如果缓存命中率更低，比如只有 30%，那么普通输入的量会大幅上升，总价可能冲到 2500 元以上。如果输出占比更高，比如达到 30%，总价会进一步攀升到 3000 元附近。

反过来，如果缓存命中率能做到 75%，并且大量任务走了轻量模型，总价可能压到 800 元以内。这就是为什么我说“按官方价到底要花多少钱”这个问题，答案不是一个固定数字，而是一个区间，取决于你的使用方式。

3.1 缓存命中率为什么是最大的杠杆

缓存命中率对成本的影响是指数级的。假设你的工作流里有一个 2000 token 的系统提示词，每次调用都带上。如果一个月调用 10 万次，这部分就是 2 亿 token 的输入量。如果不做缓存，按 10 元/百万算，光系统提示词就要花 2000 元。如果做了缓存命中，按 2 元/百万算，只要 400 元。一个设置的区别，省了 1600 元。

更关键的是，缓存命中不仅省钱，还省时间。预填充阶段跳过之后，首 token 延迟会明显降低。对于交互式应用来说，这个体验提升比省钱更有价值。

但缓存不是自动生效的。大多数平台要求你在请求里显式标记哪些部分是可缓存的，或者要求相同的前缀连续出现才能命中。如果你的请求每次都有细微差异，比如时间戳、随机 ID、动态拼接的内容，缓存就永远命中不了。我踩过的坑就是：在系统提示词里加了一个当前日期的变量，结果每天缓存全部失效，白白多花了一个月的钱。

3.2 输出 token 的控制策略

输出 token 单价最高，但也是最容易控制的。核心原则就一条：让模型少说废话。具体手段包括：

• 在提示词里明确要求“只输出结果，不要解释”
• 设置 max_tokens 上限，防止模型发散
• 对于结构化任务，要求输出 JSON 或特定格式，减少自然语言的冗余
• 避免让模型重复输入内容，比如“请把上面的内容再总结一遍”这种指令

我实测过一个场景：同一个摘要任务，不加约束时模型平均输出 800 token，加了“不超过 200 字，直接给结论”之后，输出降到 250 token 左右，效果反而更聚焦。按 30 元/百万算，10 万次调用能省 1650 元。

3.3 模型路由的实际操作

模型路由听起来复杂，做起来可以很简单。最粗糙的版本就是按任务类型硬编码：分类任务走 A 模型，生成任务走 B 模型，推理任务走 C 模型。精细一点的版本可以根据输入长度、复杂度评分、历史成功率动态选择。

我自己的做法是维护一个任务-模型映射表，初期手动配置，跑一段时间后看效果和成本，再调整。比如发现某个任务用轻量模型的效果和旗舰模型差距在 5% 以内，就果断切过去。1.73 亿 token 里如果有 40% 能切到轻量模型，按单价差 10 倍算，能省下一大半的钱。

4. 实操中怎么把成本压下来

理论算完了，说点能直接上手的东西。下面这套方法是我在实际项目里反复验证过的，不保证适用于所有场景，但大方向不会错。

4.1 第一步：把账单拆开看

不要只看总 token 数。去后台把账单导出，按 token 类型、按模型、按日期拆开。重点看三个指标：缓存命中率、输出输入比、各模型用量分布。这三个数字一出来，优化方向基本就清楚了。

如果缓存命中率低于 40%，优先做缓存优化。如果输出输入比高于 0.5，优先做输出控制。如果旗舰模型用量占比超过 60%，优先做模型路由。

4.2 第二步：缓存优化的具体做法

缓存优化的核心是保持前缀稳定。具体操作：

• 把系统提示词、固定指令、知识库引用放在请求的最前面，并且确保这部分内容每次完全一致
• 把动态内容（用户输入、时间戳、随机 ID）放在后面
• 如果平台支持显式缓存标记，一定要用上
• 定期检查缓存命中日志，看看哪些请求没命中，找出原因

我遇到过一个典型案例：系统提示词里有一句“当前时间是 {{date}}”，导致每天缓存全部失效。改成“当前时间见用户消息”之后，缓存命中率从 0% 直接跳到 70%。

4.3 第三步：输出控制的提示词模板

下面这个模板可以直接抄：

你是一个执行任务的助手。请遵守以下规则： 1. 只输出最终结果，不要解释过程 2. 如果结果是列表，用简洁的条目呈现 3. 如果结果是文本，控制在 200 字以内 4. 不要重复用户输入的内容 5. 不要添加任何前缀或后缀说明

这个模板看起来简单，但实测能把输出 token 压掉 40% 到 60%。对于批量任务来说，这个节省非常可观。

4.4 第四步：模型路由的落地

先做一个简单的路由表：

跑一周之后，对比各档位的效果和成本，再微调。不要一开始就追求完美路由，先跑起来，用数据说话。

5. 那些算账时容易踩的坑

最后说几个我实际踩过的坑，以及看到别人踩过的坑。这些细节在官方文档里通常不会写，但直接影响你的账单。

5.1 重试带来的隐形消耗

API 调用失败重试是常态，但很多人没意识到重试也在烧 token。如果一次请求因为超时失败，但服务端已经处理了输入，这次输入可能照样计费。如果重试三次，就是三倍的输入成本。更糟糕的是，如果输出到一半失败，已经生成的部分也可能计费。

控制方法：设置合理的超时时间，不要无脑重试；对于幂等性要求高的任务，做好去重；监控重试率，如果超过 5%，说明你的调用逻辑有问题。

5.2 长上下文的边际成本

长上下文模型看起来很美好，但成本是非线性的。上下文越长，每次调用的输入 token 越多，而且注意力计算量随长度平方增长。一个 10 万 token 的上下文，每次调用光输入就要 1 元（按 10 元/百万算），如果调用 1000 次，就是 1000 元。

我的建议是：能用检索解决的，不要用长上下文硬塞。把知识库做成向量检索，每次只取最相关的几段，输入 token 能降一个数量级。

5.3 流式输出的计费陷阱

流式输出本身不改变计费方式，但会改变你的行为模式。因为看到输出在滚动，你可能会不自觉地让模型多说一会儿，或者忘记设置 max_tokens。我自己的经验是，流式输出场景下输出 token 平均比非流式高 20% 到 30%。

控制方法：流式输出也要设 max_tokens，并且在提示词里明确要求简洁。

5.4 免费额度和试用期的误导

很多平台提供免费额度或者试用期折扣，导致初期账单看起来很低。一旦额度用完，按标准价计费，成本会突然跳升。做预算时一定要按标准价算，不要被试用期的数字迷惑。

5.5 汇率和税费

如果用国际版服务，账单可能是美元计价，还要考虑汇率波动和可能的税费。1.73 亿 token 按美元算可能是一两百美元，换算成人民币加上税费，可能比预期高 10% 到 20%。做预算时留出这个余量。

6. 回到那个问题：到底要花多少钱

如果非要给一个数字，我的答案是：在合理优化的前提下，1.73 亿 token 的官方价账单大约在 1200 到 2000 元之间。如果完全不优化，可能冲到 3000 到 4000 元。如果优化得很好，可以压到 800 元以内。

这个区间之所以宽，是因为 token 计费不是一个线性公式，而是一个受多种因素影响的动态系统。缓存命中率、模型选择、输出控制、重试策略，每一个变量都能让最终数字上下浮动 30% 以上。

我自己的做法是：每月初按标准价做预算，留 20% 余量；月中看一次实际消耗，如果偏离预算超过 15%，就检查是哪个环节出了问题；月末做一次复盘，把优化措施固化到工作流里。这样跑下来，成本基本可控，不会出现月底看到账单吓一跳的情况。

最后分享一个我觉得最实用的技巧：把成本指标加到你的监控面板里。不要只看 token 总量，要看每任务成本、每用户成本、缓存命中率、输出输入比。这些指标一旦可视化，优化方向会自己浮现出来。我试过在面板上放了一个“每元产出”的指标，团队里每个人都能看到，结果大家自发地开始优化提示词和调用逻辑，整体成本一个月降了 35%。这比任何行政命令都管用。