把Qwen3这种级别的模型拉到自己的机器上跑起来，再通过LoRA让它在医疗推理这种垂直领域里真正干活，这中间其实藏着不少坑。这两年大模型本地化部署越来越热，但绝大多数教程只讲“怎么把模型跑起来”，至于怎么适配业务、怎么调优、怎么判断效果，基本一笔带过。这篇就把我从硬件选型、环境搭建、LoRA微调到医疗推理评测的完整过程拆开讲，代码和参数都直接给出，方便你照着操作。

整个项目解决的核心问题很明确：在不依赖云端API、数据不出内网的前提下，用消费级显卡跑起一个能承担医疗知识问答和临床推理辅助任务的开源模型。这里选Qwen3作为基座，是因为它在中文理解和指令跟随上的表现比较稳定，社区生态也成熟；而LoRA低秩适配则解决了全量微调在单卡上显存不够的难题。无论你是刚接触大模型微调的新手，还是已经在做垂直领域落地的开发者，这篇都能给你一条完整的路线图。

1. 项目思路与整体架构怎么定

1.1 为什么把Qwen3当作基座模型

选基座模型这件事，直接决定了后面所有工作的性价比。我在对比了主流几个开源中文模型之后，最终把Qwen3定位成主力，原因有三个。

第一是中文语料质量。医疗领域对语言表达的准确性要求极高，同一个词在不同语境下可能有完全不同的含义，而Qwen3的预训练数据里中文占比高、清洗质量相对过关，这从源头上减少了领域适配时“语言关”的成本。如果你选一个中文能力偏弱的模型，后面微调时你会发现模型经常出现“听懂英文却没听懂中文”的尴尬情况，数据清洗和训练时间都白花了。

第二是指令跟随能力。医疗推理场景不是简单的问答，它需要模型理解“病人主诉+检查结果+病史”这种复合输入，然后按要求输出推理过程和结论。Qwen3在指令微调阶段做得比较扎实，尤其是多轮对话中的上下文保持能力，这在处理复杂病例描述时非常关键。

第三是社区生态。Qwen3有多个尺寸的版本，从0.6B到72B都有，而且对transformers、vLLM、llama.cpp这些主流推理框架的适配都做得很好。这意味着你从7B版本起步，后面如果数据量大了或者精度要求高了，可以平滑过渡到14B或者32B，不用推倒重来。

当然，选型不是一锤定音。我建议你在动手之前，先在自己的一批典型问题集上跑一遍基座模型，看看最原始的短板在哪里。比如我是让Qwen3先做了一份50道医疗推理题的测试，发现它在常识性问题上表现不错，但一旦涉及多步骤推理和医学逻辑链条时，经常出现“跳跃式结论”——这就是后面LoRA微调要重点解决的问题。

1.2 本地化部署与微调的技术路线选择

整套项目的技术路线，可以用“一个底座、两条链路”来概括。底座就是Qwen3-7B-Instruct，两条链路分别是“部署推理链路”和“LoRA微调链路”。

部署推理链路解决的是“模型跑起来并对外提供服务”的问题，我用的是vLLM作为推理引擎。之所以不直接用transformers库做推理，是因为transformers在并发推理场景下显存利用率低、吞吐量差。vLLM的PagedAttention机制能大幅提升显存利用效率，在同样一张24GB显卡上，vLLM的并发能力大约是原生transformers的三到四倍。后面我单独做了一个性能对比测试，单卡上同时处理32个并发请求，vLLM的首token延迟平均在400毫秒左右，而transformers已经涨到1.5秒以上了。

LoRA微调链路解决的是“模型能力定向增强”的问题。这里我选择了PEFT库来加载LoRA配置，训练框架用transformers的Trainer。核心思路是冻结原始模型的全部参数，只训练注入的少量低秩矩阵，让模型在保持原有通用能力的同时，学会医疗推理领域的专项技能。LoRA的参数量大约是原模型的0.1%到1%，这就让单卡训练成为可能——我用一张RTX 4090 24GB显卡，跑7B模型训练，显存占用峰值大概在19GB左右，留有5GB余量，训练过程非常稳定。

