之前有朋友问我你们做大模型项目到底是从哪一步开始做的我说不是从写模型代码开始也不是从租机器开始而是从“盘数据账本”开始。如果你也亲历过一个大模型构建全生命周期项目会发现最折腾人的从来不是某个单一技术环节而是数据、训练、评估、部署之间的衔接断层。数据没按预期洗好训练出来的模型可能直接带偏产品形态评估方式不对部署上线的效果和你的验收结论可能完全是两回事。这篇文章我会直接摊开讲一条从数据准备到服务部署的完整技术路线图以及我在各个阶段实际踩过的坑、摸索出来的做法给正在搭自己这条流水线的工程师一个可以照抄的参考。1. 数据不是“多就好”语料工程先算账1.1 数据源与粗清洗别把垃圾当原料任何大模型项目的起点都是“拿什么训练”。很多团队一上来就只顾着往前冲把公开爬虫语料直接扔进训练流程结果模型生成的答案里带着网页导航文本、重复广告甚至乱码。第一道工序不是去重不是tokenize而是先做“正文提取”。我习惯把数据源分成几类来看网页通用语料覆盖面广但信噪比很低需要去掉导航、广告、评论、登录弹窗。书籍与论文类长文本结构完整适合提升模型的推理和长期依赖能力但版权和合规风险要先处理干净。代码语料不是简单拿仓库文件拼一起就行需要按文件类型、函数体粒度切分并且过滤掉生成产物和临时文件。多语言与领域语料这部分决定你的产品在特定语言或行业里能不能用常常需要额外采集和标注。指令与对话语料体量不大但对最终产品的“手感”影响最大后面我会单独讲。粗清洗有一个顺序问题。我们在某次迭代里先做语言识别再做正文抽取结果很多语言识别器被网页里的英文导航带偏导致中文正文被标记成其他语言删掉了。后来调整成“先抽取正文、再识别语言、再做规则过滤”数据损失率立刻降了十几个百分点。这个顺序看起来不值一提实际影响非常大。1.2 去重和近重复从精确匹配到模糊去重数据集如果不去重模型会把同一段文本背下来而不是学会概括这在后续评测里表现为“见过的题分数高、没见过的题分数崩”。精确去重好做难的是近重复文本比如保留不同格式参数的文档、加了不同开头结尾的新闻稿。这类文本大概率还是阻挡。我们项目当时用的是粗哈希加MinHash的组合先拿 sha1 做精确去重再用 MinHash 算文档之间的Jaccard相似度阈值放在 0.8 左右再配合 n-gram 重叠做二次确认。参数上有一个经验可以分享窗口太小比如用 5-gram对代码这种符号密集的文本会误伤很多本来不重复的样本窗口太大比如 15-gram又很难抓到被改写了几个词的重复内容。我们后来在自然语言上用 13-gram在代码语料上降低成 9-gram分别跑了两套签名效果才稳定下来。还有一个容易被忽略的是“跨数据集去重”。如果你既用了公开语料又从其他团队那边拿了一批历史训练集两边各自的去重都做了合到一起还是会有大量重叠。正确做法是所有源头数据统一汇入同一个指纹库分批去重时增量地对着整个库查而不是每批独立算。1.3 质量过滤与数据配比能力地图怎么画粗清洗之后我建议先用一个质量分类模型或者最少用一个规则打分器把语料分成几档。规则分打分可以用句子长度、标点密度、HTML标签残留比例、敏感词库命中次数等指标拼出个分数来。质量分类器则需要人工标注几千条样本给低质量、中等、高质量打标再训练一个轻量文本分类器。这一步的目的不是把数据洗到“绝对干净”而是为了有意识控制数据组成。我见过不少团队把语料洗得只剩精华结果模型的知识覆盖范围明显变窄遇到偏门问题就生硬。适当地保留一点有噪音但信息量大的文本反而能提高模型在下游任务上的泛化性。数据配比是数据阶段最容易“拍脑袋”的环节。我们后来用的配比思路大致是数据类别占比每条平均去重后的体量范围网页通用文本55%-65%覆盖基础世界知识书籍/长文档10%-15%提升长文本与推理能力代码10%-20%提升逻辑与结构化文本能力多语言/领域文本5%-10%按产品市场调整指令/对话种子1%-3%为后续对齐准备提示模板这个配比不是拍脑袋拍出来的而是每轮先用 1/100 的小批量数据训练小模型看不同能力维度的评测曲线再调整下一轮。比如我们发现数学类评测分数偏低就去排查是不是数字格式被过度清理或者代码占比太低。把配比当成“可变旋钮”而不是“固定配方”这会让后边的训练少走很多弯路。2. 预训练与继续训练先分清自己是哪条路线2.1 分词器是第一个“产品决策”很多人觉得分词器只是训练前的准备工作不值得花心思。我的建议反过来分词器决定了模型看待文本的粒度会影响训练效率、上下文容量和最终能力必须当成一个正式决策来做。在中文、英文、代码混合的场景里分词器最容易出问题的点是数字和格式。比如“2.5万元”可能被切成一堆碎片模型很难建立起数字间的关联推理能力自然上不去。我们当时在分词器语料里专门加入了大量带小数点、百分号、日期、货币单位的文本再重新训练BPE词表才把数字类token的表示理顺。词表大小也要结合实际选。词表太大会让embedding矩阵占掉大量参数推理时的显存开销也上去词表太小则会把一些高频词拆散显著拉长序列长度。一般来说中英混合场景建议在 5万到 10万 词级别去试验先看压缩率也就是同样的文本切成多少 token再看不同词表下模型的收敛速度不要只看单条短文本的切分效果。2.2 从零预训练与继续预训练资源不同打法完全不同大模型构建全生命周期里最贵的是预训练。但很多团队其实没有必要从零开始。现在主流的开源底座已经相当成熟更现实的路线是“继续预训练 领域增量语料”。两条路线的选择基本由成本和可控性决定。我遇到过一个团队任务场景很特定预算不算大却坚持要从零训一个模型。结果训练到一半发现数据规模撑不起模型容量知识广度远不如公开底座只能终止项目换路线白白烧掉一大笔算力。从零训练适合的场景是你想彻底掌控数据来源和模型行为或者想基于一套完全全新的数据体系做研究并且能接受以“周”或“月”为单位的训练周期。继续预训练适合的场景是底座模型已经具备通用能力你只需要灌入行业知识、特定语言习惯或企业内部文档。继续训练的成本通常低一个数量级但要小心“灾难性遗忘”。我跑继续训练时有几个固定动作新版增量语料与旧版通用语料按 3:1 到 1:1 混合保留回放数据防止遗忘。把学习率压到预训练阶段的 1/10 甚至更低损失函数不要追太猛。每隔固定步数跑一组未参与训练的通用评测集用来监控通用能力是否明显下滑。2.3 分布式训练稳定比炫技更重要预训练只要规模上来就一定绕不开数据并行和模型并行。这里我不打算赘述算法原理只说工程上最有感触的部分稳定压倒一切。训练大模型最怕的不是单步算得慢而是“跑到40%崩了回滚到20小时前的检查点”。分布式训练中掉节点、显存超限、通信卡死都是常态。我们的做法是检查点保存频率要设定为一个不会浪费太多磁盘但又能承受单节点故障的间隔比如每 3到 5个step保存一次优化器状态而不是只存模型权重。每次保存完自动运行一个 5-step 的验证集损失前向发现问题早回滚不用等人工发现。日志系统要能同时看到 loss、吞吐量、显存利用率、通信耗时否则崩溃原因根本无从查起。记忆最深的一次故障损失曲线突然出现一个尖峰又回落训练程序没报错但后续模型的生成质量明显变差。后来追查发现是某节点缓存的数据切分顺序错乱导致一部分batch里混入了空文本。这类问题靠看loss不一定能抓出来所以我后来会定期检查训练数据里非空样本比例、序列截断比例把这些当常规指标报警。3. 对齐与微调指令数据决定产品手感3.1 指令数据集的构建质量是唯一护城河预训练结束后的底座模型只能说“会文本接龙”不意味着“会听话执行任务”。从底座到能用通常要经历指令微调SFT。这里最关键的不是数据量而是指令数据质量。我们在构建指令数据集时第一版犯过一个典型错误全部用模板话术生成指令格式倒是对但任务类型高度集中在“总结”和“问答”模型上线后被问到“改写这句话”、“提取关键信息”、“按表格输出”这类操作就懵了。后来我们把指令数据按产品行为重新拆成几类阅读理解、信息抽取、格式转换、代码生成、角色扮演、拒答场景。每类都维护一小组人工精写的种子数据再用已有模型做扩充一切都要保证对话格式统一。要注意的是指令数据里的“答案”不是越长越好。某次人工评估里我们发现模型总喜欢在回答末尾加“以上是……”这类废话回查指令集才发现标注人员为了凑字数净把这类尾缀当标准答案。这类数据会潜移默化地把模型带偏。所以SFT数据清洗时除了看语义正确性还要盯着格式噪音比如多余的问候语、结论段重复、列表但不闭合的markdown。3.2 SFT的操作细节轮数、批次、混入比例SFT阶段容易过拟合因为高质量指令数据的体量通常只有几万到几十万条远小于预训练数据。我们做SFT时参考过一套默认配置学习率取 1e-5 到 2e-5 区间批次大小不要贪大权重衰减稍微调高一点训练轮数控制在 2到4 轮之间。如果你发现训练集损失降到接近0、验证集损失却还在半程那就是过拟合信号需要停得更早。另一个容易翻车的是“把SFT和继续预训练混在一起”。内部迭代时我们试过把领域文档和指令数据塞进同一条流水线结果模型对指令的遵循时灵时不灵。原因是这两类数据的loss目标不一致一个在学文本分布一个在学行为对齐。合理做法是继续训练先跑完再做SFT两边用不同的学习率和数据加载逻辑。SFT阶段还要盯“格式一致性”。同一个系统的prompt、assistant前缀、多轮历史拼接方式在训练和推理时必须完全一致。我们曾因为训练时在历史轮次之间缺了一个分隔符导致推理时同样的分隔符没生效模型总把用户最新一句当成历史内容。这种问题靠观感根本发现不了最好在训练前写一个数据格式校验脚本对每条样本跑一遍正向拼接和反向还原。3.3 偏好对齐从RLHF到DPO的现实选择指令微调让模型会说话偏好对齐让模型“说得更像人喜欢的东西”。很多项目卡在RLHF这一步因为它需要训练奖励模型、做强化学习采样工程链路长调参复杂远不是跑一两个脚本能搞定的。如果项目的人力有限我更推荐先用DPO这类直接偏好优化方法。核心逻辑其实不难理解人工对同一批模型生成结果做偏好排序然后用排序结果构造正负样本对直接让模型朝着被偏好的输出方向学习。相比RLHFDPO不需要单独训练奖励模型也不需要在线采样策略环境搭建和复现成本低很多。不过DPO对数据同样敏感。如果你构造的正负样本差异太小模型就不知道该往哪调整差异太大则容易把风格学歪。我们当时的经验是先做一轮SFT确保模型已经能稳定生成非空结果再在这些结果里挑正负样本。偏好数据的规模也不需要很大几千条精心筛选的对子往往比几万条粗糙对子更有用。偏好对齐阶段还有一个重要指标叫KL散度可以理解为“新模型和旧模型偏离了多远”。偏离太大意味着模型可能学会了讨好偏好数据却丢掉了通用能力。我们每轮对齐后会跑一遍通用的知识评测集一旦发现通用能力掉得厉害就降低DPO的beta参数或者缩小训练步数。4. 评估与验收把“感觉不错”变成可信证据4.1 自动评测集既要标准也要防渗漏大模型项目最大的幻觉就是“人工试了几个case觉得不错就认为模型达标了”。要支撑一个模型的发布决策必须有自动评估流程。我们通常会准备三类评测集评测类型用途典型构成通用能力评测和公开模型横向对比常识、逻辑、数学、代码类题目领域能力评测验证产品核心场景内部专家构造的行业问答、案例分析格式与约束评测验证产品行为约束输出长度、格式、拒答触发条件通用能力评测用于判断底座基础没有崩领域能力评测才是真正决定能不能上线的那一份。而“格式与约束评测”是很多人会漏做的比如让模型输出JSON它却包了Markdown要求只回答200字以内它偏要写一长串。这类行为规则在评测自动脚本里很容易跑。防数据渗漏是评测里最要命的问题。如果评测集曾以任何形式出现在训练语料或指令数据中分数虚高不代表真实能力。我们在内部某次迭代里发现数学分数涨得离谱一查才知道标注人员把评测题直接补写进了SFT数据。后来的规定是所有评测集样本统一以哈希值入库训练数据加载时强制对比过滤任何和评测集哈希重叠的样本直接丢弃。4.2 人工评估让标准和体验对上自动指标能抓客观能力但产品“好不好用”最终还是人说了算。人工评估的难点在于标准不一致有人觉得回答详细是优点有人觉得太啰嗦。我们的做法是做一套打分卡把答案按“准确性”“完整性”“可执行性”“格式合规”四个维度分开打分而不是让人给一个总分。评分者之间的一致性也需要监控。如果两人对同一批答案的打分差距很大大概率不是模型问题而是指标描述不够细化。比如“完整性”到底是指覆盖了几个要点还是指有没有给出推理过程这些都要在评分说明里写清楚。人评分时也需要盲评不要让评分者知道对应的模型版本否则容易受主观倾向影响。4.3 回归测试与发布门槛每次新版本训练完不能只看新版评测分涨了多少还要跑“回归测试”确认旧版本能做的事情新版没有丢掉。我们内部会把上一版模型在固定评测集上的输出存成基线新版本发布前自动diff一遍针对每个case看是“变好”“变差”还是“没变”。如果变差的比例超过阈值哪怕总分是涨的这个版本也不会被直接推到线上。发布门槛也要提前定好最好写成一个简单的验收表领域能力评测得分不低于某个值、格式约束通过率不低于某个值、通用评测下滑不超过某个百分比、人工评估综合分不低于上一版。把门槛写清楚后团队就不会再出现“谁都说不准但要上线”的场面。5. 从模型到服务部署时的性能与成本博弈5.1 模型压缩与量化精度换速度但要换得值模型训练完成只是个中间态真正影响用户体验的是推理速度和服务成本。部署阶段首先遇到的就是模型体量问题。一个几十B参数的稠密模型直接用BF16权重部署单卡显存根本放不下怎么都得做量化或者多卡切分。量化是目前最直接的压缩手段。常见的做法是从BF16/FP16到INT8或INT4。INT8通常对效果影响较小INT4能进一步省显存但是否能用取决于模型对低精度的敏感度。我见过同一个模型某一部分层INT4后效果几乎不掉另一部分层INT4却会导致输出严重崩坏。所以量化绝不是一个全局开关拍下去就完事需要逐模块跑评估对比。还有一个容易被忽略的优化点是KV Cache。推理时的长序列会缓存每一层的Key和Value随着并发请求增多这部分显存占用会迅速超过模型权重本身。部署时留多少显存给KV Cache、开多大并发、是否开启Paged Attention都会直接影响吞吐建议先跑压测再定数值不要凭感觉设一个固定gpu_memory_utilization。5.2 推理框架与连续批处理让显卡别闲着大模型服务端的核心矛盾在于单次请求的生成是串行的但显存和算力都很大如果一次只服务一个请求整张卡的有效利用率非常低。所以主流推理框架都做了连续批处理也就是同时跑多个不同进度的请求谁有token生成出来就占一次前向空闲的显存继续接新请求。部署时模板化配置的思路通常是这样模型权重加载进显存后通过推理引擎暴露一个兼容OpenAI风格的HTTP接口上层网关负责鉴权、路由、限流。这里我建议在架构上直接把“保持对话历史”和“生成逻辑”分离开上下文管理交给上层服务推理引擎只负责“给定输入输出增量token”否则长会话会把KV Cache吃满拖垮全集群。服务化之后还有两个容易踩的坑一个是最大输入长度的硬限制写代码时如果不处理超长请求一个几百KB的文本片段就能把请求打到超时另一个是流式输出和结构化输出的区别像JSON模式需要推理引擎主动约束生成过程和普通流式文本是两套逻辑不要混在一起设计。5.3 延迟、吞吐与并发用数据说话上线前我们会为部署方案做一组压测并整理成一张参数表。核心指标有首token延迟、平均生成速度、最大并发数、错误率和显存占用。不同业务对这些指标的容忍度完全不同实时客服可能要求首token至少要在一秒内离线批量生成则更看重总吞吐。参数建议记录的值作用并发请求数1/10/50/100 分别测试找到拐点防止无限抬高并发拖垮服务单请求最大长度512/2048/4096验证KV Cache预留是否够生成速度tokens/s和业务体感直接相关显存水位权重/KV Cache/中间激活定位瓶颈决定是否需要扩容或降级如果并发一上来延迟立刻翻倍通常不是算力不够而是显存碎片或者调度器限制了预填充和解码的并行度先把推理框架的调度参数调一调再决定要不要加机器。6. 上线后的闭环监控、回流与再迭代6.1 线上要盯的不只是QPS服务一上线很多团队就把注意力全放到QPS和高可用上了忽略了模型本身的在线表现。模型部署后到底答得好不好不能靠用户没事来投诉得靠主动埋点。线上监控至少要分三层来看性能层TP999延迟、超时率、显存利用率、服务重启次数。生成层输出长度分布、终止原因分布、拒绝回答频率、空输出比例。业务层用户反馈、点赞/点踩、追问率、转人工率。生成层和业务层经常被忽略。比如某个版本上线后平均回答长度缩短了30%但延迟指标漂亮了好多这其实可能意味着模型开始大面积偷懒。我们在一次迭代里就遇到过“人工评测分上涨、线上转人工率也上升”的矛盾后来定位到模型大量使用简短敷衍的模板话术看起来在评测集上很干净实际并不符合用户真实诉求。6.2 反馈数据回流形成一个能自我改善的正循环部署不是终点真正的全生命周期需要形成闭环。用户在线上产生的反馈数据经过脱敏和筛选后会成为下一轮SFT数据的来源。我们的回流链路大致是采集违规或低分case - 人工复核 - 重写正确答案 - 去重入库 - 和原有指令数据按比例混合 - 进入下一轮迭代。这里要特别提醒线上反馈数据不能直接拿来训练。用户点“赞”不代表回答正确可能是误触也可能是答案看起来顺眼但信息是错的。真实操作中所有回流数据都要至少过一次人工标注或半自动审核。标注时也别只标答案对错最好标出“问题类型”“错误类型”比如是事实错误、格式错误还是答非所问这样后续才能针对错误类型去补数据。我已经在多个模型项目里反复撞过同一堵墙团队总觉得新数据越多越好于是下一版很快就忘记了旧行为结果用户熟悉的回答风格突然变了带来一片抱怨。后来我们定了一条规则每一轮SFT必须固定回放20%-30%的旧版人工精选数据像压舱石一样压住模型的历史行为。这是我觉得整个闭环里最值得保留的一条经验。回到开头那个问题做大模型项目第一步确实不是写代码而是先把“从数据到部署再到回流”这条链路的每个环节都想明白。很多技术点单看都不难难的是它们之间的衔接数据怎么支持训练评测怎么反馈数据线上行为怎么回流到下一版。如果你正在搭类似的路线图我建议先不要追求任何单点极致而是把每个阶段的输入输出接口固化下来让数据、模型、服务三层能够稳定接力。链条跑顺了后面的迭代速度自然就快了。