Continued Pretraining mit Firmendaten: GPU-Zeit, Speicher und Datenaufbereitung auf 8 GPUs

Kann ein Unternehmen Continued Pretraining auf dem eigenen Server betreiben

Continued Pretraining, auch Domänenanpassung genannt, heißt, ein offenes Basismodell mit einer großen Menge Rohtext weiterzutrainieren, etwa mit Handbüchern, Berichten und Korrespondenz eines Unternehmens, mit demselben Ziel der Vorhersage des nächsten Tokens wie im ursprünglichen Pretraining. Auf einem Server mit acht Karten ist das für Modelle bis etwa 32B Parameter und Tokenmengen im niedrigen Milliardenbereich machbar: Nach unserer Rechnung braucht ein 8B-Modell auf acht NVIDIA H200 NVL etwa zwei Tage je 10 Milliarden Tokens. Planen Sie die Datenaufbereitung als eigenes Projekt.

Die Rechnung dahinter ist kurz, und sie entscheidet über den Server. Diese Seite rechnet sie für 8B-, 32B- und 70B-Modelle auf acht H200 NVL und auf acht Karten der NVIDIA RTX PRO 6000 Blackwell Server Edition durch und behandelt dann Speicher, Datenaufbereitung und das, was Continued Pretraining einem Modell beibringt und was nicht. Überwachtes Fine-Tuning mit kleineren Datensätzen behandelt unser Leitfaden zum Fine-Tuning-Server mit 2, 4 oder 8 GPUs, ein vollständiges Fine-Tuning eines Modells im Detail unsere Seite zum vollständigen Fine-Tuning von Qwen3.8-27B.

Für die Geschäftsführung zählen drei Zahlen: wie viele Tokens verwertbaren Texts das Unternehmen hat, welche Modellgröße es anpassen will und wie viele Tage der Server belegt sein darf. Beginnen Sie mit der ersten. Die Angabe von Anthropic, die unser Vergleich von Fine-Tuning und RAG zitiert, setzt 200.000 Tokens mit etwa 500 Seiten gleich; 10 Milliarden Tokens wären nach unserer Rechnung also etwa 25 Millionen Seiten. Zählen Sie die Tokens einer Stichprobe mit dem Tokenizer des Modells, bevor Sie einen Lauf planen.

GPU-Zeit nach 6·N·D

Der Rechenaufwand beim Training eines dichten Transformers beträgt etwa sechs Gleitkommaoperationen je Parameter und Token. EleutherAIs „Transformer Math 101“ schreibt das als C ≈ 6PD, mit etwa 2PD für den Vorwärts- und 4PD für den Rückwärtsdurchlauf. Für Llama 3.1 8B mit 8,03 Milliarden Parametern ergeben 10 Milliarden Tokens 6 × 8,03 × 10⁹ × 10¹⁰ ≈ 4,8 × 10²⁰ FLOP. Zum Vergleich: Die Modellkarte von Meta gibt an, dass Llama 3.1 auf „~15 trillion tokens“ vortrainiert wurde, und nennt 1,46 Millionen H100-GPU-Stunden für das 8B-Modell.

Um aus FLOP Tage zu machen, teilen Sie durch die Spitzenleistung der Karten und durch den Anteil davon, den ein Lauf erreicht, seine Model FLOP Utilization (MFU). Das README von NVIDIAs Megatron-LM nennt „up to 47% Model FLOP Utilization (MFU) on H100 clusters“; in den Läufen zur schwachen Skalierung steigt die MFU „from 41% for the smallest model considered to 47–48% for the largest models“. Das sind abgestimmte Läufe auf großen H100-Clustern. Auf einem PCIe-Server mit NVLink-Brücken oder ganz ohne NVLink und mit allgemeinen Frameworks sollten Sie niedriger planen. Wir zeigen 40 Prozent als optimistischen und 20 Prozent als vorsichtigen Fall; den echten Wert liefert Ihr eigener kurzer Testlauf.

Die Spitzenwerte sind dichtes BF16: 835,5 TFLOPS je H200 NVL, die Hälfte der 1.671 TFLOPS, die NVIDIA mit Sparsity angibt, und 503,8 TFLOPS für die RTX PRO 6000 Workstation Edition laut NVIDIAs Architektur-Whitepaper. Für die Server Edition nennt NVIDIA keinen dichten Wert; sie läuft mit niedrigeren Takten, die Zahlen unten sind für sie also eine Obergrenze.