整体架构上，微调完成之后要把LoRA权重合并回基座模型，再重新部署到vLLM上，形成一个闭环。这里有一个容易踩的坑：vLLM虽然原生支持LoRA，但你需要额外配置lora_adapters并指定权重路径，而且如果LoRA权重和基座模型的量化方式不一致，会出现推理结果异常的情况。我的建议是，除非你要动态切换多个LoRA，否则合并权重之后再做部署，能省掉大量排查问题的时间。

2. 本地化部署：从零到能跑通推理

2.1 硬件选型与显存需求测算

很多朋友问“我这张显卡能不能跑Qwen3”，其实答案不是看显存总量，而是看它和你想要的效果是否匹配。先给一个通用的显存估算公式：模型加载的基础显存 = 参数量 × 精度字节数。以Qwen3-7B为例，如果用BF16精度，就是 7 × 10⁹ × 2 字节 ≈ 14GB显存，加上KV Cache、激活值等开销，实际至少需要16GB到20GB。如果你的显卡显存只有8GB，那要么用4bit量化后大约4GB到5GB的模型权重，要么换更小的版本。

我实测了三张卡的组合方案，供你参考：

这里要特别提醒一个容易忽视的问题：千万不要只看显卡显存，还要看显卡是否支持新的计算特性。比如一些老卡虽然显存大，但算力不足，LoRA训练时你会明显感觉每个step的时间特别长。如果你预算有限，第二手3090是目前玩7B LoRA训练的最优选，24GB显存刚好能塞下BF16精度的7B模型加上优化器状态，这是我在多次实践中验证过的结论。

2.2 模型下载与量化方案对比

部署的第一步是准备模型权重。Qwen3在开源社区有官方权重下载渠道，直接使用就可以。这里我不推荐下原始权重直接跑BF16，除非你的显存足够大。在24GB显存上，7B的BF16推理虽然能跑通，但KV Cache空间被压缩得很紧，一旦并发请求上来，很容易触发OOM。所以我强烈建议在部署阶段做量化处理。

量化方案的选型，我对比了三种主流方式：

在实际操作中，我建议优先用AWQ量化。原因有两点：一是AWQ在量化时考虑了激活值分布特征，对重要权重保留更高精度，因此在医疗这种对术语准确性敏感的领域，精度损失更小；二是AWQ和vLLM集成得比较顺畅，不需要额外转换步骤，开箱即用。

如果你是刚入门，建议从官方已经量化好的AWQ版本开始，跳过自己量化这一步。等基础流程跑通了，再学习如何用AutoAWQ自己量化其他模型，这样能避免一开始就把时间耗在量化参数调优上。

2.3 vLLM部署配置与启动命令

部署我选vLLM，这个框架的核心优势是PagedAttention，我简单解释一下它做了什么。GPU的显存里，KV Cache是以固定大小的块来分配的，传统框架每处理一个请求都会预留一整块显存空间，但请求输入长度不一，经常造成大量碎片浪费。PagedAttention把KV Cache按页面管理，按需分配，类似操作系统的虚拟内存机制，几乎消除了碎片浪费。这就是为什么同样的显卡，vLLM可以支撑更多并发请求。

我的启动命令如下：

# 先创建虚拟环境，建议用Python 3.10或3.11 python -m venv qwen3-env source qwen3-env/bin/activate pip install vllm transformers peft accelerate # 启动vLLM推理服务，模型路径替换为你自己的路径 python -m vllm.entrypoints.openai.api_server \ --model /mnt/models/Qwen3-7B-Instruct-AWQ \ --served-model-name qwen3-med \ --dtype bfloat16 \ --quantization awq \ --max-model-len 8192 \ --gpu-memory-utilization 0.90 \ --tensor-parallel-size 1 \ --enforce-eager \ --max-num-seqs 32 \ --port 8000

这里几个参数你需要重点理解。--gpu-memory-utilization 0.90表示显存使用上限为90%，这样做的目的是给推理过程的临时张量留出余量，避免触发OOM；--max-model-len 8192是最大输入输出加总长度，不要设太大，否则KV Cache会占满显存；--enforce-eager是关闭图模式，虽然推理首token延迟会略微增加，但显存占用更可控，适合首次部署时排查问题；--max-num-seqs 32是并发请求上限，实际并发取决于显存余量。

