En lokal-först-agent för privat och kostnadseffektivt kunskapsarbete

Perplexity Portable Computer är en lokal-först-agent.

Hela stacken körs lokalt som standard. Modellen, kontrollmiljön, konversationen och banan finns alla på användarens maskin. Arbete som kräver omvärlden, såsom webbsökning, anslutning eller eskalering till en starkare rådgivarmodell i molnet, anropas endast när det är nödvändigt och styrs alltid av användaren. Känslig data lämnar därför aldrig enheten utan tillåtelse, och lokala modeller har ingen inferensavgift: systemet är privat och kostnadseffektivt av hänsyn till sin konstruktion.

En effektiv lokal-först-agent kräver att modellen och kontrollmiljön utformas tillsammans. Kontrollmiljöer för allmänna ändamål förutsätter en frontlinjemodell som kan absorbera långa kontexter, navigera i ett brett verktygsutbud och planera över långa horisonter. Lokala modeller är mindre tillförlitliga under dessa krav. Istället för att be en liten modell att hantera en kontrollmiljö byggd för en stor, formade vi de två runt varandra: en kontrollmiljö skräddarsydd efter modellens kapacitetsprofil, och en modell tränad i efterhand för att använda den kontrollmiljön effektivt.

Introduktion

Agentkapaciteten har under de senaste månaderna utvecklats snabbt inom ett brett spektrum av kunskapsarbetsuppgifter. Även om dessa framsteg ger stora vinster i produktivitet och effektivitet, utgör de också två utmaningar.

Tokenförbrukningen stiger snabbt, och därmed även den totala kostnaden. När intelligens nås via API:er för slutna modeller som körs på fjärrkluster, lämnar privat information och immateriella rättigheter användarens enhet vid varje förfrågan. Allt eftersom agenter skalas över individuella arbetsflöden och hela organisationer blir tokenutgifter och dataförflyttning allt svårare att styra.

Samtidigt har öppen källkods-modeller förbättrats i ännu snabbare takt. Framstegen är tydligast i mycket små och effektiva modeller som NVIDIA Nemotron 3.5 Lightning (30B totala parametrar), Qwen 3.6 (35B) och Qwen 3.8 (27B). Dessa små modeller presterar över sin viktklass och klarar nu komplexa agentiska arbetsflöden. Maskinvara för lokal inferens utvecklas parallellt: system som NVIDIA DGX Spark kan nu köra dessa modeller lokalt. Tillsammans gör dessa trender full drift på enheten praktisk samtidigt som de tillåter användare att välja externa funktioner vid behov, såsom webbsökning, anslutning eller molnmodelleskalering.

Detta lokal-först-tillvägagångssätt möjliggör betydande kostnadsbesparingar, eftersom lokal inferens undviker per-token-API-avgifter. Det löser också naturligt integritets- och immaterialrättsproblemen: privata token behöver aldrig överföras till fjärrkluster och förblir säkert inom gränsen för den lokala enheten.

I juni introducerade vi den första hybrida lokal-server-inferensorkestratorn som avgör vilket arbete som ska köras på enheten och vilket arbete som ska gå till agenter i molnet. Här förklarar vi hur vi byggde en sådan lokal-först-agent, inklusive kontrollmiljön och modellerna som samoptimerats för varandra.

Vi ger en översikt över de viktigaste designvalen, utvärderar Computer mot populära öppna kontrollmiljöer för allmänna ändamål (Hermes och Pi) över tre offentliga riktmärken och vår interna Local Knowledge Work Bench. På vårt riktmärke, med modellen Qwen 3.8 27B som körs på en NVIDIA DGX Spark, uppnår Computer det högsta poänget, 82,6% mot 77,6% för Pi och 74,0% för Hermes. PPLX 27B, vår modell som tränats i efterhand ovanpå Qwen 3.8 27B, höjer poängen ytterligare till 85,4%.

Utforma kontrollmiljön kring den lokala modellen

Även om kompakta modeller på enheten redan är ganska kapabla, släpar de fortfarande efter större frontlinjemodeller i prestanda. En noggrant utformad kontrollmiljö krävs för att styra dessa modeller effektivt och för att hantera deras begränsningar.

Populära kontrollmiljöer med öppen källkod som Pi och Hermes har visat sig vara generella: de fungerar bra med ett brett utbud av modeller i olika storlekar och klasser. Men de är inte optimerade för kapaciteten hos modeller på enheten. Vi utformade den lokala kontrollmiljön specifikt för denna miljö, kring några nyckelprinciper.

Kontexteffektivitet

Huvudfokus vid utformningen av vår kontrollmiljö var att få ut det mesta av modellens kontext.

