Immich no ofrece una proporción fiable de almacenamiento exclusiva para miniaturas, por lo que las bibliotecas familiares deben medir los bytes generados por recurso y reservar espacio independiente para los modelos de ML.
Un archivo de fotos familiares de 2 TB no indica cuánto crecerá su directorio de miniaturas de Immich, porque el número de recursos, la resolución original, la configuración de las miniaturas, la proporción de vídeos y los modelos habilitados modifican el espacio derivado. El método más seguro para calcular la capacidad es procesar una muestra representativa, medir por separado las miniaturas y la caché de modelos, proyectar el crecimiento de la biblioteca y añadir margen operativo, en lugar de tratar un único porcentaje como requisito universal.
Separa los originales del almacenamiento generado por Immich
Empieza por establecer una distinción: las fotos y los vídeos originales son solo una parte del espacio de disco que respalda una biblioteca de Immich. El servidor también conserva recursos generados para la navegación y la compatibilidad, mientras que el servicio de aprendizaje automático mantiene los archivos de modelos descargados en su propia caché. Estas categorías crecen por motivos distintos, por lo que combinarlas en un porcentaje impreciso dificulta saber qué configuración o carga de trabajo está consumiendo realmente el espacio.
Una referencia de dimensionamiento de la comunidad de Immich señala que las miniaturas y los vídeos transcodificados juntos pueden añadir aproximadamente entre un 10 y un 20 % de media. Esta cifra solo sirve como contexto general: combina dos categorías generadas y, por tanto, no debe presentarse como una proporción exclusiva de miniaturas. Una familia con muchas fotos y pocos vídeos puede obtener un resultado muy distinto al de un archivo con muchos vídeos.
La arquitectura también importa al decidir dónde colocar ese espacio adicional. El análisis de ZimaSpace sobre la organización de fotos mediante IA considera la indexación y los datos generados como servicios alrededor de la biblioteca original, no como sustitutos de ella. Para planificar la capacidad, mantén por separado los originales, el área de miniaturas y vistas previas, los derivados de vídeo, la base de datos y la caché de ML, aunque compartan un mismo disco físico.
Mide el coste de las miniaturas por recurso antes de ampliar
Elige una muestra representativa de la biblioteca familiar en lugar de los mil archivos más sencillos. Debe incluir las distintas generaciones de teléfonos, resoluciones de cámaras, retratos, capturas de pantalla, panorámicas y otros tipos de imagen habituales. Deja que finalicen los trabajos relacionados con las miniaturas, registra el número de recursos procesados y mide el directorio de miniaturas. Dividir los bytes medidos entre los recursos procesados proporciona una proporción local para la planificación que ya refleja la configuración elegida para miniaturas y vistas previas.
Las instalaciones reales demuestran por qué importa esa proporción local. Un debate de Immich informó de 21 GB de miniaturas, junto con 58 GB de vídeo codificado en ese sistema concreto. La cifra es anecdótica y no constituye un objetivo, pero demuestra que las carpetas derivadas pueden tener tamaños muy diferentes y deben medirse de forma independiente, en lugar de inferirse únicamente a partir de los terabytes de la biblioteca original.
Por ejemplo, si 10.000 imágenes representativas generan 12 GB de miniaturas y vistas previas, la tasa observada es de aproximadamente 1,2 MB por recurso. Una biblioteca proyectada de 60.000 imágenes requeriría, por tanto, unos 72 GB con la misma configuración, antes de añadir un margen de crecimiento. Repite la muestra después de cambiar la resolución o la calidad de las miniaturas, porque esos cambios invalidan la proporción anterior por recurso aunque los archivos originales no hayan cambiado.
La caché de modelos de ML depende más de los modelos que del número de fotos
El almacenamiento del aprendizaje automático se comporta de forma diferente al de las miniaturas. La caché de modelos contiene principalmente archivos de modelos que el servicio de ML descarga y reutiliza, por lo que su tamaño depende más de los modelos de búsqueda inteligente y reconocimiento facial que selecciones que de si la biblioteca tiene 20.000 o 200.000 fotos. El tamaño de la biblioteca modifica cuánto procesamiento se realiza, pero no exige una copia nueva del modelo por cada recurso.
Una implementación reciente de Immich autoalojado describe una caché de modelos persistente montada para el servicio de aprendizaje automático e informa de que los modelos utilizados ocupaban menos de 1 GB en total. Esa es una configuración concreta, no una garantía. Lo importante es el mecanismo de persistencia y reutilización: una vez presentes los archivos seleccionados, el crecimiento normal del número de fotos no multiplica los binarios de los modelos.
Para un servidor familiar que pueda cambiar de modelos más adelante, es razonable planificar una reserva mayor que la caché mínima observada actualmente. Un mantenedor de Immich ha sugerido que, en general, unos 10 GB de almacenamiento suelen ser suficientes, dependiendo de los modelos elegidos. Tómalo como una reserva inicial conservadora, no como un requisito, y sustitúyelo por el tamaño real de la caché de tu configuración cuando hayan finalizado los primeros trabajos de ML.
La proporción de vídeos y la caché del cliente pueden invalidar una estimación basada solo en fotos
La estimación de miniaturas más ML deja de describir adecuadamente el almacenamiento total cuando la biblioteca contiene muchos vídeos o cuando se analiza el almacenamiento local del dispositivo. La compatibilidad de vídeo puede crear grandes derivados en el servidor, mientras que las cachés del teléfono y del navegador ocupan almacenamiento del cliente que no forma parte del directorio de miniaturas ni de la caché de modelos de ML del servidor. Mezclar esas cifras puede hacer que una estimación normal de miniaturas parezca enormemente errónea.
El informe de un usuario con una biblioteca grande ilustra esta diferencia: una biblioteca de aproximadamente 2,4 TB, con 179.000 fotos y 19.000 vídeos, registró 822 GB de derivados del servidor para miniaturas y vídeos transcodificados, mientras que la aplicación de Android también acumuló decenas de gigabytes localmente. Es una anécdota, no una regla de dimensionamiento, pero muestra cómo el vídeo y la caché del cliente pueden dominar un modelo sencillo basado solo en fotos.
Mantén las categorías separadas al medir: datos de miniaturas y vistas previas del servidor, vídeo codificado, caché de modelos de ML, base de datos y caché local del cliente. Si el almacenamiento de miniaturas parece inesperadamente grande, inspecciona directamente el directorio de miniaturas en lugar de todo el árbol de datos de Immich. Si el vídeo codificado es la carpeta dominante, la pregunta de planificación ha cambiado: ya no se trata del exceso de indexación de fotos, sino de la compatibilidad de vídeo y la política de transcodificación.
Usa una fórmula basada en muestras y crecimiento para el almacenamiento familiar
Usa tres valores: los bytes medidos de miniaturas por recurso representativo, el número de imágenes proyectado para los próximos uno o dos años y el tamaño medido de la caché de modelos de ML. Multiplica los dos primeros, añade la caché de modelos y, después, incorpora un margen operativo para regeneraciones, cambios de configuración y el crecimiento normal del sistema de archivos. Un margen del 20–25 % es una heurística de planificación, no un requisito de Immich; quienes tengan discos con poco espacio libre deberían medir con más frecuencia en lugar de asumir que el margen siempre será suficiente.
Un límite conservador para la caché de modelos puede partir de la recomendación del mantenedor de que unos 10 GB deberían bastar en general, dependiendo de los modelos elegidos. Combínalo con tu propia medición de miniaturas, no con la cifra del 10–20 % correspondiente a miniaturas más transcodificaciones. Para una huella proyectada de miniaturas de 72 GB, una reserva de 10 GB para modelos y un margen del 25 %, la reserva de planificación sería de unos 103 GB.
Vuelve a calcular cuando cambie cualquier variable que influya en la estimación: la resolución o calidad de las miniaturas, un cambio importante en la resolución de las cámaras, otro modelo de ML, un crecimiento significativo del vídeo o un aumento considerable del número de familiares que suben recursos. El umbral de decisión es sencillo: si el almacenamiento generado proyectado más el margen se acerca al espacio libre disponible en el volumen rápido previsto, mueve la ruta de los derivados, añade capacidad o reduce la configuración de generación correspondiente antes de llegar a ese punto.
Centro de Tecnología e IA
Más para leer

Los modelos abiertos están alcanzando a la IA de vanguardia: ¿será 2026 el año en que la IA local alcance un nivel suficientemente bueno?
Los modelos abiertos están alcanzando un nivel suficiente para más cargas de trabajo de IA local, mientras que los modelos de vanguardia en la...

NVIDIA PAIR convierte tu red doméstica en un clúster local de IA—¿todavía necesitas un gran servidor con GPU?
NVIDIA PAIR distribuye las solicitudes de IA local entre varios PC, haciendo que la capacidad de cómputo sea más flexible, mientras un servidor doméstico...

¿Por qué Immich se siente más rápido en una red LAN que mediante conexiones remotas?
Las solicitudes en la LAN suelen seguir una ruta más corta y con menor latencia. El acceso remoto añade limitaciones de capacidad de la...