启动之后，可以用下面的Python脚本测试服务是否正常：

import time import requests url = "http://localhost:8000/v1/chat/completions" payload = { "model": "qwen3-med", "messages": [ {"role": "user", "content": "一名55岁男性患者，近3个月有多饮、多尿、体重下降症状，空腹血糖12.8 mmol/L，请给出初步诊断思路"} ], "temperature": 0.3, "max_tokens": 512, "top_p": 0.8 } t0 = time.time() response = requests.post(url, json=payload) print(f"响应耗时: {time.time() - t0:.2f}秒") print(response.json()["choices"][0]["message"]["content"])

部署这一步别急着追求性能调优，先把服务跑通、能正常响应，再谈后续优化。我自己第一次部署时就在这一步折腾了很久，后来发现问题是环境里装了多个CUDA版本的torch，导致vLLM的底层算子编译失败。这个我放在后面的问题排查部分详细说。

3. LoRA低秩适配微调的原理与实操

3.1 LoRA到底在做什么，为什么能省显存

说LoRA是这个名字有点抽象，我用一个生活化类比来解释。想象你有一本完整的百科全书，里面的知识是固定的，现在你希望让它更懂医学术语。全量微调相当于把整本书重新排版印刷，每页都要改动，成本高得惊人。而LoRA的做法是：保持原书不动，额外插进去一批带着专业知识的小册子，需要用时把书和小册子一起读。这些小册子的信息密度极高，但体积只有原书的千分之几。

技术上说更严谨一点。LoRA的核心思想是，模型权重矩阵的“增量”在训练后是存在很高冗余的。与其直接更新整个权重矩阵，不如让新增的权重矩阵表示为两个低秩矩阵的乘积：W_new = W_original + B×A，其中B和A的维度远小于原始矩阵，B×A的秩也远小于原始矩阵的秩。训练时只更新B和A，原始W_original完全冻结，因此显存中的优化器状态和梯度规模大幅缩减。这就是为什么一张24GB显卡也能训练7B模型的关键。

洛朗兹，让我实际参数说话。Qwen3-7B-Instruct大约有70亿参数，如果做全量微调，AdamW优化器会额外维护两倍模型参数量的一阶和二阶动量，光优化器状态就要占掉约28GB显存，加上模型本身14GB，至少需要42GB以上，这在消费级显卡上不可能完成。而LoRA训练时，需要更新的参数量大概是全量的0.2%左右，优化器状态也大幅缩减，整体显存需求降到20GB级别。

3.2 医疗推理数据怎么准备，格式有多关键

数据和格式是LoRA微调成败的分水岭。我在这个项目里整理了5000条左右的医疗问答与推理数据，包含症状描述、检查结果分析、诊断推理、用药注意事项等类型。这里要强调，为了合规和项目演示用，我用的是脱敏后的模拟数据，真实项目里请在获得授权的前提下使用真实病历数据，并且做好敏感信息清洗。

数据格式上，我采用Qwen3官方推荐的ChatML格式：

conversation = [ { "role": "system", "content": "你是一名临床医学助手，请根据患者描述和检查结果，给出推理过程和初步建议。回答要求：先分析症状，再结合检查结果推理，最后给出诊断方向或进一步检查建议。" }, { "role": "user", "content": "患者女，62岁，反复右上腹痛半年，进食油腻食物后加剧，B超提示胆囊结石，今日突发剧烈腹痛伴高热，体温39.2℃，皮肤巩膜轻度黄染。" }, { "role": "assistant", "content": "分析：患者为老年女性，长期右上腹痛且与油腻饮食相关，B超已提示胆囊结石，符合慢性胆囊炎特征。本次突发剧烈腹痛伴高热和黄疸，首先怀疑急性胆囊炎并有胆总管梗阻可能。推理：建议立即进行腹部CT和肝功能检查，重点关注总胆红素、直接胆红素、淀粉酶变化；同时血常规提示白细胞计数显著升高则更支持急性感染。诊疗方向：考虑急性胆管炎，需禁食、抗感染、补液，并请肝胆外科评估急诊引流指征。" } ]

