El abuelo de Allyson Vasquez dejó a medias un juego de ajedrez tallado a mano. Para completar las piezas que faltaban, ella parte de una de las figuras existentes: obtiene una imagen o un escaneo, lo lleva a ComfyUI, genera una malla 3D, termina de trabajarla en Blender y la convierte en un objeto físico con una impresora 3D. Es una historia familiar, pero también un ejemplo muy claro de lo que ocurre cuando la IA deja de ser una página a la que enviamos una petición y pasa a formar parte de las herramientas de trabajo.
Por qué ejecutar la IA en tu propio equipo
La memoria unificada, clave para modelos grandes
Modelos y herramientas: Qwen, Nemotron y llama.cpp
Agentes de IA que trabajan en tu PC
MCP para conectar agentes con tus aplicaciones
NVIDIA OpenShell y Execution Containers: agentes con accesos acotados
NVIDIA PAIR: repartir la inferencia entre equipos de la red local
Caso práctico: diseño arquitectónico con agentes
Creación de contenido acelerada con RTX
Premiere Pro y Photoshop en beta: funciones de IA con modelos locales
Blender 5.3 Beta: DLSS Ray Reconstruction en el visor de Cycles
RTX Video y NVIDIA Broadcast, con su servidor MCP local
Generación de imágenes, vídeo y 3D con ComfyUI
Ahí es donde entra NVIDIA RTX Spark. La plataforma combina una CPU Grace basada en ARM, una GPU Blackwell RTX y memoria unificada en equipos con Windows 11. En lugar de reservar la IA para una función aislada, ofrece margen para mantener modelos, aplicaciones creativas y proyectos exigentes dentro del mismo ordenador. Según las herramientas elegidas, el flujo puede ejecutarse en el equipo, apoyarse en otro PC de la red local o combinar aplicaciones locales con un modelo en la nube.
El vídeo oficial NVIDIA RTX Spark | Made to Create reúne varias de esas posibilidades. Lo interesante está en el trabajo que queda entre una referencia inicial y el resultado: generar, revisar, corregir y continuar editando desde las aplicaciones que ya utiliza el creador.
Portátiles NVIDIA RTX Spark
Precio: 3.299,99 EUR
Por qué ejecutar la IA en tu propio equipo
Trabajar en local cambia bastante la operativa frente a los servicios de IA en la nube. Una vez descargados el modelo, el programa que lo ejecuta y los recursos necesarios, un flujo preparado para funcionar sin conexión puede seguir utilizándose sin depender de un servicio remoto. Los requisitos de cuentas, licencias o suscripciones dependerán de las herramientas elegidas, pero la inferencia local permite prescindir de una conexión permanente a Internet para esas tareas. Para alguien que trabaja durante un viaje, en una localización con mala cobertura o en un estudio cuya conexión se ha caído, poder continuar con el proyecto supone una ventaja práctica.
Además, las peticiones que se resuelven íntegramente en el PC no generan un coste por llamada a una API externa. Esto permite repetir una generación, probar distintas instrucciones o comparar variantes sin sumar cargos por uso de ese servicio. El hardware, la energía, el almacenamiento, el mantenimiento y las posibles licencias siguen formando parte del coste total, por lo que el ahorro dependerá del volumen de trabajo y de las herramientas utilizadas. Esta diferencia puede resultar especialmente útil durante el desarrollo de software y la creación de contenido, donde las pruebas y las iteraciones forman parte habitual del proceso.
Vista del editor de código Visual Studio Code mostrando la integración de funciones de asistencia para programación en un entorno de desarrollo con tema oscuro. Foto: HardZone.es
El tercer punto que debemos tener en cuenta es el control sobre los datos. Un documento interno, el vídeo de un cliente o una imagen inédita pueden permanecer en el dispositivo cuando toda la cadena es local. Cuando dependemos de IA alojada en la nube, los datos pasan por servidores de terceros, algo que puede chocar con los acuerdos de confidencialidad de algunos clientes. Lo mismo ocurre con aplicaciones que combinan funciones locales con servicios en la nube: en el momento en que nuestros datos salen del PC, podemos tener un problema.
La memoria unificada, clave para modelos grandes
En un PC con gráfica dedicada, la memoria del sistema y la memoria de vídeo son dos espacios físicos separados. Podemos instalar mucha RAM y seguir chocando contra la capacidad de la GPU al cargar los pesos de un modelo, su contexto o una escena compleja. Esto es lo que suele pasar, sobre todo, en portátiles: el procesador tiene memoria de sobra para las aplicaciones, mientras que la gráfica cuenta con un bloque bastante más pequeño para todas sus cargas.
RTX Spark nace precisamente para cambiar esa organización. La CPU Grace y la GPU Blackwell acceden a la misma memoria física coherente, de modo que los modelos, el contexto y los recursos creativos disponen de un espacio común. Podemos encontrar portátiles que van desde los 32 GB hasta los 128 GB de memoria, lo que permite plantear el uso de modelos que quedarían fuera de muchas GPU convencionales y, al mismo tiempo, mantener abiertas herramientas como ComfyUI o Blender sin tratar la VRAM como una habitación con la puerta siempre atascada. La memoria total se reparte entre Windows, la CPU, la GPU, las aplicaciones, el motor de inferencia, las activaciones y la caché que conserva el contexto, y se va ajustando según las necesidades de cada proceso.
Aquí es donde entra en juego también una nueva técnica que ayuda a que los pesos de los modelos ocupen menos: la cuantización. NVFP4, por ejemplo, emplea valores de 4 bits optimizados para la arquitectura Blackwell y reduce la huella frente a formatos de mayor precisión. Según NVIDIA, este formato puede ocupar cerca de 3,5 veces menos que FP16. Eso sí, debemos tener en cuenta que la memoria total del proceso incluye más elementos que los pesos (procesos, contexto, etc.), pero, aunque no podemos aplicarlo a cualquier modelo, sí nos sirve para entender el ahorro del formato.
Al final, lo importante es que exista una variante del modelo preparada para NVFP4 y que el motor utilizado sepa aprovecharla. De esta forma se deja más espacio para contexto, modelos auxiliares y aplicaciones, haciendo que todo funcione de una forma mucho más natural y más fluida. Y esto, para un creador, significa poder conservar más partes del flujo abiertas; y para un desarrollador, probar configuraciones más grandes antes de recurrir a la infraestructura remota.
Modelos y herramientas: Qwen, Nemotron y llama.cpp
Cuando hablamos de IA local, el nombre del modelo solo cuenta una parte de la historia. Qwen o Nemotron, por ejemplo, pueden publicarse en distintas variantes, con cuantizaciones y formatos pensados para motores diferentes. Por ejemplo, el caso de Qwen ilustra muy bien por qué hay que mirar el archivo concreto. En este modelo tenemos, por ejemplo, una variante GGUF Q4_K_M de Qwen3.8-27B destinada a funcionar dentro de LM Studio Bionic y llama.cpp. Sin embargo, existe asimismo un artefacto NVFP4 con el mismo modelo base, que en su ficha aparece como orientado a Linux y a otros motores. Por ello, es muy importante dejar de pensar tanto en la cantidad de parámetros que tiene un modelo y pensar un poco más en el checkpoint, formato, sistema y runtime del mismo.
Entorno de trabajo de ComfyUI durante el proceso de creación de un personaje robótico mediante inteligencia artificial. Foto: HardZone.es
llama.cpp, por su parte, es el programa que se encarga de ejecutar modelos GGUF. Este software puede utilizarse desde la línea de comandos o levantar un servidor local con una API compatible con el protocolo de OpenAI. En el caso de NVIDIA, la herramienta cuenta con binarios optimizados para Windows ARM64 con aceleración CUDA, una opción especialmente interesante para convertir RTX Spark en el backend de una aplicación propia.
NVIDIA también cuenta con sus propios modelos de IA local. El más conocido, Nemotron, se puede descargar en distintas variantes, como GGUF y NVFP4, lo cual abre aún más las posibilidades a la hora de usar modelos de IA local, ya sea apostando por modelos listos y optimizados para llama.cpp, o para utilizar dentro de otras configuraciones o en otros entornos. El archivo que elegimos determina la memoria que ocuparán los pesos y el software necesario. La longitud del contexto añade, además, su propio consumo. Por eso, tener memoria suficiente para el modelo es el primer paso, aunque la experiencia final también depende del ritmo al que procese la entrada y genere la respuesta.
Agentes de IA que trabajan en tu PC
Un modelo genera una respuesta; pero un agente encadena pasos y utiliza herramientas para completar un trabajo. Puede revisar archivos, consultar el estado de un proyecto, pedir a una aplicación que ejecute una operación y decidir qué hacer con el resultado. Esa capacidad exige separar bien las piezas: el modelo razona, el «agent harness» mantiene el ciclo, las herramientas actúan y las políticas delimitan hasta dónde llegan sus permisos.
Ejemplo de interacción con el asistente Hermes en RTX Spark, donde se muestra un resumen de tareas matutinas y recordatorios diarios. Foto: HardZone.es
RTX Spark proporciona el equipo en el que pueden convivir todas esas capas. MCP, OpenShell, Microsoft Execution Containers y PAIR resuelven partes diferentes del problema: conectar aplicaciones, acotar accesos y repartir solicitudes. Juntas permiten construir flujos bastante más útiles que un chat, siempre que cada una se utilice para la función que le corresponde.
MCP para conectar agentes con tus aplicaciones
Model Context Protocol, o MCP, ofrece una forma común de presentar herramientas y recursos a una aplicación de IA. En vez de diseñar una integración diferente para cada programa, un servidor puede anunciar operaciones concretas y el agente puede solicitarlas. Así se puede pasar de copiar datos entre ventanas a pedir que una aplicación procese un archivo, cambie un ajuste o devuelva el estado de una tarea.
El servidor puede vivir en el mismo PC o en otra máquina. MCP se ocupa de la comunicación; los permisos y el aislamiento pertenecen a las capas que rodean al agente. Esto permite ser bastante preciso: una herramienta puede exponer únicamente las operaciones necesarias para un proyecto, mientras OpenShell o un contenedor limitan los archivos, la red y las credenciales accesibles.
NVIDIA OpenShell y Execution Containers: agentes con accesos acotados
Dar a un agente acceso general al ordenador sería una mala idea. NVIDIA OpenShell permite colocar políticas alrededor de sus acciones y establecer qué archivos, procesos, conexiones, API y credenciales puede utilizar. El modelo puede estar en el equipo o en un servicio remoto; las reglas se aplican al entorno en el que actúan sus herramientas. Microsoft Execution Containers, también conocidos como MXC, aportan la contención del código y de las herramientas mediante políticas del sistema. La combinación de ambos permite plantear casos muy concretos: un agente con permiso para leer la carpeta de un proyecto y lanzar una aplicación, pero con el resto del disco y determinadas conexiones fuera de su alcance.
MXC alcanzó la versión 1.0 en octubre de 2026. En RTX Spark, la integración nativa de OpenShell con MXC para Windows sigue en desarrollo y está planteada como una vía futura, mientras que las rutas estables de OpenShell se encuentran en Linux. Su utilidad actual está en mostrar hacia dónde va el control de los agentes y en obligarnos a pensar en políticas explícitas. Al final, la madurez y las garantías dependen del backend y de la configuración aplicada.
NVIDIA PAIR: repartir la inferencia entre equipos de la red local
Cuando varios agentes o aplicaciones llaman al mismo modelo, las peticiones pueden acumularse. NVIDIA PAIR es una herramienta diseñada para descubrir equipos autorizados dentro de la red local y dirigir cada solicitud completa a un nodo disponible con motores como Ollama, LM Studio o llama.cpp. De cara a la aplicación, existe un punto de entrada común; por debajo, el router decide qué máquina atenderá el trabajo.
Eso sí, es importante tener en cuenta su principal limitación: al usar PAIR, la memoria de los equipos permanece separada. Esta herramienta reparte peticiones completas entre nodos: cada ordenador debe cargar por sí solo los pesos, el contexto, la caché y el runtime. Tres equipos con 64 GB permiten atender más trabajo concurrente, pero el modelo más grande sigue limitado por la capacidad individual del nodo que recibe la solicitud. PAIR tampoco fragmenta un modelo o una petición para ejecutarlos entre varias máquinas.
Caso práctico: diseño arquitectónico con agentes
La demostración oficial Architectural Design With Agents on NVIDIA RTX Spark aterriza estas ideas en un ejemplo muy claro. El punto de partida es una parcela acompañada de referencias visuales y requisitos. El agente trabaja con Rhino para preparar el terreno, los retranqueos, la envolvente y una propuesta de distribución. El arquitecto revisa el resultado, corrige lo necesario y da paso a la siguiente fase.
