大模型工程实践指南：预训练、微调、推理与开源二次开发

这年头只要聊到AI“大模型”三个字几乎躲不掉。可大多数人的认知停在“用过ChatGPT”或者“看过几篇榜单测评”的层面真要落到具体干活预训练、微调、推理、开源二次开发这四个词哪一个拎出来都能劝退一批新手。我是Loongwise过去一年多密集做过几个自有数据的模型项目从买卡租卡、清洗数据、跑分布式训练到微调、量化、部署推理服务整条链路基本都摸过一遍。这篇把这条技术路线的全貌、关键决策点和真正的应用边界一次讲清楚。适合正在做LLM工程落地的同学、想评估自建还是调用API的技术负责人以及对“到底要不要自己训模型”感到纠结的产品负责人。1. 先把技术路线讲透预训练、微调、推理到底在解决什么问题1.1 三个环节的分工与关系大模型从技术视角看是一条流水线而不是单独一个文件。把模型权重下载下来只是一个起点。预训练解决的是“模型有没有基础知识与推理能力”的问题它负责从海量文本里学习语言的统计规律、知识结构、思维链能力产出一个通用的基座模型。微调解决的是“这个模型是否贴合我的具体任务”的问题基座模型什么都会一点但直接用来做特定领域任务往往不够精准需要拿业务数据做针对性的调优。推理解决的是“模型能力能否以可接受的成本和延迟对外提供服务”权重再多跑不动或者跑起来太贵产品就立不住。我用一个生活化的类比来解释。预训练相当于一个学生花十几年接受通识教育学的是广泛的知识体系、阅读能力和思考方式毕业时底子已经很扎实。微调相当于上岗前的职业培训把通用的能力收敛到某个具体岗位上比如文档审核、客服问答、代码审查。推理则相当于把他安排进生产线考虑的是出活速度、人力成本和排班调度。三者不是前后替代的关系而是层层递进的关系每一层都有独立的工程问题。1.2 我见过的最常见的认知误区我刚接触大模型项目时最大的误区就是以为“微调”是一切问题的解药只要模型答得不好就微调一把。后来被现实教育了很多时候模型答得不好根因根本不在模型本身而是提示词没设计好、上下文信息不完整、或者压根就不适合用大模型来做。反过来也有一些人把预训练神话化觉得只有大厂玩得起小团队就只能调API但实际上开源生态已经把这层门槛大幅拉低了基于开源模型做二次开发已经是很多公司的主选项。这条链路上最容易犯的另一个错是把成本算错。有人张口就要从零预训练一个千亿模型却连数据准备和算力评估都没做过。预训练、微调、推理这三个环节的算力需求差着数量级预训练动辄上万卡时微调可能只需要一卡到几十卡推理优化更多是看服务吞吐和显存规划。差一个数量级预算方案就完全不同。想清楚这一点后面所有的路线讨论才有意义。2. 预训练整个链路里最重、也最容易被误判的工程2.1 预训练到底在训练什么接触过NLP的人都知道语言模型做的是“根据前文预测下一个词”。预训练阶段模型在海量语料上反复执行这个最简单也最困难的任务。说它简单是因为训练目标单一不需要人工标注说它困难是因为数据量巨大而且模型要从这种“盲猜下一个词”的压力中压缩出语法规则、事实知识、逻辑推理甚至跨语言的迁移能力。很多文章会用“涌现能力”来解释预训练的效果但从工程视角看我更愿意把它拆成三件事理解能力、知识密度和指令遵循的底子。理解能力来自注意力机制在长上下文中建立关联知识密度取决于语料的覆盖度、质量和去重程度指令遵循的底子则更多要到后面对齐阶段才显现。预训练阶段并不直接追求“听话”而是在训练“会思考”。2.2 数据工程才是真正的护城河预训练领域有一句被说烂的话数据决定模型上限。我实际做下来觉得这句话的力度还不够。模型结构各家可以互相借鉴训练框架也都是公开的真正的差异点几乎全在数据上。语料清洗到什么程度、怎么去重、怎么按语言和领域配比、要不要混合代码数据、采样的温度怎么设这些坑每一个都能吞掉大量算力。举例来说去重这一步就不是简单的“删掉完全相同的句子”。语义相似的文本、模板化的重复段落、从同一篇文章拆出来的多个片段都需要用指纹算法加Embedding聚类做多级去重。我在一次预训练任务里用MinHash做了两轮去重去掉将近30%的冗余数据训练效率提升是肉眼可见的。还有语料配比代码和自然语言的比例、中文英文的比例、学术文本和网页文本的比例微调几个点下游评测分数可能就完成质变。这些经验很难从论文里获得基本要靠试错积累。2.3 分布式训练框架与工程细节预训练的技术核心是分布式训练。目前业界的主流方案是DeepSpeed、Megatron-LM以及两者结合的Megatron-DeepSpeed。数据并行、张量并行、流水线并行、序列并行这四类并行策略各有各的使用场景。数据并行最简单每个GPU持有一份完整模型副本分一批数据训练梯度同步后更新。张量并行把一个Transformer层拆到多卡上解决单卡放不下的问题。流水线并行则是把不同层分给不同设备切分计算流水。我自己的体会是预训练和微调的并行策略重点完全不同。微调时数据并行加ZeRO就够了预训练则必须考虑3D并行甚至4D并行还有通信拓扑、负载均衡、损失缩放等一堆细节。如果不熟悉分布式训练直接用现成框架还好一旦遇到了模型并行下某个张量尺寸对不上、梯度累积步数不对导致收敛不稳的问题排错成本会高到让人怀疑人生。所以如果不是特别有闲钱和人力我的建议是预训练这种重基建活尽量少碰或者只在专业团队里碰多数创业团队不值得从零做。这是我在这个领域的真心话。2.4 预训练的成本与门槛公开信息里的预训练成本大多以百万美元计那是卡时和电费、带宽、人力一起算的总账。对小团队来说算力租赁可能是几百块一小时到几千块一小时不等训练一个7B到13B的模型跑几十天账单就会达到几十万甚至百万级别。所以要不要预训练不是技术问题是财务问题。现在很多团队已经形成一个共识直接用开源基座模型把资源砸到微调和推理优化上性价比高得多。3. 微调花小钱把通用模型调成合手的工具3.1 先判断“到底该不该微调”这是我在实操中被问得最多的问题。我的判断框架很简单先用Prompt工程和上下文检索试一试如果效果能达到产品要求就不要微调如果试了收敛不了或者语义、格式、领域术语的偏差一直存在才考虑微调。很多人上来就微调其实是拿微调弥补Prompt和RAG的缺失结果数据和训练成本花了不少效果还不一定更好。微调真正擅长的事有三类。第一让模型稳定输出特定格式比如企业内部的合同模板、严格的JSON结构第二注入某个垂直领域的术语、行话和常识比如医疗、法律、工程图纸这些公开语料里面比例很低的专有知识第三稳定一个风格或语气比如让模型的回复更简短、更口语化或者更像某个角色的表达。凡是不属于这三类的问题先怀疑是提示词或链路的问题别急着烧钱。3.2 全参微调与参数高效微调微调的主要技术路线分两端。全参微调更新模型所有参数效果上限最高但对显存和算力的要求也最夸张一个小模型全参微调也需要几十GB甚至上百GB的显存而且容易过拟合。参数高效微调里最出名的就是LoRA。LoRA的做法是冻结原模型权重只在Transformer的注意力层旁边插入低秩矩阵训练时只更新这些小矩阵。这样训练参数量可能只占全模型的1%到2%显存需求一下子降了一到两个数量级。我今年做过好几个LoRA微调项目效果基本能接近甚至对齐全参微调前提是秩、目标模块和数据量都调对。QLoRA是在LoRA基础上再对基座模型做4-bit量化加载把7B模型微调的显存压到10GB以下单卡消费级显卡就能跑。这对小团队来说意义极大。不过要提醒的是LoRA不是银弹因为训练参数少和全参微调相比它对知识注入的深度有限更适合做风格和指令对齐类任务真要系统性注入某个领域的复杂知识还是得考虑全参或更大规模的LoRA。3.3 微调数据怎么准备微调数据的质量直接决定微调的天花板。我见过太多项目模型结构没毛病训练参数也不差结果数据一塌糊涂标注不一致、正负样本比例失衡、重复样本过多轻则模型学偏重则灾难性遗忘。准备微调数据时我会做这几步。第一写清楚任务说明书把每条数据应该长什么样列成规范第二进行多次“小批验证”拿50到100条先微调一轮人工看输出不合格就回头改数据而不是继续扩量第三做去重和去噪把只有微小差异的样本留一条把答非所问、错别字成片的样本清出去第四控制数据配比真实业务场景的数据往往长尾严重冷门case要么多采要么干脆不做不能让它把主流能力带偏。每一条都踩过坑尤其是第一条和第二条几乎决定微调的成败。3.4 一次典型的LoRA微调实操以Qwen2.5-7B为例我自己常用的微调流程大致是先加载基座模型配置LoRA的秩r、缩放系数alpha、Dropout和target_modules。一般经验值r16、alpha32target_modules选取attention层的q_proj、k_proj、v_proj、o_proj当然现在很多框架里直接写“all”也行。训练参数里学习率通常设在1e-4到2e-4之间配合余弦退火批量大小看显存QLoRA下4或者8都能跑训练轮数我习惯用1到3个epoch超过3轮过拟合风险明显上升。训练中我会盯着两个指标训练损失是否稳定下降以及一个固定验证集上的输出是否在逐步贴近期望的格式。训练结束后的合并操作也容易踩坑用PEFT合并LoRA权重到基座模型时务必确认模型的dtype一致否则精度错位会带来莫名其妙的输出混乱。实测下来在消费级显卡上跑7B模型的QLoRA微调一条1万条左右的数据集大约两到四小时就能完成一轮性价比非常高。4. 推理从权重到可用服务的最后一公里4.1 推理引擎怎么选模型微调完还只是权重文件真正面向用户的是推理服务。推理引擎这个环节这两年卷得很厉害。vLLM应该是目前社区接受度最高的核心是PagedAttention把KV Cache像操作系统管理内存一样做分页管理显存利用率显著提升吞吐量比原生HuggingFace Transformers推理高一个量级。SGLang也在快速发展在多轮对话和结构化输出的场景上有优势。TensorRT-LLM是英伟达的自家方案优化极致但适配成本高适合对性能有极致要求的生产环境。选型的逻辑我的经验是优先vLLM因为它生态好、文档全、坑相对少如果业务是大量并发的结构化输出可以试试SGLang如果已经上了全套英伟达方案而且有专门性能调优的人力TensorRT-LLM值得投入。还有Ollama这类轻量方案适合本地开发、个人实验和快速原型但压不住高并发的生产场景。把引擎选型想得太重没必要先用最通用的等量大了再迁移也来得及。4.2 显存、KV Cache与吞吐量的博弈推理阶段最大的资源瓶颈是KV Cache。一个7B模型FP16权重大约占14GB但推理时每一层注意力都要缓存历史和当前时刻的Key、Value向量上下文越长、并发请求越多KV Cache占的显存就越夸张。这也是为什么模型支持多长的上下文和实际能跑多长的上下文完全是两回事。不规划KV Cache一批并发长文本请求直接就能把显存打爆。实际部署中我会先估算一个预算假设单卡80GB模型权重14GB预留足够余量后剩下的显存主要分给KV Cache。显存不够时优先考虑量化模型权重其次降低最大输入长度限制再次通过批处理控制并发。vLLM提供了很多调度参数比如gpu_memory_utilization和max_num_batched_tokens实际调起来需要在吞吐量和延迟之间反复试不存在一劳永逸的最佳值。4.3 量化把模型塞进更小的显存量化是推理优化里见效最快的手段。业界常用的是AWQ和GPTQ都是做权重量化AWQ在部分任务上损失更小。还有更激进的FP8、INT4甚至INT2方案。我在部署7B和13B模型时通常先用FP16跑基准量化之后用评测集验证指标落差。如果业务对精度敏感比如法律文书、医学输出就不要为了省那点显存去压得太狠如果只是普通问答场景INT4量化换来的显存节省非常划算。量化的另一个坑是不同推理引擎对量化格式的兼容性不一样。GPTQ的模型在vLLM里能跑换到TensorRT-LLM可能需要重新导出AWQ也是。所以量化方案最好在选定推理引擎之后再定免得做完量化发现引擎不认又得返工。代码里偶尔会遇到量化后输出出现NaN多半是校准集太小导致缩放系数不准加几倍校准数据再试通常会好。4.4 服务化部署要点真正对外提供服务除了推理引擎还要考虑API层、并发控制、监控和灰度。我一般用Docker把推理服务打包外面再套一层统一的API网关负责鉴权、限流、日志。vLLM本身支持OpenAI兼容接口这一步能省很多事上层应用可以直接用OpenAI SDK的地址连接。监控方面至少要看吞吐量、首Token延迟、Token生成速度、显存利用率和错误率这五样缺一不可。还有一个容易忽视的点推理服务的模型权重加载时间。一个大点的模型加载几分钟可能都算正常生产环境必须做模型预加载和优雅启动防止容器编排滚动更新时把服务直接打挂。我用过的最简单方案是加一个就绪探针等模型真正加载完成再放流量。这些细节看起来不起眼但真正上线之后全是决定服务质量的关键。5. 开源二次开发站在开源基座上做自己的产品5.1 开源生态的现状开源大模型这几年的进展可以用野蛮生长来形容。从Llama系列开始到Qwen、GLM、DeepSeek、Mistral等一拨又一拨的开放权重模型把大模型的准入门槛拉到了前所未有的低位。以前自己搞一个可用的文本模型几乎是天方夜谭现在开源社区里7B、14B、72B各种规模的基座随便挑不少模型在特定任务上的表现甚至能对标顶级闭源模型。开源二次开发的“二次”非常关键。绝大多数团队不是要自己发明模型结构而是基于一个成熟基座用微调、RAG、Agent、工具调用等手段把它改造成适合业务的产品。这条路线的优势很直接可控、可私有化部署、数据不出域、长期成本可预期对很多数据敏感的组织几乎是唯一选择。5.2 基座模型怎么选选基座模型我会看五个维度任务能力、生态成熟度、模型规模、许可证合规性、社区活跃度。任务能力先看公开榜单和自己的评测集别光看总分要看细分能力比如代码、数学、中文理解、长文本。生态成熟度看有没有对应的量化版本、微调框架适配、推理引擎支持。模型规模结合你的硬件预算来7B是性价比之王但复杂推理任务可能力不从心72B级别能力很强但没有足够显存也是白搭。许可证这块特别容易被忽略。很多开源模型带着特定的使用条款有的限制商用有的对月活用户数有限制有的要求衍生品保持同协议开源。我在早期项目里就因为忽视了模型许可证后面差点在法律层面出问题。现在选模型的第一步就是先看LICENSE确认商用和二次分发是不是符合预期。5.3 应用开发模式Prompt工程、RAG与Agent开源模型拿到手最常见的第一层改造是提示词工程。这层门槛最低调整成本和返工成本也都低我强烈建议所有团队先从这一层做起。第二层是RAG把私有知识库外挂到模型上通过检索把相关文本拼进上下文模型再基于这些材料生成答案。RAG的优势是不需要重新训练幻觉可以大幅缓解而且知识更新成本低换了文档内容下次检索就生效。第三层是Agent。让模型不只是聊天而是能调用工具、执行多步计划、读取外部系统数据再综合结果给出输出。开源模型做Agent的难点在于指令遵循、工具调用格式、多步推理的可靠性直接取决于基座能力。实测下来小模型在简单单步工具调用上没问题复杂多步任务里还是大模型稳。所以Agent链路对模型选型的要求比普通问答高得多不能拍脑袋选最小的模型。5.4 一个典型的开源落地路线拿一个我最近参与的项目举例团队要做企业内部知识问答系统数据不能出域。我们直接选定了开源基座模型用公司内部的制度文档和技术文档构建了一个RAG知识库同时用几百条人工标注的问答对做了LoRA微调让模型习惯内部的语气和回答格式。整个推理服务部署在自有机房的GPU服务器上通过API网关对内网提供OpenAI兼容接口。整个过程没有做任何预训练甚至没有做全参微调但最终效果已经能满足业务方验收标准。这类路线的成本结构很有意思硬件采购或租用一次性投入剩下的主要是数据清洗、评测和运营费用边际成本很低。对比按量付费的API方案虽然初期投入更高但在数据敏感度和长期成本上优势明显。对一个稳定运行两三年的业务来说私有化开源路线往往更划算。6. 应用边界什么需求该走哪条路什么时候应该收手6.1 先算清账预算决定技术路线我一直想强调技术路线不是拍脑袋定的而是预算倒推的。如果你的整体预算只能覆盖API调用费用那开源二次开发就只是个备选如果你已经有一批闲置GPU或者有长期高并发的需求开源自部署的路径就出来了。这里我建议每个团队都做一份“显存-吞吐-成本”的测算表算清楚服务目标并发和上下文长度下需要多少GPUGPU是租是买摊到每个月是多少钱。很多团队不做这一步上线以后发现推理成本比预期的API费用还贵就尴尬了。6.2 什么时候不该微调应用边界这块我得说点得罪人的话。相当一部分场景实在没必要微调。原因很简单微调带来的增量收益常常被它带来的维护成本吃掉。如果模型的能力缺口可以通过写更好的提示词、挂更强的检索、接更合适的外部工具搞定那就先别微调。尤其是团队里没有能稳定产出高质量训练数据的人贸然微调只会得到一个“看似定制、实则更蠢”的模型。另一个不该微调的情况是业务变化太快。知识类产品今天的内容明天就过期了微调的知识会和现实脱节RAG反而更适合。微调的适用对象是“语义和格式长期稳定”的任务而不是“新鲜知识不断涌入”的任务。边界不清晰钱就打了水漂。6.3 什么时候才值得动预训练预训练的适用面更加狭窄。除非你确实需要完全自主可控的模型架构、或者任务领域太特殊导致公开语料覆盖不足、或者你有足够的算力、数据和工程人力否则从零预训练都是不理性的。一个折中方案是继续预训练拿领域数据在开源基座上接着训一段既吸收了通用能力又补充了领域知识成本比从零预训练低得多也是不少垂直模型的真实做法。6.4 安全与合规的边界模型能力是把双刃剑。开源模型能做的事情很多但部署和使用的安全责任是落在使用方身上的。数据合规、内容安全、服务稳定性这些在自部署场景里没有供应商替你兜底都要自己扛。我建议每个自部署项目上线前都要做一次功能与安全验收评测输出是否包含有害内容、敏感数据是否会在对话中泄露、接口有没有鉴权和风控。这些不是可选项是上线的前置条件。特别强调一点很多人以为开源模型“免费”就忽略了背后的人力成本。安全和合规不是买来的是维护出来的。没有专职或兼职的人员盯评测、盯监控、盯更新再好的模型也会变成一个无人看管的生产隐患。7. 我踩过的坑大模型项目常见问题速查聊完边界把话题拉回到实操。这一节我用表格加说明的形式把实操中最高频的问题列出来。这些都是我在项目里真实遇到过的坑不是从文档里抄来的。现象常见原因解决思路微调后模型通用能力明显下降数据配比失衡、轮数过多、学习率过大降低epoch到1-2学习率控制在1e-4量级加入通用指令数据混合训练推理时显存溢出KV Cache没规划、并发设置过高、上下文过长先量化权重再限制max_model_len最后调并发批处理参数输出格式总是不稳定Prompt约束不够强、没用结构化输出接口改用引擎的guided_decoding功能或把格式要求写进微调数据问答效果差但不知道是不是模型问题缺少评测集全靠人工抽测提前建一份固定评测集改一次链路就重测一次用分数说话LoRA合并后模型输出乱码合并时dtype不一致、基座路径不对确认加载和保存都用同一dtype合并后先在本地跑几条case验证长文本生成越到后面越乱上下文长度超出训练窗口、位置编码外推失效使用支持长上下文的基座或开启RoPE缩放并做长文本专项评测这里我特别说一下评测集这个事。很多团队开发过程中从来不做成体系的测评全部依赖人肉看输出。一两个人看几十条结果还能接受一旦数据量上去、改动频繁人肉根本覆盖不过来。我现在的做法是建一个上百条的固定评测集包含正例、反例、边界case任何链路改动都先跑一遍评测拿分数对比再决定要不要上线。这是整个项目中性价比最高的投资之一。另一个高频坑是训练中的损失曲线。很多新手看到损失下降就觉得一切正常但损失下降很可能只是因为模型在记住训练数据。我习惯在训练中同时观察验证集如果训练损失下降而验证损失上升马上降低学习率或者提前停止。大模型微调比传统机器学习更容易过拟合这不是理论问题是实操里天天发生的事情。最后说说我个人的真实体会。做这一行久了我越来越觉得大模型技术并不玄学它就是一条分工明确、成本清晰的工程链路。预训练是重基建微调是定向改造推理是产品化最后一公里开源二次开发则是普通人切入这个领域最现实的门。别被各种榜单和噱头带偏回到自己的业务需求、算力预算和团队能力三个维度老老实实选一条路线走比追逐最热的模型有效得多。如果非要给一条建议我的建议是把评测体系建起来。无论是做微调、调推理、还是换基座评测集就是你的指南针没有它你在整条链路里都会像盲人摸象。我是Loongwise这篇如果能在某个决策点上帮到你我自己踩过的那些坑也算没白踩。