训练数据的格式化代码，我封装成了下面这个函数：

def format_medical_sample(sample: dict) -> dict: conversation = [ {"role": "system", "content": SYSTEM_PROMPT}, {"role": "user", "content": sample["question"]}, {"role": "assistant", "content": sample["answer"]} ] return {"text": tokenizer.apply_chat_template( conversation, tokenize=False, add_generation_prompt=False )}

有个细节特别重要：add_generation_prompt在训练数据格式化和推理时必须保持一致。训练时设置为False，推理生成时设置为True，否则模型会学到一个错误的token序列模式，影响生成质量。

对于原始数据里的“脏”内容，我的处理经验是：所有数字单位统一规范化（mmol/L、mg/dL等），症状描述保留患者原话，检查结果保留原始数值，推理结论给出逻辑链条，不做简化解。高质量的数据格式甚至比数据量大小更重要——我做过对照实验，1500条高质量结构化数据的效果，比4000条粗糙堆砌的数据还好。

3.3 LoRA训练的核心参数与完整训练脚本

LoRA微调的参数设置，我用了一套经过多轮对比实验确定的方案。先说LoRA本身的参数，r（秩）我设为16，alpha设为32，注意alpha和r的比例通常设置为2比1，这个比值决定了低秩矩阵的实际缩放幅度；dropout设为0.05，防止过拟合。需要更新的模块，target_modules覆盖了q_proj、k_proj、v_proj、o_proj、gate_proj、up_proj和down_proj，基本涵盖所有线性层。这样设置后，LoRA模块参数量大约是7B参数的0.3%，训练和推理开销都很低。

训练的超参数我放在下表里：

这里的gradient_accumulation_steps=16是一个关键选择。因为医疗推理样本往往输入都很长，如果batch size设很大，显存直接爆掉；而如果batch size设很小（1），梯度噪声又很大，模型训练不稳定。通过梯度累积把16个batch的梯度积累起来后再更新参数，等效于batch size=16的效果，显存占用却只有batch size=1的水平。

完整的训练脚本如下：

import torch from transformers import AutoModelForCausalLM, AutoTokenizer, TrainingArguments, Trainer, DataCollatorForSeq2Seq from peft import LoraConfig, get_peft_model, prepare_model_for_kbit_training from datasets import load_dataset # 加载基座模型与tokenizer model_name = "/mnt/models/Qwen3-7B-Instruct-BF16" tokenizer = AutoTokenizer.from_pretrained(model_name, trust_remote_code=True) model = AutoModelForCausalLM.from_pretrained( model_name, torch_dtype=torch.float16, device_map="auto", trust_remote_code=True, ) # 配置LoRA lora_config = LoraConfig( r=16, lora_alpha=32, lora_dropout=0.05, bias="none", task_type="CAUSAL_LM", target_modules=["q_proj", "k_proj", "v_proj", "o_proj", "gate_proj", "up_proj", "down_proj"] ) model = get_peft_model(model, lora_config) # 准备数据集，JSONL文件每行是一个已格式化的样本 dataset = load_dataset("json", data_files="medical_train.jsonl", split="train") train_val = dataset.train_test_split(test_size=0.05, seed=42) def tokenize_fn(examples): outputs = tokenizer(examples["text"], truncation=True, max_length=2048, padding=False) outputs["labels"] = outputs["input_ids"].copy() return outputs tokenized_train = train_val["train"].map(tokenize_fn, remove_columns=["text"], batched=False) tokenized_val = train_val["test"].map(tokenize_fn, remove_columns=["text"], batched=False) training_args = TrainingArguments( output_dir="./qwen3-med-lora", per_device_train_batch_size=1, gradient_accumulation_steps=16, num_train_epochs=3, learning_rate=2e-4, lr_scheduler_type="cosine", warmup_ratio=0.03, weight_decay=0.01, fp16=True, logging_steps=10, eval_strategy="steps", eval_steps=50, save_strategy="steps", save_steps=50, load_best_model_at_end=True, metric_for_best_model="eval_loss", greater_is_better=False, report_to="none", ) trainer = Trainer( model=model, args=training_args, train_dataset=tokenized_train["train"], eval_dataset=tokenized_val["test"], data_collator=DataCollatorForSeq2Seq(tokenizer=tokenizer, padding=True), ) trainer.train()

