Un agente con prioridad local para un trabajo de conocimiento privado y rentable

Perplexity Portable Computer es un agente con prioridad local.

Todo el conjunto se ejecuta localmente de forma predeterminada. El modelo, el arnés, la conversación y la trayectoria residen en la máquina del usuario. El trabajo que necesita del mundo exterior, como la búsqueda web, los conectores o la transferencia a un modelo asesor más potente en la nube, se invoca solo cuando es necesario y siempre está controlado por el usuario. Por lo tanto, los datos confidenciales nunca abandonan el dispositivo sin permiso, y los modelos locales no conllevan ninguna tarifa de inferencia: el sistema es privado y rentable por diseño.

Un agente con prioridad local eficaz requiere que el modelo y el arnés se diseñen conjuntamente. Los arneses de propósito general presuponen la existencia de un modelo de vanguardia capaz de absorber contextos largos, navegar por una amplia superficie de herramientas y planificar a largo plazo. Los modelos locales son menos fiables ante esas demandas. En lugar de pedir a un modelo pequeño que gestione un arnés diseñado para uno grande, moldeamos ambos mutuamente: un arnés adaptado al perfil de capacidades del modelo y un modelo postentrenado para utilizar ese arnés eficazmente.

Introducción

En los últimos meses, las capacidades agénticas han avanzado rápidamente en una amplia gama de tareas de trabajo de conocimiento. Si bien estos avances aportan grandes aumentos de productividad y eficiencia, también plantean dos desafíos.

El consumo de tokens está aumentando rápidamente, y con él el gasto general. Cuando se accede a la inteligencia a través de las API de modelos de código cerrado que se ejecutan en clústeres remotos, la información privada y la propiedad intelectual abandonan el dispositivo del usuario con cada solicitud. A medida que los agentes se escalan en los flujos de trabajo individuales y en organizaciones enteras, el gasto en tokens y el movimiento de datos se vuelven cada vez más difíciles de gobernar.

Al mismo tiempo, los modelos de código abierto han mejorado a un ritmo aún mayor. El progreso es más visible en modelos muy pequeños y eficientes como NVIDIA Nemotron 3.5 Lightning (30B de parámetros totales), Qwen 3.6 (35B) y Qwen 3.8 (27B). Estos modelos pequeños superan sus expectativas y ahora son capaces de realizar flujos de trabajo agénticos complejos. El hardware de inferencia local avanza en paralelo: sistemas como NVIDIA DGX Spark ahora pueden ejecutar estos modelos localmente. En conjunto, estas tendencias hacen que la operación totalmente en el dispositivo sea práctica, al tiempo que permiten a los usuarios optar por capacidades externas cuando sea necesario, como búsqueda web, conectores o transferencia a modelos en la nube.

Este enfoque con prioridad local permite un ahorro de costos significativo, ya que la inferencia local evita las tarifas de API por token. También resuelve de forma natural las preocupaciones sobre privacidad y propiedad intelectual: los tokens privados nunca necesitan transmitirse a clústeres remotos y permanecen de forma segura dentro de los límites del dispositivo local.

En junio, presentamos el primer orquestador de inferencia híbrido local-servidor que decide qué trabajo debe ejecutarse en el dispositivo y qué trabajo debe enviarse a los agentes en la nube. Aquí explicamos cómo construimos dicho agente con prioridad local, incluido el arnés y los modelos optimizados conjuntamente.

Ofrecemos una visión general de las principales opciones de diseño, evaluamos Computer frente a arneses de propósito general de código abierto populares (Hermes y Pi) en tres benchmarks públicos y en nuestro Local Knowledge Work Bench interno. En nuestro benchmark, con el modelo Qwen 3.8 27B ejecutándose en un NVIDIA DGX Spark, Computer alcanza la puntuación más alta, un 82,6% frente al 77,6% de Pi y el 74,0% de Hermes. PPLX 27B, nuestro modelo postentrenado sobre Qwen 3.8 27B, eleva aún más la puntuación hasta el 85,4%.

Diseñar el arnés en torno al modelo local

Aunque los modelos compactos en el dispositivo ya son bastante capaces, todavía se quedan atrás de los modelos de vanguardia más grandes en cuanto a rendimiento. Se necesita un arnés diseñado cuidadosamente para orientar estos modelos eficazmente y abordar sus limitaciones.

Los arneses de código abierto populares como Pi y Hermes han demostrado ser generales: funcionan bien con una amplia variedad de modelos de diferentes tamaños y clases. Sin embargo, no están optimizados para las capacidades de los modelos en el dispositivo. Diseñamos el arnés local específicamente para este entorno, basándonos en unos pocos principios clave.

Eficiencia de contexto

El enfoque principal en el diseño de nuestro arnés fue hacer el mejor uso del contexto del modelo.

