AI 模型开发，从头到尾 — 从数据到部署的现实生命周期

引言 — 对"模型开发"最大的误解
第 0 阶段 — 先做评估（eval-first）
数据 — 质量胜于数量
预训练 — 缩放定律的世界
微调光谱 — 从 SFT 到 DPO
评估 — 不要（全然）相信基准测试
服务（Serving）— 一场比训练更持久的战斗
部署之后 — 数据飞轮
个人如何开始
结语
参考资料

引言 — 对"模型开发"最大的误解

一提到"开发 AI 模型"，很多人会想到在数千张 GPU 上跑上几个月的预训练（pretraining）。但截至 2026 年，实务中发生的模型开发绝大多数并非如此。真正的第一步，是在写下第一行代码之前要先爬的决策阶梯：

第1阶. 靠提示词工程能解决吗？        → 大多数项目到这里就结束了
第2阶. 靠 RAG（检索增强）能解决吗？   → 如果问题是知识
第3阶. 需要微调吗？                 → 如果问题是格式・语气・领域行为
第4阶. 需要预训练吗？               → 如果你是前沿实验室

阶梯每往上爬一级，成本大约上升十倍，灵活性也随之下降相应的幅度。优秀模型开发者的第一项能力，不是把训练代码写好，而是不必要时不往上爬的判断力。本文将在那个判断之后，按顺序走一遍每个阶段实际发生的事情。

第 0 阶段 — 先做评估（eval-first）

模型开发中最常被重复的错误，是"先跑训练，之后再凭感觉确认有没有变好"。把顺序倒过来 — 评估集要先于模型。

把成功标准写成数字：不是"摘要写得好"，而是像"关键事实遗漏率 5% 以下、幻觉率 1% 以下"这样。
黄金数据集 100 题：从真实用户输入中挑出的代表性案例，加上你希望它失败的陷阱案例。不必完美，只要能版本管理、能反复执行就够了。
回归评估的习惯：哪怕只改了一行提示词，也要跑一次评估。没有这个习惯，就会被困在"昨天还行，今天不行"的谜团里。

我在做 JLPT 模拟考试工具时也原样应用了这条原则 — 验证"正确答案的位置是否均匀分布"的测试，先于题库本身就存在了。评估先行，剩下的一切才会变成实验。

数据 — 质量胜于数量

不管走到哪个阶段，数据都占成败的八成。而所有关于数据的格言，最终都收敛成一句话：一 GB 好数据，胜过一 TB 垃圾数据。

去重（dedup）：网络爬取数据中相当一部分是重复的。重复会招致过拟合和死记硬背，也是基准测试污染（后面会讲到）的元凶。
过滤与筛选：语言检测、质量分类器、有害内容清除。前沿实验室之间的差异更多来自这条流水线而非架构，这是业内公开的秘密。
许可与来源：在 2026 年的模型开发中，法务审查不是奢侈品，而是必经工序。
合成数据的兴起与陷阱：用更强的模型生成训练数据（蒸馏数据、self-instruct）如今已是标准技法。但如果仅靠模型输出一代一代地训练下去，据报告存在分布尾部被削掉的模型崩溃（model collapse）风险 — 合成数据是真实数据的调味料，不是主食。

如果是微调阶段，几百到几千条高质量示范数据，胜过几十万条带噪声的数据。哪怕只亲手做 100 条数据，你看待自己问题的眼光也会变得不同。

预训练 — 缩放定律的世界

大多数团队根本不会走到这一层，但了解这一层的原理，对上面每一层的判断都有帮助。

缩放定律就是这个世界的物理学。DeepMind 的 Chinchilla 研究揭示的核心是"在给定算力下，存在模型规模与数据量的最优比例" — 大约是每个参数配 20 个 token。前几代模型相对于数据来说参数过多（"undertrained"，训练不足），这一发现之后，业界朝"更小的模型、更多的数据"方向重新调整。今天优秀的小模型能打败几年前的大模型，一半的原因就在这里。

分布式训练栈，则是执行这套物理学的工程学。

数据并行：把同一个模型复制到多张 GPU 上，拆分批次分别处理，再同步梯度（all-reduce）。
张量/流水线并行：当模型本身放不进一张 GPU 时，要么拆分层（流水线），要么拆分矩阵（张量）。
混合精度（bf16）与梯度检查点：内存与速度之间的标准权衡。
故障是默认情况：在数千张 GPU × 数周的训练中，硬件故障不是"会不会"，而是"什么时候"。检查点策略，就是生存策略。

如果你对这层基础设施感兴趣，可以在 NVIDIA GPU Operator 与 MIG 指南里看 Kubernetes 上的 GPU 运维，也可以在神经网络实验室里亲手摸一摸反向传播最底层的原理。

微调光谱 — 从 SFT 到 DPO