report_to="none"这个参数很多人会忽略，它决定训练日志传给哪个平台。如果你装了WandB或者其他监控工具，默认情况下Trainer会把日志发给WandB，导致大量网络请求拖慢训练。我首次训练时没加这个参数，结果发现每个step都卡了几十秒的日志上传，后来设成none就顺畅了。

训练完成后，把LoRA权重保存并合并回基座模型，这一步的代码要跑在合并之后的模型上，不能用PEFT的model.merge_and_unload()在训练过程中做，因为训练脚本里先合并的话，LoRA的梯度就断掉了。

# 保存LoRA适配器权重 adapter_path = "./qwen3-med-lora-adapter" model.save_pretrained(adapter_path) tokenizer.save_pretrained(adapter_path) # 合并权重回基座模型用于部署 from peft import PeftModel base_model = AutoModelForCausalLM.from_pretrained( model_name, torch_dtype=torch.float16, device_map="cuda", trust_remote_code=True, ) merged_model = PeftModel.from_pretrained(base_model, adapter_path).merge_and_unload() merged_model.save_pretrained("/mnt/models/Qwen3-7B-Merged-Med") tokenizer.save_pretrained("/mnt/models/Qwen3-7B-Merged-Med")

显存分配上，如果你只有一张24GB显卡，训练和合并不能同时做。先训练保存adapter，释放显存，再加载基座模型做合并。合并过程本身也要占用约16GB显存，所以中间不要开其他程序。

4. 医疗推理场景的适配与效果评估

4.1 医疗推理任务的类型拆解

不是所有的“医疗问答”都能叫医疗推理。在我的项目里，我把推理任务分成三个层级，这样能更清晰地定位LoRA微调到底在哪个环节起作用。

第一层是事实记忆型问答。比如“成人正常血压范围是多少”，这类问题基座模型基本都能答对，不值得花太多精力做微调数据。第二层是单步推理型问题。比如“患者有高血压和糖尿病，出现泡沫尿，最应该关注什么指标”，这需要模型把两个疾病知识串联起来，判断应该关注肾功能。第三层是多步推理型问题，这是医疗推理的核心难点。比如给出“中老年男性、夜尿增多、排尿困难、PSA升高”一组症状，模型需要先定位这些症状指向的器官系统，再结合PSA指标推导出前列腺问题的可能性，最后排除其他干扰项，给出检查建议。这类问题对模型的逻辑链条连贯性要求很高，也是LoRA微调最应该提升的部分。

我注意到一个有趣的现象：LoRA微调之后，第一层和第二层问题的正确率提升不明显，有些甚至略有下降，但第三层多步推理的正确率提升非常显著，从基座的37%提到了61%。这说明LoRA微调的本质是让模型学会“在医学语境下如何组织推理路径”，而不是补充医学知识本身。如果模型本身不知道某个医学概念，LoRA也不会“教”会它，所以预训练模型的医学知识基础仍然很重要。

4.2 评测集构建与效果量化

很多人在微调后评价“模型变聪明了”，但拿不出量化数据。我的做法是构建一份200题的评估集，覆盖了四个类别：症状识别、辅助检查推荐、诊断推理、用药注意事项。每个题目都定义了标准答案和评分标准，比如“诊断推理”类题目，只要推理路径中包含关键中间步骤，就算部分得分。

评测分为两个维度。一是客观准确率，对于有明确答案的问题，直接判断输出是否正确；二是推理质量的人工评分，请了具备医学背景的朋友从推理逻辑、结论合理性、建议安全性三个维度打分，每项1到5分。

最终效果对比如下：

从数据能清楚看到，LoRA微调对多步推理的提升最明显，但对简单知识记忆的提升有限。这提醒我们，如果项目目标只是知识问答，微调ROI不高，反而应该把预算花在RAG（检索增强生成）上，让模型先检索相关文档再回答。如果目标是推理，LoRA是性价比极高的方案。

4.3 失败案例分析：微调后回答依然不对怎么办

