En lokal-først-agent for privat og kostnadseffektivt kunnskapsarbeid

Perplexity Portable Computer er en lokal-først-agent.

Hele stabelen kjører lokalt som standard. Modellen, rammeverket, samtalen og banen befinner seg alle på brukerens maskin. Arbeid som krever omverdenen, som nettsøk, koblinger eller eskalering til en sterkere rådgivermodell i skyen, aktiveres bare når det er nødvendig, og er alltid kontrollert av brukeren. Sensitiv data forlater derfor aldri enheten uten tillatelse, og lokale modeller har ingen slutningsavgift: systemet er privat og kostnadseffektivt av naturtilstand.

En effektiv lokal-først-agent krever at modellen og rammeverket utformes sammen. Generelle rammeverk forutsetter en grensemodell som kan absorbere lange kontekster, navigere i et bredt verktøyområde og planlegge over lange horisonter. Lokale modeller er mindre pålitelige under slike krav. I stedet for å be en liten modell om å administrere et rammeverk bygget for en stor, formet vi de to rundt hverandre: et rammeverk skreddersydd for modellens kapasitetsprofil, og en modell ettertrent til å bruke det rammeverket effektivt.

Innledning

Agentkapasiteter har de siste månedene avansert raskt på tvers av et bredt spekter av kunnskapsarbeidsoppgaver. Selv om disse fremskrittene gir store gevinster i produktivitet og effektivitet, utgjør de også to utfordringer.

Tokenforbruket øker raskt, og med det også de totale kostnadene. Når intelligens nås gjennom API-ene til lukkede modeller som kjører på eksterne klynger, forlater privat informasjon og åndsverk brukerens enhet ved hver forespørsel. Ettersom agenter skaleres på tvers av individuelle arbeidsflyter og hele organisasjoner, blir tokenutgifter og dataflyt stadig vanskeligere å styre.

Samtidig har åpen kildekode-modeller forbedret seg i et enda raskere tempo. Fremgangen er mest synlig i svært små og effisiente modeller som NVIDIA Nemotron 3.5 Lightning (30 milliarder totale parametere), Qwen 3.6 (35B) og Qwen 3.8 (27B). Disse små modellene yter over evne og er nå i stand til å utføre komplekse arbeidsflyter for agenter. Maskinvare for lokal slutning utvikler seg parallelt: systemer som NVIDIA DGX Spark kan nå kjøre disse modellene lokalt. Sammen gjør disse trendene fullstendig enhetsbasert drift praktisk, samtidig som brukere kan velge eksterne funksjoner ved behov, som nettsøk, koblinger eller eskalering til sky-modell.

Denne lokal-først-tilnærmingen muliggjør betydelige kostnadsbesparelser, siden lokal slutning unngår API-avgifter per token. Den løser også naturlig personvern- og åndsverksbekymringene: private tokens trenger aldri å bli overført til eksterne klynger og forblir trygt innenfor grensene til den lokale enheten.

I juni introduserte vi den første hybride lokale server-slutningsorkestratoren som avgjør hvilket arbeid som skal kjøre på enheten, og hvilket arbeid som skal gå til agenter i skyen. Her forklarer vi hvordan vi bygde en slik lokal-først-agent, inkludert rammeverket og modellene som er samoptimalisert for hverandre.

Vi gir en oversikt over de viktige designvalgene, og evaluerer Computer opp mot populære generelle rammeverk med åpen kildekode (Hermes og Pi) på tvers av tre offentlige benchmarks og vår interne Local Knowledge Work Bench. På vår benchmark, med Qwen 3.8 27B-modellen kjørende på en NVIDIA DGX Spark, oppnår Computer den høyeste poengsummen, 82,6 % mot 77,6 % for Pi og 74,0 % for Hermes. PPLX 27B, vår modell ettertrent på toppen av Qwen 3.8 27B, hever poengsummen ytterligere til 85,4 %.

Utform rammeverket rundt den lokale modellen

Selv om kompakte modeller på enheten allerede er ganske kapable, henger de fremdeles etter større grensemodeller i ytelse. Et nøye utformet rammeverk trengs for å styre disse modellene effektivt og for å adressere deres begrensninger.

Populære rammeverk med åpen kildekode som Pi og Hermes har vist seg å være generelle: de fungerer godt med et bredt utvalg av modeller på tvers av størrelser og klasser. Men de er ikke optimert for egenskapene til enhetsbaserte modeller. Vi designet det lokale rammeverket spesifikt for denne innstillingen, rundt noen få nøkkelprinsipper.

Konteksteffektivitet

Hovedfokuset i utformingen av rammeverket vårt var å få mest mulig ut av modellens kontekst.

