简介面向AI研发、NLP及法律医疗领域智能化应用的技术人员这份资料围绕LlamaFactory框架对Qwen2.5进行高效微调系统讲解垂直领域专家模型构建全流程适合希望将通用模型定制到专业行业并落地部署的工程师与研究人员。内容覆盖环境搭建、数据收集与预处理、配置文件编写、模型训练、效果评估及服务部署等环节重点解析LoRA、QLoRA等参数高效微调策略并结合法律判断与医疗诊断真实案例直观对比微调前后模型在专业任务中的表现同时拓展到法律咨询、合同审查、病历生成、健康问答等具体场景强调数据预处理质量与超参设置对最终效果的显著影响。资源为单个docx文档压缩包约39KB文档结构清晰附有可直接参考的配置示例与实操要点可引导读者按步骤复现并优化自己的微调流程。目前已有94人学习使用对希望掌握大模型垂直适配技术并快速产出行业模型的技术团队具有实用参考价值。1. 大模型微调不是玄学用 LlamaFactory 把 Qwen2.5 调成法律和医疗专家很多做自然语言处理的工程师第一次被问到“能不能把通用大模型调成法律和医疗领域的专家模型”时第一反应是必须要有 A100 集群才能动手。直到 QLoRA 把门槛压到一张 12GB 显存的消费级显卡也能跑 7B 模型LlamaFactory 又把这个过程封装成了配置文件微调技术才算真正下沉到普通开发者手里。这份资源的核心内容很具体以 Qwen2.5-7B-Instruct 为底座用 LlamaFactory 做 LoRA 和 QLoRA 微调分别在法律和医疗两套指令数据集上训练出垂直领域专家模型并覆盖从数据构造到 Ollama、vLLM 部署的完整链路。适合三类人在低显存环境下做领域微调的算法工程师给律所或医院搭建内部问答系统的应用开发者以及刚进入大模型微调领域、需要一份可复现模板的研究生。笔记里的配置参数和避坑记录都是实测过的照着走一遍就能跑通不用自己从头猜参数。2. LlamaFactory 的选型逻辑和环境搭建先把可复现的底座打好2.1 为什么是 LlamaFactory它把 Trainer、PEFT 和数据处理压缩成一套配置要说清楚 LlamaFactory 的价值得先对比其他三条路线。直接用 Hugging Face 的 Trainer 写训练循环灵活性最高但你要自己手动完成 LoRA 注入、数据集格式转换、模板适配、停用词设置这些杂活每换一个底座模型就要重来一遍时间成本远高于训练本身。用 PEFT TRL 组合比 Trainer 省事但 TRL 的 SFTTrainer 和 datasets 的 map 流程在样本量过万时容易出现各种字段匹配问题出了问题还不好定位。用 DeepSpeed Megatron 做分布式训练是完全不同的应用层级一个 7B 参数模型的单卡微调项目根本没必要上这套体系。LlamaFactory 恰好把这三条路线的优点收拢到自己这边。它底层复用 PEFT 和 transformers 的成熟实现上层提供统一的命令行和 YAML 入口。你只需要告诉它模型路径、数据集路径、微调方法和 batch 大小剩下的数据处理、模板拼接、优化器配置都是自动完成。对做实际项目的人来说还有一个容易被忽略的价值点是“训练前数据校验”启动训练时会先输出数据集的样本数量和格式检查结果格式不对会直接报错而不是跑到一半才崩。路线配置成本LoRA/QLoRA数据集管理多卡扩展Trainer 手写高自己拼装无难PEFT TRL中支持半自动中DeepSpeed 全家桶很高支持无强LlamaFactory低支持自带校验内置如果你接触过 QLoRA应该知道它的核心是把底座模型量化为 4bit再在反量化后的特征上挂 LoRA 适配器。LlamaFactory 对这套机制做了封装所以上表里才敢写“支持”。但我建议你内心始终带着“底层是 PEFT”的意识遇到文档查不到的行为时直接去读 PEFT 的源码比在 LlamaFactory 文档里找答案更快。2.2 版本依赖矩阵torch、transformers、CUDA 的搭配不能想当然版本搭配是微调项目里最常见也最隐蔽的翻车点。下面是我在 Ubuntu 22.04、NVIDIA 驱动 535 环境下验证过的一套组合conda create -n llama_factory python3.10 -y conda activate llama_factory pip install torch2.4.0 --index-url https://download.pytorch.org/whl/cu121 pip install transformers4.45.2 datasets3.0.1 tokenizers0.19.1 pip install llama-factory0.9.0我解释一下每行的用意。PyTorch 那一行必须带--index-url指向 cu121 的 wheel 目录否则 pip 默认安装的可能是不带 CUDA 支持的 CPU 版训练时会一直在 CPU 上跑速度慢到像死机。transformers 锁到 4.45.2 是因为 LlamaFactory 0.9.x 的AutoModelForCausalLM接口对这个版本适配最稳定换到 4.50 以上的新版可能出现 Qwen2.5 config 字段兼容问题。datasets 和 tokenizers 看起来不起眼但一旦版本漂移map函数内部会出现 key mismatch 报错而且报错信息不直接。如果你的显卡驱动是较老的 470 或 510 系列那 CUDA 12.1 的 torch 可能装不上需要退回cu118后缀并配合较低的 transformers 版本。这时不要硬上 QLoRA 4bit可以用 8bit 或者干脆 LoRA 16bit虽然显存压力大一点但不会在环境阶段就卡住。还有一种常见场景是 Windows 下想先本地试跑。我的习惯是先装 WSL2在 WSL2 Ubuntu 里建这套 conda 环境尽可能跟线上训练机保持一致避免 Windows 原生路径和 CUDA 版本坑影响后续排障。2.3 显存预估和量级选择7B 到 32B 在 QLoRA 下要怎么选显存需求是可以提前算出来的不用等训练时爆掉才发现。下面这张表是 QLoRA 4bit 加gradient_checkpointing开启条件下的实测区间底座模型微调方式单卡显存需求推荐 GPUQwen2.5-7BQLoRA (4bit)10~13 GBRTX 3090 / 4070 Ti SuperQwen2.5-7BLoRA (16bit)16~18 GBRTX 3090 / 4090Qwen2.5-14BQLoRA (4bit)22~26 GBA6000 / 双卡 4090Qwen2.5-32BQLoRA (4bit)42~48 GBA100 40G这里有个规律QLoRA 的显存需求不是按模型参数量线性涨的。7B 到 14B 参数量翻一倍显存只涨一倍多是因为 4bit 量化把大部分权重固定在显存里不再浮动。但一旦超过 32B量化后的前向激活值也会因为 hidden size 增大而显著膨胀那时就要认真考虑max_seq_len和 batch size 的取舍。我在项目里通常直接按“显存卡的 75% 作为安全线”来选模型比如一张 24GB 的 4090安全线大约 18GB跑 7B 的 LoRA 没问题跑 14B 的 QLoRA 就只能用 batch size 1 而且不能开评估集。显存判断还要注意一个容易忽略的点训练阶段的显存峰值比推理阶段高很多。推理时 7B fp16 模型只需要 14~16GB 左右而 QLoRA 训练时因为保存梯度、优化器状态和混合精度中间值同样模型要 12GB 以上。所以如果你的目标只是私有化部署而不是训练那完全不需要按训练标准去采购显卡。3. 法律与医疗训练集的构造从原始文档到指令对不是复制粘贴3.1 指令格式选型sharegpt 处理多轮对话alpaca 只适合单轮很多资料一上来就让你把数据整理成 JSON但没人说清楚 alpaca 和 sharegpt 两种格式的区别。alpaca 格式把每条样本拆成 instruction、input、output 三个字段适合“问题-答案”的一轮结构。下面是一个法律问答的 alpaca 示例{ instruction: 根据合同编相关条文判断这份房屋买卖合同是否有效, input: 甲与乙签订房屋买卖合同甲支付了全部价款但签约时乙尚未取得房屋所有权证书。, output: 合同效力与物权登记是两个层次。合同是否有效取决于双方意思表示真实且不违反法律强制性规定物权未登记不影响合同成立与生效。 }sharegpt 格式则是多轮消息列表系统、用户、助手三条消息按顺序排{ conversations: [ { from: system, value: 你是法律领域的专业助手请依据现行民事法律条文回答不确定时明确说明。 }, { from: human, value: 我签了购房合同但对方没有产权证这合同有效吗 }, { from: gpt, value: 合同一般自成立时生效不动产物权变动需要登记才发生效力。未取得产权证并不必然导致合同无效但要结合具体事实判断。 }, { from: human, value: 那我能不能主张违约金 }, { from: gpt, value: 可以。违约金的请求前提是合同有效且对方构成违约与产权证是否办理登记是两回事。 } ] }法律和医疗场景的用户提问天然是多轮的咨询者会追问、补充症状、改剂量所以我把两份数据集统一转成 sharegpt 格式并且把 system prompt 单独做成一个字段。这个字段直接影响模型行为法律模型的 system prompt 我写成“不确定时明确说明”医疗模型的 system prompt 写成“回答用药建议时强调必须线下就诊确认”。训练完之后你会发现模型确实开始学会在知识边界外说“这个需要结合线下检查结果判断”而不是硬编答案。另外一个细节是格式检查。LlamaFactory 启动后会告诉你每个数据集的有效样本数和预估 token 量但你需要在进入训练之前自己先看一眼 JSON 的字段闭合。常见坑是手写 JSON 时最后一条 conversations 后面多了逗号解析器直接报 JSONDecodeError白白浪费一上午。3.2 法律数据的四步流水线判决书切分、改写到倒推问题法律数据最稳定的公开来源是裁判文书网和公开的法律法规库但原始裁判文书不能直接当训练数据。我从真实项目中总结了一套四步流水线第一步抽取“案件事实”和“裁判理由”两个章节。判决书的结构比较固定可以用正则按标题切出来。第二步切分长文本。一份判决书事实部分可能有三五千字需要按语义段落切成 200~400 字的片段避免单条样本在 token 化时超过 cutoff_len。第三步把裁判理由改写成问答形式。这一步要人工介入因为裁判文书的语言是高度嵌套的直接拿来做答案模型会学出一股庭审腔。第四步倒推问题。把改写后的答案交给标注者让标注者写出自然用户可能提出的问题再把“问题-答案”对喂进数据集。为了让文本清洗可复用我写了一个针对法律文本的去噪脚本import json import re def clean_law_text(text: str) - str: # 去掉判决书里的审理程序段落只保留事实和理由 text re.sub(r(审理经过|本院认为|审判人员)[:], \n, text) # 合并连续空白 text re.sub(r\s, , text).strip() return text with open(raw_cases.jsonl, r, encodingutf-8) as f: cases [json.loads(line) for line in f if line.strip()] cleaned [] for case in cases: fact clean_law_text(case.get(fact, )) reason clean_law_text(case.get(reason, )) if len(fact) 80 or len(reason) 80: continue # 过滤过短样本 cleaned.append({instruction: case[instruction], input: fact, output: reason}) with open(law_clean.jsonl, w, encodingutf-8) as f: for item in cleaned: f.write(json.dumps(item, ensure_asciiFalse) \n)这里clean_law_text函数里的正则有两个作用一是把“审理经过”“本院认为”这类程序性标题替换成换行符让文本分成更易读的块二是把空白字符压成单空格。过滤条件len 80是为了把切碎的、不完整的句子排除掉这类噪声样本会让模型学到“对空提问给空回答”的坏习惯。保存为 jsonl 而不是 json是因为数据量大了之后 jsonl 可以一行一条流式读取训练前不需要把整个文件塞进内存。法律数据还有一个特有细节法条引用标记。我在清洗时把“合同编第X条”“民法典第X条”统一包裹成[[法条]]标记作为生成内容里的一个隐藏结构。模型会学会在引用法条时输出这个标记后续在验证阶段就能用脚本自动比对法条编号是否存在减少人工审核的工作量。3.3 医疗数据的清洗红线隐私边界和术语一致性医疗数据是敏感领域先划一条红线不要私自爬取医院的电子病历、门诊记录、带患者信息的文本即便做了脱敏也不行。合规的来源包括公开的医学教材问答章节、药品说明书里的适应症和用法、医学知识库的术语解释、医生发表在官方平台上的科普文章。这些数据虽然信息密度不如病历高但胜在来源清晰、没有隐私风险。术语一致性是医疗数据里最容易出问题的点。患者习惯说“胸口疼”“心口闷”病历里写“胸骨后压榨样疼痛”如果这些口语表达不经处理直接进入训练集模型会学到“胸口疼”和“胸痛”是两个无法互通的概念。我一般在数据管线上加一层术语归一映射term_map { 胸口疼: 胸痛胸口疼, 心口闷: 胸痛心口闷, 咳嗽: 咳嗽, 咳痰: 咳痰, } def normalize_medical_term(text: str) - str: for k, v in term_map.items(): if k in text: text text.replace(k, v) return text这里的映射逻辑是标准化术语放前面口语表达放括号里作为补充。模型既学到规范的临床语言又保留了患者描述的原始语义。需要注意的是映射表不能太激进比如“肚子疼”不要硬映射成“腹痛”因为患者语境里的“肚子疼”有时指胃痛有时指肠炎无法精确归一到单一术语保留口语反而是更安全的做法。医疗指令对的目标输出也跟法律不同。法律数据要求“可验证”医疗数据要求“保守”。我把医疗数据的 output 统一加上安全后缀比如“以上建议仅供参考请以线下医生诊断为准”。不要觉得这是废话模型在真实咨询场景里如果没有这层兜底出现一次错误用药建议就是事故。4. LlamaFactory 训练实战YAML 参数逐条拆开再跑单卡/多卡4.1 训练配置文件拆解lora_rank、学习率和 cutoff_len 的配合把数据集准备好之后训练本身其实是最不用操心的部分。下面这份 YAML 来自我微调法律医疗混合模型时实际跑通的配置model_name_or_path: /models/Qwen2.5-7B-Instruct template: qwen stage: sft finetuning_type: lora lora_rank: 16 lora_alpha: 32 lora_dropout: 0.05 dataset: law_sharegpt, medical_sharegpt cutoff_len: 2048 per_device_train_batch_size: 2 gradient_accumulation_steps: 8 learning_rate: 2.0e-4 num_train_epochs: 3 lr_scheduler_type: cosine warmup_ratio: 0.03 logging_steps: 10 save_steps: 200 output_dir: outputs/qwen25_law_medical_lora先说 lora_rank 和 lora_alpha。rank 16 alpha 32 是 LoRA 社区最成熟的起点alpha 是 rank 的两倍等于在反向传播时把低秩矩阵的贡献放大一倍。如果你只有 1 万条以内的样本rank 8 就够了样本超过 5 万条可以试 rank 32但要注意提高 rank 会显著增加过拟合风险需要同步增加 dropout 或在验证集上做早停。cutoff_len决定单条样本的最大 token 数。我设置 2048 是因为两个领域的样本大部分在 800~1800 token 之间设置太低会把长样本暴力截断让模型学到不完整的回答逻辑设置太高又会让短样本被大量 padding白白浪费算力。判断方法很简单——统计一下数据集的 token 长度分布取 P90 分位数再加 20% 余量就是合理的 cutoff_len。再看优化器相关参数。learning_rate2e-4 搭配cosine调度器和 0.03 的warmup_ratio前 3% 的步数线性升温到峰值之后按余弦曲线衰减。LoRA 需要更新的参数很少如果一开始就给 1e-3 以上的学习率loss 会在前几十步剧烈震荡然后掉进一个很差的局部最小值。如果你观察到训练的 loss 曲线像锯齿一样大概率就是这个原因。我建议你一定要在配置里加上评估集。LlamaFactory 支持eval_dataset和eval_strategy两个参数每隔一定步数跑一次验证集 loss。没有评估集的话你完全不知道模型在第几个 epoch 开始过拟合只能靠部署后的人工测试来发现那时候后悔药已经很难买了。4.2 单卡 QLoRA 启动命令逐段解释和日志信号判断单卡 QLoRA 的启动命令如下CUDA_VISIBLE_DEVICES0 llamafactory-cli train \ --model_name_or_path /models/Qwen2.5-7B-Instruct \ --template qwen \ --stage sft \ --finetuning_type lora \ --quantization_bit 4 \ --dataset law_sharegpt,medical_sharegpt \ --cutoff_len 2048 \ --per_device_train_batch_size 2 \ --gradient_accumulation_steps 8 \ --learning_rate 2.0e-4 \ --num_train_epochs 3 \ --lora_rank 16 \ --lora_alpha 32 \ --output_dir outputs/qwen25_law_medical_loraquantization_bit 4就是 QLoRA 的关键开关它会把底座模型以 4bit 加载训练过程中的张量运算反量化到 fp16回传梯度只更新 LoRA 分支。--cutoff_len 2048控制单样本最大长度。与配置文件不同的是命令行适合临时覆盖设备号和输出路径核心参数还是写进 YAML 里提交到 git 做记录方便复现。训练开始后你要盯三个信号。第一个是日志输出里的global_step确认它在增长。第二个是 loss 值从 2.0 起步逐渐往下走属于正常如果第一步就低于 0.3说明模型在背答案而不是在学推理训到三五个 epoch 后 loss 低于 0.1 时要警惕过拟合而不是开心。第三个是显存占用。QLoRA 7B 在 batch size 2、cutoff 2048 时应该在 12GB 上下浮动如果你的显存占用能装满一张 24GB 的卡说明某个参数配置有冗余常见原因是gradient_checkpointing没开。4.3 多卡和断点续跑deepspeed 配置与 checkpoint 恢复的边界大部分场景一张 3090 或 4090 就能跑到满意的效果除非你的样本量超过 5 万条且要跑 3 个 epoch否则不用急着上多卡。如果你确实要上LlamaFactory 内置了 deepspeed 支持命令变成deepspeed --num_gpus2 llamafactory-cli train \ --model_name_or_path /models/Qwen2.5-7B-Instruct \ --template qwen \ --stage sft \ --finetuning_type lora \ --dataset law_sharegpt,medical_sharegpt \ --cutoff_len 2048 \ --per_device_train_batch_size 4 \ --gradient_accumulation_steps 4 \ --learning_rate 2.0e-4 \ --num_train_epochs 3 \ --deepspeed configs/ds_z2_config.json \ --output_dir outputs/qwen25_law_medical_lora注意这里把 batch size 加大到 4、梯度累积降到 4等效 batch 大小还是 16但每张卡的吞吐量翻倍。ds_z2_config.json直接用 LlamaFactory examples 目录里自带的 ZeRO-2 配置即可不要自己从头写 zero_optimization 配置stage 参数、offload 设备参数和通信后端之间任何一个不匹配训练都不会报错但速度会慢得你怀疑人生。断点续跑也是实际项目中必会的操作。LlamaFactory 训练中断后output_dir里会留下checkpoint-xxx目录恢复训练用--resume_from_checkpoint outputs/qwen25_law_medical_lora/checkpoint-200。恢复时需要注意如果你在中途改过数据集文件或cutoff_len建议老老实实从头训因为 optimizer 状态里的 tokenizer 信息和新配置对不上。另外 LoRA 的 checkpoint 往往只保存适配器权重不保存底座恢复时仍然要指定完整的model_name_or_path。5. 避坑从 loss 不降到 Ollama 500 错误的五个现场5.1 loss 卡在异常区间不下降现象训练已经跑了 100 多步loss 稳定在 3.0 以上纹丝不动。原因比较多但我在两个项目里定位到的都是数据集问题一是训练集里大量样本的 output 字段为空或为空字符串模型每次都在学“输入就结束”无法学到有效信息二是重复样本太多模型在重复中学不出泛化规律。解决方式是训练前做一次去重和空值过滤。我一般会在数据管线末尾加一个脚本统计每个 output 的字符数和重复度低于 20 个字符的直接剔除重复率超过 30% 的样本组只保留一条。数据干净之后loss 通常会立刻掉到 2.0 以下。5.2 第一步就报 CUDA out of memory现象训练命令刚执行第一个 step就报CUDA out of memory。原因通常是cutoff_len和per_device_train_batch_size组合超出单卡显存。因为是动态 paddingbatch 里一旦混入一条接近 cutoff_len 的长样本整批的显存峰值就会瞬间抬高。解决步骤很有顺序先把gradient_checkpointing打开这能省掉一半的激活显存如果还爆把cutoff_len降到 1024再不行把 batch size 改成 1同时靠梯度累积维持等效 batch 大小。我一般不推荐一上来就降 batch因为梯度的噪声会变大训练曲线不好看。5.3 推理输出变成复读机现象模型回答到一半开始重复同一句话比如“好的好的好的”重复二十遍。原因LoRA 微调轮数偏多模型在自回归路径上过度拟合了高频 token 序列采样时一旦进入这个循环就走不出来。解决一是把num_train_epochs从 3 降到 1~2并打开评估集观察验证 loss 在哪个 epoch 开始回升二是在部署侧调高repetition_penalty。如果模型已经训完可以通过修改生成参数来控制PARAMETER repeat_penalty 1.15 PARAMETER temperature 0.3如果你部署在 vLLM则对应--repetition-penalty 1.15。这里要注意一个问题repetition_penalty调得太高会走向另一个极端模型每个词都刻意避开重复输出变得机械、词不达意1.1~1.15 通常是最平衡的区间。5.4 模型编造不存在的法条现象问“房屋买卖合同需要登记才生效吗”模型回答“根据民法典第 999 条第 3 款……”但第 999 条根本不存在。原因训练语料里法条引用和解释混在一起模型学到的分布让它认为每个解释后面都应该跟一个引用。解决清洗阶段加正则把法条编号提取出来去比对原始法条库不存在的编号整条标为不合格。在推理阶段我还会在验证脚本里做法条编号正则匹配返回一个“法条命中率”指标低于 95% 就发警报。这个方法解决不了模型整体的事实错误但至少能把“伪造法条”这个最影响信任的问题压住。5.5 Ollama 运行报 500 internal server error现象模型导出后在 Ollama 里ollama run qwen2.5直接报500 internal server error有些场景下第一次运行正常第二次就报错。原因八成是 GGUF 文件有问题要么是转换时参数不对导致量化表损坏要么是模型文件在重新下载时被截断另外就是 Ollama 的 llama.cpp 运行时对某些低 bit 量化等级支持不稳定比如q2_k在这种场景下最容易崩。解决顺序如下ollama serve ollama logs先看日志里有没有gguf或ggml字样。如果有确认是模型文件问题后回到 LlamaFactory 侧重新导出用 fp16 全精度导出再用 llama.cpp 的 quantize 工具手动转一次llama-quantize ./merged_qwen.gguf ./qwen_q4km.gguf q4_k_m ollama create qwen2.5-law-med -f Modelfileq4_k_m是精度和体积都比较均衡的量化档位我后来所有给 Ollama 用的模型都统一用这个档位500 错误就再也没出现过。6. 验证与部署一条命令导出合并权重再接入 Ollama 和 vLLM训练完成并不代表模型能用。LoRA 适配器只存在于独立文件里必须先和底座权重合并导出完整模型llamafactory-cli export \ --model_name_or_path /models/Qwen2.5-7B-Instruct \ --adapter_name_or_path outputs/qwen25_law_medical_lora \ --template qwen \ --finetuning_type lora \ --export_dir ./merged_qwen_law_med \ --export_size 4 \ --export_legacy_format false这里--export_size 4按单个 4GB 分片导出方便后续工具读取如果你后面要接 vLLM这个分片大小完全兼容如果要转 GGUF这个分片大小也不会触发 2GB 上限的警告。合并完成后先做两层验证。第一层是自动化规则校验准备一套法律和医疗各 50 条问题的评测集脚本自动检查法条编号是否存在、答案里是否带安全提示、有没有明显重复文本。第二层是人工验证抽 20 条多轮对话每条让模型连续回答三轮看模型是否能维持同一事实立场而不是前后矛盾。两层都过了再进部署环节。vLLM 部署最简单直接指到合并后的目录vllm serve ./merged_qwen_law_med \ --served-model-name qwen2.5-law-med \ --tensor-parallel-size 1 \ --max-model-len 2048Ollama 部署多一步 GGUF 转换。先执行转换命令生成 fp16 GGUF再写 Modelfile 指定聊天模板和采样参数python convert_hf_to_gguf.py ./merged_qwen_law_med \ --outfile ./qwen_law_med.gguf \ --outtype f16FROM ./qwen_law_med.gguf TEMPLATE {{ if .System }}|im_start|system {{ .System }}|im_end| {{ end }}|im_start|user {{ .Prompt }}|im_end| |im_start|assistant PARAMETER temperature 0.4 PARAMETER top_p 0.9 PARAMETER repeat_penalty 1.1最后ollama create qwen2.5-law-med -f Modelfile再ollama run qwen2.5-law-med验证一次整个链路就通了。说起来你可能不信我第一次做法律模型微调时在“导出模型”这步栽了跟头直接用了训练过程中的中间 checkpoint 去转 GGUF结果漏了一半 LoRA 权重模型回复全是乱码。从那以后我每次交付前都强制走一遍“合并权重—转 GGUF—Ollama 端到端测试”的完整流程导出命令只认llamafactory-cli export这一条路中间结果一律当没看到。希望帮到你。本文还有配套的精品资源点击获取 从零微调Qwen2.5法律医疗专家：LlamaFactory与QLoRA实战
简介面向AI研发、NLP及法律医疗领域智能化应用的技术人员这份资料围绕LlamaFactory框架对Qwen2.5进行高效微调系统讲解垂直领域专家模型构建全流程适合希望将通用模型定制到专业行业并落地部署的工程师与研究人员。内容覆盖环境搭建、数据收集与预处理、配置文件编写、模型训练、效果评估及服务部署等环节重点解析LoRA、QLoRA等参数高效微调策略并结合法律判断与医疗诊断真实案例直观对比微调前后模型在专业任务中的表现同时拓展到法律咨询、合同审查、病历生成、健康问答等具体场景强调数据预处理质量与超参设置对最终效果的显著影响。资源为单个docx文档压缩包约39KB文档结构清晰附有可直接参考的配置示例与实操要点可引导读者按步骤复现并优化自己的微调流程。目前已有94人学习使用对希望掌握大模型垂直适配技术并快速产出行业模型的技术团队具有实用参考价值。1. 大模型微调不是玄学用 LlamaFactory 把 Qwen2.5 调成法律和医疗专家很多做自然语言处理的工程师第一次被问到“能不能把通用大模型调成法律和医疗领域的专家模型”时第一反应是必须要有 A100 集群才能动手。直到 QLoRA 把门槛压到一张 12GB 显存的消费级显卡也能跑 7B 模型LlamaFactory 又把这个过程封装成了配置文件微调技术才算真正下沉到普通开发者手里。这份资源的核心内容很具体以 Qwen2.5-7B-Instruct 为底座用 LlamaFactory 做 LoRA 和 QLoRA 微调分别在法律和医疗两套指令数据集上训练出垂直领域专家模型并覆盖从数据构造到 Ollama、vLLM 部署的完整链路。适合三类人在低显存环境下做领域微调的算法工程师给律所或医院搭建内部问答系统的应用开发者以及刚进入大模型微调领域、需要一份可复现模板的研究生。笔记里的配置参数和避坑记录都是实测过的照着走一遍就能跑通不用自己从头猜参数。2. LlamaFactory 的选型逻辑和环境搭建先把可复现的底座打好2.1 为什么是 LlamaFactory它把 Trainer、PEFT 和数据处理压缩成一套配置要说清楚 LlamaFactory 的价值得先对比其他三条路线。直接用 Hugging Face 的 Trainer 写训练循环灵活性最高但你要自己手动完成 LoRA 注入、数据集格式转换、模板适配、停用词设置这些杂活每换一个底座模型就要重来一遍时间成本远高于训练本身。用 PEFT TRL 组合比 Trainer 省事但 TRL 的 SFTTrainer 和 datasets 的 map 流程在样本量过万时容易出现各种字段匹配问题出了问题还不好定位。用 DeepSpeed Megatron 做分布式训练是完全不同的应用层级一个 7B 参数模型的单卡微调项目根本没必要上这套体系。LlamaFactory 恰好把这三条路线的优点收拢到自己这边。它底层复用 PEFT 和 transformers 的成熟实现上层提供统一的命令行和 YAML 入口。你只需要告诉它模型路径、数据集路径、微调方法和 batch 大小剩下的数据处理、模板拼接、优化器配置都是自动完成。对做实际项目的人来说还有一个容易被忽略的价值点是“训练前数据校验”启动训练时会先输出数据集的样本数量和格式检查结果格式不对会直接报错而不是跑到一半才崩。路线配置成本LoRA/QLoRA数据集管理多卡扩展Trainer 手写高自己拼装无难PEFT TRL中支持半自动中DeepSpeed 全家桶很高支持无强LlamaFactory低支持自带校验内置如果你接触过 QLoRA应该知道它的核心是把底座模型量化为 4bit再在反量化后的特征上挂 LoRA 适配器。LlamaFactory 对这套机制做了封装所以上表里才敢写“支持”。但我建议你内心始终带着“底层是 PEFT”的意识遇到文档查不到的行为时直接去读 PEFT 的源码比在 LlamaFactory 文档里找答案更快。2.2 版本依赖矩阵torch、transformers、CUDA 的搭配不能想当然版本搭配是微调项目里最常见也最隐蔽的翻车点。下面是我在 Ubuntu 22.04、NVIDIA 驱动 535 环境下验证过的一套组合conda create -n llama_factory python3.10 -y conda activate llama_factory pip install torch2.4.0 --index-url https://download.pytorch.org/whl/cu121 pip install transformers4.45.2 datasets3.0.1 tokenizers0.19.1 pip install llama-factory0.9.0我解释一下每行的用意。PyTorch 那一行必须带--index-url指向 cu121 的 wheel 目录否则 pip 默认安装的可能是不带 CUDA 支持的 CPU 版训练时会一直在 CPU 上跑速度慢到像死机。transformers 锁到 4.45.2 是因为 LlamaFactory 0.9.x 的AutoModelForCausalLM接口对这个版本适配最稳定换到 4.50 以上的新版可能出现 Qwen2.5 config 字段兼容问题。datasets 和 tokenizers 看起来不起眼但一旦版本漂移map函数内部会出现 key mismatch 报错而且报错信息不直接。如果你的显卡驱动是较老的 470 或 510 系列那 CUDA 12.1 的 torch 可能装不上需要退回cu118后缀并配合较低的 transformers 版本。这时不要硬上 QLoRA 4bit可以用 8bit 或者干脆 LoRA 16bit虽然显存压力大一点但不会在环境阶段就卡住。还有一种常见场景是 Windows 下想先本地试跑。我的习惯是先装 WSL2在 WSL2 Ubuntu 里建这套 conda 环境尽可能跟线上训练机保持一致避免 Windows 原生路径和 CUDA 版本坑影响后续排障。2.3 显存预估和量级选择7B 到 32B 在 QLoRA 下要怎么选显存需求是可以提前算出来的不用等训练时爆掉才发现。下面这张表是 QLoRA 4bit 加gradient_checkpointing开启条件下的实测区间底座模型微调方式单卡显存需求推荐 GPUQwen2.5-7BQLoRA (4bit)10~13 GBRTX 3090 / 4070 Ti SuperQwen2.5-7BLoRA (16bit)16~18 GBRTX 3090 / 4090Qwen2.5-14BQLoRA (4bit)22~26 GBA6000 / 双卡 4090Qwen2.5-32BQLoRA (4bit)42~48 GBA100 40G这里有个规律QLoRA 的显存需求不是按模型参数量线性涨的。7B 到 14B 参数量翻一倍显存只涨一倍多是因为 4bit 量化把大部分权重固定在显存里不再浮动。但一旦超过 32B量化后的前向激活值也会因为 hidden size 增大而显著膨胀那时就要认真考虑max_seq_len和 batch size 的取舍。我在项目里通常直接按“显存卡的 75% 作为安全线”来选模型比如一张 24GB 的 4090安全线大约 18GB跑 7B 的 LoRA 没问题跑 14B 的 QLoRA 就只能用 batch size 1 而且不能开评估集。显存判断还要注意一个容易忽略的点训练阶段的显存峰值比推理阶段高很多。推理时 7B fp16 模型只需要 14~16GB 左右而 QLoRA 训练时因为保存梯度、优化器状态和混合精度中间值同样模型要 12GB 以上。所以如果你的目标只是私有化部署而不是训练那完全不需要按训练标准去采购显卡。3. 法律与医疗训练集的构造从原始文档到指令对不是复制粘贴3.1 指令格式选型sharegpt 处理多轮对话alpaca 只适合单轮很多资料一上来就让你把数据整理成 JSON但没人说清楚 alpaca 和 sharegpt 两种格式的区别。alpaca 格式把每条样本拆成 instruction、input、output 三个字段适合“问题-答案”的一轮结构。下面是一个法律问答的 alpaca 示例{ instruction: 根据合同编相关条文判断这份房屋买卖合同是否有效, input: 甲与乙签订房屋买卖合同甲支付了全部价款但签约时乙尚未取得房屋所有权证书。, output: 合同效力与物权登记是两个层次。合同是否有效取决于双方意思表示真实且不违反法律强制性规定物权未登记不影响合同成立与生效。 }sharegpt 格式则是多轮消息列表系统、用户、助手三条消息按顺序排{ conversations: [ { from: system, value: 你是法律领域的专业助手请依据现行民事法律条文回答不确定时明确说明。 }, { from: human, value: 我签了购房合同但对方没有产权证这合同有效吗 }, { from: gpt, value: 合同一般自成立时生效不动产物权变动需要登记才发生效力。未取得产权证并不必然导致合同无效但要结合具体事实判断。 }, { from: human, value: 那我能不能主张违约金 }, { from: gpt, value: 可以。违约金的请求前提是合同有效且对方构成违约与产权证是否办理登记是两回事。 } ] }法律和医疗场景的用户提问天然是多轮的咨询者会追问、补充症状、改剂量所以我把两份数据集统一转成 sharegpt 格式并且把 system prompt 单独做成一个字段。这个字段直接影响模型行为法律模型的 system prompt 我写成“不确定时明确说明”医疗模型的 system prompt 写成“回答用药建议时强调必须线下就诊确认”。训练完之后你会发现模型确实开始学会在知识边界外说“这个需要结合线下检查结果判断”而不是硬编答案。另外一个细节是格式检查。LlamaFactory 启动后会告诉你每个数据集的有效样本数和预估 token 量但你需要在进入训练之前自己先看一眼 JSON 的字段闭合。常见坑是手写 JSON 时最后一条 conversations 后面多了逗号解析器直接报 JSONDecodeError白白浪费一上午。3.2 法律数据的四步流水线判决书切分、改写到倒推问题法律数据最稳定的公开来源是裁判文书网和公开的法律法规库但原始裁判文书不能直接当训练数据。我从真实项目中总结了一套四步流水线第一步抽取“案件事实”和“裁判理由”两个章节。判决书的结构比较固定可以用正则按标题切出来。第二步切分长文本。一份判决书事实部分可能有三五千字需要按语义段落切成 200~400 字的片段避免单条样本在 token 化时超过 cutoff_len。第三步把裁判理由改写成问答形式。这一步要人工介入因为裁判文书的语言是高度嵌套的直接拿来做答案模型会学出一股庭审腔。第四步倒推问题。把改写后的答案交给标注者让标注者写出自然用户可能提出的问题再把“问题-答案”对喂进数据集。为了让文本清洗可复用我写了一个针对法律文本的去噪脚本import json import re def clean_law_text(text: str) - str: # 去掉判决书里的审理程序段落只保留事实和理由 text re.sub(r(审理经过|本院认为|审判人员)[:], \n, text) # 合并连续空白 text re.sub(r\s, , text).strip() return text with open(raw_cases.jsonl, r, encodingutf-8) as f: cases [json.loads(line) for line in f if line.strip()] cleaned [] for case in cases: fact clean_law_text(case.get(fact, )) reason clean_law_text(case.get(reason, )) if len(fact) 80 or len(reason) 80: continue # 过滤过短样本 cleaned.append({instruction: case[instruction], input: fact, output: reason}) with open(law_clean.jsonl, w, encodingutf-8) as f: for item in cleaned: f.write(json.dumps(item, ensure_asciiFalse) \n)这里clean_law_text函数里的正则有两个作用一是把“审理经过”“本院认为”这类程序性标题替换成换行符让文本分成更易读的块二是把空白字符压成单空格。过滤条件len 80是为了把切碎的、不完整的句子排除掉这类噪声样本会让模型学到“对空提问给空回答”的坏习惯。保存为 jsonl 而不是 json是因为数据量大了之后 jsonl 可以一行一条流式读取训练前不需要把整个文件塞进内存。法律数据还有一个特有细节法条引用标记。我在清洗时把“合同编第X条”“民法典第X条”统一包裹成[[法条]]标记作为生成内容里的一个隐藏结构。模型会学会在引用法条时输出这个标记后续在验证阶段就能用脚本自动比对法条编号是否存在减少人工审核的工作量。3.3 医疗数据的清洗红线隐私边界和术语一致性医疗数据是敏感领域先划一条红线不要私自爬取医院的电子病历、门诊记录、带患者信息的文本即便做了脱敏也不行。合规的来源包括公开的医学教材问答章节、药品说明书里的适应症和用法、医学知识库的术语解释、医生发表在官方平台上的科普文章。这些数据虽然信息密度不如病历高但胜在来源清晰、没有隐私风险。术语一致性是医疗数据里最容易出问题的点。患者习惯说“胸口疼”“心口闷”病历里写“胸骨后压榨样疼痛”如果这些口语表达不经处理直接进入训练集模型会学到“胸口疼”和“胸痛”是两个无法互通的概念。我一般在数据管线上加一层术语归一映射term_map { 胸口疼: 胸痛胸口疼, 心口闷: 胸痛心口闷, 咳嗽: 咳嗽, 咳痰: 咳痰, } def normalize_medical_term(text: str) - str: for k, v in term_map.items(): if k in text: text text.replace(k, v) return text这里的映射逻辑是标准化术语放前面口语表达放括号里作为补充。模型既学到规范的临床语言又保留了患者描述的原始语义。需要注意的是映射表不能太激进比如“肚子疼”不要硬映射成“腹痛”因为患者语境里的“肚子疼”有时指胃痛有时指肠炎无法精确归一到单一术语保留口语反而是更安全的做法。医疗指令对的目标输出也跟法律不同。法律数据要求“可验证”医疗数据要求“保守”。我把医疗数据的 output 统一加上安全后缀比如“以上建议仅供参考请以线下医生诊断为准”。不要觉得这是废话模型在真实咨询场景里如果没有这层兜底出现一次错误用药建议就是事故。4. LlamaFactory 训练实战YAML 参数逐条拆开再跑单卡/多卡4.1 训练配置文件拆解lora_rank、学习率和 cutoff_len 的配合把数据集准备好之后训练本身其实是最不用操心的部分。下面这份 YAML 来自我微调法律医疗混合模型时实际跑通的配置model_name_or_path: /models/Qwen2.5-7B-Instruct template: qwen stage: sft finetuning_type: lora lora_rank: 16 lora_alpha: 32 lora_dropout: 0.05 dataset: law_sharegpt, medical_sharegpt cutoff_len: 2048 per_device_train_batch_size: 2 gradient_accumulation_steps: 8 learning_rate: 2.0e-4 num_train_epochs: 3 lr_scheduler_type: cosine warmup_ratio: 0.03 logging_steps: 10 save_steps: 200 output_dir: outputs/qwen25_law_medical_lora先说 lora_rank 和 lora_alpha。rank 16 alpha 32 是 LoRA 社区最成熟的起点alpha 是 rank 的两倍等于在反向传播时把低秩矩阵的贡献放大一倍。如果你只有 1 万条以内的样本rank 8 就够了样本超过 5 万条可以试 rank 32但要注意提高 rank 会显著增加过拟合风险需要同步增加 dropout 或在验证集上做早停。cutoff_len决定单条样本的最大 token 数。我设置 2048 是因为两个领域的样本大部分在 800~1800 token 之间设置太低会把长样本暴力截断让模型学到不完整的回答逻辑设置太高又会让短样本被大量 padding白白浪费算力。判断方法很简单——统计一下数据集的 token 长度分布取 P90 分位数再加 20% 余量就是合理的 cutoff_len。再看优化器相关参数。learning_rate2e-4 搭配cosine调度器和 0.03 的warmup_ratio前 3% 的步数线性升温到峰值之后按余弦曲线衰减。LoRA 需要更新的参数很少如果一开始就给 1e-3 以上的学习率loss 会在前几十步剧烈震荡然后掉进一个很差的局部最小值。如果你观察到训练的 loss 曲线像锯齿一样大概率就是这个原因。我建议你一定要在配置里加上评估集。LlamaFactory 支持eval_dataset和eval_strategy两个参数每隔一定步数跑一次验证集 loss。没有评估集的话你完全不知道模型在第几个 epoch 开始过拟合只能靠部署后的人工测试来发现那时候后悔药已经很难买了。4.2 单卡 QLoRA 启动命令逐段解释和日志信号判断单卡 QLoRA 的启动命令如下CUDA_VISIBLE_DEVICES0 llamafactory-cli train \ --model_name_or_path /models/Qwen2.5-7B-Instruct \ --template qwen \ --stage sft \ --finetuning_type lora \ --quantization_bit 4 \ --dataset law_sharegpt,medical_sharegpt \ --cutoff_len 2048 \ --per_device_train_batch_size 2 \ --gradient_accumulation_steps 8 \ --learning_rate 2.0e-4 \ --num_train_epochs 3 \ --lora_rank 16 \ --lora_alpha 32 \ --output_dir outputs/qwen25_law_medical_loraquantization_bit 4就是 QLoRA 的关键开关它会把底座模型以 4bit 加载训练过程中的张量运算反量化到 fp16回传梯度只更新 LoRA 分支。--cutoff_len 2048控制单样本最大长度。与配置文件不同的是命令行适合临时覆盖设备号和输出路径核心参数还是写进 YAML 里提交到 git 做记录方便复现。训练开始后你要盯三个信号。第一个是日志输出里的global_step确认它在增长。第二个是 loss 值从 2.0 起步逐渐往下走属于正常如果第一步就低于 0.3说明模型在背答案而不是在学推理训到三五个 epoch 后 loss 低于 0.1 时要警惕过拟合而不是开心。第三个是显存占用。QLoRA 7B 在 batch size 2、cutoff 2048 时应该在 12GB 上下浮动如果你的显存占用能装满一张 24GB 的卡说明某个参数配置有冗余常见原因是gradient_checkpointing没开。4.3 多卡和断点续跑deepspeed 配置与 checkpoint 恢复的边界大部分场景一张 3090 或 4090 就能跑到满意的效果除非你的样本量超过 5 万条且要跑 3 个 epoch否则不用急着上多卡。如果你确实要上LlamaFactory 内置了 deepspeed 支持命令变成deepspeed --num_gpus2 llamafactory-cli train \ --model_name_or_path /models/Qwen2.5-7B-Instruct \ --template qwen \ --stage sft \ --finetuning_type lora \ --dataset law_sharegpt,medical_sharegpt \ --cutoff_len 2048 \ --per_device_train_batch_size 4 \ --gradient_accumulation_steps 4 \ --learning_rate 2.0e-4 \ --num_train_epochs 3 \ --deepspeed configs/ds_z2_config.json \ --output_dir outputs/qwen25_law_medical_lora注意这里把 batch size 加大到 4、梯度累积降到 4等效 batch 大小还是 16但每张卡的吞吐量翻倍。ds_z2_config.json直接用 LlamaFactory examples 目录里自带的 ZeRO-2 配置即可不要自己从头写 zero_optimization 配置stage 参数、offload 设备参数和通信后端之间任何一个不匹配训练都不会报错但速度会慢得你怀疑人生。断点续跑也是实际项目中必会的操作。LlamaFactory 训练中断后output_dir里会留下checkpoint-xxx目录恢复训练用--resume_from_checkpoint outputs/qwen25_law_medical_lora/checkpoint-200。恢复时需要注意如果你在中途改过数据集文件或cutoff_len建议老老实实从头训因为 optimizer 状态里的 tokenizer 信息和新配置对不上。另外 LoRA 的 checkpoint 往往只保存适配器权重不保存底座恢复时仍然要指定完整的model_name_or_path。5. 避坑从 loss 不降到 Ollama 500 错误的五个现场5.1 loss 卡在异常区间不下降现象训练已经跑了 100 多步loss 稳定在 3.0 以上纹丝不动。原因比较多但我在两个项目里定位到的都是数据集问题一是训练集里大量样本的 output 字段为空或为空字符串模型每次都在学“输入就结束”无法学到有效信息二是重复样本太多模型在重复中学不出泛化规律。解决方式是训练前做一次去重和空值过滤。我一般会在数据管线末尾加一个脚本统计每个 output 的字符数和重复度低于 20 个字符的直接剔除重复率超过 30% 的样本组只保留一条。数据干净之后loss 通常会立刻掉到 2.0 以下。5.2 第一步就报 CUDA out of memory现象训练命令刚执行第一个 step就报CUDA out of memory。原因通常是cutoff_len和per_device_train_batch_size组合超出单卡显存。因为是动态 paddingbatch 里一旦混入一条接近 cutoff_len 的长样本整批的显存峰值就会瞬间抬高。解决步骤很有顺序先把gradient_checkpointing打开这能省掉一半的激活显存如果还爆把cutoff_len降到 1024再不行把 batch size 改成 1同时靠梯度累积维持等效 batch 大小。我一般不推荐一上来就降 batch因为梯度的噪声会变大训练曲线不好看。5.3 推理输出变成复读机现象模型回答到一半开始重复同一句话比如“好的好的好的”重复二十遍。原因LoRA 微调轮数偏多模型在自回归路径上过度拟合了高频 token 序列采样时一旦进入这个循环就走不出来。解决一是把num_train_epochs从 3 降到 1~2并打开评估集观察验证 loss 在哪个 epoch 开始回升二是在部署侧调高repetition_penalty。如果模型已经训完可以通过修改生成参数来控制PARAMETER repeat_penalty 1.15 PARAMETER temperature 0.3如果你部署在 vLLM则对应--repetition-penalty 1.15。这里要注意一个问题repetition_penalty调得太高会走向另一个极端模型每个词都刻意避开重复输出变得机械、词不达意1.1~1.15 通常是最平衡的区间。5.4 模型编造不存在的法条现象问“房屋买卖合同需要登记才生效吗”模型回答“根据民法典第 999 条第 3 款……”但第 999 条根本不存在。原因训练语料里法条引用和解释混在一起模型学到的分布让它认为每个解释后面都应该跟一个引用。解决清洗阶段加正则把法条编号提取出来去比对原始法条库不存在的编号整条标为不合格。在推理阶段我还会在验证脚本里做法条编号正则匹配返回一个“法条命中率”指标低于 95% 就发警报。这个方法解决不了模型整体的事实错误但至少能把“伪造法条”这个最影响信任的问题压住。5.5 Ollama 运行报 500 internal server error现象模型导出后在 Ollama 里ollama run qwen2.5直接报500 internal server error有些场景下第一次运行正常第二次就报错。原因八成是 GGUF 文件有问题要么是转换时参数不对导致量化表损坏要么是模型文件在重新下载时被截断另外就是 Ollama 的 llama.cpp 运行时对某些低 bit 量化等级支持不稳定比如q2_k在这种场景下最容易崩。解决顺序如下ollama serve ollama logs先看日志里有没有gguf或ggml字样。如果有确认是模型文件问题后回到 LlamaFactory 侧重新导出用 fp16 全精度导出再用 llama.cpp 的 quantize 工具手动转一次llama-quantize ./merged_qwen.gguf ./qwen_q4km.gguf q4_k_m ollama create qwen2.5-law-med -f Modelfileq4_k_m是精度和体积都比较均衡的量化档位我后来所有给 Ollama 用的模型都统一用这个档位500 错误就再也没出现过。6. 验证与部署一条命令导出合并权重再接入 Ollama 和 vLLM训练完成并不代表模型能用。LoRA 适配器只存在于独立文件里必须先和底座权重合并导出完整模型llamafactory-cli export \ --model_name_or_path /models/Qwen2.5-7B-Instruct \ --adapter_name_or_path outputs/qwen25_law_medical_lora \ --template qwen \ --finetuning_type lora \ --export_dir ./merged_qwen_law_med \ --export_size 4 \ --export_legacy_format false这里--export_size 4按单个 4GB 分片导出方便后续工具读取如果你后面要接 vLLM这个分片大小完全兼容如果要转 GGUF这个分片大小也不会触发 2GB 上限的警告。合并完成后先做两层验证。第一层是自动化规则校验准备一套法律和医疗各 50 条问题的评测集脚本自动检查法条编号是否存在、答案里是否带安全提示、有没有明显重复文本。第二层是人工验证抽 20 条多轮对话每条让模型连续回答三轮看模型是否能维持同一事实立场而不是前后矛盾。两层都过了再进部署环节。vLLM 部署最简单直接指到合并后的目录vllm serve ./merged_qwen_law_med \ --served-model-name qwen2.5-law-med \ --tensor-parallel-size 1 \ --max-model-len 2048Ollama 部署多一步 GGUF 转换。先执行转换命令生成 fp16 GGUF再写 Modelfile 指定聊天模板和采样参数python convert_hf_to_gguf.py ./merged_qwen_law_med \ --outfile ./qwen_law_med.gguf \ --outtype f16FROM ./qwen_law_med.gguf TEMPLATE {{ if .System }}|im_start|system {{ .System }}|im_end| {{ end }}|im_start|user {{ .Prompt }}|im_end| |im_start|assistant PARAMETER temperature 0.4 PARAMETER top_p 0.9 PARAMETER repeat_penalty 1.1最后ollama create qwen2.5-law-med -f Modelfile再ollama run qwen2.5-law-med验证一次整个链路就通了。说起来你可能不信我第一次做法律模型微调时在“导出模型”这步栽了跟头直接用了训练过程中的中间 checkpoint 去转 GGUF结果漏了一半 LoRA 权重模型回复全是乱码。从那以后我每次交付前都强制走一遍“合并权重—转 GGUF—Ollama 端到端测试”的完整流程导出命令只认llamafactory-cli export这一条路中间结果一律当没看到。希望帮到你。本文还有配套的精品资源点击获取