从零训练大模型完整流程：数据、预训练、SFT、DPO对齐与评估部署

1. 为什么你要读这篇一个完整的模型训练闭环是怎样的前阵子有个朋友问我网上全是三步微调大模型的教程但真正从零开始预训练一个模型到底要走完哪些流程这个问题问得很实在。今天市面上的开源模型已经多到用不完绝大多数人确实只需要微调但从零训练这四个字背后藏着整个大模型技术的核心逻辑——数据怎么配比、loss怎么收敛、对齐怎么做、模型到底怎么才算好所有这些问题的答案不在微调教程里而在完整的训练全流程里。这篇文章我不会讲那些百亿参数集群才能跑的东西而是围绕一套能落地、能复现、显存要求相对友好的完整流程展开数据准备、预训练、SFT监督微调、DPO/RLHF对齐、评估与部署。全程用实践视角写每一步都告诉你为什么这么做、不这么做会踩什么坑。适合的人群是有大模型使用经验、想理解训练原理的工程师准备在垂直领域自己训模型的算法同学以及那些手上有几块卡想折腾点真东西的技术爱好者。先说结论从零训一个模型不管规模大小核心就是五件事——数据、预训练、指令微调、偏好对齐、评估。这五件事不是流水线式的一次性通过而是一个反复循环、不断往回改的闭环。理解了这一点你去看那些大厂的技术报告比如Llama、Qwen的技术报告会突然觉得豁然开朗。2. 动手前的准备硬件、框架和成本预期2.1 硬件到底需要什么ChatGPT这样开头我们可以用几块消费级GPU跑起来网上很多教程动辄就是A100 80G集群看着就劝退。但实话实说如果你只是训练一个**十亿参数级别1B~7B**的模型单卡24G显存比如4090、3090、A5000是能启动的。72B那种大模型不在本文讨论范围属于需要有真实算力预算的团队才碰的东西。我建议的最低配置和对应场景如下显存/卡型能做什么不能做什么单卡 24G4090/3090预训练/继续预训练 1B~3BSFT 7BLoRADPO 7BLoRA全参微调 13B单卡 48GA6000/L40S全参微调 7B预训练 3B~7B需要合理batch大规模预训练双卡/四卡 24G数据并行预训练 7B序列长度可以拉长超大模型、超长序列多卡 A100/H800任意除了钱几乎没有限制这里有一个非常重要的认知显存决定你能否跑起来但真正决定预训练效果的是总计算量和数据质量。所以即便你只有一张4090训练一个1B模型只要数据好、超参数合理一样能做出一个能对话、能推理、有基本常识的可用模型。这一点后面预训练章节会详细展开。2.2 选框架HuggingFace Trainer、DeepSpeed还是Megatron常见的选择有三个HuggingFace Trainer适合单卡或小规模并行代码量最小调试方便适合快速验证想法。缺点是调度开销大特别大的模型和长序列下效率一般。DeepSpeedZeRO系列优化器非常成熟是目前开源社区的主流方案。搭配Trainer使用能实现数据并行张量并行ZeRO-3序列长度、batch size都可以撑得很高。Megatron-LMNVIDIA出品适合超大模型、超大规模集群工程复杂度非常高普通场景用不上。我的建议很简单1B~13B范围单卡或双卡用Trainer就够了四卡以上再上DeepSpeed ZeRO-2/ZeRO-3。不要一上来就整Megatron光配置分布式环境就能劝退一半人。2.3 成本估算练一个7B模型到底要花多少钱这是所有人在动手前最关心的问题。我们做一个粗略估算一个7B参数的模型每个token的前向反向计算量大约是 7B × 2前向反向× 3梯度更新 ≈ 42 GFLOPs/token这是简化值实际还要乘上一些常数。训练数据量按100B token来算一个中规中矩的7B模型一般需要200B以上这里保守点总计算量就是 42 × 100B 4.2B GFLOPs 4.2 × 10^18 FLOPs。一张A100 80G的FP16算力大约是 312 TFLOPS实际有效利用率按40%算就是125 TFLOPS左右。单卡训练时间 4.2 × 10^18 /125 × 10^12 3.36 × 10^6 秒 ≈ 39天。也就是说单张A100练100B token的7B模型需要约40天。换成4卡A100就是10天。换成4090呢4090 FP16算力约82.6 TFLOPS有效算力打四折就是33 TFLOPS单卡要跑147天四卡也要37天。这个估算告诉你两件事第一全参预训练确实贵第二想省钱就要缩小模型或缩小数据。这就是为什么我们下面会推荐小规模数据高质量清洗继续预训练的思路而不是一上来就冲大语料。3. 数据工程预训练的数据质量和规模决定模型的地基3.1 数据从哪来开源数据集和自采数据的分工预训练模型的知识和语言能力几乎全部来自数据。大厂的预训练语料动辄几TB但普通人不可能也没必要走这条路。如果你的目标是垂直领域法律、医疗、代码、金融等或者想要一个通用对话模型主流的做法是用开源通用数据打底叠加自己的领域数据做增补。常见的开源数据源RedPajama一个开源复刻Llama训练数据的项目包含CommonCrawl、Wikipedia、Books、Arxiv、StackExchange等子集质量整体不错但需要自己清洗和去重。The Pile一个800GB左右的学术向混合数据集代码、论文、书籍都有做基础预训练很好用。中文语料可以找开源的清洗后中文数据比如WuDaoCorpora悟道、CLUECorpus或者自己从CommonCrawl抓取中文子集后清洗。代码数据GitHub代码数据可以去下载公开镜像或者用BigQuery上的公共GitHub数据需要自己的tokenizer处理。这里要特别提醒一下开源数据不等于干净数据。CommonCrawl里大量重复页面、垃圾内容、乱码、广告文本如果不过滤模型会学到非常离谱的语言怪癖。我在实际处理中清洗流程一般是语言识别过滤只保留目标语言。URL黑名单过滤剔除成人、营销、低质UGC站点。页面去重SimHash/MinHash重复率高于0.8的直接丢弃。文档质量打分用质量分类器或者规则长度、标点比例、乱码比例等。去除模板化文本如阅读全文发布时间等。这套清洗流程本身就是一个不小的工程好在很多步骤可以用现成工具比如fasttext做语言识别datasketch做MinHash去重核心思路是宁可丢不可脏。3.2 数据配比不是数据多就好比例要对预训练数据配比是很多人容易忽略但极其影响效果的点。不同来源的数据对模型的能力贡献完全不同数据类型作用常见配比网页文本/通用文本语言能力、常识60%~70%书籍/长文档长文本建模、逻辑能力10%~15%代码逻辑推理、结构化表达10%~20%数学/科学推理能力3%~5%对话/指令数据对话能力通常放少量SFT阶段才放大0~2%配比的核心逻辑是通用文本提供语言基础代码和书籍提供推理和深度垂直数据决定模型的专业浓度。比例失调会导致模型偏科。这里有个真实教训我见过一个团队预训练数据里加了30%的对话数据结果模型虽然很会聊天但常识问答和推理明显退化。原因很简单对话数据大多是短文本信息量低模型在短文本上打转长程依赖和深度语义学得不够。所以预训练阶段的对话数据一定是少量点缀真正的主力是长短混合的说明书、文章、代码这类信息密度高的文本。3.3 Tokenizer训练一个被低估的环节Tokenizer是模型理解语言的切词器它的好坏直接影响模型的参数量、训练速度和最终效果。BPEByte Pair Encoding是目前的主流方案Llama、Qwen用的都是BPE或其变体。自定义tokenizer训练时要注意词表大小一般建议 32K~128K。太小则每个词要用多个token表示模型seq len浪费推理速度也受影响太大则embedding层参数暴增词表128K时embedding就占5120×128K6.5亿参数对7B模型来说占比很夸张。中文场景建议 64K 起步英文场景32K通常够用。词表必须有足够的中文字覆盖如果直接用Llama的词表来支持中文中文字符会被拆成多个字节token导致训练效率低效果也不行。这也是为什么Llama原版对中文不友好的根因。训练数据要多样Tokenizer训练语料应该覆盖你所有的数据来源否则预训练时会出现大量未登录字符被切碎的情况。Tokenizer训练推荐用tokenizers库的BpeTrainer代码很简单这里给一个示例from tokenizers import Tokenizer, models, trainers, pre_tokenizers tokenizer Tokenizer(models.BPE()) tokenizer.pre_tokenizer pre_tokenizers.ByteLevel(add_prefix_spaceFalse) trainer trainers.BpeTrainer( vocab_size64000, min_frequency2, special_tokens[unk, s, /s, pad] ) files [data/part1.txt, data/part2.txt] # 训练语料路径 tokenizer.train(files, trainer) tokenizer.save(tokenizer.json)训练完后务必检查 tokenizer 对中文、代码缩进、特殊符号的切分情况。一个检查技巧把一段中文和一段代码分别encode看看切出来的token数量是否合理。如果我们被切成3个token说明词表训练语料的中文占比太低需要补充。3.4 预训练数据制备的完整流程参考我自己读公司的预训练数据pipeline时会按这个顺序操作你可以直接照搬收集原始数据统一格式jsonl每行一个文档。跑语言识别和质量过滤脚本剔除低质数据。MinHash去重保留一个重复簇的中心。做文档级长度过滤过短的文档直接丢弃过长的做截断。混合配比抽样打乱生成训练集。训练tokenizer将文本tokenize成id并保存为二进制文件如mmap格式方便训练时随机采样。留出1%~2%数据作为验证集用于观察loss收敛。这个过程看起来繁琐但预训练的成败60%取决于数据值得花时间。我认识的很多开源模型作者最后悔的都是当初没有在数据清洗上多花时间而在模型结构上反复折腾。4. 预训练实操从随机权重到懂语言的核心步骤4.1 模型的初始化和基础结构选择对大多数从零训练的人来说不建议自己设计新的模型结构。主流的做法是用Llama架构现在有大量开源实现或者直接用transformers库的LlamaForCausalLM。也可以从已有的开源配置开始改参数例如从一个3B配置调成1.5B以节省时间。定义一个小模型1.3B的配置大概是这样from transformers import LlamaConfig, LlamaForCausalLM config LlamaConfig( vocab_size64000, hidden_size2048, # 隐藏层维度 intermediate_size5504, # FFN中间维度 num_hidden_layers24, # 层数 num_attention_heads16, num_key_value_heads8, # GQA推理时节省显存 max_position_embeddings8192, rope_theta1000000.0, rms_norm_eps1e-6, ) model LlamaForCausalLM(config) print(f参数量: {model.num_parameters() / 1e9:.2f}B)这里说明一个容易被忽略的细节GQA分组查询注意力很重要。它把KV cache降低到原来的1/群组数能显著减少推理时的显存占用和带宽压力。如果完全没有KV cache的限制MHA多头注意力也行但小模型部署更推荐GQA。4.2 预训练的超参数这组参数可以无脑起步预训练和一个好的微调在超参数上有本质区别。微调通常用很小学习率1e-5级别预训练需要相对大的学习率同时配合warmup和余弦退火。一句话推荐配置以1B模型、24G单卡为例参数值说明batch size32动态累积梯度更新时的有效batch序列长度2048/4096短序列起步稳定后再加长学习率3e-41B模型常用范围warmup steps1000~2000防止初期发散学习率调度cosine decay退火到峰值的1/10优化器AdamWbeta10.9, beta20.95weight decay0.1常见设置grad clip1.0防止梯度爆炸用 Trainer DeepSpeed 的配置示例training_args TrainingArguments( output_dir./checkpoints, per_device_train_batch_size2, gradient_accumulation_steps16, learning_rate3e-4, warmup_steps1000, lr_scheduler_typecosine, logging_steps10, save_steps1000, num_train_epochs1, fp16True, deepspeedds_config.json, ) trainer Trainer( modelmodel, argstraining_args, train_datasettrain_dataset, eval_dataseteval_dataset, )这里有个大坑要特别提醒batch size 和梯度累积这两个参数很多人会配错。Trainer里的batch_size2和gradient_accumulation_steps16等价于每次真实权重更新看到了2×1632条样本但这两者不是完全等价的——梯度累积会让权重更新的粒度和BN等操作出错好在Transformer里没有BN这个影响可以忽略。真正的坑是梯度累积过多会导致模型看起来在学实际上每一步的梯度信号都是很久以前的所以累积步数建议控制在32以内。4.3 判断预训练是否正常loss曲线和下游任务的早期信号很多新手盯着loss曲线看到loss下降就开心看到波动就慌。实际上预训练的loss曲线有几类典型形态需要区分对待健康形态loss平稳下降验证loss和训练loss差距不大差距大说明过拟合但在预训练阶段不太常见。loss spike某个step loss突然冲到天际通常是数据里有脏样本比如某个文档全是特殊字符或者学习率过大。处理方式先减小学习率再检查该step附近的batch数据。loss停滞训练了十几个steploss几乎不动。大概率是学习率太低、warmup太长或者数据本身有问题比如全部是相同文本。loss上升不回落典型的学习率过大导致的崩溃需要降低学习率并恢复到早期checkpoint。除了loss建议同时看一个额外指标token-wise accuracy即模型预测下一个token的准确率。这个指标比loss更直观例如准确率从0%爬到30%说明模型在真实学习如果准确率一直在个位数徘徊即使loss在下降也需要警惕数据质量。另外预训练早期百万token内可以做一个小实验给模型一段文本看它生成的句子是否语法通顺。判断标准很简单——如果一眼看不出来是乱码说明语言能力已经起来了。这个人眼早期评估效率很高建议每个checkpoint都做一次。4.4 继续预训练 vs 从头预训练小规模领域模型的最优解聊完从头训练我想特别推荐一条低成本曲线救国的路线继续预训练Continue Pretraining。思路很简单不从头初始化随机权重而是从一个高质量的开源基座模型出发比如Qwen2.5-1.5B、Llama-3.2-1B用你的领域语料继续做因果语言建模训练。这样你的模型在通用语言能力上不用从头学只需要消化领域知识即可。继续预训练和从头预训练的区别对比项从头预训练继续预训练数据量需求需要百B级通常1B~10B token即可见效算力成本极高约为前者的1/10~1/100通用能力来源完全靠数据积累继承基座模型适合场景研究、构建全新模型垂直领域、企业私有化模型我在实际项目中大部分从零训练的项目其实都是继续预训练路线性价比高得多。具体做法和从头预训练几乎一样只是学习率要调低一些1e-4~2e-4warmup steps数也需要增加因为新领域分布和原有分布差异大需要更长的适应期。5. SFT监督微调把会续写变成会听话5.1 为什么需要SFT预训练模型只会续写不会对话预训练结束的模型本质上是一个高级版输入法——你给它一段文本它只会按照统计规律继续写但不会回答问题或遵循指令。SFT就是通过人工标注/蒸馏的高质量指令数据教模型学会用户说什么我做什么这个映射。这样说可能更直观预训练模型的概率分布是给定上文预测下文SFT模型的条件分布是给定指令生成正确回答。两者的训练目标看似一样都是next token prediction但数据形态决定了行为差异。SFT数据的每条样本都是指令回答对模型在大量这样的数据上学到的就不再是续写而是服从与回应。5.2 SFT数据质量、数量和多样性SFT数据是决定模型聪明不聪明的关键也是目前社区公认最稀缺的资源。对于数据量通用对话能力5万~20万条高质量指令可以做出不错的对话模型。垂直领域能力1万~5万条领域指令就能看到明显效果。不需要海量数据SFT数据量一旦超过百万往往边际效应递减甚至引入噪声。数据多样性比数量更重要。一个典型的SFT数据集应覆盖通用问答常识、百科、生活写作与创作写文章、写邮件、改写推理与逻辑数学题、逻辑推断代码与工具使用角色扮演与多轮对话拒绝回答对于有害问题的适当拒绝构造指令数据时有一个关键技巧避免一句话指令。真实用户的问题往往是长句、多轮、有语病的如果在训练数据里全是讲个笑话解释量子力学模型应用时遇到真实用户的长尾query就会崩。所以我会故意在数据集里混入带噪声的、口语化的、有干扰词的指令让模型学会处理真实场景。5.3 SFT训练全参微调 vs LoRA全参微调Full Fine-tuning会更新模型所有参数效果上限最高但显存和成本都高。LoRALow-Rank Adaptation只在原模型旁路训练一小组低秩矩阵显存占用小、训练快效果在大多数场景下已经非常接近全参微调。对比项全参微调LoRA显存需求7B需~56G需~24G即可训练速度慢快效果上限理论更高接近rank够大时几乎无差爆炸风险数据差时灾难性遗忘风险更大可控适合场景高质量大规模数据、终极版本快速迭代、单卡资源、领域微调我的做法是前几轮探索用LoRA确定数据质量满意后再全参微调一版作为主力。LoRA的rank一般选16~64过大没有意义过小则容量不够。LoRA微调代码使用PEFT库大概是这样from peft import LoraConfig, get_peft_model, TaskType lora_config LoraConfig( task_typeTaskType.CAUSAL_LM, r32, lora_alpha64, target_modules[q_proj, k_proj, v_proj, o_proj, gate_proj, up_proj, down_proj], lora_dropout0.05, ) model get_peft_model(model, lora_config)target_modules建议覆盖所有attention和FFN的投影层效果比只挂attention层好。lora_alpha一般是r的2倍太小更新幅度小太大容易训练不稳定。5.4 SFT的过拟合如何判断背下来了而不是学会了SFT阶段最大的陷阱是过拟合模型在训练数据上表现完美但一到真实场景就抓瞎。判断标准很简单训练loss持续下降但验证集loss回升——过拟合信号。对训练集里的某些指令能逐字背诵式输出但对同义改写的指令就懵——过拟合信号。模型输出变短、趋同、模板化——过拟合信号。控制过拟合的方法数据增强对指令做同义改写、随机插入无义词、改变标点等。提高数据多样性同一种能力用100种不同的问法。早停监控验证集loss一旦回升立即停止。降低LoRA rank如果用的是LoRArank过大更容易过拟合。增大dropoutLoRA的dropout提到0.1会显著提升泛化能力。我自己的经验是SFT阶段模型的能力上限更多由数据决定而不是由训练步数决定。训10遍同一批高质量数据不如训1遍一万条多样化的数据。那些多训几个epoch效果更好的说法在SFT这种小数据场景下通常是过拟合的温床我基本只用1~2个epoch。6. DPO与RLHF偏好对齐让模型说出人更爱听的话6.1 SFT解决能不能RLHF/DPO解决好不好SFT之后模型已经会说话了但回答的质量参差不齐有的啰嗦、有的傲慢、有的编造事实、有的违反安全规则。偏好对齐阶段就是要让模型学会哪些回答更好、哪些回答要拒绝。传统RLHF的流程是训练一个奖励模型Reward Model给单条回答打分。用强化学习PPO优化策略模型最大化奖励模型分数。但PPO的工程复杂度很高——需要同时加载4个模型Actor、Critic、Reward、Reference训练稳定性差超参数极其敏感。这也是为什么很多开源项目都在往DPO迁移。6.2 DPO核心原理把对齐变成一个简单的分类问题DPODirect Preference Optimization是2023年提出的方法核心洞察非常漂亮我们不需要显式地训练一个奖励模型也不需要跑PPO循环直接用一个偏好数据集chosen vs rejected用类似排序损失的方式更新策略模型即可。DPO的损失函数本质上是最大化好回答相对坏回答的似然差L - log σ(β * (log(p_θ(y_chosen|x) / p_ref(y_chosen|x)) - log(p_θ(y_rejected|x) / p_ref(y_rejected|x))))直观理解它试图让模型增大好回答的概率、减小坏回答的概率同时用reference modelSFT模型拉住不让模型飘得太远。DPO的实现非常简单TRL库直接支持from trl import DPOTrainer, DPOConfig training_args DPOConfig( output_dir./dpo_checkpoints, beta0.1, # 温度系数越大越强调偏好越小越贴近参考模型 per_device_train_batch_size2, learning_rate1e-6, max_length2048, max_prompt_length1024, ) dpo_trainer DPOTrainer( modelmodel, # SFT后的模型 ref_modelref_model, # SFT后的原始权重冻结 argstraining_args, train_datasetpreference_dataset, )6.3 DPO数据构造从哪收集偏好数据DPO的效果几乎完全取决于偏好数据质量。常见的数据来源人工标注让标注员对比两个模型回答选更好的。质量最高成本也最高。模型蒸馏用GPT-4/Claude等顶级API生成回答作为chosen自己的模型回答作为rejected。成本低但会向闭源模型看齐。规则/社区反馈从社区问答中提取高质量回答和低质量回答比如采纳答案 vs 未采纳答案。构造偏好数据时的注意点chosen和rejected差异要明确如果两个回答水平相当模型很难学到有效的偏好信号。宁可去掉这些样本。覆盖维度要多元偏好不只是答案正不正确还包括有没有礼貌、有没有过度推理、有没有编造细节、有没有偏离问题。比例控制在1%~10%DPO数据量不需要大通常几千到几万条就能起效。过多反而可能导致模型在某个偏好维度上过于激进。6.4 什么时候该用PPO而不是DPODPO确实省事但有它的天花板。PPO在某些场景仍然不可替代场景DPOPPO数据预算小/标注困难合适需要大量RM反馈创新性任务需要探索较弱强多目标优化安全vs有用需人工造数据可以通过RM权重调节工程复杂度低高训练稳定性较稳定高度依赖超参我的建议99%的垂直领域对齐用DPO就够了。只有当你需要精细控制模型在边界情况上怎么做比如内容安全策略、复杂产品规则才值得上PPO。PPO的RLHF从搭建到稳定没有两周时间下不来且对工程师的RL功底有要求。7. 评估体系模型好不好不能只靠感觉7.1 评估的三个层次自动指标、基准测试、人类评估模型训练完所有人都会问一句效果怎么样但怎么样必须拆成可验证的问题。我的评估框架分三层第一层自动指标Perplexity困惑度衡量语言模型对文本的建模能力越低越好。但PPL和实际对话质量不是完全正相关只能做粗粒度监控。ROUGE/BLEU适合摘要、翻译类任务不适合开放对话。参考模型对比拿另一个更强的模型如GPT-4给回答打分是当前开源社区最流行的自动评估方式。第二层基准测试通用模型常用的有MMLU综合知识C-Eval中文综合知识GSM8K数学推理HumanEval代码生成BBH复杂推理跑这些基准测试注意两点遵循标准的few-shot设置不同prompt设置会显著影响分数。基准分数只是参考不要为了刷分专门调prompt否则就失真了。第三层人类评估这是最终标准。找5~10个人把模型输出和参考输出混在一起盲评关注点可以拆分准确性事实是否错误完整性是否回答了问题的所有方面逻辑性推理是否连贯语气与风格是否符合需求安全性是否有有害内容人类评估的评分卡可以表格化例如维度说明评分1-5事实准确性是否有幻觉/编造4指令遵循是否完全按要求执行3逻辑连贯推理是否自洽5风格适配是否符合指定风格4安全性是否包含有害内容57.2 评估集怎么建垂直领域必须自己造题通用基准测试只能验证通用能力垂直领域的模型必须自己构造评估集。构造方法从你的业务场景收集真实用户query整理成500~1000条。每条query手工构建标准答案/参考答案。再混入对抗性样本有害请求、越狱问题、边界模糊场景。评估时用LLM-as-Judge 人工抽检相结合。LLM-as-Judge的prompt可以参考你是评估助手。请根据以下标准对AI助手的回答进行打分1-5 1. 是否准确回答了用户问题 2. 是否包含无关/错误信息 3. 格式是否正确 4. 语气是否专业友好 用户问题{query} AI回答{response} 评分只输出数字和简短理由这种评估方式成本低、可复现适合在迭代过程中快速筛优。但最终版本建议人工复核至少100条因为自动评估本身有偏差。7.3 一次完整的迭代流程如何评估后反向改进评估的目的不只是打分而是定位问题。我的迭代流程是用评估集跑一轮评测把模型的bad case整理出来。对bad case归类是数据缺失还是指令理解错误还是偏好对齐不足如果是数据缺失回到SFT/预训练数据侧补充数据。如果是指令理解改进SFT数据构造和指令格式。如果是偏好/安全回到DPO阶段补充偏好数据。整套流程通常要转两三轮模型质量才会进入一个稳定期。千万不要觉得评估做完就结束了——评估结果必须反哺数据这才是大模型训练的闭环。8. 从训练到部署量化、推理加速和服务化8.1 合并LoRA权重与模型量化训练完成后第一个步骤是整合权重。如果用了LoRA需要把adapter合并回base modelfrom peft import PeftModel merged_model PeftModel.from_pretrained(base_model, path_to_lora_adapter) merged_model merged_model.merge_and_unload() merged_model.save_pretrained(merged_model)部署时如果显存或吞吐有压力做4bit量化GPTQ适合GPU部署能用AutoGPTQ库离线量化。AWQ激活感知量化效果和质量比GPTQ更好也是GPU部署。GGUF适合CPU或Apple Silicon、Ollama等工具部署。对7B模型做4bit量化后显存占用大约从14G降到5G左右很多消费级显卡都能跑推理了。8.2 推理框架选型vLLM、TGI还是OllamavLLM目前吞吐最高的推理框架支持PagedAttention适合生产环境多卡部署也方便。TGIText Generation InferenceHuggingFace出的和transformers生态兼容最好。Ollama傻瓜式本地部署工具适合个人电脑跑模型玩但不适合高并发服务。对生产场景我的建议是vLLM。启动服务很简单vllm serve ./merged_model \ --tensor-parallel-size 1 \ --gpu-memory-utilization 0.9 \ --max-model-len 8192 \ --port 8000如果你的模型是自己训练的、用的是HuggingFace格式vLLM可以直接识别非常方便。8.3 推理优化三板斧KV Cache、前缀缓存、投机解码部署之后压测吞吐每秒请求数和延迟首字延迟、总延迟如果性能不够考虑三板斧KV CachevLLM默认开启可以通过--kv-cache-dtype fp8进一步减显存。Prefix Cache针对系统提示词system prompt完全固定的场景vLLM的--enable-prefix-caching能复用前缀计算多轮对话或RAG场景吞吐能提升不少。Speculative Decoding用一个小的草稿模型先生成多个候选token大模型一次验证延迟可以下降2~3倍。vLLM已经支持配置--speculative-config即可。这些优化做完7B模型的推理通常能到 300~800 tokens/s单卡A100级别这是一个可以接受的生产性能。9. 全流程复盘与写在最后的体会整套流程走下来最大的感受是大模型训练不是单一技术问题而是数据工程、算法理解、工程能力的综合较量。给我留下最深印象的一件小事发生在做DPO的时候。第一次跑DPO我用了一套2000条的高质量偏好数据beta设成0.5结果训练后模型回答变得过度回避——连简单的常识问题都开始作为AI我不能…这样回复。后来把beta降到0.1重新训练效果立马正常了。这件事让我明白偏好对齐的调节旋钮非常敏感一个参数不对模型行为可能从一个极端跳到另一个极端。所以做DPO一定要有小批量实验的流程先用小数据、小beta反复试确定了再放大规模。如果是个人玩家我最后的建议是不要轻易尝试真的从随机权重开始训一个上亿参数的模型。即便你有一张4090从头训一个1B模型光是让loss下降到能看的水平就需要数周时间。做个100M~300M的小模型练手把全流程跑通然后在真实业务里用继续预训练LoRASFTDPO的路径来生产模型这个性价比是最高的。路线可以这样规划先用一个小数据集比如几千万token训练一个小模型100M~300M熟悉整个pipeline。再拿一个开源基座模型Qwen/Llama 1B~7B做继续预训练、SFT、DPO。每训练一版都要有定量的评估报告知道瓶颈在哪反哺下一轮。这样下来两三个月你就能拥有一套完整的、可以复用的自己训模型的能力。这个能力比任何单一模型都值钱。