调用大模型最容易被忽视的成本陷阱，不是某一次昂贵的请求，而是上下文窗口里反复付费的 token。开源项目 ai-engineer-notebooks 是一套免框架、跑在免费 Groq API 上的 Colab 实战笔记本，其中 04-context-and-caching.ipynb 专门教你做上下文窗口预算和提示缓存（Prompt Caching）：把每次请求当成一本四行账本，再叠加缓存、Batch、模型选型三个乘数，轻松把成本压到原来的 1/20。本文用 4 个技巧带你完整掌握这套成本控制方法。

为什么上下文窗口是一本"账本"？

大模型按 token 计费，成本和延迟都随你发出去的内容线性增长。每次请求其实都在花同一个预算池——上下文窗口，可以拆成四行：

真正的失败模式不是撞上限，而是成本蠕变：一个 Agent 为了回答 10 个 token 的问题，把 5 万 token 的历史反复重发。笔记本里给出的核心心法就是：先测量每一行，再谈优化。

技巧一：给上下文窗口做"预算表"

把系统提示、检索内容、对话历史分别设上限，发送前先核对是否超支。04-context-and-caching.ipynb 中有一个可直接沿用的预算检查思路：

• 为每一行设定 token 上限（如 system 2000 / context 8000 / history 4000）
• 超限行标OVER，及时压缩历史或裁剪检索片段
• 最后加上输出预留，确认总量在窗口之内

对话历史是最容易失控的一行。配套的 03-guardrails-and-budgets.ipynb 进一步教你在 Agent 循环里加成本/时延预算和停止条件——无界循环加付费 API，就是四位数账单的经典来源。

技巧二：先估算、后核账的 token 计数法

没有免费的精确计数接口怎么办？笔记本给出"双保险"方案：

1. 事后精确值：每个响应的usage.prompt_tokens就是本次真实计费 token 数，免费且准确
2. 事前估算值：用tiktoken分词器做发射前预检，误差通常在 10%–20%，足够拦截明显超支

还有一个反直觉的结论：token 数的是"文本字节"，不是"想法"。同一件事，简短短语和客套长文，token 可以差好几倍。压缩表达本身就是最便宜的成本杠杆。

技巧三：提示缓存——把重复前缀的价格打到 1 折

如果你每次请求都重发同一份 8k token 的运行手册（runbook），你就在为模型几秒前刚处理过的字节全价付费。提示缓存的经济学：

• 💾写入约 1.25 倍输入价（一次性）
• ⚡读取约 0.1 倍输入价，第二次请求开始就回本，之后前缀近乎 9 折
• ⏱️ TTL 很短（通常约 5 分钟，每次命中会刷新）

缓存是按精确字节的前缀匹配，任何一字节变化都会使之后的缓存全部失效。四类"隐形杀手"会让命中率悄悄归零（请求照常成功，只是全价付费）：

技巧四：Batch API + 模型选型，乘数级省钱

三个杠杆各自打击不同目标，而且可以乘法叠加：

Batch API 的判断标准很干脆：有人在盯进度条就别用；是 cron 任务就是白捡的钱。当"小模型 × Batch × 缓存前缀"三者叠加，比"大模型实时无缓存"便宜 20–50 倍是常态。笔记本里还附了一组"餐巾纸算式"示例：每天 1 万次请求的客服机器人，开启前缀缓存后日成本下降约九成——这类口算能力，正是设计评审中一眼揪出 10 倍浪费的关键。

延伸阅读：把这些技巧串成体系

📚 想动手跑一遍，按下面路径进入项目即可（所有笔记本自包含、跑在免费 Groq API 上）：

• 成本与缓存主课：01-model-apis/04-context-and-caching.ipynb
• 环境与支出护栏（spend guard）：00-setup/00-environment.ipynb
• Agent 成本/时延预算与停止条件：05-agents/03-guardrails-and-budgets.ipynb
• 用渐进式披露省上下文（Skills 模式）：05-agents/05-skills-and-progressive-disclosure.ipynb
• 全套最佳实践与反模式清单：docs/best-practices-and-anti-patterns.md

小结

控制大模型调用成本的核心就一句话：把上下文窗口当预算管，把 token 当账目记。先给四行账本设上限、用估算+核账双保险拦截超支，再用提示缓存把重复前缀打到 1 折，最后用 Batch 与模型选型乘数叠加——这套"预算 → 测量 → 缓存 → 堆乘数"的方法，会让你在拿到账单之前就看见那笔 10 倍的节省。