很多人说「想自建一个自己的大模型」，其实心里想的是让模型懂自己的业务、数据不外流，而不是真要从零训练一个底座。这两件事的成本差着好几个量级。这篇把训练、微调、部署三条路各自在干什么、要花什么、什么情况下不适用讲清楚，再给一套从需求倒推路线的判断顺序，以及每一步该去站内哪一页核对数字。
很多人张口就说「想自建一个自己的大模型」，但心里真正想要的，其实是另外几件事：让模型懂自家业务的黑话、让数据别流到外面去、把长期调用成本压下来，或者只是一个能对内对外讲的「自研」名头。这几种诉求对应的技术动作完全不是一回事，成本也差着好几个量级。从零训练一个底座和把现成模型跑起来，花的钱、要的人、需要的周期，都不在一个层面上。
这篇不讲抽象概念，就把训练、微调、部署三条路各自在动什么、要花什么、什么情况下不适用摊开来讲，最后给一套从需求倒推路线的判断顺序。每一步该核对哪些数字，都指到站内页面，你自己去看当时的口径。看完至少能回答一个问题：我这需求，到底要不要自己训。
「自建大模型」这句话，十个人有八种意思
先把诉求拆开，常见的就四种：数据不想出内网、模型要懂行业话术、想把调用成本降下来、想要一个「自研」的名头。这四种对应的动作分别是私有化部署、微调或检索增强、换更小的模型或改推理方式、以及基本不需要动模型。不先拆清楚，后面所有讨论都在鸡同鸭讲。
- 数据不外流
- 这是部署形态问题，把权重放进自己的环境跑就行，跟训不训练没关系
- 模型懂行业话术
- 多数情况是检索增强或微调能解决，不是非训练不可
- 省钱
- 先算清月用量，很多时候调 API 比自建便宜，量到位才谈得上自建更划算
- 想要「自研」名头
- 如果只是这个，先把成本表摊开再决定，名头不值一个集群的钱
有个简单的自查方法：如果你的问题换成「换个更细的提示词」或者「多喂一份资料参考」就能有明显改善，那你根本不需要训练。什么情况下例外呢？当模型要处理的是一种底座模型完全没见过的输入形态，比如某种专有信号、特殊的结构化数据流，或者对延迟和体量有硬约束、必须塞进很窄的环境里，这时候才可能真的绕不开动模型。
训练、微调、部署：三件事各自动了什么
这三件事经常被混着说，其实动的东西完全不同。训练是从接近随机的权重开始，让模型学语言和知识，动的是底座本身，周期以周计，通常要成规模的加速卡集群。微调是在已有权重上再喂一批带标注的样本，改变的是模型的表达习惯和输出风格，注意它不等于把新知识灌进去。部署只是把现成的权重跑起来对外提供接口，权重一个字节都没变，做的是显存、并发和吞吐的活。
| 做的事 | 动的是什么 | 典型周期 | 主要成本项 |
|---|---|---|---|
| 从零训练 | 底座权重 | 周级别 | 语料、算力、算法人力 |
| 微调 | 输出风格与格式 | 天级别 | 标注人力、少量算力 |
| 私有部署 | 不动权重 | 小时到天 | 显存与卡时、运维 |
| 检索增强 | 不动权重 | 小时级 | 资料整理、向量库维护 |
这张表只是个粗框架，具体每项要花多少，跟语料规模、量化档位、并发目标都有关系。要对照各家实际口径，微调去 /compute/finetune 和 /stacks/fine-tuning，训练去 /compute/training-cost 和 /compute/price-index，部署相关的显存和卡时去 /compute 或工具页核当时的数字。
什么情况下才真的需要自己训练
从零训练说得通，通常要三条同时满足：有独占且量足够大的语料、有稳定可靠的算力来源、有能验收效果的人。只满足第一条的情况最常见，也最容易被误判成「该训练了」，实际上微调或检索增强就够用，甚至提示词写清楚就行。
- 有独占语料但没算法工程能力：先试微调和检索增强，别直接上训练
- 有算力但语料质量差、没清洗：清洗本身可能比训练更花时间，先做数据
- 业务需求还在快速变形：底座训练周期长，等训完需求早变了，不如先调 API 顶着
- 三条都满足、且现成路线跑到头：这时候才轮到继续预训练或从零训练
替代顺序建议按成本从低到高走：提示词 → 检索增强 → 微调 → 继续预训练 → 从零训练。从便宜的那一端开始试，每往上一级都要有明确的、上一级解决不了的理由，不然就是烧钱。这个顺序不适用于一种情况：数据合规上明确禁止走外部接口，那起点就直接是私有化部署，而不是提示词。
日常业务需求，通常落在哪条路上
把日常需求对号入座，大部分会落在检索增强和微调这两条路上，跟从零训练没太大关系。分需求看：想让模型答得准，优先检索增强，把资料喂进上下文，资料更新了不用重训，纠错成本最低；想让模型答得像，微调更适合固定话术、固定格式、固定风格的场景，比如客服口径、报告模板。
| 你的诉求 | 优先试的路线 | 为什么 | 什么情况下不适用 |
|---|---|---|---|
| 答得准 | 检索增强 | 改资料即可，不用动权重 | 资料本身没法整理成可检索的形态 |
| 答得像 | 微调 | 能固定格式和风格 | 业务口径天天变，微调跟不上 |
| 数据不出门 | 私有化部署 | 权重放自己环境跑 | 算力或运维能力跟不上 |
| 成本降下来 | 小模型加检索 | 量到位时更划算 | 并发高到小模型顶不住 |
分别对号之后，剩下的才是微调甚至训练。另外提醒一句：「让数据不出门」本质是部署形态问题，走私有化部署或本地推理就行，跟训不训练是两码事，别把这两件事绑在一起算预算。成本这块要跟当前调用路线对比，去 /tools/model-cost-calculator 折算一下月成本再判断。
三条路各自的钱花在哪
钱花的地方不一样，容易失控的点也不一样。部署主要是显存和卡时，按并发数和上下文长度吃卡，量化档位不同成本差得明显。微调里样本准备的人力往往比算力贵，算力本身按轮次和样本量走。训练则是数据、算力、人力三块都要，算力是大头，但通常不是最容易失控的那一块，数据清洗和反复返工更耗人。
- 部署：卡时按并发和上下文算，量化档位是关键变量，先量并发峰值再估
- 微调：标注人力常被低估，先算样本量乘以标注单价，再加算力
- 训练：语料、算力、算法人力三块，具体数字去 /compute/training-cost 和 /compute/price-index 核当期水平
- 共同隐藏项：评测与返工，任何一条路都要留反复试错的时间预算
还有个常见误判：拿别人的训练成本当自己的预算。语料规模、并行效率、团队熟练度都会让实际数字差很多，别人的数只能当量级参考。要比价就去 /price-watch 看中转站和官方口径的变动，去 /price-index 看整体水平，别用记忆里的数字做决策。
一套按需求倒推路线的判断顺序
上面讲的是分块判断，真正做决定时按下面的顺序走一遍，能少走弯路。核心思路是从验收标准出发，而不是从技术名词出发。
- 写清验收标准什么样的输出算合格、谁来判断、多久判断一次，先把这条写下来，后面所有方案都拿它比
- 查数据约束有没有现成语料、能不能拿出内网，不能出去就直接排除云端路线，选项立刻少一半
- 算月用量每天调用多少次、每次多少上下文，用 /tools/model-cost-calculator 折算成月成本
- 对比替代方案同样这笔钱拿去调 API 或用托管微调，能不能达到验收标准，能就不要自建
- 留退路任何一条自建路线都要有回退到调用 API 的方案，避免卡死在自建上
这套顺序不适用于一种情况：业务对延迟有硬性要求，必须本地跑。这时候起点就是部署方案选型，而不是成本对比。延迟要求具体多少，用 /tools/speed-test 量当前路线的表现，再跟你的目标比。
几个容易踩的判断错误
判断错误比技术难度更容易让人走弯路，下面几个是反复出现的。
- 把「模型不知道我们公司的事」当成需要训练，实际是检索没做或语料没整理
- 把微调当成知识注入，结果模型学会了编，通顺但事实错得更多
- 只算卡钱不算人钱，调参、清洗、评测、上线运维通常比租卡贵
- 拿别人的训练成本当自己的预算，语料规模和团队熟练度都会让实际数字差很多
这些错误有个共同的根源：把「效果不好」直接归因到模型本身，跳过了提示词、检索、数据质量这几层。真要做决策，先按上一节那套顺序排一遍，每一步都有判断依据，而不是凭感觉。
决定之前先做的几件小事
别一上来就定方向，先花几天做几件小事，结论会清楚很多。这些动作成本低，但能把选项砍掉一大半。
- 拿 20 到 50 条真实业务样本，先用提示词和检索跑一遍，记录合格率，作为后续所有方案的基线
- 用 /tools/speed-test 量当前调用路线的延迟，自建要跟这个数比，不然体验反而变差
- 列出数据出境的硬约束，明确哪些数据绝对不能离开内网，这直接砍掉一半选项
- 把月用量记满一个月，用真实账单而不是估算来做决策，方法见 /usage 与 /token-price-to-cost
这几件事做完，你手里就有了基线合格率、延迟目标和数据约束三个硬指标，再回头看训练、微调、部署三条路，哪条走得通一目了然。至于各家具体怎么报价、可靠性如何，那是选型阶段的事，去 /sites 和 /rankings 看当时的对比结果。
下一步先拿真实样本跑一遍基线，再去算月用量，两件事做完方向基本就定了。价格和可靠性别靠记忆，去页面看当期数字。→常见问题
我只是想让模型按我们公司的说法回答，需要训练吗？
大概率不需要。这种需求通常是固定话术和固定格式，先用提示词把格式和口径写死，不够再上少量样本做微调。真正需要训练的信号很少：你的语料规模很大、领域极窄、而且现有底座在评测里怎么调都过不了线。
微调和训练最本质的区别是什么？
训练是从头或大规模继续学，模型的知识和语言能力都在变，代价高、周期长。微调是在已经会说话的模型上改说话习惯，样本量小得多，主要影响风格、格式和特定任务表现，对「它知不知道某件事」帮助有限，灌知识更适合走检索。
自建部署是不是就等于省钱？
要看用量。调用量很小的时候，自建的固定成本摊不下来，反而更贵；用量大到一定程度、且请求形态稳定，自建才可能划算。判断方法很朴素：把过去一个月的真实用量换算成卡时，再和租卡或托管推理的报价比一遍。
没有算法团队，能自己走通微调吗？
能走通，但别指望一次到位。更现实的做法是用托管式微调服务，自己只负责整理样本和验收。前提是样本质量过关、验收标准写清楚；如果连「什么样的输出算合格」都说不清，先回去补这一步，不是补技术。
怎么判断该不该从调用 API 转向自建？
三个条件同时看：数据有出不了内网的硬约束、月用量让按量付费明显不划算、团队有人能接住运维。只满足其中一两条时，先优化调用侧（换模型、加缓存、压上下文）通常更省事，效果也不差。
