npunlock abre las NPU de Intel a kernels C propios, de momento en Meteor Lake
El proyecto open source compila C a código máquina ACT-SHAVE y lo ejecuta dentro de grafos NPU, algo que la pila pública de Intel no permite. Verificado sobre NPU3720.
npunlock es un proyecto open source que abre las SHAVE programables que Intel esconde dentro de sus NPU y que su pila pública no deja tocar. Con él se compila C propio a código máquina ACT-SHAVE y se mete dentro de un grafo NPU como una operación más, conservando el compilador y el driver de Intel para el resto del grafo.
El repositorio acaba de registrar un avance: un único grafo nativo puede ejecutar a la vez ramas personalizadas independientes, una FP32 unaria y otra FP16 binaria. El autor lo ha resuelto con un preflight explícito de ACT-group que se ocupa del reordenado de ramas que hacía el compilador. La implementación está verificada en Windows x64 sobre Meteor Lake y el NPU3720.
El punto de partida es conocido para quien haya peleado con esto: Intel expone programación a nivel de grafo, con las operaciones que su compilador acepta, pero no hay flujo público para entregar una implementación en C de una operación. Los procesadores ACT-SHAVE sí son programables y ejecutan software, y de ahí tira npunlock.
Qué se puede hacer hoy
El repositorio trae un ejemplo completo de GELU en FP32 escrito en C, embebido en Python, colocado en un grafo NPU y comparado contra una referencia de NumPy, que imprime el error absoluto máximo. Hay también ejemplos de GELU en FP16, de dos entradas con varias capas y un grafo de precisión mixta con ramas unarias y binarias. Entre lo que funciona ahora mismo: compilar C de usuario a máquina ACT-SHAVE, kernels densos estáticos FP16 unarios y de dos entradas, una ruta FP32 unaria verificada, matemáticas no lineales tipo GELU y tanhf, y buffers de entrada y salida compartidos entre host y NPU compatibles con NumPy. Las APIs disponibles son Python, CLI y C nativa.
Un detalle práctico: la cadena MoviTools que han probado deja la mayoría de funciones de libm al alcance del kernel sin incluir <math.h>, vía mlibm.a. El ejemplo llama a tanhf directamente.
El toolchain no viaja en el paquete
La compilación de C personalizado depende de MoviTools, la cadena de Intel/Movidius, que npunlock ni redistribuye ni descarga. El autor apunta a un paquete de driver antiguo de Lenovo, el 31.0.100.1688, del que se extrae el payload MVC_DEPEND. El aviso va en mayúsculas en la documentación: no hay que instalar ni bajar a ese driver, solo sacarle las herramientas.
El resto del stack pide Python 3.10 o superior, CMake 3.24, toolchain MSVC y el driver NPU de Intel instalado. OpenVINO no hace falta como runtime, paquete ni frontend, aunque la herramienta emita IR en su formato para el driver.
Los límites son los de una herramienta experimental: Windows x64, Meteor Lake y NPU3720, formas estáticas, carriers ACT compatibles y layouts de tensor conocidos. Los grupos conectados de conversión de precisión mixta todavía no se pueden descubrir parcheando, y otras generaciones de NPU no se han verificado.
El autor pide justamente eso, manos para probar Linux y NPUs más nuevas. La hipótesis es que un grafo parcheado en Windows podría correr en Linux, porque quien ejecuta el código máquina es el firmware de la NPU; compilar SHAVE en Linux requeriría además una forma de cargar las DLL de MoviTools de Windows. Para generaciones posteriores, cabe que ejecuten la misma imagen SHAVE 3720xx o que un paquete OEM antiguo aporte componentes compatibles. Sin hardware delante y comparación contra un oráculo en el host, nada de eso está comprobado.