Även om modeller på enheten som Qwen 3.8 27B erbjuder kontextfönster på 260K token, fann vi empiriskt att de börjar få problem bortom 100K token. Vi håller därför den ursprungliga kontrollmiljön kortfattad: en minimal systemprompt och en liten uppsättning kärnverktyg.

Alla andra funktioner är modulariserade i on-demand-färdigheter som laddas in och ut under banans gång. Vi utformade dessa färdigheter för vanliga kunskapsarbetsuppgifter: forskning, datavetenskap, datavisualisering, dokumentskapande, mjukvaruteknik med mera.

Kontrollmiljön stöder också kontextkomprimering, vilket sammanfattar föråldrad kontext när en bana blir lång så att modellen stannar kvar inom sitt effektiva fönster.

Anslutning som kommandoradsverktyg

Dagligt kunskapsarbete kräver ofta anslutning som Gmail, GitHub, Outlook och Google Calendar. Dessa exponeras vanligtvis för en kontrollmiljö som MCP-servrar, vars stora verktygsdefinitioner förbrukar en avsevärd del av kontexten. Istället konverterade vi de mest använda MCP:erna till kompakta, lättanvända kommandoradsverktyg, kompletterade med anpassade färdigheter som gör mycket bättre användning av den begränsade effektiva kontexten.

Självverifiering

Prestandan förbättras också när agenten verifierar sitt eget arbete. Verifiering lägger till extra steg, men det förbättrar slutresultaten avsevärt och minskar avsevärt gapet till frontlinjemodeller. Det kan utlösas av modellen själv eller av en uppsättning krokar som övervakar banans hälsa och begär självverifiering när något går fel.

Sandlådeexekvering

Kontrollmiljön exekverar verktyg i en sandlåda på OS-nivå på användarens enhet. Gränsen begränsar processer, filsystemssökvägar och nätverksåtkomst enligt policy. Detta begränsar skaderadien för ett felaktigt kommando. Om sandlådan inte är tillgänglig inaktiverar kontrollmiljön sig själv före alla verktygsanrop snarare än att försämras till exekvering utan sandlåda.

Detta skiljer sig från kontrollmiljöer med öppen källkod som Pi och Hermes, som som standard kör kommandon direkt med användarens behörigheter. I Computer är isolering alltid på, kräver ingen konfiguration och verktyg kan inte köras utan den.

Diagrammet nedan visar hur dessa principer hänger ihop i exekveringsloopen. Orkestratorn är deterministisk kontrollmiljökod, inte en LLM: den upprätthåller loopen, sammanställer kontext och upprätthåller policy. Den lokala modellen föreslår nästa åtgärd; orkestratorn utför godkända verktygsanrop i sandlådan och returnerar deras resultat till modellen. Webbsökning, anslutning och rådgivaranrop korsar enhetsgränsen endast när de är aktiverade och godkända. Känslig data lämnar därför aldrig enheten utan tillåtelse.

En lokal kontrollmiljö får ut mer av samma modell

Med samma basmodell på enheten jämför vi vår lokala kontrollmiljö med alternativ för allmänna ändamål gällande webbforskning och multimodal dokumentförståelse. Alla kontrollmiljöer använder modellen Qwen 3.8 27B med medium resonemang, som körs på en NVIDIA DGX Spark. Denna jämförelse isolerar de egenskaper som tillförs av själva kontrollmiljön, före någon träning av modellen i efterhand.

Vi fokuserar på dessa två funktioner eftersom kunskapsarbete ofta kombinerar privata dokument på användarens enhet med offentlig information från webben för att producera en grundad artefakt. Webbsökning kräver anslutning, men modellinferens och bearbetning av privata dokument förblir lokala. Lokala filer fungerar som den auktoritativa källan, offentliga källor lägger till kontext och användare kan inaktivera webbsökning helt för helt offline-arbete.

Webbforskning

Vi bygger vår lokala kontrollmiljö tillsammans med Perplexity sökmotor, som har uppnått topplaceringar i oberoende utvärderingar. Kontrollmiljön kommer åt den via gränssnittet Search as Code.

Vi utvärderar forskningskvalitet på 1 266 BrowseComp-uppgifter. Computer använder Perplexity sökinfrastruktur tillsammans med vår lokala kontrollmiljö, medan Pi och Hermes förlitar sig på Brave, deras rekommenderade sökleverantör. Computer når 66,7% noggrannhet, jämfört med 50,2% för Pi och 43,9% för Hermes.

Computer har också den lägsta genomsnittliga inspelade väggtiden och tokenanvändningen: 402,1 sekunder och 852k token per uppgift, jämfört med 1 020,9 sekunder och 1,01 miljoner token för Hermes, och 826,0 sekunder och 2,82 miljoner token för Pi. Computer använder därför 61% mindre väggtid och 16% färre token än Hermes, och 51% mindre väggtid och 70% färre token än Pi.

