Hardware recomendado
Cámaras
Las cámaras que generan video H.264 y audio AAC ofrecerán la mayor compatibilidad con todas las funciones de SecureVu y Home Assistant. También es útil que tu cámara admita múltiples substreams para permitir diferentes resoluciones para detección, streaming y grabaciones sin recodificación.
Se recomiendan Dahua, Hikvision y Amcrest en ese orden. Dahua supera a Hikvision porque son más fáciles de encontrar y pedir, no porque sean mejores cámaras. Personalmente uso cámaras Dahua porque son más fáciles de comprar directamente. En mi experiencia, Dahua e Hikvision tienen múltiples streams con resoluciones y tasas de fotogramas configurables y streams muy estables. Ambas también tienen modelos con sensores grandes conocidos por su excelente calidad de imagen nocturna. No todos los modelos son iguales. Los sensores más grandes son mejor que las resoluciones más altas, especialmente de noche. Amcrest es la recomendación alternativa porque son Dahua remarcadas. Están remarcando los modelos de gama baja con sensores más pequeños o menos opciones de configuración.
Las cámaras WiFi no se recomiendan ya que sus streams son menos confiables y causan pérdida de conexión y/o pérdida de datos de video, especialmente cuando se usan más de unas pocas cámaras WiFi simultáneamente.
Muchos usuarios han reportado varios problemas con cámaras Reolink de 4K o más; es mejor quedarse con 5MP o menos para cámaras Reolink. Si usas Reolink, sugiero la configuración específica para Reolink.
Algunas cámaras recomendadas:
- Loryta(Dahua) IPC-T549M-ALED-S3 (enlace de afiliado)
- Loryta(Dahua) IPC-T54IR-AS (enlace de afiliado)
- Amcrest IP5M-T1179EW-AI-V3 (enlace de afiliado)
- HIKVISION DS-2CD2387G2P-LSU/SL ColorVu Cámara IP Turret Panorámica 8MP (enlace de afiliado)
Puedo recibir una pequeña comisión por mi respaldo, recomendación, testimonio o enlace a productos o servicios de este sitio web.
Servidor
Mi favorito actual es el Beelink EQ13 por su eficiente CPU N100 y sus NICs duales que permiten configurar una red privada dedicada para tus cámaras donde se les puede bloquear el acceso a internet. Hay muchas opciones de estaciones de trabajo usadas en eBay que funcionan muy bien. Cualquier dispositivo con una CPU Intel (con instrucciones AVX + AVX2) y capaz de ejecutar Debian debería funcionar bien. Como ventaja adicional, puedes buscar dispositivos con ranura M.2 o PCIe compatible con el Google Coral, Hailo u otros aceleradores de IA.
Ten en cuenta que muchos de estos mini PCs vienen con Windows preinstalado y necesitarás instalar Linux según la guía de inicio.
Puedo recibir una pequeña comisión por mi respaldo, recomendación, testimonio o enlace a productos o servicios de este sitio web.
Si el EQ13 está agotado, el enlace a continuación puede llevarte a una alternativa sugerida en Amazon. El Beelink EQ14 tiene algunos problemas de compatibilidad conocidos, por lo que deberías evitar ese modelo por ahora.
| Nombre | Capacidades | Notas |
|---|---|---|
| Beelink EQ13 (Amazon) | Puede ejecutar detección de objetos en varias cámaras 1080p con actividad baja-media | NICs gigabit duales para fácil red aislada de cámaras. |
| Intel 1120p (Amazon) | Puede manejar un gran número de cámaras 1080p con alta actividad | |
| Intel 125H (Amazon) | Puede manejar un número significativo de cámaras 1080p con alta actividad | Incluye NPU para detección más eficiente en la v0.17+ |
Detectores
Un detector es un dispositivo optimizado para ejecutar inferencias eficientemente para detectar objetos. Usar un detector recomendado significa menor latencia entre detecciones y más detecciones por segundo. SecureVu está diseñado con la expectativa de que se use un detector para lograr velocidades de inferencia muy bajas. Transferir TensorFlow a un detector es un orden de magnitud más rápido y reducirá drásticamente la carga de tu CPU.
SecureVu soporta múltiples detectores que funcionan con diferentes tipos de hardware:
La mayoría del hardware
-
Hailo: El módulo de aceleración de IA Hailo8 y Hailo8L está disponible en formato m.2 con un HAT para dispositivos RPi, ofreciendo amplia compatibilidad.
- Soporta muchas arquitecturas de modelos
- Funciona mejor con modelos de tamaño pequeño o tiny
-
Google Coral EdgeTPU: El Google Coral EdgeTPU está disponible en formatos USB y m.2.
-
Community Supported MemryX: El módulo acelerador M.2 MX3 está disponible en formato m.2.
- Soporta muchas arquitecturas de modelos
- Funciona mejor con modelos de tamaño tiny, small o medium
AMD
- ROCm: ROCm puede ejecutarse en GPUs discretas AMD para detección eficiente de objetos.
- Soporta arquitecturas de modelos limitadas
- Funciona mejor en GPUs AMD discretas
Apple Silicon
- Apple Silicon: Utilizable en todos los dispositivos Apple Silicon M1 y más nuevos.
- Soporta principalmente arquitecturas ssdlite y mobilenet
- Funciona bien con cualquier tamaño de modelo, incluyendo grandes
- Se ejecuta a través de un proxy ZMQ que añade algo de latencia
Intel
- OpenVino: OpenVino puede ejecutarse en GPUs Intel Arc, GPUs integradas Intel y NPUs Intel.
- Soporta la mayoría de arquitecturas de modelos
- Funciona mejor con modelos tiny, small o medium
Nvidia
-
GPU Nvidia: Las GPUs Nvidia pueden proporcionar detección eficiente de objetos.
- Soporta la mayoría de arquitecturas de modelos mediante ONNX
- Funciona bien con cualquier tamaño de modelo, incluyendo grandes
-
Community Supported Jetson: Los dispositivos Jetson son compatibles mediante los detectores TensorRT u ONNX con Jetpack 6.
Rockchip Community Supported
- RKNN: Los modelos RKNN pueden ejecutarse en dispositivos Rockchip con NPUs integradas.
- Soporta arquitecturas de modelos limitadas
- Funciona mejor con modelos tiny o small
- Funciona eficientemente en hardware de bajo consumo
Synaptics Community Supported
- Synaptics: Los modelos synap pueden ejecutarse en dispositivos Synaptics (por ejemplo, astra machina) con NPUs integradas.
Hailo-8
SecureVu soporta los Módulos de Aceleración de IA Hailo-8 y Hailo-8L en plataformas de hardware compatibles, incluyendo la Raspberry Pi 5 con el HAT PCIe del AI kit.
Configuración de modelo predeterminada:
- Hailo-8L: El modelo predeterminado es YOLOv6n.
- Hailo-8: El modelo predeterminado es YOLOv6n.
| Nombre | Tiempo de inferencia Hailo‑8 | Tiempo de inferencia Hailo‑8L |
|---|---|---|
| ssd mobilenet v1 | ~ 6 ms | ~ 10 ms |
| yolov9-tiny | 320: 18ms | |
| yolov6n | ~ 7 ms | ~ 11 ms |
Google Coral TPU
El Coral ya no se recomienda para nuevas instalaciones de SecureVu, excepto en implementaciones con requisitos de bajo consumo especialmente reducidos o hardware incapaz de utilizar otros aceleradores de IA. Se sugiere usar uno de los otros detectores soportados. SecureVu continuará brindando soporte para el Coral TPU durante el mayor tiempo posible, dado que sigue siendo uno de los dispositivos más eficientes energéticamente para ejecutar modelos de detección de objetos.
SecureVu soporta las versiones USB y M.2 del Google Coral.
- La versión USB es compatible con la mayor variedad de hardware y no requiere un controlador en la máquina host, pero carece de las funciones de regulación automática.
- Las versiones PCIe y M.2 requieren instalación de un controlador en el host. Se debe usar https://github.com/jnicolson/gasket-builder.
Un solo Coral puede manejar muchas cámaras usando el modelo predeterminado. Puedes calcular el rendimiento máximo de tu Coral basándote en la velocidad de inferencia reportada por SecureVu. Con una velocidad de inferencia de 10, tu Coral llegará a 1000/10=100, es decir 100 fotogramas por segundo.
OpenVINO - Intel
El tipo de detector OpenVINO puede ejecutarse en:
- Plataformas Intel de 6ª generación y más nuevas con iGPU
- Hosts x86 con GPU Intel Arc
- NPUs Intel
- La mayoría de CPUs AMD modernas (aunque no está oficialmente soportado por Intel)
- Hosts x86 y Arm64 mediante CPU (generalmente no recomendado)
Las GPUs Intel B-series (Battlemage) no son oficialmente compatibles con SecureVu 0.17, aunque un usuario ha proporcionado pasos para reconstruir el contenedor SecureVu con soporte para ellas.
| Nombre | Tiempo MobileNetV2 | YOLOv9 | Tiempo YOLO-NAS | Tiempo RF-DETR | Notas |
|---|---|---|---|---|---|
| Intel HD 530 | 15 - 35 ms | Solo puede ejecutar una instancia | |||
| Intel HD 620 | 15 - 25 ms | 320: ~ 35 ms | |||
| Intel HD 630 | ~ 15 ms | 320: ~ 30 ms | |||
| Intel UHD 730 | ~ 10 ms | t-320: 14ms s-320: 24ms t-640: 34ms s-640: 65ms | 320: ~ 19 ms 640: ~ 54 ms | ||
| Intel UHD 770 | ~ 15 ms | t-320: ~ 16 ms s-320: ~ 20 ms s-640: ~ 40 ms | 320: ~ 20 ms 640: ~ 46 ms | ||
| Intel N100 | ~ 15 ms | s-320: 30 ms | 320: ~ 25 ms | Solo puede ejecutar una instancia | |
| Intel N150 | ~ 15 ms | t-320: 16 ms s-320: 24 ms | |||
| Intel Iris XE | ~ 10 ms | t-320: 6 ms t-640: 14 ms s-320: 8 ms s-640: 16 ms | 320: ~ 10 ms 640: ~ 20 ms | 320-n: 33 ms | |
| Intel NPU | ~ 6 ms | s-320: 11 ms s-640: 30 ms | 320: ~ 14 ms 640: ~ 34 ms | 320-n: 40 ms | |
| Intel Arc A310 | ~ 5 ms | t-320: 7 ms t-640: 11 ms s-320: 8 ms s-640: 15 ms | 320: ~ 8 ms 640: ~ 14 ms | ||
| Intel Arc A380 | ~ 6 ms | 320: ~ 10 ms 640: ~ 22 ms | 336: 20 ms 448: 27 ms | ||
| Intel Arc A750 | ~ 4 ms | 320: ~ 8 ms |
GPUs Nvidia
SecureVu puede utilizar una GPU Nvidia que soporte la serie 12.x de librerías CUDA.
Soporte mínimo de hardware
La versión mínima del controlador en el sistema host debe ser >=545 y la GPU debe soportar una Capacidad de Cómputo de 5.0 o mayor (GPUs de era Maxwell o más nuevas).
Asegúrate de tener instalado el nvidia-container-runtime en tu sistema host.
Referencias de compatibilidad:
Matriz de soporte NVIDIA TensorRT
Capacidad de cómputo GPU NVIDIA
✅ - Acelerado con CUDA Graphs ❌ - No acelerado con CUDA Graphs
| Nombre | ✅ Tiempo YOLOv9 | ✅ Tiempo RF-DETR | ❌ Tiempo YOLO-NAS |
|---|---|---|---|
| GTX 1070 | s-320: 16 ms | 320: 14 ms | |
| RTX 3050 | t-320: 8 ms s-320: 10 ms s-640: 28 ms | Nano-320: ~ 12 ms | 320: ~ 10 ms 640: ~ 16 ms |
| RTX 3070 | t-320: 6 ms s-320: 8 ms s-640: 25 ms | Nano-320: ~ 9 ms | 320: ~ 8 ms 640: ~ 14 ms |
| RTX A4000 | 320: ~ 15 ms | ||
| Tesla P40 | 320: ~ 105 ms |
Apple Silicon
Con el detector Apple Silicon, SecureVu puede aprovechar la NPU en dispositivos M1 y más nuevos.
Apple Silicon no puede ejecutarse dentro de un contenedor, por lo que se utiliza un proxy ZMQ para comunicarse con el detector Apple Silicon de SecureVu que se ejecuta en el host.
| Nombre | Tiempo de inferencia YOLOv9 |
|---|---|
| M4 | s-320: 10 ms |
| M3 Pro | t-320: 6 ms s-320: 8 ms s-640: 20 ms |
| M1 | s-320: 9ms |
ROCm - GPU AMD
Con el detector ROCm, SecureVu puede aprovechar muchas GPUs discretas AMD.
| Nombre | Tiempo de inferencia YOLOv9 | Tiempo YOLO-NAS |
|---|---|---|
| AMD 780M | t-320: ~ 14 ms s-320: 20 ms | 320: ~ 25 ms 640: ~ 50 ms |
| AMD 8700G | 320: ~ 20 ms 640: ~ 40 ms |
Detectores con soporte de la comunidad
MemryX MX3
SecureVu soporta el Módulo de Aceleración de IA MemryX MX3 M.2 en plataformas de hardware compatibles, incluyendo x86 (Intel/AMD) y SBCs basados en ARM como la Raspberry Pi 5.
Configuración de modelo predeterminada:
- El modelo predeterminado es YOLO-NAS-Small.
| Modelo | Tamaño de entrada | Tiempo de inferencia MX3 | FPS total MX3 |
|---|---|---|---|
| YOLO-NAS-Small | 320 | ~ 9 ms | ~ 378 |
| YOLO-NAS-Small | 640 | ~ 21 ms | ~ 138 |
| YOLOv9s | 320 | ~ 16 ms | ~ 382 |
| YOLOv9s | 640 | ~ 41 ms | ~ 110 |
| YOLOX-Small | 640 | ~ 16 ms | ~ 263 |
| SSDlite MobileNet v2 | 320 | ~ 5 ms | ~ 1056 |
Nvidia Jetson
Los dispositivos Jetson son compatibles mediante los detectores TensorRT u ONNX con Jetpack 6. Hace uso del motor de medios por hardware del Jetson y del GPU y DLA del Jetson para detección de objetos con el detector TensorRT.
Plataforma Rockchip
SecureVu soporta procesamiento de video por hardware en todas las placas Rockchip. Sin embargo, la detección de objetos por hardware solo es compatible en estas placas:
- RK3562
- RK3566
- RK3568
- RK3576
- RK3588
| Nombre | Tiempo YOLOv9 | Tiempo YOLO-NAS | Tiempo YOLOx |
|---|---|---|---|
| rk3588 3 cores | tiny: ~ 35 ms | small: ~ 20 ms med: ~ 30 ms | nano: 14 ms tiny: 18 ms |
| rk3566 1 core | small: ~ 96 ms |
Synaptics
- Synaptics El modelo predeterminado es mobilenet
| Nombre | Tiempo de inferencia Synaptics SL1680 |
|---|---|
| ssd mobilenet | ~ 25 ms |
| yolov5m | ~ 118 ms |
¿Para qué usa SecureVu la CPU y para qué usa un detector? (Versión simplificada)
Tomado de una pregunta de usuario en reddit. Ligeramente modificado para mayor claridad.
Uso de CPU: Soy una CPU, Mendel es un Google Coral
Mi amigo Mendel y yo hemos sido encargados de mantener a la garza de patas rojas del vecino fuera del jardín de mis padres. Soy muy malo identificando aves; me lleva mucho tiempo, pero mi amigo Mendel es increíble en eso.
Mendel, sin embargo, tiene dificultades con casi todo lo demás. Así que llegamos a un acuerdo: yo espero hasta ver algo que se mueva y le tomo una foto a Mendel. Luego le muestro la foto y él me dice qué es. La mayoría de las veces no es nada. Pero eventualmente veo movimiento y Mendel me dice que es la garza. ¡Éxito!
¿Qué pasa cuando aumento la resolución de mi cámara?
Sin embargo, nos damos cuenta de que hay un problema. Hay más excrementos en el jardín. ¡¿Cómo pudimos no verlos?! Estuve mirando todo el día. Mis padres revisan la ventana y se dan cuenta de que está sucia y es un poco pequeña para ver todo el jardín, así que la limpian y ponen una más grande. ¡Ahora hay mucho más que ver! Sin embargo, ahora tengo un área mucho mayor que analizar en busca de movimiento y tengo que trabajar mucho más. ¡Incluso mi amigo Mendel tiene que trabajar más, ya que ahora las fotos tienen mucho más detalle para analizar!
Básicamente: cuando aumentas la resolución y/o la tasa de fotogramas del stream, hay significativamente más datos para que la CPU procese. Eso requiere potencia de cómputo adicional. El Google Coral es muy bueno detectando objetos, pero no tiene tiempo de mirar en todas partes todo el tiempo. Para equilibrarlo, SecureVu usa la CPU para detectar movimiento y luego envía esos fotogramas al Coral para la detección de objetos.
¿Los argumentos hwaccel ayudan si uso un Coral?
¡SÍ! El Coral no ayuda con la decodificación de streams de video.
Descomprimir streams de video consume una cantidad significativa de potencia de CPU. La compresión de video usa fotogramas clave (también conocidos como I-frames) para enviar un fotograma completo. Los fotogramas siguientes solo incluyen la diferencia respecto al fotograma clave. Las resoluciones y tasas de fotogramas más altas requieren más potencia de procesamiento para decodificar el stream de video, así que intenta configurarlas en la cámara para evitar trabajo de decodificación innecesario.