账单持续上涨，不清楚大模型使用成本究竟花在长上下文、重复请求还是模型输出上？
最快解法：先从账单和调用日志定位可计费用量，再分别测试提示词优化、dsh-purge 和本地部署；只有实际费用下降且任务质量可接受，才算省钱。
这篇文章适合经常调用大模型 API、想控制账单的开发者与团队；也适合评估 dsh-purge 是否适用于自身调用链路的技术人员。
如果你正在考虑将 AI Agent 改为本地运行，文中的总成本核算方法也能帮你判断是否值得迁移。
大模型使用成本：先确认账单里的钱花在哪里
“调用次数没变，为什么账单上升？”先不要急着换工具。一次请求可能包含很长的系统提示、历史对话、检索片段和工具返回；输出长度、重试次数、缓存规则及额外工具费用，也可能让最终支出不同。各平台的计费项目并不统一，需以对应平台定价页和账单明细为准。
以官方定价说明为例，模型输入与输出可能分别计费，内置工具也可能另有计费方式；不同模型或服务档位的规则还会不同。以下官方资料按各自服务和模型列明计费项目，不能拿某个平台的单价推算另一家的账单：模型 API 计费项目说明和另一份模型 API 定价说明。页面信息于 2026 年 10 月 21 日核对；实际费用仍以你账户的账单和当前适用条款为准。
先按以下项目把当前支出拆开，不要只抄一行“月账单总额”：
- 输入用量：系统提示、用户输入、对话历史、检索结果分别记录。不断增长的历史记录可能让看似简单的新问题，每次都带上大量旧内容。
- 输出用量：记录回答长度，以及模型是否生成了不必要的解释、重复格式或长篇推理内容。某些服务还会将思考过程相关用量计入输出，需核实自己的计费规则。
- 调用与重试：记录每个任务实际触发的请求数，包括失败重试、Agent 多轮规划、工具调用后再次请求模型等。
- 附加项目：检查缓存、搜索或其他工具费用，区分一次性请求费用与持续存储费用。模型定价页和缓存说明页可能分别列出不同用量的计费方法，不能只看 token 单价。
- 质量与返工：记录答案是否通过任务验收、是否需要人工修改，以及失败后是否重新调用。单次调用变便宜，如果失败和返工变多，总成本未必下降。
建一份按任务分类的基线记录：任务类型、模型与配置、输入和输出用量、请求次数、额外费用、结果是否合格、人工返工情况，以及统计周期。不要把不同任务混成平均值，否则高频简单任务与低频复杂任务会互相掩盖。
dsh-purge 的成本边界
dsh-purge 能直接降低大模型账单吗？目前不能仅凭名称判断。项目自述将 dsh-purge 描述为面向本机 Harness 的红队测试插件，涉及提示注入、主机策略与测试流程；这不等于它是通用 API 计费优化器，也没有理由预设它会减少请求用量。项目说明还提到，新会话会载入提示内容，因此是否影响实际输入 token，必须以调用链路记录为准。查看项目说明。这项判断依据是项目自述页面于 2026 年 10 月 21 日核对的内容，不是独立性能或节省测试。
要验证它是否省钱，先回答一个更具体的问题：它是否改变了你所用模型每个任务的实际计费用量？
- 若它确实减少传入模型的提示内容，需观察每次请求的输入用量是否下降。
- 若它帮助你避免不必要的重试或多轮调用，需观察同一任务的总请求数是否减少。
- 若它只是改动权限、工具边界或提示内容，但输入、输出和请求次数都没变化，就不能把账单减少归因于它。
- 若提示内容变长，或者需要额外调用模型完成测试，成本甚至可能上升。
在相同任务、模型、配置和测试样本下，分别记录启用前后的调用日志、账单明细及结果质量。不要把 Harness 本机的策略调整，直接等同于 API 调用成本优化。对于一般 API 调用链路，如果 dsh-purge 并不在请求路径中，就应先验证它是否能影响该链路；没有可观测变化，就没有直接省钱依据。
提示词优化：减少无效输入与返工
提示词优化怎样降低 token 消耗和调用成本？先删掉重复指令、过时历史和任务无关的背景，再减少不必要的往返；但每次删改都要检查结果质量。仅仅把提示写短，并不代表成本一定下降：如果关键信息被删掉，模型答错后需要多次纠正，整体请求数可能反而增加。
一个常见场景是客服 Agent 每次都把完整历史对话、固定规则和检索到的全部资料重新发给模型。你可以先按任务保留必要规则，控制历史范围，对检索结果做去重和筛选；如果固定前缀经常重复，再查看平台是否支持提示缓存以及缓存的具体计费方式。某官方缓存机制说明支持模型在提示超过 1,024 个 token 时匹配重复前缀，并以 128 个 token 为增量扩展缓存前缀；这只是该机制的规则，不代表其他平台也适用。缓存机制说明。另一份官方缓存文档也说明，缓存输入可能有较低的读取费率，但缓存存储时长等因素仍需计入。缓存计费与有效期说明。
提示词改版前后，固定任务集与模型版本，采用同一批输入进行对照：
- 记录每类任务的输入与输出用量、调用次数和账单项目。
- 找出重复规则、冗长示例、已经不相关的历史内容。
- 每轮只改一类内容，避免无法判断哪项改动带来变化。
- 用相同任务样本重跑，记录准确性、格式通过率与人工返工。
- 将单次调用成本与完成一个合格任务的成本分别比较。
- 回到平台实际账单核验变化；若调用记录显示用量下降、但附加费用或返工上升，应重新评估。
优点是通常可以从现有链路开始，不必先采购设备；风险是过度压缩上下文可能损伤回答质量，尤其是依赖规则、长历史或复杂检索的任务。若任务依赖大量固定上下文，优化重复内容和核对缓存计费，比机械删字更有针对性。
本地部署：API 支出之外还有运行总账
本地部署可以减少对外部 API 的依赖，但不等于运行费用归零。需要纳入设备或算力投入、用电、散热、部署与升级、故障处理、备份，以及负责维护的工程时间。若本地模型效果不足，仍需调用云端模型兜底，实际结果可能变成两边都付费。
设备适配也不能只看芯片型号。模型权重、上下文和并发会共同影响内存需求；苹果的开发者演示中，某个模型在 4.5 bit 量化后，光权重仍约需 380 GB 内存，并使用具有 512 GB 统一内存的设备运行。它说明的是超大模型的特定演示，不是所有模型的通用配置要求，更不能据此推算你的任务性能或盈亏结果。本地模型演示与内存说明。苹果的研究资料则介绍了 Apple 芯片上的 MLX 本地推理方向，但是否满足你的模型、并发和质量要求，仍需在目标环境复测。MLX 本地推理研究说明。
本地部署大模型什么时候可能比 API 更省钱？当你已经有合适设备、任务量持续且比较稳定，目标模型在本地能达到验收要求，同时团队能承接维护时，才值得把它列为候选。低频、波动大的任务通常更难摊薄设备与维护投入；如果必须使用更强的闭源模型、严格依赖云端工具，或需要多用户稳定并发，也要把本地方案的能力缺口和兜底 API 支出记进总账。
评估时可先用这条公式整理项目，而不是套用未经验证的通用盈亏阈值：
本地方案周期总成本＝设备或算力投入分摊＋能耗＋维护与管理投入＋仍需支付的云端调用费。
API 方案则按同一周期汇总实际输入、输出、调用和额外计费项。两边都用“完成同等数量且达到同等质量要求的任务”作比较，不能一边算 API 的真实账单，另一边只算本地单次推理费用。
按负载做选择，再决定是否组合
dsh-purge、提示词优化和本地部署哪种更有效？没有脱离任务条件的统一答案：提示词优化主要影响输入、输出与返工；dsh-purge 只有在实际改变可计费请求用量时，才有直接节省依据；本地部署主要替换部分 API 支出，同时新增设备和运行成本。把费用与质量放在同一份任务记录里比较，才知道哪项对你的总账有效。
- 若调用量低、任务偶发：先核对账单、排查重复请求，再优化提示词；除非已有合适设备和明确的隐私或离线需求，否则不要仅因单价焦虑就直接投入本地部署。
- 若调用持续且负载稳定：先做提示词对照测试；再选代表性任务验证本地模型的质量、并发和维护投入。只有同等任务的周期总成本确实下降，才考虑迁移更多负载。
- 若调用量波动较大：保留 API 弹性，优先去掉无效调用和冗余输入。若测试发现本地方案在低谷时仍有设备与维护成本，而高峰时又需 API 兜底，就把两边支出一并核算。
- 若正在试用 dsh-purge：先确认它确实位于目标调用链路内，再做启用与停用的同条件测试；如果计费用量没有可复现变化，就不要将其记作节省方案。
可复现的成本验证清单
- [ ] 固定任务样本、模型版本、配置和统计周期。
- [ ] 分开记录输入、输出、请求次数、重试、工具费用与缓存费用。
- [ ] 记录答案合格率和人工返工，避免只比较 token。
- [ ] 每次只改变一种变量，并保存启用前后的调用日志。
- [ ] 本地测试补记设备、能耗、维护投入和云端兜底支出。
- [ ] 用实际账单复核结论；无法复现的差异先不计入预期节省。
提醒：如果平台账单只展示汇总金额，先为每类任务增加请求级用量记录。没有请求级基线，就很难判断费用变化来自提示词、调用频率、缓存规则还是模型本身。
如果你目前主要依赖 API，继续调用的优势是免去设备采购和本地运维，但长上下文、重复请求和高峰调用仍可能累积费用；本地运行则减少部分外部调用，却要承担算力、用电和维护责任。先拿真实账单与任务样本完成对照，再判断迁移是否适合你；如果需要评估 Mac 运行环境，可以查看 Mac 云端租用的适用信息 和 Mac mini 配置与价格页面，按你的负载确认是否匹配。若只是短期验证本地模型或搭建临时测试环境，可了解 Kvmzen 的 Mac 算力方案；长期稳定重负载或必须连接本地物理设备时，则应优先评估自有设备与维护能力。