En este artículo
Muchas aplicaciones de IA local parecen estar ligadas a una sola marca de GPU. Sin embargo, la ejecución no depende únicamente del modelo, sino también de la forma en que ese modelo se conecta con el hardware disponible en el equipo. Ahí entran en juego ONNX, ONNX Runtime y los llamados Execution Providers.
ONNX proporciona una base estandarizada para los modelos de IA. ONNX Runtime carga y ejecuta esos modelos. Los Execution Providers conectan la Runtime con la CPU, la GPU o la NPU disponible. De este modo, una aplicación de IA local puede utilizar distintas rutas de ejecución en sistemas AMD, Intel y NVIDIA.
VANIV utiliza esta arquitectura para el procesamiento local de audio, voz y vídeo. En esta guía explicamos qué es ONNX, cómo funciona la conexión con el hardware y por qué la flexibilidad de hardware no significa que todos los ordenadores rindan igual.
¿Qué es ONNX? Un formato abierto para modelos de IA
Un formato común para modelos entrenados
Una forma sencilla de entender ONNX es imaginarlo como un formato común para modelos de IA entrenados. MP3 permite usar archivos de audio en muchas aplicaciones distintas. JPEG cumple una función parecida con las imágenes. ONNX aplica esa misma idea general a los modelos de IA, aunque técnicamente es mucho más complejo.
ONNX significa Open Neural Network Exchange. El formato define, entre otros elementos, el grafo de cálculo del modelo, sus operaciones, los tipos de datos y los parámetros almacenados. Por ejemplo, un modelo puede desarrollarse en PyTorch, exportarse a ONNX y ejecutarse después en una Runtime compatible.
La comparación con MP3 o JPEG ayuda a visualizar la idea, pero no es una equivalencia técnica. Un modelo de IA no es un simple archivo multimedia: contiene una estructura de cálculos, entradas y salidas definidas, además de pesos aprendidos durante el entrenamiento.
Un ejemplo sencillo con reconocimiento de voz
Imagina un modelo de reconocimiento de voz entrenado en un framework concreto. Sin un formato de intercambio adecuado, la aplicación final quedaría más ligada a ese framework y a su propia Runtime.
Después de exportarlo, el modelo se guarda como archivo ONNX. Una Runtime como ONNX Runtime puede cargarlo, recibir audio preparado como entrada y devolver texto reconocido u otro resultado que la aplicación utilizará en el siguiente paso.
La ventaja no es que ONNX elimine todos los límites técnicos. Su valor está en separar mejor el desarrollo del modelo de su ejecución posterior.
¿Quién está detrás de ONNX?
Microsoft y Facebook, hoy Meta, presentaron ONNX conjuntamente en 2017. El formato evolucionó hasta convertirse en un proyecto comunitario con gobernanza abierta bajo LF AI & Data.
Esto es importante porque ONNX no es un formato cerrado propiedad de un único fabricante de hardware. Su desarrollo es transversal y crea una base técnica compartida para distintos frameworks, runtimes y ecosistemas de hardware.
ONNX frente a los formatos nativos
PyTorch, TensorFlow y otros entornos de desarrollo tienen sus propios formatos y herramientas. Son importantes para entrenar modelos, experimentar y trabajar dentro del ecosistema de cada framework.
ONNX se creó como formato de intercambio. El modelo se entrena en su entorno original, se exporta a ONNX y después se ejecuta mediante una Runtime compatible.
ONNX no sustituye por completo al framework original. Añade una capa de ejecución más portable al proceso de desarrollo.
¿Tiene límites ONNX?
Sí. No todos los modelos pueden exportarse a ONNX sin ajustes. Los flujos de control dinámicos, los operadores personalizados o ciertos comportamientos específicos de un framework pueden dificultar la exportación y la ejecución posterior. El Execution Provider elegido también debe admitir los operadores necesarios o permitir una ruta alternativa.
ONNX tampoco acelera automáticamente un modelo. La versión del opset de ONNX, la versión de la Runtime y los operadores compatibles deben encajar entre sí. ONNX crea la base para una ejecución portable; el rendimiento real depende de la optimización del modelo, la Runtime, el hardware y el Execution Provider.
Esto no invalida la utilidad de ONNX. Simplemente significa que un formato común no puede resolver por sí solo todos los detalles de implementación.
Qué es ONNX y qué no es
| ONNX no es | ONNX sí es |
|---|---|
| una tarjeta gráfica u otro componente de hardware | un formato abierto para modelos de IA |
| una plataforma cloud | un puente entre desarrollo y ejecución |
| una aplicación de IA terminada | una base para inferencia portable |
| automáticamente un modelo de voz, imagen o vídeo | un componente importante de la IA flexible en hardware |
| una garantía de alto rendimiento | una base común para distintas runtimes |
ONNX por sí solo no ejecuta el modelo. Para eso hace falta una Runtime, que es la siguiente capa.
¿Qué es ONNX Runtime? Cómo se ejecutan los modelos de IA en tu hardware
El modelo y la Runtime no son lo mismo
El archivo ONNX contiene el modelo. ONNX Runtime es el entorno de ejecución que carga ese modelo y realiza los cálculos.
Una comparación sencilla:
El modelo ONNX es el plano. ONNX Runtime es la máquina que lee el plano y realiza el trabajo.
ONNX Runtime analiza y optimiza el grafo del modelo. Después ejecuta los cálculos mediante los Execution Providers disponibles. La aplicación aporta los datos de entrada y continúa procesando el resultado.
Un modelo de reconocimiento de voz paso a paso
¿Cómo funciona con un archivo de audio real?
- Cargar el modelo: ONNX Runtime carga el archivo ONNX con el modelo de reconocimiento de voz.
- Preparar el audio: La aplicación lee el archivo de audio y lo convierte al formato de entrada esperado.
- Ejecutar la inferencia: ONNX Runtime calcula la salida con ayuda de los Execution Providers disponibles.
- Generar el texto: El modelo devuelve texto reconocido o una salida intermedia a partir de la cual la aplicación genera la transcripción.
- Continuar el flujo: La aplicación utiliza el resultado para subtítulos, traducción u otra fase de procesamiento de voz.
Conviene separar estas tareas. La importación de audio, el preprocesamiento, la inferencia y el tratamiento posterior del texto son pasos distintos. Pueden utilizar modelos, bibliotecas y unidades de cálculo diferentes.
Por qué importa esta separación
El modelo, la Runtime, la conexión con el hardware y la interfaz de usuario permanecen como capas separadas. Esto permite:
- actualizar modelos sin modificar toda la interfaz
- integrar distintos Execution Providers
- utilizar la misma lógica de aplicación en varias plataformas de hardware
- optimizar el preprocesamiento y el posprocesamiento por separado
ONNX Runtime puede cargar y ejecutar un modelo. La siguiente pregunta es cómo llega el cálculo al hardware adecuado. Para eso existen los Execution Providers.
¿Qué es un Execution Provider? La conexión entre ONNX y CPU, GPU o NPU
Qué hace un Execution Provider
Un Execution Provider conecta ONNX Runtime con una plataforma de hardware o una tecnología de aceleración concreta.
ONNX Runtime analiza el grafo del modelo. Los Execution Providers registrados indican qué nodos o subgrafos pueden ejecutar. La Runtime asigna las partes compatibles. Las operaciones restantes pueden pasar a otro Provider o al CPU Execution Provider predeterminado.
Por tanto, un Execution Provider no es solo un nombre dentro de un archivo de configuración. Vincula la Runtime con kernels optimizados, gestión de memoria y hardware específico.
La analogía del adaptador universal
Puedes imaginar ONNX Runtime como un adaptador universal. El modelo se mantiene esencialmente igual, pero cambia la conexión con el hardware:
- CUDA o TensorRT para NVIDIA
- MIGraphX para AMD
- OpenVINO para Intel
- DirectML como ruta de Windows compatible con varios fabricantes
- ejecución por CPU como base amplia
La analogía explica el principio general. No significa que todos los Providers tengan las mismas funciones ni el mismo rendimiento.
¿Qué pasa si una operación no es compatible?
Si un Execution Provider no puede ejecutar una operación concreta, ONNX Runtime puede asignar las partes compatibles a otro Provider o continuar el resto por CPU.
La disponibilidad y el orden de los Providers forman parte de la configuración técnica de la aplicación. Como usuario de VANIV, trabajas con el flujo resultante mientras la asignación se realiza en segundo plano.
Comparativa entre CPU, GPU y NPU
| Unidad | Punto fuerte | Uso habitual en IA local | Límite importante |
|---|---|---|---|
| CPU | compatibilidad amplia y tareas flexibles | modelos pequeños, preprocesamiento, posprocesamiento y partes no aceleradas | suele ser más lenta en cargas muy paralelas |
| GPU | gran capacidad de cálculo paralelo | modelos de audio, voz, imagen y vídeo | VRAM, controladores y compatibilidad del Provider |
| NPU | inferencia eficiente energéticamente | portátiles, sistemas compactos y tareas en segundo plano | la compatibilidad de modelos y operadores varía |
Los Execution Providers establecen la base de una IA flexible en hardware. Ahora podemos ver cómo se aplica en NVIDIA, AMD e Intel.
ONNX en NVIDIA: CUDA y TensorRT para IA local
CUDA como ruta consolidada
El CUDA Execution Provider conecta ONNX Runtime con las GPU de NVIDIA. CUDA está muy extendido en el ecosistema de IA, por lo que muchos modelos y aplicaciones se optimizan primero para esta ruta.
Para quien ya dispone de una GPU NVIDIA, esto ofrece una vía madura respaldada por un gran ecosistema de software y desarrollo.
TensorRT como capa adicional
El TensorRT Execution Provider utiliza el motor de inferencia de NVIDIA para acelerar modelos ONNX compatibles en GPU NVIDIA. TensorRT es una capa de ejecución adicional y no debe confundirse con el formato ONNX.
Su utilidad depende del modelo, los operadores admitidos, la precisión utilizada y el trabajo de optimización necesario.
Qué significa para ti
Si tienes una tarjeta gráfica NVIDIA, dispones de una ruta ONNX muy extendida. Aun así, ONNX Runtime no está limitado a CUDA. Esa apertura es precisamente lo que permite crear aplicaciones compatibles con varios fabricantes.
ONNX en AMD: DirectML, ROCm y MIGraphX
DirectML en Windows
DirectML es una ruta de ejecución de Windows compatible con hardware DirectX 12 de distintos fabricantes. Por eso puede ser relevante para gráficos AMD, Intel y NVIDIA.
DirectML sigue recibiendo soporte, aunque se encuentra en modo de mantenimiento sostenido. Microsoft desarrolla nuevas funciones para implementaciones de ONNX Runtime en Windows a través de Windows ML. Windows ML también se basa en ONNX Runtime y puede gestionar Execution Providers adecuados para CPU, GPU y NPU.
ROCm y MIGraphX
ROCm es la plataforma de cálculo GPU de AMD y resulta especialmente relevante en Linux y en configuraciones AMD avanzadas. MIGraphX utiliza la optimización de grafos de AMD para acelerar modelos ONNX en GPU AMD.
El antiguo ROCm Execution Provider se eliminó a partir de ONNX Runtime 1.23. La documentación oficial recomienda migrar las cargas aplicables a MIGraphX.
La combinación adecuada depende del sistema operativo, la GPU, los controladores, el paquete de Runtime y el modelo.
Qué significa para ti
El hardware AMD no queda fuera de la IA local solo porque muchos proyectos empiecen ofreciendo una ruta CUDA. ONNX y los Execution Providers apropiados abren caminos adicionales que VANIV aprovecha dentro de una arquitectura flexible.
ONNX en Intel: CPU, gráficos, NPU y OpenVINO
CPU y gráficos Intel
Las CPU Intel pueden ejecutar modelos ONNX mediante rutas basadas en CPU. Los gráficos integrados de Intel y las GPU Intel Arc pueden aportar aceleración adicional según el sistema.
Por tanto, un equipo Intel no está necesariamente limitado a inferencia por CPU.
NPU en equipos Intel modernos
Las NPU están diseñadas para inferencia eficiente. Son especialmente relevantes en portátiles y equipos compactos. Su utilidad real depende del modelo y de la ruta de ejecución disponible.
Una NPU no sustituye automáticamente a una GPU potente. Su objetivo es diferente: ejecutar IA local de forma eficiente y con menor consumo.
OpenVINO
OpenVINO es un toolkit optimizado para hardware Intel que puede integrarse en ONNX Runtime como Execution Provider. El OpenVINO Execution Provider actual admite aceleración en CPU Intel, GPU Intel y NPU Intel.
Qué significa para ti
VANIV puede integrar las rutas de hardware Intel disponibles en el mismo flujo de proyecto local. La interfaz se mantiene coherente mientras la ejecución se adapta al sistema utilizado.
Las tres rutas de hardware de un vistazo
| Fabricante | Rutas de ejecución habituales | Unidades de cálculo posibles |
|---|---|---|
| NVIDIA | CUDA · TensorRT · DirectML | GPU |
| AMD | DirectML · MIGraphX · Ecosistema ROCm | GPU |
| Intel | CPU EP · OpenVINO · DirectML | CPU · GPU · NPU |
Compatibilidad de hardware y rendimiento: por qué los equipos no trabajan igual
Un portátil antiguo no se convierte de repente en una workstation de alto rendimiento. No es un problema de compatibilidad, sino una consecuencia normal de la diferencia entre componentes.
¿Qué significa esto para tu ordenador?
El rendimiento depende principalmente de tres áreas:
Compatibilidad y rendimiento son preguntas distintas
Un equipo puede ejecutar un flujo de trabajo y tardar bastante más que otro.
Por ejemplo:
- los gráficos integrados suelen ofrecer menos potencia de cálculo
- una GPU dedicada puede acelerar operaciones paralelas
- los modelos grandes necesitan más RAM o VRAM
- las partes no compatibles pueden continuar por CPU, aunque allí sean más lentas
Por qué esta guía evita comparaciones simplistas entre GPU
Afirmar que “la GPU A siempre es más rápida que la GPU B” no sería serio sin condiciones de prueba controladas. Una comparación útil necesita el mismo flujo, modelo, versiones de controlador, Execution Provider, ajustes y material de origen.
Las comparativas concretas de tarjetas gráficas encajan mejor en artículos específicos de benchmarks y compra.
Por qué ONNX es importante para la IA local
Ejecución local
Los modelos ONNX y ONNX Runtime pueden desplegarse por completo en el propio equipo. Por tanto, la inferencia no tiene que ejecutarse necesariamente en la nube.
Esto resulta especialmente útil con archivos de audio y vídeo. Los ficheros grandes no tienen que subirse a un servicio externo en cada fase.
Control sobre archivos y procesos
El procesamiento local te da más control sobre los archivos originales, los resultados intermedios y las exportaciones. También reduce la dependencia de la velocidad de subida y de la disponibilidad de servicios externos.
Trabajar en local no es una garantía automática de seguridad. Sí ofrece una base técnica para que los medios sensibles no tengan que enviarse a un servicio de inferencia de terceros.
Flexibilidad de hardware
El software y el flujo de trabajo no tienen que quedar vinculados de forma permanente a un fabricante de GPU. El modelo, la Runtime y la ruta de hardware siguen siendo componentes separados.
Así, una misma aplicación puede funcionar en sistemas distintos sin necesitar una interfaz completamente diferente para cada marca.
Una arquitectura de escritorio mantenible
Nuevos Execution Providers, generaciones de hardware y versiones de modelos pueden incorporarse a la misma arquitectura básica. Esto facilita la evolución de software local y evita dependencias innecesarias de una sola plataforma.
Cómo utiliza VANIV ONNX para audio y vídeo local
Un solo flujo para tres ecosistemas de hardware
Imagina tres puestos de trabajo:
Los tres usuarios trabajan con la misma interfaz de VANIV, las mismas funciones y el mismo flujo fundamental. El procesamiento utiliza el hardware disponible en cada equipo. El rendimiento cambia, pero el proceso se mantiene coherente.
Varias fases de IA en un proyecto local
VANIV combina:
- reconocimiento de voz local
- detección y asignación de hablantes
- traducción de vídeo con IA
- Text-to-Speech y voces offline
- Voice Cloning local
- doblaje de vídeo
- doblaje con varios hablantes
- ajuste de timing
- mezcla de audio y exportación
No todas las fases utilizan necesariamente el mismo modelo ni el mismo Execution Provider. El valor para el usuario está en que todas forman un proyecto local continuo en lugar de una colección de herramientas aisladas.
Sin subidas obligatorias a la nube
- los archivos originales y las exportaciones permanecen en tu equipo
- los vídeos grandes no tienen que subirse de nuevo en cada fase
- el cálculo local no requiere tarifas cloud por uso
- los medios confidenciales no necesitan enviarse a un servicio externo de inferencia
Para quién es VANIV
VANIV está dirigido a personas y equipos que trabajan con audio, voz o vídeo y quieren utilizar IA local en hardware AMD, Intel o NVIDIA.
Entre ellos:
- creadores de contenido y productores de vídeo
- empresas con vídeos de formación, soporte o marketing
- agencias y equipos de localización
- desarrolladores y entusiastas de la IA
- usuarios que valoran la libertad de elegir hardware
- equipos que prefieren procesamiento local a una dependencia permanente de la nube
Utiliza IA local en tu propio hardware
VANIV reúne reconocimiento de voz, traducción, Voice Cloning y doblaje de vídeo en un flujo local para AMD, Intel o NVIDIA.
Probar IA local en tu hardware →
¿Qué hardware es adecuado para IA local?
Portátil
Un portátil es adecuado para trabajo móvil, proyectos pequeños y pruebas. Los equipos modernos pueden combinar CPU, gráficos integrados, GPU dedicada y NPU.
Conviene tener en cuenta la refrigeración, la memoria gráfica compartida y las posibilidades limitadas de ampliación.
Mini PC
Un mini PC resulta útil para puestos compactos y eficientes. Según su configuración, puede asumir flujos de IA local pequeños o medianos.
Es importante revisar la ampliación de RAM, la refrigeración y el rendimiento gráfico real.
Sobremesa y workstation
Los equipos de sobremesa y las workstations son más adecuados para modelos grandes, vídeos largos y uso profesional frecuente. Ofrecen mayor capacidad de ampliación y permiten montar GPU más potentes.
A cambio, requieren más presupuesto, espacio y consumo energético.
El hardware correcto depende de tu flujo
Esta guía ofrece una orientación general. La sección de hardware de VANIV incluye información más detallada:
- Hardware para IA local: qué componentes necesitas
- GPU para IA local: tarjetas gráficas y VRAM
- Cuánta RAM necesita la IA local
- CPU y sistema para IA local
- SSD para IA local y proyectos multimedia grandes
Desde la guía general puedes acceder a los artículos específicos sobre RAM, CPU y SSD.
Preguntas frecuentes sobre ONNX
¿Necesito una tarjeta NVIDIA para usar ONNX?
No. ONNX Runtime puede ejecutar modelos en CPU, GPU y NPU de distintos fabricantes. NVIDIA está muy extendida por CUDA, pero no es un requisito para ONNX ni para VANIV.
¿Funciona ONNX con tarjetas AMD?
Sí. Según el sistema operativo y la configuración, pueden utilizarse rutas como DirectML, ROCm y MIGraphX.
¿Funciona ONNX con hardware Intel?
Sí. Dependiendo del equipo, pueden utilizarse CPU, gráficos integrados, Intel Arc, NPU y OpenVINO.
¿Puede ONNX funcionar completamente offline?
Sí. Si el modelo, la Runtime y los componentes necesarios están instalados localmente, la inferencia puede ejecutarse sin nube. Las descargas y actualizaciones sí pueden requerir internet.
¿ONNX acelera automáticamente todos los modelos?
No. ONNX es un formato de modelo. El rendimiento depende de la optimización, el hardware, los controladores, la Runtime y el Execution Provider.
¿Puedo exportar mi propio modelo a ONNX?
En muchos casos, sí. PyTorch ofrece un exportador oficial de ONNX. Otros frameworks y ecosistemas disponen de sus propias herramientas de exportación o conversión. El resultado depende de las operaciones del modelo y de las herramientas utilizadas.
¿ONNX es open source?
Sí, con una distinción importante. El proyecto ONNX utiliza la licencia Apache 2.0. ONNX Runtime también es open source y utiliza la licencia MIT. Algunos Execution Providers y SDK de hardware pueden tener condiciones distintas.
¿Qué frameworks son compatibles con ONNX?
PyTorch ofrece un exportador oficial. Existen herramientas de conversión para TensorFlow/Keras, TFLite, scikit-learn y otros ecosistemas. La compatibilidad exacta depende del modelo, sus operadores y el toolchain.
¿Cuál es la diferencia entre ONNX y ONNX Runtime?
ONNX describe el modelo y sus operaciones. ONNX Runtime es el software que carga, optimiza y ejecuta un modelo ONNX. Por tanto, el archivo del modelo y la Runtime no son lo mismo.
¿Cuál es la diferencia entre ONNX y DirectML?
ONNX describe el formato del modelo. DirectML es una tecnología de Windows para ejecutar Machine Learning con aceleración de hardware. ONNX Runtime puede utilizar DirectML como Execution Provider.
¿Cuál es la diferencia entre ONNX Runtime y OpenVINO?
ONNX Runtime es una Runtime general para modelos ONNX. OpenVINO es un toolkit optimizado para Intel que puede integrarse como Execution Provider.
¿Por qué es importante ONNX para VANIV?
VANIV utiliza ONNX para ejecutar IA local en sistemas AMD, Intel y NVIDIA. Así, el flujo no queda vinculado a un solo fabricante de GPU.
Conclusión: ONNX hace que la IA local sea flexible en hardware
En resumen:
- ONNX facilita el intercambio de modelos de IA entrenados.
- ONNX Runtime los carga, optimiza y ejecuta.
- Los Execution Providers conectan la Runtime con CPU, GPU o NPU.
El resultado es una arquitectura capaz de utilizar distintas rutas de ejecución en AMD, Intel y NVIDIA. El rendimiento sigue dependiendo del equipo, pero el flujo principal no tiene que reinventarse para cada fabricante.
VANIV se basa exactamente en este enfoque. Reconocimiento de voz, traducción, Text-to-Speech, Voice Cloning y doblaje de vídeo se integran en un flujo local que utiliza el hardware AMD, Intel o NVIDIA disponible. Tú eliges el hardware; VANIV se ocupa del flujo.
Utiliza IA local en tu propio hardware
VANIV combina audio, voz y vídeo en un flujo local para AMD, Intel o NVIDIA.
Probar IA local en tu hardware →
Fuentes técnicas y documentación adicional
AMD, Intel, NVIDIA y sus respectivas marcas son propiedad de sus titulares. VANIV es un producto independiente y no mantiene ninguna relación empresarial con estas compañías.