¿Cuántas transmisiones de cámaras puede gestionar un servidor NVR doméstico?
No existe una cifra fija y fiable de cuántos flujos de cámara puede gestionar cualquier servidor NVR doméstico. Un servidor que graba ocho flujos comprimidos puede tener una carga menor que otro que decodifica y analiza cuatro transmisiones de alta resolución. La compra debe dimensionarse a partir de tres cargas independientes —ancho de banda de grabación, decodificación de vídeo y detección de objetos— y después comprobarse en función de la retención de almacenamiento y del número de cámaras que probablemente estarán activas al mismo tiempo.
Divide cada cámara en cargas de grabación, visualización y detección
Una cámara puede generar más de una carga de trabajo aunque físicamente sea un único dispositivo. El NVR puede almacenar un flujo principal de alta calidad, decodificar un subflujo de menor resolución para la detección y retransmitir otro flujo para la visualización en directo. Tratar los tres como un único «canal de cámara» oculta el trabajo que realmente realiza el servidor.
Axis explica por qué la eficiencia de los códecs de videovigilancia cambia las necesidades de ancho de banda y almacenamiento. H.264, H.265 y los códecs más recientes pueden ofrecer tasas de bits muy diferentes para objetivos visuales similares, por lo que el número de flujos sin conocer el códec y la tasa de bits no basta para dimensionar el sistema.
La guía de ZimaSpace sobre cómo crear un servidor NVR local establece los límites arquitectónicos: el flujo de la cámara, la ruta de red, el entorno de ejecución de la aplicación, el almacenamiento de las grabaciones y el acceso remoto son partes independientes del sistema.
Crea una hoja de cálculo con una fila por cámara y columnas para la resolución de grabación, la tasa de bits de grabación, la resolución de detección, los FPS de detección, la demanda de visualización en directo y la disponibilidad de decodificación por hardware. Esa hoja será más útil que cualquier afirmación de que un procesador admite un número universal de cámaras.
Los flujos que solo graban suelen ser un problema de almacenamiento y red
Si el NVR escribe los flujos de cámara ya codificados sin decodificarlos ni volver a codificarlos, la carga de la CPU puede mantenerse relativamente baja. Los principales límites pasan a ser el rendimiento agregado de la red, las escrituras sostenidas en el disco, la sobrecarga del sistema de archivos y la posible competencia entre la reproducción o las exportaciones y las grabaciones entrantes.
La guía actual de resolución de Reolink muestra cómo la resolución y la compresión cambian las necesidades de almacenamiento de las cámaras. Un flujo de alta resolución no tiene una tasa de bits fija; la complejidad de la escena y las opciones de codificación también influyen.
Mide la tasa de bits agregada en lugar de multiplicar el número de cámaras por una cifra genérica. Suma la tasa de bits máxima prevista de todos los flujos que se graban continuamente y deja margen para la reproducción, las exportaciones, las miniaturas, las operaciones de la base de datos y los picos temporales. La red y el almacenamiento deben mantenerse cómodamente por debajo de la saturación durante todas esas tareas combinadas.
Por tanto, un procesador modesto puede grabar muchos flujos si el servidor se limita principalmente a recibir y escribir vídeo comprimido. La situación cambia cuando el NVR debe decodificar cada transmisión, escalar los fotogramas, generar vistas previas, transcodificar para los clientes o ejecutar visión artificial de forma continua.
La decodificación por hardware cambia el límite de cámaras antes que la detección mediante IA
La decodificación de vídeo puede consumir una cantidad considerable de CPU de propósito general cuando se procesan por software varios flujos de alta resolución. Los gráficos integrados u otro motor de vídeo por hardware pueden eliminar gran parte de esa carga de decodificación, por lo que dos servidores con un número de núcleos de CPU similar pueden admitir cargas de trabajo NVR muy diferentes.
Una reseña de Tom's Hardware sobre una plataforma Intel N100 con gráficos integrados muestra la clase de hardware que se utiliza habitualmente en servidores domésticos de bajo consumo: cuatro núcleos de CPU, una iGPU y almacenamiento local rápido. Lo importante es el motor multimedia, no el rendimiento en juegos.
La detección de objetos es una ruta independiente de la decodificación. Un acelerador puede procesar la inferencia de forma eficiente, pero el servidor aún debe recibir y decodificar los fotogramas antes de enviarlos al detector. No des por hecho que añadir un Coral, una GPU u otro dispositivo de IA elimina todos los cuellos de botella de la CPU y del procesamiento de vídeo.
Para realizar una prueba de compra, desactiva primero la detección y mide la grabación más la decodificación. Después activa la detección con los FPS previstos y observa el uso de la CPU, la GPU y el acelerador, los fotogramas perdidos y la latencia de detección. Así podrás identificar por separado el límite de hardware que realmente necesita una actualización.
La retención de almacenamiento puede obligar a comprar un servidor más grande antes que la carga de cómputo
Un NVR doméstico puede tener un amplio margen de procesamiento y seguir siendo una compra inadecuada porque no puede conservar el periodo de retención deseado. El vídeo continuo es una carga de escritura sostenida, y la capacidad aumenta directamente con la tasa de bits agregada y el tiempo de grabación.
El análisis de Backblaze sobre almacenamiento de videovigilancia explica cómo el número de cámaras, la tasa de bits y la retención determinan las necesidades de almacenamiento. Estas variables deben calcularse antes de elegir el número de bahías para unidades o asumir que bastará con un disco pequeño para las grabaciones.
La guía de compra de ZimaSpace sobre el aislamiento de las grabaciones de cámaras añade una consideración de fiabilidad: una carga de trabajo NVR no debe privar de recursos a los servicios críticos de domótica cuando el almacenamiento se llena o los análisis experimentan picos.
Si una configuración de dos unidades alcanza el límite de retención demasiado rápido, puede estar justificado contar con más bahías aunque el uso de la CPU sea bajo. Es una mejora de la configuración de almacenamiento, no una prueba de que la plataforma de procesamiento de cámaras necesite más capacidad de cómputo.
Prueba la actividad simultánea, no una escena vacía
Los análisis de las cámaras son variables porque no todas las vistas contienen movimiento u objetos al mismo tiempo. Una prueba nocturna tranquila puede ocultar la carga que aparece cuando llegan los miembros de la familia, los coches pasan por la entrada, las mascotas atraviesan varias zonas y se abren varias vistas en directo simultáneamente.
Las pruebas de NVR de StorageReview demostraron que varias grabaciones simultáneas de cámaras pueden gestionarse cómodamente cuando la ruta de grabación dispone de suficiente rendimiento sostenido, dejando además margen para la reproducción y el acceso de red. La lección es probar el estado combinado, no el estado inactivo.
Crea una escena de peor caso abriendo el panel de control en directo, activando el movimiento en varias zonas, ejecutando la detección de objetos y exportando o reproduciendo grabaciones recientes mientras todas las cámaras siguen grabando. Observa la latencia de decodificación, la latencia de inferencia, los fotogramas perdidos, la profundidad de la cola del disco y el uso de la red.
Si el sistema permanece estable, añadir una cámara más se convierte en una decisión de capacidad medible. Si un recurso compartido ya está cerca de la saturación, actualiza primero ese recurso en lugar de sustituir todo el NVR basándote únicamente en el número de cámaras.
Relaciona el NVR con el hardware de Zima según la escala de grabación y la carga de análisis
Para un NVR doméstico modesto en el que se graba localmente un número reducido de cámaras y los análisis son limitados, ZimaBoard 2 1664 es la opción más adecuada dentro de la gama ZimaBoard 2, ya que su memoria adicional ofrece más espacio para el software de cámaras, las bases de datos y los contenedores auxiliares. Su ranura PCIe también puede reservarse para un acelerador si se prevé realizar detección local.
No asignes un número fijo de cámaras a la placa sin probar los flujos reales. La resolución, el códec, la tasa de bits, la ruta de decodificación y los FPS de detección pueden cambiar demasiado la carga como para establecer una clasificación universal de canales. Utiliza la hoja de cálculo y la prueba de carga combinada anteriores como criterio de validación.
Da el salto a ZimaCube 2 cuando una retención más prolongada, más bahías para unidades, una grabación simultánea más intensa o un mayor almacenamiento doméstico constituyan una razón independiente para disponer de un NAS con varias bahías. Elige el Creator Pack solo cuando el cómputo dedicado de GPU sea un requisito real para los análisis, no simplemente porque la palabra «IA» aparezca en el software del NVR.
La mejor compra para un NVR es el sistema más pequeño que supera la prueba de cámaras más exigente y realista, y que aún conserva margen de almacenamiento, red y cómputo. El número de cámaras es solo la etiqueta; la carga de trabajo real es la cadena de procesamiento de los flujos.
Preguntas frecuentes
¿Debe contarse una cámara 4K como cuatro cámaras 1080p?
No. El número de píxeles por sí solo no determina la carga del servidor. También importan la tasa de bits, el códec, la frecuencia de fotogramas, el diseño del subflujo, la decodificación por hardware y la resolución de los análisis. Trata cada cámara como sus flujos de grabación y detección medidos, en lugar de convertir la resolución en un número fijo equivalente de cámaras.
¿Un acelerador de IA aumenta el número de cámaras que puedo grabar?
No automáticamente. Un acelerador puede aumentar la capacidad de detección de objetos, pero la grabación sigue dependiendo del rendimiento de la red y del almacenamiento, y la decodificación de vídeo puede seguir dependiendo de la CPU o de los gráficos integrados. Solo eleva el límite cuando la inferencia es la etapa que restringe el rendimiento.
Productos recomendados
Guía de compra
Más para leer
Cómo traducir las especificaciones de CPU, RAM e IOPS al rendimiento de Plex
Una guía de compra para convertir las mediciones de carga de trabajo de Plex en requisitos mínimos de CPU, RAM, almacenamiento y red sin...
Cómo preseleccionar servidores domésticos para Plex mediante criterios ponderados
Una matriz de compra reproducible para Plex que separa los requisitos obligatorios de las preferencias y revela las incertidumbres antes de la compra.
¿Qué ciclo de soporte y actualizaciones debería ofrecer un servidor Plex?
Un marco de compra de aprobado o reprobado para evaluar la compatibilidad con servidores Plex, el historial de actualizaciones, la compatibilidad, la reparabilidad, los...
