MedicalGPT: A Full-Pipeline Trainer for Domain LLMs, Medical or Not

What MedicalGPT Actually Solves

MedicalGPT is a training pipeline, not a model. It addresses the problem of adapting a general-purpose large language model to a narrow domain, using medicine as the worked example. The README states that it implements the ChatGPT training pipeline, which means it covers several consecutive stages: continued pretraining, supervised fine-tuning, reward modeling, reinforcement learning, and the preference optimization methods DPO, ORPO and GRPO. The intended user is an engineer or researcher who has domain text, a set of instruction-response pairs, or preference data, and wants to turn a base model like LLaMA or Qwen into something that answers questions in that domain. The project is not a hosted service and it is not a single fine-tuning script. It is a collection of training entries, each tied to a specific stage, plus shell scripts that run those entries. The medical framing matters less than the pipeline itself. Any domain with enough text could use the same stages, though the repository ships medical data examples and role-play generation scripts aimed at doctor-patient dialogue.

The Pipeline: From Pretraining to GRPO

The core structure follows the ChatGPT training pipeline described in Andrej Karpathy's State of GPT talk, which the README cites. Stage one is continued pretraining, called PT, where the model sees large amounts of domain text to shift its distribution. Stage two is supervised fine-tuning, SFT, on instruction-response data to align the model with how questions are asked and answered in the domain. Stage three branches. One branch is RLHF, which first trains a reward model on human preference rankings, then uses that reward model in a reinforcement learning loop to update the SFT model. The other branch skips the explicit reward model. DPO directly optimizes the language model against preference pairs, as the README notes, citing the Direct Preference Optimization paper. ORPO is described as monolithic preference optimization that does not need a reference model. GRPO is a reinforcement learning method that the release notes claim can produce an 'aha moment' through pure RL. The newest addition, OPD, is on-policy distillation, with its own training entry and script. Each of these methods has its own training file and its own shell script in the repository, so you do not need to write the training loop yourself. You choose a stage, pick a script, and configure it.

Getting It Running: Scripts and Configuration

The README points to shell scripts as the primary entry points. For example, ORPO usage is referenced through scripts/run_orpo.sh, and the latest release adds scripts/run_opd.sh for the OPD stage. The project expects Python 3.8 or newer, as shown in the requirements badge. You clone the repository, install dependencies from requirements.txt, then edit the shell script for the stage you want. Each script likely sets environment variables for model name, data path, output directory, and training hyperparameters, though the README does not list every variable. The repository also includes a data directory with sample toolcall data, added in v2.6, and a role_play_data directory with a generation script that can call OpenAI, Doubao, or MiniMax providers to synthesize doctor-patient dialogues for SFT. For model support, the release notes mention specific architectures: LLaMA, LLaMA2, Bloom, ChatGLM, Baichuan, Qwen-2, Qwen-2.5, Qwen3.5, and Mixtral. If your model is not in that list, you may need to adapt the code yourself. The project also supports LoRA and full-parameter training, and DeepSpeed ZeRO-3 for MoE models like Mixtral and Qwen3.5 variants.

The Hard Parts: Data Preparation and Stage Order

The biggest practical hurdle is not running the scripts, it is preparing data for each stage. PT requires raw domain text, SFT requires instruction-response pairs, reward modeling requires preference rankings, and DPO or ORPO require preference pairs. Each stage has a different data format, and the README does not show those formats directly. You have to read the wiki or inspect the data examples in the repository. The role-play generation script helps with SFT data, but it only produces doctor-patient dialogues, which is a narrow slice of what a medical model might need. For a full pipeline, you need a lot of data at every stage, and the quality of the reward model or preference data will determine whether the RLHF or DPO stage improves anything. If you only have a few hundred instruction examples, the later stages may not help. The README also notes that PT is optional, which is a sensible admission, because continued pretraining on small domain corpora often does little and can even hurt if the data is noisy. Another constraint is compute. Full-parameter training on a 13B model, which the project has done for its released models, requires multiple GPUs. LoRA reduces that burden, but preference optimization stages still need to run inference on the model repeatedly.

Where It Falls Short

MedicalGPT is a research-oriented toolkit, not a polished product. The README is heavy on release notes and light on end-to-end usage examples. There is no quickstart that takes you from a raw dataset to a trained model in one command. You are expected to know which stage you need and why. The documentation lives in a wiki, which is separate from the README, so the main file gives you an overview but not the details. The project also moves fast, with releases every few weeks in 2026, which means the API can shift. A script that works in v2.5 may change in v2.6 or v2.7. That is a maintenance cost. If you adopt it, you should pin a release and test your training runs before upgrading. Another limitation is that the project is not a medical advisor. It is a training pipeline. The models it produces can give wrong or harmful medical answers, and the README does not claim any clinical validation. Anyone deploying a model trained with this pipeline in a healthcare setting has to do their own safety testing and compliance work. The project does not include evaluation benchmarks for medical accuracy, so you cannot measure whether your trained model is actually better than the base model without building your own evaluation set.

Alternatives: LLaMA-Factory and the RLHF Route

The closest alternative is LLaMA-Factory, another open-source project that supports SFT, DPO, and other tuning methods on a wide range of models. The key difference is scope. LLaMA-Factory is a general-purpose tuning framework designed for quick experiments, with a web UI and a simpler command-line interface. MedicalGPT is a pipeline that follows a specific training philosophy, the ChatGPT pipeline, and it includes stages like reward modeling and RLHF that LLaMA-Factory also covers, but MedicalGPT ties them together in a sequence. If you want to run a single SFT job and compare a few LoRA adapters, LLaMA-Factory is likely easier. If you want to reproduce a full RLHF pipeline on a domain model, MedicalGPT gives you the scripts and the structure to do that without assembling the stages yourself. There is also the option of using the original TRL library from Hugging Face, which provides the building blocks for DPO and PPO but requires you to write the training loop and data handling yourself. MedicalGPT sits above TRL, providing a higher-level entry point. The choice depends on whether you want a guided pipeline or a bag of parts.

Maintenance, Licensing, and Upgrade Cost

The project is under active development. The last push was June 2026, and releases 2.5, 2.6, and 2.7 came out within two weeks of each other in April 2026. That velocity means new model support and new training methods arrive quickly, but it also means you should expect breaking changes. The README does not promise backward compatibility. The license is Apache-2.0, which allows commercial use, modification, and redistribution, provided you keep the license notice. That is a permissive license, but it does not cover the base models you train on. LLaMA, Qwen, and other models have their own licenses, some of which restrict commercial use. You need to check the license of your chosen base model separately. The project also releases pretrained medical models on Hugging Face, but those weights carry their own terms. The upgrade cost is moderate. Because each stage has its own script, upgrading from one version to the next may require updating your data format or your script arguments. The release notes for each version describe what changed, so you can read those before upgrading. The wiki is the place to look for details, but the README does not state how current the wiki is. You should verify that the wiki matches the release you are using.

Editorial conclusion

Adopt MedicalGPT if you already work with Hugging Face models, need a single codebase for several preference optimization methods, and have the GPU budget for multi-stage training. Skip it if you only need one quick SFT pass, because the project's value is in the full pipeline and the extra stages add real complexity. Before you commit, verify that your base model is in the supported list, read the wiki for the exact data format for your chosen stage, and check the release notes for any recent changes to the training scripts. The project is Apache-2.0, so you can modify and redistribute it freely, but the model weights you train carry their own licenses. If you want a minimal, single-stage tuning tool with a smaller feature set, look at alternatives like LLaMA-Factory instead.

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. Releases
5. shibing624/MedicalGPT on GitHub