Selv om modeller på enheten som Qwen 3.8 27B tilbyr kontekstvinduer på 260 000 tokens, fant vi empirisk ut at de begynner å slite utover 100 000 tokens. Vi holder derfor kjernerammeverket konsist: en minimal systemledetekst og et lite sett med kjerneverktøy.

Alle andre funksjoner er modularisert til on-demand-ferdigheter som lastes inn og ut gjennom hele banen. Vi designet disse ferdighetene for vanlige kunnskapsarbeidsoppgaver: forskning, datavitenskap, datavisualisering, dokumentoppretting, programvareutvikling og mer.

Rammeverket støtter også kontekstkomprimering, der foreldet kontekst summeres opp når en bane blir lang, slik at modellen holder seg innenfor sitt effektive vindu.

Koblinger som kommandolinjeverktøy

Daglig kunnskapsarbeid krever ofte koblinger som Gmail, GitHub, Outlook og Google Kalender. Disse eksponeres vanligvis for et rammeverk som MCP-servere, hvis store verktøidefinisjoner opptar en vesentlig del av konteksten. I stedet konverterte vi de mest brukte MCP-ene til kompakte, brukervennlige kommandolinjeverktøy, supplert med tilpassede ferdigheter som utnytter den begrensede effektive konteksten mye bedre.

Selvverifisering

Ytelsen forbedres også når agenten verifiserer sitt eget arbeid. Verifisering legger til ekstra trinn, men det forbedrer de endelige resultatene betraktelig og reduserer gapet til grensemodeller betydelig. Det kan utløses av selve modellen eller av et sett med kroker som overvåker banens helse og ber om selvverifisering når noe går galt.

Sandkassekjøring

Rammeverket utfører verktøy i en sandkasse på OS-nivå på brukerens enhet. Grensen begrenser prosesser, filbaner og nettverkstilgang i henhold til retningslinjer. Dette begrenser skaderadiusen til en feilaktig kommando. Hvis sandkassen er utilgjengelig, deaktiverer rammeverket seg selv før eventuelle verktøykall i stedet for å falle tilbake til usandkassekjøring.

Dette skil seg fra åpne kildekode-rammeverk som Pi og Hermes, som kjører kommandoer direkte med brukerens tillatelser som standard. I Computer er isolasjon alltid på, krever ingen konfigurasjon, og verktøy kan ikke kjøre uten det.

Diagrammet nedenfor viser hvordan disse prinsippene henger sammen i eksekveringsløkken. Orkestratoren er deterministisk rammeverkskode, ikke en språkmodell: den opprettholder løkken, setter sammen kontekst og håndhever retningslinjer. Den lokale modellen foreslår neste handling; orkestratoren utfører godkjente verktøykall i sandkassen og returnerer resultatene til modellen. Nettsøk, koblinger og rådgiverkall krysser enhetsgrensen bare når de er aktivert og godkjent.

Et lokalt rammeverk får mer ut av den samme modellen

Ved å bruke den samme lokale basismodellen sammenligner vi vårt lokale rammeverk med generelle alternativer på nettbasert forskning og multimodal dokumentforståelse. Alle rammeverk bruker Qwen 3.8 27B-modellen med middels resonnering, kjørende på en NVIDIA DGX Spark. Denne sammenligningen isolerer egenskapene som bidras av selve rammeverket, før eventuell ettertrening av modellen.

Vi fokuserer på disse to egenskapene fordi kunnskapsarbeid ofte kombinerer private dokumenter på brukerens enhet med offentlig informasjon fra nettet for å produsere en forankret artefakt. Nettsøk krever tilkobling, men modellslutning og behandling av private dokumenter forblir lokale. Lokale filer fungerer som den autoritative kilden, offentlige kilder legger til kontekst, og brukere kan deaktivere nettsøk fullstendig for helt frakoblet arbeid.

Nettforskning

Vi bygger vårt lokale rammeverk sammen med Perplexitys søkemotor, som har oppnådd topplasseringer i uavhengige evalueringer. Rammeverket får tilgang til den gjennom Search as Code-grensesnittet.

Vi evaluerer forskningskvalitet på 1 266 BrowseComp-oppgaver. Computer bruker Perplexitys søkeinfrastruktur sammen med vårt lokale rammeverk, mens Pi og Hermes stoler på Brave, deres anbefalte søkeleverandør. Computer når 66,7 % nøyaktighet, sammenlignet med 50,2 % for Pi og 43,9 % for Hermes.

Computer har også den laveste gjennomsnittlige registrerte ventetiden og tokenbruken: 402,1 sekunder og 852k tokens per oppgave, sammenlignet med 1 020,9 sekunder og 1,01 millioner tokens for Hermes, og 826,0 sekunder og 2,82 millioner tokens for Pi. Computer bruker derfor 61 % mindre ventetid og 16 % færre tokens enn Hermes, og 51 % mindre ventetid og 70 % færre tokens enn Pi.

