Storage-Tiers im KI-Server: Modell, Datensatz, Scratch, Checkpoint

Es gibt ein Gespräch, das wir mit Käufern immer wieder über NVMe führen. Sie verlangen „so schnell wie möglich“, weil die Datenblätter bei einer Gen5-SSD 14 GB/s ausweisen und eine 4090 neben einer Samsung 9100 PRO nach einem passenden Gespann klingt. Dann fragen wir, wofür die Maschine gedacht ist, die Antwort lautet „überwiegend Inferenz“ – und der richtige Aufbau besteht am Ende aus einer einzigen SSD statt aus acht. Speicher ist in einem KI-Server der Teil der Spezifikation, bei dem sich besonders leicht zu viel kaufen lässt: schmerzfrei für den Anbieter und für den Workload praktisch unsichtbar.

Dieser Artikel behandelt die vier realen Speicherebenen in einem einzelnen KI-Server, welche Aufgabe jede davon tatsächlich hat, wie der NVMe-Markt 2026 aussieht, wann Gen5 seinen Aufpreis wert ist, warum Hardware-RAID für NVMe bedeutungslos geworden ist und wie Sie jede Ebene dimensionieren, ohne Geld zu verbrennen. Die Wahl des Dateisystems ist eine eigene Frage und wird in L04 behandelt; clusterweit geteilter Speicher (NFS, BeeGFS, Lustre, Objektspeicher) ist Thema von K04. Hier bleiben wir im Gehäuse.

Die vier Speicherebenen

Ein ernstzunehmender KI-Server hat vier klar getrennte Speicherrollen. Sie unterscheiden sich in Größe, Durchsatz, Lebensdauer und Kosten dramatisch. Sie in einen einzigen Pool zu werfen, ist der erste Fehler.

Ein Inferenzserver mit 4 GPUs braucht in der Regel nur die erste Ebene und vielleicht einen Bruchteil der zweiten. Eine Trainingsmaschine mit 8 GPUs braucht alle vier – und die vier verlangen unterschiedliche Laufwerke. Die Frage „wie viel TB NVMe?“ ist ohne Angabe der Ebene sinnlos.

Modellspeicher

Die Modellebene beherbergt Ihre Gewichtsbibliothek – jede Variante von Llama, Qwen, Mistral, Stable Diffusion, Flux und Whisper, die Sie jemals laden wollen. Hier liegen auch das Betriebssystem, Container-Images, Conda-Umgebungen und die Binaries des Inferenzservers. Bei den meisten Systemen fällt das alles auf das Boot-Laufwerk zusammen.

Die Dimensionierung hängt davon ab, wie viele Modelle Sie dauerhaft vorhalten. Einige Beispiele bei gängigen Quantisierungen:

• Llama 3 70B Q4: ~40 GB
• Llama 3 70B FP8: ~70 GB
• Qwen2.5-VL 72B Q4: ~45 GB plus einige GB für den Vision-Tower
• Mistral Large 2 (123B) Q4: ~70 GB
• Llama 4 Maverick MoE FP8: ~250 GB
• Eine überschaubare VLM-Bibliothek (8 Modelle, gemischte Quantisierungen): 300–500 GB
• Ein Forschungslabor, das 30 Modelle bereithält: 2–4 TB

Überwiegend lesend. Das Modell wird einmal beim Prozessstart geladen und bleibt den Rest des Tages im VRAM. Das Laufwerk sieht beim vLLM-Start einen sequenziellen Lesevorgang von 40 GB und liegt danach weitgehend still. Eine einzelne Gen4-NVMe mit 2–4 TB – selbst eine Consumer-SSD wie die Samsung 990 PRO – bewältigt das mühelos. Zahlen Sie für Kapazität, nicht für Durchsatz.

Datensatzspeicher

Auf der Datensatzebene liegen Trainingskorpora und Material für die Feinabstimmung. Diese Ebene unterdimensionieren Kunden chronisch, weil der Datensatz, mit dem sie heute arbeiten, noch passt – und weil sie vergessen, dass der nächste es nicht mehr tut.

Realistische Größenordnungen:

• Korpus für eine LoRA-Feinabstimmung in einer Domäne: 10–100 GB
• Multimodaler Feinabstimmungsdatensatz (Bilder + Text): 1–10 TB
• Textkorpus in Pretraining-Größe (FineWeb-Teilmenge o. Ä.): 5–50 TB
• Video-Pretraining oder Datensatz mit Robotik-Demonstrationen: 20–200 TB
• Genomisches, wissenschaftliches oder gescrapetes Web-Archiv: 100 TB – 1 PB+

