Fine-Tune、检索还是 Prompt？决定因素是经济账

“我们应该 fine-tune 吗？”这个问题常被当成模型问题来问。它其实是预算问题，而且形状没有任何 benchmark 能回答：哪些钱只付一次，哪些钱按问题付，世界一变哪些钱还要再付。

这三条路线也不是做同一件事的三种方式，供应商自己说得比多数博客更直白。OpenAI 自己关于监督式 fine-tuning 最适合什么的表列了四种用途：分类、细腻翻译、生成特定格式的内容，以及纠正 instruction-following 失败。¹ 其中没有一项是“教模型它不知道的东西”。它对收益的总结是：“你可以使用更短的 prompts，带更少的示例和 context 数据，从而在规模化时节省 token 成本，并可能降低 latency”——这是卖这个功能的公司给出的账单论证。

所以：

• Fine-tuning 教的是形式和行为。 语气、格式、答案形状、你能示范但很难描述的边界。公开发表的最强版本是 LIMA 的表层对齐假说：知识来自 pretraining，对齐主要教模型该说哪一种格式子分布——这也是为什么那里一千个精选示例就够了。²
• 检索提供会变化的事实。 三者中只有它能让你修改文档后，不碰模型也让答案更新。
• Prompting 覆盖大多数真实场景，也是诚实的 baseline。自 Language Models are Few-Shot Learners 以来，in-context learning 就是默认做法：任务在 prompt 内被示范，不移动任何权重。³

两篇实测论文把中间那个错误彻底关上了门。Ovadia 及其同事比较了用无监督 fine-tuning 注入知识和用检索注入知识，结果检索稳定胜出，包括那些基础模型在 pretraining 中已经见过的事实。⁴ Gekhman 及其同事衡量了损害：引入新知识的示例拟合得很慢，而当模型终于拟合它们时，它在其他问题上的 hallucination 率会上升。⁵ 用 fine-tuning 教事实不仅会失败；还会劣化你没有训练过的问题的答案。

这一半已经定了。经济账那一半还没有，后文就是它。

一个案例，跑三种方式：基于你自己的文档做技术支持，而这些文档每周都在变。

语料是真实的，就在这块磁盘上：一个真实在用的软件仓库存放的 23 份 Markdown 内部文档——构建指南、品牌规则、翻译 brief、十份服务手册、性能和安全说明。使用 o200k_base 测量，也就是第 7 章的 encoding：

documents                              23
characters                        159,223
words                              22,194
tokens (o200k_base)                42,921
tokens with per-file headers       43,158

四万三千个 token 对这个决策来说很舒服：它能放进任何现代 context window，所以三条路线真的都可用。如果是千万级，决策已经替你做完了，那就是检索。

现在看“每周”这个词在做什么。文档流动通常只是被声称；这里直接从该仓库的版本历史中计数：

文档大约每隔一周就会动。用户可见字符串——这正是支持台实际会被问到的内容——自诞生以来每周都在动，大约每周二十个 commits。无论我们选择哪条路线，都必须能承受这种变化，而*“你训练所依赖的东西多久变一次？”*最后不是一个观点，而是你自己仓库里的一个数字。

针对这份语料写了二十个现实支持问题，每个主题一个，下面每个数字都基于这二十个问题计算。

最简单且可行的做法：把整个语料放进 system prompt，把问题放在末尾，然后让模型自己找。

system instructions                       140 tokens
the 23 documents                       43,158 tokens
the question (median of 20 measured)       13 tokens
the answer (the one assumption)           150 tokens

那里每个数字都是数出来的，除了最后一个：150 个输出 token 是一个假设，选在第 16 章计费过的 assistant 回合范围内。它是这里唯一没有实际执行出来的数字，对三条路线完全相同地应用，而 break-even 小节会精确展示你改动它时结论会移动多少。

按 2026 年 9 月 7 日从供应商页面读到的费率——每百万输入 token $1.50，每百万输出 token $9.00⁶——每个问题是 $0.066317。你在付费让模型重读四万三千个 token，只为回答十三个 token。

