这几年在大模型项目上踩过的坑比很多人预想的要多得多。从最初拿着开源的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 PretrainingCPT。它的做法是在开源底座权重的基础上用领域语料继续做下一词预测训练让模型“多读”一些你的行业文档、专利、技术手册、日志文本从而补齐领域词汇和专业知识。CPT的参数设置和全参微调很像但学习率要更低通常设为标准微调的十分之一到五分之一比如标准微调用2e-5CPT用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 rank8到16数据量小用8数据量上万用16再大收益递减LoRA alpha通常设为rank的两倍我用16rank8时学习率1e-4到2e-4LoRA通常比全参微调大一个数量级训练轮数epoch3到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个人电脑本地玩耍选OllamaMac生态选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精度字节数是2INT8是1INT4约0.5。按这个公式你在决定用什么模型之前先算一遍自己的显存能不能兜住能省很多折腾。吞吐评估也别忘了单卡7B模型在vLLM下一般能达到每秒20到60个token但这是依赖输入输出长度和并发数的做容量规划时最好用真实业务数据压测。4.3 量化技术的选择AWQ、GPTQ、4-bit、FP8到底怎么选量化就是把模型权重从高精度压缩到低精度用少量精度损失换显存和速度。目前主流方案有GPTQ、AWQ、BitsAndBytesNF4、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路线图”把每个环节的选型、参数、风险都写下来再开始跑实验。如果你现在正准备做大模型项目不妨也先把这张图画出来——它会帮你省下几周甚至几个月的弯路。