大模型是怎么炼成的:从训练数据到你手里的 API

大家好,我是极客老墨。
你有没有想过:ChatGPT、DeepSeek,这些大模型是怎么"造"出来的?
很多人用了大半年 AI,依然不知道答案。他们知道模型很强,但不知道强从哪来;知道调 temperature 能改变风格,但不知道为什么。这种"只会开车、不知道发动机"的状态,限制了你对 AI 能力边界的判断,也限制了你设计 AI 应用的想象力。
这篇文章要做一件事:把大模型从"一堆原始数据"到"你手里的 API"这条完整链路讲清楚。 普通人能看懂,开发者能用上。
第一段:模型是怎么被造出来的
大模型的诞生,分四个阶段,缺一不可。
flowchart TD
A["海量原始数据
网页/书籍/代码/论文"] --> B["预训练
Next Token Prediction"]
B --> C["指令微调 SFT
教模型听懂人话"]
C --> D["强化学习对齐 RLHF
教模型说对的话"]
D --> E["量化 & 部署
压缩上线"]
E --> F["你调用的 API"]
阶段一:预训练——从"0"开始读书
预训练是整个大模型能力的根基。这个阶段,模型什么都不知道,就像一张白纸。
研究团队先从互联网抓取海量文本的网页数据、Wikipedia、GitHub 代码库、arXiv 论文、书籍……DeepSeek-V3 的预训练数据量超过 14.8 万亿个 Token。这是什么概念?一个人一天读 8 小时,读完大概需要 2 万年。
有了数据,然后呢?训练任务出乎意料地简单:给你前面的词,猜下一个词。
输入:「人工智能是」
目标:预测「一」
输入:「人工智能是一」
目标:预测「种」
输入:「人工智能是一种」
目标:预测「模拟」
就这么一个任务,重复几十亿次。模型每猜错一次,就调整内部参数,让下次猜得准一点——这个调整过程叫反向传播(Backpropagation)。
听起来很蠢,但这个过程里,模型必须学会:语法(要猜对,先得懂语法)、逻辑(前后要自洽)、事实(猜"巴黎是法国的"之后,下一个词大概率是"首都")。理解语言这件事,被巧妙地转化成了一个预测问题。
预训练完成后,得到的叫基础模型(Base Model)。它博闻强识,但说话毫无规矩——你问它"怎么做蛋炒饭",它可能给你接着补全"的做法,与红烧肉相比……",因为它只会"续写",不会"回答"。
老墨说: 预训练的成本极其高昂。DeepSeek-V3 的预训练花了约 558 万 H800 GPU 小时,折合成本约 557 万美元。这就是为什么大模型的研发门槛这么高——不是算法有多难,是算力烧不起。
阶段二:SFT——从"读书人"变成"听话的助手"
基础模型读了天下书,但不会用。第二阶段叫指令微调(Supervised Fine-Tuning,SFT),目标是把基础模型训练成能按人类指令行事的助手。
方法很直接:收集大量"指令 → 高质量回答"的配对样本,让模型学习"当人类这么说,应该这么答"的模式。
示例数据:
指令:「帮我写一封给客户道歉的邮件」
回答:「尊敬的客户,您好。非常抱歉……(高质量示范)」
指令:「用 Go 实现一个 HTTP 服务器」
回答:「package main\nimport …(正确代码)」
这些样本从哪来?OpenAI、Anthropic 等公司雇佣了大量标注工程师,手工编写高质量的问答对。DeepSeek 则走了另一条路——用更强的模型来生成训练数据,大幅降低人工成本(这也是国产模型能以极低成本追上的原因之一)。
SFT 之后,模型开始能正常"对话"了。但它还有一个根本问题:它不在乎说的是否正确,只在乎说的像不像训练集里的高质量答案。 换句话说,它会"表演有帮助",而不是真的有帮助。
老墨说: SFT 解决的是"模型听不听话"的问题,不是"模型说没说真话"的问题。你见过 AI 一本正经地胡说八道——那叫幻觉(Hallucination),SFT 阶段解决不了,要靠下一步。
阶段三:RLHF——教模型说"对的话"
第三阶段叫基于人类反馈的强化学习(Reinforcement Learning from Human Feedback,RLHF)。这是让大模型真正变得"可用"的关键一步。
流程如下:
flowchart TD
A["同一个问题
让模型生成多个回答"] --> B["人类标注员
给每个回答打分"]
B --> C["用打分数据
训练一个「奖励模型」
Reward Model"]
C --> D["用奖励模型指导主模型
做强化学习
好回答 → 正向激励
差回答 → 负向激励"]
D --> E["模型越来越倾向于
生成高分回答"]
奖励模型扮演的角色,相当于一个"AI 考官":它学会了区分"有帮助的回答"和"看起来有帮助但实际不对的回答",然后用这个判断力持续指导主模型优化。
这个过程对安全性同样关键。通过 RLHF,可以训练模型拒绝有害请求、减少幻觉、保持前后一致。你用 ChatGPT 问它违法的问题会被拒绝,就是 RLHF 的结果。
新一代的推理模型(如 DeepSeek-R1、OpenAI o3)还加入了基于过程的强化学习——不只奖励最终答案是否正确,还奖励推理过程中的每一步是否合理,这让模型真正学会了"一步一步想"。
老墨说: RLHF 是大模型工程里最像"养孩子"的一步。你不只要告诉它"这样做是对的",还要通过不断的反馈让它学会自己判断什么是好的。这个过程决定了模型的"价值观",也是不同厂商的模型风格差异最大的地方。
阶段四:量化与部署——从实验室到生产环境
训练完成的模型,参数量动辄几百亿甚至几千亿。DeepSeek-V3 有 6710 亿参数,直接运行需要几十张顶级 GPU——这显然不能直接对外提供服务。
上线前,还要经过量化(Quantization):把模型参数从高精度浮点数(FP32/BF16)压缩成低精度整数(INT8/INT4),体积缩小 2–8 倍,推理速度大幅提升,精度损失通常在 1–3% 以内,用户几乎感知不到。
DeepSeek-V3 还用了 MoE(混合专家,Mixture of Experts) 架构:6710 亿参数里,每次实际激活的只有 370 亿,其余的"专家"按需调用。这让超大模型在推理时的实际算力消耗和同等激活参数的密集模型相当,既有大模型的能力,又有小模型的速度。
完成量化和工程优化之后,模型才部署到服务器集群,封装成 API,这才是你用 SDK 调用时对面那个东西的真实面目。
老墨说: 你调用
deepseek-chat这个 API,背后是一套从训练到部署的完整工程体系。理解这条链路,你才知道为什么"切换模型"不只是改个参数,也才能理解为什么本地部署小模型和调云端 API 的体验差异那么大——它们本质上处于这条链路的不同位置。
第二段:推理时发生了什么
模型做好了。现在你发出一个请求——从你的文字到屏幕上的回答,中间经历了什么?
flowchart TD
A["你输入的文字"] --> B["Tokenization
BPE 分词→Token ID"]
B --> C["Prefill
并行计算输入→KV Cache"]
C --> D["Decode 循环
逐 Token 自回归生成"]
D --> E["Detokenization
Token ID→文字"]
E --> F["你看到的回答"]
第一步:Tokenization——把人话拆成数字
大模型接收的不是文字,而是数字。Tokenization 把输入文字切成 Token,每个 Token 映射成一个整数 ID。
这个切割算法叫 BPE(Byte-Pair Encoding),由训练语料的统计规律决定,不是按字或词切的:
输入:「大模型不会思考」
切割:["大", "模型", "不会", "思考"]
ID: [2982, 3478, 1923, 4102]
输入:「tokenization」
切割:["token", "ization"] ← 不是整词,因为 "ization" 是高频后缀
ID: [3642, 1634]
中文和英文的 Token 效率不同:英文约 1 个 Token/4 字符,中文约 1 个 Token/1.5 汉字。同等内容,中文 prompt 比英文贵 30%–50%,直接影响 API 成本。
老墨说: Token 是计费单位,也是上下文窗口的计量单位。你能发多长的消息、模型能记住多少对话历史,本质上都是 Token 数的问题。Token 不理解透,成本估算和上下文管理全是玄学。
第二步:Prefill——把你的输入"消化"掉
Token ID 序列进入模型后,第一件事是 Prefill(预填充):把所有输入 Token 并行送进模型,一次性算完它们之间的关联关系,生成第一个输出 Token,并把中间的计算结果缓存起来——这个缓存叫 KV Cache。
Prefill 是计算密集型操作,输入越长,这一步越慢,但可以并行加速。
第三步:自回归生成——每次只猜一个词
这是大模型最核心的工作方式:每一步只预测下一个 Token 的概率分布,从中采样一个,追加到序列末尾,然后重复,直到生成结束符或达到 max_tokens 上限。
当前序列:["大", "模型", "不会"]
预测概率分布:
"思考" → 32%
"说话" → 18%
"理解" → 15%
"飞" → 0.001%
...
采样得到:"思考"
新序列:["大", "模型", "不会", "思考"]
继续预测下一个...
这就是你看到"打字机效果"的根本原因:模型在物理上就是一个 Token 一个 Token 地往外吐,不是生成完整答案再返回。流式输出(SSE)只是把这个天然的过程实时推给了客户端。
Decode 阶段依赖 KV Cache。 每生成一个新 Token,模型只需要计算这个新 Token 和所有历史 Token 的关系,历史 Token 之间的关系已经缓存在 KV Cache 里,不用重算。没有 KV Cache,计算量随序列长度平方爆炸,长对话会慢到无法使用。
老墨说: “自回归没有全局规划"是大模型最重要的局限之一。它不知道自己接下来要说什么,只知道当前序列下一个词最可能是什么。这就是为什么让模型写长结构化内容时后半段容易跑偏——在 prompt 里明确给出结构框架,相当于给每一步的局部预测提供了全局线索,是提升长内容质量的核心手段。
第四步:采样参数——控制"猜测的风格”
模型对每个 Token 算出的原始分数叫 logits,经过 Softmax 函数变成概率分布。采样参数控制的就是"怎么从这个概率分布里选一个 Token":
Temperature(温度):调节概率分布的尖锐程度。
$$P(t_i) = \frac{e^{z_i / T}}{\sum_j e^{z_j / T}}$$
| Temperature | 效果 | 适用场景 |
|---|---|---|
T → 0 | 永远选最高概率的词,输出确定 | 代码生成、JSON 提取、结构化任务 |
T = 1.0 | 原始概率分布,不调整 | 通用场景默认值 |
T > 1.0 | 概率分布变平,低概率词也有机会,输出随机 | 头脑风暴、创意写作 |
Top-P(核采样):从高到低累加,概率之和超过 P 时截止,只在这个范围里采样。top_p=0.9 意味着用 90% 的概率质量圈定候选集。
Top-P 圈范围,Temperature 控随机程度——两者作用不同,通常配合使用。
实用调参规律:
代码 / JSON / 结构化输出 → temperature: 0.0–0.3,top_p: 0.7–0.8
通用问答 / 总结 → temperature: 0.5–0.7,top_p: 0.9
创意写作 / 头脑风暴 → temperature: 0.9–1.2,top_p: 0.95–1.0
老墨说:
temperature=0不是"最聪明",是"最保守"。它总是选当前最高概率的词,不代表选的就是最好的,只代表最像训练数据里的常见答案。创意场景下,稍微放开一些反而能得到更有意思的结果。
把链路完整串一遍
现在可以把两段链路放在一起看:
flowchart TD
subgraph 制造阶段
A["海量文本数据
14.8万亿 Token"] --> B["预训练
猜下一个词,反复迭代 → 基础模型"]
B --> C["SFT 指令微调
学会听话 → 会对话的模型"]
C --> D["RLHF 强化学习对齐
学会说对的话 → 可用的助手"]
D --> E["量化 & 部署
压缩上线 → API 服务"]
end
subgraph 推理阶段
F["你的输入文字"] --> G["Tokenization
文字 → Token ID"]
G --> H["Prefill
并行计算 → KV Cache"]
H --> I["Decode 循环
逐 Token 自回归生成"]
I --> J["Detokenization
Token ID → 文字"]
J --> K["你看到的回答"]
end
E --> F
两段链路的对应关系:
| 制造阶段的工作 | 决定了推理阶段的什么 |
|---|---|
| 预训练数据的质量和规模 | 模型知识的宽度和深度 |
| SFT 的指令样本质量 | 模型理解你意图的准确度 |
| RLHF 的奖励设计 | 模型拒绝有害请求、减少幻觉的能力 |
| 量化精度 | 推理速度和本地部署的可行性 |
| Context Window 大小 | 单次对话能记住多少内容 |
老墨总结
这篇的核心认知只有一个:大模型不是从天上掉下来的,它是一套严密的工程流程的产物,每一个你能感知到的行为,背后都有对应的训练决策。
- 模型"知识丰富"——预训练数据的功劳
- 模型"听得懂人话"——SFT 微调的功劳
- 模型"不乱说话"——RLHF 对齐的功劳
- 模型"能快速响应"——量化和工程优化的功劳
- 模型"答案随机/确定"——你调的 temperature 参数的功劳
理解这条链路之后,你对大模型的判断会完全不同:
当模型答错了,你知道这可能是训练数据里没有这个知识,也可能是 SFT 样本不够,不会盲目认为"AI 不行"。
当模型拒绝了你的请求,你知道这是 RLHF 对齐的结果,不是模型"不会",换个说法往往绕得过去。
当你想让模型输出更稳定,你知道应该调低 temperature,而不是换一个更贵的模型。
这些认知会在后面所有模块里反复用到——设计 prompt 时、排查 bug 时、评估模型时。这一篇搞透,后面的路会顺很多。
文章有帮助?转发给同样在踩坑的朋友。有不同意见?评论区见。
关注公众号:极客老墨
更多 AI 应用开发、工程实践和效率工具分享,欢迎扫码关注。
