大模型训练、微调与推理，这两年几乎成了每个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/FSDP
7B模型的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乘d，LoRA把增量拆成B乘A，B的维度是d乘r，A是r乘d，r远小于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 checkpointing，24G卡很容易爆；开了之后单卡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_DEVICES=0 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服务，并发高 |
| SGLang | RadixAttention、结构化输出优化 | 复杂Prompt共享、Agent场景 |
| TensorRT-LLM | NVIDIA深度优化、编译成TensorRT引擎 | 对性能要求极高的专项部署 |
| llama.cpp / llama-server | CPU和混合设备友好 | 消费级显卡、Mac本、嵌入式 |
| Ollama | 安装极简、管理模型方便 | 本地体验、轻量应用、学习 |
| transformers | 开发友好、性能平庸 | 测试、调参、跑通流程 |
4.2 用vLLM搭一个面向生产环境的OpenAI兼容API
vLLM是我目前在生产环境用得最多的框架。它装起来不复杂，关键是把模型路径、显存上限和最大序列长度配置合理。拿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怎么选”“推理框架该用哪个”这类问题时，就不需要看任何人的结论，因为你自己已经能用资源和效果去衡量了。
