Wie viel Speicherplatz benötigt Immich für Vorschaubilder und maschinelles Lernen bei der Sicherung von Familienfotos?

Immich verfügt über kein verlässliches Speicherverhältnis ausschließlich für Vorschaubilder. Daher sollten Familienbibliotheken die generierten Bytes pro Asset messen und separaten Speicherplatz für ML-Modelle einplanen.

Ein 2-TB-Fotoarchiv einer Familie sagt nicht aus, wie groß das Immich-Verzeichnis für Vorschaubilder werden wird, da die Anzahl der Assets, die Quellauflösung, die Einstellungen für Vorschaubilder, der Videoanteil und die aktivierten Modelle den daraus entstehenden Speicherbedarf beeinflussen. Die sicherere Methode zur Größenplanung besteht darin, eine repräsentative Stichprobe zu verarbeiten, Vorschaubilder und Modell-Cache getrennt zu messen, das Bibliothekswachstum zu prognostizieren und anschließend zusätzlichen Betriebsspielraum einzuplanen, statt einen Prozentsatz als universell gültigen Bedarf zu betrachten.

Originale und von Immich erzeugten Speicher getrennt betrachten

Beginnen Sie mit einer klaren Abgrenzung: Originalfotos und -videos sind nur ein Teil des Speicherbedarfs, der eine Immich-Bibliothek unterstützt. Der Server speichert außerdem generierte Assets für die Anzeige und Kompatibilität, während der Machine-Learning-Dienst heruntergeladene Modelldateien in einem eigenen Cache ablegt. Diese Kategorien wachsen aus unterschiedlichen Gründen. Wenn man sie zu einem vagen Prozentsatz zusammenfasst, wird es schwierig zu erkennen, welche Einstellung oder welcher Arbeitsvorgang tatsächlich Speicherplatz verbraucht.

Eine langjährige Referenz zur Größenplanung aus der Immich-Community weist darauf hin, dass Vorschaubilder und transkodierte Videos zusammen durchschnittlich etwa 10–20 % zusätzlich belegen können. Diese Zahl dient nur als grober Anhaltspunkt: Sie fasst zwei generierte Kategorien zusammen und darf daher nicht als reines Verhältnis für Vorschaubilder dargestellt werden. Eine familienorientierte Bibliothek mit wenigen Videos kann deutlich anders ausfallen als ein videointensives Archiv.

Auch die Architektur spielt eine Rolle bei der Entscheidung, wo dieser zusätzliche Speicherplatz untergebracht werden soll. ZimaSpaces Betrachtung der KI-gestützten Fotoorganisation behandelt Indizierung und generierte Daten als Dienste rund um die ursprüngliche Bibliothek, nicht als deren Ersatz. Für die Kapazitätsplanung sollten Originale, Vorschaubilder/Preview-Daten, Video-Derivate, Datenbank und ML-Cache als separate Positionen geführt werden, auch wenn sie sich eine physische Festplatte teilen.

Vorschaubildkosten pro Asset messen, bevor Sie skalieren

Wählen Sie einen repräsentativen Ausschnitt der Familienbibliothek statt der einfachsten tausend Dateien. Er sollte die verschiedenen Smartphone-Generationen, Kameraauflösungen, Porträts, Screenshots, Panoramen und andere Bildtypen enthalten, die bei der normalen Nutzung vorkommen. Lassen Sie die Aufgaben für Vorschaubilder vollständig abschließen, notieren Sie die Anzahl der verarbeiteten Assets und messen Sie das Vorschaubildverzeichnis. Wenn Sie die gemessenen Bytes durch die Anzahl der verarbeiteten Assets teilen, erhalten Sie ein lokales Planungsverhältnis, das Ihre gewählten Einstellungen für Vorschaubilder und Previews bereits berücksichtigt.

Reale Installationen zeigen, warum dieses lokale Verhältnis wichtig ist. In einer Immich-Diskussion wurden 21 GB an Vorschaubildern neben 58 GB an codierten Videos in einem bestimmten System gemeldet. Diese Zahl ist anekdotisch und kein Zielwert, zeigt aber, dass generierte Verzeichnisse deutlich unterschiedliche Größen haben können und unabhängig gemessen werden sollten, statt sie allein aus den Terabytes der ursprünglichen Bibliothek abzuleiten.

Wenn beispielsweise 10.000 repräsentative Bilder 12 GB an Vorschaubildern und Previews erzeugen, beträgt Ihre beobachtete Rate etwa 1,2 MB pro Asset. Eine prognostizierte Bibliothek mit 60.000 Bildern würde bei denselben Einstellungen somit vor zusätzlichem Wachstumsspielraum ungefähr 72 GB erfordern. Wiederholen Sie die Stichprobe, wenn Sie die Auflösung oder Qualität der Vorschaubilder ändern, da diese Änderungen das alte Verhältnis pro Asset ungültig machen, obwohl sich die Originaldateien nicht verändert haben.

Der ML-Modell-Cache hängt stärker von den Modellen als von der Anzahl der Fotos ab

Der Speicherbedarf für Machine Learning verhält sich anders als der für Vorschaubilder. Der Modell-Cache enthält hauptsächlich Modelldateien, die der ML-Dienst herunterlädt und wiederverwendet. Sein Speicherbedarf hängt daher stärker davon ab, welche Modelle für die intelligente Suche und Gesichtserkennung ausgewählt wurden, als davon, ob die Bibliothek 20.000 oder 200.000 Fotos enthält. Die Bibliotheksgröße beeinflusst zwar den Verarbeitungsaufwand, erfordert aber keine neue Modellkopie für jedes Asset.

