MedicalGPT: eine Trainingspipeline für medizinische Sprachmodelle

Welches Problem MedicalGPT adressiert

Die meisten Teams, die ein Sprachmodell auf medizinische Texte anpassen wollen, stehen vor dem gleichen Problem: Die einzelnen Verfahren sind publiziert, aber es fehlt eine zusammenhängende Umsetzung, die von der Datenaufbereitung bis zum fertigen Gewicht reicht. MedicalGPT versucht genau diese Lücke zu schließen. Das Repository beschreibt sich selbst als Umsetzung einer ChatGPT-Trainingspipeline für den medizinischen Bereich und nennt als Bestandteile Pretraining, Supervised Finetuning, RLHF mit Reward Modeling und Reinforcement Learning, DPO, ORPO, GRPO sowie OPD. Die Zielgruppe sind laut README Entwickler und Forscher, die ein Basismodell auf Domänendaten nachtrainieren wollen, statt ein allgemeines Modell direkt einzusetzen. Der Anspruch ist dabei nicht, ein fertiges Medizinmodell zu liefern. Das README beschreibt eine Trainingspipeline, und die im Repository verlinkten Modelle auf Hugging Face sind Beispiele früherer Läufe des Autors, keine garantierten Artefakte des aktuellen Codes.

Die Stufen der Pipeline und ihre Datenabhängigkeiten

Das README gliedert das Training in Stufen. Zuerst kommt PT (Continue PreTraining), ein zweites Pretraining auf Domänendokumenten, das laut README optional ist. Danach folgt SFT, bei dem ein Instruktionsdatensatz aufgebaut und das vortrainierte Modell darauf feinabgestimmt wird. Die dritte Stufe verzweigt sich: Entweder RLHF mit einem Reward Model nach dem HHH-Prinzip (helpful, honest, harmless) und anschließendem Reinforcement Learning, oder DPO, das laut README ohne komplexes Reinforcement Learning auskommt und menschliche Präferenzen direkt optimiert. In späteren Versionen kamen ORPO, GRPO und OPD hinzu. Wichtig ist, was diese Aufteilung für die Daten bedeutet: Jede Stufe braucht ein anderes Format. PT braucht Rohtext, SFT braucht Instruktions-Antwort-Paare, Reward Modeling braucht Rangfolgen, DPO und ORPO brauchen Präferenzpaare. Das README verweist für die Datenaufbereitung auf Skripte und auf Beispieldaten im data-Verzeichnis, etwa toolcall-Daten ab Version 2.6. Wer nur SFT-Daten hat, kann die späteren Stufen nicht einfach anhängen.

Verfahren, die auf unterschiedliche Weise auf Präferenzen zugreifen

Die interessanteste Designfrage steckt im Verhältnis von RLHF, DPO und ORPO. RLHF ist der aufwendigste Weg: Es braucht ein separates Reward Model, das auf einem Ranking-Datensatz trainiert wird, und danach eine Optimierungsschleife, in der das SFT-Modell gegen dieses Reward Model aktualisiert wird. DPO umgeht das Reward Model und optimiert das Sprachmodell direkt gegen Präferenzpaare. ORPO geht noch einen Schritt weiter und verbindet laut README die Präferenzoptimierung mit dem SFT-Schritt in einem einzigen Verfahren ohne Referenzmodell. Wer wenig Rechenzeit und wenig annotierte Ranking-Daten hat, ist mit DPO oder ORPO besser bedient. RLHF lohnt sich vor allem dann, wenn ein belastbares Reward Model als eigenständiges Artefakt gebraucht wird, etwa weil mehrere nachgelagerte Läufe darauf zugreifen sollen. GRPO schließlich wird im README als reines Reinforcement-Learning-Verfahren beschrieben, das laut Projekt einen aha moment erlebbar machen soll. Diese Formulierung stammt aus dem Projekt selbst; belastbare Messwerte dazu liefert das Material nicht.

Von der Installation zum ersten Trainingslauf

Das Repository gibt konkrete Einstiegspunkte vor. Die Startskripte liegen im Verzeichnis scripts/, und das README nennt namentlich scripts/run_orpo.sh für ORPO sowie scripts/run_opd.sh für die in Version 2.7 eingeführte OPD-Distillation. Für OPD existiert zusätzlich ein eigener Einstiegspunkt training/opd_training.py. Die Abhängigkeiten stehen in requirements.txt, und das README nennt Python 3.8 oder neuer als Voraussetzung. Der typische Ablauf besteht darin, ein Basismodell über den Modellpfad zu laden, einen der Trainingsskripte mit passenden Parametern aufzurufen und anschließend mit einem Inferenzskript zu prüfen. Für Retrieval-Augmented Generation verweist das README auf demo/chatpdf.py, das ab Version 1.7 verfügbar ist. Wer die Konfiguration anpassen will, findet die Parameter in den jeweiligen Skripten und in der Wiki-Dokumentation, auf die das README verlinkt. Wichtig: Das README dokumentiert nicht durchgängig jeden Schalter, und für einzelne Verfahren ist die Wiki-Seite die einzige Quelle.

Modellunterstützung und ihre Grenzen