第 16 章的修复可以直接套用：语料稳定，且位于开头，所以是完美的 cache 前缀，读回来只需十分之一成本——每个问题 $0.007864，降幅 88%。第 16 章的警告也同样适用，而且以那章标出但没有计价的形式出现。这个供应商不收写入溢价；它收租金。显式 cache 每存储一个 token 每小时收费 $0.000001，⁶ 所以让 43,298 个 token 保持温热的成本是

不管有没有人提问。也就是六个月 $189.78，为一个空房间付费。把租金除以每个问题节省的钱，条件一行就出来：cache 这份语料要在每小时 0.74 个问题以上才回本——把每周 cache 重建也算进去，就是每月 546 个。低于这个量，你开启的省钱功能反而在亏钱。

同一路线，同一段代码，一个 flag，账单变五倍。第 16 章发现过一个由时间戳放错位置造成的版本；这里没有任何东西错，除了流量。Cache 是对流量的押注，而在这个供应商这里，你按小时下注。

第 19 章的检索器，不做修改：按章节边界切分并附加上下文标题，建索引，把四段最佳摘录放进 prompt。对二十个问题测得：

chunks produced from the corpus              330
mean tokens of a chunk's own text          124.9
mean tokens of the four retrieved extracts   884
prompt per question (140 + 884 + 13)       1,037
one-off embedding of every chunk        46,823 tokens

prompt tokens 比路线一少四十二倍，每个问题 $0.002906。按每百万 embedding tokens $0.15⁶，构建索引成本 $0.0070——还不到三个问题的成本——每次文档变化从头重建也同样是 $0.0070。六个月里每周重建整个索引，成本是十八美分。

有一点值得停下来。检索会摧毁 prompt caching。 现在稳定前缀是 140-token 的 system instruction；从第 141 个 token 开始，每次调用的 prompt 都不同，因为摘录是按问题选择的。而 140 个 token 低于第 16 章引用过的所有 cache 最低门槛。所以路线二完全无法 cached，听起来很糟，其实不是：不 cache 1,037 个 token，比 cache 43,298 个便宜。

这是一个值得带走的通用规则：两个大型 token 节省技术不能作用在同一份内容上，胜出者是移除更多 token 的那个。检索移除了 97.6%。

用内部风格的两百个示例训练，然后提问时完全不附带文档。

training examples                            200
training tokens                           24,389
epochs                                         3
prompt per question (15 + 13)                 28

训练成本是 24,389 × 3 × 每百万 $10.00 = $0.7317。这是全部构建成本，还不到一杯咖啡，也正因为如此，很多团队会在检查它是否有用之前就先付掉它。

现在是陷阱，也是本章存在的原因。fine-tuned model 的运行成本并不等于它的 base model。价格页用一句话说明：“从 Gemini 3 开始，tuned model endpoint prediction price 将是 base model 的 1.5 倍。”⁶ 不是训练。是 inference，是模型存在期间每一个 token 的 inference。

所以把它写成公式。令 $p_i$ 和 $p_o$ 为基础输入和输出价格，$m$ 为 tuned 乘数，$L_R$ 为你要替换的路线的 prompt 长度，$L_F$ 为 fine-tuning 后的 prompt 长度，$O$ 为答案长度。只有在以下条件成立时，fine-tuning 每个问题才更便宜：

第一项很明显：你的新短 prompt，被加价了。第二项不明显，而钱正是流向那里——答案上的附加费，它和你的 prompt 无关，训练也无法缩短它。用实测数字——$m = 1.5$、$L_F = 28$、$O = 150$、$p_o/p_i = 6$——阈值是

answer   50 tokens -> the prompt it replaces must exceed   192 tokens
answer  150 tokens -> the prompt it replaces must exceed   492 tokens
answer  400 tokens -> the prompt it replaces must exceed 1,242 tokens
answer 1000 tokens -> the prompt it replaces must exceed 3,042 tokens