微调不是单一技法，而是一个光谱。按实务顺序：

SFT（监督微调） — 用"遇到这样的输入，就这样回答"的示范数据来训练。是教会格式遵循、语气、领域词汇最直接的方法。

LoRA / QLoRA — 不更新全部权重，而是在每一层旁边挂上一个小的低秩矩阵（适配器）来训练。可训练参数减少到几百分之一，让消费级 GPU 一张卡就能微调 7B 级模型，是对个人开发者而言最重要的发明。QLoRA 在此基础上再加上 4 比特量化，进一步压缩内存。

对齐（alignment） — 超越"正确答案"，教会模型"更受偏好的答案"的阶段。由 InstructGPT 确立的 RLHF（基于人类反馈的强化学习）需要奖励模型 + PPO 这样复杂的流水线，但 DPO（Direct Preference Optimization）用"直接在偏好对数据上优化"这个简单的损失函数替代了其中相当一部分，大幅降低了对齐的入门门槛。2026 年的实务默认值是"SFT → DPO（或其变体）"。

什么时候用什么：知识注入应该先用 RAG，而不是微调（微调后的知识更新既慢又贵）。微调真正取胜的地方是格式・风格・领域特化的行为 — 只吐 JSON、遵循公司内部代码规范、保持特定的语气。

评估 — 不要（全然）相信基准测试

基准测试污染是这个阶段最大的陷阱。公开基准测试的题目一旦混入训练数据，分数会上升，能力却原地不动。看到新模型亮眼的基准分数时，"怎么保证这些题目没出现在训练数据里？"永远是一个正当的问题。

实务评估的三层结构：

自动指标 — 有明确正确答案的任务（分类、抽取）的准确率/F1。便宜又快，尽量多用这一层。
LLM-as-judge — 由强模型给自由文本输出打分。可以规模化，但存在偏差（偏好自己风格的输出、偏好长文本），需要定期核验它与人工评分的一致率。
人工评估 — 最贵，也最准确的终审。重要发布前，哪怕只做一小批也好。

而最重要的一点是：用你自己的任务做出的、属于你自己的评估集，比任何公开基准测试都更能说明你的产品。第 0 阶段做出的黄金集，会在这里持续发挥作用。

服务（Serving）— 一场比训练更持久的战斗

模型只训练一次，但推理会永远运行下去。总成本的大部分都来自服务环节。

量化：把权重从 bf16 降到 INT8、4 比特，内存能降到一半到四分之一 — 质量损失需要按任务逐一测量，但往往比想象中小。
蒸馏（distillation）：用大模型的输出教小模型，在特定任务上以几分之一的成本获得相近的质量。"用前沿模型做原型 → 用蒸馏做量产"已成为标准模式。
KV 缓存与连续批处理（continuous batching）：Transformer 推理的瓶颈更多在于内存带宽而非计算量。vLLM 一类服务引擎的 PagedAttention、continuous batching 为什么能把吞吐量提高好几倍，值得花时间弄懂一次。
延迟预算设计：按 p99 而不是 p50 来设计，并用流式输出降低用户感知到的延迟。

如果你面对的是把多个模型密集地塞进一张 GPU 的问题，前面提到的 MIG 分割指南正是这个点上的基础设施解法。

部署之后 — 数据飞轮

部署不是终点，而是启动了最好的数据收集器。

生产环境评估：离线黄金集加上线上抽样打分并行进行。实际使用的分布一定会偏离开发时的分布。
失败案例挖掘：用户重新提问、修正、或中途离开的对话，是下一轮微调最好的原料。
飞轮：部署 → 收集失败 → 数据化 → 重新训练 → 部署。这个循环转动的速度，就是团队实力本身。模型开发不是一个项目，而是一个运营循环。

个人如何开始

一条能让个人体验这整个过程的现实路径：

从零到一次：用 Karpathy 的 nanoGPT 一类的迷你实现，亲手训练一个小型 Transformer。缩放的直觉，来自那几百行代码。
微调一次：拿一个公开的 7B 级模型，用 LoRA，配上自己做的 500 条数据。目的是亲身感受数据质量如何左右结果。
评估框架一次：自己任务的黄金集 100 条，加上自动打分脚本。光是这一点，就已经是前 10% 的习惯了。
服务一次：把量化后的模型跑在本地，实测一下吞吐量和延迟。

如果苦恼的是学习方法本身，用 AI 学习的方法里的 8 个技巧值得一看；如果目标是这个领域的职业发展，按职位划分的知识地图里 AI/LLM 工程师那一节就是你的下一步。

结语

把 AI 模型开发的生命周期压缩成一句话，就是这样：先做评估，怀疑你的数据，阶梯只爬到必要的高度，并设计好部署之后的循环。 华丽的是训练曲线，但胜负永远取决于它前后的东西 — 数据、评估与运营。