课程地图：七组共 19 个概念

一张地铁线路图：先看到所有线路，再一站一站地坐过去。

先是计价表——成本是怎么算的。然后是六组杠杆：选哪个模型，怎么在模型之间分配请求，怎么避免重复付费，怎么少发内容，怎么在成本与速度、质量之间取得平衡，以及怎么把这一切衡量出来。

下面每个概念的形式都一样：英文术语（你在文档里会遇到的那个词）、一个日常画面、一张图，以及一张带字段的卡片：是什么、例子、陷阱，以及关联概念。

Token——成本的单位

一辆按里程计价的出租车——这趟车的价格不是统一定价，而是行驶的距离，一路都在跳表。

一个 token 是一小段文本——大约是一个词，或一个词的一部分——它就是你被计费的单位。你不是按请求以统一价格付费，而是为模型读取和写出的文本量付费。一旦你把 token 看作那块计价表，一切的成本就都变得清晰可读了。

Input / Output Tokens——进去的和出来的，你都要付费

一通电话，你说的和你听到的都要收费——整段对话都算，不只是你那一半。

你要为 input token——你发送的一切：prompt、上下文、历史记录——以及 output token——模型生成的一切付费。你每次调用都发送的长上下文，每次都要付费，哪怕答案很短。这就是为什么一个把巨量上下文塞进每个请求的功能，不管 output 多大都很贵。

Cost Formula——每次调用的 token 数 × 调用次数

一家按件、按里程双重计费的快递服务——你的总价就是跑了多少趟乘以每趟跑多远。砍掉任何一个，账单都会下降。

你的总成本有两个乘数：每次调用多少 token（主要取决于你发送多少上下文）和你做多少次调用（取决于你的设计有多「话痨」——单次调用、固定链路，还是一个循环很多次的 agent）。长上下文乘以大量调用，就是 AI 账单爆炸的方式。本课中几乎每一项省钱技巧，都是在拉动这两个杠杆之一：少发或少调用。

Frontier Model——最聪明的，也是最贵的

一支从自行车到货运卡车的车队——每趟的成本天差地别，而用卡车去送一封信，为这点活儿花了大把钱。

模型从小而便宜到大而昂贵，底端和顶端之间每 token 的价格差好几倍。最大、最聪明的那个就是 frontier model。它在困难、开放式的推理上确实更强。但真实产品做的大多数事并不是这类：给消息分类、抽取一个字段、把一段话做摘要、给请求做路由。一个小模型处理这些，质量好到你无法和那个巨无霸区分开。

Right-sizing——让模型匹配任务

好的经理把难题交给专家，把例行工作交给新人——让人才匹配任务，而不是反过来。

Right-sizing 的意思是让模型匹配任务真正的需求。困难、新颖、多步骤的推理值得用强大的模型；简单、范围明确、重复性的工作交给小模型。这不是在质量上妥协——而是让能力匹配需求，这样你就不再为例行工作多付钱，同时仍把重型模型用在真正需要的地方。一个任务一个任务地把这件事做对，是影响 AI 产品账单的最大杠杆。

Model Routing——默认用小的，需要时再升级

一个客服台：一线人员处理大多数问题，只把真正棘手的转给专家——大多数问题根本不需要升级。

model routing 模式：默认把每个请求发给小而便宜的模型，只有任务真正需要时才升级到更大、更贵的模型。由于简单的情况占多数，大多数请求都能便宜地处理，你只为少数值得的请求付溢价。默认做法从「用最好的模型、以后再省钱」翻转为「用能过线的最便宜的模型，过不了再升级」。

Router——谁来决定每个请求用哪个模型

一位分诊护士迅速评估每个病人，把他们送到合适的护理级别——一个又快又便宜的判断，把昂贵的资源导向真正需要的地方。

要做 routing，得有东西来判断每个请求的难度——一个 router。它可以是简单的规则（短而结构化的任务给小模型；长而开放的给大模型）、一个便宜的分类器，甚至一个判断难度的小模型。router 本身必须又便宜又快，因为它要处理所有请求。好的 router 会悄悄地把大部分流量送给便宜的模型，把 frontier 留给真正困难的那一小部分。

Plan-and-Execute——强模型做规划，便宜的模型去执行

建筑师设计大楼，但施工队承担大部分体力活——你为思考付钱给昂贵的专家，为干活付钱给更便宜的人手。

routing 的一种强力形式是 plan-and-execute：一次调用强模型，把困难的任务拆成具体的步骤，然后由更便宜、更小的模型去执行这些步骤。昂贵的推理只发生一次；大部分工作都在低价下完成。与全部交给大模型相比，这种混合设计可以大幅压低账单。

Response Caching——同一个答案别付两次钱

一位职员把最常被问到的答案记在柜台的卡片上，而不是每次有人问都从头去查。

如果你的应用反复产生同样的模型输出——同一个问题、同一份文档的摘要、同一次查询——你就是在一遍又一遍地为相同的工作付费。Response caching 第一次把结果存起来，之后重复出现时立刻免费地提供（缓存课讲了具体机制）。昂贵的调用只发生一次；便宜的读取发生许多次。

Prompt Caching——复用不变的部分

一封格式信函，冗长的标准开头已经预先印好，你只需要填那几行会变的内容——不用每次都重写整封信。

通常你的上下文中有一大块在每次调用里都相同——一个很长的 system prompt、固定的指令、一份共享的文档。Prompt caching 让模型复用那段不变的前缀，而不是每次都重新处理，对重复的部分收取低得多的费用。由于这段固定的上下文往往占了你 input token 的大头，缓存它可以在高流量的功能上大幅削减 input 成本。这是一项几乎免费的节省：把稳定的部分放在最前面，并保持完全一致。