Multimodal dokumentforståelse på enheten

Mange dokumenter bærer informasjon visuelt og er vanskelige å analysere som ren tekst: PDF-er, skannede sider, skjermbilder, diagrammer og presentasjoner. Disse arbeidsflytene er avhengige av OCR og bildeforståelse, og har mest nytte av en opprinnelig multimodal modell.

Rammeverket sender dokumentlister og bilder direkte til modellen, som forstår dem og kombinerer visuelle bevis med den ekstraherte teksten. Å behandle disse filene på enheten holder sensitive dokumenter og deres ekstraherte innhold private.

Vi evaluerer multimodal dokumentforståelse på ParseBench-100, et delsett på 100 oppgaver av ParseBench-benchmarken, med 20 oppgaver hver for diagrammer, layout, tabeller, tekstinnhold og formatering.

Computer når en gjennomsnittlig poengsum på 65,1 %, sammenlignet med 34,6 % for Hermes og 13,9 % for Pi. Den fullfører også oppgaver med minst tid og færrest tokens: i gjennomsnitt 60,6 sekunder og 20,1k tokens per oppgave, sammenlignet med 108,3 sekunder og 32,1k tokens for Hermes, og 410,5 sekunder og 829,1k tokens for Pi. Computer leder i alle fem dokumentkategorier, med sin største fordel på diagrammer. Layout forblir vanskelig for alle tre rammeverkene.

Tabell 1. ParseBench-100 gjennomsnittlig poengsum etter dokumentkategori for Computer-, Hermes- og Pi-rammeverkene med Qwen 3.8 27B-modellen på enheten. Computer leder i alle fem kategoriene.

Innukking av grensegapet med rådgivereskalering

Selv med et nøye utformet rammeverk overstiger de vanskeligste oppgavene fremdeles egenskapene til en kompakt modell på enheten. For slike oppgaver eksponerer rammeverket et rådgiververktøy: den lokale modellen kan konsultere en sterkere grensemodell når den trenger hjelp med planlegging, oppløsning av flertydighet, gjenoppretting fra gjentatte feil eller verifisering av det endelige resultatet.

Den lokale modellen avgjør når den skal be om råd, mens rammeverksorkestratoren beholder verktøymyndighet og kontrollerer hvilken kontekst som sendes. Eskalering er valgfritt. Brukeren avgjør om den skal aktiveres, og om hvert rådgiverkall skal godkjennes manuelt eller automatisk.

Før et rådgiverkall velger rammeverket ut relevant kontekst, bruker en PII-klassifisator til å flagge sensitiv informasjon, og viser brukeren hva som vil forlate enheten. Rådgiveren mottar bare den godkjente konteksten og returnerer tekstveiledning; den har ingen direkte tilgang til enhetens filer, verktøy eller samtaler. Dette forbedrer både kostnad og personvern, og vi planlegger å utforske denne retningen videre i fremtidig arbeid.

Vi tester denne tilnærmingen på utfordrende programvareutviklingsoppgaver, som krever sterk resonnering og er der en lokal modell oftest kommer til kort. Til dette bruker vi Terminal Bench 2.1, en populær benchmark med 89 oppgaver for koderingsagenter.

Vi ønsker å svare på to spørsmål: hvor mye av gapet til en grensemodell kan rådgivereskalering lukke, og til hvilken kostnad. Helt lokale modeller koster praktisk talt ingenting å kjøre, siden slutning skjer på brukerens maskinvare. Når modellen begynner å kalle rådgiveren, begynner den imidlertid å pådra seg API-kostnader.

Som baseline for grenseytelse bruker vi Claude Opus 5 som opererer i det lokale rammeverket; den lokale modellen er Qwen 3.8 27B. Til slutt parer vi de to: Qwen 3.8 27B utfører oppgaven og eskalerer til en Claude Opus 5-rådgiver når den trenger hjelp. Vi evaluerer ikke rådgivereskalering med Pi eller Hermes fordi ingen av dem tilbyr et tilsvarende rådgiververktøy; å legge til ett ville kreve modifisering av verktøyflaten og orkestreringslogikken, slik at resultatet ikke lenger ville representere hyllevare-rammeverket.

Rådgivereskalering hever Computers poengsum fra 59,6 % til 73,0 %, en økning på 13,5 prosentpoeng, til en estimert API-kostnad på 0,415 USD per kjøring. Å kjøre Claude Opus 5 alene når 82,4 % til 0,65 USD per kjøring. Eskalering gjenvinner dermed omtrent tre femtedeler av gapet til grensen til omtrent to tredeler av grensens kostnad, og brukeren avgjør når den avtalen er verdt å gjøre.

Ettertrening for rammeverket og kunnskapsarbeid

