这几年做大模型落地我最大的感受是训练、微调、推理这三件事虽然经常被放在一起讨论但它们的底层逻辑、工程难点和踩坑方式完全不同。很多人拿着“大模型”三个字冲进来有的卡在预训练阶段被算力劝退有的在微调环节被过拟合和灾难性遗忘折磨还有的模型明明效果不错一上线推理速度慢到没法用。这篇文章我想把这条链路完整拆一遍从预训练到底层并行策略到微调里全量、Freeze、LoRA三种方式的本质区别再到推理框架里量化、KV Cache、连续批处理这些真正决定性能的细节最后用一个Qwen模型从微调到本地部署的完整流程收尾。适合正在做大模型应用落地、准备微调自己的模型、或者被推理性能问题困扰的算法和工程同学参考。我不打算写成那种大而全的综述而是把我在实际项目中验证过的东西讲清楚为什么这么做、不这么做会出什么问题、参数怎么选、哪些地方容易翻车。这篇文章的核心就一句话——训练决定模型上限微调决定模型能不能用推理决定模型能不能真正跑起来。1. 一条链路看明白训练、微调、推理到底在干什么1.1 三者的角色分工和边界先给三个概念画一条清晰的边界。预训练Pre-training是在海量通用数据上让模型学会语言本身的基本规律——语法、常识、世界知识、逻辑推理的雏形。这个阶段的产物是一个“什么都知道一点但什么都不太听话”的基础模型比如Llama、Qwen的base版本。它的特点是通用性强、知识面广但不会很好地遵循指令也不会针对某个垂直领域有深入的表现。微调Fine-tuning是在预训练模型的基础上用更小规模、更高质量、更聚焦的数据让模型适配特定任务或特定风格。这个阶段的产物是Chat版本、行业版本或者各种垂直应用模型。比如你用客服对话语料微调模型就学会客服的口吻和业务规则用法律文书微调它就偏向法条理解和案例分析。推理Inference则完全不同。它是在模型参数已经固定的情况下把训练好的权重加载起来对输入做出预测的过程。推理阶段没有反向传播、没有梯度更新只有前向计算。也就是说训练是在“学”推理是在“用”。虽然推理不更新参数但工程上的复杂度一点都不低——内存带宽、显存容量、并发调度、时延优化每一样都能让人折腾好几天。这三者对应的计算特征差异非常大。训练是典型的计算密集型加通信密集型需要GPU大规模并行动辄几十上百张卡微调是中等规模的资源消耗单卡或几卡就能完成大部分场景推理则是延迟敏感型要面对的是每秒钟成千上万的请求考验的是吞吐量和响应速度。1.2 为什么“训练”和“推理”逻辑完全不同很多刚接触大模型的人会有一个误区以为训练和推理的区别只是“多跑几个epoch”和“少跑几个epoch”。实际上是两套完全不同的工程体系。训练阶段关心的是梯度能否稳定下降、loss能否收敛、批次大小是否合理、学习率要不要warmup。这个阶段GPU利用率可以拉得很高因为我们可以把大批次的数据塞进去反正不着急出结果等得起。训练框架的核心优化点是并行计算和梯度同步比如我们常说的ZeRO、张量并行、流水并行全都是在为“更快地完成一轮参数更新”服务。推理阶段关心的是延迟、吞吐、显存占用。这个阶段不能被延迟等于“来一个算一个”因为用户等不起。推理框架要做的事情是在不改变模型输出的前提下尽可能地“偷工减料”——比如量化把FP16变成INT8甚至INT4KV Cache把已经算过的历史结果缓存起来连续批处理让GPU在做矩阵乘法的间隙也不闲着。说白了训练是烧钱买个聪明脑子推理是把聪明脑子用出效率。这里有个很经典的数据可以说明推理阶段的内存瓶颈到底有多严重。一个7B参数的模型权重用FP16存储光权重就占14GB。如果输入序列长度是2048每个token在每个层都要保存Key和Value向量7B模型、32层、40个注意力头、head维度128的情况下KV Cache占用的显存大约是2K和V×32层数×2048序列长度×40头数×128维度×2字节算下来大约1.6GB。序列长度翻倍到4096KV Cache也跟着翻倍。这还只是单请求如果并发请求数量一上来显存压力立刻成倍放大。这也是为什么现在推理框架都在KV Cache上做文章。2. 预训练从数据到参数的核心逻辑2.1 预训练在做什么预测下一个token预训练本质上是一个非常“笨”的任务——让模型根据前面的文本预测下一个词。听起来简单但当数据规模达到万亿token级别时模型就能从这种朴素的预测任务中提炼出语言的统计规律、语法结构、事实知识甚至推理能力。GPT系列的思路就是这么走通的下一个词预测的这种自监督方式不需要人工标注只管喂文本就行。这里有一个关键认知需要建立预训练不是“教会模型回答问题的过程”而是“让模型理解语言规律的过程”。回答问题是微调和RLHF阶段的事情。所以你会发现base模型经常“说话”前言不搭后语或者不会聊天这是正常的因为它确实没学过“该怎么回复用户”。如果你需要对话能力就要做后续的指令微调或者对齐。预训练的另一个核心是数据配比。你不会把所有数据一视同仁而是要有策略地混合通用网页文本、百科知识、代码、数学、多语言语料不同来源的数据有不同的质量分布。代码数据尤其重要因为它蕴含着严密的逻辑结构能显著增强模型的推理能力。业界的经验是代码数据占比通常在10%到20%之间数学和科学类数据适量增加能有效提升模型的逻辑水平。数据质量比数据数量更重要——一堆低质量重复文本训出来的模型反而会变“笨”。2.2 算力、数据和模型规模三者的关系预训练有个著名的经验公式叫Chinchilla法则也叫Scaling Law它告诉我们对于一个参数量为N的模型最优的训练token数大约是20N。也就是说7B模型你大概需要140B token的数据量来训练13B模型需要260B70B模型需要1.4T。这个比例不是绝对的但偏离太远会导致浪费——数据少了模型欠拟合数据多了后面的收益也在递减。对应的算力需求可以用一个简化公式估算C ≈ 6ND。C是训练所需的总浮点运算量FLOPsN是模型参数量D是训练token数。取7B模型和140B数据6 × 7×10⁹ × 140×10⁹ ≈ 5.88×10²¹ FLOPs。以一张A100 80GB的理论算力312 TFLOPSFP16来算即使算力利用率做到50%实际预训练通常能优化到更合理的水平单卡需要的时间也极其漫长。所以预训练必须靠大规模并行几百上千张GPU同时跑这是大多数团队根本无法承受的成本。这个公式最大的价值是帮我们做可行性判断。想训练一个7B模型先算算自己手里的卡够不够。不够就别硬上要么用更小的模型要么直接用开源模型做微调。我自己见过不少团队一上来就想训练自己的大模型结果发现一个epoch都要跑几个星期最后草草收场。预训练是巨头的游戏对绝大多数团队来说微调和推理才是真正的机会点。2.3 并行策略和混合精度预训练的工程底座预训练能跑起来靠的是分布式并行策略。常见的并行方式有几种。数据并行Data Parallelism最简单每张卡上放一份完整模型把不同batch的数据分给不同卡算梯度然后做梯度同步。张量并行Tensor Parallelism是把单个层的矩阵运算切到多张卡上每张卡负责一部分神经元计算。流水并行Pipeline Parallelism则是按层切分GPU 0算前几层GPU 1算中间层GPU 2算后面层数据像流水线一样依次流过。再加上ZeRO优化器可以把优化器状态、梯度和参数分片存到不同卡上大幅降低显存占用。预训练实际跑起来往往是这些策略的混合体为了最大化算力利用率。与并行配套的是混合精度训练。日常我们用FP32做数值计算但对大模型来说FP32显存占用太大且计算速度慢。混合精度的思路是前向和反向计算用FP16或BF16梯度更新时用FP32的master weights保持精度。为什么用BF16而不是FP16FP16的指数位太少数值范围窄训练中容易溢出BF16保留了和FP32一样的指数位只是牺牲了尾数精度对大模型的梯度传播更友好。现在主流训练框架里BF16基本是默认选择。混合精度不是没有坑。最常见的问题是loss突然变成NaN。排查思路一般是先降低学习率看是不是优化器步长太大检查数据里有没有异常值确认梯度裁剪是否生效。分布式训练里通信瓶颈也非常致命数据并行中每步都要做梯度AllReduce卡间通信量等于模型参数量乘以4字节。模型越大通信越慢这也是ZeRO-3能成为主流的原因——它把通信量降到几乎只有梯度同步的量级。3. 微调用最少代价把模型调成“自己人”3.1 三种微调方式的本质区别微调是绝大多数开发者和企业真正会接触的环节。从头预训练不现实直接用base模型又不好用微调就成了性价比最高的路径。现在主流的微调方案有三类全量微调、Freeze微调和LoRA微调。它们的本质区别在于模型参数中哪些被更新、哪些保持冻结。全量微调Full Fine-tuning是更新模型全部参数。效果通常最好因为模型有最大的自由度去适配新数据但资源消耗也最大。一个7B模型全量微调光梯度就是14GBFP16加上优化器状态AdamW需要两倍参数量大小的momentum和variance显存需求轻松超过60GB单张A100勉强能跑消费级显卡基本不用想。Freeze微调是冻结大部分层只微调最后几层或者某些特定层。思路是预训练模型的前面层学到的是通用的语言特征越是靠近输出层特征越偏向具体任务。所以只微调后面的层能在效果和资源之间取得平衡。这种方式显存占用比全量小不少但灵活性打了折扣实际项目中用得不算多。LoRALow-Rank Adaptation是目前最流行的方式也是我强烈推荐大多数人优先考虑的方案。它的核心思想可以用一句话概括不改动原始权重只训练一小部分新增的低秩矩阵。假设模型的权重矩阵W是d×d维LoRA的思路是引入两个小矩阵Ad×r和Br×d用它们的乘积BA去近似权重的增量ΔW。训练时冻结W只更新A和B。这个rrank远小于d比如d4096时r取16新增参数只有原来的1/256。这里给一个直观的对比表微调方式更新参数7B模型显存需求参考效果上限适用场景全量微调全部参数60GB以上需多卡最高数据量大、算力充足、追求极限效果Freeze微调部分层30-40GB中等偏高资源有限、下游任务单一LoRA少量低秩矩阵16-24GB单卡可跑接近全量消费级显卡、快速迭代、多任务适配3.2 LoRA的数学原理和rank怎么选LoRA的数学原理其实非常优雅。预训练模型的权重W已经学到了很好的特征表示微调需要做的只是在这个基础上“打个补丁”。理论上这个补丁ΔW应该是一个d×d矩阵但研究表明权重更新的本质往往包含在极低维的子空间中用一个低秩矩阵就能捕获大部分有效信息。所以LoRA把ΔW分解成A和B的乘积。前向计算从xW变成了x(W BA)也就是xW xBA。训练时W和原始路径都不动只优化A和B。推理阶段有两种选择一是把BA合并进WW_new W BA这样模型结构和原来完全一样没有任何额外推理开销二是保留LoRA权重动态加载方便在不同LoRA之间切换而不用重新加载整个模型。rankr怎么选是我被问得最多的问题。具体任务、具体数据量没有标准答案但我给出一个相对可靠的经验区间通用指令跟随类的任务r选8到16就够垂直领域知识学习r选16到32如果微调数据量很大而且需要学习的模式很复杂可以尝试r64。r不是越大越好太大会引入噪声导致过拟合太小又表达力不够。我从实践中得到的建议是优先从r16起步看验证集效果再上下调整不要一上来就追求大rank。alpha参数是另一个需要理解的超参数。它的作用是对LoRA权重进行缩放实际权重更新为alpha/r乘以BA。我一般把alpha设为rank的两倍这种做法在大多数开源项目里都是安全默认项。学习率也需要注意LoRA因为新增参数量少通常可以用比全量微调更高的学习率1e-4到3e-4是比较常见的区间。3.3 微调数据的构造质量比数量重要得多我见过太多人把微调做成了“喂数据大赛”以为数据量越大效果越好。实际情况是几百条高质量的对话数据效果可能比几万条从网上乱抓的文本好得多。微调的本质不是让模型学习新知识而是让模型格式化地输出已有知识。所以指令微调数据的核心是“一致性”和“格式统一”。你的每条训练样本应该包含三个部分指令Instruction、输入Input、输出Output。指令要尽量贴近真实使用场景不要用“请回答以下问题”这种空洞模板要像真实用户那样提问。输出要对齐格式比如如果是做客服机器人所有输出都要遵循“先道歉、再解释、后提供解决方案”的话术结构。模型学的是模式数据格式越统一学出来的行为就越稳定。数据清洗上我踩过最大的坑是“重复样本”。微调数据里如果某条样本出现几十次模型会明显过拟合到这条数据上表现为输出时反复说同一句话。所以要专门做去重。另一个坑是数据泄漏——测试集和训练集内容高度重叠评估时感觉模型很强上线一用就废。大模型本身训练语料里可能已经包含你测试集的内容评估时要格外小心。领域微调还要注意“灾难性遗忘”问题。模型在适应新任务时可能把预训练学会的通用能力忘掉。比如你只微调了医疗数据模型可能从此不会写代码了。缓解方法混入一定比例的通用指令数据业界通常推荐微调数据里混10%到20%的通用SFT数据或者降低学习率让更新幅度小一点或者用LoRA这种方式本身就比全量微调更轻量遗忘问题会轻很多。4. 推理框架把模型变成真正能用的服务4.1 量化、KV Cache、连续批处理推理优化三件套微调出来的模型只是一个“档案”要真正面向用户提供服务必须经过推理框架的优化。推理优化可以从几个层面理解计算优化、显存优化、调度优化。量化是计算优化的重要手段。举个例子FP16转INT8权重体积直接减半计算速度也大幅提升。量化分两种训练后量化PTQ和量化感知训练QAT。PTQ不用重新训练直接把权重映射到低精度速度快但可能有精度损失QAT在训练阶段就模拟量化误差效果好但成本高。对大多数场景先用PTQ跑一遍效果不满意再考虑QAT。GQAGrouped Query Attention也是一种“类量化”的结构优化让多个查询头共享一组键值头从而减少KV Cache键值缓存大小效果非常实用。KV Cache是大模型推理里的一个独特机制。自回归生成是逐token输出每个新token都要和之前所有token计算注意力。如果每次从头算一遍复杂度是O(n²)序列稍微长一点就慢得无法接受。KV Cache的做法是把已经计算过的Key和Value向量缓存在显存里新token只需要做增量计算。这本来是单个请求内的优化但多请求并发时KV Cache占了大量显存而且分配算法不高效的话显存碎片化严重。vLLM提出的PagedAttention把KV Cache切分成固定大小的块像虚拟内存一样管理既能按需分配又能共享重复的前缀让显存利用率提升了非常多。连续批处理Continuous Batching解决了传统静态批处理的痛点。传统批处理里一个batch里如果有请求提前生成完了GPU也要等整个batch结束才能释放资源。连续批处理把这个粒度细化到token级别——哪个请求的当前token算完了立刻腾出位置给新请求。这样GPU的利用率大幅提升吞吐量可能翻倍甚至更多。现在主流推理框架的吞吐优势很大程度都来自于这个调度策略。4.2 主流推理框架怎么选推理框架的选择直接决定上线后的性能和运维复杂度我结合自己用过的经验做一个横向对比框架定位性能特点最适合场景注意点vLLM高吞吐在线服务PagedAttention高效利用显存吞吐高生产环境API服务高并发场景对CUDA版本有要求动态shape支持一般TensorRT-LLM极致延迟优化TensorRT引擎优化GPU利用率极高对时延极度敏感的场景编译过程繁琐模型结构需定制导出Ollama本地轻量部署一键启动支持GGUF格式个人电脑、内网离线环境框架封装度太高底层调优空间有限llama.cppCPU/边缘部署纯C实现支持CPU和量化无GPU环境、边缘设备吞吐有限大模型并发能力弱vLLM LoRA多任务灵活部署动态加载多个LoRA快速切换多个垂直任务需要显存预留LoRA权重空间选型建议很直接生产环境在线API服务vLLM是省心的默认选择社区活跃、生态好、支持模型范围广。如果你有强实时性要求比如智能客服必须几百毫秒内出首tokenTensorRT-LLM值得花时间折腾它的延迟优化是几个框架里最激进的。如果是内网离线部署、想要简单省事Ollama足够。跑在纯CPU上的边缘场景llama.cpp是唯一靠谱的选择。框架之间不是互斥的。我见过不少项目的做法是用vLLM跑主力API同时用Ollama做内部测试和demo演示两者共用一套微调产物只是导出格式不同。还有一个容易忽略的问题是模型格式。HuggingFace格式safetensors是训练和微调的主流格式但很多推理框架需要特定格式vLLM直接用HF格式Ollama需要GGUF格式TensorRT-LLM需要engine格式。这就涉及转换流程。模型转换看起来是个小事但版本不匹配、tokenizer不一致导致的bug能让人排查好几个小时。我的经验是微调完成先导出HF格式并本地验证效果确认无误后再转目标格式每转一次就做一次效果抽查。这个流程不可省格式转换引入的精度损失或者结构损坏模型输出质量会肉眼可见地下降。5. 一个能跑通的参考链路Qwen微调加部署实操5.1 环境准备和数据准备理论讲再多不如跑一遍。我拿Qwen2.5-7B-Instruct作为基底模型用llama-factory做LoRA微调再用vLLM做推理部署最后导出一份GGUF格式给Ollama用。这套链路在8GB显存的消费级显卡上也能跑起来LoRA模式非常典型。环境准备只需要Python 3.10以上和CUDA环境。先用conda建一个干净的虚拟环境conda create -n qwen-finetune python3.10 -y conda activate qwen-finetune然后安装llama-factory。llama-factory是目前最主流的微调工具它把数据处理、LoRA、全量微调、评估、推理、模型导出全都包了还提供了一个WebUI界面对新手极其友好。安装命令git clone https://github.com/hiyouga/LLaMA-Factory.git cd LLaMA-Factory pip install -e .数据准备方面我想演示一个具体的垂直场景。假设你要微调一个“农业问答助手”收集到的原始数据是“土壤湿度低于30%时需要启动灌溉”这种知识条目。不能直接拿这个东西去微调要转换成指令微调的标准格式{ instruction: 当土壤湿度低于多少时需要启动灌溉系统, input: , output: 当土壤湿度低于30%时建议启动灌溉系统以保证作物根系正常吸收水分。同时需要结合土壤类型和作物品种进行调整沙质土壤可适度提高阈值。 }一批这样的数据存放在train.json里每个元素一条。5.2 llama-factory 微调实操llama-factory支持命令行和WebUI两种方式。命令行适合自动化WebUI适合迭代调试。我这里用命令行做个演示。在项目根目录创建一个config文件qwen_lora.yamlmodel_name_or_path: Qwen/Qwen2.5-7B-Instruct dataset: train.json finetuning_type: lora lora_rank: 16 lora_alpha: 32 stage: sft template: qwen cutoff_len: 1024 learning_rate: 2e-4 num_train_epochs: 3.0 per_device_train_batch_size: 1 gradient_accumulation_steps: 16 output_dir: qwen-lora-output几个参数我解释一下为什么这么设。LoRA rank是16适配几百条到几千条规模的数据足够alpha是rank的两倍这是常见的缩放比例。per_device_train_batch_size设为1因为7B模型在LoRA模式下即使只训练低秩矩阵完整模型还是要加载进显存batch太大会OOM。gradient_accumulation_steps设为16是为了凑出一个16的有效批大小让梯度更新更稳定。cutoff_len设为1024控制输入序列长度过长会撑爆显存过短会截断有效信息。启动微调llamafactory-cli train yaml_config/qwen_lora.yaml训练过程里主要盯两个loss指标训练集loss和验证集loss。训练loss应该持续下降验证loss如果先降后升说明开始过拟合可以提前停止或者把epoch调小。训练完成后导出LoRA产物并合并回基础模型llamafactory-cli export \ --model_name_or_path Qwen/Qwen2.5-7B-Instruct \ --adapter_name_or_path qwen-lora-output \ --template qwen \ --finetuning_type lora \ --export_dir qwen-merged导出后的qwen-merged目录就是一个标准的HuggingFace模型目录直接用transformers加载或者部署都行。5.3 用vLLM部署和Ollama本地化部署推荐vLLM。安装很简单pip install vllm启动服务只需要一条命令python -m vllm.entrypoints.openai.api_server \ --model qwen-merged \ --served-model-name qwen-agri \ --tensor-parallel-size 1 \ --max-model-len 4096 \ --gpu-memory-utilization 0.9这里gpu-memory-utilization设为0.9的意思是让vLLM最多用90%的显存做推理和KV Cache留10%给模型加载余量和其他进程。如果机器上还跑着别的服务这个值要适当调低。启动之后用OpenAI SDK风格发一个测试请求from openai import OpenAI client OpenAI( base_urlhttp://localhost:8000/v1, api_keyEMPTY ) response client.chat.completions.create( modelqwen-agri, messages[ {role: user, content: 大棚种植番茄土壤湿度多少时需要浇水} ], streamTrue ) for chunk in response: delta chunk.choices[0].delta.content if delta: print(delta, end, flushTrue)如果还要在个人电脑上用Ollama跑同一个模型需要先把HF格式转成GGUF。转换方式有两种用llama.cpp自带的转换脚本或者直接用ollama的官方导入流程。最简单的方式是pip install llama-cpp-python python -m llama_cpp.convert_hf_to_gguf qwen-merged \ --outfile qwen-agri.gguf \ --outtype q8_0然后建一个Ollama模型文件modelfileFROM qwen-agri.gguf TEMPLATE {{- if .System }} 系统{{ .System }} {{- end }} 用户{{ .Prompt }} 助手执行ollama create qwen-agri -f modelfile就把模型装进Ollama了。后续可以随时用ollama run qwen-agri本地体验而且GGUF格式在CPU上也能跑出差没GPU也能演示模型效果。6. 我在工程里踩过的坑和排查思路6.1 训练和微调阶段的典型问题很多人在微调阶段遇到的第一个问题是显存溢出OOM。常见原因有三个batch size太大、序列长度太长、优化器状态占用被忽略。LoRA微调7B模型时很多人以为用LoRA就不占显存了实际上基础模型的权重、输入激活值都在显存里只是梯度不占而已。如果OOM先把batch size降到1再开gradient accumulation配合cutoff_len缩短序列长度。还不行就考虑换小一点的基座模型比如7B换成3B很多时候效果差距并没有想象中那么大。训练不收敛loss不降是另一个高发问题。排查顺序我建议这样先看数据的输入输出格式是否正确尤其是tokenizer的special token是否处理对再看学习率LoRA建议从1e-4到3e-4区间试再看数据本身如果指令全是“你好”“在吗”这种无效对话模型学到的是个寂寞。有些模型base版本和chat版本的tokenizer处理方式差异很大用chat版本模型微调时可以用自带的chat template构造指令不要自己拼格式。还有一个微妙的问题就是“模型开始胡说八道”。这个现象在微调后反而变严重的情况很常见——LoRA把所有参数都往新任务上推模型在领域知识的边界外面开始乱编。缓解方式降低LoRA的alpha让更新幅度温和增大数据里的通用指令比例或者在微调时加入一点原始模型的通用能力数据作为锚点。6.2 推理部署阶段的常见问题推理阶段最容易出的是性能问题。模型加载慢、首token延迟高、吞吐上不去是三个高频投诉。模型加载慢大多数情况是量化没做或者磁盘IO是瓶颈大模型动辄十几GB从磁盘加载到显存就需要几十秒。优化办法是预加载和保持常驻不要频繁重建服务实例。首token延迟高问题可能出在prefill计算太慢。首token需要处理整个输入序列序列越长计算越重。如果你的业务场景输入都是几千token的PDF文档建议用支持前缀缓存的框架vLLM搭配合适的调度器把重复的Prompt前缀缓存下来极大减少prefill计算量。吞吐上不去则要看是不是batch size设小了。vLLM里可以通过设置max_num_seqs调大并发序列数提升吞吐。不过注意并发上去了单请求延迟也会升高需要平衡。我一般先评估业务对延迟的容忍度再决定吞吐优先还是延迟优先。还有一个推理阶段特别容易被忽略的坑多路并发时KV Cache撑爆显存。如果你用的是量化权重权重占显存小了剩出来的空间看似很多但KV Cache是动态增长长对话很容易把显存吃光。这时候要么限制max-model-len要么启用vLLM的自动显存管理或者用支持KV量化FP8甚至INT4的KV Cache的框架版本。6.3 数据和模型安全方面的注意事项数据质量直接影响模型行为这个怎么强调都不过分。我遇到过的最严重问题是数据投毒——训练语料里被混入恶意样本模型在某些特定触发词下输出错误甚至有害的内容。大模型的训练数据来源庞杂任何一环审核不严都可能被利用。做微调时务必确认数据来源可信对爬取的数据做严谨的内容审核和去重关键业务模型不要从不明渠道下载现成的SFT数据集直接训练。注意训练数据里绝对不要包含个人隐私、企业机密、未公开的商业信息。模型会“记住”训练数据而且不排除后续通过巧妙的问题被诱导出来。大模型数据安全的第一条红线就是不能进训练集的数据永远不要让它进去。模型文件本身也是风险点。从网上下载模型权重时要校验文件hash确认是从官方渠道获取。微调产物的发布也要做好版本管理尤其是面向外部提供API服务时模型的更新和回滚流程要足够简单万一上线模型出问题必须能几分钟内切回旧版本。6.4 常见问题速查表现象可能原因排查方式训练loss持续不降数据格式错误、学习率过低先跑一遍验证集看预期输出逐个排除验证loss上升过拟合减小epoch增加数据量调低alphaOOMbatch过大、序列过长batch降到1缩短cutoff_len微调后模型能力全面退化灾难性遗忘混入通用SFT数据调低学习率推理速度慢未启用KV Cache或量化确认框架配置尝试INT8/INT4量化并发一高就崩溃显存被KV Cache撑爆限长、限并发、启用KV Cache量化同一问题回答不稳定推理温度过高降低temperature必要时用greedy decoding我在实际项目中见过太多人被这些基础问题卡住白白浪费时间。这张表是我自己遇到问题时的第一反应清单按这个顺序查通常很快能找到根因。几句大实话要说搞大模型这一年多来我最大的体会就是链路上每个环节的瓶颈点完全不一样。预训练卡的是算力和数据微调卡的是数据质量和调参经验推理卡的是工程细节——哪怕只省下几毫秒的延迟、多扛几个并发对线上体验的影响都特别直接。很多人一开始把精力全放在模型效果上结果卡在部署上线实在可惜。最后再分享一个我一直在用的工作习惯微调一个模型之前先把评估集建好。这个评估集不用很大五十到一百条覆盖典型场景的真实问题就够每条都有明确的预期答案。每次微调完、量完化、部署完先在这套评估集上跑一遍分数合格再继续下一步。这个习惯帮我拦截了无数次“模型训完但效果还不如base”的尴尬情况。大模型的基建越来越完善真正拉开差距的往往就是这些不起眼的小流程。