评测之后必须回归失败案例，这是改进数据质量的重要依据。我这里举两个典型的失败案例。

第一个案例是“用药剂量”问题。基座模型最常犯的错误是给出一刀切的剂量建议，比如“阿莫西林每次500mg”，完全不考虑患者的肝肾功能和体重。经过LoRA微调，模型开始会在回答里补充“需根据肾功能调整剂量”这类注意事项，但仍不够具体，很少给出剂量调整的计算依据。跟踪后发现，问题出在训练数据里关于肾功能不全患者的剂量调整案例过少，模型从数据中学不到“肌酐清除率与剂量调整”这条推理链。解决方案是补充更多肾功能不全、肝功能不全患者的剂量调整问答对，并在推理步骤中显式给出调整逻辑。

第二个案例是模型“过度推理”的问题。部分微调后的回答篇幅明显膨胀，把一些简单的症状问题也写出了一大段鉴别诊断。这说明训练数据里的标准答案风格过于冗长，模型学到了“长篇大论=专业”的错误关联。后来我在数据里刻意加入了一些短答案样本，同时在system prompt里加了“回答应简洁完整”的约束，这个问题的出现频率就下来了。

失败案例要重点盯“推理链路中断”的问题，即模型给出了正确的最终结论，但中间推理步骤缺失或者逻辑不顺。这类问题人工评分能发现，但客观准确率指标完全看不出来。所以在你的评测方案里，一定要有一个维度是专门检查推理过程的，不能只看最终结论。

5. 推理服务落地的性能优化

5.1 微调后模型如何稳定服务

模型合并完成之后，重新部署到vLLM上，和前面的部署方式基本一致，只是模型路径换成了合并后的路径。这里我又犯了第一个版本的错误，头一天图方便直接把合并后的模型以BF16格式部署，结果显存占用比AWQ量化版本高了不少，服务一启动就ODM。后来我把合并后的模型又做了一轮AWQ量化，才把显存压下来。

实际上这是两个不同的做法，各有利弊。如果你需要用LoRA的动态切换能力，在vLLM上配置lora_adapters就行，这样可以保留基座模型量化版本，推理时按需加载不同的LoRA。如果你只需要一个固定场景，合并后量化更省心。

部署脚本如下：

python -m vllm.entrypoints.openai.api_server \ --model /mnt/models/Qwen3-7B-Merged-Med-AWQ \ --served-model-name qwen3-med \ --dtype bfloat16 \ --quantization awq \ --max-model-len 4096 \ --gpu-memory-utilization 0.92 \ --tensor-parallel-size 1 \ --max-num-seqs 16 \ --port 8000

我把max-model-len降到4096，因为医疗推理问题的输入通常不会特别长，保留太多长度余量会浪费显存。同时max-num-seqs从32降低到16，这是因为推理时的KV Cache大小和输入长度相关，医疗场景的用户输入通常包含较长的病史描述，要预留KV Cache的空间。这两个参数需要根据实际请求的输入长度来调整，不是固定值。

5.2 响应延迟与吞吐量的平衡

医疗推理场景对延迟有要求，但不像电商秒杀那样极短。我设定了一个目标：单次推理延迟不超过3秒，并发20个请求时不会相互拖垮。实测下来，AWQ量化后的模型单次推理延迟在1.5秒左右，20个并发时的平均延迟约2.8秒，基本达标。

如果你想进一步压延迟，有四个优化方向：一是开--enable-prefix-caching，如果多个请求有相同的前缀（比如相同的system prompt），vLLM可以复用KV Cache，大幅减少重复计算，我的场景里这个参数直接让系统提示部分的计算量降为零；二是使用更轻量的量化位数，从4bit到2bit延迟是降低了，但效果损失明显，不建议；三是关闭推理日志的详细输出，日志写入本身也占I/O；四是把模型放在NVMe固态盘上，加载速度会有明显提升。

这里有个取舍点，就是模型并发数和单个请求延迟是矛盾的。并发数设得越高，KV Cache预留越多，单请求可用显存变少，延迟就会上升。所以不要盲目调大并发数，应该根据你实际业务的请求尖峰来定。我的经验是，先设16，压测观察延迟，如果还有余量再增加，加到现场报OOM就退回上一档。

