MedicalGPT：用 ChatGPT 训练管线自建医疗大模型，从增量预训练到 GRPO
MedicalGPT: Training Your Own Medical GPT Model with ChatGPT Training Pipeline. 训练医疗大模型，实现了包括增量预训练(PT)、有监督微调(SFT)、RLHF、DPO、ORPO、GRPO。
秒懂
- 它是什么？
- MedicalGPT 是一套把 ChatGPT 训练管线搬到医疗领域的开源实现，覆盖增量预训练、SFT、RLHF、DPO、ORPO、GRPO 和 OPD。本文拆解它的阶段设计、实际运行方式，以及哪些团队适合直接采用。
- 适合谁用？
- 适合以下团队采用：有医疗领域文本与对话数据，需要从基座模型出发训练专属模型，并且具备多卡 GPU 或 DeepSpeed 经验的研究组与公司。不适合：只想快速获得一个可用的医疗问答 API，没有意愿处理数据清洗与多阶段训练调参的团队。
- 能商用吗？
- 可以。Apache-2.0 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库最近一次提交在 1 天前。
- 用什么语言写的？
- 主要是 Python（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
它解决的是训练流程碎片化的问题
医疗大模型训练不是单步操作。从领域预训练到人类偏好对齐，中间隔着数据格式转换、模型加载、分布式训练、评估等多个环节。多数开源项目只覆盖其中一步，比如只做 SFT 或只做 DPO。MedicalGPT 把 ChatGPT 训练管线完整搬到了医疗场景，按阶段拆成 PT、SFT、RM、RL、DPO、ORPO、GRPO，以及 2026 年新增的 OPD。它的目标用户很明确：需要自己训练医疗模型的工程师或研究人员，而不是调用现成 API 的开发者。项目以医疗为例，但 README 里说明这是领域模型的训练方法，数据换成法律或金融文本同样适用。这一点决定了它的定位是训练框架，而非医疗问答产品。
从增量预训练到 OPD 的阶段设计
训练流程分成三个主要阶段。第一阶段是可选的在领域文档上的增量预训练，目的是让模型适应医疗数据分布。第二阶段是有监督微调，用指令数据对齐意图并注入领域知识。第三阶段是偏好对齐，项目提供两条路径：一是 RLHF，先训练奖励模型，再用强化学习更新策略；二是 DPO，跳过奖励模型直接优化语言模型。README 明确引用 DPO 论文，说明该方法把语言模型本身当作奖励模型。ORPO 则更进一步，不需要参考模型。GRPO 是纯强化学习方法，release 日志提到可以体验 aha moment，指模型在推理中自发产生反思行为。OPD 是 v2.7 新增的 on-policy 蒸馏训练，有独立入口 training/opd_training.py。整体设计遵循 Karpathy 的 State of GPT 演讲中的管线，但把每一步都做成了可单独运行的脚本。
实际运行：脚本入口与数据格式
项目用 shell 脚本作为启动入口。README 和 release 日志提到 scripts/run_opd.sh 用于 OPD，scripts/run_orpo.sh 用于 ORPO，run_sft.sh 这类脚本对应各自阶段。训练代码集中在 training 目录，比如 opd_training.py。数据方面，data 目录下提供样例，包括 toolcall 数据，用于 v2.6 新增的 Function Call 微调。角色扮演数据生成脚本在 role_play_data 目录，支持 OpenAI、豆包、MiniMax 等 provider。具体命令需要看仓库里的脚本内容，但模式是清晰的：每个方法对应一个 Python 训练入口和一个 shell 启动脚本。运行前要准备符合格式的 JSON 数据，不同模型有不同的对话模板，v2.5 起新增了 qwen3、qwen3_5、qwen3_nothink 等模板。
模型支持范围与硬件前提
项目支持的模型随版本扩展。v2.0 加入 Llama-3，v2.1 加入 Qwen-2，v2.3 加入 Qwen-2.5，v2.5 加入 Qwen3.5 系列，包括 MoE 变体。v1.8 支持 Mixtral 8x7B。历史版本还覆盖 Baichuan、ChatGLM、Bloom。支持 LoRA 和全参数训练，v2.4 起 GRPO 也支持 LoRA。硬件方面，训练 13B 甚至更大的模型需要多卡环境，项目支持 DeepSpeed ZeRO-3，特别是 MoE 训练。没有多卡 GPU 的团队基本无法跑完整流程，只能做 LoRA 微调小模型。这一点 README 没有直接写，但根据模型规模和分布式支持可以推断。
局限与选错工具的场景
MedicalGPT 不是拿来即用的产品。它没有提供训练好的医疗模型下载链接，只有一个 Hugging Face 用户页。你要自己准备数据、自己跑训练、自己评估效果。数据质量直接决定模型表现，项目只提供样例和生成脚本，不负责数据清洗。另一个限制是训练周期长，四阶段流程每一步都要调参，失败排查成本高。如果你的目标只是做一个医疗问答 demo，用现成的 API 或直接微调一个 7B 模型可能更快，不需要引入完整的 RLHF 管线。此外，OPD 和 GRPO 都是较新的方法，社区经验少，遇到问题可参考的文档有限。
替代方案与差异
直接替代品是 LLaMA-Factory，它同样支持 SFT、DPO、ORPO、GRPO，但界面和命令行更统一，适合快速尝试多种模型。差异在于 MedicalGPT 按 ChatGPT 管线分成独立阶段，每个阶段有单独脚本，更贴近研究流程，方便你在 RM 和 RL 之间插入自定义逻辑。而 LLaMA-Factory 更偏向开箱即用的训练工具，阶段划分不如 MedicalGPT 明显。另一个角度是 Hugging Face 的 TRL 库，它提供 DPO 和 GRPO 的训练器，但需要你自己组装数据加载和模型包装。MedicalGPT 的价值在于把数据处理、模板选择、训练启动整合成一套脚本，减少了胶水代码。
维护活跃度与许可证
项目采用 Apache-2.0 许可证，商用友好，不需要开源衍生代码，但保留版权声明。维护节奏从 release 日志看相当稳定，2023 年至今每年都有多个版本。v2.7 发布于 2026 年 4 月，v2.6 和 v2.5 分别间隔一周，说明作者在持续跟进新模型和训练方法。升级成本主要在于数据格式兼容性，新版本可能新增对话模板或数据转换代码，旧脚本不一定直接可用。另外项目依赖较多，requirements.txt 列出 Python 3.8+，需要安装 PyTorch、Transformers、DeepSpeed 等，环境配置本身需要一定时间。
编辑结论
适合以下团队采用：有医疗领域文本与对话数据，需要从基座模型出发训练专属模型，并且具备多卡 GPU 或 DeepSpeed 经验的研究组与公司。不适合：只想快速获得一个可用的医疗问答 API，没有意愿处理数据清洗与多阶段训练调参的团队。采用前先验证三件事：确认你的基座模型在支持的列表内，包括 Qwen3.5、Llama-3 等；检查 scripts 目录下对应方法的 shell 脚本是否匹配你的显存与节点数；用最小数据集跑通 run_sft.sh 再扩展到全量。该项目的价值在于把分散的 PT、SFT、RLHF、DPO、ORPO、GRPO、OPD 训练入口集中到一套代码，但这也意味着你需要自己维护数据格式与各阶段的超参数，项目本身不提供开箱即用的医疗问答模型。
社区笔记