DeepSeek模型训练费用多少钱

很多团队看到「自训」两个字，第一反应是问一句「要多少钱」，然后被一个跨度极大的数字吓住或者忽悠住。真正卡住人的不是总额，而是不知道该拆成哪几块、每块按什么口径估、哪几块容易被漏掉。这篇不讲参数细节，只给一份可以照着填的估算框架，以及每类数字该去站内哪一页核对当期情况。

很多团队看到「自训」两个字，第一反应是问一句要多少钱，然后被一个跨度极大的数字吓住或者忽悠住。真正卡住人的不是总额，而是不知道该拆成哪几块、每块按什么口径估、哪几块容易被漏掉。这篇不讲参数细节，只给一份可以照着填的估算框架，以及每类数字该去站内哪一页核对当期情况。

先说明一件事：本文所有涉及钱和耗时的数字，都不写死，因为写死了也没意义——卡型、租期、数据量、并行策略一变，结论就翻篇。你要做的是带着自己的参数，到站内对应页面看当时的报价和指数，然后套下面的框架手算一遍。

先别问总额：训练开销为什么不能一口价

同一个结构规模的模型，在不同数据量、不同并行策略、不同卡型下，花费能差出好几倍，所以任何单一数字都不可信。如果有人张口就给你一个总额，先问他这数字包含了哪几块、假设的数据量和卡型是什么，通常一问就露馅。

还有一个更常见的坑：训练和微调经常被混为一谈。只做微调的团队，账本结构和从零预训练完全不是一回事，前者主要是数据和调参人力，后者才是算力大头。先分清自己在做哪种，再谈钱，否则估算表从第一行就是错的。

把账拆成四块：算力、数据、人力、试错

预算表最少要有四行，只写一行算力的表基本都会超支。四块之间不是简单的加法关系：算力跑得慢，人力周期就拉长；数据返工，算力和人力同时被拖；试错不够，前面三块全部作废重来。

• 算力块：训练时长乘卡数量再乘单位卡时价格，是最容易被单独拎出来讨论、也最容易被低估的一块；
• 数据块：采集、清洗、标注、去重、合规审核，很多团队只算了算力，到数据阶段才发现预算见底；
• 人力块：三拨人的工期折算，周期越长这块占比越高，而且不会因为项目暂停而暂停；
• 试错块：跑不通重来的那部分，通常按成功成本的固定比例预留，不留就等于没预算。

算力怎么估：时长、卡数、卡时单价三个变量

1. 先测单步耗时拿一小批数据在目标卡型上实跑，记录单步耗时和显存占用，不要用论文里的数字直接换算。
2. 推算总步数与并行效率估算需要的训练步数，再按并行策略乘一个效率折扣，多卡并行很难跑满线性加速。
3. 查当期卡时单价到 GPU 租用比价（/compute/gpu-rental） 和 租卡价格指数（/compute/price-index） 看当前水平，别用几个月前的记忆报价。
4. 自购卡换成折旧口径自购的话要用折旧加电费加运维来算，去 买卡还是租卡（/compute/tco） 和 电费这笔账（/compute/power） 对齐算法，否则两种方案没法放一张表里比。

显存不够导致跑不起来时，可能要换更贵的卡型或增加卡数，这一项要提前在 几张卡够用（/compute/sizing） 里试算一遍。很多超支不是因为单价涨了，而是因为原方案跑不动，中途被迫升级硬件配置。

数据和人力：最常被漏掉的两块

数据成本按单条样本的获取加清洗加审核单价，乘以有效样本量来估。关键是有效样本量远小于采集量，采集一批、清洗一轮、去重之后能用的比例往往低得让人意外，这个折扣系数一定要在表里显式写出来。

人力按人月折算，并且要把等人、等卡、等数据的空转时间算进去。这部分不会体现为任何产出，但会实打实体现在工资单上。一个常见的错误是只按「有效工作人月」报预算，实际项目周期往往是它的若干倍。

• 外包标注先问清结算口径：按条、按小时还是按项目，三种口径给出的总价差异很大；
• 小语种和敏感领域的合规审查是硬成本，不是可选项，要提前进预算表而不是事后补；
• 数据返工是最容易被低估的一项，标注规范改一次，之前标的部分可能全部作废；
• 人力预算里要给「对接和协调」留位置，跨团队项目的沟通成本往往被算进个人工时里被忽略。

能不能不从头训：微调、继续训练、蒸馏三条省钱路

先确认目标是「改行为」还是「补知识」。前者微调通常够用，后者往往更适合上检索方案，硬训进去既贵又难更新。这个判断做错，后面的钱基本都是白花。

微调只动一小部分参数，算力需求比预训练低一个量级，但数据质量要求更高，具体服务商口径可以看 微调服务商目录（/stacks/fine-tuning）。继续训练介于两者之间，适合已有大量领域语料的团队，但要为灾难性遗忘带来的额外调参试错成本留预算。

训练、部署、微调三者的差别容易混，不清楚的话先去 模型训练（/training） 页把概念对齐再谈钱，否则很容易把推理成本算进训练预算，或者反过来漏算。

给老板一个区间：估算表怎么填

把四块分别写成下限、上限、中位数三列，并标注每个数字的来源是实测、询价还是行业经验。来源标注看起来麻烦，但它是后来复盘时唯一能判断「当初错在哪」的依据。

对每个上限值注明「什么情况下会突破」，比如数据返工、卡型临时涨价、周期拉长。写清楚触发条件，比给一个更悲观的上限有用得多，因为老板关心的是什么时候需要再批预算。

1. 手算一遍再核对用 模型成本计算器（/tools/model-cost-calculator） 和 Token 单价换算（/tools/token-price-calculator） 把能算的部分核对一遍，减少低级错误。
2. 标注数据来源每一行后面写清是实测、询价还是经验值，经验值要额外加一行说明它的误差范围。
3. 写明暂停触发条件区间给出去之后，明确写出超过上限就暂停的触发条件和负责人，否则预算会被中途一点点磨掉。

什么情况下这笔钱不该花

调用量还没到能摊薄自训成本的规模时，直接调 API 通常更划算。判断方法很简单：把预估的调用量按当前单价在 Token 单价换算（/tools/token-price-calculator） 里折成一年支出，再和自训四块预算放一起看量级，差距明显的话就先别自训。

团队没有稳定的工程和数据人手时，自训的隐性成本会远超算力账单。这里说的隐性成本包括招聘周期、人员流失、知识断档，这些在预算表上通常看不到，但会在项目中途以进度延期的形式集中爆发。

需求还在快速变化、模型行为每周都要调的阶段，自训的迭代速度跟不上，容易做完就过时。所以要写清不适用条件：如果只是想把某个特定任务做稳，先试小规模微调，别一上来就按预训练做预算。

签字前过一遍的清单

预算表提交前，按下面几项逐条对照。这份清单不解决估算准不准的问题，但能挡住大多数「一眼就该发现」的漏洞，也能让评审的人更快抓到重点。

• 四块预算是否都有上下限，且写明数据来源是实测、询价还是经验；
• 算力单价是否来自站内当期页面，而不是记忆里的旧价格；
• 试错比例是否单独列出，而不是含糊地混在算力费用里；
• 有效样本量的折扣系数是否显式写出，而不是默认采集量等于可用量；
• 是否明确了超过上限就暂停的触发条件和对应负责人；
• 微调、继续训练、预训练三条路线是否都评估过，并写清为什么选当前这条。