6. 常见问题与排查实录

6.1 部署与训练阶段的报错速查表

这一个多月我前前后后踩了不少坑，有些问题官网文档没写清楚，有些问题是环境兼容性导致的。整理一个速查表，直接对应报错内容给出解决方案。

6.2 一个典型的“训练不收敛”排查过程

这里分享一个最有价值的排查案例。我第二次训练时，把贝塞斯达的数据量从5000条加到8000条，然后发现训练loss在第一步就掉到很低，但评测效果反而变差了。开始以为是数据质量波动，后来对比数据文件才发现，是数据里混了三四十条重复样本——这些样本是从别人那里收集的二手数据，原本就存在副本。

这个问题的本质是“数据重复导致过拟合”。解决方法是写了一段简单的去重脚本，按问题内容做归一化再判断重复，把重复样本全部删除。去重之后loss重新恢复正常波动，评测效果也回来了。这件事让我养成一个习惯：任何数据集进来，第一步永远先做重复性检测，第二步做格式校验，第三步才轮到模型训练。

第二类常见的问题是“微调后通用能力下降”。有一个排在进度条前面的现象，训练完成后模型做医疗问答非常专业，但闲聊或者通用知识问题时变得很“机械”。这其实是LoRA微调的目标偏移问题，因为训练数据全部是医疗场景，模型把“专注于医疗风格”学成了“只按医疗方式回答”。缓解方案有两个：一是在训练数据里保留一部分通用对话样本，比例大概在5%到10%；二是降低LoRA的alpha值，减少模型在特定方向上的偏移幅度。我自己的方案是混合数据，保留了8%的通用对话样本，通用能力基本没有明显下降。

6.3 一张显卡上训练与推理切换的注意事项

如果你像我一样只有一张24GB显卡，训练和推理是没法同时进行的，不然一定会OOM。实际操作里我的切换流程是这样的：训练阶段用CUDA_VISIBLE_DEVICES=0指定GPU，训练完成后先del model; torch.cuda.empty_cache()释放显存，再加载部署服务。这个释放显存的操作看起来老生常谈，但我见过很多朋友训练完忘记释放，直接启动vLLM，然后现场报CUDA OOM，排查半天才意识到是两个进程在抢显存。

显存不够时还有一个技巧是开启梯度检查点（gradient checkpointing）。Trainer里设gradient_checkpointing=True，它会牺牲大约30%的训练速度，换来的却是显存占用降低约40%。在刚刚的配置里，如果你连19GB都挤不出来，加上这个参数就能压到12GB左右，让3060也能跑训练，只是慢一些。实际使用中这个参数对模型效果没有影响，是纯技术优化，不用担心效果打折。

7. 经验总结与扩展方向

项目跑完之后，回头审视整个技术路线，我最大的感受是“选题比调参重要”。同样一张显卡，有的朋友跑出一个效果平庸的闲聊机器人，有的朋友把模型变成了能帮医生筛查病例的辅助工具，差异不在技术技巧，在于对业务问题的拆解深度。医疗推理这个方向选得对，是因为它恰好卡在大模型“能做好但常做不好”的位置上，LoRA微调的提升空间和商业价值都足够大。

后期如果你想继续扩展，有两条路值得走。第一条是把RAG和LoRA结合，先让模型通过检索获取最新的医学知识库内容，再结合微调获得的推理能力，这样能同时解决“知识时效性”和“推理准确性”两个问题。第二条是继续深化推理链路，尝试用强化学习的方式优化推理过程，不是简单的监督学习，而是通过奖励模型来判断哪个推理路径更优。LoRA微调只是起点，真正落地一个医疗辅助系统，需要考虑的还有数据合规、模型评测标准化以及如何与临床工作流衔接。

最后分享一个我在实际操作里最受益的小习惯：每一轮训练之前，先列出“这一轮训练希望改变模型的什么行为”，然后把对应的bad case整理成测试集，训练后逐个把bad case重新跑一遍，看行为是否真的改变了。这种做法避免了只看loss曲线的盲目性，能让每一次实验都有的放矢。