Die Liste der unterstützten Architekturen wächst mit jeder Version. Genannt werden unter anderem LLaMA und LLaMA 2, Llama-3, Bloom, ChatGLM und ChatGLM2, Baichuan, Qwen-2, Qwen-2.5, Mixtral 8x7B als MoE-Beispiel, Qwen-2.5 und in Version 2.5 die Qwen3.5-Reihe inklusive Base-, Instruct- und MoE-Varianten. Für Qwen3.5 wurden laut Release Notes die Chat-Templates qwen3, qwen3_5, qwen3_nothink und qwen3_5_nothink ergänzt, und DeepSpeed ZeRO-3 wird für MoE-Training unterstützt. Diese Breite ist ein Vorteil, aber auch eine Warnung: Die Kompatibilitätsaussagen beziehen sich jeweils auf den Stand der Release Notes. Ein heute veröffentlichtes Basismodell, das nach dem letzten Release erschienen ist, wird dort nicht erwähnt und ist damit nicht abgedeckt. Wer ein sehr neues Modell verwenden will, muss selbst prüfen, ob Tokenizer, Chat-Template und Attention-Implementierung zusammenpassen. Das README gibt dafür keine Garantie.

Wo das Projekt an seine Grenzen stößt

Die deutlichste Einschränkung ist, dass MedicalGPT keine Daten mitbringt und keine Evaluationsergebnisse im Repository dokumentiert. Das README beschreibt Verfahren, aber es nennt keine Genauigkeitswerte, keine Vergleichsstudien und keine klinische Validierung. Wer ein Modell für den produktiven Einsatz in einem medizinischen Kontext braucht, muss die Bewertung selbst aufsetzen. Ein zweiter Punkt betrifft die Hardware. Die genannten Modelle reichen von 7B bis 13B Parametern, und Mixtral 8x7B ist ein MoE-Modell mit entsprechendem Speicherbedarf. Das README beschreibt zwar Techniken wie LoRA, DeepSpeed ZeRO-3, FlashAttention-2, LongLoRA mit S²-Attn, NEFTune und RoPE-Interpolation, aber es quantifiziert den Ressourcenbedarf nicht. Ein dritter Punkt: Die Pipeline ist auf den medizinischen Bereich zugeschnitten, aber die Verfahren selbst sind domänenunabhängig. Wer ein Modell für Recht oder Finanzen trainieren will, kann die Skripte verwenden, muss aber die Daten und die Chat-Templates anpassen, und das README hilft dabei nur begrenzt. Und schließlich: Die Qualität der späteren Stufen hängt vollständig von der Qualität der Präferenz- und Ranking-Daten ab. DPO und ORPO können schlechte Annotationen nicht ausgleichen, sie verstärken sie.

Was andere Projekte anders machen

Als Vergleich bietet sich LLaMA-Factory an, ein Projekt, das ebenfalls Feintuning für eine breite Modellpalette bereitstellt. Der Unterschied liegt im Schwerpunkt. LLaMA-Factory positioniert sich als allgemeine Trainings- und Inferenzplattform mit einer grafischen Oberfläche und einer sehr großen Zahl unterstützter Modelle. MedicalGPT konzentriert sich auf eine durchgängige Pipeline mit Domänenfokus und dokumentiert die einzelnen Stufen ausführlicher, inklusive der Herkunft der Verfahren aus den zitierten Papern. Wer eine breite Modellabdeckung und eine UI sucht, ist bei LLaMA-Factory besser aufgehoben. Wer die einzelnen Stufen der Präferenzoptimierung nachvollziehen und anpassen will, findet bei MedicalGPT mehr Erklärung im Repository. Beide Projekte sind unter Apache-2.0 lizenziert, was die kommerzielle Nutzung erlaubt, aber die Verantwortung für die Daten und die Ergebnisse beim Nutzer lässt.

Wartung, Lizenz und was vor dem ersten Lauf zu prüfen ist

Die Release-Kadenz ist hoch: Version 2.5 erschien am 7. April 2026, 2.6 am 14. April und 2.7 am 20. April. Der letzte Push liegt laut Repository-Metadaten auf dem 3. Juni 2026. Diese Frequenz bedeutet, dass sich Skripte und Parameter zwischen Versionen ändern können. Wer die Pipeline produktiv einsetzt, sollte die verwendete Version pinnen und die Release Notes vor jedem Upgrade lesen. Die Lizenz ist Apache-2.0, was die Nutzung, Änderung und Weitergabe erlaubt, sofern die Lizenzbedingungen eingehalten werden. Das ist keine Rechtsberatung, und insbesondere bei medizinischen Anwendungen kommen regulatorische Anforderungen hinzu, die das Repository nicht behandelt. Konkret zu prüfen sind vor dem ersten Lauf: die Datenformate in data/ gegen die eigene Datenlage, die in scripts/ liegenden Startskripte gegen die eigene Hardware, und die Wiki-Dokumentation für Parameter, die im README nicht auftauchen. Wer diese drei Punkte geklärt hat, kann einschätzen, ob die Pipeline zum eigenen Vorhaben passt.

Redaktionelles Fazit

Wer eine medizinisch zugeschnittene Pipeline für PT, SFT und Präferenzoptimierung sucht und die Hardware für 7B- bis 13B-Modelle stellt, findet hier einen zusammenhängenden Einstiegspunkt. Wer ein fertiges, klinisch validiertes Modell oder ein Managed Service erwartet, sollte Abstand nehmen. Vor dem ersten Lauf lohnt es sich, die in scripts/ liegenden Startskripte und die Datenformate in data/ gegen die eigene Datenlage zu prüfen, weil das Repository Abläufe liefert, aber keine Daten und keine Evaluationsergebnisse.

Offizielle Quellen

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