Das Zugriffsmuster ist sequenzielles Lesen, über Epochen hinweg wiederholt und parallel über viele DataLoader-Worker. Durchsatzempfindlich (weil die GPU wartet), aber latenztolerant. Die Schreibrate ist praktisch null, sobald die Daten bereitgestellt sind.

Bei Datensätzen über rund 10 TB liegt die richtige Antwort meist außerhalb des Gehäuses – siehe K04 zu NFS, BeeGFS und Objektspeicher-Mustern. Im Gehäuse selbst ist eine Datensatzebene aus HDDs im RAIDZ2 (günstig, groß, langsam, aber ausreichend, sobald der Page-Cache warm ist) oder ein U.2-NVMe-RAID der Mittelklasse bis vielleicht 50 TB vertretbar.

Scratch

Scratch ist der unbesungene Held. Diese Ebene fängt alles auf, was sonst nirgends sauber hinpasst: dekodierte Bild-Shards, von ZeRO-Offload ausgelagerte Zwischenaktivierungen, Datensatz-Caches von webdataset/DALI, temporäre Datensatz-Shuffles, Artefakte aus Container-Builds und den Dump eines abgestürzten Laufs. Leselastig und schreiblastig zugleich.

Dimensionierung: 2–8 TB sind der Sweet Spot. Unter 2 TB füllt bereits eine einzelne Feinabstimmung die Ebene. Über 8 TB bauen Sie meist eine kleine Datensatzebene und nennen sie Scratch – auch gut, aber stehen Sie dazu.

Die Lebensdauer zählt hier auf eine Weise, wie sie es bei den anderen Ebenen nicht tut. Scratch frisst Schreibvorgänge – 5–20 TB pro Tag sind auf einer stark genutzten Trainingsmaschine nichts Ungewöhnliches. Ein Enterprise-Laufwerk mit 1 DWPD und 4 TB erlaubt fünf Jahre lang 4 TB Schreibvolumen pro Tag; ein ernsthaftes Trainings-Scratch will 1–3 DWPD in Mixed-Use-Qualität.

Checkpoint

Auf der Checkpoint-Ebene landet der Trainingszustand. Stoßweise: zehn Minuten Stille, dann 50–500 GB in wenigen Sekunden geschrieben, dann wieder Stille.

Ein Checkpoint eines 70B-Modells in FP16 umfasst rund 140 GB an Gewichten. Mit FSDP treiben Gradienten und Optimizer-State den Umfang je Checkpoint auf 400–700 GB. Mit DeepSpeed ZeRO-3 und vollständigem Optimizer-State (Adam: 8 Byte je Parameter für den FP32-Master plus erstes und zweites Moment) kann ein 70B-Checkpoint nahe an 1 TB herankommen.

Die dauerhafte Schreibrate einer einzelnen Gen5-NVMe liegt bei rund 10–13 GB/s. Ein Checkpoint von 700 GB ist damit optimistisch in etwa einer Minute geschrieben – sofern jeder Rank auf ein eigenes Laufwerk streamt. Synchron blockiert das Training genau diese Minute. Die Lösung ist asynchrones, geshardetes Checkpointing (siehe unten).

NVMe Gen4 vs. Gen5 – wann sich der Aufpreis lohnt

Der NVMe-Markt 2026 teilt sich in ausgereiftes Gen4 (5–7 GB/s) und inzwischen breit verfügbares Gen5 (12–14 GB/s). An der Spitze des Consumer-Segments steht die Samsung 9100 PRO mit 14.8 GB/s sequenziellem Lesen und 13.4 GB/s sequenziellem Schreiben. Enterprise-Gen5 bewegt sich in derselben Liga – Solidigm D7-PS1010 mit 14.5 GB/s Lesen, Micron 9550 MAX mit 14 GB/s Lesen, Kioxia CD8, SanDisk DC SN861 – alle liefern 13–14 GB/s Lesen und 8–10 GB/s dauerhaftes Schreiben.

Der Aufpreis für Gen5 gegenüber Gen4 bei vergleichbarer Kapazität liegt Mitte 2026 im Consumer-Segment bei 30–50 % und im Enterprise-Segment bei 20–35 %.

