Google lleva GPU de LiteRT a Play services para reducir tamaño y actualizar el runtime sin republicar la app

LiteRT mueve el runtime fuera de cada APK. Google publicó el 28 de octubre que LiteRT en Google Play services incorpora inferencia GPU y atiende más de un billón de inferencias diarias según la empresa. El punto de partida es la distribución y actualización de inferencia personalizada en dispositivos Android heterogéneos. La lectura conserva fecha, alcance y responsable; una novedad técnica no demuestra adecuación para cada organización. La lectura responsable de la distribución y actualización de inferencia personalizada en dispositivos Android heterogéneos separa el anuncio reciente de cualquier promesa futura. La pregunta inmediata es migrar por cohortes después de comparar tamaño, velocidad, consumo, compatibilidad y paridad de resultados. Para responderla, una organización necesita conservar modelo, formato, versión, dispositivo, API, acelerador, fallback, latencia, memoria, tamaño, salida, error, energía y rollback y comunicar qué aspectos todavía no se han evaluado de manera independiente.

CompiledModel unifica CPU y GPU. En pruebas de Google, retirar el runtime empaquetado redujo aproximadamente ocho megabytes y la nueva GPU resultó cerca de 1,4 veces más rápida que el delegado heredado. Esta precisión modifica la decisión: migrar por cohortes después de comparar tamaño, velocidad, consumo, compatibilidad y paridad de resultados. El equipo escribe qué espera mejorar, qué dato excluye y quién responde ante una desviación. El alcance importa tanto como la novedad. En este caso, cifras de pruebas propias, fragmentación de hardware, disponibilidad de GPU, actualizaciones escalonadas, APIs obsoletas y retirada futura de NNAPI delimitan la interpretación. Registrar población, región, versión y fecha evita convertir un piloto, una cifra de la empresa o una oferta inicial en garantía universal de disponibilidad, impacto o retorno.

ML Drift acelera con fallback disponible. La API CompiledModel usa OpenCL cuando está disponible, OpenGL como alternativa y puede caer a CPU cuando el dispositivo no ofrece una GPU utilizable. La evidencia mínima incluye modelo, formato, versión, dispositivo, API, acelerador, fallback, latencia, memoria, tamaño, salida, error, energía y rollback. Guardar versión y configuración evita comparaciones incompatibles y ayuda a explicar de dónde procede una mejora. La adopción debe comenzar con una línea base y criterios de salida. El objetivo es una inferencia local más ligera y mantenible que preserve calidad y pueda retroceder ante regresiones por dispositivo. Una demostración convincente no reemplaza medidas sobre calidad, carga humana, exclusiones y errores. La evidencia debe permitir comparar el estado anterior con el resultado real después del cambio.

La cobertura incluye móviles relojes y automóviles. El servicio funciona desde Android 7 y se amplía a Wear OS 4 y Android Automotive desde Android 11, con actualizaciones escalonadas mediante Play services. Los límites relevantes son cifras de pruebas propias, fragmentación de hardware, disponibilidad de GPU, actualizaciones escalonadas, APIs obsoletas y retirada futura de NNAPI. Deben aparecer en diseño, contrato y seguimiento; lo que queda fuera se registra como pendiente. Toda integración necesita un camino negativo además del recorrido ideal. Hay que probar datos incompletos, conflictos, denegaciones y situaciones ambiguas. Esos casos muestran si modelo, formato, versión, dispositivo, API, acelerador, fallback, latencia, memoria, tamaño, salida, error, energía y rollback sigue disponible cuando el sistema debe detenerse, pedir ayuda o explicar una limitación sin inventar certeza.

Android Studio ofrece una migración asistida. La herramienta @litert-runtime de Android Studio puede reescribir llamadas Interpreter y configurar aceleración, aunque Google pide revisar el diff y probar en hardware real. Una prueba útil combina caso normal, excepción y recuperación. El responsable verifica la salida y relee el destino antes de aceptar una acción. La participación de usuarios y especialistas debe modificar decisiones, no decorar el lanzamiento. Si aparecen cifras de pruebas propias, fragmentación de hardware, disponibilidad de GPU, actualizaciones escalonadas, APIs obsoletas y retirada futura de NNAPI, el equipo necesita reducir alcance, corregir el diseño y conservar trazas. La capacidad de retroceder convierte la supervisión en una función operativa y no en una intención.

Lectura Goatify para una dependencia compartida. Las APIs del delegado GPU y delegados personalizados quedan obsoletas, mientras Google anuncia la retirada de NNAPI a partir de 2027. El resultado buscado es una inferencia local más ligera y mantenible que preserve calidad y pueda retroceder ante regresiones por dispositivo. Goatify une diagnóstico, piloto y decisión con trazas para avanzar, corregir o detenerse. La oportunidad para Goatify es traducir la noticia en una inferencia local más ligera y mantenible que preserve calidad y pueda retroceder ante regresiones por dispositivo. Eso exige diagnóstico, prueba y readback. El cliente recibe una recomendación que distingue hechos publicados, supuestos locales y condiciones para avanzar, de forma que la novedad se convierta en una decisión responsable.