- ONNX Runtime y Windows ML integran la ejecución de modelos ONNX en Windows 11, unificando CPU, GPU y NPU.
- WinML automatiza la selección de Execution Providers y simplifica el despliegue, manteniendo APIs compatibles con ONNX Runtime.
- La ejecución local en Windows 11 aporta privacidad, baja latencia y ahorro de costes frente a la nube.
- Herramientas como AI Toolkit, ONNX Model Zoo y los EPs de AMD, Intel, NVIDIA y Qualcomm facilitan conversión, optimización y soporte de hardware.
Windows 11 ha cambiado por completo la forma en la que ejecutamos modelos de IA en el PC, pasando de depender casi siempre de la nube a poder correr inferencias complejas de manera local con un rendimiento muy serio. ONNX Runtime y Windows ML son el dúo clave en este salto: un entorno de ejecución optimizado y una capa de integración con el sistema operativo que se encargan de exprimir CPU, GPU y NPU (consulta las especificaciones de tu PC) sin que el desarrollador tenga que volverse loco con cada tipo de hardware.
Si estás pensando en desplegar modelos ONNX en equipos con Windows 11, ya sea para clasificación de imágenes, procesamiento de texto, reconocimiento de escritura o incluso modelos de lenguaje ligeros, tienes a tu disposición un ecosistema muy maduro: ONNX como formato estándar, ONNX Runtime como motor de inferencia multiplataforma y Windows ML como middleware que unifica y automatiza el uso de los aceleradores disponibles en cada máquina.
Qué es ONNX y qué papel juega ONNX Runtime
ONNX (Open Neural Network Exchange) es un formato abierto pensado para describir modelos de aprendizaje automático de forma que puedan moverse entre distintos frameworks y ejecutarse en todo tipo de hardware. Un modelo ONNX encapsula la arquitectura de la red (capas, conexiones, operaciones), los pesos entrenados y la definición de las entradas y salidas que acepta.
Gracias a ONNX es posible, por ejemplo, entrenar un modelo en PyTorch o TensorFlow y luego exportarlo a un archivo .onnx que podrás ejecutar en cualquier entorno compatible. Este enfoque basado en un estándar común evita atarse a un framework concreto y facilita muchísimo el despliegue en producción, sobre todo cuando se quiere reutilizar el mismo modelo en distintos dispositivos.
ONNX Runtime es el motor de inferencia oficial para este formato, una biblioteca optimizada que acelera la ejecución de modelos en CPUs, GPUs y aceleradores específicos como NPUs. Es multiplataforma (Windows, Linux, macOS, edge, incluso navegadores en ciertos escenarios) y soporta modelos procedentes no solo de ONNX puro, sino también de frameworks como PyTorch, TensorFlow/Keras, TFLite o scikit-learn mediante conversiones.
Una de las grandes bazas de ONNX Runtime es su sistema de Execution Providers (EPs), pequeños “bridges” que conectan el runtime con distintos backends de hardware. Hay EPs para CPU, DirectML, CUDA, TensorRT, OpenVINO, Qualcomm NN y otros, cada uno especializado en sacar partido a un tipo de chip o conjunto de chips concreto.
Todo este ecosistema se complementa con un control muy cuidado de versiones y opsets, de forma que los modelos no se queden obsoletos de un día para otro. ONNX mantiene compatibilidad hacia atrás y una representación basada en grafos, lo que simplifica la interoperabilidad entre frameworks y la optimización posterior del modelo.
Windows ML: la capa que integra ONNX Runtime en Windows 11
Windows ML (WinML) es el middleware que Microsoft ha creado para integrar ONNX Runtime dentro del propio sistema operativo y ofrecer a los desarrolladores una API coherente para ejecutar modelos de IA en Windows 10 (a partir de 1809) y, especialmente, en Windows 11.
La gracia de Windows ML es que trata CPU, GPU y NPU como un conjunto de recursos unificados (incluso en Windows con ARM y NPU), en lugar de obligarte a gestionar cada chip por separado. En la práctica, esto significa que el sistema puede decidir automáticamente dónde ejecutar cada parte del modelo para lograr el mejor rendimiento, teniendo en cuenta la presencia (o no) de NPU, la potencia de la GPU y la carga de la CPU.
En Windows 11, y más aún a partir de la versión 24H2, Microsoft recomienda claramente WinML como vía principal para usar ONNX Runtime. WinML se encarga de la distribución y el mantenimiento de la copia compartida de ONNX Runtime incluida en el sistema, así como de los Execution Providers que permiten hablar con hardware de AMD, Intel, NVIDIA o Qualcomm.
Desde el punto de vista del desarrollador, WinML está disponible como API WinRT en el espacio de nombres Windows.AI.MachineLearning, embebida en la DLL Microsoft.Windows.AI.MachineLearning.dll. Además, a través del Windows App SDK y paquetes NuGet dedicados, puedes usar la misma superficie de API de ONNX Runtime dentro de tus aplicaciones sin tener que empaquetar todas las dependencias manualmente.
WinML también ofrece automatismos que marcan la diferencia, como la selección dinámica del Execution Provider más adecuado según el hardware del usuario. Por supuesto, si lo necesitas, puedes forzar o ajustar esa selección de manera explícita para casos avanzados.
Ventajas de ejecutar modelos ONNX en local en Windows 11
Usar ONNX Runtime y Windows ML para ejecutar modelos en local sobre Windows 11 tiene ventajas muy claras frente a depender siempre de la nube. La primera y más evidente es la privacidad: los datos no salen del equipo del usuario, algo fundamental cuando se trabaja con información sensible o regulada.
Además de la privacidad, la ejecución local reduce la latencia de forma drástica, ya que desaparecen los viajes de ida y vuelta a servidores remotos. Esto es clave en aplicaciones interactivas, asistentes inteligentes de escritorio, herramientas creativas o cualquier escenario que exija respuestas inmediatas incluso en hardware modesto.
Otro punto a favor es la capacidad de funcionar sin conexión. Con los modelos y el runtime instalados en el dispositivo, tu aplicación puede seguir ejecutando inferencias aunque no haya acceso a Internet: útil durante viajes, en entornos industriales aislados o simplemente como medida de resiliencia frente a cortes de red.
Desde el punto de vista económico, prescindir de servicios cloud continuos reduce costes, especialmente en escenarios con muchos dispositivos o uso intensivo. En lugar de pagar por inferencias en un servidor remoto, aprovechas la potencia ya disponible en el parque de PCs de la organización.
Por último, trabajar con modelos ONNX en local te da un control total sobre el pipeline: puedes adaptar el preprocesado, postprocesado, cuantizar modelos para aligerarlos, cambiar de EP según el hardware y actualizar la versión de ONNX Runtime cuando te interese, sin depender de cambios externos en una API de terceros.
Integración de ONNX Runtime en Windows ML: APIs y modos de uso
Windows ML incluye una copia compartida de ONNX Runtime con sus API completas, lo que permite que una app que instale el SDK correspondiente acceda tanto a las APIs clásicas de WinML como a la superficie de ONNX Runtime que ya conozcas de otros entornos.
En Python, por ejemplo, el módulo se importa exactamente igual que cuando usas ONNX Runtime puro, simplemente con import onnxruntime as ort. Esto significa que tu código de inferencia puede ser prácticamente idéntico tanto en Windows ML como en otros sistemas, con la ventaja añadida de que Windows se encarga de los detalles de hardware cuando se usa WinML.
En .NET (C#, VB.NET, etc.) la forma más habitual de trabajar es mediante paquetes NuGet como Microsoft.ML.OnnxRuntime o Microsoft.ML.OnnxRuntime.DirectML. El primero permite ejecutar modelos en CPU y otros EPs estándar; el segundo integra el Execution Provider DirectML para aprovechar la GPU y otros aceleradores compatibles con esta capa.
WinML, por su parte, ofrece una API WinRT que se puede consumir desde C#, C++/WinRT y otros lenguajes soportados, con tipos específicos para modelos, sesiones de inferencia y bindings de entrada/salida. Además, existe una versión redistribuible de WinML que puedes empaquetar junto a tu aplicación en escenarios en los que la versión de Windows instalada no incluya la variante que necesitas.
Si lo prefieres, también es posible usar directamente la C API de ONNX Runtime en Windows, en lugar de la API WinRT, algo especialmente interesante para aplicaciones nativas de alto rendimiento o cuando quieras incluir tu propia compilación personalizada del runtime. De hecho, el propio paquete WinRT puede convivir con una versión de onnxruntime.dll que tú aportes, siempre que la sustituyas con cuidado.
Requisitos previos y opciones de despliegue en Windows 11
Para aprovechar al máximo ONNX Runtime y Windows ML en Windows 11 conviene tener claro qué SDKs y versiones del sistema necesitas, y realizar un diagnóstico de fallos de hardware previo en equipos con comportamiento errático.
En Windows 10 (1809+) y Windows 11 antes de la versión 24H2 puedes usar ONNX Runtime sin problema, aunque tendrás que gestionar de forma más manual la selección del Execution Provider y la configuración de modelos y dependencias. Aun así, la integración con DirectML ya te permite aprovechar la GPU en muchos equipos.
En Windows 11 24H2 y posteriores, WinML sube varios peldaños en automatización, gestionando de forma más inteligente la elección del EP ideal según el hardware instalado (CPU, GPU, NPU) y la presencia de EPs proporcionados por partners como AMD, Intel, NVIDIA o Qualcomm. Para cubrir todo el ecosistema de silicio, esta combinación de WinML + ONNX Runtime es la opción recomendada.
En cuanto al desarrollo, en .NET lo habitual es contar con Visual Studio 2022 o posterior y el Windows App SDK (por ejemplo, 1.3+ en escenarios de WinUI 3). Para proyectos WinUI 3 empaquetados (MSIX), basta con añadir la referencia al paquete Microsoft.AI.MachineLearning si vas a usar la API WinML, o a los paquetes de ONNX Runtime que necesites si prefieres esa ruta.
Para escenarios de escritorio clásicos, WinUI 3 o aplicaciones empaquetadas con MSIX, el soporte es muy bueno. También existe compatibilidad hacia atrás con Windows 8.1+ en ciertas combinaciones de runtime, aunque si tu foco es exprimir el hardware moderno, lo lógico es centrar el objetivo en Windows 11 24H2 o superior.
Ejemplo práctico: ejecutar un modelo ONNX en .NET con GPU en Windows 11
Una forma muy directa de ver el potencial de ONNX Runtime en Windows 11 es crear una aplicación de escritorio que clasifique imágenes usando un modelo ONNX conocido como ResNet50. En este escenario, la app permite al usuario elegir una foto, la muestra en pantalla y lista los objetos detectados con su probabilidad.
Puedes crear un proyecto WinUI 3 en C#, tipo “Aplicación vacía, empaquetada (WinUI 3 en escritorio)” y llamarlo, por ejemplo, ONNXWinUIExample. Tras crear el proyecto, el siguiente paso es añadir los paquetes NuGet necesarios:
- Microsoft.ML.OnnxRuntime.DirectML, que suministra las API para ejecutar modelos ONNX sobre la GPU vía DirectML.
- SixLabors.ImageSharp, que facilita el preprocesado de imágenes (redimensionar, normalizar, etc.).
- SharpDX.DXGI, que permite descubrir y manipular dispositivos DirectX desde C#.
Una vez instalados los paquetes, se incorporan las directivas using al archivo MainWindow.xaml.cs para acceder a estas APIs: Microsoft.ML.OnnxRuntime, Microsoft.ML.OnnxRuntime.Tensors, SharpDX.DXGI y los espacios de nombres de ImageSharp. Con esto ya puedes empezar a configurar la sesión de inferencia.
El modelo ONNX (por ejemplo, resnet50-v2-7.onnx) se descarga desde el repositorio oficial de modelos ONNX y se copia a una carpeta del proyecto, como model. En las propiedades del archivo se indica “Copiar al directorio de salida: Copiar si es más reciente” para que esté disponible en tiempo de ejecución junto al ejecutable.
La interfaz de usuario puede ser muy sencilla: un botón para seleccionar una foto, un control Image para mostrarla y un TextBlock para enseñar las predicciones. En el XAML principal basta con definir un Grid con tres columnas y ubicar ahí estos controles, asignando el evento de clic del botón a un manejador denominado, por ejemplo, myButton_Click.
Inicialización de la sesión de inferencia con DirectML
El corazón del ejemplo es la inicialización de la sesión de inferencia, que se hace en un método auxiliar tipo InitModel. Este método comprueba primero si la sesión ya está creada para evitar hacerlo más de una vez y, si no existe, procede a seleccionar un adaptador gráfico y a configurar las opciones de sesión.
Con la biblioteca SharpDX.DXGI se crea un objeto Factory1 y se obtiene el primer adaptador disponible (por ejemplo, el índice 0). A continuación se instancia un objeto SessionOptions, se establece el nivel de logging deseado y se llama a AppendExecutionProvider_DML(deviceId) para vincular la sesión con el proveedor DirectML asociado a ese dispositivo gráfico.
Finalmente se construye la InferenceSession pasando la ruta del modelo ONNX y las opciones configuradas. A partir de ese momento, todas las inferencias que realice la app aprovecharán la GPU (u otro acelerador soportado por DirectML) de forma casi transparente, manteniendo el control fino si fuese necesario.
Esta separación entre inicialización (InitModel) y ejecución concreta es importante para el rendimiento, ya que evita recrear la sesión cada vez que el usuario selecciona una nueva imagen. Lo habitual es inicializar una única sesión por modelo y reutilizarla a lo largo de toda la vida de la aplicación.
Preprocesado de imágenes y ejecución del modelo
En el manejador del botón, lo primero es permitir al usuario elegir una imagen utilizando un FileOpenPicker, restringido a extensiones típicas como .jpg, .jpeg, .png o .gif. Una vez seleccionado el archivo (o cancelado, en cuyo caso el proceso se detiene), se muestra la foto en la interfaz mediante un BitmapImage.
Después llega el preprocesado: se abre el archivo como flujo, se detecta el formato con ImageSharp y se carga en una estructura de imagen con píxeles RGB de 24 bits. A continuación se redimensiona a 224×224 píxeles, que es el tamaño de entrada esperado por ResNet50, utilizando un modo de recorte para mantener la relación de aspecto lo mejor posible.
El siguiente paso es normalizar los píxeles siguiendo los parámetros con los que se entrenó el modelo. Se redimensiona a 224×224 píxeles y se definen los vectores de medias y desviaciones estándar (por ejemplo, 255 * y 255 * ) para rellenar un DenseTensor<float> con forma .
Con el tensor ya preparado, se crea un OrtValue que apunta directamente al buffer del DenseTensor usando CreateTensorValueFromMemory, evitando copias adicionales dentro de ONNX Runtime. Este OrtValue se inserta en un diccionario de entradas asociándolo con el nombre de input del modelo (por ejemplo, «data»).
Antes de ejecutar, se comprueba que la sesión de inferencia está inicializada y, si no, se llama a InitModel. A continuación se crea un objeto RunOptions y se llama a _inferenceSession.Run pasando las opciones, el diccionario de entradas y la colección de nombres de salida de la sesión. El resultado es una colección inmutable de OrtValue con los tensores de salida.
Postprocesado: softmax, labels y visualización de resultados
El modelo ResNet50 devuelve sus predicciones como un tensor con logits, es decir, valores sin normalizar que conviene transformar a probabilidades. Para ello se extrae el buffer de salida como un Span<float> y se copia a un array de floats sobre el que se aplican operaciones estándar de LINQ o bucles clásicos.
Para obtener probabilidades se calcula una función softmax: se suman las exponenciales de todos los logits y se divide la exponencial de cada uno entre esa suma, consiguiendo valores en el rango que, juntos, suman 1. El resultado es un conjunto de probabilidades asociadas a las distintas clases con las que se entrenó el modelo.
El índice de cada posición de la salida se corresponde con una etiqueta de clase predefinida. Estas etiquetas se suelen agrupar en una clase auxiliar, por ejemplo LabelMap, que expone un array estático de cadenas (Labels) en el orden correcto. Esa clase puede copiarse de los ejemplos oficiales de ONNX Runtime en GitHub, donde se listan categorías como «tench», «goldfish», «great white shark», y así hasta cientos de entradas.
Para facilitar el manejo de resultados, es habitual definir otra clase sencilla, tipo Prediction, con propiedades Label y Confidence. A partir del array de probabilidades se genera una secuencia de Prediction asociando el índice con la etiqueta y el valor con la probabilidad, y se ordena de mayor a menor confianza para extraer, por ejemplo, el top 10 más probable.
Finalmente, la aplicación puede imprimir estas predicciones en el TextBlock de la interfaz, añadiendo líneas del estilo «Label: X, Confidence: Y». El usuario verá así qué objetos detecta el modelo en su imagen y con qué nivel de seguridad lo hace, sin necesidad de entender nada de tensores ni de ONNX por debajo.
Uso de Windows ML y WinUI 3 con modelos ONNX
Más allá del ejemplo con ONNX Runtime directo, Windows 11 ofrece una forma muy cómoda de integrar modelos ONNX en aplicaciones modernas mediante Windows ML y WinUI 3. En este enfoque, la aplicación usa el paquete NuGet Microsoft.AI.MachineLearning para cargar el modelo, preparar las entradas y ejecutar la inferencia de manera nativa.
El flujo general suele ser: crear un proyecto WinUI 3 empaquetado, añadir el paquete de Windows ML, copiar el modelo ONNX a una carpeta como Assets/ML y marcarlo para que se copie al directorio de salida. A partir de ahí, se construye el objeto de modelo desde el archivo y se crea una sesión o binding para gestionar las entradas y salidas.
Un punto interesante de WinML es su capacidad para trabajar directamente con tipos del propio sistema, como Windows.Media.VideoFrame. Esto permite, por ejemplo, pasar frames en tiempo real de la cámara del dispositivo directamente al modelo, sin tener que hacer conversiones extrañas ni copias innecesarias entre buffers.
En escenarios de clasificación de imágenes sencillos, como un modelo MNIST de 28×28 píxeles en escala de grises, el preprocesado se reduce a rellenar un tensor con valores normalizados y a construir la estructura de entrada adecuada para la sesión de WinML. El resultado será normalmente un vector de probabilidades para cada clase (0-9) del que se toma el índice con valor máximo.
WinML se apoya en DirectML y en los EPs de ONNX Runtime para decidir cómo y dónde ejecutar el modelo, pero lo hace de forma bastante automática: si hay GPU o NPU disponibles, las utilizará, y si no, tirará de CPU. También puedes consultar información sobre el dispositivo que está usando en cada momento para tu propia telemetría o para adaptar el comportamiento de la app.
Soporte de hardware: AMD, Intel, NVIDIA, Qualcomm y NPUs
Microsoft ha trabajado directamente con los principales fabricantes de chips para que Windows ML y ONNX Runtime saquen partido a las últimas generaciones de hardware. Cada proveedor mantiene su propio Execution Provider optimizado, que es distribuido y registrado por Windows ML para facilitar la vida al desarrollador.
AMD integra soporte de Windows ML en la plataforma Ryzen AI, con un EP capaz de aprovechar NPU, GPU y CPU de sus procesadores. Esto permite que los modelos ONNX puedan escalar entre aceleradores según el tipo de carga, sin tener que escribir código específico para cada uno.
Intel combina su stack OpenVINO con Windows ML para permitir que los PCs con procesadores Intel Core Ultra seleccionen entre CPU, GPU o NPU según convenga. OpenVINO aporta optimizaciones muy agresivas en inferencia, que se exponen de forma integrada dentro del ecosistema WinML.
NVIDIA, por su parte, ofrece TensorRT for RTX como Execution Provider para ONNX Runtime. En equipos con GPUs GeForce RTX o RTX PRO, esto permite generar motores de inferencia altamente optimizados para cada sistema, mejorando tiempos de respuesta y reduciendo el consumo de recursos en comparación con soluciones más genéricas.
Qualcomm y Microsoft han colaborado para exprimir las NPUs de la serie Snapdragon X, utilizando el EP Qualcomm Neural Network para la NPU y completándolo con GPU y CPU mediante integración con los EPs estándar de ONNX Runtime. Esto es especialmente relevante en dispositivos Windows on ARM pensados para autonomía y trabajo en movilidad.
Conversión de modelos y herramientas de desarrollo
Para llegar a tener un modelo ONNX funcionando en Windows 11 lo primero es, claro, disponer de ese modelo. Puedes recurrir al ONNX Model Zoo, que ofrece modelos preentrenados para tareas como clasificación de imágenes, detección de objetos, NLP o generación de texto, entre otros.
Otra opción muy habitual es convertir tus propios modelos desde frameworks de entrenamiento como PyTorch o TensorFlow, usando herramientas como torch.onnx.export, tf2onnx o utilidades específicas de ONNX Runtime (onnxruntime-tools), que permiten exportar redes neuronales completas al formato ONNX manteniendo su estructura y pesos.
En el contexto de Windows, Microsoft ofrece el AI Toolkit para VS Code, un conjunto de herramientas que centraliza la conversión a ONNX desde PyTorch, la cuantización para reducir tamaño y consumo, la optimización y compilación del modelo y su evaluación antes del despliegue. Todo ello orientado a que el modelo quede listo para ejecutarse de forma eficiente con Windows ML.
También puedes encontrar recursos prácticos en la AI Dev Gallery, un espacio donde se muestran escenarios de uso reales y ejemplos que te permiten experimentar con modelos personalizados en local sobre Windows ML, sin tener que reinventar todo el pipeline cada vez.
Casos de uso habituales de ONNX Runtime en Windows 11
Con toda esta infraestructura, es fácil imaginar aplicaciones reales que se beneficien de ONNX Runtime en Windows 11. La más inmediata es la clasificación de imágenes: desde apps que etiquetan fotos de producto hasta herramientas que reconocen documentos o clasifican contenido multimedia archivado.
La detección de anomalías locales es otro escenario muy interesante, por ejemplo en software de monitorización que analiza métricas en tiempo real en el propio PC o en entornos edge sin conexión. En lugar de enviar datos crudos a la nube, el modelo ONNX puede evaluar en local y solo notificar cuando haya algo realmente relevante.
También hay mucho margen para asistentes inteligentes offline, integrados en aplicaciones de productividad o flujos de trabajo específicos de empresa. Aunque los grandes modelos de lenguaje completos suelen requerir más recursos, versiones ligeras o especializadas pueden ejecutarse con éxito a través de ONNX Runtime.
Otros casos típicos incluyen modelos de NLP ligeros para análisis de texto, reconocimiento de escritura o dígitos (como MNIST), mejoras de imagen con redes neuronales (por ejemplo, filtros inteligentes) o incluso inferencias combinadas en aplicaciones multimedia avanzadas.
En todos estos escenarios, la ejecución local reduce la dependencia de servicios externos y te permite ofrecer una experiencia muy fluida al usuario, especialmente cuando el hardware cuenta con GPU o NPU modernas que Windows ML puede aprovechar automáticamente.