Wann sich Gen5 tatsächlich rechnet:

• Modelle aus dem Kaltstart laden. Ein MoE-Modell mit 250 GB lädt auf Gen5 in 18 Sekunden, auf Gen4 in 36 Sekunden. Relevant, wenn Sie häufig Modelle wechseln.
• I/O-gebundenes Training. Vision-Pipelines, die rohe JPEGs von der Platte dekodieren, oder multimodale Datensätze, bei denen die Vorverarbeitung den Engpass bildet.
• Checkpoint auf lokale NVMe vor der asynchronen Kopie. Je schneller der lokale Schreibvorgang, desto früher läuft das Training weiter.
• Cluster-Speicherserver für 8+ Trainingsknoten. Die aggregierte Nachfrage der Clients übersteigt die Gen4-Obergrenze.

Wann Gen4 genügt und Gen5 rausgeworfenes Geld ist:

• Inferenzserver. Das Modell wird einmal beim Start geladen; den Rest des Tages liegt das Laufwerk im einstelligen MB/s-Bereich.
• OS-Root und Container-Ablage. Einmal im Monat booten, gelegentlich Pakete installieren.
• Datensatzebene mit vordekodierten, großen Shards. Ein PyTorch-DataLoader mit 8 Workern, der WebDataset-Shards liest, sättigt vielleicht 4–6 GB/s aggregiert; Gen4 deckt das ab.

Die ehrliche Fassung: Rund 70 % der Systeme, die wir ausliefern, sind reine Inferenzmaschinen – und dort ist Gen4-NVMe durchgängig die richtige Wahl. Gen5 ist eine Entscheidung auf der Trainingsebene.

Bauformen – M.2, U.2/U.3, E3.S

M.2 Gen5 wird drosseln. Eine Samsung 9100 PRO mit 2 TB erreicht im heißen Gehäuse bei dauerhaften 13 GB/s schnell 75 °C und taktet zurück. Modelle mit Kühlkörper helfen. M.2 eignet sich für Boot und moderate Lasten; für eine Scratch-Ebene mit dauerhaften Schreibvorgängen ist es die falsche Bauform.

U.2 ist das Arbeitspferd. Jedes Enterprise-NVMe-Laufwerk, das Kentino in einem Bone64c- oder Supermicro-Gehäuse ausliefert, ist U.2 und praktisch durchgängig mit U.3-Backplanes austauschbar. 25 W thermisches Budget, Dual-Port für Multipath, Hot-Swap-fähig – und 7.68 TB sowie 15.36 TB liegen im Sweet Spot aus Preis und Dichte.

E3.S ist die Zukunft – langsam. Von Grund auf für Gen5-/Gen6-Thermik entwickelt. Für einen einzelnen Server oder einen kleinen Kentino-Cluster bleibt U.2/U.3 bis ins Jahr 2026 die praktische Wahl; E3.S wird für Refresh-Zyklen ab 2027 interessant.

Stapeln Sie keine M.2-Adapterkarten in einem heißen Gehäuse. PCIe-Adapterkarten, die vier M.2-Laufwerke hinter einem Switch-Chip aufnehmen, funktionieren – aber in einem 4U-Server mit acht GPUs ist der Luftstrom über diesen Karten schlecht. Wir sehen thermisches Throttling binnen zehn Minuten unter Dauerlast. Wenn Sie vier NVMe im Server brauchen, nehmen Sie U.2.

Lebensdauer – DWPD als Kaufsignal

Für einen KI-Server ist die Zuordnung eindeutig:

• Modellebene: leseintensiv, 0.3–1 DWPD.
• Datensatzebene: leseintensiv, 0.3–1 DWPD.
• Scratch-Ebene: Mixed-Use, 1–3 DWPD. Das ist die Ebene, die ihr Lebensdauerbudget wirklich verdient.
• Checkpoint-Ebene: Mixed-Use, 1–3 DWPD. Stoßweise Schreibvorgänge summieren sich; 1 DWPD auf einem 4-TB-Laufwerk erlaubt nur 4 TB pro Tag – und das überschreitet eine intensive Trainingskadenz.

Schreibintensiv (3+ DWPD) ist für nahezu jeden KI-Workload überdimensioniert. Die falsche Lebensdauerklasse lässt sich durch Austausch korrigieren; die falsche Durchsatzklasse oft nicht. Treffen Sie die Durchsatzentscheidung beim Bau richtig und behandeln Sie die Lebensdauer als etwas, das Sie nachrüsten können.