在实测答案长度下，492 个 token——其中 450 个来自答案附加费，而不是 prompt。 如果替换的 prompt 比这更短，那么每个问题永远更贵，任何量级都一样；而这个阈值会随着 assistant 说的话变多而线性增长，所以一个写长答案的 assistant，无论删除多少 prompt，都不可能通过 fine-tune 变成更便宜的 token。

从另一个方向看，同一个事实可以记成一句话。在 fine-tuned 路线每个问题的 $0.002088 中，97.0% 是答案。Fine-tuning 优化的是剩下的 3%。

四个数字就能描述任意这些路线：一次性支付多少、文档变化时支付多少、不管有没有问题每小时支付多少，以及每个问题支付多少。这是在不修改第 16 章 computeCost 的前提下扩展它。

import { computeCost, type Pricing, type Usage } from "./cost";   // Chapter 16

export interface Route {
  name: string;
  setupUSD: number;            // paid once, before the first question
  perRefreshUSD: number;       // paid every time the documentation changes
  standingUSDPerHour: number;  // paid per hour whatever the traffic
  pricing: Pricing;
  usage: Usage;                // one question and its answer
}

export const perQueryUSD = (r: Route) => computeCost(r.pricing, r.usage);

const HOURS_PER_MONTH = (24 * 365.25) / 12;

export function totalUSD(
  r: Route, months: number, queriesPerMonth: number, refreshesPerMonth: number,
) {
  return r.setupUSD
       + months * refreshesPerMonth * r.perRefreshUSD
       + months * HOURS_PER_MONTH * r.standingUSDPerHour
       + months * queriesPerMonth * perQueryUSD(r);
}

/** Monthly volume at which `b` overtakes `a`. null = it never does. */
export function crossover(
  a: Route, b: Route, months: number, refreshesPerMonth: number,
): number | null {
  const fixed = (r: Route) =>
      r.setupUSD
    + months * refreshesPerMonth * r.perRefreshUSD
    + months * HOURS_PER_MONTH * r.standingUSDPerHour;
  const dFixed = fixed(b) - fixed(a);                     // b's extra fixed cost
  const dVar = perQueryUSD(a) - perQueryUSD(b);           // b's per-question saving
  if (dVar <= 0) return null;                             // b is never cheaper
  return Math.max(0, dFixed / dVar / months);
}

tuned model 不是另一张价格表，而是同一张价格表乘上一个系数：

const TUNED_MULTIPLIER = 1.5;   // read from the provider's pricing page, 2026-09-07

const scale = (p: Pricing, k: number): Pricing => ({
  input: p.input.map(t => ({ ...t, price: t.price * k })),
  cachedInput: p.cachedInput!.map(t => ({ ...t, price: t.price * k })),
  output: p.output.map(t => ({ ...t, price: t.price * k })),   
});

那一行高亮代码就是上一节的整个论点：乘数也落在 output 上。

六个月，文档每周刷新：

还有交叉点，也就是预算真正需要的四个数字：

retrieval -> fine-tune, documentation never changes:     148 questions / month
retrieval -> fine-tune, documentation refreshed weekly: 3,989 questions / month
prompt (no cache) -> retrieval:                            1 question / month
prompt (no cache) -> prompt (cached):                    546 questions / month

请把前两个一起读，因为它们就是本章的重点。静止语料让 fine-tuning 在一百五十个问题后回本；每周变化的语料会把同一个交叉点推远 27 倍，模型本身没有任何变化——只有你多久需要再次付费这一点变了。构建成本只是脚注；维护成本才是决策。

如果你现在得出结论：一个繁忙的支持台应该 fine-tune，那么算术同意你。它仍然是错的，下一节解释为什么。

成本表有一列算不出来，所以本节实际运行 fine-tune：本地，在一个小型开放模型上，用手写的适配器，而不是从库里拉一个。第 11 章构建了 LoRA；这里就是它，在 Qwen2.5-0.5B-Instruct 全部 24 层的 q_proj 和 v_proj 上，rank 8：