Multimodal dokumentförståelse på enheten

Många dokument bär information visuellt och är svåra att tolka som vanlig text: PDF-filer, skannade sidor, skärmdumpar, diagram och presentationer. Dessa arbetsflöden är beroende av OCR och bildförståelse, och drar störst nytta av en nativt multimodal modell.

Kontrollmiljön skickar dokumentsidor och bilder direkt till modellen, som förstår dem och kombinerar visuellt bevis med den extraherade texten. Att bearbeta dessa filer på enheten håller känsliga dokument och deras extraherade innehåll privata.

Vi utvärderar multimodal dokumentförståelse på ParseBench-100, en delmängd på 100 uppgifter av riktmärket ParseBench, med 20 uppgifter vardera för diagram, layout, tabeller, textinnehåll och formatering.

Computer når en genomsnittlig poäng på 65,1%, jämfört med 34,6% för Hermes och 13,9% för Pi. Den slutför också uppgifter med minst tid och färst token: i genomsnitt 60,6 sekunder och 20,1k token per uppgift, jämfört med 108,3 sekunder och 32,1k token för Hermes, och 410,5 sekunder och 829,1k token för Pi. Computer leder i alla fem dokumentkategorier, med sin största fördel på diagram. Layout förblir svårt för alla tre kontrollmiljöerna.

Tabell 1. Genomsnittligt poäng för ParseBench-100 per dokumentkategori för kontrollmiljöerna Computer, Hermes och Pi med modellen Qwen 3.8 27B på enheten. Computer leder i alla fem kategorier.

Minska gapet till frontlinjen med rådgivareskalering

Även med en noggrant utformad kontrollmiljö överstiger de svåraste uppgifterna fortfarande kapaciteten hos en kompakt modell på enheten. För sådana uppgifter exponerar kontrollmiljön ett rådgivarverktyg: den lokala modellen kan rådfråga en starkare frontlinjemodell när den behöver hjälp med planering, att lösa tvetydigheter, återhämtning från upprepade fel eller att verifiera slutresultatet.

Den lokala modellen avgör när råd ska begäras, medan kontrollmiljöns orkestrator behåller verktygsbehörighet och styr vilken kontext som skickas. Eskalering är valfri. Användaren avgör om den ska aktiveras och om varje rådgivaranrop ska godkännas manuellt eller automatiskt.

Före ett rådgivaranrop väljer kontrollmiljön ut relevant kontext, tillämpar en PII-klassificerare för att flagga känslig information och visar användaren vad som skulle lämna enheten. Rådgivaren tar endast emot den godkända kontexten och returnerar textvägledning; den har ingen direkt åtkomst till enhetens filer, verktyg eller konversationer. Detta förbättrar både kostnad och integritet, och vi planerar att utforska denna riktning ytterligare i framtida arbete.

Vi testar detta tillvägagångssätt på utmanande mjukvaruutvecklingsuppgifter, som kräver starkt resonemang och där en lokal modell oftast kommer till kort. För detta använder vi Terminal Bench 2.1, ett populärt riktmärke med 89 uppgifter för kognitiva agenter.

Vi vill besvara två frågor: hur stor del av gapet till en frontlinjemodell kan rådgivareskalering stänga, och till vilken kostnad. Helt lokala modeller kostar i princip ingenting att köra, eftersom inferens sker på användarens maskinvara. När modellen väl börjar anropa rådgivaren börjar den dock ådra sig API-kostnader.

Som baslinje för frontlinjeprestanda använder vi Claude Opus 5 som körs i den lokala kontrollmiljön; den lokala modellen är Qwen 3.8 27B. Slutligen parar vi ihop de två: Qwen 3.8 27B utför uppgiften och eskalerar till en Claude Opus 5-rådgivare när den behöver hjälp. Vi utvärderar inte rådgivareskalering med Pi eller Hermes eftersom ingen av dem tillhandahåller ett motsvarande rådgivarverktyg; att lägga till ett skulle kräva att dess verktygsyta och orkestreringslogik modifierades, så resultatet skulle inte längre representera den färdiga kontrollmiljön.

Rådgivareskalering höjer Computers poäng från 59,6% till 73,0%, en ökning med 13,5 procentenheter, till en beräknad API-kostnad på $0,415 per körning. Att köra Claude Opus 5 enbart når 82,4% till $0,65 per körning. Eskalering återställer därmed ungefär tre femtedelar av gapet till frontlinjen till ungefär två tredjedelar av frontlinjens kostnad, och användaren avgör när den avvägningen är värd att göra.

Efterträning för kontrollmiljön och kunskapsarbete

