Quiénes sostienen la inferencia local

Un equipo que lleva años midiendo latencia en placas pequeñas, depurando modelos que caben en 2 MB y decidiendo qué datos nunca deberían salir del terminal. Esta página cuenta de dónde venimos y por qué trabajamos así.

De un prototipo de escritorio a terminales desplegados en planta

La historia de EdgeBio se mide en versiones de firmware, no en rondas de financiación. Cada etapa resolvió un problema concreto de inferencia local: primero la latencia, después el consumo, más tarde la privacidad de las plantillas y, finalmente, la operación sin red.

  1. Etapa 01

    Primer modelo facial ejecutado en un SoC de gama baja

    El punto de partida fue un reconocedor de 12 MB que tardaba 900 ms por fotograma en una placa con 256 MB de RAM. Se recortaron capas convolucionales redundantes y se sustituyó la última etapa por una proyección lineal. La latencia bajó a 180 ms y el modelo cabía en memoria sin swap. Fue la primera vez que la verificación funcionó sin enviar nada a un servidor.

  2. Etapa 02

    Cuantización int8 y el problema de la iluminación variable

    Al comprimir los pesos a enteros de 8 bits, el consumo energético cayó casi a la mitad, pero la tasa de falsos rechazos subió en pasillos con luz lateral. Se incorporó un preprocesado adaptativo por histograma local y se ajustaron los umbrales de decisión por franja horaria. El resultado fue un modelo de 1.8 MB que rinde mejor que el original de 12 MB en capturas en movimiento.

  3. Etapa 03

    Plantillas irreversibles y la decisión de no almacenar embeddings

    Guardar el vector de rasgos sin protección era cómodo y también indefendible. Se adoptó una proyección unidireccional con sal por dispositivo, de modo que la plantilla almacenada no permite reconstruir el rostro ni la huella. La revocación se resolvió regenerando la sal y volviendo a enrolar. El coste de cómputo en el MCU fue asumible: unos pocos milisegundos por verificación.

  4. Etapa 04

    Operación con conectividad intermitente en planta

    Cuarenta terminales en una nave industrial perdían el enlace satelital cada pocas horas. Se diseñó una caché cifrada de plantillas, una política de decisión local y una sincronización diferida por lotes. El terminal sigue verificando durante cortes largos y, al recuperar la conexión, reconcilia estados sin duplicar enrolamientos ni aceptar plantillas ya revocadas.

  5. Etapa 05

    Del piloto cerrado a la documentación abierta

    Lo que empezó como un cuaderno de decisiones de ingeniería se convirtió en una guía pública: poda, cuantización, destilado, protección de plantillas y tolerancia a fallos de red. Publicamos los parámetros que funcionaron y también los que no, porque el detalle práctico es lo que permite replicar un despliegue real en un terminal con recursos limitados.

Cada etapa dejó una restricción que sigue vigente: el dato biométrico no sale del dispositivo salvo como plantilla protegida, y la decisión se toma en el propio sensor.

Quiénes sostienen EdgeBio

Un equipo pequeño, repartido entre Santiago del Estero y viajes cortos a plantas industriales. Escribimos sobre lo que instalamos, no sobre lo que imaginamos.

EdgeBio nació de una discusión concreta: un cliente no podía enviar plantillas faciales a un servidor central por una cláusula contractual. En lugar de negociar la cláusula, movimos la inferencia al terminal. Desde entonces trabajamos con equipos de seguridad, integradores y responsables de cumplimiento que necesitan biometría funcionando dentro del dispositivo, sin depender de un enlace estable con la nube.

  • Para quién Integradores de control de acceso

    Empresas que despliegan lectores en plantas, hospitales u oficinas y necesitan que la verificación siga operando cuando el enlace satelital o el VPN se cae durante horas. Trabajamos con hardware ya comprado, no con placas propias.

  • Cómo pensamos La plantilla no sale del sensor

    Partimos de una regla simple: si el dato biométrico puede quedarse en el dispositivo, se queda. Eso condiciona la arquitectura de micromodelos, la política de caché y hasta la elección del SoC. No es una postura de marketing, es una restricción de diseño.

  • Qué no hacemos No vendemos reconocimiento en la nube

    Si el proyecto exige comparar contra una base centralizada de millones de rostros, no somos el proveedor adecuado. Preferimos decirlo antes de firmar que adaptar el discurso después.

  • Tono Documentación antes que promesas

    Publicamos métricas de latencia, consumo y tasa de verificación medidas en banco de pruebas. Cuando algo falla en campo, lo anotamos en el blog con el mismo detalle que cuando funciona.

Configuracion de cookies

Usamos cookies para mantener el sitio estable, recordar opciones basicas y entender que paginas resultan utiles. Puedes aceptar, rechazar o revisar la configuracion antes de continuar.