大模型训练、微调与推理这两年几乎成了每个AI团队都要碰一遍的链路。不管是做大模型微调还是部署推理框架底层其实就三件事先有一个通用底座再把它改造成适合自己业务的样子最后把这个能力稳定地暴露给上层应用。很多刚入门的朋友会在这三个环节里迷路搞不清全量微调和LoRA到底该怎么选vLLM和Ollama又差在哪模型明明在那个项目里跑得好好的换成自己的环境就各种OOM。这篇文章我按一条完整链路来拆预训练和增量训练的底层逻辑、全量微调与LoRA微调的实际差别与操作、从模型权重到生产级服务的推理框架选型以及落地时最常踩的坑。内容面向想真正动手做微调和部署的工程师、技术负责人也适合正在为大模型选型做调研的团队。我会尽量把“为什么要这么做”讲清楚而不只是甩参数和命令。1. 先把链路盘清楚预训练、微调、推理分别解决什么问题1.1 三条流水线的本质区别在聊具体技术之前我建议先建立一张地图。一个模型从“出生”到“上线”通常经过三个阶段预训练、微调也叫后训练、推理部署。很多人把这三件事混在一起谈但它们的算力需求、技术栈、团队分工差异非常大。预训练的目的是让模型学会语言规律和通用世界知识。它吃的是海量文本动辄几万亿token在数千张甚至上万张显卡上跑好几个星期。这一阶段决定了一个模型的“底子”好还是不好也是普通团队很难复制的一步。微调则是站在预训练模型肩膀上做定向改造。它不需要重新学习语言而是让模型学会特定任务的输入输出格式、特定领域的表达习惯或者注入一部分私有知识。微调的数据量通常只有几千到几十万条单机多卡甚至单卡都能完成。这也是大模型落地中最常见的切入点。推理部署是价值出口。模型训练得再好如果不能以可接受的延迟和吞吐提供服务就落不了地。推理和训练完全是两种工程问题训练追求吞吐和模型质量推理则要同时照顾延迟、并发、显存成本。所以才催生出vLLM、SGLang、TensorRT-LLM、Ollama这一大批推理框架。1.2 从高频问题看大家的真实困惑我最近在社区里看到很多类似的提问llama-factory怎么部署和微调、LoRA实战教程有没有Qwen版本、7B模型微调要多少显存、本地部署大模型用Ollama还是vLLM。这些问题的背后其实都指向同一个核心资源有限的情况下如何在效果和成本之间做出正确取舍。全量微调能改得更彻底却需要多卡甚至几十卡LoRA微调省显存但可学习参数少会不会学不动推理框架里Ollama装起来方便但并发上来以后吞吐掉得厉害要不要换vLLM模型下载下来用transformers跑得好好的为什么一上服务就崩这些困惑本质上是因为大家缺的不是单个工具的使用方法而是对整个链路里“资源消耗从哪来、瓶颈在哪”的判断力。这篇文章的核心就是想把这层判断力交给你。2. 预训练与增量训练的底层逻辑数据、算力与并行2.1 预训练到底在做什么如果你把预训练简化到极致它就是一个很大的“下一个词预测”任务给定前面一段文本让模型预测下一个token是什么然后拿预测结果与真实文本做交叉熵损失反向传播更新参数。这个目标看着简单却能让模型从万亿token里学到语法、事实、推理能力甚至一部分世界模型。但训练数据不是简单堆文本。一套成熟的预训练管线要做超大规模的清洗、去重、语言配比和领域配比。混入多少代码数据、多少中文语料、多少数学数据直接影响模型的下游表现。这也是为什么很多团队做增量训练时发现效果很差根子往往不是训练代码有问题而是数据配比出了问题。预训练的另一个特点是训练轮数极少。大多数基础模型的训练epoch在1到2之间因为海量token已经足够模型收敛多轮并没有带来信息增益反而容易让模型“背下来”损害泛化能力。这点和后面微调的习惯非常不一样如果你拿CV训练里跑几十个epoch的思路去预训练大模型基本会翻车。2.2 分布式训练的必要技术张量并行、流水线并行、ZeRO/FSDP7B模型的BF16权重就要占14GB显存配合优化器状态、梯度和激活值单卡训练几乎不现实。想要在有限硬件上训练就必须上一个或多个系统。数据并行最常见每张卡放一份完整模型副本各自吃不同batch然后做梯度同步。它简单高效但每张卡都要完整放下一份模型显存成本很高。为了解决这个痛点ZeRO和PyTorch FSDP的做法是分片把优化器状态、梯度甚至参数切到多卡上需要用的时候再聚合。如果模型是7B/13B级别单机多卡用FSDP通常最省事。你要是手头只有几张消费级卡这也是最该优先掌握的。张量并行的思路是把Transformer某一层的矩阵按列或按行切开让不同GPU共同完成一件矩阵乘法。这种切法通信量很大一般要求GPU之间走NVLink这种高速互联适合单机多卡场景。流水线并行则是把不同层分给不同GPU数据像流水线一样依次流过各卡通信压力小但存在天然的流水线气泡。超大模型训练通常把数据并行、张量并行、流水线并行组合成3D并行再配合ZeRO落地。如果你不是要训练上百亿以上的模型我的建议是别一上来就搭Megatron三层并行先用NVIDIA官方推荐的FSDP或者DeepSpeed ZeRO-3跑通小规模实验资源不够再逐步加并行度。并行度越高调试成本和通信开销越大不一定划算。2.3 增量训练补知识但别指望它改变行为增量训练又叫领域预训练或继续预训练本质是拿领域语料接着做next token预测。它的典型场景是企业内部语料有大量专业术语和行业知识通用模型没见过希望通过继续训练把知识“记”进去。这里有个常见误区“我拿业务问答数据做增量训练模型应该就能回答业务问题了。”不对。增量训练只能让模型见过这些内容不一定能学会回答问题的格式。真正让它学会对话格式的是后面的指令微调SFT。正确顺序通常是先做领域增量训练再做指令微调让模型既知道知识又知道怎么回答问题。增量训练要注意三点。第一学习率要压得非常低通常是初始预训练学习率的十分之一甚至更低否则会快速破坏原有能力。第二领域语料要和通用语料混合着来比如一份领域语料对一份通用语料防止灾难性遗忘。第三做数据时要保持语料的多样性和格式统一不要全是同一模板的重复文本否则模型很容易训歪。3. 微调方案的选型与实操全量、Freeze、LoRA怎么挑3.1 三种微调方法对比别再凭感觉选微调的本质是在通用模型基础上更新参数不同方案的核心区别是“更新哪部分参数”。围绕这个话题全量微调、Freeze微调、LoRA微调一直是检索量最大的三兄弟。先看全量微调。它更新模型全部参数理论上效果上限最高尤其适合需要强任务格式适配、数据量很大的场景。但代价是训练过程的显存开销非常大即使使用FSDP混合精度7B模型也常常需要多张48G以上的卡。如果你有充足硬件并且希望模型彻底改变风格全量微调可以选。Freeze微调的做法是冻结大部分层只训练靠近输出的若干层或部分注意力模块。它的显存占用比全量低但存在“头尾难以兼顾”的问题能用的人设变了但能力上限容易被冻结住通常效果不如全量也不如LoRA。现在很多团队已经直接用LoRA替代它。LoRA微调是目前事实上的标准方案。模型原有权重被完全冻结只在每一层旁边插入低秩矩阵作为可学习参数训练时只更新这些少量参数推理时再把低秩矩阵合并回原始权重几乎不增加推理开销。7B模型用LoRA微调显存需求可以从全量的几十GB压到十几GB甚至更低普通24G显卡就能跑。我的选型建议很简单在自己能承担的最大显存范围里优先选LoRA。先跑通数据验证和效果测试如果数据量很大、风格改造需求非常彻底再考虑全量微调。Freeze微调如今更多作为历史方案用于对比除非你有一些特殊原因比如目标模块固定在深层否则不推荐作为首选。3.2 LoRA原理拆解和显存计算思路LoRA论文给了很直接的解释预训练模型的权重更新过程往往是低秩的也就是说虽然模型参数空间很大但真正有效的最优路径落在一个低维子空间里。因此不需要更新完整的高维矩阵只要训练两个低秩矩阵A和B的乘积近似表达增量就好。假设某一层的权重W是d乘dLoRA把增量拆成B乘AB的维度是d乘rA是r乘dr远小于d。训练时冻结W只更新A和B推理阶段可以显式地算W等于W加BA好像从不曾加过LoRA一样。如果你把一个7B模型上千亿参数压到只训练几百万参数模型照样能适配指令数据。理解这个原理你就明白为什么LoRA有三个关键参数。rank r直接决定表达容量r太小学不到位r过大训练慢还容易过拟合。alpha是缩放系数会乘到低秩矩阵的更新结果上直观理解成“学习步长放大倍数”。target_modules则决定往哪些线性层插适配器常见选择是query、key、value、output和gate。一般先上q、k、v、o如果想提升表达能力再把gate、up、down加进去但不要盲目全加否则显存和可学习参数量都会上涨。显存预算也可以粗算一次。以7B模型为例如果用LoRA微调BF16权重本身约14GB反向传播需要保存少量梯度和LoRA参数再加上激活值如果不开gradient checkpointing24G卡很容易爆开了之后单卡24G基本能跑。如果改用QLoRA把基础模型压到4bit激活和梯度再省一截甚至16G左右的消费卡也能尝试但省显存会带来训练速度下降和少量精度损失。14B到70B的模型则建议直接用QLoRA或上多卡分布式。3.3 用Llama-Factory快速微调一个可用的Qwen模型实际动手时如果从零写训练脚本会面临很多坑数据格式模板、tokenizer的chat template、包装数据、Gradient checkpointing开关、分布式启动每个地方都会出错。Llama-Factory这类开源工具把很多重复工作收敛成了配置和命令非常适合快速验证。首先把项目clone下来并安装依赖这里有个容易错的地方是额外安装flash-attention-2能明显提速但同时要求CUDA环境正确。如果你的CUDA版本和PyTorch不匹配训练会在attention阶段莫名报错。安装完成后数据的注册是关键一步。Llama-Factory要求先把数据集写到data/dataset_info.json里并在messages等字段中标注内容列而不是把JSON直接扔给命令行。假设你要微调Qwen2.5-7B的指令模型可以用类似下面的命令llamafactory-cli train \ --model_name_or_path /models/Qwen2.5-7B-Instruct \ --stage sft \ --finetuning_type lora \ --dataset custom_sft_data \ --template qwen \ --cutoff_len 2048 \ --learning_rate 2e-4 \ --num_train_epochs 3 \ --per_device_train_batch_size 2 \ --gradient_accumulation_steps 4 \ --output_dir outputs/qwen_lora_zh \ --gradient_checkpointing true \ --lora_rank 32 \ --lora_alpha 64 \ --lora_target_modules q_proj,k_proj,v_proj,o_proj,gate_proj,up_proj,down_projLlama-Factory也提供Web UI版本执行CUDA_VISIBLE_DEVICES0 python src/train_web.py后会启动一个图形界面可以直接选择模型、数据集、微调方式和训练参数对新手更友好。但我始终建议提交训练任务前先在界面里打开“Preview”看一下数据转换后的实际内容确认system、user、assistant三段内容没有被错误套模板。曾经遇到过数据格式没问题但因为模板值选错训练时把每一条历史对话都当成新对话导致模型学了一堆错误拼接文本。数据格式方面如果你用Alpaca格式字段通常是instruction、input、output如果你用ShareGPT形式则更贴近真实多轮对话。业务数据里的一个高频问题是指令太短、答案太长且带格式噪声。发现微调后模型输出越来越像营销号时先去清洗数据而不是急着加大rank。3.4 Mac、低显存环境到底能不能微调很多人问到MacBook能不能用来LoRA微调它能跑但不建议作为主力训练机。M系列芯片的统一内存架构让大模型在CPU内存里加载权重比普通PC有优势配合MLX这类专门优化的框架可以跑7B甚至13B的低参数量微调实验。但CUDA生态里的flash-attention、deepspeed并行在Mac上都不能直接用训练速度大约是主流NVIDIA卡的几分之一。我自己的建议是Mac适合快速做数据集验证和单步forward测试真正需要训练还是租一张云GPU更划算。这个判断往往比优化训练代码更能省时间。4. 推理框架选型与工程落地从权重到高可用服务4.1 为什么推理也要单独讲“框架”而不是直接用transformers模型训练完之后你拿到的是一堆权重。很多人一开始会自然想到用transformers的generate函数跑推理从功能上它当然可以但生产场景不行原因在于推理是自回归的模型每次只生成一个token需要重新读取之前的所有KV状态。如果不做缓存长文本生成会越来越慢显存里也会堆积大量无用的中间张量。现代推理框架的核心优化基本围绕三件事。第一是KV Cache把已计算的历史key和value缓存下来避免重复计算。第二是连续批处理新请求不必等当前批次整体生成完可以随时插入显著提高GPU利用率。第三是显存管理vLLM引入的PagedAttention借鉴操作系统的分页思想把KV Cache切成更小的块按需分配减少显存碎片浪费。理解这几个点之后你就知道为什么Ollama适合个人本地用而高并发服务一般选vLLM不是Ollama代码写得不好而是它的定位偏轻量易用并没有把吞吐优化做到极致。所以选推理框架时先想清楚自己的场景是给几个人提供本地问答服务还是给外部业务提供几十上百并发请求的API。框架核心特点建议场景vLLM高吞吐、PagedAttention、OpenAI兼容API生产环境API服务并发高SGLangRadixAttention、结构化输出优化复杂Prompt共享、Agent场景TensorRT-LLMNVIDIA深度优化、编译成TensorRT引擎对性能要求极高的专项部署llama.cpp / llama-serverCPU和混合设备友好消费级显卡、Mac本、嵌入式Ollama安装极简、管理模型方便本地体验、轻量应用、学习transformers开发友好、性能平庸测试、调参、跑通流程4.2 用vLLM搭一个面向生产环境的OpenAI兼容APIvLLM是我目前在生产环境用得最多的框架。它装起来不复杂关键是把模型路径、显存上限和最大序列长度配置合理。拿7B模型举例可以这样启动服务python -m vllm.entrypoints.openai.api_server \ --model /models/Qwen2.5-7B-Instruct \ --served-model-name qwen25-7b \ --dtype bfloat16 \ --max-model-len 8192 \ --gpu-memory-utilization 0.9 \ --tensor-parallel-size 1 \ --host 0.0.0.0 \ --port 8000这里--gpu-memory-utilization不能直接设成1.0因为GPU还要留出一部分内存做激活值、临时张量和运行时开销设得过高启动时可能通过显存预检但一到真实请求就OOM。我之前就遇到过因为把这个参数调到0.98导致并发请求时偶发崩溃的情况降回0.9就稳定了。--max-model-len决定模型能处理的最大上下文同时也决定KV Cache的预留策略调得越大能并发的请求数越少。如果业务中绝大多数请求都在几千token以内不建议硬上32K留更大的batch空间往往对吞吐更友好。客户端调用可以直接使用OpenAI SDK设置base_url为http://你的服务地址:8000/v1。容易踩坑的地方在于served-model-name要和服务端定义一致否则客户端会提示模型不存在不要直接拿原始模型目录名去猜。如果想把模型放进单张卡里跑更大参数的模型一般会给推理框架配量化方案最常见的是AWQ和GPTQ。AWQ按激活值的统计信息挑选重要通道量化后推理速度没有明显下降但存储和显存都会减少不少。一个14B模型如果以AWQ INT4格式部署显存占用大约只要BF16版本的一半左右。不过量化不是免费的如果你需要模型输出严谨的代码或数学推理建议先跑一轮评测看看量化后的效果是否可以接受。4.3 Ollama和AnythingLLM本地知识库的正确打开方式推理框架并不只是面向后端API的技术人很多需求其实落到“本地知识库客服”上。比如有人会问“AnythingLLM可以训练模型吗”答案是不能它是一个基于大模型的RAG工作台负责把文档切片、向量化、检索再组合Prompt交给底层大模型回答问题。它本身不训练模型而是调用Ollama或其他推理框架暴露出的接口。这里其实有一个特别值得强调的工程判断当你想做一个内部AI问答助手优先考虑组合RAG和提示词工程而不是一上来就微调模型。RAG适合知识持续变化、答案依赖外部文档的场景比如产品手册、官网FAQ、内部知识库。微调则适合模型表达风格、输出格式、固定指令需要固化的场景。把“知识补充”塞进微调会带来更新成本高、知识容易过期的问题把“风格改变”寄托在RAG上Prompt会越来越臃肿且不稳定。只要你的模型体积没有大到单机跑不动推荐这种组合方案Ollama负责本地模型推理提供OpenAI兼容接口AnythingLLM负责文档管理与向量检索上层客服流程只做Prompt组织。整个链路的好处是更换模型非常方便模型从7B升级到14B时不需要改动RAG逻辑。这比每次业务变化都重新微调省太多事了。5. 落地过程中的常见问题与调优实录5.1 微调时遇到OOM和Loss异常该怎么办大模型微调最常见的问题就是显存不够。遇到CUDA OOM不要急着加钱买卡先检查这几个方向per_device_train_batch_size是否设置成大于1在小卡上把它降到1通常能直接救回来gradient_accumulation_steps是用来做梯度累积的它不影响显存只影响等效batch size所以OOM时可以把它调大同时保持总batch不变gradient_checkpointing是否开启它用计算换显存开启后显存可能降低20%到40%。Loss异常也有规律可循。如果Loss一开始就很小但不再下降很可能是数据集里大量样本的标签和输入没有对应上模型学到的是捷径。如果Loss前期正常但几个epoch之后反而上涨大概率是学习率太高或者模型在死记训练集需要调低学习率并加一点早停。一个我在项目里反复使用的“冒烟测试”方法构造一条样本单条数据过拟合几次迭代如果Loss能降到很低、预测完全正确说明代码链路没问题再换成全量数据去训练。这条经验能帮你把代码问题和数据问题快速隔离。5.2 推理阶段容易被忽略的配置问题推理框架部署时崩溃经常不是网络或服务配置而是模型权重加载和推理框架不匹配。比如某个模型在Hugging Face页面标注推荐模板是ChatML但你在服务里没有设置对应的template启动后模型能回复但每条消息都怪怪的第一轮还好多轮就逐渐崩。遇到这类问题时先打开框架日志看一下它加载的chat template到底是什么以及实际构造出的Prompt是什么样的不要盯着生成文本猜测。另一个容易被忽略的是解码参数。生产环境里你会看到有人设了temperature为0.1甚至0这是为了稳定性但太低会让代码和复杂任务表现变差。更干净的方案是使用top_p并控制max_tokens还要记得设置合理的超时时间。vLLM服务端虽然设置了max-model-len但单个请求的超时和重试策略往往容易忘了配置高峰时一个慢请求可能拖垮整个网关。这些工程细节比模型本身的差别更能决定系统稳定性。5.3 怎么判断微调和推理方案是否达标最后聊评估。很多团队微调一个星期觉得模型“聪明了”一问效果好在哪说不出来。我见过有人在没有独立验证集的情况下拿着训练集里的对话问模型得到的回答自然漂亮但这不能说明模型真的学好了。评估至少需要做两层。第一层是在公开基准或自有验证集上做指标测试语言模型常用的包括通用能力评测集、代码类任务和数学类任务按你的业务场景选几套就行。第二层是人工盲测把微调前后、不同方案的输出放在同一页面不看来源打分重点看是否遵循指令、是否遗漏要点、有没有幻觉。如果你在做一个客服场景可以准备30条典型用户问题按每轮对话分别打分。这里也可以顺便解释一个容易混淆的点目标检测训练里有mAP、nnU-Net训练有Dice它们都是任务专属的评估指标而大模型微调在业务指标上很难只靠一个数值解决因为语言生成质量本身是多维度的。与其花精力追求某个基准分数的百分位提升不如花时间搭好验证集让每次迭代都能回答一个问题这次改动到底有没有让模型变得更好用。这个习惯一旦建立后面所有训练配置调整都会少走非常多弯路。我在实际项目里见过太多团队把时间花在堆rank、调学习率、换更大的基座模型上最后发现数据质量才是真正的瓶颈。大模型训练、微调、推理这条链路看着庞杂核心逻辑却很单纯数据决定上限工程决定下限。对绝大多数团队来说最优路径不是复刻一次预训练而是用一个小而干净的数据集做LoRA微调再用vLLM或Ollama把服务稳定跑起来把验证集做扎实。等你走完这一轮再回头看到“全量微调和LoRA怎么选”“推理框架该用哪个”这类问题时就不需要看任何人的结论因为你自己已经能用资源和效果去衡量了。 大模型微调与推理部署全链路解析：从LoRA到vLLM的工程实践
大模型训练、微调与推理这两年几乎成了每个AI团队都要碰一遍的链路。不管是做大模型微调还是部署推理框架底层其实就三件事先有一个通用底座再把它改造成适合自己业务的样子最后把这个能力稳定地暴露给上层应用。很多刚入门的朋友会在这三个环节里迷路搞不清全量微调和LoRA到底该怎么选vLLM和Ollama又差在哪模型明明在那个项目里跑得好好的换成自己的环境就各种OOM。这篇文章我按一条完整链路来拆预训练和增量训练的底层逻辑、全量微调与LoRA微调的实际差别与操作、从模型权重到生产级服务的推理框架选型以及落地时最常踩的坑。内容面向想真正动手做微调和部署的工程师、技术负责人也适合正在为大模型选型做调研的团队。我会尽量把“为什么要这么做”讲清楚而不只是甩参数和命令。1. 先把链路盘清楚预训练、微调、推理分别解决什么问题1.1 三条流水线的本质区别在聊具体技术之前我建议先建立一张地图。一个模型从“出生”到“上线”通常经过三个阶段预训练、微调也叫后训练、推理部署。很多人把这三件事混在一起谈但它们的算力需求、技术栈、团队分工差异非常大。预训练的目的是让模型学会语言规律和通用世界知识。它吃的是海量文本动辄几万亿token在数千张甚至上万张显卡上跑好几个星期。这一阶段决定了一个模型的“底子”好还是不好也是普通团队很难复制的一步。微调则是站在预训练模型肩膀上做定向改造。它不需要重新学习语言而是让模型学会特定任务的输入输出格式、特定领域的表达习惯或者注入一部分私有知识。微调的数据量通常只有几千到几十万条单机多卡甚至单卡都能完成。这也是大模型落地中最常见的切入点。推理部署是价值出口。模型训练得再好如果不能以可接受的延迟和吞吐提供服务就落不了地。推理和训练完全是两种工程问题训练追求吞吐和模型质量推理则要同时照顾延迟、并发、显存成本。所以才催生出vLLM、SGLang、TensorRT-LLM、Ollama这一大批推理框架。1.2 从高频问题看大家的真实困惑我最近在社区里看到很多类似的提问llama-factory怎么部署和微调、LoRA实战教程有没有Qwen版本、7B模型微调要多少显存、本地部署大模型用Ollama还是vLLM。这些问题的背后其实都指向同一个核心资源有限的情况下如何在效果和成本之间做出正确取舍。全量微调能改得更彻底却需要多卡甚至几十卡LoRA微调省显存但可学习参数少会不会学不动推理框架里Ollama装起来方便但并发上来以后吞吐掉得厉害要不要换vLLM模型下载下来用transformers跑得好好的为什么一上服务就崩这些困惑本质上是因为大家缺的不是单个工具的使用方法而是对整个链路里“资源消耗从哪来、瓶颈在哪”的判断力。这篇文章的核心就是想把这层判断力交给你。2. 预训练与增量训练的底层逻辑数据、算力与并行2.1 预训练到底在做什么如果你把预训练简化到极致它就是一个很大的“下一个词预测”任务给定前面一段文本让模型预测下一个token是什么然后拿预测结果与真实文本做交叉熵损失反向传播更新参数。这个目标看着简单却能让模型从万亿token里学到语法、事实、推理能力甚至一部分世界模型。但训练数据不是简单堆文本。一套成熟的预训练管线要做超大规模的清洗、去重、语言配比和领域配比。混入多少代码数据、多少中文语料、多少数学数据直接影响模型的下游表现。这也是为什么很多团队做增量训练时发现效果很差根子往往不是训练代码有问题而是数据配比出了问题。预训练的另一个特点是训练轮数极少。大多数基础模型的训练epoch在1到2之间因为海量token已经足够模型收敛多轮并没有带来信息增益反而容易让模型“背下来”损害泛化能力。这点和后面微调的习惯非常不一样如果你拿CV训练里跑几十个epoch的思路去预训练大模型基本会翻车。2.2 分布式训练的必要技术张量并行、流水线并行、ZeRO/FSDP7B模型的BF16权重就要占14GB显存配合优化器状态、梯度和激活值单卡训练几乎不现实。想要在有限硬件上训练就必须上一个或多个系统。数据并行最常见每张卡放一份完整模型副本各自吃不同batch然后做梯度同步。它简单高效但每张卡都要完整放下一份模型显存成本很高。为了解决这个痛点ZeRO和PyTorch FSDP的做法是分片把优化器状态、梯度甚至参数切到多卡上需要用的时候再聚合。如果模型是7B/13B级别单机多卡用FSDP通常最省事。你要是手头只有几张消费级卡这也是最该优先掌握的。张量并行的思路是把Transformer某一层的矩阵按列或按行切开让不同GPU共同完成一件矩阵乘法。这种切法通信量很大一般要求GPU之间走NVLink这种高速互联适合单机多卡场景。流水线并行则是把不同层分给不同GPU数据像流水线一样依次流过各卡通信压力小但存在天然的流水线气泡。超大模型训练通常把数据并行、张量并行、流水线并行组合成3D并行再配合ZeRO落地。如果你不是要训练上百亿以上的模型我的建议是别一上来就搭Megatron三层并行先用NVIDIA官方推荐的FSDP或者DeepSpeed ZeRO-3跑通小规模实验资源不够再逐步加并行度。并行度越高调试成本和通信开销越大不一定划算。2.3 增量训练补知识但别指望它改变行为增量训练又叫领域预训练或继续预训练本质是拿领域语料接着做next token预测。它的典型场景是企业内部语料有大量专业术语和行业知识通用模型没见过希望通过继续训练把知识“记”进去。这里有个常见误区“我拿业务问答数据做增量训练模型应该就能回答业务问题了。”不对。增量训练只能让模型见过这些内容不一定能学会回答问题的格式。真正让它学会对话格式的是后面的指令微调SFT。正确顺序通常是先做领域增量训练再做指令微调让模型既知道知识又知道怎么回答问题。增量训练要注意三点。第一学习率要压得非常低通常是初始预训练学习率的十分之一甚至更低否则会快速破坏原有能力。第二领域语料要和通用语料混合着来比如一份领域语料对一份通用语料防止灾难性遗忘。第三做数据时要保持语料的多样性和格式统一不要全是同一模板的重复文本否则模型很容易训歪。3. 微调方案的选型与实操全量、Freeze、LoRA怎么挑3.1 三种微调方法对比别再凭感觉选微调的本质是在通用模型基础上更新参数不同方案的核心区别是“更新哪部分参数”。围绕这个话题全量微调、Freeze微调、LoRA微调一直是检索量最大的三兄弟。先看全量微调。它更新模型全部参数理论上效果上限最高尤其适合需要强任务格式适配、数据量很大的场景。但代价是训练过程的显存开销非常大即使使用FSDP混合精度7B模型也常常需要多张48G以上的卡。如果你有充足硬件并且希望模型彻底改变风格全量微调可以选。Freeze微调的做法是冻结大部分层只训练靠近输出的若干层或部分注意力模块。它的显存占用比全量低但存在“头尾难以兼顾”的问题能用的人设变了但能力上限容易被冻结住通常效果不如全量也不如LoRA。现在很多团队已经直接用LoRA替代它。LoRA微调是目前事实上的标准方案。模型原有权重被完全冻结只在每一层旁边插入低秩矩阵作为可学习参数训练时只更新这些少量参数推理时再把低秩矩阵合并回原始权重几乎不增加推理开销。7B模型用LoRA微调显存需求可以从全量的几十GB压到十几GB甚至更低普通24G显卡就能跑。我的选型建议很简单在自己能承担的最大显存范围里优先选LoRA。先跑通数据验证和效果测试如果数据量很大、风格改造需求非常彻底再考虑全量微调。Freeze微调如今更多作为历史方案用于对比除非你有一些特殊原因比如目标模块固定在深层否则不推荐作为首选。3.2 LoRA原理拆解和显存计算思路LoRA论文给了很直接的解释预训练模型的权重更新过程往往是低秩的也就是说虽然模型参数空间很大但真正有效的最优路径落在一个低维子空间里。因此不需要更新完整的高维矩阵只要训练两个低秩矩阵A和B的乘积近似表达增量就好。假设某一层的权重W是d乘dLoRA把增量拆成B乘AB的维度是d乘rA是r乘dr远小于d。训练时冻结W只更新A和B推理阶段可以显式地算W等于W加BA好像从不曾加过LoRA一样。如果你把一个7B模型上千亿参数压到只训练几百万参数模型照样能适配指令数据。理解这个原理你就明白为什么LoRA有三个关键参数。rank r直接决定表达容量r太小学不到位r过大训练慢还容易过拟合。alpha是缩放系数会乘到低秩矩阵的更新结果上直观理解成“学习步长放大倍数”。target_modules则决定往哪些线性层插适配器常见选择是query、key、value、output和gate。一般先上q、k、v、o如果想提升表达能力再把gate、up、down加进去但不要盲目全加否则显存和可学习参数量都会上涨。显存预算也可以粗算一次。以7B模型为例如果用LoRA微调BF16权重本身约14GB反向传播需要保存少量梯度和LoRA参数再加上激活值如果不开gradient checkpointing24G卡很容易爆开了之后单卡24G基本能跑。如果改用QLoRA把基础模型压到4bit激活和梯度再省一截甚至16G左右的消费卡也能尝试但省显存会带来训练速度下降和少量精度损失。14B到70B的模型则建议直接用QLoRA或上多卡分布式。3.3 用Llama-Factory快速微调一个可用的Qwen模型实际动手时如果从零写训练脚本会面临很多坑数据格式模板、tokenizer的chat template、包装数据、Gradient checkpointing开关、分布式启动每个地方都会出错。Llama-Factory这类开源工具把很多重复工作收敛成了配置和命令非常适合快速验证。首先把项目clone下来并安装依赖这里有个容易错的地方是额外安装flash-attention-2能明显提速但同时要求CUDA环境正确。如果你的CUDA版本和PyTorch不匹配训练会在attention阶段莫名报错。安装完成后数据的注册是关键一步。Llama-Factory要求先把数据集写到data/dataset_info.json里并在messages等字段中标注内容列而不是把JSON直接扔给命令行。假设你要微调Qwen2.5-7B的指令模型可以用类似下面的命令llamafactory-cli train \ --model_name_or_path /models/Qwen2.5-7B-Instruct \ --stage sft \ --finetuning_type lora \ --dataset custom_sft_data \ --template qwen \ --cutoff_len 2048 \ --learning_rate 2e-4 \ --num_train_epochs 3 \ --per_device_train_batch_size 2 \ --gradient_accumulation_steps 4 \ --output_dir outputs/qwen_lora_zh \ --gradient_checkpointing true \ --lora_rank 32 \ --lora_alpha 64 \ --lora_target_modules q_proj,k_proj,v_proj,o_proj,gate_proj,up_proj,down_projLlama-Factory也提供Web UI版本执行CUDA_VISIBLE_DEVICES0 python src/train_web.py后会启动一个图形界面可以直接选择模型、数据集、微调方式和训练参数对新手更友好。但我始终建议提交训练任务前先在界面里打开“Preview”看一下数据转换后的实际内容确认system、user、assistant三段内容没有被错误套模板。曾经遇到过数据格式没问题但因为模板值选错训练时把每一条历史对话都当成新对话导致模型学了一堆错误拼接文本。数据格式方面如果你用Alpaca格式字段通常是instruction、input、output如果你用ShareGPT形式则更贴近真实多轮对话。业务数据里的一个高频问题是指令太短、答案太长且带格式噪声。发现微调后模型输出越来越像营销号时先去清洗数据而不是急着加大rank。3.4 Mac、低显存环境到底能不能微调很多人问到MacBook能不能用来LoRA微调它能跑但不建议作为主力训练机。M系列芯片的统一内存架构让大模型在CPU内存里加载权重比普通PC有优势配合MLX这类专门优化的框架可以跑7B甚至13B的低参数量微调实验。但CUDA生态里的flash-attention、deepspeed并行在Mac上都不能直接用训练速度大约是主流NVIDIA卡的几分之一。我自己的建议是Mac适合快速做数据集验证和单步forward测试真正需要训练还是租一张云GPU更划算。这个判断往往比优化训练代码更能省时间。4. 推理框架选型与工程落地从权重到高可用服务4.1 为什么推理也要单独讲“框架”而不是直接用transformers模型训练完之后你拿到的是一堆权重。很多人一开始会自然想到用transformers的generate函数跑推理从功能上它当然可以但生产场景不行原因在于推理是自回归的模型每次只生成一个token需要重新读取之前的所有KV状态。如果不做缓存长文本生成会越来越慢显存里也会堆积大量无用的中间张量。现代推理框架的核心优化基本围绕三件事。第一是KV Cache把已计算的历史key和value缓存下来避免重复计算。第二是连续批处理新请求不必等当前批次整体生成完可以随时插入显著提高GPU利用率。第三是显存管理vLLM引入的PagedAttention借鉴操作系统的分页思想把KV Cache切成更小的块按需分配减少显存碎片浪费。理解这几个点之后你就知道为什么Ollama适合个人本地用而高并发服务一般选vLLM不是Ollama代码写得不好而是它的定位偏轻量易用并没有把吞吐优化做到极致。所以选推理框架时先想清楚自己的场景是给几个人提供本地问答服务还是给外部业务提供几十上百并发请求的API。框架核心特点建议场景vLLM高吞吐、PagedAttention、OpenAI兼容API生产环境API服务并发高SGLangRadixAttention、结构化输出优化复杂Prompt共享、Agent场景TensorRT-LLMNVIDIA深度优化、编译成TensorRT引擎对性能要求极高的专项部署llama.cpp / llama-serverCPU和混合设备友好消费级显卡、Mac本、嵌入式Ollama安装极简、管理模型方便本地体验、轻量应用、学习transformers开发友好、性能平庸测试、调参、跑通流程4.2 用vLLM搭一个面向生产环境的OpenAI兼容APIvLLM是我目前在生产环境用得最多的框架。它装起来不复杂关键是把模型路径、显存上限和最大序列长度配置合理。拿7B模型举例可以这样启动服务python -m vllm.entrypoints.openai.api_server \ --model /models/Qwen2.5-7B-Instruct \ --served-model-name qwen25-7b \ --dtype bfloat16 \ --max-model-len 8192 \ --gpu-memory-utilization 0.9 \ --tensor-parallel-size 1 \ --host 0.0.0.0 \ --port 8000这里--gpu-memory-utilization不能直接设成1.0因为GPU还要留出一部分内存做激活值、临时张量和运行时开销设得过高启动时可能通过显存预检但一到真实请求就OOM。我之前就遇到过因为把这个参数调到0.98导致并发请求时偶发崩溃的情况降回0.9就稳定了。--max-model-len决定模型能处理的最大上下文同时也决定KV Cache的预留策略调得越大能并发的请求数越少。如果业务中绝大多数请求都在几千token以内不建议硬上32K留更大的batch空间往往对吞吐更友好。客户端调用可以直接使用OpenAI SDK设置base_url为http://你的服务地址:8000/v1。容易踩坑的地方在于served-model-name要和服务端定义一致否则客户端会提示模型不存在不要直接拿原始模型目录名去猜。如果想把模型放进单张卡里跑更大参数的模型一般会给推理框架配量化方案最常见的是AWQ和GPTQ。AWQ按激活值的统计信息挑选重要通道量化后推理速度没有明显下降但存储和显存都会减少不少。一个14B模型如果以AWQ INT4格式部署显存占用大约只要BF16版本的一半左右。不过量化不是免费的如果你需要模型输出严谨的代码或数学推理建议先跑一轮评测看看量化后的效果是否可以接受。4.3 Ollama和AnythingLLM本地知识库的正确打开方式推理框架并不只是面向后端API的技术人很多需求其实落到“本地知识库客服”上。比如有人会问“AnythingLLM可以训练模型吗”答案是不能它是一个基于大模型的RAG工作台负责把文档切片、向量化、检索再组合Prompt交给底层大模型回答问题。它本身不训练模型而是调用Ollama或其他推理框架暴露出的接口。这里其实有一个特别值得强调的工程判断当你想做一个内部AI问答助手优先考虑组合RAG和提示词工程而不是一上来就微调模型。RAG适合知识持续变化、答案依赖外部文档的场景比如产品手册、官网FAQ、内部知识库。微调则适合模型表达风格、输出格式、固定指令需要固化的场景。把“知识补充”塞进微调会带来更新成本高、知识容易过期的问题把“风格改变”寄托在RAG上Prompt会越来越臃肿且不稳定。只要你的模型体积没有大到单机跑不动推荐这种组合方案Ollama负责本地模型推理提供OpenAI兼容接口AnythingLLM负责文档管理与向量检索上层客服流程只做Prompt组织。整个链路的好处是更换模型非常方便模型从7B升级到14B时不需要改动RAG逻辑。这比每次业务变化都重新微调省太多事了。5. 落地过程中的常见问题与调优实录5.1 微调时遇到OOM和Loss异常该怎么办大模型微调最常见的问题就是显存不够。遇到CUDA OOM不要急着加钱买卡先检查这几个方向per_device_train_batch_size是否设置成大于1在小卡上把它降到1通常能直接救回来gradient_accumulation_steps是用来做梯度累积的它不影响显存只影响等效batch size所以OOM时可以把它调大同时保持总batch不变gradient_checkpointing是否开启它用计算换显存开启后显存可能降低20%到40%。Loss异常也有规律可循。如果Loss一开始就很小但不再下降很可能是数据集里大量样本的标签和输入没有对应上模型学到的是捷径。如果Loss前期正常但几个epoch之后反而上涨大概率是学习率太高或者模型在死记训练集需要调低学习率并加一点早停。一个我在项目里反复使用的“冒烟测试”方法构造一条样本单条数据过拟合几次迭代如果Loss能降到很低、预测完全正确说明代码链路没问题再换成全量数据去训练。这条经验能帮你把代码问题和数据问题快速隔离。5.2 推理阶段容易被忽略的配置问题推理框架部署时崩溃经常不是网络或服务配置而是模型权重加载和推理框架不匹配。比如某个模型在Hugging Face页面标注推荐模板是ChatML但你在服务里没有设置对应的template启动后模型能回复但每条消息都怪怪的第一轮还好多轮就逐渐崩。遇到这类问题时先打开框架日志看一下它加载的chat template到底是什么以及实际构造出的Prompt是什么样的不要盯着生成文本猜测。另一个容易被忽略的是解码参数。生产环境里你会看到有人设了temperature为0.1甚至0这是为了稳定性但太低会让代码和复杂任务表现变差。更干净的方案是使用top_p并控制max_tokens还要记得设置合理的超时时间。vLLM服务端虽然设置了max-model-len但单个请求的超时和重试策略往往容易忘了配置高峰时一个慢请求可能拖垮整个网关。这些工程细节比模型本身的差别更能决定系统稳定性。5.3 怎么判断微调和推理方案是否达标最后聊评估。很多团队微调一个星期觉得模型“聪明了”一问效果好在哪说不出来。我见过有人在没有独立验证集的情况下拿着训练集里的对话问模型得到的回答自然漂亮但这不能说明模型真的学好了。评估至少需要做两层。第一层是在公开基准或自有验证集上做指标测试语言模型常用的包括通用能力评测集、代码类任务和数学类任务按你的业务场景选几套就行。第二层是人工盲测把微调前后、不同方案的输出放在同一页面不看来源打分重点看是否遵循指令、是否遗漏要点、有没有幻觉。如果你在做一个客服场景可以准备30条典型用户问题按每轮对话分别打分。这里也可以顺便解释一个容易混淆的点目标检测训练里有mAP、nnU-Net训练有Dice它们都是任务专属的评估指标而大模型微调在业务指标上很难只靠一个数值解决因为语言生成质量本身是多维度的。与其花精力追求某个基准分数的百分位提升不如花时间搭好验证集让每次迭代都能回答一个问题这次改动到底有没有让模型变得更好用。这个习惯一旦建立后面所有训练配置调整都会少走非常多弯路。我在实际项目里见过太多团队把时间花在堆rank、调学习率、换更大的基座模型上最后发现数据质量才是真正的瓶颈。大模型训练、微调、推理这条链路看着庞杂核心逻辑却很单纯数据决定上限工程决定下限。对绝大多数团队来说最优路径不是复刻一次预训练而是用一个小而干净的数据集做LoRA微调再用vLLM或Ollama把服务稳定跑起来把验证集做扎实。等你走完这一轮再回头看到“全量微调和LoRA怎么选”“推理框架该用哪个”这类问题时就不需要看任何人的结论因为你自己已经能用资源和效果去衡量了。