# 按 token 为智能付费 关于用 AI 做开发的经济学速成课——为什么每次调用模型都要花钱花时间，以及如何把成本控制在可承受范围内。19 个概念——Token、Frontier model、Model routing、Plan-and-execute、Prompt caching、Semantic caching、Batching、延迟-成本-质量三角、Streaming 等——每个都有英文名、一张图和一张卡片：是什么 → 例子 → 陷阱 → 关联。结尾附一页速查表。核心思想：成本和速度是设计约束，能过线的最便宜的模型通常就赢了。 - **Author:** Fedor Chishchin - **Level:** intermediate - **Reading time:** ~30 分钟阅读 - **Published:** 2026-06-13 - **Source:** https://fedorthinks.com/zh/learn/model-economics-express --- ## 1. 你按 token 付费 要控制一个 AI 功能的成本，你首先得看懂那块计价表。模型按 token 计费，几乎每一个经济决策都源自这意味着什么。 ### 课程地图：七组共 19 个概念 > 一张地铁线路图：先看到所有线路，再一站一站地坐过去。 先是**计价表**——成本是怎么算的。然后是六组杠杆：选哪个模型，怎么在模型之间分配请求，怎么避免重复付费，怎么少发内容，怎么在成本与速度、质量之间取得平衡，以及怎么把这一切衡量出来。 _Diagram: 上面是计价表，下面是六组杠杆——第 2–7 章依次讲它们。_ 下面每个概念的形式都一样：**英文术语**（你在文档里会遇到的那个词）、一个日常画面、一张**图**，以及一张带字段的**卡片**：_是什么_、_例子_、_陷阱_，以及*关联*概念。 ### Token——成本的单位 > 一辆按里程计价的出租车——这趟车的价格不是统一定价，而是行驶的距离，一路都在跳表。 一个 **token** 是一小段文本——大约是一个词，或一个词的一部分——它就是你被计费的单位。你不是按请求以统一价格付费，而是为模型读取和写出的文本量付费。一旦你把 token 看作那块计价表，一切的成本就都变得清晰可读了。 _Diagram: 文本被切成 token，计价表逐个计数——账单随每个 token 增长。_ #### Token (计费单位) - **是什么:** 一小段文本——大约一个词或词的一部分。计费单位。 - **例子:** 「退款政策是 30 天」大约是七个 token，而不是一次请求。 - **陷阱:** 你为文本的量付费，而不是为请求的数量：长请求花得更多。 - **关联:** token 汇总成 **Input / Output Tokens** 和整个 **Cost Formula**。 ### Input / Output Tokens——进去的和出来的，你都要付费 > 一通电话，你说的和你听到的都要收费——整段对话都算，不只是你那一半。 你要为 **input token**——你发送的一切：prompt、上下文、历史记录——_以及_ **output token**——模型生成的一切付费。你每次调用都发送的长上下文，每次都要付费，哪怕答案很短。这就是为什么一个把巨量上下文塞进每个请求的功能，不管 output 多大都很贵。 _Diagram: 左边：你发送的一切。右边：模型写出的内容。两半都要计费——每次调用都是如此。_ #### Input / Output Tokens (你发出的，你收到的) - **是什么:** Input——prompt、上下文、历史。Output——生成的答案。 - **例子:** 几千 token 的 system prompt + 一个简短的问题 + 一行的回答：几乎整张账单都是 input。 - **陷阱:** 大上下文每次调用都要花钱，而不是只花一次。 - **关联:** **Context Trimming** 和 **Prompt Caching** 削减 input；**Concise Structured Output** 削减 output。 ### Cost Formula——每次调用的 token 数 × 调用次数 > 一家按件、按里程双重计费的快递服务——你的总价就是跑了多少趟乘以每趟跑多远。砍掉任何一个，账单都会下降。 你的总成本有两个乘数：每次调用多少 **token**（主要取决于你发送多少上下文）和你做多少次**调用**（取决于你的设计有多「话痨」——单次调用、固定链路，还是一个循环很多次的 agent）。长上下文乘以大量调用，就是 AI 账单爆炸的方式。本课中几乎每一项省钱技巧，都是在拉动这两个杠杆之一：**少发**或**少调用**。 _Diagram: 两个杠杆在你手里：少发和少调用。每个 token 的价格（你选的模型）会同时放大这两者。_ #### Cost Formula (是什么在推高账单) - **是什么:** 成本 = 每次调用的 token 数 × 调用次数（× 模型每 token 的价格）。 - **例子:** 一个带着长上下文调用 20 次的 agent，花费是同样上下文只调用一次的许多倍。 - **陷阱:** agent 循环会悄悄地让调用次数成倍增加。 - **关联:** 接下来的每项技巧都在缩小其中一个乘数——见结尾的关系图。 > **定调的问题:** 「到底是什么在推高这个功能的账单——每次调用都带着庞大的上下文、一个聪明但昂贵的 模型、还是调用太多次——因为这能告诉我该拉哪个杠杆？」 > 模型按 token 计费，input 和 output 都算。你的成本是每次调用的 token 数乘以调用次数——所以每一项节省都归结为：发送更少，或者调用更少。 ## 2. frontier 并不总是答案 本能反应是凡事都用最聪明的模型。这种本能很烧钱，因为模型之间的价格差距巨大，而大多数任务根本不需要顶配。 ### Frontier Model——最聪明的，也是最贵的 > 一支从自行车到货运卡车的车队——每趟的成本天差地别，而用卡车去送一封信，为这点活儿花了大把钱。 模型从小而便宜到大而昂贵，底端和顶端之间每 token 的价格差好几倍。最大、最聪明的那个就是 **frontier model**。它在困难、开放式的推理上确实更强。但真实产品做的大多数事并不是这类：给消息分类、抽取一个字段、把一段话做摘要、给请求做路由。一个小模型处理这些，质量好到你无法和那个巨无霸区分开。 _Diagram: 每 token 的价格从小模型到 frontier 成倍攀升（并非按比例绘制）。_ #### Frontier Model (顶配型号) - **是什么:** 产品线里最大、最聪明、也最贵的模型。 - **例子:** 用它来给工单分类，就像请顶级外科医生来贴个创可贴。 - **陷阱:** 让它成为每项任务的默认选择，就等于默认选了最贵的方案——这是 AI 产品里最常见的浪费。 - **关联:** **Right-sizing**、**Model Routing** 和 **Plan-and-Execute** 决定它该用在哪里。 ### Right-sizing——让模型匹配任务 > 好的经理把难题交给专家，把例行工作交给新人——让人才匹配任务，而不是反过来。 **Right-sizing** 的意思是让模型匹配任务真正的需求。困难、新颖、多步骤的推理值得用强大的模型；简单、范围明确、重复性的工作交给小模型。这不是在质量上妥协——而是让能力匹配需求，这样你就不再为例行工作多付钱，同时仍把重型模型用在真正需要的地方。一个任务一个任务地把这件事做对，是影响 AI 产品账单的最大杠杆。 _Diagram: 例行任务交给小模型；只有真正困难的才交给 frontier。_ #### Right-sizing (模型适配任务) - **是什么:** 对每个任务，用能把它做好的最弱的那个模型。 - **例子:** 从邮件里抽取一个字段——小模型；理清一桩混乱的法律案件——大模型。 - **陷阱:** 「做得好」要靠 evals 验证，而不是靠肉眼。 - **关联:** 静态版本；动态版本是 **Model Routing**。由 **Clear the Bar** 检验。 > **模型的问题:** 「这个任务真的需要最聪明的模型吗——还是我在为一个小而便宜的模型也能做得毫无区别的活， 付 frontier 的价钱？」 > 模型价格差异巨大，而大多数任务不需要 frontier。例行的用小的，真正困难的用强的——别再为大多数简单任务多付钱。 ## 3. 按难度分流 如果大部分工作很简单、一部分很难，你就不会给所有事选同一个模型——而是把每个请求送到合适的那个。这种即时的选择就是 routing，是最有杠杆效应的模式之一。 ### Model Routing——默认用小的，需要时再升级 > 一个客服台：一线人员处理大多数问题，只把真正棘手的转给专家——大多数问题根本不需要升级。 **model routing** 模式：默认把每个请求发给小而便宜的模型，只有任务真正需要时才**升级**到更大、更贵的模型。由于简单的情况占多数，大多数请求都能便宜地处理，你只为少数值得的请求付溢价。默认做法从「用最好的模型、以后再省钱」翻转为「用能过线的最便宜的模型，过不了再升级」。 _Diagram: 请求先去小模型；如果答案不达标，就升级到 frontier。_ #### Model Routing (升级) - **是什么:** 按难度，逐个请求即时地选择模型。 - **例子:** 客服机器人：「我的订单在哪」交给小模型，一桩复杂的投诉交给大模型。 - **陷阱:** 你需要一种办法发现便宜的答案不达标——否则糟糕的答案会到达用户手里。 - **关联:** 决定由 **Router** 做出；姐妹模式——**Plan-and-Execute**。 ### Router——谁来决定每个请求用哪个模型 > 一位分诊护士迅速评估每个病人，把他们送到合适的护理级别——一个又快又便宜的判断，把昂贵的资源导向真正需要的地方。 要做 routing，得有东西来判断每个请求的难度——一个 **router**。它可以是简单的规则（短而结构化的任务给小模型；长而开放的给大模型）、一个便宜的分类器，甚至一个判断难度的小模型。router 本身必须又便宜又快，因为它要处理所有请求。好的 router 会悄悄地把大部分流量送给便宜的模型，把 frontier 留给真正困难的那一小部分。 _Diagram: router 把大部分流量送给小模型，把困难的那一小部分送给 frontier。_ #### Router (调度员) - **是什么:** 评估请求并为它挑选模型的组件。 - **如何运作:** 规则、便宜的分类器，或一个小的评判模型。 - **陷阱:** 如果 router 本身又慢又贵，它会吃掉全部节省。 - **关联:** **Model Routing** 的核心；把模型之间的价格差变成节省。 ### Plan-and-Execute——强模型做规划，便宜的模型去执行 > 建筑师设计大楼，但施工队承担大部分体力活——你为思考付钱给昂贵的专家，为干活付钱给更便宜的人手。 routing 的一种强力形式是 **plan-and-execute**：一次调用强模型，把困难的任务拆成具体的步骤，然后由更便宜、更小的模型去执行这些步骤。昂贵的推理只发生一次；大部分工作都在低价下完成。与全部交给大模型相比，这种混合设计可以大幅压低账单。 _Diagram: 强模型只写一次计划；便宜的模型执行各个步骤。_ #### Plan-and-Execute (规划用贵的，执行用便宜的) - **是什么:** 强模型做规划；便宜的模型执行计划的各个步骤。 - **例子:** 基于 50 份文档的报告：大模型决定抽取什么、怎么合并，小模型逐份处理文档。 - **陷阱:** 一个糟糕的计划会被便宜的步骤忠实地——并且错误地——执行下去。 - **关联:** **Model Routing** 的变体；精准地使用 **Frontier Model**。 > **分流的问题:** 「我是把每个请求都发给同一个模型——还是把简单的大多数分流给便宜的模型，只把真正困难的 情况升级给昂贵的那个？」 > 默认用小模型，只有任务值得时才升级到大模型。一个便宜的 router，加上「规划用贵的、执行用便宜的」的分工，把模型之间的价格差变成节省。 ## 4. 缓存：别把活干两遍 最便宜的模型调用，就是你根本没发出的那次。当相同或相似的工作反复出现时，记住答案而不是重新计算，是你能得到的最大节省之一。 ### Response Caching——同一个答案别付两次钱 > 一位职员把最常被问到的答案记在柜台的卡片上，而不是每次有人问都从头去查。 如果你的应用反复产生同样的模型输出——同一个问题、同一份文档的摘要、同一次查询——你就是在一遍又一遍地为相同的工作付费。**Response caching** 第一次把结果存起来，之后重复出现时立刻免费地提供（缓存课讲了具体机制）。昂贵的调用只发生一次；便宜的读取发生许多次。 _Diagram: 命中是即时且免费的；未命中则交给模型，结果被存起来。_ #### Response Caching (复用整个答案) - **是什么:** 存下完成的模型答案，输入完全相同时直接提供。 - **例子:** 同一篇文章给一千个读者的摘要，只计算一次。 - **陷阱:** 只有输入真的会重复的地方才划算；答案可能过期。 - **关联:** 由 **Prompt Caching**（共享的 prompt 部分）和 **Semantic Caching**（相似的请求）进一步扩展。 ### Prompt Caching——复用不变的部分 > 一封格式信函，冗长的标准开头已经预先印好，你只需要填那几行会变的内容——不用每次都重写整封信。 通常你的上下文中有一大块在每次调用里都相同——一个很长的 system prompt、固定的指令、一份共享的文档。**Prompt caching** 让模型复用那段不变的**前缀**，而不是每次都重新处理，对重复的部分收取低得多的费用。由于这段固定的上下文往往占了你 input token 的大头，缓存它可以在高流量的功能上大幅削减 input 成本。这是一项几乎免费的节省：把稳定的部分放在最前面，并保持完全一致。 _Diagram: 第一次调用付全价；之后共享的前缀来自缓存，便宜得多。_ #### Prompt Caching (缓存前缀) - **是什么:** 服务商复用不变的 prompt 前缀，并对它收取更低的费用。 - **例子:** 一个带长指令和参考文档的机器人：这些被缓存，只有用户的问题按全价计费。 - **陷阱:** prompt 开头的任何小改动（比如一个时间戳）都会破坏前缀匹配。 - **关联:** 削减 **Input / Output Tokens** 的 input 一侧；与 **Context Trimming** 互补。 ### Semantic Caching——捕捉近似的重复 > 一个服务台，能认出「怎么重置密码」和「我忘了密码」是同一个问题——并给两者同样的现成答案。 除了完全匹配之外，**semantic caching** 用含义（借助 **embeddings**）来识别新请求与之前的某个请求是否足够接近，从而复用答案——「你们的退款政策是什么」和「退货怎么处理」不必分别重新计算。它抓住了常见的情形：用户用不同的措辞问同一件事，把一长串被换了说法的问题变成便宜的缓存命中。 _Diagram: 含义相近的两个请求共享一个缓存的答案。含义相距很远的请求交给模型。_ #### Semantic Caching (按含义缓存) - **是什么:** 以请求的含义（一个 embedding）而不是确切文本作为键的缓存。 - **例子:** 「我忘了密码」得到的是为「怎么重置密码」存下的答案。 - **陷阱:** 相似度阈值要谨慎设置：用词相似的问题可能需要不同的答案。 - **关联:** 扩展 **Response Caching**；建立在 embeddings 之上。 > **缓存的问题:** 「这个功能在哪里重复计算相同或几乎相同的答案——缓存，包括固定的 prompt 前缀，能否把这种 重复的成本变成一次性的成本？」 > 最便宜的调用就是你跳过的那次。缓存重复的答案，复用不变的 prompt 前缀，并用语义捕捉换了说法的重复——重复的工作就是你本不必付的重复成本。 ## 5. 少发一点，并且批处理 当你确实要发起调用时，你通过控制发送多少、要求多少来控制它的成本。少发内容和把工作成组处理，是压低单次调用成本的日常杠杆。 ### Context Trimming——少发一点上下文 > 旅行只打包你真正会用到的东西，而不是把整个衣柜都带上——多带的每一件都要花力气扛着，而大部分你根本碰都不会碰。 既然你按 input token 付费，最直接的节省就是 **context trimming**。裁剪对话历史，把旧的轮次做**摘要**而不是原样带着，只检索最相关的几个片段而不是全部。这是 **context engineering** 一举两得：更紧凑的上下文不仅对质量更好，每次调用也更便宜。大多数臃肿的 AI 账单底下，都有臃肿的 prompt。 _Diagram: 之前：完整的历史和所有文档。之后：一段简短的摘要、前三个片段和问题。_ #### Context Trimming (只发需要的) - **是什么:** 只给模型这一步需要的东西。 - **例子:** 不发 40 轮历史——改发一段摘要；不发整个知识库——改发前三个片段。 - **陷阱:** 裁得太狠，模型会丢掉它需要的一个事实，答得更差。 - **关联:** 缩小 **Cost Formula** 的第一个乘数；是 **Prompt Caching** 的邻居。 ### Concise Structured Output——要求更少的输出 > 问一个只要「是」或「否」的问题，你得到的是快速的答案；问一个邀请长篇大论的问题，你得到的是一篇你得先付钱、再去裁剪的文章。 output token 你也要付费，所以别让模型生成超出你所需的内容。请求**简洁的结构化输出**——只要指定的字段、简短的答案、没有啰嗦的开场白——而不是一篇你最后只会从中解析出一个数字的长文。**结构化输出**在这里一举两得：它更可靠，*而且*更便宜，因为紧凑的 schema 产生的 token 比自由文本更少。 _Diagram: 一篇长文要花许多 output token；只有一个字段的 schema 给出同样的答案，便宜得多。_ #### Concise Structured Output (紧凑的 schema) - **是什么:** 限制答案的形状和长度：只要你需要的字段。 - **例子:** 把评论的评分写成 `{"score": 4}`，而不是三段推理。 - **陷阱:** schema 太死板，可能让模型在困难任务上没有思考的空间。 - **关联:** 削减 **Input / Output Tokens** 的 output 一半。 ### Batching——能成组的就成组 > 洗一整桶衣服，而不是一次洗一件衬衫——成组处理能摊薄固定开销，每次运行完成得更多。 当你有许多相似的请求，而且每个都不需要立刻得到答案时，把它们**批处理**——一起处理许多个——通常比一个一个发出去更便宜，服务商也常常为可以在方便时运行的 **batch job** 提供折扣。你用**延迟**（每一项都要等整批）换取更低的成本——这对后台或批量工作是合适的交易：处理积压的任务、丰富数据集。 _Diagram: 逐个处理：现在，按正常价格。批处理：稍后，但常常有折扣。_ #### Batching (批量作业) - **是什么:** 把许多不紧急的请求作为一个 batch job 发送。 - **例子:** 一夜之间把 100,000 张旧工单作为一批打上标签。 - **陷阱:** 答案不会马上到——不适用于有人正在等待的任何事情。 - **关联:** 有意识地选择 **Latency–Cost–Quality Triangle** 中的「成本」一角。 > **效率的问题:** 「我发送的上下文、要求的输出，是否超出了这个任务所需——把不紧急的工作批处理，能不能让它 更便宜？」 > 通过少发来控制单次调用的成本：裁剪上下文，要求简洁的结构化输出，把不紧急的工作批处理。更紧凑的 prompt 不仅更好，也更便宜。 ## 6. 延迟、成本、质量 成本从不单独存在——它要与速度和质量互相交换。把这三者看成一个按使用场景来平衡的三角，能避免你为了优化其中一个而毁掉另一个。 ### Latency–Cost–Quality Triangle——三者互相拉扯 > 老作坊门口那块牌子——「快、便宜、好：三选二」——因为在其中一项上使劲，通常要在另一项上付出代价。 成本、**延迟**（速度）和**质量**构成一个三角，它们互相交换。最大、最聪明的模型质量最好，但成本最高，往往也最慢；小模型便宜又快，但在困难任务上较弱；大量上下文能提升质量，但会同时抬高成本和延迟。你很少能让三者同时拉满。所以你不会孤立地优化成本——对每个使用场景，你要决定哪一角最重要，以及愿意拿什么去换。 _Diagram: 大模型拉向质量，小模型拉向成本和速度。三者同时拉满是罕见的。_ #### Latency–Cost–Quality Triangle (三选二) - **是什么:** 三种你无法同时推到极限的品质。 - **例子:** 换成小模型：更便宜更快，但在困难的情形上更弱。 - **陷阱:** 压低成本可能悄悄拉低质量——用 evals 检查。 - **关联:** 具体选哪一角是 **Use-case Balance**；提速的技巧是 **Streaming**。 ### Use-case Balance——按功能选择平衡点 > 比赛选跑车，搬家选货车——同一个问题，相反的答案，因为是任务决定了什么重要。 合适的平衡完全取决于功能本身。面向用户的聊天成败取决于**延迟**，需要又快又有能力的模型。夜间的批处理任务只关心**成本**，可以用最便宜、最慢的选项。高风险的法律或医疗答案把**质量**放在两者之上。三角上没有唯一正确的点——说清楚这个功能必须赢下哪一角、可以牺牲哪一角，是驱动其他所有选择的决定。 _Diagram: 三个功能，三个赢家：聊天赢在延迟，批处理任务赢在成本，高风险场景赢在质量。_ #### Use-case Balance (点名获胜的那一角) - **是什么:** 对每个功能，明确点出三角中最重要的那一角。 - **例子:** 搜索自动补全——延迟；夜间打标签——成本；医疗摘要——质量。 - **陷阱:** 所有事用同一套设置，会处处都损失一点。 - **关联:** 驱动 **Right-sizing**、**Batching** 和 **Streaming** 中的各项选择。 ### Streaming——廉价地获得「感知速度」 > 一间厨房做好一道就上一道，而不是让你等整桌饭菜——总时间一样，但等待的感觉短得多。 有一个技巧能绕开这个三角：把模型的输出在生成的同时一个 token 一个 token 地**流式传输**，让用户立刻看到文字出现，而不是盯着空白屏幕直到整个答案完成。总时间不变，但**感知延迟**大幅下降。这是一种不换更快的模型就让功能「感觉很快」的廉价办法——管理的是等待的体验，而不是等待本身。 _Diagram: 没有 streaming：空白屏幕直到结束。有 streaming：文字立刻开始出现，总时间不变。_ #### Streaming (逐 token 输出) - **是什么:** 答案边生成边显示，一个 token 一个 token 地。 - **例子:** 聊天助手在问题发出后片刻就开始打字。 - **陷阱:** 不会加快完整结果的到达：如果你需要整个答案（比如给代码用的 JSON），就没有收益。 - **关联:** 在不更换模型的情况下，帮助 **Latency–Cost–Quality Triangle** 中的「延迟」一角。 > **三角的问题:** 「对这个功能来说，哪一角最重要——成本、延迟还是质量——我选的模型和设计是不是为了赢下那一 角、并牺牲了该牺牲的另一角？」 > 成本、延迟和质量互相交换——你很少能三者都拉满。选好每个功能必须赢下哪一角，牺牲该牺牲的另一角，再用 streaming 几乎免费地买来感知速度。 ## 7. 用好它 AI 经济学归结为一种朴素的姿态：知道东西值多少钱，并有意识地只花能把事办成的最少的钱。杠杆不多，大部分节省来自拒绝默认地多付钱。 ### Cost per Task——按任务衡量，而不只是看总账单 > 一份逐项列出的账单，显示每道菜花了多少，而不是一个大数字——只有明细才能告诉你该在哪里砍。 你无法控制你没有衡量的成本。要记录每个功能、每种调用类型、每个任务实际花了多少 token——即 **cost per task**——而不只是一笔笼统的月度账单。成本是需要像性能一样去监测和关注的东西。大多数昂贵的 AI 功能都有一两个**成本热点**，明细能立刻揭示它们，而总数则把它们藏得严严实实。 _Diagram: 一个月度数字说明不了什么；按功能拆分的明细立刻显示出热点。_ #### Cost per Task (逐项成本) - **是什么:** 按功能、调用类型和任务记录 token 和金额。 - **例子:** 明细显示 agent 循环吃掉的比聊天、搜索和摘要加起来还多。 - **陷阱:** 没有明细，你优化的是看得见的东西，而不是贵的东西。 - **关联:** 告诉你该先拉 **Cost Formula** 的哪个乘数。 ### Clear the Bar——刚好过线的最便宜的方案 > 你买的是够用的工具，而不是货架上最贵的那个——超出你所需的能力，只是花掉的钱。 统领性的原则：使用仍然满足你的**质量门槛**的最便宜的模型、最小的上下文和最少的调用——不多也不少。这不是为了便宜而便宜；而是拒绝为任务用不上的能力买单。用 **evals** 设定门槛，然后找到能过线的最轻的配置。大多数节省并不是什么聪明的花招——而是不再出于习惯默认选择最强大、上下文最多、最话痨的那个方案。 _Diagram: evals 设定门槛。选能过线的最便宜的模型；高出的部分都是多付的钱。_ #### Clear the Bar (够好就行，不多不少) - **是什么:** 能通过你的 evals 的最小配置（模型、上下文、调用次数）。 - **例子:** 你把一个功能从大模型降到中等模型，跑 evals——质量不变，账单下降。 - **陷阱:** 没有 evals，这个「门槛」只是一种感觉，节省会悄悄侵蚀质量。 - **关联:** 本课所有杠杆的总和；检验 **Right-sizing** 和 **Model Routing**。 ### 一切如何关联 > 一块有三个旋钮的控制面板：每 token 的价格、每次调用的 token 数、调用次数。本课中的每项技巧都在拧其中一个。 本课中的每项技巧都作用于账单的三个乘数之一。**Right-sizing**、**Model Routing** 和 **Plan-and-Execute** 降低每 token 的价格。**Context Trimming**、**Concise Output** 和 **Prompt Caching** 降低每次调用的 token 数。**Response** 和 **Semantic Caching** 降低调用次数。**Batching** 用等待换来折扣，**Cost per Task** 告诉你该往哪看，而这个三角提醒你：每个杠杆都要拿延迟和质量去交换。 _Diagram: 上面的杠杆压低三个乘数，三者合起来就是总成本；按任务拆分的明细负责衡量它。_ #### 在大规模上线 AI 功能之前 - **你知道 cost per task 吗**——用 token 衡量，而不只是总账单？ - **模型与难度匹配吗**——例行的用小模型，只在需要时才用 frontier？ - **你在做 routing 吗**——简单的大多数交给便宜的模型，困难的情况再升级？ - **你在做缓存吗**——重复的答案、固定的 prompt 前缀、近似的重复？ - **你发送的是最小量吗**——裁剪过的上下文、简洁的结构化输出、不紧急的就批处理？ - **哪一角获胜**——成本、延迟还是质量——设计是否为此做了调整？ #### 你把成本管得好的标志 - 你**衡量 cost per task**，知道你的热点，而不只是月度总额。 - 你**让模型匹配难度**并做 **routing**，而不是凡事都用 frontier。 - 你**缓存**重复的工作和固定的 prompt 前缀。 - 你**发送最小量**的上下文，并要求**简洁**的输出。 - 你按功能**平衡三角**，并用 **streaming** 让一切感觉很快。 ## 速查表：全部 19 个概念 ### 计价表 - **Token** (计费单位): 一小段文本，大约一个词。你被计费的单位。 - **Input / Output Tokens** (进与出): 你发送的和模型写出的都要付费——每次调用都是如此。 - **Cost Formula** (是什么在推高账单): 每次调用的 token 数 × 调用次数（× 模型每 token 的价格）。 ### 模型选择 - **Frontier Model** (顶配型号): 最聪明也最贵。是例外，而不是默认。 - **Right-sizing** (模型适配任务): 例行任务用小模型，真正困难的用强的。 ### 分流 - **Model Routing** (升级): 默认用便宜的模型，只在需要时才用贵的。 - **Router** (调度员): 一个又便宜又快的评判者，决定每个请求用哪个模型。 - **Plan-and-Execute** (规划用贵的，执行用便宜的): 强模型只规划一次，便宜的模型执行各个步骤。 ### 缓存 - **Response Caching** (复用整个答案): 为完全相同的重复请求存下的答案——即时且免费。 - **Prompt Caching** (缓存前缀): 不变的 prompt 前缀被复用，便宜得多。 - **Semantic Caching** (按含义缓存): 含义相近的请求共享同一个存下的答案。 ### 少发 - **Context Trimming** (只发需要的): 只发需要的上下文：用摘要代替历史，用前几个片段代替全部。 - **Concise Structured Output** (紧凑的 schema): 只要你需要的字段——更少的 output token，更可靠。 - **Batching** (批量作业): 不紧急的工作作为一批：稍后完成，但常常有折扣。 ### 平衡 - **Latency–Cost–Quality Triangle** (三选二): 快、便宜、好——三选二。 - **Use-case Balance** (点名获胜的那一角): 每个功能都要明确点出它最重要的那一角。 - **Streaming** (逐 token 输出): 文字立刻开始出现：总时间一样，等待感觉更短。 ### 用好它 - **Cost per Task** (逐项成本): 按功能、按任务拆分的明细揭示成本热点。 - **Clear the Bar** (够好就行，不多不少): 能通过你的 evals 的最便宜的配置——不多不少。 > AI 经济学是有意识的节俭：按 token 计费，让模型匹配难度，做 routing，做缓存，发送最小量，并在成本与延迟、质量之间取得平衡——刚好过线的最便宜的方案获胜。 速成课结束 · 7 章 · 19 个概念 接下来是实践：拿一个 AI 功能，衡量一个任务实际花了多少 token——然后试试那些显而易见的招数。把它降到更小的模型，用 evals 检查质量是否保持；裁剪上下文；缓存重复的内容。你通常会发现账单大幅下降而没有真正的损失，因为你一直是出于习惯在默认选择最贵的方案。当一个更便宜的配置通过门槛、你意识到 frontier 模型其实从来都不是必需的那一刻，这套方法就通了。但请把一个想法放在所有想法之上：你按 token 为智能付费，所以只花能把事办成的最少的钱。