大模型全链路实战：从预训练、微调到推理与二次开发

早几年我带团队做 AI 项目第一个问题通常是这个需求要不要用深度学习模型现在反过来了需求文档里动不动就是接一个大模型。大模型预训练、微调、推理、开源二次开发这四个词已经快被聊烂了但真正动过手的人都知道从一张 Hugging Face 权重到业务真正跑起来中间的路线远比想象中复杂。这几年我围绕一套自己沉淀的技术路线做全链路落地代码、配置、踩坑记录都收在 Loongwise 这个集合里。这篇就是把这些年的经验按预训练、微调、推理、开源二次开发四个阶段拆开讲清楚每一步为什么这么设计、实际怎么做、边界划在哪。适合刚准备接触大模型的工程师、正在选型的团队决策者也适合想从 API 调用往自主微调迈一步的算法同学。1. 预训练原理你未必需要复现但必须读懂1.1 数据工程预训练的天花板不在模型结构很多人以为预训练就是写个 Transformer 然后海量喂数据这是最常见的误解。模型结构这几年已经高度同质化基本逃不开 LayerNorm、GELU 或者 SwiGLU、Rotary Embedding、GQA 这些组件。真正让一个预训练权重好用还是难用的大部分取决于数据和训练策略。数据工程里第一关是清洗。从 Common Crawl 这类公开语料拿到原始网页后要做的不是简单删标签而是做语言判别、乱码过滤、敏感信息过滤、重复片段去重、低质量页面剔除。比如中文语料中有一大段英文大量无意义符号重复这些如果不处理模型会在隐层里学到一堆噪声。做预训练数据时我的经验是宁缺毋滥。喂 1000 万条低质量数据效果往往不如喂 200 万条高质量清洗数据。第二关是配比。通用大模型的语料里一般会混合网页文本、百科、书籍、代码、论文、对话数据。比例上代码和数学类数据能显著提升模型的逻辑推理能力但占比太高又会拉低自然语言流畅度。我和团队常用的配比大概是普通网页 60%、代码 20%、书籍论文 10%、对话数据 10%然后按 domain 做概率采样而不是简单拼接。多语言场景还要分语种配比中文和英文的比例需要根据实际应用场景调。第三关是 tokenization。中文词的切分方式直接决定了训练效率。拿 7B 模型说词表大小设在 3 万到 10 万之间比较常见。词表太小句子会被切成很长的 token 序列训练和推理都慢词表太大嵌入层参数占比高显存和存储压力变大。如果想做垂直领域预训练比如医疗、法律先拿领域语料统计高频词汇再看现有模型 tokenizer 有没有覆盖不够就扩词表重新训练 embedding。这里我吃过亏直接拿通用 tokenizer 去训医疗语料很多专业缩写被切成碎片模型根本学不到稳定语义。预训练数据量也有一个粗颗粒参考。OpenAI 在 Chinchilla 论文里提出训练 token 数约为模型参数量的 20 倍。也就是说7B 模型理想数据量大概在 140B token 左右。当然这是针对通用训练语境的估算领域模型、大模型后继续训练都可以适当减少。可如果网络资料里有人告诉你用 1B token 训个 7B 模型也够了别信那不是预训练顶多算热启动。1.2 训练策略与算力估算动手之前先算账预训练任务一般会用 AdamW 优化器配合 warmup 和余弦衰减。warmup 的作用是让模型在初期不要因为 lr 太大而震荡通常设成总步数的 1% 到 3%。学习率峰值大概在 3e-4 到 1e-3 这个区间7B 量级模型常用 max lr 3e-4。batch size 用 token 数而不是样本条数来度量单 step 的总 token 数一般在 0.5M 到 4M。并行训练上现在主流是 DeepSpeed ZeRO 或者 FSDP。ZeRO Stage 1 切优化器状态Stage 2 再切梯度Stage 3 连模型参数也切。对 7B 来说单机多卡用 ZeRO Stage 2 往往就够如果是 70B 或者更大直接 Stage 3配合 activation checkpointing显存才扛得住。混合精度训练基本是标配bf16 比 fp16 稳得多loss 不会轻易溢出。叠个梯度累积数据并行 张量并行是大部分中小团队的预训练基座。算力账更要提前算。训练一个模型的总计算量大约等于 6 乘模型参数量乘训练 token 数。比如 7B 参数、140B token总计算量大概是 6 * 7e9 * 1.4e11约 5.88e21 FLOPs。假设用 A100 80GBF16 实际吞吐折中按 120 TFLOPS 算一块卡跑完大约要 5.88e21 / 1.2e14大约是 4.9 万秒也就是 567 天。如果租 128 卡并行还需要考虑通信损耗理想情况缩到 5 天以内。这个账一算就明白非必要别从零预训练大模型。如果你不是死磕底座研究我更建议把预训练理解为学会使用别人的预训练权重。业内每天都有新的高质量开源模型发布尤其是中文模型已经非常能打。真正有价值的动作是继续预训练在通用权重基础上拿领域语料再训一段时间让模型更适应行业措辞。这种做法计算量只要预训练的 1/10 甚至更少但对领域术语的理解提升很明显。1.3 预训练权重怎么选Base 和 Chat 别搞混开源社区能拿到的预训练权重一般分两类base model 和 chat model。base model 只做过预训练没有经过指令微调和人类偏好对齐特点是续写能力强但不会好好听话直接对话会问一句答一句还要用户自己接话。chat model 后面做了 SFT 和 RLHF 或者 DPO更像一个助手。选型原则我总结三点。第一需要自己定制对话风格和领域语料选 base model因为即使再对齐微调数据也会覆盖之前的风格。第二追求开箱即用、快速做产品原型选 chat model尤其 Qwen、Llama 这类官方 chat 版本基础对话质量已经很高。第三做 agent 或工具调用类场景优先看模型在 function calling 上的原生能力比如 GLM 系列、Qwen 系列对 tool call 支持都比较好。还有一个细节同一个家族里版本号差异可能比想象中大。微调之前先跑通一批评测题目比如数学、代码、中文常识、指令跟随确认这个底座在你目标场景的 baseline 是多少。我见过不少团队跳过评测直接微调结果效果差还找不到原因最后发现是底座没选对。2. 微调把通用底座变成业务专员2.1 全量微调、LoRA、QLoRA先分清要用哪一种微调的目标是让模型跟着业务走。如果你只有几千条高质量业务问答又想快速验证效果用 LoRA 基本就够了。LoRA 的原理是冻结原模型参数只训练注入的低秩矩阵。以 rank16 为例总参数量通常只增加 1% 左右显存压力小训练速度快还能方便地同时保留多条微调分支切换任务时换 LoRA 权重即可。全量微调不是不能用而是成本高、收敛难。它会把基座里学到的通用知识全部重新洗一遍数据量不够就会灾难性遗忘。有一次我把开源 chat 模型拿 2000 条客服语料做全量微调结果模型变得只会用客服腔说话让它解释常识也满嘴亲请问有什么可以帮您。后来切成 LoRA效果反而更稳因为基座知识被保留住了。全量微调更适合定制新语言、换注意力结构或者做深度领域适配而这些场景普通团队很少碰。QLoRA 是在 LoRA 基础上把基座权重进一步压缩成 4bit 或 8bit再从量化权重上反向传播。这能让你在 24G 显存里微调 7B 模型甚至在消费级显卡上跑起来。量化带来的精度损失对大多数对话任务影响不明显。我实测下来QLoRA 训出的模型和 LoRA 训出的模型在评测集上差距通常在 1 分以内。所以显存不够就大胆用 QLoRA。2.2 数据处理与指令模板微调的大头其实是数据微调成功与否80% 靠数据20% 靠超参。数据格式可以统一成 ChatML 或者 Alpaca 指令模板。核心就一句话分隔符稳定角色清楚输入输出严格对应。我常用 JSONL 格式{messages: [{role: system, content: 你是智能客服助手。}, {role: user, content: 订单超过三天没发货怎么办}, {role: assistant, content: 请您先确认订单状态我帮您查一下物流。}]}构造数据的时候有几个容易翻车的点。第一答案里不能包含太多系统 Prompt 才能知道的信息否则模型强依赖 prompt推理时不给系统提示就乱说。第二同一批数据要避免完全相同的模板句式多样性比数量更关键。第三模型输出如果过长把单轮数据控制在模型最大长度的一半以内给系统提示和未来拼接留余量。数据量和效果的关系不是线性增长。我观察到500 条干净样本往往就能让模型在某个固定任务上明显变规矩2000 到 5000 条能把风格稳定下来真正做到复杂任务泛化通常需要 2 万条以上。为了守住通用能力我习惯在微调数据里混 10% 到 20% 的通用指令数据比如让模型解释概念、做摘要避免全量数据都押在单一业务上导致的灾难性遗忘。2.3 一套可以直接参考的 LoRA 实操配置假如你要微调一个 7B 模型用 transformers 和 PEFT 框架可以参考下面这套配置。from peft import LoraConfig, get_peft_model, prepare_model_for_kbit_training from transformers import AutoTokenizer, AutoModelForCausalLM model_id Qwen/Qwen2.5-7B-Instruct model AutoModelForCausalLM.from_pretrained(model_id, torch_dtypeauto, device_mapauto) tokenizer AutoTokenizer.from_pretrained(model_id) lora_config LoraConfig( r16, lora_alpha32, target_modules[q_proj, k_proj, v_proj, o_proj, gate_proj, up_proj, down_proj], lora_dropout0.05, biasnone, task_typeCAUSAL_LM, ) model get_peft_model(model, lora_config)训练超参上我常用的组合是学习率 2e-4batch size 4梯度累积 8 步epoch 3 到 5最大序列长度 2048。warmup ratio 设 0.03lr schedule 用 cosine。如果你的数据特别长可以把 max length 拉长到 4096但 batch 要相应调小否则 OOM 是早晚的事。target_modules 这个参数很多人默认只调 q_proj 和 v_proj但我建议把 gate_proj、up_proj、down_proj 也加上。实测多头注意力加 MLP 一起微调模型能记住更多业务细节收敛也更快。r 值不要盲目加到 64 以上rank 太高训练变慢还有可能过拟合。一般 r16、alpha32 是个甜点区。训练完成后Adafactor 或者 AdamW 都行。保存时仅保存 adapter 权重一个 LoRA 文件通常只有几十 MB部署和版本管理都很方便。我自己的习惯是每个微调任务保留一份基础数据快照、一份训练 log、一份 adapter 文件回滚成本很低。2.4 偏好对齐SFT 之后的质量提升空间SFT 让模型学会模仿但没法让模型对同一问题做出更好和更差的判断。这时候需要偏好优化。比较轻量的做法是 DPO不需要训练奖励模型只需要准备被选回答和被拒回答的数据对。实操中我一般这样组织 DPO 数据给同一条用户问题收集模型生成的多个回答人工挑一个最好和一个最差。配对数量 3000 到 10000 对就能看到显著效果。DPO 训练时学习率要比 SFT 更低一般 1e-5 到 5e-5epoch 1 到 2不然模型容易说过头生成风格变得刻意讨好。偏好优化最适合用在内容安全、语气控制、格式遵循这类场景。比如想让客服模型不再长篇大论放弃官方废话就可以在 DPO 里把简洁准确回答设为 chosen把冗长套话设为 rejected。这个流程跑通之后你会发现 SFT 负责打开能力DPO 负责收敛风格两者互补。3. 推理与部署从能聊天到能扛流量3.1 推理引擎怎么选别被生态绑架模型训练完接下来要面对的是推理。同一个模型用不同推理引擎部署吞吐和延迟可以差出好几倍。选型没有标准答案主要看你的硬件、并发和延迟要求。vLLM上手最稳生态最成熟支持 PagedAttention 和 continuous batchingOpenAI 兼容 API 开箱即用。绝大多数中小团队首选。SGLang在后端做了很多调度优化多轮对话场景下吞吐表现很好适合长上下文和复杂 prompt。TensorRT-LLM英伟达全家桶优化路线适合单机多卡、极致吞吐和低延迟但算子编译和模型转换的复杂度偏高。llama.cpp纯 CPU 和 Mac 场景很实用量化后普通笔记本和 NAS 也能跑出可用速度。Ollama更偏个人和私有化体验一条命令拉模型但对高并发服务化支持弱适合做内网测试和轻量使用。我的建议是上线前先用 vLLM 包一层确保功能稳定再用 SGLang 或者 TensorRT-LLM 做压测别一开始就上重型优化。部署服务不是写论文稳定和可回滚优先。模型量化也是推理绕不开的环节。我常用 AWQ 和 GPTQ4bit 量化在 7B 模型上的显存占用直接降到 5G 到 6G 左右大部分消费级显卡都能跑。FP8 量化在 H 系列显卡上效果更平衡。如果你对精度极其敏感可以先跑 16bit在 KV cache 上做优化。3.2 vLLM 部署示例与关键参数假设你已经把一个 7B chat 模型微调完需要把它包装成对业务侧可用的 API。最简单的方式是用 vLLM 拉起一个 OpenAI 兼容的服务。vllm serve Qwen/Qwen2.5-7B-Instruct \ --served-model-name my-lora-model \ --tensor-parallel-size 1 \ --gpu-memory-utilization 0.9 \ --max-model-len 8192 \ --quantization awq \ --port 8000这几个参数背后分别代表什么我拆一下。tensor-parallel-size表示用几块卡切分模型7B 模型单卡能装下就设 1多卡要考虑通信损耗。gpu-memory-utilization表示给模型预留多少显存0.9 是给 KV cache 留下充分空间又不会因为预留太少导致 OOM。max-model-len是模型最大上下文长度开太大会把显存全吃进 KV cache 分配开太小则长文档任务被截断。quantization指定量化方式如果用白嫖的 base 16bit 就不加这个参数。服务起来后用 curl 测试curl http://localhost:8000/v1/chat/completions \ -H Content-Type: application/json \ -d {model: my-lora-model, messages: [{role: user, content: 你好}]}如果返回正常业务方就可以按 OpenAI SDK 的方式接入。这也是我强烈推荐的做法外部系统只认 OpenAI 协议内部随便换引擎和模型业务代码不用动。团队可以把 Dify、LangChain、FastGPT 全部接上同一套网关。3.3 上下文长度、KV Cache 与吞吐优化部署时的显存大头不全是模型权重KV Cache 才是吃显存的大户。每一条请求都会生成一组 Key 和 Value 缓存。上下文越长、并发越高KV Cache 占用越大。直观来说一个 7B 模型权重可能只占 14G 显存但开 32 并发、每个请求 4K 上下文后KV Cache 能吃掉另外 20G。怎么优化第一开启 continuous batching让多条请求在同一个 batch 里动态加入和退出比静态 batch 吞吐高很多。vLLM 默认就是 continuous batching这也是它比 naive transformers 快几倍的关键。第二用 PagedAttention 或类似机制管理 KV Cache像操作系统的虚拟内存一样按页分配减少碎片。第三尽量限制 max-model-len不要为了万一遇到长文本给所有请求都拉满长度。很多上线事故都是长上下文并发把显存撑爆。流式输出也很重要。大模型生成首字前有一个 prefill 阶段预填充过程耗时占比很大。现在很多引擎支持 prefill 和 decode 分离把用户长 prompt 预先处理完生成阶段再快速吐字。做产品时用户感知的延迟通常是首 token 时间而不是总生成时间。所以如果你的场景是聊天机器人务必开流式让用户先看到第一个字在动体验会好很多。3.4 私有化部署一台机器也能跑起来的组合拳很多企业问我大模型能不能完全私有化不依赖互联网可以。一台 4090 或者 Mac Studio 就能起步。组合拳我推荐 Ollama 加上 Dify。Ollama 负责拉起模型它支持从 GGUF 到 Qwen、Llama 一堆模型格式内置量化配置。装好之后一条命令就能跑起来。Dify 负责应用编排把对话、知识库、工作流都拖拽出来。两个服务都在本地数据不出内网非常适合做企业知识库问答。具体路径是这样的先用 Ollama 拉一个 7B 或 13B 的量化模型起个本地服务然后在 Dify 里把模型接入 Base URL 指向本地 Ollama再上传企业文档切分后写入向量数据库最后配置一个检索增强生成流程用户问题时先向量检索再把检索片段和问题一起交给大模型回答。这套方案单卡 24G 显存完全能跑部署时间一天以内。这里要特别提一嘴工业检测、服装检测这类场景。很多人问这类 AI 是不是也要用大模型我的答案通常是否定的。工业瑕疵检测、服装细粒度分类本质上是视觉小目标识别和高频缺陷识别核心诉求是准、快、稳定。传统 CNN 目标检测模型或者轻量视觉 Transformer 在这类任务上成本低、延迟低、可解释性强也更容易过产线验收。大模型更适合做这些系统的辅助大脑比如把检测结果汇总成自然语言报告再生成维修建议。4. 开源二次开发与应用边界能做、该做与别碰的4.1 读懂模型授权协议再动手开源大模型并不是随意商用四个字就完事。不同模型的许可证差别很大一旦忽略可能后面被法律风险打得措手不及。我在选型时至少会看三点。第一模型权重有没有明确允许商用。MIT 和 Apache 2.0 一般最宽松有些模型许可证会附加使用限制比如月活用户超过一定数量要申请授权或者禁止用于某些领域。第二再发布时要不要保留版权声明和协议文本。Apache 2.0 要求保留版权声明如果你把 LoRA 权重发布到社区通常还要注明底座模型来源。第三衍生作品的授权方式。有些协议要求你的衍生模型同样开放如果你的产品不想开源核心模型文件就得特别注意。我给团队定的流程每引入一个新模型都会先拉出授权协议全文重点段落标注出来让法务过一遍。这一步看着麻烦其实是在给整个产品上保险。开源社区也有各种模型 License 对比表但还是要回到源头看原始文本。4.2 二次开发的常见形态微调、私有化、RAG 与 Agent开源二次开发的大方向就四条微调、私有化部署、RAG、Agent 工具调用。微调负责性格RAG 负责知识Agent 负责行动。整套链路我推荐从 RAG 起步原因很简单RAG 不改模型只把外部数据切成片段、检索、塞进上下文。这样企业文档更新不需要重新训练成本低效果立竿见影。一旦 RAG 不能满足需求比如模型无法遵循复杂的业务规则再考虑微调叠加。Agent 是现在的热点但也最容易翻车。让大模型去调用企业内部 API、操作数据库本质是把决策权交给模型。这非常依赖模型的指令理解和结果鲁棒性。做 Agent 项目我有个原则先用小范围、低风险权限试探所有关键操作加人工确认还要把模型输出解析成结构化参数避免直接让模型执行原生脚本。私有化部署和云端 API 怎么取舍我自己的判定标准是看数据敏感性和调用频次。如果业务数据涉密、客户要求不出内网那就私有化部署。如果只是通用知识问答和内容生成直接用免费或低价的模型 API 更经济。需要注意的是私有化不等于防火墙里随便跑一样要做模型输入输出过滤、日志脱敏和权限隔离。4.3 应用边界别把大模型当万能药大模型适合做哪些事内容生成、多轮对话、信息抽取、知识问答、代码生成、语音与文本摘要这些场景模型能力很强技术边界比较清楚。不适合做哪些事我列几个典型反面需要精确实数的计算任务大模型经常算错需要毫秒级响应的嵌入式控制模型延迟扛不住需要强规则约束的流程审批模型输出不可控需要小目标高精度检测的视觉任务模型的成本性价比远不如专用小模型。还有一点大模型天然会幻觉任何需要绝对准确且无法校验输出的场景都不能让模型直接面向最终用户。理解边界的关键是算账。一个云端大模型 API 调用次数多起来费用增长极快本地私有化部署要买卡、养育维机器成本和电价也是持续支出。我的建议是先用规则和传统小模型解决的问题不要为了时髦硬上大模型。大模型应该被当作一个组件而不是整个系统。4.4 硬件成本、风险清单与选型心得硬件算力预算可以参考一个简化估算。7B 模型做纯推理量化后单卡 16G 足够带 KV Cache 高并发跑服务最好 24G 起。7B LoRA 微调24G 显存可用 QLoRA48G 可以轻轻松松。13B 到 14B 模型做全量低参微调建议 24G 到 48G。70B 级别模型哪怕量化推理也要多卡 48G微调基本是 8 卡 A100 起步了。风险清单我再补充几条。数据隐私方面使用云端 API 时不要传未脱敏的身份证号、手机号模型幻觉方面所有关键决策都要有兜底校验安全注入方面用户输入可能携带恶意 prompt比如忽略以上所有规则所以系统提示要设计健壮必要时加输入输出过滤层协议合规方面发布衍生模型前反复核对许可证。选型上我个人的顺序是先明确场景是对话、抽取还是工具调用再选一个开源 chat 模型做评测数据集先做小规模微调看 loss 曲线和 badcase上线前用压测工具验并发最后再决定是继续微调还是上 RAG。Loongwise 这个技术路线的核心就是先把最小闭环跑通再逐步扩大边界而不是一开始就把架构搭得无比复杂。这套动作走下来你会发现大模型落地没有想象中玄学。预训练决定模型能力的上限微调决定它是否贴合业务推理部署决定产品能否扛住用户开源二次开发则决定了合规性和成本可控性。如果让我给一句最直接的总结别追最大参数量的模型选择任务匹配的底座小步快跑地微调认真处理数据和评测用一套干净的推理网关把它们串起来。边界不是别人画的是你自己在一次次踩坑和上线中慢慢测出来的。