这几年在大模型项目上踩过的坑，比很多人预想的要多得多。从最初拿着开源的7B模型做垂直场景适配，到后来被业务方追问“能不能训练一个我们自己的模型”，再到被运维同事拿着日志问“为什么并发一上来就超时”，我发现自己反复在讲同一张流程图——大模型的预训练、微调、推理和开源二次开发。Loongwise就是基于这些项目经验沉淀下来的一套梳理方式，它不是我发明的什么框架，而是把这条技术路线从上到下捋清楚的一种视角。
这篇文章不打算堆论文公式，也不准备做模型排行。我想把这条链条讲透：预训练、微调、推理、开源二次开发各自到底在解决什么问题，选型时应该盯哪些指标，实操中哪些参数必须捏死，以及开源二次开发真正的边界和坑在哪里。适合刚接触大模型、准备做垂直场景落地的算法工程师，也适合业务团队里需要理解技术边界的产品和技术负责人。看完之后，你应该能自己判断：一个具体需求，到底该走预训练、微调、还是干脆别碰大模型。
1. 大模型落地前，先把整条技术路线在脑子里摆正
很多人一上来就问“用什么模型”“怎么微调”，但如果你不知道预训练、微调、推理三者之间是接力关系，选型和调参就是盲人摸象。我见过不少团队，拿着一个没经过领域适配的底座模型硬跑业务，效果不好就反复调prompt，最后归咎于“大模型不行”。实际上问题多数出在链路错位。
1.1 预训练、微调、推理到底各自解决什么问题
预训练解决的是“语言能力”问题。模型在海量语料上通过自监督学习，学会了词法、句法、常识、世界知识，这时候的模型是一个“通识专家”，什么都知道一点，但什么都不专。它的产出是底座模型权重，比如Llama系列、Qwen系列、DeepSeek系列，这些权重可以开源，也可以闭源自用。
微调解决的是“能力对齐”问题。底座模型虽然懂语言，但未必会听指令、未必知道你的业务术语、未必按照你的输出格式工作。微调用一批“输入-期望输出”的标注数据，把模型从“会聊天”掰到“会干活”。这个阶段产出的是适配特定任务的模型，比如客服模型、法律问答模型、工业缺陷识别模型。
推理解决的是“落地服务”问题。训练出来的模型只是一堆浮点数，要对外提供服务，必须经过推理引擎加载、显存管理、并发调度、量化压缩，才能以可接受的延迟和吞吐对外输出结果。很多团队在训练上花了大力气，最后栽在推理上——模型质量不错，但跑不起来、跑不快、并发一高就崩。
这三者不是孤立的。预训练决定模型能力上限，微调决定业务适配度，推理决定落地成本。Loongwise分析技术路线时，第一件事就是把需求拆到这三个环节里，看短板出在哪一环，而不是盲目追求“最强的底座模型”。
1.2 Loongwise视角下的技术选型路线图
拿一个具体的业务需求来举例。假设你要做一个工业AI检测系统，要识别产线上的服装瑕疵。我先问三个问题：第一，通用大模型能不能直接干这件事？答案是不能，因为工业瑕疵图片和缺陷描述不是通用语料里常见的内容，而且输出格式要求严格。第二，需不需要从头预训练一个模型？大概率不需要，除非你的场景极度特殊且数据量足够大。第三，微调之后怎么部署？如果是产线边缘侧，要考虑单卡推理、实时性、离线运行。
所以Loongwise给出的通用路线图是：先评估底座模型，优先选择中文能力强、生态好、社区活跃的开源模型，比如Qwen系列；然后判断是否需要继续预训练来补领域知识，还是直接微调对齐任务；微调完成后，根据硬件条件选推理引擎，量化到合适精度，最后封装成标准API或边缘服务。这条路线的核心是“按需分层”，不把资源浪费在不需要的环节上。
很多开源模型其实已经做得很好，盲目从零预训练基本是在烧钱。以7B模型为例，预训练需要约1到2万亿token，即便用A100集群，也要跑数周，成本高达百万级。而用开源底座做领域继续预训练，只需几十亿到几百亿token，成本降两三个数量级。这就是为什么“开源二次开发”成为绝大多数项目的现实选择。
2. 预训练：不是只有从零训练这一条路
预训练这个词在社区里经常被误读。一提到预训练，很多人就想到几万张显卡、几千亿token、几个月的训练周期，觉得那是大厂专属。实际上预训练分几个档次，和你手里的资源直接相关。
2.1 从零预训练的现实门槛
从零预训练一个模型，门槛主要在三块。第一是数据，你需要清洗和配比数万亿token的高质量语料，还要考虑去重、毒性过滤、语种配比，这一块没有成熟团队踩坑，很容易把模型训“脏”。第二是算力，以Llama 2 7B为例，在4096序列长度下训练约1.4万亿token，至少需要几百张A100连续跑几十天，中间还要处理节点故障、梯度同步、loss spike。第三是工程，分布式训练框架的选择、混合精度策略、学习率调度、重启恢复，每一个环节都能让训练直接报废。
所以我的建议很直接：除非你是做学术研究、有充足的算力预算，或者你的业务场景在开源模型中完全找不到影子，否则不要轻易从零预训练。多数业务团队既没有数据工程能力，也没有训练运维能力，硬上只会得到一个比开源模型更差的底座。
2.2 继续预训练：领域适配的花钱最优解
比从零预训练务实得多的方案是继续预训练，英文叫Continue Pretraining（CPT）。它的做法是在开源底座权重的基础上，用领域语料继续做下一词预测训练，让模型“多读”一些你的行业文档、专利、技术手册、日志文本，从而补齐领域词汇和专业知识。
CPT的参数设置和全参微调很像，但学习率要更低，通常设为标准微调的十分之一到五分之一，比如标准微调用2e-5，CPT用2e-6到5e-6。原因是底座模型已经收敛得很好，过大的学习率会破坏原有知识，造成灾难性遗忘。训练数据配比也要注意，一般建议领域语料与通用语料混合，比例在1:1到1:4之间，纯领域语料容易让模型“偏科”，导致通用能力明显退化。
CPT的适用场景是：模型在你的领域里频繁出现陌生术语、缩写、格式，比如医疗病历里的诊断编码、法律条文里的条款结构、半导体设备里的工艺名词。这种情况直接微调效果有限，因为微调主要对齐“指令-输出”，并不负责把新知识塞进模型参数。先用CPT补知识，再微调对齐任务，才是完整打法。
2.3 开源预训练权重怎么选、怎么下、怎么验证
用到开源权重时，最常见的问题反而是“怎么选”。这里不需要把排行榜翻个底朝天，先看三点：一是中文能力，重点看C-Eval、CMMLU这些中文基准；二是许可证，有些模型只允许研究使用，商用需要单独授权；三是社区生态，权重下载渠道、微调工具兼容性、推理引擎支持度直接决定你后续的省心程度。
下载权重之后，不要直接拿去微调，先做一步验证。用几组典型的业务问题问一遍，记录baseline表现；再跑几个标准benchmark，确认下载的权重没有损坏、和官方报告大致吻合。我遇到过团队下载了被二次打包的权重，里面夹带了恶意修改，训练出来效果诡异，排查了三天才发现权重本身有问题。所以尽量从官方仓库下载，下载后比对哈希值，别贪方便从网盘转存。
另外需要提醒的是，预训练权重的显存占用往往比推理阶段大得多。7B模型用FP16加载，仅权重就占14GB显存，加上优化器状态、梯度、激活值，训练时显存需求是推理的3到5倍。这决定了你的微调策略，也直接影响硬件选型，下面会详细展开。
3. 微调实操：从LoRA到全参，主流微调工具框架选型与实战
微调是整个Loongwise路线里文章最多的环节，也是我最想展开讲的。因为这里面的坑不是“学不会”，而是“不知道有坑”。
3.1 你需要的到底是SFT、LoRA还是QLoRA
先理清三个概念。全参微调（Full Fine-tuning）是让所有参数都参与梯度更新，效果上限最高，但显存和算力开销也最大，7B模型在FP16下全参微调需要至少60GB以上显存。LoRA微调是冻结原模型，只训练注入的低秩矩阵，显存需求大幅下降，7B模型在16GB显存上就能跑，效果在多数场景下逼近全参。QLoRA则是在LoRA的基础上，把底座模型量化到4-bit再训练，进一步把显存压到8GB甚至更低。
你该选哪种？我的判断标准是：如果你有单张24GB以上显存的显卡，优先LoRA；如果只有16GB甚至8GB，用QLoRA；如果显存非常充裕且追求极致效果，可以考虑全参微调，但要承担灾难性遗忘的风险。绝大多数业务场景，LoRA已经足够，因为它本质是在底座能力之上修出一条适配业务的“小路”，而业务数据量通常也就是几千到几万条，远不足以支撑全参更新。
3.2 主流微调工具框架选型：LLaMA-Factory、Axolotl怎么做取舍
微调工具这几年迭代很快，主流选择集中在LLaMA-Factory、Axolotl，还有各家官方的训练脚本。LLaMA-Factory在我实际使用中最省心，它对Qwen、Llama、DeepSeek等主流模型做了大量适配，提供了统一的数据格式，支持LoRA、QLoRA、全参微调，而且带WebUI，新手也能上手。Axolotl更偏向工程化、声明式配置，适合需要高度定制训练流程的团队，但对初学者不友好。
选型我给一个实操建议：个人开发者或小团队，直接用LLaMA-Factory，它能让你在半天内跑通一个LoRA微调；如果团队有专门的训练工程师，需要精细控制数据采样、学习率调度、评估逻辑，再考虑Axolotl或自研脚本。不要一上来就自己写训练循环，pytorch底层API暴露的问题很多，踩坑成本太高。
数据格式是工具适配的关键。LLaMA-Factory的alpaca格式长这样：
[ { "instruction": "请判断这个服装图片是否存在瑕疵", "input": "图片描述或图片路径", "output": "存在，左袖口有污渍" } ]实际使用中，我会把业务数据统一整理成这个格式，再按8:1:1切分训练集、验证集和测试集。注意，验证集不能省，很多人嫌麻烦直接全量训练，结果loss降到很低，泛化却一塌糊涂。
3.3 LoRA微调实战：参数设置与训练技巧
拿我之前做过的一个服装瑕疵识别问答场景举例。底座用的是Qwen2.5-7B，数据是3000条人工标注的缺陷描述和整改建议。LoRA关键参数我直接给出一份可复用的配置：
- LoRA rank：8到16，数据量小用8，数据量上万用16，再大收益递减
- LoRA alpha：通常设为rank的两倍，我用16（rank=8时）
- 学习率：1e-4到2e-4，LoRA通常比全参微调大一个数量级
- 训练轮数（epoch）：3到5轮，小数据量5轮，数据量大3轮足够
- batch size：在显存允许下尽量大，我当时用8
- 梯度累积：显存不够时，可以用累积步数把有效batch size补回来
- 序列长度：文本类任务看业务需要，图片问答需要更大序列，要权衡显存
训练过程中，我最常盯的三个指标是训练loss、验证loss和人类盲评。有人只看训练loss降低就觉得成功了，这不对。LoRA训练到后期，训练loss可能趋近于0，但验证loss如果回升，说明已经过拟合。此时应该早停，或者加大数据增强/正则。
一个容易忽略的坑是Qwen系列模型的对话模板。同一句话，不同模型的prompt模板格式差距很大，Qwen需要加上特定的system和角色标记。如果用了错的模板，微调会训练得很好，但推理时输出却非常奇怪。LLaMA-Factory已经内置了模板支持，但如果你自己写推理脚本，一定要确认chat template和训练时一致。
3.4 数据质量与对话模板：容易被忽视的隐藏变量
微调圈有句话叫“垃圾进，垃圾出”，但“垃圾”的表现形式常常很隐蔽。最常见的三种：第一是标注不一致，同一类型的缺陷，有的标注写“轻微脏污”，有的写“小瑕疵”，模型学到的就是混叠标准；第二是输出格式不统一，有的答案带上“根据图片分析”，有的直接给结论，模型会学乱；第三是分成不当，把包含错误信息的样本混进训练集。
解决数据问题没有捷径，只能靠标注规范和多轮质检。我建议每条标注至少两人交叉确认，分歧样本单独讨论。对输出格式，尽量做强制约束，比如把格式要求写进instruction，并且保证所有标注都严格遵循这个格式，模型才能学会稳定输出。
模板问题再强调一次。很多人拿开源模型跑推理时，直接用最简单的“user: xxx, assistant: xxx”拼接，这在非微调场景下问题不大，但一旦做SFT或LoRA，模板必须和训练完全一致。有一个笨但可靠的办法：微调跑通后，先用训练集里的样本跑一遍推理，对比输出结构是否和预期一致，再上真实业务数据。这一步能挡掉一大半“白训了”的悲剧。
4. 推理部署：让微调好的模型真正跑起来
模型训完了，不等于能上线。推理部署是整个路线里最容易被低估的环节。我在项目里亲眼见过，一个微调效果很好的模型，因为推理引擎选错，单卡并发只有个位数，延迟直接飙到几十秒，最后被业务方一票否决。推理不是加载个权重那么简单，它涉及显存规划、量化、批处理策略、服务框架选型。
4.1 推理引擎选型：vLLM、Ollama、MLX、AirLLM怎么选
推理引擎这块，社区里叫得上名的很多，但它们的定位完全不同，选错了就是灾难。vLLM是目前生产环境最主流的方案，它通过PagedAttention和连续批处理优化吞吐，适合高并发、多用户场景，也是我把微调模型上线时的首选。Ollama适合个人电脑本地玩，一条命令拉起一个模型，交互式体验好，但不适合做高并发的生产服务，它的吞吐和延迟控制能力比vLLM弱。
MLX是苹果平台上的推理框架，专门为Apple Silicon优化，在Mac上跑Qwen 3.8/27B这类模型，4-bit量化后体验相当自然，适合做本地原型验证。AirLLM我试过几次，它的思路是用磁盘和CPU帮显存分担压力，让低配置电脑也能跑大模型，但速度真的慢，只适合偶尔用一次的实验场景，不适合持续服务。
选型判断很简单：生产服务选vLLM，个人电脑本地玩耍选Ollama，Mac生态选MLX，极限低配置跑大模型才考虑AirLLM。如果你是在线服务，别用Ollama做后端，它的continuous batching能力不足，并发一上来就开始排队，这种锅我背过。
4.2 显存计算与吞吐评估：8B、27B、72B各需要什么配置
推理阶段的显存需求虽然没有训练那么夸张，但也不是简单按参数大小乘2就完事。以FP16精度为例，7B模型权重约占14GB，加上KV cache、激活值和运行时开销，实际加载至少需要16GB到20GB显存。如果只有一张12GB的显卡，就必须量化。
再拿热度很高的27B模型举例，FP16权重约54GB，单卡4090的24GB显存根本装不下，量化到4-bit后权重约13.5GB，加上KV cache能勉强放下，但要跑快还得靠MLX或vLLM的优化。72B模型在FP16下约144GB，即便4-bit量化也要36GB，通常需要多卡并行或CPU卸载，个人单卡基本跑不动。
给出一个实用的显存估算公式：显存需求 ≈ 参数量(以B为单位) × 精度字节数 × 1.2（额外开销系数）。FP16精度字节数是2，INT8是1，INT4约0.5。按这个公式，你在决定用什么模型之前，先算一遍自己的显存能不能兜住，能省很多折腾。吞吐评估也别忘了，单卡7B模型在vLLM下，一般能达到每秒20到60个token，但这是依赖输入输出长度和并发数的，做容量规划时最好用真实业务数据压测。
4.3 量化技术的选择：AWQ、GPTQ、4-bit、FP8到底怎么选
量化就是把模型权重从高精度压缩到低精度，用少量精度损失换显存和速度。目前主流方案有GPTQ、AWQ、BitsAndBytes（NF4）、FP8等。GPTQ是训练后量化，对模型做逐层校准，精度损失较小，适合追求质量的生产环境。AWQ也是训练后量化，但它根据激活值分布来保护重要权重，在商业模型上表现更稳。BitsAndBytes的NF4量化是QLoRA训练时用的默认方案，也支持直接推理，速度快但质量损失相对大一些。
我自己的经验是：4-bit量化（NF4或GPTQ）适合在8GB到12GB显存的卡上跑7B到13B模型，肉眼能感觉到一定质量下降，但多数业务还能接受；AWQ在质量上通常优于GPTQ，但推理时需要额外加载量化参数；FP8是新趋势，在H100等新卡上支持好，精度几乎无损，但旧卡不友好。量化不是越低越好，4-bit下模型的知识保留和推理稳定性都会变差，能用8-bit尽量别上4-bit，这是血泪教训。
4.4 本地部署的完整链路：从下载到API暴露
这里给一套可以直接抄的本地部署链路。第一步，下载模型权重，注意用官方仓库，并核对哈希。第二步，根据硬件条件决定是否量化，用ollama自带命令可以很方便地拉取量化版模型，或者用llama.cpp把权重转成GGUF格式。第三步，选择推理引擎，生产用vLLM，个人用Ollama。第四步，配置服务端口和并发参数，最简单的方式是起一个兼容OpenAI格式的服务。
以vLLM为例，一个可用的启动命令如下：
vllm serve Qwen/Qwen2.5-7B-Instruct \ --tensor-parallel-size 1 \ --gpu-memory-utilization 0.9 \ --max-model-len 8192 \ --port 8000启动后，服务暴露在8000端口，你可以用OpenAI SDK直接调用。这里有个常见坑：gpu-memory-utilization设太高，会导致KV cache分配不足，长文本请求直接报错；设太低，又会浪费显存。建议7B模型从0.85到0.9开始试，根据压测结果回调。max-model-len决定了支持的最大序列长度，设太大会占满KV cache，设太小又接不住长文档，需要按业务场景权衡。
5. 开源二次开发：站在巨人肩膀上的工程化改造
开源二次开发是大模型落地最现实的路径。它的核心不是改权重，而是改“模型和业务之间的接口”。权重改了叫微调，接口改了叫二次开发。很多人把两者混为一谈，其实它们的应用边界完全不同。
5.1 二次开发到底是改什么：不是改模型权重，而是改应用边界
举个例子，你基于Qwen做OCR文档理解系统。业务需要的不是模型能写诗，而是模型能稳定地把发票、合同里的关键字段抽出来，输出成JSON。这里要做的二次开发包括：设计prompt模板、写抽取的POST处理逻辑（把模型输出清洗成结构化数据）、对常见错误输出做规则兜底、甚至用少量样本微调提高抽取准确率。这一整套工程改造，就是二次开发的常态。
二次开发的边界在于“模型能力不够的部分，不能靠工程硬凑”。如果模型本身没有视觉能力，你写再多的prompt它也读不了图片；如果模型本身不具备复杂推理能力，靠思维链提示词也只能适度改善。所以二次开发之前，先诚实评估：这个任务，底座模型到底会不会。不会，就回到微调；会但输出不稳定，才用二次开发去加固。
5.2 常见场景拆解：文档理解、知识抽取、工业AI检测、股票K线分析
文档理解是目前二次开发最密集的场景。团队都希望模型直接从PDF里抽取字段，但PDF的排版解析、表格结构识别、长文档切片、跨页上下文拼接，全是工程活。主流做法是先用OCR或版面分析工具把PDF转成文本块，再用大模型做摘要和字段抽取，最后用规则校验输出字段合法性。
知识抽取场景，社区里有像OneKE这样的开源抽取框架，专门把非结构化文本转成结构化知识。这类框架多数是基于微调过的模型做的，二次开发时主要做实体对齐、关系消歧和知识库融合。工业AI检测、服装检测这类场景，反而要小心。大模型不是万能的，产线上的缺陷识别本质上是一个图像检测任务，传统视觉模型（比如YOLO系列）在实时性和精度上依然更有优势。我在工业项目里的经验是，把YOLOv11这类检测模型当主力，把大模型用在上层：用大模型做缺陷描述生成、归因分析、维修建议生成。这种“视觉模型+大模型”的分层架构，才是工业落地的最优解。
股票K线分析也很典型。很多人问“能不能用大模型预测股价”，我的回答是先泼冷水——预测不是大模型的强项，它更擅长解释。二次开发的正确姿势是：用规则或技术指标脚本识别K线形态，再用大模型把这个形态翻译成风险提示和操作要点说明。模型给你讲人话，判断还得靠你自己的策略和纪律。
5.3 开源生态的许可证边界与商业化红线
开源二次开发最容易踩的法律红线是许可证。同样叫“开源”，有的许可证允许商用，有的只允许研究。Llama系列、Qwen系列、DeepSeek系列各自的商用条款不一样，做产品前必须逐条确认。特别是那些声称“免费可商用”的模型，要看清是否有附加条件，比如月活用户超过一定数量需要单独申请授权。
我的建议是：在做技术选型时，就把许可证合规作为一个硬性筛选条件，别等项目上线了再补救。融资或对外的产品，法务审查会盯这块。同时，二次开发涉及的代码也要留好License声明，尤其当你是基于别人的开源项目做的改造，该保留的版权信息不能删，否则可能构成侵权。
6. 常见问题与排查技巧实录
这部分我把项目里遇到的高频问题整理成一个速查表，每条都是亲自踩过的坑，比看官方文档管用。
6.1 训练阶段的典型问题
第一个高频问题是loss不降。我遇到过一次，数据格式完全正确，但loss一直徘徊在2.5左右，怎么调学习率都没用。后来发现是数据里有大量重复样本，模型在“背答案”而不是“学规律”，把重复样本去掉后loss才正常下降。第二个问题是显存溢出。明明配置和文档一致，却总报OOM。这里要检查的是batch size、序列长度和梯度累积的组合，三者共同决定显存峰值。第三个问题是训练曲线非常平滑但验证集效果差，这几乎可以断定是过拟合，要么降epoch，要么加dropout或数据增强。
遇到问题的排查顺序也有讲究，我一般按照“数据 → 参数 → 代码 → 环境”的顺序来。先检查数据有没有空值、重复、格式错误，因为80%的问题都出在数据上；再看参数有没有用对，比如LoRA的target_modules是否正确、学习率是否合适；然后检查代码与模型版本是否匹配；最后再看CUDA版本和依赖包兼容性。环境问题通常表现为报错信息看不懂，建议先重装依赖、升级pytorch，再考虑其他可能。
6.2 推理阶段的典型问题
推理阶段最常见的问题是速度慢。如果换了vLLM还是慢，先看有没有开足够大的并发，再看是否被KV cache限制住了，最后检查是不是量化版本导致解码速度下降。另一个高频问题是输出乱码，常见原因是tokenizer和模型权重不匹配，比如你换了tokenizer文件但没同步更新，解决方法是重新下载完整模型目录并校验哈希。
还有一个容易被忽略的点是推理时的temperature参数。很多人用默认值，结果模型输出随机性太强，同样的请求每次答案都不一样。做结构化抽取这类对稳定性要求高的任务，把temperature调到0甚至0.1，能极大提升结果一致性。如果你要的是确定性输出，部分引擎还支持贪心解码（greedy decoding），彻底关闭随机采样。
6.3 一个单卡推理的真实案例
最后分享一个我最近调通的案例。一张24GB的显卡，跑Qwen 27B模型的4-bit量化版本，用MLX框架，最终实现了单卡推理。过程没有想象中顺利：第一次直接加载FP16版本，显存瞬间爆掉；换成4-bit量化后，权重占约13.5GB，还剩约10GB的KV cache空间，但并发一上来还是OOM。后来我把max-model-len从默认值调低到4096，并关闭了部分冗余的请求并发，终于稳定跑通。
这个案例想说明两件事：第一，单卡跑大模型不是不可能，关键在于量化精度、序列长度、并发三者之间的平衡；第二，别盲目追求大模型，27B在某些任务上确实比7B强，但代价是部署复杂度成倍上升。上线前先问自己，业务真的需要27B吗？7B不行吗？很多时候7B微调到位，性价比远高于27B硬扛。
我个人在实际操作中的体会是：大模型项目的成败，很少由某一个环节决定，而是整条链条的协同。预训练、微调、推理、二次开发，每一环都有它的位置和边界，跳过任何一步或者搞混它们之间的关系，都会在后面付出代价。所以我的习惯是动手之前先画一张属于自己的“Loongwise路线图”，把每个环节的选型、参数、风险都写下来，再开始跑实验。如果你现在正准备做大模型项目，不妨也先把这张图画出来——它会帮你省下几周甚至几个月的弯路。