Aunque los modelos en el dispositivo como Qwen 3.8 27B ofrecen ventanas de contexto de 260K tokens, descubrimos empíricamente que empiezan a tener dificultades más allá de los 100K tokens. Por lo tanto, mantenemos el arnés principal conciso: un indicador de sistema mínimo y un conjunto reducido de herramientas principales.

Todas las demás capacidades se modularizan en habilidades bajo demanda que se cargan y descargan a lo largo de la trayectoria. Diseñamos estas habilidades para tareas comunes de trabajo de conocimiento: investigación, ciencia de datos, visualización de datos, creación de documentos, ingeniería de software y más.

El arnés también admite la compactación de contexto, resumiendo el contexto obsoleto cuando una trayectoria se alarga para que el modelo permanezca dentro de su ventana efectiva.

Conectores como herramientas de línea de comandos

El trabajo de conocimiento diario a menudo requiere conectores como Gmail, GitHub, Outlook y Google Calendar. Estos suelen exponerse a un arnés como servidores MCP, cuyas grandes definiciones de herramientas consumen una parte sustancial del contexto. En su lugar, convertimos los MCP más utilizados en herramientas de línea de comandos compactas y fáciles de usar, complementadas con habilidades personalizadas que aprovechan mucho mejor el contexto efectivo limitado.

Autoverificación

El rendimiento también mejora cuando el agente verifica su propio trabajo. La verificación añade pasos adicionales, pero mejora enormemente los resultados finales y reduce sustancialmente la brecha con los modelos de vanguardia. Puede ser activada por el propio modelo o por un conjunto de ganchos que monitorizan la salud de la trayectoria y solicitan la autoverificación cuando algo va mal.

Ejecución en entorno aislado

El arnés ejecuta las herramientas en un entorno aislado a nivel de sistema operativo en el dispositivo del usuario. El límite restringe los procesos, las rutas del sistema de archivos y el acceso a la red según la política. Esto limita el radio de impacto de un comando erróneo. Si el entorno aislado no está disponible, el arnés se desactiva antes de realizar cualquier llamada a herramientas en lugar de degradarse a una ejecución sin aislamiento.

Esto difiere de los arneses de código abierto como Pi y Hermes, que ejecutan comandos directamente con los permisos del usuario de forma predeterminada. En Computer, el aislamiento está siempre activado, no requiere configuración y las herramientas no pueden ejecutarse sin él.

El diagrama siguiente muestra cómo encajan estos principios en el bucle de ejecución. El orquestador es código de arnés determinista, no un LLM: mantiene el bucle, ensambla el contexto y hace cumplir las políticas. El modelo local propone la siguiente acción; el orquestador ejecuta las llamadas a herramientas aprobadas en el entorno aislado y devuelve sus resultados al modelo. La búsqueda web, los conectores y las llamadas a asesores cruzan el límite del dispositivo solo cuando están habilitados y aprobados.

Un arnés local saca más partido del mismo modelo

Utilizando el mismo modelo base en el dispositivo, comparamos nuestro arnés local con alternativas de propósito general en investigación web y comprensión multimodal de documentos. Todos los arneses utilizan el modelo Qwen 3.8 27B con razonamiento medio, ejecutándose en un NVIDIA DGX Spark. Esta comparación aisla las capacidades aportadas por el propio arnés, antes de cualquier postentrenamiento del modelo.

Nos centramos en estas dos capacidades porque el trabajo de conocimiento a menudo combina documentos privados en el dispositivo del usuario con información pública de la web para producir un artefacto fundamentado. La búsqueda web requiere conectividad, pero la inferencia del modelo y el procesamiento de documentos privados permanecen locales. Los archivos locales sirven como fuente autorizada, las fuentes públicas añaden contexto y los usuarios pueden deshabilitar por completo la búsqueda web para trabajar totalmente sin conexión.

Investigación web

Construimos nuestro arnés local junto con el motor de búsqueda de Perplexity, que ha alcanzado los puestos más altos en evaluaciones independientes. El arnés accede a él a través de la interfaz Search as Code.

Evaluamos la calidad de la investigación en 1.266 tareas de BrowseComp. Computer utiliza la infraestructura de búsqueda de Perplexity junto con nuestro arnés local, mientras que Pi y Hermes dependen de Brave, su proveedor de búsqueda recomendado. Computer alcanza una precisión del 66,7%, en comparación con el 50,2% de Pi y el 43,9% de Hermes.

Computer también tiene el tiempo de pared y el uso de tokens medio registrado más bajos: 402,1 segundos y 852k tokens por tarea, en comparación con los 1.020,9 segundos y 1,01 millones de tokens de Hermes, y los 826,0 segundos y 2,82 millones de tokens de Pi. Por lo tanto, Computer utiliza un 61% menos de tiempo de pared y un 16% menos de tokens que Hermes, y un 51% menos de tiempo de pared y un 70% menos de tokens que Pi.