Unsere Rechnung: C = 6 × Parameter × Tokens (8,03, 32,76 und 70,55 Milliarden Parameter); Zeit = C ÷ (8 × dichte BF16-Spitzenleistung × MFU), bei MFU 40 % und 20 %. Spitzenwerte 835,5 TFLOPS (H200 NVL) und 503,8 TFLOPS (Workstation Edition, Obergrenze für die Server Edition).

Die Laufzeit wächst linear mit der Tokenzahl. Eine Milliarde Tokens auf dem 8B-Modell braucht etwa 5 bis 10 Stunden auf acht H200 NVL und mindestens 8 bis 17 Stunden auf acht Karten der Server Edition. FP8-Training verdoppelt die Spitzenleistung beider Karten, doch veröffentlichte Werte zur Auslastung beim FP8-Training auf diesen Karten haben wir nicht gefunden; die Tabelle bleibt daher bei BF16.

Die Neuberechnung von Aktivierungen bringt zusätzliche Arbeit. EleutherAIs Beitrag begrenzt sie auf „a full additional forward pass“. Die MFU zählt nur die 6PD des Modells; die Neuberechnung zeigt sich also als niedrigere MFU und nicht als zusätzliche FLOPs in der Formel, und die Tabelle rechnet sie nicht noch einmal hinzu.

Wir bauen Trainingsserver mit acht Karten der H200 NVL oder der RTX PRO 6000 Server Edition; schicken Sie uns Ihre Tokenzahl und das Modell, das Sie anpassen wollen, und unser Team antwortet mit der geschätzten Laufzeit und der Konfiguration dafür.

Speicher für das Training aller Parameter

Dieser Abschnitt geht davon aus, dass alle Gewichte trainiert werden, wie im ursprünglichen Pretraining. Wir verwenden dieselbe Regel wie unser Leitfaden zum GPU-Speicher für Fine-Tuning: 16 Byte je Parameter mit Adam in Mixed Precision, die EleutherAIs Beitrag in 2 Byte 16-Bit-Gewichte, 2 Byte Gradienten und 12 Byte Optimiererzustände aufteilt, eine 32-Bit-Kopie der Gewichte eingeschlossen. Mit FSDP oder DeepSpeed ZeRO-3 auf acht Karten geshardet:

Unsere Rechnung aus den Modellzuständen auf unseren Fine-Tuning-Seiten; 8-Bit-Adam mit etwa 10 Byte je Parameter; freier Speicher gegenüber der angegebenen Kapazität (96 und 141 GB). Aktivierungen kommen aus dem freien Rest.

Pretraining läuft auf langen, gepackten Sequenzen; Aktivierungen nehmen daher einen großen Teil des freien Speichers ein, und Activation Checkpointing tauscht sie gegen die oben genannte Neuberechnung. Das 8B-Modell lässt auf beiden Servern Platz. Das 32B-Modell passt auf acht Karten der Server Edition mit etwa 30 GB je Karte für Aktivierungen. Das 70B-Modell gehört auf acht H200 NVL mit 8-Bit-Adam oder mit dem Optimierer im Hauptspeicher, den unsere Seite zum Fine-Tuning-Server für Llama 3.3 70B mit etwa 988 GB ansetzt; auf acht Karten der Server Edition sind 7,8 GB Rest je Karte keine Grundlage für einen Plan.

Der Verkehr zwischen den Karten ist bei langen Läufen kleiner, als er aussieht. Ein geshardeter Schritt sammelt die 16-Bit-Gewichte zweimal ein und reduziert die Gradienten einmal, beim 8B-Modell etwa 3 × 16,1 GB × 7/8 ≈ 42 GB je Karte und Micro-Batch, etwa 0,66 Sekunden bei 64 GB/s über PCIe Gen5. Ein Micro-Batch mit 16.384 Tokens je Karte braucht bei 40 Prozent von 503,8 TFLOPS etwa 3,9 Sekunden Rechenzeit. Nach unserer Rechnung macht der Verkehr damit auch ohne NVLink etwa ein Sechstel der Rechenzeit aus, und FSDP überlappt einen Teil davon. Auf acht H200 NVL sind die Karten in jeder Domäne aus vier Karten über NVLink verbrückt, doch ein über alle acht geshardeter Lauf geht zwischen den beiden Domänen weiter über PCIe; der PCIe-Wert ist dort also ebenfalls der Planungswert, wie unsere Seite zur NVLink-Brücke der H200 NVL erklärt.

