绝大多数中小企业需要的不是微调,是 RAG 加提示词
同一件事,三家云给出三个不同的倍数。把公开单价摊开算一遍,你会发现该省的钱不在你以为的地方。

文章目录
共 5 节0.6 变成 1.20,3.6 变成 7.20。
据火山引擎方舟计费页的公开数据,doubao-seed-2.0-lite 这个型号,基础模型在线推理的价格是输入 0.6 元、输出 3.6 元(每百万 token);同一个型号做完精调之后,输入 1.20 元、输出 7.20 元。两张表并排一放,是整整一倍。
十家里有八家看到这组数,会得出一个结论:微调太贵,别碰。
方向也许对,理由是错的。翻一倍听着吓人,但它是个比值,不是钱。真正决定这件事做不做的,是把比值乘上你自己的调用量之后那个绝对数——而多数人从来没乘过这一步。
这一篇只干一件事:按各家计费页上真实存在的公开单价,把微调这笔账一项一项摊开。
一、同一个问题,三家云给了三个不同的答案
火山引擎:贵一倍。 基础模型 doubao-seed-2.0-lite 输入 0.6 元、输出 3.6 元;精调模型同型号输入 1.20 元、输出 7.20 元(每百万 token)。1.20 ÷ 0.6 = 2,7.20 ÷ 3.6 = 2。这个倍数不是官方写在文档里的一句话,是我拿它计费页上两张不同的表对照出来的,且只在该页公开的 lite 型号那一档成立。
OpenAI:贵五成。 定价页上,gpt-4.1 基础模型每百万 token 输入 $2.00、输出 $8.00;微调版本 gpt-4.1-2025-04-14 输入 $3.00、输出 $12.00。3 ÷ 2 = 1.5,12 ÷ 8 = 1.5。同样是我自己做的除法。
阿里云百炼:不加价。 同一张计费页上,微调后按 token 调用的 qwen3-32b,输入 0.002 元/千 Token、输出 0.008 元/千 Token(非思考)或 0.02 元/千 Token(思考),与同页基础模型 qwen3-32b 的单价完全相同。
这里必须加一句限定,否则你会拿错结论去做决策:阿里云那个「不加价」,只成立在「SFT 高效训练 + 按 Token 计费」这一条路径上。同一家的另一条路径叫独占部署,价钱是完全不同的量级,第二节会专门算。
还有第四家,压根不按 token 卖。 腾讯云 TI-ONE 训练平台按 GPU 机器小时计费:A100×1 的 16c96g 规格每小时 31.50 元,不足 1 小时按秒计费;A100×8 每小时 261.26 元;同规格包年包月每月 125,418 元(页面更新日期 2026 年 6 月 3 日)。而腾讯云 TokenHub 的《计费方式》页,完整计费项清单里未列出任何模型精调项——只有推理的输入、输出、缓存输入,以及图像、视频、语音和订阅套餐。
我要在这里刹一脚:这只能说明那一张计费方式页上没有列这一项,不能推出「腾讯云不支持微调」。 在成本话题上把「我没查到」写成「它没有」,是自己给自己埋雷。
二、训练费便宜得可以忽略,真正的钱不在那里
把比值换成钱。
阿里云百炼计费页给了公式,原文是:「模型训练费用 =(训练数据 Token 总数 + 混合训练数据 Token 总数)× 循环次数 × 训练单价(最小计费单位:1 token)」。同页训练单价,Qwen3-8B 是 0.006 元/千 Token,Qwen3-32B 是 0.04 元/千 Token。
拿这条公式算一遍。假设你攒了 500 条问答样本,每条按 800 token 计(这个 800 是我为了演示设的假设值,不是任何官方数据),循环 3 轮:
500 × 800 = 400,000 token;400,000 × 3 = 1,200,000 token,即 1,200 千 token;1,200 × 0.006 = 7.2 元。
七块二。这就是在 Qwen3-8B 上做一次三轮训练的公开单价成本。
不是我算错了。百度智能云千帆的精调价格页(该页标注更新时间 2026 年 4 月 15 日)给的官方算例是同一个量级:「25.8千字符数 ×(0.5~0.8)× 2 × 0.03 = 0.774~1.2384 元(原价)」。不到一块二毛四。同页还给了并排价:ERNIE-4.0-Turbo-128K 全量更新 0.2 元/千 tokens、LoRA 0.05 元/千 tokens(均为折后价)。一除,LoRA 是全量的四分之一(除法是我做的;这是限时折扣的折后价,与原价不是一回事)。
火山引擎的文档给了 LoRA 的另一面:「LoRA…训练速度更快、机器资源消耗更低,成本远低于全量精调;且在大多数场景下,LoRA 精调效果可达到全量精调的 98% 以上。」——这句 98% 是火山引擎官方文档的口径,不是第三方独立验证的结论。 更硬的公开数据在 HuggingFace 的 PEFT 官方文档里,Quicktour 直接贴出了运行输出:「trainable params: 524,288 || all params: 1,236,338,688 || trainable%: 0.0424」,并解释「you're only training 0.04% of them!」;LoRA 概念页另写着「LoRA does not add any inference latency」。
每个月都得交的那一份,长这样。
先看按量的那条路。用火山公开的那组数,输出侧的差价是 7.20 − 3.60 = 3.60 元/百万 token。这是一条你自己就能填的算式:
每月多花的钱 =(精调后单价 − 基础单价)× 你每月消耗的百万 token 数
- →每月输出 1,000 万 token → 10 × 3.60 = 36 元
- →每月输出 1 亿 token → 100 × 3.60 = 360 元
- →每月输出 10 亿 token → 1,000 × 3.60 = 3,600 元
看清楚了:「贵一倍」在中小企业的真实调用量上,一个月是几十块到几百块。 这就是开头那个错误结论的来处——被比值吓住,从来没乘过这一步。
再看另一条路。阿里云同一张计费页上,独占部署(模型单元):千问2.5-开源版-7B 的 MU5×1 规格 21 元/小时、10,139 元/月;同型号 MU1×2 规格 108 元/小时、52,236 元/月;千问3.6-35B-A3B 的 MU1×8 规格 432 元/小时、208,944 元/月。
一万块、五万块、二十万块,每月。和上面那几十块几百块不在一个数量级。
同页 qwen3-32b 按量调用的输出价 0.008 元/千 Token,折合 8 元/百万 token。最低那档独占部署 10,139 元/月除以 8,约 12.7 亿输出 token——租一个月最便宜那档独占实例的钱,够你在按量通道上买十二亿多个输出 token。(除法是我做的;被除数是 7B 的部署月费、除数是 32B 的按量单价,只能当量级示意。)
三、提供方自己在收窄这条路,而且自己给了顺序
OpenAI 的弃用公告里给了一张时间表。自 2026 年 5 月 7 日起:「Creating fine-tuning jobs or training is not available to organizations that have not previously run fine-tuning.」;公告写明自 2026 年 7 月 2 日起:「Creating fine-tuning jobs is no longer available to organizations that have not run inference on a fine-tuned model in the past 60 days.」;公告并写明 2027 年 1 月 6 日:「Active existing customers will no longer be able to create new fine-tuning jobs on this date. Inference on fine-tuned models will be disabled only when the underlying base model is deprecated.」其定价页顶部同时挂着一句:「OpenAI is winding down the fine-tuning platform.」
后两个日期都晚于本文发布日期,是公告已写明的时间表,不是已发生的事。但方向已经写在公告上了。
另有一条只能陈述、不能引申的事实:Anthropic 官方开发者文档的索引文件中,检索不到任何 fine-tuning 条目——这说的是那份索引里没有这一类文档页,不是说这家公司不提供这项能力。
真正值钱的是各家官方文档给出的先后顺序,它们出奇地一致。
OpenAI 那份《Optimizing LLM Accuracy》里写得最直白:「Many 'how-to' guides on optimization paint it as a simple linear flow - you start with prompt engineering, then you move on to retrieval-augmented generation, then fine-tuning. However, this is often not the case - these are all levers that solve different things.」它把问题分成两类:Context optimization——「You need to optimize for context when 1) the model lacks contextual knowledge because it wasn't in its training set, 2) its knowledge is out of date, or 3) it requires knowledge of proprietary information.」;LLM optimization——「You need to optimize the LLM when 1) the model is producing inconsistent results with incorrect formatting, 2) the tone or style of speech is not correct, or 3) the reasoning is not being followed consistently.」
同一份文档里还有两句更狠的:「many of our largest customer deployments at OpenAI were done using only prompt engineering and RAG.」;「squeeze as much accuracy out of basic methods as you can before reaching for more complex RAG or fine-tuning - let your accuracy target be the objective, not jumping for RAG + FT because they are perceived as the most sophisticated.」
火山引擎的《模型精调概述》说的是同一件事,只是换成了中文和插件的说法:「时效性强的信息检索需求,建议选择联网内容插件」「确定域内的信息检索需求,建议选择知识库插件」;「如效果问题集中、判定规则清晰,建议先尝试通过PE优化提示词,成本更低、迭代更敏捷」;以及那句该抄在墙上的——「精调模型推理成本较基础模型更高,如对推理成本非常敏感,请评估后再进行精调或等待基础模型优化。」
百度千帆的《什么情况下适合精调》(该页标注更新时间 2025 年 10 月 29 日)把顺序写死成三级台阶:先「调整Prompt优化输出…调整Prompt是最简单的方式」;再「挂载知识库提升效果(使用RAG)。如果需要引入少量新的知识…您可以考虑挂载外部知识库。」;只有「若前两种方法的效果不符合预期」,才轮到精调。
把这三家的原话拧成一张四问表:
第 1 问:你要解决的,是模型「不知道」,还是模型「不像话」?
不知道——缺内部资料、缺时效性强的信息、缺专有知识——按 OpenAI 的分法这是 context 侧问题,微调解决不了。是 → 走检索,时效性强的走联网、域内固定的走知识库(火山口径)。
第 2 问:如果是「不像话」,具体不像在哪?
格式不稳、口吻风格不对、推理过程不一致——这才是 LLM 侧的问题。千帆的说法是「需要纠正大模型输出的格式、口吻或者风格」「需要大模型处理一些边界Case」。是 → 微调进入候选,但还不到动手的时候。
第 3 问:提示词榨干了吗?
判定标准不是「我改过几版」,是那句原文:把基础手段的准确率榨到不能再榨了没有。榨干的标志是你说得出「第几版改了什么、评测分从多少到多少」。
第 4 问:你的调用量够摊销吗?
火山文档的原话是:「精调训练、数据构造成本较高(建议最少 SFT数百样本、DPO百条样本、CPT一千万 tokens),更大的业务规模能有效摊销训练成本。」把第二节那条算式填上你的月调用量,看多出来那笔钱和要投的人力比值不值。
四问全过,才轮到「先做哪一步」:
- 1先写评测集。 三十到五十条真实业务问题配标准答案。没有它,后面每一步都是玄学。
- 2再榨提示词。 每改一版跑一次评测集,记分。这一步花人的时间,不花账单上的钱。
- 3再挂检索。 按千帆的界定,「引入少量新的知识」「严格参考少量文件」这类需求走这一步,同样跑评测集。
- 4还不够,才做小样本试训。 OpenAI 说「Start with 50+ examples, evaluate, and then dial your training set size up」;火山说「建议优先采用少量数据(50条~100条)对模型做 SFT 后观察真实评估是否有收益」,epoch「通常设置为 2 到 5 轮」。两家起步量级一致。
- 5有收益,再谈上量。 没收益,第 4 步那笔钱就是你为「不做这件事」买到的确定答案,按第二节的单价算,很便宜。
四、代价:RAG 不是免费的,提示词也不是
前面三节像是在给 RAG 加提示词这条路背书,所以这一节的冷水要泼在自己身上。
代价一,检索不是万能的,官方文档里就有它失手的实测。 还是 OpenAI 那份文档,记了一组冰岛语的实测分数:baseline GPT-4 的 BLEU 是 62,加 few-shot 到 70,用 1000 条样本微调 gpt-3.5 到 78,微调 gpt-4 到 87。然后是这一句——「RAG actually decreased accuracy, dropping four points from our GPT-4 fine-tuned model to 83.」加了检索反而掉了四分。这条直接反驳本文的主张,所以必须写进来:检索解决的是「模型不知道」;当问题根本不在「不知道」上——比如一门语言的语法直觉——检索非但帮不上忙,还会往上下文里塞干扰。
代价二,提示词工程要占一个人的时间,而且是持续占。 第三节那五步里,前三步花的不是账单上的钱,是人的钱。这笔钱不出现在任何一张计费页上,所以最容易被漏算,也最容易在半路因为「那个人太忙了」而停摆。
代价三,独占部署是另一个量级,别在没算过之前签。 第二节那三个数——10,139、52,236、208,944,每月——和按量通道上那几十块几百块的差价,隔着两三个数量级。前提不是「微调之后就得这么部署」,而是你的并发和延迟真到了那一步。
代价四,试错本身有账单。 「精调不支持免费额度抵扣」(火山)、「主动取消训练后,已消耗的 tokens 仍会推送计费」(阿里云)。你不能靠「先跑跑看,不行就掐掉」来免费探路。按第二节那七块二算,这个代价不大,但不是零。
什么时候不该照这套做
这套顺序有边界,说清楚它比推销它重要。
第一,如果你的问题从一开始就落在「格式、口吻、风格、边界 Case」上,别在检索上耗着。 千帆把这几类明确划给了精调,OpenAI 把它们归在 LLM optimization 一侧。这类问题上检索使不上劲。
第二,如果你要引入的不是「少量新知识」而是一整个领域的知识体系,千帆给的路更远:「需要引入大量的领域或者行业知识时,可以考虑通过Post-pretrain」。
第三,如果你的月调用量大到让第二节那条算式的结果变成六位数,本文关于「差价可以忽略」的说法对你全部失效。火山那句原话就是给你的:对推理成本非常敏感,就先评估,或等基础模型优化。
第四,本文里所有的倍数——2 倍、1.5 倍、1 倍——只在各家计费页公开的那几个型号和档位上成立,且都是我拿两张表对照算出来的,不是官方结论。照抄一个别人算出来的倍数去做采购决策,和不算是一回事。
先别买 GPU,先别签独占部署,先别攒数据集。先写三十条评测题。这是全篇唯一一个我建议你读完就去做的动作。
至于「知识库建起来之后怎么不让它慢慢开始骗人」,那是另一笔完全不同的账,本站另有一篇专门讲。
本文事实来源
可自行复核- 1
OpenAI 自助微调平台弃用公告(2026 年 5 月 7 日通知,含 2026 年 5 月 7 日、2026 年 7 月 2 日、2027 年 1 月 6 日三个节点原文)
- 2
OpenAI 定价页(微调训练与推理单价、基础模型单价、页首「winding down the fine-tuning platform」公告)——页面未标注发布日期
- 3
火山引擎方舟模型精调计费(精调训练 LoRA/全量单价、按算力单价、基础模型与精调模型在线推理单价、「精调不支持免费额度抵扣」)——本文只引用该页公开单价,未引用其页面更新日期
- 4
阿里云百炼模型训练与部署计费(训练计费公式、Qwen3-8B/Qwen3-32B 训练单价、独占部署月费、微调后按 Token 调用单价、取消训练仍计费的 FAQ)——页面更新日期由前端脚本注入,未能取得
- 5
百度智能云千帆精调价格(LoRA 与全量更新并排单价、训练总价公式、官方算例 0.774~1.2384 元原价),页面标注更新时间 2026 年 4 月 15 日
- 6
腾讯云 TI-ONE 训练平台计费(A100×1 每小时 31.50 元、A100×8 每小时 261.26 元、包月 125,418 元),页面标注最近更新 2026 年 6 月 3 日
- 7
腾讯云 TokenHub《计费方式》页的完整计费项清单中未列出任何模型精调项——本文只引用该页清单构成,未引用其页面更新日期
- 8
OpenAI《Optimizing LLM Accuracy》(三种手段解决不同问题、context / LLM optimization 的界定、「many of our largest customer deployments… only prompt engineering and RAG」、「Start with 50+ examples」、冰岛语 BLEU 62→70→78→87 与 RAG 掉四分至 83、「squeeze as much accuracy out of basic methods as you can」)——页面未标注发布日期
- 9
火山引擎《模型精调概述》(时效性检索用联网插件、域内检索用知识库插件、先用 PE 优化提示词、样本量建议、「精调模型推理成本较基础模型更高」)——本文未引用其页面更新日期
- 10
百度智能云千帆《什么情况下适合精调》(Prompt → RAG → 精调 的顺序与各自适用条件、Post-pretrain 的适用条件),页面标注更新时间 2025 年 10 月 29 日
- 11
火山引擎《有监督微调最佳实践》(建议先用 50~100 条数据试、epoch 通常 2 到 5 轮、「LoRA 精调效果可达到全量精调的 98% 以上」——该 98% 为火山引擎官方文档口径,非独立验证)
- 12
HuggingFace PEFT 官方 Quicktour(「trainable params: 524,288 || all params: 1,236,338,688 || trainable%: 0.0424」、「you're only training 0.04% of them」): ;PEFT LoRA 概念页(「LoRA does not add any inference latency」)
- 13
Anthropic 官方开发者文档索引中检索不到任何 fine-tuning 条目——本文只陈述该索引文件中不存在该类文档页,未就其能力做任何推断
