医学大语言模型这两年是真的火，火到什么程度呢，我身边做临床科研的、做医疗信息化的、甚至做医院行政的朋友，都在问同一个问题：到底有哪些模型是真正能用的，哪些只是论文里跑了个分就销声匿迹了。这个问题看起来简单，实际上坑特别多。因为医学大语言模型这个领域，跟通用大模型完全不是一个玩法——通用模型你跑个benchmark，看看排行榜就大概有数了；但医学模型不行，它涉及到临床数据的隐私合规、医学知识的专业壁垒、以及最要命的幻觉问题，一个模型在MedQA上刷到90分，放到真实门诊场景里可能连一个简单的用药禁忌都判断错。
我自己在这个方向上折腾了挺长时间，从最早拿通用模型做医学问答微调，到后来系统性地测试各种开源医学模型，再到现在帮几个团队做医学AI应用的选型评估，踩过的坑可以说是相当丰富了。这篇文章我打算把目前主流的医学大语言模型做一个系统性的梳理，不是那种罗列论文标题的汇总，而是从实际使用者的角度，讲清楚每个模型的特点、适用场景、部署门槛、以及我在实测中发现的那些文档里不会写的问题。
不管你是刚入门的医学生想了解这个领域，还是做医疗AI产品的工程师需要选型参考，或者是从业者想找一个能本地部署的医学问答助手，这篇内容应该都能给你一些实在的参考。我会尽量把技术细节讲清楚，同时保持人话，不让非CS背景的朋友看得太吃力。
1. 医学大语言模型的分类逻辑与选型框架
1.1 为什么不能简单按参数量来分类
很多人第一次接触医学大模型，习惯性地按参数量来分——7B、13B、70B这样排。这个思路在通用模型领域勉强能用，但在医学领域会出大问题。原因很简单：医学模型的性能瓶颈往往不在参数量，而在训练数据的质量和领域适配的深度。
我举个例子你就明白了。有一个7B的医学模型，在USMLE（美国执业医师资格考试）风格的题目上，准确率能超过某些70B的通用模型。为什么？因为它的训练数据里包含了大量经过医学专家标注的临床指南、病例报告、药物说明书，这些数据的密度极高，每一token承载的医学信息量远超通用语料。反过来，一个70B的通用模型，哪怕参数量大十倍，它在医学任务上的表现可能还不如前者，因为它的训练语料里医学内容占比可能不到5%。
所以我在做选型的时候，更倾向于按能力维度来分类，而不是按规模。具体来说，我会看这几个维度：
- 知识覆盖范围：是只覆盖某个专科（比如放射科、病理科），还是覆盖全科医学
- 任务类型：是只做问答，还是能做摘要、结构化提取、诊断推理、报告生成
- 部署形态：是只能通过API调用，还是可以本地部署
- 训练方式：是基于通用模型微调，还是从领域语料从头预训练
- 数据合规性：训练数据是否可追溯，是否涉及患者隐私
这五个维度组合起来，才能真正描述一个医学大模型的定位。光看参数量，就像只看一个人的身高来判断他会不会打篮球一样，信息量太少了。
1.2 三类主流技术路线的取舍
目前医学大语言模型的技术路线，大致可以分成三类，每一类都有明显的优缺点，我逐个拆解一下。
第一类：通用基座+医学指令微调
这是最常见的做法。拿一个已经训练好的通用大模型（比如LLaMA系列、Qwen系列），用医学领域的指令数据做监督微调（SFT），有时候还会加上RLHF或者DPO来做偏好对齐。优点是开发成本相对低，基座模型的通用能力保留得比较好，模型既能聊医学也能聊别的。缺点是医学知识的深度往往不够，因为微调阶段的数据量通常有限，很难覆盖所有专科的细分知识。
我实测下来，这类模型在常见病、多发病的问答上表现不错，但一旦涉及到罕见病、复杂用药交互、最新临床指南，就容易露怯。而且有一个很隐蔽的问题：它们有时候会用非常自信的语气说出错误的医学信息，这个比直接说“我不知道”危险得多。
第二类：医学语料继续预训练+指令微调
这类模型在通用基座的基础上，先用大规模的医学语料做继续预训练（Continued Pre-training），让模型“泡”在医学文本里，然后再做指令微调。代表就是各种在PubMed、临床指南、医学教科书上继续训练的模型。优点是医学知识的深度和广度都明显更好，尤其是对专业术语的理解和生成更准确。缺点是继续预训练的成本很高，而且如果语料质量参差不齐，模型可能会学到一些错误的关联。
这里有一个很关键的细节：继续预训练的数据配比。我见过一些模型，医学语料占比过高，导致通用能力严重退化，连正常的对话都变得磕磕绊绊。理想的配比通常是在医学语料中混入一定比例的通用语料，保持模型的“基本沟通能力”。
第三类：从零预训练的领域原生模型
这类模型完全从医学语料从头训练，不依赖通用基座。理论上这是最纯粹的领域模型，但实际做的人很少，因为成本太高了。从头预训练一个像样的模型，需要的数据量、算力、时间都是天文数字。目前能看到的这类模型，参数量通常不大，能力也比较局限，更多是学术探索性质。
不过这类模型有一个独特的优势：完全可控。训练数据、训练过程、模型行为都是可追溯的，这在医疗这种强监管场景下，有时候比性能更重要。
1.3 选型时必须问自己的五个问题
在具体看各个模型之前，我建议你先问自己五个问题，这五个问题的答案会直接决定你该选哪个方向。
问题一：你的数据能不能出本地？如果涉及患者隐私数据，那基本只能选支持本地部署的开源模型，API调用的方案直接排除。这个问题没有商量余地，合规红线不能碰。
问题二：你的场景对准确率的要求有多高？如果是做医学科普、健康咨询，那容错率相对高一些；如果是辅助诊断、用药建议，那准确率要求就非常苛刻，宁可模型说“我不确定”也不能给错误答案。
问题三：你的用户是谁？是医生、护士、医学生，还是普通患者？不同用户对模型输出的专业程度、语言风格要求完全不同。给医生用的模型可以满篇术语，给患者用的模型必须通俗易懂。
问题四：你的算力预算有多少？本地部署7B模型和70B模型，硬件成本差了一个数量级。7B模型一张消费级显卡就能跑，70B模型至少需要多张专业卡。
问题五：你需要模型具备哪些能力？纯问答、文本摘要、结构化提取、多轮对话、工具调用——不同能力对模型的要求不一样。有些模型问答很强但摘要很弱，有些模型多轮对话容易跑偏。
把这五个问题想清楚，你再看下面的模型汇总，就会更有针对性。
2. 主流医学大语言模型逐一拆解
2.1 开源可本地部署的医学模型
这一类的模型是我个人最关注的，因为本地部署意味着数据不出域，对于医疗场景来说这是刚需。我按我实际测试过的顺序来说。
模型A：基于LLaMA架构的医学微调模型
这个模型在开源医学模型里知名度很高，它的训练数据主要来自医学教材、临床指南和部分公开的医学问答数据集。我实测下来，它在USMLE风格的选择题上表现相当不错，尤其是基础医学和内科方向。但它的短板也很明显：中文支持比较弱，如果你需要中文医学问答，需要额外做中文微调。
部署方面，7B版本在单张24G显存的卡上可以跑FP16推理，量化到4bit之后甚至能在16G显存的卡上跑。我建议如果要做生产部署，至少用4bit量化，因为FP16的显存占用和推理延迟在实际场景中会比较吃力。
注意：这个模型的输出风格偏“教科书”，回答比较冗长，如果你需要简洁的答案，需要在prompt里明确要求。
模型B：基于Qwen架构的中文医学模型
这个模型对中文医学场景的适配明显更好，训练数据里包含了大量中文临床指南、药品说明书和中文医学文献。我在测试中文用药咨询、中医相关问题的时候，它的表现比模型A好不少。尤其是中医方向，很多通用模型对中医术语的理解一塌糊涂，但这个模型能比较准确地处理。
它的参数量覆盖比较全，从1.8B到72B都有。我的建议是：如果你只是做简单的医学问答demo，1.8B或7B够用；如果要做稍微严肃一点的应用，至少上14B；72B版本效果最好但部署成本很高。
模型C：专注于医学文献理解的模型
这个模型的定位很特殊，它不是做问答的，而是专门做医学文献的摘要、信息抽取和结构化。如果你需要从大量论文里提取特定信息（比如某种药物的临床试验结果），这个模型比通用模型好用得多。它的训练数据主要是PubMed的论文全文和摘要。
我实测用它做文献信息抽取，准确率比通用模型高出一大截。但它的局限性也很明显：不适合做开放式问答，你问它“感冒怎么办”它可能答得不如一个7B的通用模型。
模型D：多模态医学模型
这类模型能同时处理文本和医学影像（X光、CT、病理切片等），是最近比较热的方向。我测试过几个，说实话目前还不太成熟。文本问答能力普遍弱于纯文本模型，影像理解能力也还在早期阶段。但如果你做的是影像报告生成这类特定任务，它确实能省不少事。
部署门槛方面，多模态模型因为要处理图像，显存占用比纯文本模型高不少，而且推理速度也慢。我建议如果要做多模态，至少准备一张40G以上的卡。
2.2 通过API调用的商业医学模型
如果你不涉及敏感数据，或者只是做原型验证，API调用的商业模型是更省事的选择。我按使用体验来说。
商业模型X：通用大厂的医学专用版本
几个大厂都推出了医学专用版本，通常是在通用模型基础上做了医学领域的强化。优点是稳定、易用、文档齐全，缺点是贵，而且你没法控制模型更新——厂商一升级，你的应用可能就要重新调prompt。
我实测下来，这类模型在常见医学问答上表现稳定，但深度不够。你问它标准的临床指南问题，它能答得不错；你问它某个罕见病的鉴别诊断，它就开始含糊其辞了。
商业模型Y：专注医疗垂直领域的创业公司产品
这类产品的特点是医学知识做得比较深，有些甚至和医院合作做了真实临床数据的验证。但问题是质量参差不齐，有些确实做得好，有些就是套了个壳。选这类产品的时候，我建议一定要做POC测试，别光看宣传材料。
商业模型Z：面向患者的健康咨询模型
这类模型的语言风格更通俗，适合做患者教育、健康科普。但如果你拿它做专业医学用途，会发现它的回答太“浅”了，缺乏临床细节。
2.3 各模型关键指标横向对比
下面这张表是我根据实际测试和公开资料整理的，供你选型参考。需要说明的是，这些评分带有一定主观性，具体场景下可能有所不同。
| 模型 | 参数量范围 | 中文支持 | 本地部署 | 医学知识深度 | 通用能力保留 | 部署门槛 |
|---|---|---|---|---|---|---|
| 模型A | 7B-70B | 弱 | 支持 | 高 | 中 | 中 |
| 模型B | 1.8B-72B | 强 | 支持 | 中高 | 高 | 低-高 |
| 模型C | 7B-13B | 中 | 支持 | 高（文献） | 低 | 低 |
| 模型D | 7B-34B | 中 | 支持 | 中 | 中 | 高 |
| 商业X | 不公开 | 强 | 不支持 | 中 | 高 | 无 |
| 商业Y | 不公开 | 强 | 部分支持 | 高 | 中 | 低 |
| 商业Z | 不公开 | 强 | 不支持 | 低 | 高 | 无 |
这张表里我特意没有放具体的准确率数字，因为不同测试集上的数字差异很大，放出来反而容易误导。选型的时候，更重要的是看模型的能力特点跟你的场景是否匹配。
3. 医学大模型实操部署与微调要点
3.1 本地部署的硬件选型与量化策略
本地部署医学大模型，硬件是第一个门槛。我按不同预算给几个方案。
预算有限（一张消费级显卡）：16G显存的卡可以跑7B模型的4bit量化版本，推理速度大概每秒20-40个token，做demo和轻量应用够用。但要注意，4bit量化会带来一定的性能损失，在医学这种对准确性要求高的场景下，需要评估这个损失是否可接受。
中等预算（一张专业卡）：40G或48G显存的卡可以跑13B-14B模型的FP16版本，或者70B模型的4bit量化版本。这个配置是我比较推荐的，兼顾了性能和成本。
充足预算（多卡）：多张专业卡可以跑70B模型的FP16版本，或者做多模型ensemble。但多卡部署的复杂度会明显上升，需要处理模型并行、通信开销等问题。
量化策略方面，我实测下来，4bit量化（比如GPTQ或AWQ）在医学问答任务上的性能损失通常在5%-10%左右，8bit量化损失更小但显存节省有限。如果显存够，我建议优先用8bit；如果显存紧张，4bit也能接受，但一定要在你的实际任务上做评估。
提示：量化后的模型在某些细分任务上可能出现“能力塌缩”，比如原本能正确回答的罕见病问题，量化后开始胡编。部署前一定要做充分的回归测试。
3.2 医学指令微调的数据准备与训练技巧
如果你手头有高质量的医学数据，做指令微调是提升模型领域能力的有效手段。我分享一下我的经验。
数据准备：医学指令数据的质量比数量重要得多。我见过有人拿几万条低质量的问答数据去微调，效果还不如几千条专家标注的高质量数据。理想的数据应该包含：问题、标准答案、以及可选的推理过程。推理过程很重要，它能让模型学会“怎么想”而不只是“答什么”。
数据格式方面，我建议用统一的指令模板，比如：
{ "instruction": "根据以下症状描述，给出可能的鉴别诊断和下一步检查建议", "input": "患者男性，45岁，反复上腹痛3个月，进食后加重...", "output": "可能的鉴别诊断包括：1. 胃溃疡... 2. 慢性胃炎... 建议下一步检查：1. 胃镜... 2. 幽门螺杆菌检测..." }训练技巧：微调的时候，学习率不要设太大，我通常用1e-5到5e-5之间。训练轮数也不要太多，医学数据容易过拟合，通常2-3个epoch就够了。另外，我强烈建议保留一部分通用指令数据混在一起训练，防止模型丧失通用对话能力。
有一个坑我踩过：用纯医学数据微调后，模型变得只会“一本正经地答题”，你问它“今天天气怎么样”它也会往医学上扯。混入10%-20%的通用指令数据可以很好地缓解这个问题。
3.3 推理阶段的Prompt工程与安全护栏
模型部署好了，不代表就能直接用。医学场景对输出的安全性要求极高，必须在推理阶段加护栏。
Prompt设计：我通常会在system prompt里明确几个约束：第一，不确定的时候必须说“不确定”，不能编造；第二，涉及用药建议时必须提示“请遵医嘱”；第三，不能给出明确的诊断结论，只能提供“可能的考虑方向”。
一个我常用的system prompt模板：
你是一个医学知识助手，你的回答仅供医学专业人士参考，不构成诊疗建议。 在回答时请遵循以下原则： 1. 如果问题超出你的知识范围，请明确说明，不要编造信息 2. 涉及药物剂量、用法时，请提示用户查阅最新药品说明书 3. 不要给出确定性的诊断结论，只提供鉴别诊断的思路 4. 回答中引用的指南或文献，如果不确定具体出处，请说明输出过滤：除了prompt约束，我还会加一层输出过滤，检测回答中是否包含高风险内容，比如具体的药物剂量推荐、明确的诊断结论等。一旦检测到，就触发人工审核或者直接返回安全提示。
多轮对话管理：医学问答经常是多轮的，用户会不断补充信息。这里要注意上下文管理，避免模型被前面的错误信息带偏。我的做法是每轮对话都重新注入system prompt，并且在上下文过长时做摘要压缩。
4. 医学大模型应用中的典型问题与排查
4.1 幻觉问题的识别与缓解
幻觉是医学大模型最致命的问题。我见过模型编造出不存在的药物名称、虚构的临床研究、错误的剂量单位。更可怕的是，这些错误信息往往包装得非常专业，非专业人士根本看不出来。
识别幻觉的方法，我总结了几条：第一，检查模型引用的文献是否存在，很多幻觉会编造看起来很像真的的文献标题；第二，检查药物名称和剂量是否符合常识；第三，用多个模型交叉验证，如果多个模型给出矛盾答案，就需要警惕。
缓解幻觉的手段，除了前面说的prompt约束和输出过滤，还可以用RAG（检索增强生成）架构。让模型基于检索到的真实医学文献来回答，而不是完全依赖参数里的知识。我实测下来，RAG能把幻觉率降低一半以上，但前提是检索库的质量要过关。
4.2 常见问题速查表
下面这张表是我在实际项目中遇到的高频问题，以及对应的排查思路。
| 问题现象 | 可能原因 | 排查方向 | 解决方案 |
|---|---|---|---|
| 模型回答过于笼统 | 训练数据缺乏细节 | 检查微调数据质量 | 补充高质量细节数据 |
| 中文回答夹杂英文术语 | 训练语料中英混杂 | 检查语料配比 | 增加中文语料比例 |
| 多轮对话后跑偏 | 上下文管理不当 | 检查对话历史长度 | 限制轮数或做摘要压缩 |
| 推理速度突然变慢 | 显存不足触发交换 | 监控显存占用 | 降低量化精度或batch size |
| 特定专科问题表现差 | 训练数据覆盖不足 | 按专科测试 | 补充专科数据微调 |
| 输出格式不稳定 | prompt约束不够 | 检查prompt设计 | 增加格式示例和约束 |
4.3 几个我踩过的坑和对应的经验
第一个坑：盲目追求大参数量。我一开始觉得参数量越大越好，后来发现7B的医学专用模型在很多任务上比70B的通用模型好用。参数量不是唯一指标，领域适配程度更重要。
第二个坑：忽视推理延迟。做demo的时候用大模型觉得效果很好，上线之后发现用户等不了那么久。医学问答场景下，用户能接受的等待时间大概是3-5秒，超过这个时间体验就明显下降。所以选型的时候一定要把推理延迟纳入考量。
第三个坑：微调数据泄露。有一次我用了一批数据做微调，测试的时候发现模型在测试集上表现异常好，后来发现测试集和训练集有重叠。医学数据本来就稀缺，很容易出现这种情况，做评估的时候一定要严格划分训练集和测试集。
第四个坑：忽略模型的“拒答”能力。一个好的医学模型应该知道什么时候该说“我不知道”。我测试过一些模型，问它任何问题它都会给一个答案，哪怕这个问题完全超出它的知识范围。这种模型在实际使用中非常危险。评估模型的时候，一定要测试它的拒答能力。
5. 医学大模型的未来方向与个人实践建议
5.1 值得关注的技术趋势
从我这段时间的观察来看，医学大模型有几个方向值得关注。
多模态融合：文本+影像+检验数据的多模态模型是必然趋势。真实的临床决策本来就不是只看文本的，影像、化验、生命体征都是重要信息。目前的多模态医学模型还比较早期，但进展很快。
Agent化：让模型不只是回答问题，而是能调用工具、执行多步推理。比如一个医学Agent可以自动检索最新指南、计算药物剂量、检查药物交互，最后给出综合建议。这个方向我觉得比单纯提升模型参数更有价值。
个性化：基于患者个人病史、基因信息、生活习惯做个性化建议。这需要模型能处理长上下文，并且有很强的推理能力。目前还比较难，但方向是明确的。
可解释性：医学场景对可解释性的要求很高，医生需要知道模型为什么给出这个建议。目前大部分模型都是黑盒，可解释性研究还处于早期阶段。
5.2 给不同角色的实践建议
如果你是医学生或医生：我建议先从API调用的商业模型入手，了解大模型能做什么、不能做什么。然后可以尝试本地部署一个7B的医学模型，感受一下开源模型的能力边界。不需要一上来就搞微调，先用起来再说。
如果你是AI工程师：重点研究RAG架构在医学场景的落地，以及如何做输出安全护栏。模型选型方面，我建议至少测试3-5个模型，在你的实际任务上做对比，不要只看论文里的benchmark数字。
如果你是产品经理：最重要的是想清楚场景。医学大模型不是万能的，它在某些场景下很好用（比如医学知识问答、文献摘要），在某些场景下风险很高（比如直接给诊断结论）。找到合适的场景比选一个“最强”的模型更重要。
如果你是研究者：我建议关注医学模型的评估方法。目前医学大模型的评估还很不成熟，很多论文用的测试集和真实临床场景差距很大。如何设计更贴近真实的评估方案，是一个很有价值的研究方向。
5.3 我个人的一些使用心得
最后分享几个我日常使用医学大模型的小技巧。
第一个技巧：用“角色扮演”提升回答质量。在prompt里让模型扮演一个特定专科的医生，比如“你是一个有20年经验的心内科医生”，回答的专业度和针对性会明显提升。这个技巧在多个模型上都有效。
第二个技巧：分步提问比一次性提问效果好。复杂的医学问题，拆成几个小问题逐步问，比一次性问一个大问题得到的结果更准确。比如不要问“这个患者可能是什么病”，而是先问“这个症状的可能原因有哪些”，再问“结合这些检查结果，哪些原因更可能”。
第三个技巧：让模型给出推理过程。在prompt里要求模型“先分析再给结论”，不仅能提升答案质量，还能让你更容易发现模型推理中的错误。如果推理过程有问题，结论大概率也不可靠。
第四个技巧：定期更新知识。医学知识更新很快，模型的训练数据是有截止日期的。对于最新的指南、新药信息，一定要用RAG或者手动补充的方式更新，不能完全依赖模型的内置知识。
医学大语言模型这个领域变化太快了，我今天梳理的这些内容，可能过几个月就有新的模型出来。但底层的选型逻辑、部署方法、安全考量，这些是不太会变的。希望这篇内容能帮你在医学大模型的选型和应用上少走一些弯路。如果你在实际操作中遇到什么问题，欢迎一起交流探讨。