class LoRALinear(nn.Module):
    def __init__(self, base: nn.Linear, r=8, alpha=16):
        super().__init__(); self.base = base
        for p in self.base.parameters():
            p.requires_grad = False              # the model is frozen  
        self.A = nn.Parameter(torch.zeros(r, base.in_features))
        nn.init.normal_(self.A, std=1 / r)
        self.B = nn.Parameter(torch.zeros(base.out_features, r))
        self.s = alpha / r
        self.on = True                           # so the same run can compare both

    def forward(self, x):
        y = self.base(x)
        return y + (x @ self.A.T @ self.B.T) * self.s if self.on else y

两百个训练示例从语料中机械生成，因此可复现：问题是把章节标题改写成问题，答案则是该章节自身文本，采用严格的内部风格——一行以 Short answer: 开头，一行以 Source: 开头并带文件路径。格式是被教的形式；路径是事实。 然后在二十个留出问题上看两个数字：答案是否符合内部风格，以及它是否说出了真正能回答问题的文件。

两个 baseline 让表格可读，而且两者都来自第 4 章的坚持，不是事后补充。二十个正确答案里有十个是同一个文件，所以一个忽略问题、永远回答 CLAUDE.md 的模型得分是 10/20。检索器也有自己的上限：在这二十个问题中，它的四段摘录有 14 次包含正确文件，7 次把它排第一，所以 14/20 是任何使用它的 reader 能达到的最高分。

LoRA modules 48   trainable parameters 540,672 (0.109 % of the model)
400 steps, 2 epochs, 0.76 s/step on 16 CPU threads, 304 s in total
mean loss over the first 50 steps 3.7363 -> over the last 50 steps 2.4197

                                        house style   correct source
always answer the most common file             --          10 / 20
the retriever's own ceiling                    --          14 / 20
base model, closed book                    0 / 20           0 / 20
fine-tuned, closed book                   19 / 20           8 / 20
base model, four retrieved extracts       13 / 20           2 / 20
fine-tuned, four retrieved extracts        1 / 20           1 / 20

形式被学会了，而且完全、快速。 从 0 到 19/20，只用了一个 540,672 参数的适配器——模型的 0.109%——在一台看不到显卡的处理器上训练五分钟。

事实没有被学会。 8/20 和完全忽略问题能得到的 10/20 没有可区分差异，第 4 章关于 20 个样本的区间已经把这点说得很清楚。那些文件路径在训练数据中出现了三轮；最后学出来的是以一个看起来合理的 Source: 行结尾的习惯。问它本章开头的问题时，fine-tuned model 回答 Short answer: 10.x . . .，并引用 CLAUDE.md。正确答案在 CLAUDE.md 中，是 18.17.0。

然后形式崩了，这一行正是实验的意义所在。 给 fine-tuned model 一千个 token 的检索摘录——一种它从没见过的 prompt 形状，因为每个训练 prompt 都是二十八个 token——内部风格从 19/20 崩到 1/20。在本章开头的问题上，它回答 18.17.0——正确，但完全没有它被训练出的格式。所以 fine-tuning 没有教会一种格式；它教会的是以训练集里的 prompts 为条件的格式，第一个看起来不同的 prompt 就把格式一起带走了。你用什么 fine-tune，什么就会成为模型唯一擅长的输入分布，而这件事没人会放进电子表格。

关于指标再补一条，直接指向第 29 章：“正确来源”把形式和事实一起打分，所以两个检索行看起来都很糟，尽管两个模型都答对了那个问题的事实。一个端到端数字掩盖了三件事——14/20 recall 的检索器、0.5B reader 和引用格式——而要选择修哪一个，就要在测量之前把它们拆开，不是在之后。

现在看供应商替你填好的那一列。fine-tuned model 不是你拥有的资产；它是租在别人 base model 上的东西，并且上面印着结束日期。2026 年 9 月 7 日，OpenAI 价格页的 fine-tuning 部分完整写着这条通知：

