{"author":{"@type":"Person","name":"Alexander Bock","url":"https://abxk.ai/de/autor/alexander-bock/"},"categories":["AI Development"],"content":{"markdown":"Die meisten KI-Apps kommen nie mit einer GPU in Berührung. Sie rufen ein Modell über eine API auf, und der Anbieter betreibt die Hardware. Das ändert sich, wenn Sie ein Modell per Fine-Tuning anpassen, ein Modell mit offenen Gewichten selbst betreiben oder Millionen Dokumente in einem Durchlauf verarbeiten. Dann mieten Sie Rechenleistung — und die Rechnung hängt von Entscheidungen ab, die Sie treffen, bevor der erste Job startet.\n\nDies ist Teil 3 von Level 3 (Profi). Sie lernen, wann Sie wirklich GPUs brauchen, wie Sie den GPU-Speicher aus der Modellgröße abschätzen, welche Mietform zu welcher Last passt und wie Sie die Auslastung hoch und die Kosten im Griff halten. Wir erklären die Kostenlogik, keine Preise.\n\n## Wann Sie GPUs brauchen — und wann nicht\n\nEine **GPU** (Graphics Processing Unit, also ein Grafikprozessor) hat Tausende kleiner Rechenkerne und sehr schnellen Speicher. Deshalb eignet sie sich für die Matrizenrechnungen in neuronalen Netzen. Der Speicher auf der Karte heißt **VRAM**, und er entscheidet, welche Modelle Sie ausführen können.\n\nEigene GPUs, gemietet oder gekauft, brauchen Sie in vier Situationen:\n\n- **Fine-Tuning:** Sie trainieren ein Modell mit offenen Gewichten auf Ihren eigenen Beispielen weiter. Manche Anbieter passen auch ausgewählte geschlossene Modelle als Dienst für Sie an; dann sind die GPUs deren Sache. Teil 4 dieses Levels hilft bei der Wahl zwischen [Fine-Tuning, RAG und Prompting](/de/ai-development/learn/fine-tuning-vs-rag-vs-prompting/).\n- **Selbstbetrieb:** Daten dürfen Ihre Infrastruktur nicht verlassen, oder Sie brauchen volle Kontrolle über die Modellversion.\n- **Batch-Jobs:** Sie berechnen Embeddings für ein großes Archiv oder ordnen Millionen Datensätze ein, und die gleichmäßige Last hält die GPU beschäftigt.\n- **Training von Grund auf:** außerhalb von Forschungslaboren und großen Unternehmen selten.\n\nKeine GPUs brauchen Sie, wenn Sie einen Prototyp bauen, wenn wenige oder unregelmäßige Anfragen kommen oder wenn das beste Modell für Ihre Aufgabe nur über eine API verfügbar ist. Eine gehostete API macht aus Fixkosten Kosten pro Anfrage, und um Updates, Skalierung und Ausfälle kümmert sich jemand anderes. Mit eigenen GPUs wandert diese Arbeit zu Ihrem Team: Treiber- und Sicherheitsupdates, Monitoring, Reserven für Lastspitzen und ein Plan für den Tag, an dem eine Maschine ausfällt.\n\n![Entscheidungsbaum: Start mit einer gehosteten API; vier Ja-Nein-Fragen zu Datenkontrolle, Lernen aus eigenen Beispielen, großen Batch-Jobs und stetig hoher Last führen jeweils zu einer Form, GPUs zu mieten; viermal Nein heißt, Sie bleiben bei der API](/images/learn/de/gpu-infrastructure-for-ai-decide.webp \"API oder eigene GPUs? Beginnen Sie mit der API, und wechseln Sie erst, wenn ein klarer Grund auftaucht.\")\n\nModelle mit offenen Gewichten sind die üblichen Kandidaten für den Selbstbetrieb. Unsere [LLM-Datenbank](/de/llm/) führt {{\u003c stat \"models-open\" \u003e}} Modelle mit offenen Gewichten, mit Erscheinungsdatum und Testergebnissen. Offene Gewichte bedeuten nicht immer freie Nutzung: Manche Lizenzen schränken die kommerzielle Nutzung ein oder stellen andere Bedingungen. Lesen Sie deshalb die Lizenz, bevor Sie auf einem Modell aufbauen.\n\n## GPU-Speicher: eine Faustregel\n\nDie erste Frage lautet, ob das Modell in den GPU-Speicher passt. Für die Gewichte des Modells liefert eine einfache Formel eine gute Schätzung:\n\n*Speicher für die Gewichte (GB) ≈ Parameter (in Milliarden) × Bytes je Parameter*\n\nJeder Parameter belegt in 16-Bit-Genauigkeit (FP16 oder BF16) 2 Bytes, in 8 Bit 1 Byte und in 4 Bit etwa ein halbes Byte. Gewichte mit weniger Bits zu speichern, heißt **Quantisierung**. Sie spart Speicher und beschleunigt oft die Inferenz, kann aber etwas Qualität kosten. Testen Sie sie deshalb an Ihrer eigenen Aufgabe.\n\nFür die Inferenz, also die Nutzung des Modells, reicht der Platz für die Gewichte nicht. Der **KV-Cache** speichert Zwischenergebnisse für den Text, den das Modell schon verarbeitet hat, damit es sie nicht für jedes neue Token neu berechnen muss. Er wächst mit der Kontextlänge und mit der Zahl der Anfragen, die parallel laufen. Für eine schnelle Prüfung empfiehlt EleutherAI, für die Inferenz etwa das 1,2-Fache des Speichers der Gewichte einzuplanen (Quelle: EleutherAI, „Transformer Math 101“, 2023, blog.eleuther.ai). Das genügt für kurze Prompts und wenige parallele Anfragen. Lange Kontexte und viele gleichzeitige Nutzer können deutlich mehr brauchen.\n\n| Modellgröße | 16 Bit | 8 Bit | 4 Bit | Volles Fine-Tuning (~16 Bytes je Parameter) |\n|---|---|---|---|---|\n| 7B | ~14 GB | ~7 GB | ~3,5 GB | ~112 GB |\n| 13B | ~26 GB | ~13 GB | ~6,5 GB | ~208 GB |\n| 34B | ~68 GB | ~34 GB | ~17 GB | ~544 GB |\n| 70B | ~140 GB | ~70 GB | ~35 GB | ~1.120 GB |\n\nDie Tabelle zeigt grobe Näherungen, nur für die Gewichte; „B“ steht für Milliarden (englisch *billion*) Parameter. Viele verbreitete GPUs haben 24, 48 oder 80 GB Speicher, die neuesten Rechenzentrumsmodelle mehr. Das Diagramm schlägt die 20 Prozent für die Inferenz auf und zeigt, welche Kombinationen passen:\n\n![Balkendiagramm: ungefährer Speicherbedarf für die Inferenz von Modellen mit 7, 13, 34 und 70 Milliarden Parametern in 16, 8 und 4 Bit, mit Linien für GPU-Speichergrößen von 24, 48 und 80 GB](/images/learn/de/gpu-infrastructure-for-ai-memory.webp \"Ungefährer Speicherbedarf für die Inferenz: Gewichte plus etwa 20 Prozent. Werte aus der Faustregel, keine Messungen.\")\n\n{{\u003c callout type=\"example\" title=\"Ein 13B-Modell für Fragen zu internen Dokumenten dimensionieren\" \u003e}}\nGewichte in 8 Bit: 13 Milliarden × 1 Byte ≈ 13 GB. Dazu etwa 20 Prozent für KV-Cache und Overhead: rund 16 GB. Das passt auf eine GPU mit 24 GB, mit etwas Reserve für längere Kontexte. Es sind Näherungen — messen Sie mit Ihren echten Prompts und Ihrer echten Last, bevor Sie sich festlegen.\n{{\u003c /callout \u003e}}\n\nTraining braucht weit mehr. Volles Fine-Tuning mit dem verbreiteten Adam-Optimierer in gemischter Genauigkeit (Mixed Precision) braucht etwa 16 Bytes je Parameter für Gewichte, Gradienten und Optimiererzustände (Quelle: Rajbhandari u. a., „ZeRO“, Microsoft, 2020). Dazu kommen die **Aktivierungen**, die Zwischenergebnisse jedes Trainingsschritts. Deshalb nutzen die meisten Teams **LoRA** (Low-Rank Adaptation): Das Basismodell bleibt eingefroren, und nur kleine Adapter-Matrizen werden trainiert (Quelle: Hu u. a., „LoRA“, Microsoft, 2021). QLoRA geht einen Schritt weiter und lädt das Basismodell in 4 Bit. Die Autoren haben damit ein Modell mit 65 Milliarden Parametern auf einer einzigen GPU mit 48 GB per Fine-Tuning angepasst (Quelle: Dettmers u. a., „QLoRA“, 2023).\n\n## Vier Wege, GPUs zu mieten\n\nGPU-Clouds bieten verschiedene Abrechnungsmodelle. Welches passt, hängt davon ab, wie planbar Ihre Last ist.\n\n![Vier Karten: GPUs auf Abruf, reserviert, als Spot und serverless, jeweils mit den bezahlten Stunden an einem Beispieltag, der Art der Abrechnung und dem passenden Einsatz](/images/learn/de/gpu-infrastructure-for-ai-rental.webp \"Vier Wege, GPU-Rechenleistung zu mieten, und die Lasten, zu denen sie passen.\")\n\n| Abrechnungsmodell | So zahlen Sie | Passt für | Achten Sie auf |\n|---|---|---|---|\n| Auf Abruf (On-Demand) | Pro Stunde oder Sekunde, solange die Maschine läuft | Experimente, Fine-Tuning-Läufe, unregelmäßige Jobs | Sie zahlen auch, wenn die GPU nichts tut |\n| Reserviert | Feste Zusage für einen Zeitraum, zu einem niedrigeren Satz | Stetige Last rund um die Uhr | Sie zahlen für Kapazität, die Sie nicht nutzen |\n| Spot / unterbrechbar | Freie Kapazität mit Rabatt | Batch-Jobs und Training mit Checkpoints | Der Anbieter kann die Maschine jederzeit stoppen |\n| Serverless | Pro Anfrage oder Sekunde Rechenzeit; skaliert auf null | Unregelmäßige Last, Demos, interne Tools | Kaltstarts: Ein großes Modell zu laden, dauert |\n\nEin **Checkpoint** speichert den Stand eines Trainingslaufs in regelmäßigen Abständen. So kann ein unterbrochener Job weiterlaufen, statt von vorn zu beginnen. Ohne Checkpoints ist Spot-Kapazität ein Glücksspiel.\n\nRunpod aus unserem [Vergleich der Infrastruktur-Tools](/de/ai-development/#area-infrastructure) ist eine GPU-Cloud dieser Art. Nach Angaben des Anbieters bietet sie GPUs auf Abruf und serverlose Rechenleistung, abgerechnet nach Nutzung:\n\n{{\u003c tool-shot \"runpod\" \u003e}}\n\n## Auslastung: die Zahl, die über Ihre Kosten entscheidet\n\nDie **Auslastung** ist der Anteil der bezahlten GPU-Zeit, der nützliche Arbeit leistet. Bei stundenweiser Abrechnung kostet eine untätige GPU so viel wie eine beschäftigte. Stellen Sie sich einen internen Assistenten vor, der auf einer GPU im Dauerbetrieb läuft, aber nur zu Bürozeiten Anfragen bekommt: Die meisten bezahlten Stunden bleiben ungenutzt.\n\n![Beispiel: drei 24-Stunden-Leisten für eine ständig laufende GPU, eine GPU nach Zeitplan mit Auto-Stopp und serverlose Rechenleistung, mit ausgelasteten, bezahlten, aber ungenutzten und nicht bezahlten Stunden](/images/learn/de/gpu-infrastructure-for-ai-utilization.webp \"Beispieltag eines internen Assistenten, der zu Bürozeiten genutzt wird: Das Abrechnungsmodell entscheidet, wie viele ungenutzte Stunden Sie bezahlen. Illustration, keine Messdaten.\")\n\nDrei Hebel erhöhen die Auslastung:\n\n- **Batching:** Die GPU verarbeitet mehrere Anfragen gleichzeitig. Der Durchsatz steigt, und jede einzelne Anfrage wartet etwas länger. Open-Source-Inferenzserver wie vLLM nehmen neue Anfragen fortlaufend in einen Batch auf, der gerade verarbeitet wird. Außerdem legen sie den KV-Cache in kleinen Blöcken ab, sodass mehr Anfragen in denselben Speicher passen (Quelle: Kwon u. a., „PagedAttention“, SOSP 2023).\n- **Passende Größe:** Ein 7B-Modell in 4 Bit braucht nicht die größte GPU. Wählen Sie die kleinste Karte, auf die das Modell mit Reserve passt.\n- **Zeitplanung:** Lassen Sie Batch-Jobs nachts auf denselben GPUs laufen, und stoppen Sie Maschinen außerhalb der Arbeitszeit.\n\nMessen Sie, was Sie für Ihr Geld bekommen: GPU-Auslastung und Speicherbelegung (zum Beispiel mit dem Tool `nvidia-smi`), Tokens pro Sekunde, Anfragen pro Stunde und Wartezeit in der Warteschlange. Die wichtigste betriebswirtschaftliche Zahl sind die Kosten pro Anfrage oder pro erfolgreich erledigter Aufgabe: die Kosten einer Stunde geteilt durch die Anfragen, die die GPU in dieser Stunde bedient hat. Vergleichen Sie diesen Wert jeden Monat mit den Kosten derselben Arbeit über eine API. Unser Artikel [So senken wir KI-Entwicklungskosten](/de/ai-development/reduce-ai-development-costs-without-compromising-results/) zeigt weitere Hebel.\n\n## Praxisbeispiel: ein nächtlicher Batch-Job auf einer gemieteten GPU\n\nEin Support-Team ordnet jedes neue Ticket nach Thema und Dringlichkeit ein. Heute schickt die App jedes Ticket an eine gehostete API. Inzwischen kommen Zehntausende Tickets pro Nacht, die Aufgabe ist eng umrissen, und niemand braucht das Ergebnis innerhalb von Sekunden. Damit ist sie ein guter Kandidat für eine gemietete GPU. Das Team prüft das in sechs Schritten:\n\n1. **Ausgangswert:** die Genauigkeit an 300 Tickets messen, die Menschen von Hand eingeordnet haben, dazu die Kosten pro 1.000 Tickets mit der bisherigen API.\n2. **Kandidatenmodell:** ein Modell mit offenen Gewichten und etwa 8 Milliarden Parametern, getestet mit demselben Prompt. Ist der Prompt allein nicht genau genug, folgt Fine-Tuning mit LoRA; Teil 4 dieses Levels vergleicht die Möglichkeiten.\n3. **Speicher:** 8 Milliarden × 1 Byte in 8 Bit ≈ 8 GB, plus etwa 20 Prozent ≈ 10 GB. Eine GPU mit 24 GB lässt Platz für Batching.\n4. **Abrechnungsmodell:** Der Job läuft einmal pro Nacht und kann beim letzten fertigen Ticket weitermachen. Spot-Kapazität oder GPUs auf Abruf mit Auto-Stopp passen beide; eine ständig laufende GPU passt nicht.\n5. **Messen:** Tickets pro Stunde auf der GPU. Kosten pro 1.000 Tickets = Kosten pro Stunde ÷ Tickets pro Stunde × 1.000.\n6. **Entscheiden:** Gewechselt wird nur, wenn die Genauigkeit bei den 300 Test-Tickets mindestens so gut ist wie vorher und die Kosten pro 1.000 Tickets deutlich niedriger liegen — einschließlich der Stunden, die das Team in den Betrieb steckt.\n\nDie Zahlen in diesem Beispiel dienen der Veranschaulichung; entscheiden müssen Ihre eigenen Messungen. Behalten Sie die API in den ersten Wochen als Rückfallebene, damit eine gescheiterte Nacht keine Tickets unbearbeitet lässt.\n\n## Checkliste zur Kostenkontrolle\n\nBevor Sie Ihre erste GPU mieten, richten Sie diese Kontrollen ein:\n\n1. **Budget und Warnungen** je Projekt, mit einem harten Limit, wo der Anbieter eines unterstützt.\n2. **Auto-Stopp** für untätige Maschinen und Entwicklungsumgebungen.\n3. **Labels** an jeder Ressource, damit Sie sehen, welches Projekt welche Kosten verursacht.\n4. **Speicher aufräumen:** Volumes und Snapshots kosten weiter Geld, auch wenn die GPU aus ist.\n5. **Checkpoints** für jeden Trainingslauf, der länger als eine Stunde dauert.\n6. **Quantisierung testen,** bevor Sie eine größere GPU wählen.\n7. **Trennung:** Website und Datenbank bleiben auf normalem Hosting, nur das Modell kommt auf GPUs.\n8. **Ein monatlicher Vergleich** der Kosten pro Aufgabe mit einer gehosteten API.\n\nPunkt 7 wird leicht übersehen. Die Web-App um ein Modell herum — Frontend, Benutzerkonten, Datenbank — läuft problemlos auf normalem Hosting, etwa auf einem Server, den Sie mit einem Kontrollpanel wie Plesk verwalten, oder auf einer Plattform wie Netlify. Nur der Inferenzdienst braucht die GPU, und der [Leitfaden zum Selbstbetrieb](/de/ai-development/learn/self-host-open-weight-models/) in Level 4 zeigt, wie Sie ihn im Produktivbetrieb führen.\n\n{{\u003c tools \"runpod plesk netlify\" \u003e}}","text":"Die meisten KI-Apps kommen nie mit einer GPU in Berührung. Sie rufen ein Modell über eine API auf, und der Anbieter betreibt die Hardware. Das ändert sich, wenn Sie ein Modell per Fine-Tuning anpassen, ein Modell mit offenen Gewichten selbst betreiben oder Millionen Dokumente in einem Durchlauf verarbeiten. Dann mieten Sie Rechenleistung — und die Rechnung hängt von Entscheidungen ab, die Sie treffen, bevor der erste Job startet.\nDies ist Teil 3 von Level 3 (Profi). Sie lernen, wann Sie wirklich GPUs brauchen, wie Sie den GPU-Speicher aus der Modellgröße abschätzen, welche Mietform zu welcher Last passt und wie Sie die Auslastung hoch und die Kosten im Griff halten. Wir erklären die Kostenlogik, keine Preise.\nWann Sie GPUs brauchen — und wann nicht Eine GPU (Graphics Processing Unit, also ein Grafikprozessor) hat Tausende kleiner Rechenkerne und sehr schnellen Speicher. Deshalb eignet sie sich für die Matrizenrechnungen in neuronalen Netzen. Der Speicher auf der Karte heißt VRAM, und er entscheidet, welche Modelle Sie ausführen können.\nEigene GPUs, gemietet oder gekauft, brauchen Sie in vier Situationen:\nFine-Tuning: Sie trainieren ein Modell mit offenen Gewichten auf Ihren eigenen Beispielen weiter. Manche Anbieter passen auch ausgewählte geschlossene Modelle als Dienst für Sie an; dann sind die GPUs deren Sache. Teil 4 dieses Levels hilft bei der Wahl zwischen Fine-Tuning, RAG und Prompting. Selbstbetrieb: Daten dürfen Ihre Infrastruktur nicht verlassen, oder Sie brauchen volle Kontrolle über die Modellversion. Batch-Jobs: Sie berechnen Embeddings für ein großes Archiv oder ordnen Millionen Datensätze ein, und die gleichmäßige Last hält die GPU beschäftigt. Training von Grund auf: außerhalb von Forschungslaboren und großen Unternehmen selten. Keine GPUs brauchen Sie, wenn Sie einen Prototyp bauen, wenn wenige oder unregelmäßige Anfragen kommen oder wenn das beste Modell für Ihre Aufgabe nur über eine API verfügbar ist. Eine gehostete API macht aus Fixkosten Kosten pro Anfrage, und um Updates, Skalierung und Ausfälle kümmert sich jemand anderes. Mit eigenen GPUs wandert diese Arbeit zu Ihrem Team: Treiber- und Sicherheitsupdates, Monitoring, Reserven für Lastspitzen und ein Plan für den Tag, an dem eine Maschine ausfällt.\nAPI oder eigene GPUs? Beginnen Sie mit der API, und wechseln Sie erst, wenn ein klarer Grund auftaucht. Modelle mit offenen Gewichten sind die üblichen Kandidaten für den Selbstbetrieb. Unsere LLM-Datenbank führt 172 Modelle mit offenen Gewichten, mit Erscheinungsdatum und Testergebnissen. Offene Gewichte bedeuten nicht immer freie Nutzung: Manche Lizenzen schränken die kommerzielle Nutzung ein oder stellen andere Bedingungen. Lesen Sie deshalb die Lizenz, bevor Sie auf einem Modell aufbauen.\nGPU-Speicher: eine Faustregel Die erste Frage lautet, ob das Modell in den GPU-Speicher passt. Für die Gewichte des Modells liefert eine einfache Formel eine gute Schätzung:\nSpeicher für die Gewichte (GB) ≈ Parameter (in Milliarden) × Bytes je Parameter\nJeder Parameter belegt in 16-Bit-Genauigkeit (FP16 oder BF16) 2 Bytes, in 8 Bit 1 Byte und in 4 Bit etwa ein halbes Byte. Gewichte mit weniger Bits zu speichern, heißt Quantisierung. Sie spart Speicher und beschleunigt oft die Inferenz, kann aber etwas Qualität kosten. Testen Sie sie deshalb an Ihrer eigenen Aufgabe.\nFür die Inferenz, also die Nutzung des Modells, reicht der Platz für die Gewichte nicht. Der KV-Cache speichert Zwischenergebnisse für den Text, den das Modell schon verarbeitet hat, damit es sie nicht für jedes neue Token neu berechnen muss. Er wächst mit der Kontextlänge und mit der Zahl der Anfragen, die parallel laufen. Für eine schnelle Prüfung empfiehlt EleutherAI, für die Inferenz etwa das 1,2-Fache des Speichers der Gewichte einzuplanen (Quelle: EleutherAI, „Transformer Math 101“, 2023, blog.eleuther.ai). Das genügt für kurze Prompts und wenige parallele Anfragen. Lange Kontexte und viele gleichzeitige Nutzer können deutlich mehr brauchen.\nGPU-Infrastruktur für KI: wann sich das Mieten lohnt Modellgröße 16 Bit 8 Bit 4 Bit Volles Fine-Tuning (~16 Bytes je Parameter) 7B ~14 GB ~7 GB ~3,5 GB ~112 GB 13B ~26 GB ~13 GB ~6,5 GB ~208 GB 34B ~68 GB ~34 GB ~17 GB ~544 GB 70B ~140 GB ~70 GB ~35 GB ~1.120 GB Die Tabelle zeigt grobe Näherungen, nur für die Gewichte; „B“ steht für Milliarden (englisch billion) Parameter. Viele verbreitete GPUs haben 24, 48 oder 80 GB Speicher, die neuesten Rechenzentrumsmodelle mehr. Das Diagramm schlägt die 20 Prozent für die Inferenz auf und zeigt, welche Kombinationen passen:\nUngefährer Speicherbedarf für die Inferenz: Gewichte plus etwa 20 Prozent. Werte aus der Faustregel, keine Messungen. “Ein 13B-Modell für Fragen zu internen Dokumenten dimensionieren\nGewichte in 8 Bit: 13 Milliarden × 1 Byte ≈ 13 GB. Dazu etwa 20 Prozent für KV-Cache und Overhead: rund 16 GB. Das passt auf eine GPU mit 24 GB, mit etwas Reserve für längere Kontexte. Es sind Näherungen — messen Sie mit Ihren echten Prompts und Ihrer echten Last, bevor Sie sich festlegen.\nTraining braucht weit mehr. Volles Fine-Tuning mit dem verbreiteten Adam-Optimierer in gemischter Genauigkeit (Mixed Precision) braucht etwa 16 Bytes je Parameter für Gewichte, Gradienten und Optimiererzustände (Quelle: Rajbhandari u. a., „ZeRO“, Microsoft, 2020). Dazu kommen die Aktivierungen, die Zwischenergebnisse jedes Trainingsschritts. Deshalb nutzen die meisten Teams LoRA (Low-Rank Adaptation): Das Basismodell bleibt eingefroren, und nur kleine Adapter-Matrizen werden trainiert (Quelle: Hu u. a., „LoRA“, Microsoft, 2021). QLoRA geht einen Schritt weiter und lädt das Basismodell in 4 Bit. Die Autoren haben damit ein Modell mit 65 Milliarden Parametern auf einer einzigen GPU mit 48 GB per Fine-Tuning angepasst (Quelle: Dettmers u. a., „QLoRA“, 2023).\nVier Wege, GPUs zu mieten GPU-Clouds bieten verschiedene Abrechnungsmodelle. Welches passt, hängt davon ab, wie planbar Ihre Last ist.\nVier Wege, GPU-Rechenleistung zu mieten, und die Lasten, zu denen sie passen. GPU-Infrastruktur für KI: wann sich das Mieten lohnt (2) Abrechnungsmodell So zahlen Sie Passt für Achten Sie auf Auf Abruf (On-Demand) Pro Stunde oder Sekunde, solange die Maschine läuft Experimente, Fine-Tuning-Läufe, unregelmäßige Jobs Sie zahlen auch, wenn die GPU nichts tut Reserviert Feste Zusage für einen Zeitraum, zu einem niedrigeren Satz Stetige Last rund um die Uhr Sie zahlen für Kapazität, die Sie nicht nutzen Spot / unterbrechbar Freie Kapazität mit Rabatt Batch-Jobs und Training mit Checkpoints Der Anbieter kann die Maschine jederzeit stoppen Serverless Pro Anfrage oder Sekunde Rechenzeit; skaliert auf null Unregelmäßige Last, Demos, interne Tools Kaltstarts: Ein großes Modell zu laden, dauert Ein Checkpoint speichert den Stand eines Trainingslaufs in regelmäßigen Abständen. So kann ein unterbrochener Job weiterlaufen, statt von vorn zu beginnen. Ohne Checkpoints ist Spot-Kapazität ein Glücksspiel.\nRunpod aus unserem Vergleich der Infrastruktur-Tools ist eine GPU-Cloud dieser Art. Nach Angaben des Anbieters bietet sie GPUs auf Abruf und serverlose Rechenleistung, abgerechnet nach Nutzung:\nRunpod: GPU-Cloud zum Trainieren und Betreiben von KI-Modellen, abgerechnet nach Nutzung. Bild: Quelle runpod.io. Runpod im Vergleich → Auslastung: die Zahl, die über Ihre Kosten entscheidet Die Auslastung ist der Anteil der bezahlten GPU-Zeit, der nützliche Arbeit leistet. Bei stundenweiser Abrechnung kostet eine untätige GPU so viel wie eine beschäftigte. Stellen Sie sich einen internen Assistenten vor, der auf einer GPU im Dauerbetrieb läuft, aber nur zu Bürozeiten Anfragen bekommt: Die meisten bezahlten Stunden bleiben ungenutzt.\nBeispieltag eines internen Assistenten, der zu Bürozeiten genutzt wird: Das Abrechnungsmodell entscheidet, wie viele ungenutzte Stunden Sie bezahlen. Illustration, keine Messdaten. Drei Hebel erhöhen die Auslastung:\nBatching: Die GPU verarbeitet mehrere Anfragen gleichzeitig. Der Durchsatz steigt, und jede einzelne Anfrage wartet etwas länger. Open-Source-Inferenzserver wie vLLM nehmen neue Anfragen fortlaufend in einen Batch auf, der gerade verarbeitet wird. Außerdem legen sie den KV-Cache in kleinen Blöcken ab, sodass mehr Anfragen in denselben Speicher passen (Quelle: Kwon u. a., „PagedAttention“, SOSP 2023). Passende Größe: Ein 7B-Modell in 4 Bit braucht nicht die größte GPU. Wählen Sie die kleinste Karte, auf die das Modell mit Reserve passt. Zeitplanung: Lassen Sie Batch-Jobs nachts auf denselben GPUs laufen, und stoppen Sie Maschinen außerhalb der Arbeitszeit. Messen Sie, was Sie für Ihr Geld bekommen: GPU-Auslastung und Speicherbelegung (zum Beispiel mit dem Tool nvidia-smi), Tokens pro Sekunde, Anfragen pro Stunde und Wartezeit in der Warteschlange. Die wichtigste betriebswirtschaftliche Zahl sind die Kosten pro Anfrage oder pro erfolgreich erledigter Aufgabe: die Kosten einer Stunde geteilt durch die Anfragen, die die GPU in dieser Stunde bedient hat. Vergleichen Sie diesen Wert jeden Monat mit den Kosten derselben Arbeit über eine API. Unser Artikel So senken wir KI-Entwicklungskosten zeigt weitere Hebel.\nPraxisbeispiel: ein nächtlicher Batch-Job auf einer gemieteten GPU Ein Support-Team ordnet jedes neue Ticket nach Thema und Dringlichkeit ein. Heute schickt die App jedes Ticket an eine gehostete API. Inzwischen kommen Zehntausende Tickets pro Nacht, die Aufgabe ist eng umrissen, und niemand braucht das Ergebnis innerhalb von Sekunden. Damit ist sie ein guter Kandidat für eine gemietete GPU. Das Team prüft das in sechs Schritten:\nAusgangswert: die Genauigkeit an 300 Tickets messen, die Menschen von Hand eingeordnet haben, dazu die Kosten pro 1.000 Tickets mit der bisherigen API. Kandidatenmodell: ein Modell mit offenen Gewichten und etwa 8 Milliarden Parametern, getestet mit demselben Prompt. Ist der Prompt allein nicht genau genug, folgt Fine-Tuning mit LoRA; Teil 4 dieses Levels vergleicht die Möglichkeiten. Speicher: 8 Milliarden × 1 Byte in 8 Bit ≈ 8 GB, plus etwa 20 Prozent ≈ 10 GB. Eine GPU mit 24 GB lässt Platz für Batching. Abrechnungsmodell: Der Job läuft einmal pro Nacht und kann beim letzten fertigen Ticket weitermachen. Spot-Kapazität oder GPUs auf Abruf mit Auto-Stopp passen beide; eine ständig laufende GPU passt nicht. Messen: Tickets pro Stunde auf der GPU. Kosten pro 1.000 Tickets = Kosten pro Stunde ÷ Tickets pro Stunde × 1.000. Entscheiden: Gewechselt wird nur, wenn die Genauigkeit bei den 300 Test-Tickets mindestens so gut ist wie vorher und die Kosten pro 1.000 Tickets deutlich niedriger liegen — einschließlich der Stunden, die das Team in den Betrieb steckt. Die Zahlen in diesem Beispiel dienen der Veranschaulichung; entscheiden müssen Ihre eigenen Messungen. Behalten Sie die API in den ersten Wochen als Rückfallebene, damit eine gescheiterte Nacht keine Tickets unbearbeitet lässt.\nCheckliste zur Kostenkontrolle Bevor Sie Ihre erste GPU mieten, richten Sie diese Kontrollen ein:\nBudget und Warnungen je Projekt, mit einem harten Limit, wo der Anbieter eines unterstützt. Auto-Stopp für untätige Maschinen und Entwicklungsumgebungen. Labels an jeder Ressource, damit Sie sehen, welches Projekt welche Kosten verursacht. Speicher aufräumen: Volumes und Snapshots kosten weiter Geld, auch wenn die GPU aus ist. Checkpoints für jeden Trainingslauf, der länger als eine Stunde dauert. Quantisierung testen, bevor Sie eine größere GPU wählen. Trennung: Website und Datenbank bleiben auf normalem Hosting, nur das Modell kommt auf GPUs. Ein monatlicher Vergleich der Kosten pro Aufgabe mit einer gehosteten API. Punkt 7 wird leicht übersehen. Die Web-App um ein Modell herum — Frontend, Benutzerkonten, Datenbank — läuft problemlos auf normalem Hosting, etwa auf einem Server, den Sie mit einem Kontrollpanel wie Plesk verwalten, oder auf einer Plattform wie Netlify. Nur der Inferenzdienst braucht die GPU, und der Leitfaden zum Selbstbetrieb in Level 4 zeigt, wie Sie ihn im Produktivbetrieb führen.\nRunpodInfrastruktur \u0026amp; Hosting · KI ist der KernGPU-Cloud zum Trainieren und Betreiben von KI-Modellen, abgerechnet nach Nutzung. PleskInfrastruktur \u0026amp; Hosting · Software mit KI-FunktionenHosting-Kontrollpanel für Websites, WordPress, E-Mail, DNS und Datenbanken. NetlifyInfrastruktur \u0026amp; Hosting · Software mit KI-FunktionenPlattform zum Bauen, Ausliefern und Hosten von Websites und Web-Apps. Kurzbeschreibungen aus unserem Tool-Vergleich, nach Angaben der Anbieter — nicht von ABXK getestet.\n","words":1839},"date":"2026-10-14","description":"Wann ein KI-Projekt eigene GPUs braucht, wie Sie den Speicher aus der Modellgröße schätzen und wann GPUs auf Abruf, reserviert, als Spot oder Serverless passen.","image":"https://abxk.ai/images/cover/gpu-infrastructure-for-ai.webp","json":"https://abxk.ai/de/ai-development/learn/gpu-infrastructure-for-ai/index.json","kind":"page","language":"de","learning_path":{"category":"ai-development","level":3,"level_name":"Profi"},"modified":"2026-10-14","related_tools":["Runpod","Plesk","Netlify"],"section":"ai-development","tags":["gpu","cloud-computing","selbstbetrieb","ki-infrastruktur"],"title":"GPU-Infrastruktur für KI: wann sich das Mieten lohnt","translations":[{"json":"https://abxk.ai/en/ai-development/learn/gpu-infrastructure-for-ai/index.json","language":"en","url":"https://abxk.ai/en/ai-development/learn/gpu-infrastructure-for-ai/"}],"url":"https://abxk.ai/de/ai-development/learn/gpu-infrastructure-for-ai/"}