KI-Modelle auf Cloud-GPUs feinabstimmen

Wenn Ihr Team ein LLM-Feinabstimmungsprojekt plant, eine RAG-Pipeline aufbaut oder mit einem multimodalen Modell experimentiert, das Text- und visuelle Inhalte kombiniert, ist das Hindernis fast immer dasselbe: Jemand hat Sie aufgefordert, einen Serverkauf im Wert von 100.000 bis 500.000 Euro zu rechtfertigen, bevor ein einziger Entwickler eine Zeile Trainingscode geschrieben oder eine Anwendung bereitgestellt hat. Dieses Gespräch kann Monate dauern, und während Sie darauf warten, dass die Finanzabteilung das Budget freigibt, haben Ihre Wettbewerber bereits geliefert.

Die Alternative ist GPU as a Service. Sie stellen eine H100 oder A100 bereit, wenn Sie sie benötigen, führen Ihren Trainingsauftrag aus und bezahlen nur für die Stunden, die Sie tatsächlich nutzen. Keine Beschaffungswarteschlange, keine ungenutzte Hardware, keine Investitionsdebatte. OVHcloud AI Solutions bietet den vollständigen Stack: verwaltete Notebooks, serverlose Trainingsaufträge, Inferenz-Endpunkte und einen Katalog vortrainierter Open-Weight-Grundlagenmodelle – alles auf souveräner EU-Infrastruktur.

Dieser Leitfaden erläutert, warum Cloud-GPU-Training für die meisten Teams im Bereich generative KI wirtschaftlich sinnvoll ist, wie die OVHcloud-Plattform in der Praxis aussieht und wie Sie genau von einem Datensatz zu einem bereitgestellten Modell-Endpunkt gelangen, ohne einen einzigen physischen Server zu berühren. Er spiegelt einen der deutlichsten Trends in der Infrastruktur für generative KI wider: Bezahlen Sie für GPU-Stunden, nicht für GPU-Hardware.

Schritt 1 — Starten Sie ein AI Notebook mit GPU und Ihrem ML-Framework

Melden Sie sich im OVHcloud Control Panel an, navigieren Sie zu AI Notebooks und erstellen Sie ein neues Notebook. Wählen Sie Ihre GPU-Variante (H100 oder V100S für anspruchsvolle Arbeiten, L4 für leichtere Experimente), wählen Sie Jupyter oder VS Code und wählen Sie ein vorgefertigtes Image, das zu Ihrem Stack passt. Das Notebook ist in wenigen Minuten mit CUDA, Ihrem gewählten Framework und einem einsatzbereiten Terminal live.
Verbinden Sie Ihren Object Storage-Bucket beim Start als Daten-Volume. Dies bedeutet, dass Ihr Datensatz als lokaler Pfad innerhalb des Notebooks ohne manuelles Kopieren verfügbar ist und Ihre Modell-Checkpoints während des Trainings direkt in den Bucket geschrieben werden können – ein einfaches, effektives Muster für jedes Team, nicht nur für spezialisierte ML-Plattform-Ingenieure.

Schritt 2 — Bereitstellung Ihres Datensatzes im Object Storage

Object Storage (S3-kompatibel)* ist die kanonische Datenschicht für AI-Trainingsjobs. Es ist S3-kompatibel, sodass Ihre vorhandenen Tools (boto3, die AWS CLI, rclone) ohne Modifikation funktionieren. Laden Sie Ihr Trainingskorpus, tokenisierte Datensätze und alle vorverarbeiteten Artefakte hier hoch, bevor Sie einen Trainingsjob übermitteln. Wenn Ihre Pipeline Schritte zur Datenanreicherung enthält, führen Sie diese vorgelagert aus und speichern Sie den resultierenden Datensatz zur Reproduzierbarkeit und Versionskontrolle zusammen mit dem Original.

Ein praktischer Vorteil: Es fallen keine Datenausgangsgebühren zwischen OVHcloud-Diensten an. Das Verschieben von Daten aus dem Object Storage auf eine GPU-Instanz für das Training, das Zurückschreiben von Checkpoints in den Speicher während des Jobs oder das Abrufen von Modellartefakten in AI Deploy nach dem Training – keiner dieser Transfers verursacht versteckte Kosten. Die Iteration Ihres Datensatzes und der Datenqualität im Allgemeinen ist kostengünstig.

Schritt 3 – Senden Sie einen Trainingsjob ab und wählen Sie die richtige GPU-Variante aus

Paketieren Sie Ihr Trainingsskript als Docker-Image (oder verwenden Sie ein vorgefertigtes OVHcloud-Image) und übermitteln Sie einen Job mit der ovhai CLI:

ovhai job run --gpu 1 --flavor h100-1-gpu --volume my-bucket@GRA/dataset:/workspace/data:ro --volume my-bucket@GRA/output:/workspace/output:rw my-registry/my-training-image:latest

Wählen Sie Ihre GPU-Variante basierend auf den VRAM-Anforderungen: Ein 7B-Modell-Fine-Tuning passt normalerweise auf eine einzelne H100 mit 80 GB VRAM; größere Modelle oder größere Batch-Größen erfordern möglicherweise eine H200 oder eine Multi-GPU-Anfrage, um das Training zu beschleunigen. Der Job läuft serverlos und wird über Live-Logs im Control Panel oder über die API überwacht. Wenn er endet, befinden sich Ihre Modellartefakte im Object Storage.

Schritt 4 – Stellen Sie Ihr Modell mit AI Deploy oder AI Endpoints bereit

Erstellen Sie für ein benutzerdefiniertes, feinabgestimmtes Modell eine AI Deploy-App, die auf Ihr Modell-Artefakt im Object Storage verweist. Konfigurieren Sie Autoscaling basierend auf Anfragevolumen und Speicherschwellenwerten und aktivieren Sie Response-Caching, wo Ihr Verkehrsmuster dies zulässt, um die Inferenzkosten weiter zu senken – eine einfache Technik, die sich gut mit Request-Batching für durchsatzsensitive Anwendungen kombinieren lässt. Jede Caching-Ebene, die Sie hinzufügen, reduziert gleichzeitig die durchschnittliche Latenz und verbessert das Kosten-Leistungs-Verhältnis. Ihr Endpunkt ist innerhalb von Minuten live und skaliert entsprechend dem Datenverkehr.

Überspringen Sie bei Standard-Open-Weight-Modellen den Bereitstellungsschritt vollständig und fragen Sie AI Endpoints direkt ab. Die API ist mit dem OpenAI-Client-Format kompatibel, sodass bestehende Integrationen oft nur eine Änderung der Basis-URL erfordern.

Das 7B-Fine-Tuning, das auf einer einzelnen H100 in wenigen Stunden läuft

Die überwiegende Mehrheit der generativen KI-Projekte trainiert nicht von Grund auf neu. Sie führen ein Fine-Tuning eines bestehenden vortrainierten Open-Weight-Foundation-LLM durch – Mistral 7B, Llama 3 8B, Falcon oder eine ähnliche Sprachmodellarchitektur – und zwar auf einem domänenspezifischen Datensatz. Fine-Tuning ist selbst eine Form des Transfer Learning: Sie beginnen mit einem Modell, das bereits flüssige Sprache im Allgemeinen generiert, und spezialisieren es für Ihre Aufgabe mit weitaus weniger GPU-Stunden als beim Training eines Modells von Grund auf. Unter Verwendung von Techniken wie LoRA oder QLoRA sowie Quantisierung zur Reduzierung der Speicherauslastung während des Trainings kann ein 7B-Modell auf einer einzelnen H100 in 4 bis 12 Stunden fertiggestellt werden, abhängig von der Datensatzgröße und der Anzahl der Epochen. Die meisten Entwicklerteams finden diese Technik auf der OVHcloud-Plattform weitaus zugänglicher als die Verwaltung ihrer eigenen Trainingsarchitektur.

Dies ist das Szenario, in dem Pay-as-you-go-Computing am wirtschaftlichsten ist. Sie führen Ihren Fine-Tuning-Job aus, bewerten das Ergebnis, passen den Datensatz oder die Hyperparameter an, um Overfitting auf einem kleinen domänenspezifischen Korpus zu verhindern, und führen ihn erneut aus. Jede Iteration kostet eine vorhersehbare Anzahl an GPU-Stunden. Sie können ein Dutzend Experimente für weniger als die monatliche Stromrechnung eines physischen Servers durchführen, die Modellleistung regelmäßig bewerten und die Modellfähigkeiten sowie die Qualität der generierten Inhalte mit jedem Durchgang verbessern – und das Ergebnis dann veröffentlichen, sobald es Ihre Anforderungen erfüllt.

Für mittelgroße Modelle im Bereich von 13B bis 70B Parametern sind Multi-GPU-Jobs auf OVHcloud möglich (bis zu 4 GPUs pro Job unter den aktuellen Limits). Planen Sie für das 70B-Fine-Tuning H100- oder H200-Instanzen ein und nutzen Sie Quantisierung, um VRAM-Beschränkungen zu verwalten und die Speicherauslastung Schicht für Schicht zu steuern.

Wann Sie mit einem Solutions Architect über groß angelegtes Vortraining sprechen sollten