OpenAI 正在逐步关闭 fine-tuning 平台。该平台不再向新用户开放，但 fine-tuning 平台的现有用户在未来几个月仍可创建训练任务。所有 fine-tuned models 在其 base models 被弃用之前仍可用于 inference。⁷

时间线精确到日：2026 年 5 月 7 日，对从未 fine-tune 过的组织关闭；2026 年 7 月 2 日，对六十天内没有在 fine-tuned model 上运行 inference 的组织关闭；2027 年 1 月 6 日，不再允许任何新任务。⁸ 同一页面安排了 fine-tuned models 本身的下线——ft-gpt-3.5-turbo、ft-gpt-4、ft-gpt-4.1-nano、ft-babbage-002、ft-davinci-002——日期为 2026 年 10 月 23 日，每个都带一个推荐替代 base model，这是一种礼貌说法：重新训练吧。

另一家 frontier 供应商从未把这份租约卖给你。Anthropic 的文档索引列出 699 页，没有一页关于 fine-tuning；Bedrock 价格页的模型定制部分覆盖 Amazon Nova、Amazon Titan、Cohere、Meta 和 OpenAI open-weight models，没有 Claude。⁹¹⁰ 如果你的架构依赖 fine-tune，三大 frontier 家族之一在任何预算下都不可用。

Self-hosting 把模型租约换成机器租约，而 AWS 在自己的页面上已经把这笔账算出来：一个 customised model 的 provisioned throughput，一个 model unit，一个月承诺，是“1 model unit × $21.18 × 24 hours × 31 days = $15,757.92”每月。¹⁰ 直接租金属更便宜，但不是免费——H100 按需 $3.99/GPU-hour，preemptible $1.99¹¹——一张必须始终在线的卡大约每月 $2,900，不管有没有人提问。每月一万个问题时，整条检索路线六个月是 $174.52。

这正是 LoRA 作为预算论证而不是技术论证发挥作用的地方。在同一个模型上测得，attention 和前馈层上的 rank-16 适配器是 8,798,208 个参数——模型的 1.781%，bfloat16 下 17.6 MB——相比 base weights 的 0.988 GB；它的 optimiser 和 gradient state 是 140.77 MB，而 full fine-tuning 需要 7.90 GB，相差 56 倍。结果不是训练更便宜，而是一个已加载的 base model 可以服务多个适配器，这是 GPU 固定成本唯一能被摊开的方式。托管训练也反映了这一点：16B 以下 low-rank 每百万 token $0.48，full $0.54，每个任务最低 $4.00。¹¹ 这个底价才是细节。对于 24,389 个 token、三轮 epoch，这份语料每次重新训练会按 $4.00 计费，而不是算出来的 $0.04——26 次每周运行的最低费用是 $104，而算术只有 91 美分。

还有两列只会出现在账单上。

数据驻留大约多花 10%，两个供应商给出的数字一致。 OpenAI 对 2026 年 3 月 5 日或之后发布的模型的数据驻留端点收取“10% uplift”；⁷ Vertex 非全球端点价格是 $1.65，而不是 $1.50，也是同样的 10%。⁶ 把它和 tuned endpoint 的 50% 加价相比，民间说法就反过来了：residency 很便宜，fine-tuning 不便宜——而且 fine-tuning 也不是更私有的选项，因为语料无论如何都会到供应商那里，只是从每次调用一次，变成训练时一次。

同一页面上有你数据最明确的标价：它把一个 fine-tuned model 列了两次；启用数据共享时，inference 价格正好减半——输入 $2.00 对 $4.00，输出 $8.00 对 $16.00。⁷ 允许供应商保留你发送的内容值 50% 折扣，这说明它对他们有多值钱。

Distillation——用大模型的答案训练你自己的小模型——通常被当作二者的出路。计价后它并不是，因为 teacher 正是你试图替换的系统：通过向检索路线问两百个问题来生产两百个训练示例，成本是 200 × $0.002906 = $0.58，再加上训练它们的 $0.73。Distillation 是你在检索 pipeline 工作之后做的事，用来让它更便宜；它也继承检索器搞错的每个事实。