Semantic Caching——捕捉近似的重复

一个服务台，能认出「怎么重置密码」和「我忘了密码」是同一个问题——并给两者同样的现成答案。

除了完全匹配之外，semantic caching 用含义（借助 embeddings）来识别新请求与之前的某个请求是否足够接近，从而复用答案——「你们的退款政策是什么」和「退货怎么处理」不必分别重新计算。它抓住了常见的情形：用户用不同的措辞问同一件事，把一长串被换了说法的问题变成便宜的缓存命中。

Context Trimming——少发一点上下文

旅行只打包你真正会用到的东西，而不是把整个衣柜都带上——多带的每一件都要花力气扛着，而大部分你根本碰都不会碰。

既然你按 input token 付费，最直接的节省就是 context trimming。裁剪对话历史，把旧的轮次做摘要而不是原样带着，只检索最相关的几个片段而不是全部。这是 context engineering 一举两得：更紧凑的上下文不仅对质量更好，每次调用也更便宜。大多数臃肿的 AI 账单底下，都有臃肿的 prompt。

Concise Structured Output——要求更少的输出

问一个只要「是」或「否」的问题，你得到的是快速的答案；问一个邀请长篇大论的问题，你得到的是一篇你得先付钱、再去裁剪的文章。

output token 你也要付费，所以别让模型生成超出你所需的内容。请求简洁的结构化输出——只要指定的字段、简短的答案、没有啰嗦的开场白——而不是一篇你最后只会从中解析出一个数字的长文。结构化输出在这里一举两得：它更可靠，而且更便宜，因为紧凑的 schema 产生的 token 比自由文本更少。

Batching——能成组的就成组

洗一整桶衣服，而不是一次洗一件衬衫——成组处理能摊薄固定开销，每次运行完成得更多。

当你有许多相似的请求，而且每个都不需要立刻得到答案时，把它们批处理——一起处理许多个——通常比一个一个发出去更便宜，服务商也常常为可以在方便时运行的 batch job 提供折扣。你用延迟（每一项都要等整批）换取更低的成本——这对后台或批量工作是合适的交易：处理积压的任务、丰富数据集。

Latency–Cost–Quality Triangle——三者互相拉扯

老作坊门口那块牌子——「快、便宜、好：三选二」——因为在其中一项上使劲，通常要在另一项上付出代价。

成本、延迟（速度）和质量构成一个三角，它们互相交换。最大、最聪明的模型质量最好，但成本最高，往往也最慢；小模型便宜又快，但在困难任务上较弱；大量上下文能提升质量，但会同时抬高成本和延迟。你很少能让三者同时拉满。所以你不会孤立地优化成本——对每个使用场景，你要决定哪一角最重要，以及愿意拿什么去换。

Use-case Balance——按功能选择平衡点

比赛选跑车，搬家选货车——同一个问题，相反的答案，因为是任务决定了什么重要。

合适的平衡完全取决于功能本身。面向用户的聊天成败取决于延迟，需要又快又有能力的模型。夜间的批处理任务只关心成本，可以用最便宜、最慢的选项。高风险的法律或医疗答案把质量放在两者之上。三角上没有唯一正确的点——说清楚这个功能必须赢下哪一角、可以牺牲哪一角，是驱动其他所有选择的决定。

Streaming——廉价地获得「感知速度」

一间厨房做好一道就上一道，而不是让你等整桌饭菜——总时间一样，但等待的感觉短得多。

有一个技巧能绕开这个三角：把模型的输出在生成的同时一个 token 一个 token 地流式传输，让用户立刻看到文字出现，而不是盯着空白屏幕直到整个答案完成。总时间不变，但感知延迟大幅下降。这是一种不换更快的模型就让功能「感觉很快」的廉价办法——管理的是等待的体验，而不是等待本身。

Cost per Task——按任务衡量，而不只是看总账单

一份逐项列出的账单，显示每道菜花了多少，而不是一个大数字——只有明细才能告诉你该在哪里砍。

你无法控制你没有衡量的成本。要记录每个功能、每种调用类型、每个任务实际花了多少 token——即 cost per task——而不只是一笔笼统的月度账单。成本是需要像性能一样去监测和关注的东西。大多数昂贵的 AI 功能都有一两个成本热点，明细能立刻揭示它们，而总数则把它们藏得严严实实。

Clear the Bar——刚好过线的最便宜的方案

你买的是够用的工具，而不是货架上最贵的那个——超出你所需的能力，只是花掉的钱。

统领性的原则：使用仍然满足你的质量门槛的最便宜的模型、最小的上下文和最少的调用——不多也不少。这不是为了便宜而便宜；而是拒绝为任务用不上的能力买单。用 evals 设定门槛，然后找到能过线的最轻的配置。大多数节省并不是什么聪明的花招——而是不再出于习惯默认选择最强大、上下文最多、最话痨的那个方案。

一切如何关联

一块有三个旋钮的控制面板：每 token 的价格、每次调用的 token 数、调用次数。本课中的每项技巧都在拧其中一个。

本课中的每项技巧都作用于账单的三个乘数之一。Right-sizing、Model Routing 和 Plan-and-Execute 降低每 token 的价格。Context Trimming、Concise Output 和 Prompt Caching 降低每次调用的 token 数。Response 和 Semantic Caching 降低调用次数。Batching 用等待换来折扣，Cost per Task 告诉你该往哪看，而这个三角提醒你：每个杠杆都要拿延迟和质量去交换。