Så langt har vi holdt den lokale modellen uendret for å isolere hva rammeverket bidrar med. Med rammeverksdesignet på plass kommer de største gjenværende gevinstene fra å tilpasse selve modellen. Bruksdata for Perplexity Computer viser oss hva folk faktisk gjør for kunnskapsarbeid, som vi bruker til å syntetisere treningsdata. Vi ettertrenar den lokale modellen inne i Computer-rammeverket, styrt av den virkelige distribusjonen av oppgaver som brukere utfører.

Konkret identifiserer vi et mangfoldig sett med bruksområder som trener opp ulike modellkapasiteter, verktøy og koblinger. Fra disse bruksområdene syntetiserer vi realistiske miljøer for forsterkende læring og definerer utfordrende, men verifiserbare oppgaver: hver oppgave består av en instruksjon, et miljø og en verifikator som poengsetter det endelige resultatet, der miljøet er en Docker-beholder som rammeverket opererer i. Viktig nok inneholder de ingen ekte dokumenter eller brukerinformasjon, fordi oppgavene er syntetiske.

Vi bruker disse miljøene for totrinnstrening: avvisningsfinjustering etterfulgt av forsterkende læring. I det første trinnet kjører vi ut modellen mot hver oppgave flere ganger, velger de beste banene etter verifikatorpoengsum, og trener på dem med veiledet læring. Dette trinnet initialiserer modellen for det spesifikke rammeverket og oppgavedistribusjonen. I det andre trinnet finjusterer forsterkende læring modellen ytterligere, noe som gjør den mer robust.

Et delsett av oppgaver holdes tilbake fra trening og brukes til endelig evaluering; vi kaller dette tilbakeholdte settet for Local Knowledge Work Bench: 53 oppgaver som spenner over sju kategorier av daglig kunnskapsarbeid, fra dypgående forskning til dokumentoppretting. Vi vil snart publisere en teknisk rapport som beskriver modelltreningen i detalj, og vi planlegger å frigi denne evalueringsbenchmarken som åpen kildekode.

Vi ettertrenet Qwen 3.8 27B med denne tilnærmingen, og produserte en modell vi kaller PPLX 27B, og evaluerte den på Local Knowledge Work Bench. Med basismodellen Qwen 3.8 27B oppnår Computer den høyeste poengsummen (82,6 %, sammenlignet med 77,6 % for Pi og 74,0 % for Hermes) og bruker færrest tokens (520k, mot 681k for Pi og 634k for Hermes). Pi fullfører oppgaver raskest på 176 sekunder per oppgave, sammenlignet med 218 sekunder for Computer og 292 sekunder for Hermes. PPLX 27B løfter Computers poengsum til 85,4 %, til prisen av flere tokens (678k versus 520k). Den estimerte ventetiden er 250 sekunder.

Tabell 2. Oppgvekategorier for Local Knowledge Work Bench.

Konklusjon

Forskningen vår viser at en sterk modell med åpen kildekode, med kapabel lokal maskinvare og et rammeverk bygget for dem, kan håndtere ekte kunnskapsarbeid til nesten null slutningskostnad uten at sensitiv data trenger å forlate enheten.

På tvers av de ulike benchmarkene matchet eller overgikk Computer Hermes og Pi i nøyaktighet mens den kjørte Qwen 3.8 27B på en NVIDIA DGX Spark. Blant de tre benchmarkene som rapporterer latens og tokenbruk, var Computer raskest på BrowseComp og ParseBench-100 og brukte færrest tokens på alle tre; Pi var raskest på Local Knowledge Work Bench.

Gevinstene kom fra valg vi tok. Vi bygde et konsist lokalt rammeverk med ferdigheter som lastes ved behov. Vi konverterte koblinger til kompakte CLI-verktøy i stedet for MCP-servere. Utførelsen ble sandkasseisolert for sikkerhet.

Resultatene viser også hvor kompakte modeller har rom for forbedring. For eksempel, på de utfordrende kodingsoppgavene i Terminal Bench 2.1, henger den lokale modellen etter grensemodellen på tvers av alle tre rammeverkene. Rådgivereskalering innsnevrer, men lukker ikke fullstendig gapet; fortsatte forbedringer i modellkapasiteter og lokal maskinvare trengs fremdeles for å dytte ytelsen videre.

Formålet med å bygge rammeverket og modellen for lokale begrensninger er å gi brukere eksplisitt kontroll over hvilken informasjon som forlater maskinene deres. Det er også kostnadsfordeler for brukeren. Vi ser på dette som en del av et bredere skifte der stadig mer kapable agenter beveger seg fra ekstern infrastruktur til individuelle og lokale enheter. Vi forventer at fremskritt innen brikker, modeller og enheter kontinuerlig vil utvide spekteret og kvaliteten på kunnskapsarbeid som Portable Computer håndterer lokalt.