钱只是可见的一半。另一半以等待到来，原因和账单相同：模型必须先读完整个 prompt，才会说第一个字。第 13 章在你能摸到的模型上测过 prefill 对 decode；这里是同样的测量，一次运行、一台机器、对 prompt 长度：

绝对数字属于一个跑在十六个 CPU 线程上的 0.5B 模型，不能说明托管 frontier model 的情况。形状完全可迁移：prefill 随 prompt 长度增长，而每 token 成本会随着第 9 章的二次项开始显现而爬升——一千个 token 时 4.79 ms，八千个 token 时 6.04 ms，仅仅因为更长就有 26% 的惩罚。

对三条路线的后果很直接。路线一每个问题 prefill 四万三千个 token，cache hit 让它变得可忍受——第 16 章解释了原因：cache read 替代 prefill 工作，所以它一次交易同时买到 latency 和金钱。路线二 prefill 一千个，并且先向索引多一次往返。路线三 prefill 二十八个，不添加任何东西，所以它在回答速度上可测地最快。它只是回答了错误的东西。

三个看起来像模型问题、其实不是的问题——这里花十分钟，之后省一个月：

凌驾于这一切之上的要求是：没有评估集，就无法做这个决策，而且销售 fine-tune 的供应商自己也这么说。 OpenAI 指南开篇写道：“只有在设置 evals 后才投入 fine-tuning。你需要一种可靠方式来判断你的 fine-tuned model 是否比 base model 表现更好”，并补充说，如果五十个好示例什么都没改变，问题在任务或 prompt，而不是数据量。¹ 二十个问题，也就是本章使用的规模，可以展示机制，但不能选择供应商——第 4 章衡量了原因；当你只有二十个案例时该怎么做——重复它们、配对它们，并测量运行之间的离散度——则是第 29 章。

四列，只有最后一列决定：

由此得出的规则很短，值得记住：从 prompt 开始；当事实会变时加检索；只有当你已经测量出仍然缺少的是形状而不是事实时，才 fine-tune——而且在做之前，要先给答案计价，不是给 prompt 计价。

给已经带着结论而来的人一个不舒服的版本：在本章测量的案例中，fine-tuning 在每月超过四千个问题后确实是最便宜路线；但在事实上，它仍然打不过对所有问题都回答 CLAUDE.md。

这里的每个价格都是按 token，且每条路线都是安排 token 的不同方式。接下来这将不再成立。

第 21 章离开文本。进入模型的图像不是字符串，而是一格格 patch，带着你没有选择的 token 数；一分钟语音在一个供应商处按秒计费，在另一个供应商处按 audio token 计费；合成语音按字符出售，转录按分钟，原始计算按 GPU-second。本章用一个成本函数回答的问题——哪个更便宜？——在单位匹配之前甚至无法提出，而互联网上没有计算器会替你标准化它们。

那里也会再次出现训练：带 trigger word 的图像适配器，以及从样本克隆出的声音。这引出了下一章开头的问题，而且它不是反问：如果 fine-tuning 语言模型几乎总是错误购买，为什么 fine-tuning 图像模型几乎总是正确购买？

本章中的每个价格、阈值和乘数都来自供应商自己的页面，读取日期为 2026 年 9 月 7 日，并带上该日期引用，因为它们都会变。实测数字——token 计数、chunk 大小、检索大小、训练 loss、分数、latencies 和版本历史计数——都在同一天的一台机器上生成，并可从上述语料复现。

本地实验使用 Qwen/Qwen2.5-0.5B-Instruct 和 greedy decoding，因此可精确复现；适配器是上文打印出的十二行 class，在 q_proj 和 v_proj 上 rank 8。语料是一个真实在用的软件仓库中被跟踪的 Markdown 文档，不包括两个只追加日志，其变化率从该仓库的版本历史中统计。