Wenn Ihr Projekt das Vortraining eines Modells von Grund auf mit zehn- oder hundertmilliarden Parametern umfasst, ist das eine grundlegend andere architektonische Herausforderung und eine andere Art der Kundenbindung. Verteiltes Training über viele GPUs, benutzerdefinierte Netzwerk-Fabric, Checkpoint-Management im Petabyte-Maßstab und die Orchestrierung lang laufender Jobs sind keine Self-Service-Entscheidungen; sie erfordern dedizierte Tools und eine Referenzarchitektur, die für Ihren Fall erstellt wurde.

Für groß angelegtes Vortraining ist der richtige erste Schritt ein Gespräch mit einem OVHcloud AI Solutions Architect. Sie können Ihre Rechenanforderungen bewerten, GPU-Cluster-Optionen und das richtige Tool für jede Phase besprechen und Ihnen bei der Entwicklung einer Trainingsarchitektur helfen, die Ihrem Umfang und Ihrer angestrebten Leistungsverbesserung entspricht. Der Link zur Anforderung dieses Gesprächs befindet sich im Abschnitt „Erste Schritte“ weiter unten.

Kostenvergleich: On-Premise H100-Server vs. OVHcloud Pay-as-you-go

Anschaffungskosten, Strom, Betrieb und Abschreibung
Die Gesamtkosten eines On-Premise-GPU-Servers umfassen mehr als nur den Listenpreis. Ein typisches 8×H100 SXM-System kostet in der Anschaffung zwischen 150.000 und 250.000 Euro. Hinzu kommen: Upgrades der Strominfrastruktur, Kühlung, Rack-Platz, ein dreijähriger Wartungsvertrag und das Gehalt des Ingenieurs, der für den laufenden Betrieb verantwortlich ist. Über 36 Monate abgeschrieben, belaufen sich die Gesamtbetriebskosten auf wesentlich mehr als nur den Hardware-Listenpreis.

Bei OVHcloud fallen keine Anschaffungskosten an. Sie zahlen nur für die GPU-Stunden, die Sie verbrauchen, abgerechnet pro Minute, ohne Verpflichtung und ohne Leerlaufkosten. Wenn Ihr Projekt storniert wird, zahlen Sie nichts über das hinaus, was Sie bereits ausgeführt haben.

Keine CLOUD-Act-Exponierung bei Trainingsdaten

Der US CLOUD Act erlaubt es US-Behörden, Unternehmen mit Hauptsitz in den USA zur Herausgabe von Daten zu zwingen, die irgendwo auf der Welt gespeichert sind, einschließlich Daten, die von US-Cloud-Anbietern in europäischen Rechenzentren gehostet werden. Wenn Ihr Trainingskorpus personenbezogene Daten, Gesundheitsakten, Rechtsdokumente, Finanztransaktionen oder eine andere regulierte Kategorie enthält, schafft das Training auf einer Infrastruktur, die dem US-Recht unterliegt, ein Compliance-Risiko, das allein durch vertragliche Maßnahmen nur schwer vollständig zu mindern ist.

OVHcloud ist ein europäisches Unternehmen ohne US-Muttergesellschaft. Es besteht keine strukturelle Abhängigkeit vom CLOUD Act. Ihre Trainingsdaten verbleiben unter EU-Recht in der EU-Rechtsordnung. Für Teams in regulierten Sektoren – Gesundheitswesen, Finanzdienstleistungen, Legal Tech, öffentlicher Sektor – ist dies kein theoretischer Vorteil; es ist eine Anforderung und zunehmend das Hauptkriterium, nach dem Beschaffungsteams vorab fragen.

EU AI Act-Substrat, DSGVO, HDS und ISO 27701

Die Infrastruktur von OVHcloud ist nach ISO 27001, ISO 27017, ISO 27018 und ISO 27701 zertifiziert. Die HDS-Zertifizierung ist für Teams relevant, die Modelle mit Gesundheitsdaten in Frankreich trainieren. Im Hinblick auf die DSGVO werden auf OVHcloud verarbeitete Trainingsdaten innerhalb der EU gemäß EU-Recht gespeichert und verarbeitet, was Datenschutz-Folgenabschätzungen erheblich vereinfacht und zur Sicherstellung der laufenden Compliance beiträgt.

Eine Klarstellung, die wichtig ist: OVHcloud stellt das souveräne Infrastruktur-Substrat bereit. Die Einhaltung des EU AI Act auf Modellebene – Modellkarten, Erkennung von Verzerrungen, Audit-Protokolle, Transparenzpflichten – bleibt Ihre Verantwortung als Entwickler des KI-Systems. Souveräne Infrastruktur unterstützt Ihre Compliance-Verpflichtungen; sie erfüllt diese nicht automatisch.

Auf Analystenseite hat GigaOM Radar OVHcloud für Interkonnektivität und souveräne Verfügbarkeit ausgezeichnet, und IDC hat OVHcloud als Major Player im Bereich European Public Cloud IaaS benannt.