微调 一次 要 多少 钱

打算做微调的团队常卡在同一个问题：问供应商报价，对方要你先说清数据量和训练轮数，而这两项自己也还没定；于是报价迟迟拿不到，预算只能拍脑袋。这篇不给你一个固定数字，而是给一套估算顺序：先分清钱花在哪几块，再按哪几项参数去站内页面查当时的数字，最后列出能动手砍掉的几项。

打算做微调的团队常卡在同一个问题：问供应商报价，对方要你先说清数据量和训练轮数，而这两项自己也还没定；于是报价迟迟拿不到，预算只能拍脑袋。真实情况是，没人能一口报出「一次微调多少钱」，因为这笔钱取决于你选的路子，而不是某个固定价目。

这篇不给固定数字，给一套估算顺序：先分清钱花在哪几块，再按哪几项参数去站内页面查当时的数字，最后列出能动手砍掉的几项。按这个顺序走，你半小时内能拉出一张自己团队可用的预算表，而不是等对方报价。

一次微调的钱由哪几块拼成

先把账分成四块看：训练算力、数据准备与标注、训练完之后的托管推理、以及自己人投入的工时。前三块在站内能查到公开口径，第四块最容易被漏掉，但它往往决定这个项目到底值不值得做。

除了四块主账，还有三块附加账经常被忽略：反复试跑失败重来、试完不用的模型占着存储与端点、上线后每次调用还要付推理钱。前两项是沉默成本，第三项是长期支出。

按哪几个参数去查当时的数字

不要先看价再倒推参数，那样只会越看越乱。正确的顺序是：先把下面四个参数填成一张表，再拿这张表去站内逐个页面核对当天的数字。

• 训练侧四参数：底模规格、训练数据量、训练轮数、卡型与卡数，这四个决定训练时长，时长再乘当时的租金
• 推理侧两参数：部署后每日请求量、上下文长度，换算方式可对照站内的 token 单价换算工具
• 价格会动，所以不要照抄任何一篇文章里的金额，到站内官方 API 价格页、算力总览与 GPU 租用比价页看当天口径
• 查的时候顺手记下查询时间，同一份预算表隔两周就该重算一次

把参数和价格分开记录，好处是供应商报价回来时你能立刻判断贵在哪一项：是数据量开太大，还是卡型选高了，还是推理单价本身偏高。没有这张表，你只能被动接受报价。

能砍的几刀，按代价从低到高排

1. 先砍训练规模，不砍底模减小数据量、降低轮数，先做小样本试跑验证方向对不对，再决定要不要全量训。验证方式：看小样本跑出来的效果是否接近预期，不接近就先改数据而不是加卡。
2. 换托管方式训练时租按量的卡，训练完切到托管推理或走按量 API，比一直独占一张卡便宜。可对照站内微调与托管推理哪家划算那页的口径做比较。
3. 换更上游的做法能用提示工程、检索增强或少量示例解决的任务，先别上微调。确实需要稳定风格或固定格式输出时再上，判断标准是：改了三次提示词仍然不稳定。
4. 最后才动数据质量与评测这两项砍了，训出来的模型没法判断好坏，重训一次的成本比省下的多。所以它们排在最后，不是最先。

砍的顺序很重要。很多团队一上来就省评测环节，结果训了三版都不知道哪版能用，反而最贵。按上面的顺序走，每一刀都能说清省了多少、代价是什么。

这套估算什么时候不适用

上面这套算法默认你的任务是「通用数据、可租算力、上线调用量中等」。下面三种情况里，它算出来的数字参考价值有限，得换算法。

• 数据需要大量人工标注或涉及合规审核时，人力成本会盖过算力成本，这时算力报价再低也没意义，应先把标注和审核的工时估出来
• 需要私有化部署或独占算力时，成本从按次变成按月甚至按年，得按买卡还是租卡的几年账来算，不能只看单次训练费
• 底模不开源或供应商不提供微调接口时，这条路本身走不通，应改看站内微调服务商目录里能接的渠道

另外，如果这次微调的目标只是验证一个想法，那预算重点应该放在最小可行的试跑上，而不是按上线标准做全量估算。目标不同，账的口径也不同。