RAID für NVMe – Hardware ist tot, Software ist die Antwort

Das verdient einen eigenen Abschnitt, weil Kunden immer noch danach fragen. Die Kurzfassung: Wenn in Ihrem System 2026 ein Hardware-RAID-Controller vor NVMe-Laufwerken sitzt, ist es falsch konfiguriert.

Hardware-RAID-Controller (LSI/Broadcom MegaRAID, Microchip SmartRAID, HPE Smart Array, Dell PERC) wurden für SAS/SATA entwickelt. Der ASIC auf dem Controller übernimmt Parität, Caching und Command Queuing – und bei SAS-Bandbreite (12 Gbit/s = 1.5 GB/s) hat er reichlich Luft.

NVMe Gen5 mit 14 GB/s pro Laufwerk sättigt einen Einzelkarten-RAID-Controller bereits nach zwei Laufwerken. Acht Laufwerke hinter einer Hardware-RAID-Karte erzeugen mehr Bandbreite, als der PCIe-Uplink der Karte transportieren kann. Der Controller wird zum Engpass – und anschließend zum Ausfallpunkt.

Die praktikablen Antworten sind Software:

• mdadm (Linux-Software-RAID). Ausgereift, im Kernel, unterstützt RAID0/1/10 gut. RAID5/6 auf NVMe funktioniert, aber die Paritätsberechnung frisst CPU. Für 4 NVMe im Mirror oder Stripe: perfekt.
• ZFS RAIDZ2. Bessere Datenintegrität (Ende-zu-Ende-Prüfsummen), besseres Werkzeug für Scrubs und Austausch, Snapshot- und Clone-Semantik. CPU-hungriger als mdadm. Die richtige Wahl für Archiv- und Datensatzebenen, bei denen Datenintegrität wichtiger ist als maximaler Durchsatz.
• Replikation je Laufwerk / Erasure Coding auf Anwendungsebene. Bei sehr großen Arrays verlagern MinIO/Ceph EC oder BeeGFS-Striping die Redundanzentscheidung vollständig aus der Blockebene heraus.

Für die meisten Kentino-Systeme gilt:

• Boot: 2× M.2 NVMe im mdadm-RAID1.
• Scratch: RAID0 über 2–4 NVMe (die Daten lassen sich neu erzeugen).
• Datensatz/Checkpoint: RAID10 mit mdadm oder RAIDZ2 mit ZFS.

Hardware-RAID hat in einem KI-Server genau einen verbliebenen Anwendungsfall: einen kleinen Boot-Mirror hinter einer einfachen Broadcom-/MegaRAID-Karte auf einem Server, bei dem Sie unbedingt bootfähige Redundanz vor dem Betriebssystem wollen. Selbst dort funktioniert mdadm-RAID1 mit EFI auf beiden Laufwerken einwandfrei.

Netzwerkspeicher für die Datensatzebene

Die Quintessenz: Oberhalb von 10 TB gehört die Datensatzebene fast immer außerhalb des KI-Servers. Im Gehäuse wollen Sie schnelles Scratch, schnelle Checkpoints und einen Modellspeicher; der Datensatz darf entfernt liegen.

Wie PyTorch Daten tatsächlich lädt

Ein nützliches Modell für die Speicherdimensionierung ist, nachzuvollziehen, was der DataLoader von PyTorch tut. Mit num_workers=8 und pin_memory=True:

1. Acht Worker-Prozesse öffnen Datensatzdateien parallel.
2. Jeder Worker liest, dekodiert (JPEG, Videoframes, Audio-Resampling) und tensorisiert ein Sample.
3. Der dekodierte Tensor wird im Shared Memory abgelegt.
4. Der Hauptprozess holt aus der gemeinsamen Queue, pinnt in den Host-RAM und kopiert per DMA auf die GPU.

Die praktischen Folgen:

• Eine Vision-Pipeline ist selten speichergebunden – es sei denn, der Datensatz ist so groß, dass der Page-Cache das Working Set nicht halten kann.
• Eine LLM-Pretraining-Pipeline, die vortokenisierte Shards liest, ist auf Gen4 häufig speichergebunden. Gen5 hilft. Ebenso hilft es, den aktiven Shard-Satz auf lokale NVMe statt auf NFS zu legen.
• Inferenz ist praktisch nie speichergebunden – jedenfalls nach dem Laden des Modells. Die Festplattenaktivität einer Serving-Maschine ist eine flache Linie.