LoRA statt Training aller Parameter

LoRA lässt sich auch für Continued Pretraining einsetzen. Der Leitfaden von Unsloth zum Continued Pretraining nimmt lm_head und embed_tokens in die trainierten Module auf, nutzt Rang 16 und gibt den Embeddings eine „2-10x smaller“ Lernrate, etwa 5e-5 für die Adapter und 5e-6 für die Embeddings, für Fälle wie das Erlernen einer neuen Sprache. Der Speicherbedarf sinkt auf die eingefrorene Basis plus Adapter.

Der Preis dafür ist dokumentiert. Das Paper „LoRA Learns Less and Forgets Less“ (Mai 2024) verglich beide Methoden für Programmierung und Mathematik, darunter Continued Pretraining auf 20 Milliarden unstrukturierten Tokens, und fand, dass „LoRA substantially underperforms full finetuning“ in üblichen Einstellungen mit niedrigem Rang, während es „better maintains the base model's performance on tasks outside the target domain“. Der Rechenaufwand je Token sinkt mit eingefrorener Basis auf etwa 4N, Vorwärtsdurchlauf plus Gradienten der Eingaben, nach derselben Rechnung wie auf unserer Seite zum Fine-Tuning von gpt-oss; ein LoRA-Lauf des 8B-Modells auf 10 Milliarden Tokens braucht daher etwa zwei Drittel der Zeit aus der Tabelle oben.

Datenaufbereitung: deduplizieren, filtern, tokenisieren

Die Pipeline von den Dokumenten zu den Trainingstoken ist ein eigenes Projekt. Sie läuft auf Prozessoren und in einigen Schritten auf GPUs.

Extrahieren und bereinigen. Wandeln Sie PDFs, Office-Dokumente und E-Mails in reinen Text um, entfernen Sie wiederkehrende Bestandteile wie Signaturen, Kopfzeilen und Navigation, und lassen Sie Dokumente weg, die Ihre Rechtsberatung und Ihr Datenschutz­beauftragter nicht für das Training freigegeben haben.

Deduplizieren. Firmenarchive enthalten viele Kopien und Beinahe-Kopien desselben Dokuments. NVIDIAs NeMo Curator, Apache 2.0, bietet „exact/fuzzy/substring deduplication“ auf GPUs über RAPIDS und Ray; sein README nennt eine unscharfe Deduplizierung eines Teils von RedPajama v2 in 0,65 Stunden auf drei H100-Knoten gegenüber 10,7 Stunden mit einer prozessorbasierten Alternative, und sein GPU-Pfad für Text braucht etwa 16 GB GPU-Speicher. Hugging Faces datatrove, ebenfalls Apache 2.0, ist „a library to process, filter and deduplicate text data at a very large scale“ mit Beispielen für MinHash-, Satz- und Exact-Substring-Deduplizierung und läuft lokal, unter Slurm oder auf Ray.

Filtern und klassifizieren. NeMo Curator nennt für Text Klassifikation, Qualitätsfilter, kombinierte Qualitätsklassifikatoren und Spracherkennung. Entscheiden Sie, welche Dokumenttypen in den Korpus gehören: Tausend Kopien eines Serienbriefs bringen dem Modell wenig bei.

Tokenisieren und packen. Tokenisieren Sie mit dem Tokenizer des Basismodells und speichern Sie die Token-IDs. Nach unserer Rechnung belegen 10 Milliarden Tokens bei 4 Byte je Token-ID 40 GB; 2 Byte reichen nur für Vokabulare mit höchstens 65.536 Einträgen, und Llama 3.1 hat 128.256. Checkpoints brauchen mehr Platz als die Daten: Ein fortsetzbarer Checkpoint eines vollständigen 8B-Trainings enthält bei 14 Byte je Parameter etwa 112 GB, nach den Zahlen auf unserer Seite zum Fine-Tuning-Server.

Vergessen, Lernrate und Datenmischung