Comprensión multimodal de documentos en el dispositivo

Muchos documentos contienen información de forma visual y son difíciles de analizar como texto plano: PDF, páginas escaneadas, capturas de pantalla, gráficos y presentaciones. Estos flujos de trabajo dependen del OCR y de la comprensión de imágenes, y se benefician enormemente de un modelo nativamente multimodal.

El arnés pasa las páginas de los documentos y las imágenes directamente al modelo, el cual las comprende y combina la evidencia visual con el texto extraído. Procesar estos archivos en el dispositivo mantiene los documentos confidenciales y su contenido extraído de forma privada.

Evaluamos la comprensión multimodal de documentos en ParseBench-100, un subconjunto de 100 tareas del benchmark ParseBench, con 20 tareas para cada uno de los siguientes aspectos: gráficos, diseño, tablas, contenido de texto y formato.

Computer alcanza una puntuación media del 65,1%, en comparación con el 34,6% de Hermes y el 13,9% de Pi. También completa las tareas con el menor tiempo y la menor cantidad de tokens: una media de 60,6 segundos y 20,1k tokens por tarea, frente a los 108,3 segundos y 32,1k tokens de Hermes, y los 410,5 segundos y 829,1k tokens de Pi. Computer lidera las cinco categorías de documentos, con su mayor ventaja en los gráficos. El diseño sigue siendo difícil para los tres arneses.

Tabla 1. Puntuación media de ParseBench-100 por categoría de documento para los arneses Computer, Hermes y Pi con el modelo Qwen 3.8 27B en el dispositivo. Computer lidera en las cinco categorías.

Reduciendo la brecha con la vanguardia mediante la transferencia a asesores

A pesar de contar con un arnés diseñado cuidadosamente, las tareas más difíciles siguen superando las capacidades de un modelo compacto en el dispositivo. Para dichas tareas, el arnés expone una herramienta de asesoramiento: el modelo local puede consultar a un modelo de vanguardia más potente cuando necesita ayuda con la planificación, la resolución de ambigüedades, la recuperación de fallos repetidos o la verificación del resultado final.

El modelo local decide cuándo solicitar asesoramiento, mientras que el orquestador del arnés conserva la autoridad sobre las herramientas y controla qué contexto se envía. La transferencia es opcional. El usuario decide si la habilita y si aprueba cada llamada al asesor de forma manual o automática.

Antes de realizar una llamada a un asesor, el arnés selecciona el contexto relevante, aplica un clasificador PII para marcar la información confidencial y muestra al usuario lo que saldría del dispositivo. El asesor recibe únicamente el contexto aprobado y devuelve una guía en texto; no tiene acceso directo a los archivos, herramientas o conversaciones del dispositivo. Esto mejora tanto el coste como la privacidad, y planeamos explorar esta dirección con más detalle en futuros trabajos.

Probamos este enfoque en tareas desafiantes de ingeniería de software, las cuales exigen un fuerte razonamiento y son aquellas en las que un modelo local suele quedarse corto. Para ello, utilizamos Terminal Bench 2.1, un popular benchmark de 89 tareas para agentes de programación.

Queremos responder a dos preguntas: qué parte de la brecha con un modelo de vanguardia puede cerrar la transferencia a asesores, y a qué coste. Los modelos totalmente locales prácticamente no cuestan nada de ejecutar, ya que la inferencia se realiza en el hardware del usuario. Sin embargo, una vez que el modelo comienza a llamar al asesor, empieza a incurrir en costes de API.

Como línea base para el rendimiento de vanguardia, utilizamos Claude Opus 5 operando en el arnés local; el modelo local es Qwen 3.8 27B. Por último, combinamos ambos: Qwen 3.8 27B ejecuta la tarea y la transfiere a un asesor Claude Opus 5 cuando necesita ayuda. No evaluamos la transferencia a asesores con Pi o Hermes porque ninguno proporciona una herramienta de asesoramiento equivalente; añadir una requeriría modificar su superficie de herramientas y su lógica de orquestación, por lo que el resultado ya no representaría el arnés estándar.

La transferencia a asesores eleva la puntuación de Computer del 59,6% al 73,0%, una ganancia de 13,5 puntos porcentuales, con un coste de API estimado de $0,415 por ejecución. Ejecutar Claude Opus 5 por sí solo alcanza el 82,4% a $0,65 por ejecución. Por lo tanto, la transferencia recupera aproximadamente tres quintas partes de la brecha con la vanguardia a cerca de dos tercios del coste de esta, y es el usuario quien decide cuándo vale la pena asumir ese intercambio.

Postentrenamiento para el arnés y el trabajo de conocimiento