Die Checkpoint-Klippe

Ein Checkpoint eines 70B-Modells in FP16 umfasst 140 GB an Gewichten. Dazu kommt der Adam-Optimizer-State (~8 Byte je Parameter für FP32-Master plus erstes plus zweites Moment): rund 560 GB mehr. Dazu Gradienten, falls Sie mitten im Schritt einen Snapshot ziehen: weitere rund 140 GB. Ein „vollständiger“ 70B-Checkpoint kann je nach Umfang 800 GB bis 1 TB erreichen.

Synchron, mit einem einzigen Rank, der alles schreibt, auf eine einzelne Gen5-NVMe mit dauerhaft 13 GB/s Schreibrate: rund 75 Sekunden für einen Checkpoint von 1 TB. Das Training blockiert die gesamte Zeit. Wer das alle 100 Schritte tut und je Schritt 5 Sekunden braucht, hat den Trainingslauf gerade um 15 % verlangsamt.

Zwei Abhilfen, beide unverzichtbar:

1. Geshardetes Checkpointing. Jeder FSDP-Rank schreibt seinen eigenen Shard auf sein eigenes lokales Laufwerk. Bei 8 GPUs und 8 lokalen Laufwerken beträgt das Schreibvolumen je Rank 125 GB, und die Schreibvorgänge laufen parallel. Die Wanduhrzeit sinkt auf rund 10 Sekunden.

2. Asynchrones Checkpointing. PyTorch DCP (torch.distributed.checkpoint) lagert den Schreibvorgang in einen CPU-Thread aus. Die GPU stockt kurz für die Staging-Kopie von GPU zu CPU (wenige Sekunden), dann läuft das Training weiter und der eigentliche Schreibvorgang auf den Speicher passiert im Hintergrund.

Die Kombination – asynchron und geshardet – verwandelt den Checkpoint-Speicher von „muss 1 TB in Sekunden aufnehmen“ in „muss eine gleichmäßige Hintergrundkopie von einigen hundert MB/s mithalten“. Das schafft praktisch jede Speicherebene. Der Fehler, den Sie vermeiden sollten: synchrone Checkpoints mit vollem Zustand je Rank, direkt auf NFS geschrieben. 2022 war das normal. 2026 ist es ein Kunstfehler.

Konkrete Speicherlayouts für Kentino AI

Inferenzserver mit 4 GPUs (z. B. Kentino AI 192 Genoa, 4× RTX 5090 oder 4× RTX Pro 6000 Blackwell):

Boot + Modell:   1× 2 TB Gen5 M.2 NVMe (Consumer oder leseintensiv Enterprise)\nScratch:         optional, für reine Inferenz oft entbehrlich\nDatensatz:       auf der Maschine nicht nötig\nCheckpoint:      auf der Maschine nicht nötig\n\nGesamt: 2 TB NVMe. Kosten: niedrig. Für jeden Inferenz-Workload ausreichend.

Trainingsserver mit 8 GPUs (z. B. Kentino AI 256 Turin Dual, 8× RTX 5090 oder 8× RTX Pro 6000):

Boot:            2× 480 GB M.2 NVMe, mdadm RAID1, ext4 → /\nModellspeicher:  2× 4 TB U.2 Gen5 NVMe, mdadm RAID1, ext4 → /models\nScratch:         2× 8 TB U.2 Gen5 NVMe, mdadm RAID0, XFS → /scratch\nCheckpoint:      2× 8 TB U.2 Gen5 NVMe, mdadm RAID10, XFS → /checkpoints\nDatensatz:       NFS-Mount von externem Speicherserver, 100 GbE\n\nLokale NVMe gesamt: ~36 TB. Kosten: spürbar, aber im Verhältnis zur GPU-Investition stimmig.

Gemeinsamer Speicherknoten für den Cluster (getrennt vom Compute):

Boot:            2× 960 GB M.2 NVMe, RAID1, ext4\nHot-Tier:        12× 7.68 TB U.2 Gen5 NVMe, ZFS RAIDZ2 oder BeeGFS-Storage-Target, XFS\nCold-Tier:       8× 16 TB SAS HDD, ZFS RAIDZ2 → /archive\nNetzwerk:        2× 100 GbE, RoCE- oder NVMe-oF-fähig\n\nBedient die Datensatzebene des Clusters. Zur Wahl des verteilten Dateisystems siehe K04.