Ein Modell, das nur auf Firmentexten trainiert wird, verliert einen Teil seiner allgemeinen Fähigkeiten. Die Studie „Simple and Scalable Strategies to Continually Pre-train Large Language Models“ (2024) fand, dass „a simple and scalable combination of learning rate (LR) re-warming, LR re-decaying, and replay of previous data“ das Niveau eines Trainings von Grund auf erreichte, getestet bis zu einem Modell mit 10B Parametern, und dabei „saving significant compute compared to re-training“. Replay heißt, allgemeinen Text der Art, auf der das Modell ursprünglich trainiert wurde, in Ihren Korpus zu mischen; die Zusammenfassung nennt keinen festen Anteil, testen Sie die Mischung also in einem kleinen Lauf mit Ihrem Evaluierungssatz.

Für Sprache und Stil sind die Gewinne belegt. „Don't Stop Pretraining“ (2020) fand, dass „a second phase of pretraining in-domain (domain-adaptive pretraining) leads to performance gains“, in vier Domänen, darunter biomedizinische und informatische Fachpublikationen.

Bei Fakten sieht es anders aus. Die EMNLP-Studie von 2024, die unser Vergleich von Fine-Tuning und RAG bespricht, führte unüberwachtes Continued Pretraining mit neuem Material durch und kam zu dem Schluss, dass Modelle auf diesem Weg „struggle to learn new factual information“; die Suche über die Dokumente schnitt besser ab. Nutzen Sie Continued Pretraining, um die Sprache Ihrer Domäne zu vermitteln, und behalten Sie die Suche, wie in unserem Leitfaden zu RAG auf Firmendaten, für Fakten, die sich ändern. Ob eine Änderung dieser Größe Folgen nach dem EU AI Act hat, behandelt unsere Seite zu AI Act und Fine-Tuning; die Bewertung bestätigt Ihre Rechtsberatung.

Welcher Server für Continued Pretraining

8B-Modelle, bis zu einigen Milliarden Tokens. Acht Karten der RTX PRO 6000 Server Edition, nach unserer Rechnung mindestens 3,5 Tage je 10 Milliarden Tokens, mit 80 GB je Karte frei für Aktivierungen. Unsere Seite zum Kauf eines Servers mit 8× RTX PRO 6000 Server Edition nennt die Konfiguration.

8B- bis 32B-Modelle oder wiederholte Läufe. Acht H200 NVL mit zwei 4-Wege-NVLink-Brücken, 2,3 TB Hauptspeicher und acht NVMe-Laufwerken, unsere Trainingskonfiguration: etwa 2,1 Tage je 10 Milliarden Tokens für das 8B-Modell bei 40 Prozent MFU, 8,5 Tage für das 32B-Modell.

70B-Modelle. Acht H200 NVL mit 8-Bit-Adam oder ausgelagertem Optimierer, 18 Tage oder mehr je 10 Milliarden Tokens, oder zwei solcher Server im 400G-Netz. Unsere Seite zum Server mit acht H200 NVL beschreibt die Hardware, unsere Seite zum Kauf eines Servers mit 8× H200 NVL die Bestellung.

Acht H200 NVL mit 600 W und zwei AMD EPYC 9555 mit 64 Kernen nehmen nach unserer Schätzung (Karten und Prozessoren plus 15 Prozent für den Rest) etwa 6,3 kW aus dem Netz auf; der Lauf des 8B-Modells von 50 Stunden verbraucht damit etwa 315 kWh. Eine Messung am gelieferten System bestätigt den Wert.

Einen Trainingsserver bei uns bestellen

Sie können dieses System bei uns kaufen: Unser Team dimensioniert die Konfiguration nach Ihrer Arbeitslast und Ihrem Budget und antwortet innerhalb eines Werktages. Der Server wird vor der Lieferung montiert und getestet und in der EU mit einem Vertrag und einer Rechnung geliefert, mit Herstellergarantie auf jede Komponente und der Montage in unserer Verantwortung. Auf Anfrage installieren wir Betriebssystem, Treiber, CUDA und eine Container-Runtime. Datenpipeline und Trainingsplattform darauf gehören zu unserem Service Private AI/ML, den unser Engineering-Partner Vixen.UNO umsetzt. Mengen und Lieferzeit bestätigen wir schriftlich mit dem Angebot. Beschreiben Sie Ihren Korpus, das Basismodell und die Zeit, die der Lauf dauern darf, und wir antworten mit einer Konfiguration und einem schriftlichen Angebot.

FAQ