Eine aktuelle selbst gehostete Immich-Bereitstellung beschreibt einen persistenten Modell-Cache, der für den Machine-Learning-Dienst eingebunden wurde, und berichtet, dass die dort verwendeten Modelle insgesamt weniger als 1 GB belegten. Das gilt für diese Konfiguration und ist keine Garantie. Entscheidend sind die Persistenz und Wiederverwendung: Sobald die ausgewählten Dateien vorhanden sind, vervielfacht das normale Wachstum der Fotoanzahl die Modelldateien nicht.

Für einen Familienserver, auf dem später möglicherweise andere Modelle verwendet werden, ist ein größerer Planungswert sinnvoller als der kleinste aktuell beobachtete Cache. Ein Immich-Maintainer hat angedeutet, dass im Allgemeinen etwa 10 GB Speicherplatz ausreichen, abhängig von der Modellauswahl. Betrachten Sie dies als konservative anfängliche Reserve und ersetzen Sie sie nach Abschluss der ersten ML-Aufgaben durch die tatsächliche Cache-Größe Ihrer laufenden Konfiguration.

-15% OFF

ZimaBoard 2 – Mini-Heimserver für Ihre große Idee

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Videoanteil und Client-Caches können eine reine Fotoschätzung verfälschen

Die Schätzung für Vorschaubilder und ML ist keine sinnvolle Beschreibung des gesamten Speicherbedarfs mehr, wenn die Bibliothek viele Videos enthält oder wenn Sie den lokal auf dem Gerät belegten App-Speicher betrachten. Die Videokompatibilität kann große serverseitige Derivate erzeugen, während Caches auf Smartphones und in Browsern lokalen Client-Speicher belegen, der nicht zum Vorschaubildverzeichnis oder ML-Modell-Cache des Servers gehört. Wenn man diese Werte vermischt, kann eine normale Schätzung für Vorschaubilder völlig falsch erscheinen.

Ein Nutzerbericht zu einer großen Bibliothek verdeutlicht diese Abgrenzung: Bei einer etwa 2,4 TB großen Bibliothek mit 179.000 Fotos und 19.000 Videos wurden 822 GB an serverseitigen Derivaten für Vorschaubilder und transkodierte Videos gemeldet, während die Android-App lokal ebenfalls mehrere Dutzend Gigabyte ansammelte. Das ist eine anekdotische Angabe und keine Planungsregel, zeigt aber, wie Video und Client-Caching ein einfaches Modell für reine Fotos dominieren können.

Halten Sie die Kategorien bei der Messung getrennt: serverseitige Vorschaubild-/Preview-Daten, codierte Videos, ML-Modell-Cache, Datenbank und lokaler Client-Cache. Wenn der Speicher für Vorschaubilder unerwartet groß erscheint, prüfen Sie direkt das Vorschaubildverzeichnis und nicht den gesamten Immich-Datenbaum. Wenn codierte Videos das größte Verzeichnis bilden, hat sich die relevante Planungsfrage von den Indexierungsdaten für Fotos hin zu Videokompatibilität und Transkodierungsrichtlinien verschoben.

Eine Formel auf Basis von Stichprobe und Wachstum für Familienspeicher verwenden

Verwenden Sie drei Eingaben: die gemessenen Vorschaubild-Bytes pro repräsentativem Asset, die für die nächsten ein bis zwei Jahre prognostizierte Bildanzahl und die gemessene Größe des ML-Modell-Caches. Multiplizieren Sie die ersten beiden Werte, addieren Sie den Modell-Cache und anschließend einen betrieblichen Puffer für erneute Generierung, Einstellungsänderungen und normales Wachstum des Dateisystems. Ein Puffer von 20–25 % ist hier eine Planungsheuristik und keine Immich-Anforderung. Bei knappem Speicherplatz sollten Sie häufiger messen, statt davon auszugehen, dass dieser Puffer immer ausreicht.

Eine konservative Obergrenze für den Modell-Cache kann bei der Empfehlung des Maintainers beginnen, dass etwa 10 GB abhängig von der Modellauswahl im Allgemeinen ausreichen sollten. Kombinieren Sie diesen Wert mit Ihrer eigenen Messung für Vorschaubilder und nicht mit dem Verhältnis von 10–20 % für Vorschaubilder plus Transkodierungen. Bei einer prognostizierten Größe von 72 GB für Vorschaubilder, einer Modellreserve von 10 GB und einem Puffer von 25 % ergäbe sich eine Planungsreserve von etwa 103 GB.

Berechnen Sie neu, sobald sich eine Variable ändert, die die Schätzung beeinflusst: Auflösung oder Qualität der Vorschaubilder, ein deutlicher Wechsel der Kameraauflösung, ein anderes ML-Modell, starkes Videowachstum oder ein erheblicher Anstieg der Anzahl der Familienmitglieder, die Assets hochladen. Die Entscheidungsschwelle ist einfach: Wenn der prognostizierte Speicherbedarf für generierte Daten einschließlich Puffer sich dem verfügbaren freien Speicherplatz auf dem vorgesehenen schnellen Volume nähert, verschieben Sie den Pfad für Derivate, erweitern Sie die Kapazität oder reduzieren Sie die relevanten Einstellungen zur Datengenerierung, bevor die Bibliothek diesen Punkt erreicht.