|
GPU-VRAM
|
≥ 24 GB (gemma4-Peak noch nicht
vermessen)
|
≥ 24 GB; mehr bei parallelen Jobs
oder Presets
|
Naming-Modell ist in allen Presets
gemma4 (~16 GB Gewichte); realer Peak noch nicht vermessen,
bis dahin ≥ 24 GB ansetzen. Die alten Werte (10–12 GB,
visual_3d 9–11 GB, norm_exact 8–10 GB) gelten nur für
Opt-in-Images mit gemma3. Token-freie Variante eva02: 6–8
GB; eva02 läuft vor dem Naming, aber sequenziell – Peak =
max(eva02, gemma4).
|
|
CPU-Kerne
|
4 Kerne
|
8 Kerne und mehr
|
Prefetch-Worker = min(6, Kerne −
2); überschreibbar über RUNPOD_PREFETCH_WORKERS, 0 =
serieller Betrieb. Die Worker rendern auch die
Contact-Sheets für das Naming (~15 s je Blatt) und wirken
damit auf beide Phasen.
|
|
Arbeitsspeicher
|
≥ 16 GB
|
≥ 16 GB Basis plus ~1 GB je
Prefetch-Worker
|
Je Worker höchstens ein Mesh im
Speicher: sechs Worker mit 100-MB-STL ≈ 22 GB, zuzüglich
~0,5 GB je Worker für das
Contact-Sheet-Rendering.
|
|
Festplatte
|
≥ 70 GB frei
|
≥ 70 GB frei für Image und Laden
des Tarballs
|
Image ~28 GB (Modellgewichte ~22
GB, davon gemma4 ~16 GB); das Laden des Tarballs benötigt
temporär etwa das Doppelte.
|
|
Share
|
5 x Größe des Kataloges auf der
Festplatte
|
5 x Größe des Kataloges auf der
Festplatte
|
Macht die Daten für beide
beteiligten Server zugänglich.
|
|
Netzwerk
|
kein Internetzugang
erforderlich
|
keine dauerhafte
Verbindung
|
Sämtliche Modelle sind im Docker
enthalten
|
