Google HEIR hace compilable la inferencia privada, pero no automáticamente práctica
El compilador HEIR de Google puede traducir varios modelos a computación cifrada, pero la expansión del texto cifrado, la memoria, la latencia y los cambios del modelo siguen siendo decisivos.
Google ha presentado HEIR como una ruta desde un modelo ordinario de aprendizaje automático hasta la inferencia sobre entradas cifradas. El compilador de código abierto es real, sus cuatro demostraciones públicas cubren cargas de trabajo útiles y su diseño abarca varios esquemas criptográficos y backends de software.
No es un interruptor que vuelva privado cualquier modelo. La documentación actual de HEIR todavía exige decisiones de ingeniería sobre operadores, aproximaciones numéricas, disposición del texto cifrado, parámetros de cifrado, backends, claves y hardware. La demostración de Google comunica mediciones de CPU monohilo para sus ejemplos y dice que los resultados de latencia con aceleradores llegarán más adelante. Eso convierte a HEIR en una ruta de prototipado creíble, no en evidencia de que un modelo arbitrario vaya a cumplir un objetivo de nivel de servicio en producción.
La separación importante está entre la necesidad de privacidad y la viabilidad del sistema. El cifrado homomórfico completo (FHE) solo importa cuando elimina una exposición de entrada que la aplicación realmente tiene; HEIR solo importa cuando el modelo encaja en su ruta de compilación. El tiempo de evaluación cifrada, la memoria, el tráfico de textos cifrados, la precisión, la gestión de claves y la recuperación ante fallos determinan entonces si esa ganancia de privacidad es viable con la carga de trabajo prevista. Tratar estos aspectos como preguntas separadas evita que un requisito de privacidad se convierta silenciosamente en un proyecto de infraestructura sin límites.
HEIR cambia el problema del compilador, no la ecuación de costes
El cifrado ordinario de transporte y almacenamiento protege los datos mientras se mueven o están en reposo, pero un servicio suele descifrarlos antes de calcular sobre ellos. FHE utiliza esquemas de cifrado especiales que permiten a un servidor evaluar operaciones compatibles sobre el texto cifrado. El cliente descifra el texto cifrado devuelto para recuperar el resultado correspondiente, mientras que el servidor que realiza la evaluación no necesita la clave secreta ni la entrada en texto plano.
Esa propiedad puede eliminar un punto de exposición importante. Un recomendador, por ejemplo, podría puntuar características cifradas de usuarios sin que el servicio de puntuación las vea. No protege todas las partes del producto. Los endpoints del cliente, las claves, los registros, las actualizaciones del modelo, el preprocesamiento en texto plano, las respuestas devueltas, el control de acceso y los canales laterales requieren su propio diseño. La salida también puede revelar información sensible si la aplicación formula una pregunta insegura.
HEIR aborda la difícil traducción intermedia. Su diseño de aprendizaje automático lleva representaciones de modelos desde rutas relacionadas con PyTorch, TensorFlow y ONNX a MLIR, un framework de compilación con varios niveles de representación intermedia. La canalización marca los datos secretos, selecciona un esquema criptográfico y un backend, sustituye o aproxima operaciones que no se mapean limpiamente a la aritmética cifrada, elige disposiciones de textos cifrados, gestiona el crecimiento del ruido, selecciona parámetros y emite código para una biblioteca o una ruta de hardware de nivel inferior.
El compilador puede automatizar gran parte de ese trabajo, pero el propietario de la aplicación sigue aportando decisiones que cambian la corrección y el coste. La configuración de ejemplo de HEIR incluye el grado de aproximación y el rango de entrada de una activación no lineal. Si eliges un rango que no coincide con los datos de producción, un programa cifrado que por lo demás sea válido puede perder calidad de modelo. Si eliges un circuito más profundo o caro, la latencia, el tamaño del texto cifrado, el material de claves o la memoria pueden superar el presupuesto de despliegue.
Cuatro demostraciones delimitan el alcance, no la preparación universal
El anuncio de Google del 14 de agosto señala cuatro demostraciones compiladas: recomendación de contenidos, detección de fraude con tarjetas de crédito, detección de anomalías de red y reconocimiento de palabras de activación. El repositorio público de demostraciones hace más concreto el límite.
El ejemplo de fraude compila un perceptrón multicapa pequeño con activaciones sigmoides a CKKS, un esquema para aritmética de números aproximados, y expone rutas de evaluación con Lattigo y OpenFHE. Los ejemplos de recomendación y palabra de activación advierten que sus ejecuciones pueden necesitar al menos 96 GiB de RAM. El modelo de palabra de activación es una red convolucional temporal compacta, no un modelo general de voz o lenguaje. El ejemplo de red incluye detectores de anomalías con cinco y 50 características y un arnés de medición que separa el cifrado, la evaluación y el descifrado.
Son artefactos útiles porque un equipo puede inspeccionar los modelos, las rutas de datos, los objetivos de compilación y el código de medición. Siguen siendo demostraciones elegidas por tener estructuras compatibles. El artículo de Google dice que las cifras de latencia publicadas utilizan un único hilo de CPU y que el equipo planea mostrar más adelante los beneficios de latencia de los aceleradores. No publica un benchmark de producción entre backends, una prueba de servicio concurrente, un objetivo de disponibilidad ni una comparación del coste total.
Las palabras importan. Estos ejemplos demuestran que HEIR puede compilar y ejecutar varios programas de inferencia cifrada no triviales. No demuestran que la misma canalización admita todos los operadores de un transformer, que un backend demostrado encaje en el hardware de un equipo ni que un servicio FHE sea más barato que mantener la carga de trabajo local. Una nota actual de introducción a HEIR también indica que todavía se está desarrollando un binario de extremo a extremo para flujos como convertir un modelo Torch precompilado a un backend; mientras tanto, la ruta documentada utiliza las herramientas de nivel inferior heir-opt y heir-translate.
La aritmética limita el backend
Un esquema FHE define la aritmética cifrada disponible para el programa. Un backend implementa ese esquema. Son decisiones vinculadas, no nombres de paquetes intercambiables.
| Propiedad de la carga | Familia de esquemas candidata | Rutas de bibliotecas HEIR documentadas actualmente | Pregunta del prototipo que puede detener el trabajo |
|---|---|---|---|
| Aritmética entera o modular exacta | BGV o BFV | OpenFHE o Lattigo | ¿Se pueden representar todas las comparaciones, búsquedas y etapas no lineales sin cambiar silenciosamente el modelo? |
| Inferencia aproximada de números reales | CKKS | OpenFHE o Lattigo | ¿El error de aproximación permanece dentro del control de calidad de la tarea en rangos de entrada reales? |
| Circuitos booleanos o de enteros cortos | CGGI | tfhe-rs o Jaxite | ¿La profundidad del circuito y la frecuencia de bootstrap encajan en el presupuesto de latencia y hardware? |
| Ruta de investigación orientada al hardware | IR de HEIR a nivel de esquema o inferior | Las integraciones con CPU, GPU, FPGA, ASIC o fotónica varían según el objetivo | ¿El objetivo es reproducible y está disponible, o solo existe como demostración de investigación o de un socio? |
Esta tabla es un mapa inicial derivado de las canalizaciones actuales de HEIR y de la documentación de backends, no una promesa de compatibilidad. El nombre de un esquema no establece la cobertura de operadores, la seguridad de los parámetros, la madurez del compilador ni la equivalencia de resultados entre bibliotecas. Fija el compilador, frontend, esquema, backend, conjunto de parámetros, modelo y artefacto generado exactos utilizados en la prueba.
La elección de versión necesita la misma disciplina. Al comprobarlo el 25 de agosto, el endpoint de última versión de GitHub identificaba v2026.08.11.dev0, pese al sufijo de estilo de desarrollo; el repositorio también ofrece una versión mensual del 1 de agosto y nightlies fechadas más nuevas. Ese nombre convierte “estable” en un atajo inseguro. Selecciona deliberadamente una etiqueta y un commit probados. “Último” no es una dependencia reproducible.
La privacidad tiene que justificar la factura del texto cifrado
FHE resulta más convincente cuando un servicio externo debe calcular sobre datos que no puede ver, la ejecución local no está disponible o no es aceptable y un enclave de hardware o un control organizativo no satisface el modelo de amenazas. El caso depende de qué campos permanecen cifrados, dónde vuelve el texto plano, quién conserva las claves y qué pueden revelar todavía los tiempos de solicitud, los metadatos, los errores y las salidas descifradas.
Si esos límites son imprecisos, ningún resultado favorable de latencia puede hacer que el sistema merezca la pena. La ejecución en el dispositivo, la minimización de datos, un modelo local más pequeño, la computación confidencial o un flujo dividido pueden satisfacer la misma necesidad con menos complejidad. El análisis del despliegue local de Qwen muestra por qué la memoria que aparece en un dispositivo no es lo mismo que la capacidad de inferencia utilizable; FHE añade una capa distinta, pero igualmente importante, de sobrecoste de representación y runtime.
Un operador no puede representar el sistema cifrado
El segundo control parte de una carga de trabajo pública o sintética pequeña que conserva las formas y los rangos del modelo de producción sin exponer datos sensibles. Compila primero la ruta útil más pequeña. Registra las operaciones no compatibles y los cambios del modelo como resultados, no como inconvenientes que ocultar.
Después mide todo el ciclo de vida de la solicitud:
| Medición | Registro mínimo | Decisión que protege |
|---|---|---|
| Calidad de la tarea | Métrica en texto plano, métrica cifrada, fallos por segmento y ajustes de aproximación | Evita publicar una ruta cifrada rápida que produzca un modelo materialmente distinto |
| Compilación y preparación | Tiempo de exportación del frontend, compilación, generación de parámetros, generación de claves y tamaño del artefacto | Expone trabajo que omite una cifra de inferencia en estado estable |
| Latencia | Cifrado del cliente, transferencia, evaluación del servidor, transferencia de vuelta y descifrado del cliente; p50 y p95 | Separa la fase cara y conserva el presupuesto visible para el usuario |
| Rendimiento | Solicitudes por segundo con concurrencia y tamaño de lote declarados | Evita convertir una demostración monohilo en una previsión de capacidad |
| Memoria | Memoria residente máxima, claves de evaluación, claves de rotación o bootstrap, artefactos del modelo y búferes de texto cifrado | Comprueba si el host objetivo puede ejecutar y recuperar el servicio |
| Expansión de datos | Bytes de texto plano, bytes de texto cifrado enviados y devueltos y bytes temporales | Hace visibles los costes de red y almacenamiento |
| Operaciones | Recuentos de sumas, multiplicaciones, rotaciones, comparaciones, bootstraps y conversiones de disposición | Localiza la característica del circuito que controla el coste |
| Fiabilidad | Tiempos de espera, entradas malformadas, fallos de precisión, reintentos, rotación de claves y tiempo de reversión | Comprueba si el sistema es operable, no solo ejecutable |
La memoria merece su propio control. El preprint independiente KeyMemRT de 2026 identifica las claves de rotación como un consumidor importante de memoria en aplicaciones FHE complejas y prueba un enfoque de compilador/runtime para gestionar su ciclo de vida. Sus mejoras comunicadas pertenecen a sus propias configuraciones y no deben transferirse a un servicio HEIR. El hallazgo general sigue siendo útil: el material de claves y la memoria de runtime forman parte del diseño del sistema, no son metadatos criptográficos despreciables.
Los resultados de hardware necesitan una atribución igual de estricta. Un benchmark de acelerador puede mostrar qué logró un circuito, esquema, conjunto de parámetros, revisión del compilador, dispositivo, estrategia de lotes y precisión concretos. No puede aportar la fila de latencia de otro modelo. El análisis de inferencia en el borde de Waymo (en español) plantea el mismo punto para TOPS: una cifra de aritmética máxima no resuelve el encaje de memoria, transferencia, temperatura, software o carga de trabajo.
Un prototipo exitoso aún puede terminar con “no desplegar”
Hay varios resultados útiles que quedan fuera de un servicio FHE de producción. El control de privacidad puede mostrar que el cálculo protegido es lo bastante pequeño como para aislarlo mientras el resto permanece local o usa cifrado ordinario. La prueba del compilador puede identificar una activación no compatible que se pueda sustituir y volver a entrenar sin perjudicar la calidad. El benchmark puede mostrar que el modelo funciona, pero que solo un flujo por lotes, no una API interactiva, encaja en el presupuesto. También puede mostrar que la memoria, la expansión del texto cifrado o las operaciones de claves superan el valor obtenido.
Ese último resultado no es un experimento fallido. La aportación de HEIR es hacer que una parte mayor de esta disyuntiva pueda inspeccionarse dentro de un framework de compilación compartido. El preprint de HEIR de 2025 presenta el proyecto como una plataforma para implementar, combinar y comparar técnicas de cifrado homomórfico en toda la pila. La demostración más reciente de Google muestra cómo esa plataforma puede alcanzar cargas de trabajo reconocibles de aprendizaje automático.
La incertidumbre restante pertenece a la aplicación, no al anuncio. HEIR solo obtiene una ruta de producción cuando el resultado cifrado sigue resolviendo la tarea y el sistema completo —no un único operador favorable— encaja en las restricciones de calidad, latencia, memoria, seguridad y recuperación.
Fuentes
- Google: How Google Is Making Private AI Practical with Homomorphic Encryption
- HEIR machine-learning compiler design
- HEIR getting-started guide
- HEIR compiler pipelines
- HEIR v2026.08.11.dev0 release
- Google fully homomorphic encryption demo repository
- HEIR: A Universal Compiler for Homomorphic Encryption
- KeyMemRT: Unlocking Memory-Scalable FHE