Modelos ligeros para huella y rostro: qué cabe realmente en un móvil de gama media

Cuando un equipo de producto plantea ejecutar la identificación biométrica en el propio teléfono, la primera pregunta que aparece en la mesa técnica no es si el modelo es preciso, sino si cabe. Y no cabe en abstracto: cabe dentro de un presupuesto de memoria que el sistema operativo ya está usando, dentro de un margen térmico que se agota con cualquier tarea sostenida, y dentro de una ventana de latencia que el usuario percibe como inmediata o como espera. En un móvil de gama media, ese presupuesto es estrecho y poco negociable.

Los SoC recientes de gama media suelen reservar entre 1 y 2 GB de RAM para la NPU, pero ese bloque no es exclusivo. El reconocimiento facial compite con la cámara, con el motor de gráficos y con procesos en segundo plano que el sistema no siempre libera. En la práctica, un modelo de rostro cuantizado a INT8 que ocupe más de 8 MB empieza a notar presión: la primera inferencia es rápida, la décima ya arrastra recarga de pesos desde almacenamiento. La huella, en cambio, trabaja con tensores mucho menores y tolera mejor la contención, aunque suele depender de un sensor dedicado con su propio firmware.

El presupuesto térmico marca otro límite silencioso. Una NPU que ejecuta inferencias continuas durante varios minutos eleva la temperatura del chasis y el sistema reduce la frecuencia para protegerse. En pruebas con dispositivos de gama media, ese throttling aparece antes de los tres minutos de uso intensivo y puede duplicar la latencia por inferencia. Para una autorización de transferencia puntual no es un problema; para un flujo que valida cada orden de una sesión de trading, sí lo es.

De ahí surge una jerarquía razonable según el tipo de operación. La consulta de saldo puede resolverse con un modelo mínimo, casi un clasificador de presencia, porque el riesgo es bajo y la fricción debe ser nula. La confirmación de una orden exige un modelo intermedio con umbral de confianza calibrado y verificación de vitalidad. La autorización de una transferencia, en cambio, justifica un modelo más pesado o incluso una segunda señal biométrica combinada. No es lo mismo proteger un dato que mover dinero.

Queda la pregunta de cuándo conviene delegar en el servidor. La respuesta no es ideológica. Si el dispositivo está en una red estable y la operación es de alto valor, el coste de enviar una plantilla cifrada y esperar la validación remota puede ser aceptable. Si la red es móvil, congestionada o el usuario opera desde una ubicación con cobertura irregular, la inferencia local evita una espera que rompe el flujo. La decisión se toma por operación, no por producto.

El error más común al dimensionar estos modelos es optimizar para el mejor caso: el teléfono frío, la red vacía, el usuario quieto. El hardware real impone lo contrario. Diseñar para el peor escenario razonable, con margen térmico y memoria de sobra, es lo que separa una verificación que funciona en demo de una que aguanta una sesión completa.