Hittills har vi hållit den lokala modellen oförändrad för att isolera vad kontrollmiljön bidrar med. Med kontrollmiljöns design på plats kommer de största återstående vinsterna från att anpassa själva modellen. Användningsdata för Perplexity Computer visar oss vad människor faktiskt gör för kunskapsarbete, vilket vi använder för att syntetisera träningsdata. Vi eftertränar den lokala modellen inuti Computer-kontrollmiljön, ledd av den verkliga fördelningen av uppgifter som användare utför.

Konkrethet mätt identifierar vi en mångfald av användningsfall som utövar olika modellkapaciteter, verktyg och anslutning. Från dessa användningsfall syntetiserar vi realistiska förstärkningsinlärningsmiljöer och definierar utmanande men verifierbara uppgifter: varje uppgift består av en instruktion, en miljö och en verifierare som poängsätter slutresultatet, där miljön är en Docker-container som kontrollmiljön verkar i. Viktigt är att eftersom uppgifterna är syntetiska innehåller de inga verkliga dokument eller användarinformation.

Vi använder dessa miljöer för träning i två steg: avvisningsfinjustering följt av förstärkningsinlärning. I det första steget kör vi ut modellen mot varje uppgift flera gånger, väljer ut de bästa banorna efter verifierarpoäng och tränar på dem med övervakad inlärning. Detta steg initierar modellen för den specifika kontrollmiljön och uppgiftsfördelningen. I det andra steget finjusterar förstärkningsinlärning modellen ytterligare, vilket gör den mer robust.

En delmängd av uppgifter hålls undan från träning och används för slutlig utvärdering; vi kalla denna undanhållna uppsättning för Local Knowledge Work Bench: 53 uppgifter som spänner över sju kategorier av dagligt kunskapsarbete, från djupgående forskning till dokumentskapande. Vi kommer snart att publicera en teknisk rapport som beskriver modellträningen i detalj, och vi planerar att öppna källkoden för detta utvärderingsriktmärke.

Vi eftertränade Qwen 3.8 27B med detta tillvägagångssätt, vilket producerade en modell vi kallar PPLX 27B, och utvärderade den på Local Knowledge Work Bench. Med basmodellen Qwen 3.8 27B uppnår Computer det högsta poänget (82,6%, jämfört med 77,6% för Pi och 74,0% för Hermes) och använder färst token (520k, mot 681k för Pi och 634k för Hermes). Pi slutför uppgifter snabbast på 176 sekunder per uppgift, jämfört med 218 sekunder för Computer och 292 sekunder för Hermes. PPLX 27B lyfter Computers poäng till 85,4%, till priset av fler token (678k mot 520k). Dess beräknade väggtid är 250 sekunder.

Tabell 2. Uppgiftskategorier för Local Knowledge Work Bench.

Slutsats

Vår forskning visar att en stark modell med öppen källkod, med kapabel lokal maskinvara och en kontrollmiljö byggd för dem, kan hantera verkligt kunskapsarbete till nästan noll inferenskostnad utan att känslig data behöver lämna enheten.

Över de olika riktmärkena matchade eller överträffade Computer Hermes och Pi i noggrannhet medan den körde Qwen 3.8 27B på en NVIDIA DGX Spark. Bland de tre riktmärken som rapporterar latens och tokenanvändning var Computer snabbast på BrowseComp och ParseBench-100 och använde färst token på alla tre; Pi var snabbast på Local Knowledge Work Bench.

Vinsterna kom från val vi gjorde. Vi byggde en kortfattad lokal kontrollmiljö med färdigheter som laddas vid behov. Vi konverterade anslutning till kompakta CLI-verktyg istället för MCP-servrar. Exekvering sandlådades för säkerhet.

Resultaten visar också var kompakta modeller har utrymme för förbättringar. Till exempel, på de utmanande kodningsuppgifterna i Terminal Bench 2.1, släpar den lokala modellen efter frontlinjemodellen över alla tre kontrollmiljöerna. Rådgivareskalering minskar men stänger inte helt gapet; fortsatta förbättringar av modellkapacitet och lokal maskinvara behövs fortfarande för att driva prestandan vidare.

Syftet med att bygga kontrollmiljön och modellen för lokala begränsningar är att ge användarna explicit kontroll över vilken information som lämnar deras maskiner. Det finns också kostnadsfördelar för användaren. Vi ser dessa som en del av en bredare skiftning där allt mer kapabla agenter flyttar från fjärrinfrastruktur till individuella och lokala enheter. Vi förväntar oss att framsteg inom chip, modeller och enheter kontinuerligt kommer att utöka utbudet och kvaliteten på det kunskapsarbete som Portable Computer hanterar lokalt.