Zwei Dinge verdienen Beachtung. Der Inferenzserver hat ein einziges Laufwerk. Der Trainingsserver hat vier Ebenen, aber jedes Laufwerk ist auf seine Rolle dimensioniert und nicht auf das größte verfügbare überzogen. Der Cluster-Speicherknoten ist eine vollständig eigene Maschine.

Ehrliche Einschätzung – die meisten Kunden überdimensionieren den Speicher

Ein Muster, das wir oft genug sehen, um es anzusprechen: Ein Kunde baut einen Server mit 8 GPUs, „um zukunftssicher zu sein“, spezifiziert acht U.2-NVMe mit je 15.36 TB, weil die Einschübe nun einmal da sind, und fährt dann Inferenz-Workloads, die vielleicht 200 GB an Modelldateien berühren – während der Rest des Arrays für immer brachliegt. 25,000 € NVMe, die kalt bleiben.

Die ehrlichen Dimensionierungsregeln:

• Reine Inferenz, ein einzelner Server: 2–4 TB NVMe gesamt. Ein Laufwerk. Fertig.
• Inferenz plus gelegentliche Feinabstimmung: 4–8 TB gesamt. Boot + Scratch.
• Ernsthaftes Training, ein einzelner Server: 16–40 TB über Boot, Modell, Scratch und Checkpoint verteilt, mit dem Datensatz extern auf einem NAS oder Objektspeicher.
• Cluster: Datensatz und Checkpoint wandern in den gemeinsamen Speicher; die lokale NVMe je Knoten schrumpft zurück auf das Inferenzprofil (2–8 TB) für Boot, Modell und Write-Back-Scratch.

Speicher ist der einzige Bereich eines KI-Aufbaus, in dem der Reflex „mehr ist immer besser“ durchgängig falsch ist. Der Nutzen von GPUs skaliert grob linear mit den Kosten; RAM skaliert ordentlich; Speicher skaliert oft gar nicht mehr, sobald Sie genug davon haben.

Was schiefgeht

Die Fehlerbilder, die uns im Feld begegnen, der Reihe nach:

• Das Boot-Laufwerk ist eine Consumer-M.2 ohne Redundanz. Das Laufwerk fällt nach 18 Monaten aus, der Server bootet nicht mehr, die Modelle liegen sicher im RAID – aber der Wiederaufbau kostet einen Tag. Abhilfe: 2× M.2 im mdadm-RAID1, auch auf Inferenzmaschinen.
• Scratch läuft mitten im Lauf voll. Datensatz-Cache, dekodierte Shards und temporäre Framework-Dateien wirken zusammen. Abhilfe: überwachen, Alarm bei 80 % Füllstand, auf das 1.5-Fache des größten erwarteten Working Sets auslegen.
• Hardware-RAID-Karte vor NVMe. Die Leistung ist halb so hoch wie möglich, der Controller ist ein Single Point of Failure und der Ersatz exotisch. Abhilfe: Karte ausbauen, mdadm oder ZFS direkt.
• Synchroner Checkpoint auf NFS, das Training steht. Abhilfe: asynchroner, geshardeter Checkpoint, erst auf lokale NVMe, dann asynchron kopieren.
• Thermisches Throttling bei Gen5-M.2. Ein mit 14 GB/s angegebenes Laufwerk liefert nach 3 Minuten dauerhaften Schreibens noch 4 GB/s. Abhilfe: Kühlkörper, besserer Luftstrom oder Wechsel auf U.2.
• Der Datensatz auf der Datensatzebene sättigt Gen4. Die Vision-Trainings-Pipeline ist zu 30 % speichergebunden. Abhilfe: Gen5-Scratch, Vordekodierung nach WebDataset – oder beides.
• Der ZFS-ARC frisst RAM, der für das Training gedacht war. Die Standardzuweisung von 50 % treibt den Trainingsprozess in den OOM. Abhilfe: zfs_arc_max auf 10–20 % des RAM begrenzen. Siehe L04.

---

Dieser Beitrag ist Teil des Kentino Wiki, einer Referenzreihe zu KI-Compute, Robotik und den Systemen, die beides verbinden. Anmerkungen und Korrekturen gern an info@kentino.com.