Hasta ahora, hemos mantenido el modelo local sin cambios para aislar lo que aporta el arnés. Una vez establecido el diseño del arnés, las mayores ganancias restantes provienen de adaptar el propio modelo. Los datos de uso de Perplexity Computer nos muestran lo que la gente hace realmente en su trabajo de conocimiento, los cuales utilizamos para sintetizar datos de entrenamiento. Postentrenamos el modelo local dentro del arnés de Computer, guiados por la distribución real de las tareas que realizan los usuarios.

Concretamente, identificamos un conjunto diverso de casos de uso que ejercitan diferentes capacidades del modelo, herramientas y conectores. A partir de estos casos de uso, sintetizamos entornos de aprendizaje por refuerzo realistas y definimos tareas desafiantes pero verificables: cada tarea consta de una instrucción, un entorno y un verificador que puntúa el resultado final, donde el entorno es un contenedor de Docker en el que opera el arnés. Es importante destacar que, dado que las tareas son sintéticas, no contienen documentos reales ni información de los usuarios.

Utilizamos estos entornos para un entrenamiento en dos etapas: ajuste fino por rechazo seguido de aprendizaje por refuerzo. En la primera etapa, ejecutamos el modelo frente a cada tarea varias veces, seleccionamos las mejores trayectorias según la puntuación del verificador y las entrenamos mediante aprendizaje supervisado. Esta etapa inicializa el modelo para el arnés específico y la distribución de tareas. En la segunda etapa, el aprendizaje por refuerzo ajusta aún más el modelo, haciéndolo más robusto.

Se reserva un subconjunto de tareas que no se utiliza en el entrenamiento para la evaluación final; denominamos a este conjunto reservado Local Knowledge Work Bench: 53 tareas que abarcan siete categorías de trabajo de conocimiento diario, desde la investigación profunda hasta la creación de documentos. Pronto publicaremos un informe técnico que describe en detalle el entrenamiento del modelo, y planeamos abrir el código fuente de este benchmark de evaluación.

Postentrenamos Qwen 3.8 27B con este enfoque, produciendo un modelo al que llamamos PPLX 27B, y lo evaluamos en el Local Knowledge Work Bench. Con el modelo base Qwen 3.8 27B, Computer alcanza la puntuación más alta (82,6%, frente al 77,6% de Pi y el 74,0% de Hermes) y utiliza la menor cantidad de tokens (520k, en comparación con los 681k de Pi y los 634k de Hermes). Pi completa las tareas más rápido, en 176 segundos por tarea, frente a los 218 segundos de Computer y los 292 segundos de Hermes. PPLX 27B eleva la puntuación de Computer al 85,4%, a costa de un mayor uso de tokens (678k frente a 520k). Su tiempo de pared estimado es de 250 segundos.

Tabla 2. Categorías de tareas del Local Knowledge Work Bench.

Conclusión

Nuestra investigación demuestra que un modelo de código abierto sólido, con hardware local capaz y un arnés diseñado para ellos, puede gestionar trabajo de conocimiento real a un coste de inferencia cercano a cero sin necesidad de que los datos confidenciales abandonen el dispositivo.

En los distintos benchmarks, Computer igualó o superó a Hermes y Pi en precisión al ejecutar Qwen 3.8 27B en un NVIDIA DGX Spark. Entre los tres benchmarks que informan sobre la latencia y el uso de tokens, Computer fue el más rápido en BrowseComp y ParseBench-100 y utilizó la menor cantidad de tokens en los tres; Pi fue el más rápido en el Local Knowledge Work Bench.

Las mejoras provienen de las decisiones que tomamos. Construimos un arnés local conciso con habilidades que se cargan bajo demanda. Convertimos los conectores en herramientas CLI compactas en lugar de servidores MCP. La ejecución se aisló en un entorno protegido por motivos de seguridad.

Los resultados también muestran en qué áreas los modelos compactos tienen margen de mejora. Por ejemplo, en las desafiantes tareas de programación de Terminal Bench 2.1, el modelo local se queda por detrás del modelo de vanguardia en los tres arneses. La transferencia a asesores reduce pero no cierra por completo la brecha; todavía se necesitan mejoras continuas en las capacidades de los modelos y en el hardware local para impulsar aún más el rendimiento.

El propósito de construir el arnés y el modelo para restricciones locales es dar a los usuarios un control explícito sobre qué información abandona sus máquinas. También existen beneficios de coste para el usuario. Consideramos que esto forma parte de un cambio más amplio en el que agentes cada vez más capaces pasan de la infraestructura remota a dispositivos individuales y locales. Esperamos que los avances en chips, modelos y dispositivos amplíen continuamente la gama y la calidad del trabajo de conocimiento que Portable Computer gestiona localmente.