Lad os være ærlige: on-device AI har længe været noget, der virkede godt på en scene og i nicheprojekter. OpenJarvis rokker ved det billede. Forskere fra Stanford og Lambda Labs udgiver nu et open source-framework (Apache 2.0), som kører agenter, hukommelse og læring lokalt på enheden. Ifølge deres paper lander åbne vægtmodeller konfigureret i OpenJarvis i gennemsnit inden for 3,2 procentpoint af bedste cloud-model – og under deres benchmarkprotokol rapporterer de cirka 800× lavere marginal API-omkostning pr. forespørgsel og cirka 4× lavere latenstid end skybaseline. Kilderne er åbne, men tallene er betinget af setup og protokol. Det er vigtigt.
Repoet gik live i marts 2026, arXiv-paperet i maj (arXiv:2605.17172). Ifølge MarkTechPost-sammenfatningen er der allerede cirka 5,4k stjerner og 1,2k forks i juni 2026 – øjebliksbilleder, javist, men det peger på momentum. Vi har fulgt med tæt, for vi har kunder, der spørger uge for uge: Kan vi flytte assistenterne ud på kanten uden at sænke kvaliteten?
Hvad OpenJarvis er
OpenJarvis er et framework, ikke en enkelt model. Tænk det som fem byggesten, der kan byttes uafhængigt. Pointen er jordnær: du beskriver hele systemet i en deklarativ spec, og så kan den samme adfærd køre på tværs af hardware og motorer, så længe du holder dig til specifikationen.
De fem primitives er defineret sådan: Intelligence (modellen, vægte, generation og quantization), Engine (inference-runtime, batching, KV-cache, hardwarevej), Agents (selve reasoning-loopen som ReAct eller CodeAct, systemprompter, værktøjspolitik), Tools og Memory (connectors til data og beskedkanaler, MCP-understøttelse) samt Learning (optimering, fx LoRA, DSPy, GEPA eller LLM-guided spec search). Hver del kan udskiftes, og hele pakken serialiseres i en TOML-spec. Det lyder tørt, men i praksis er det netop her, teams ofte taber tid: små forskelle i opsætning – bare en anden KV-cache – skaber rod.
Lidt om spec og søgning
Den anden tekniske nyhed er LLM-guided spec search. Under optimering – ikke i produktion – spiller en frontier cloud-model lærer: den læser traces, finder fejlklumper og foreslår redigeringer på tværs af Intelligence, Engine, Agents og Tools & Memory. En gate accepterer kun ændringer, hvis de forbedrer målfejlene uden meningsfulde regressioner andetsteds. Default-tolerance er 1 procentpoint. Når spec’en er optimeret, kører inference on-device uden cloud-kald. Læreren er et søgetidsfænomen, ikke en driftsafhængighed.
Det er elegant. Og i vores erfaring (nu bliver jeg subjektiv) løfter en lille justering i tool-use-politik ofte mere end at jagte en større model. At sætte tal på tværs af flere primitives – ikke kun prompter – giver mening.
Hvad forskerne målte
Ifølge MarkTechPost’ opsummering tester holdet 11 lokale modeller på tværs af fire familier – Qwen3.5, Gemma4, Nemotron og Granite – med cloudbaselines som Claude Opus 4,6, GPT-5,4 og Gemini 3,1 Pro. Under deres protokol lander OpenJarvis-konfigurerede modeller i gennemsnit inden for 3,2 procentpoint af bedste cloud-model. Den påstand er stærk, men læs note: det er gennemsnit over deres benchmarkpakke.
De rapporterer cirka 800× lavere marginal API-omkostning per query og cirka 4× lavere latenstid. Det er stort – men kun under den beskrevne protokol, hvor læreren bruges ved søgetid og amortiseres over anvendelse. Vi anbefaler at dykke i selve arXiv-pdf’en for at validere målemetode, queries pr. dag og den konkrete amortiseringsmodel. Tallene er lovende, men man bør teste dem på egne workloads.
Benchmarkbetingelser og begrænsninger
OpenJarvis er evalueret på otte benchmarks med i alt 508 opgaver: fra tool calling (ToolCall-15) og agentiske workflows (PinchBench) til kundeservice (τ-Bench V2, τ²-Bench Telecom), kode (LiveCodeBench), generel assistance (GAIA) samt dyb research (LiveResearchBench, DeepResearchBench). Kontekstvinduer er modelafhængige, og latenstid afhænger af engine, batch og KV-cache. Klassikere i feltet.
Vigtig nuance, som vi selv har brændt fingrene på: små forskelle i quantization og cache-politik kan flytte både nøjagtighed og ventetid markant. Benchmarkprotokoller skjuler tit de små hjørner, hvor virkeligheden siver ind: netværksforhold, baggrundsbelastning, kolde caches. Test på eget grej.
Infrastruktur og økosystem
OpenJarvis understøtter flere inference engines: Ollama, vLLM, SGLang, llama.cpp, Apple Foundation Models og Exo blandt andet. Projektet hævder 25+ dataconnectors og 32+ beskedkanaler, MCP-native, og udskiftelige memory backends. Installation beskrives som én kommando og cirka tre minutter på bredbånd. Frameworket er testet på syv hardwareplatforme fra Mac Mini M4 til NVIDIA DGX. Det åbner for brede edge-scenarier – og ja, for at ting kan gå galt på uventede måder.
Repo-metrics i juni 2026 viser cirka 5,4k stjerner og 1,2k forks. Snapshot, ja. Inden man beslutter strategi, giver det mening at krydstjekke issues, seneste commits og CI-status. Vi kigger altid efter fordelingen mellem lukkede og åbne fejl – og om dokumentationen faktisk matcher koden.
Hvad betyder det i praksis
Kort sagt: lavere marginale omkostninger, hurtigere svar og bedre datakontrol. For virksomheder med høje volumener – 100+ forespørgsler per dag per agent – giver papirets tal mening, fordi læreren kun bruges ved søgetid, ikke ved hver forespørgsel. Det mindsker regningen dramatisk i drift.
Privatliv og compliance vinder også. On-device inference kan holde persondata og følsomme logs tættere på kildesystemerne. Men I skal stadig have logning, kryptering og adgangskontrol på plads – og definere, hvad der aldrig forlader enheden. Vi så en klinisk assistent blive brugbar først, da vi fjernede en enkelt cloud-hop i et triage-flow: ventetiden faldt, og lægen holdt op med at se assistenten som tidsrøver.
Tre scenarier vi ville starte med
- Kundesupport-assistent på edge: Kører på kontaktcentrets egne maskiner, integreret til CRM og vidensbase via connectors. Måler på first response time, løsningsrate og antallet af eskalationer. On-device mindsker også risiko ved ticket-tekst med persondata.
- Medicinsk triage-prototype: Lokalt på hospitalets sikre net, med begrænset tool-use og stærk auditlog. Fokus på latenstid fra input til anbefalet næste trin. Start uden læring i drift – kun søgetid-læring under kontrollerede forhold.
- Factory edge-monitor: Agent der læser sensordata, sammenholder med manualer og SOP’er og foreslår fejlsøgning. Kører på en lille workstation ved linjen. Offline-tolerant, lokal cache, rullet ud med signeret vægtpakke.
Engineering- og driftsudfordringer
Modellivscyklus: Hvordan opdaterer I vægte, prompter og spec uden at knække kompatibilitet? Er vægte signeret? Hvem godkender en ny gate-tolerance? Erfaringen: rollback skal være to klik, ikke ti.
Hardwarevariationer: Quantization-formater, KV-cache-strategi og batching opfører sig forskelligt på Mac M-serien vs. NVIDIA. Der kan være 20–40 procent forskel i latenstid alene på cache-opsætning. Den slags ses ikke i en pæn benchmarktabel.
Observability og MLOps: On-device betyder, at I ikke bare kan sende alt til et sky-dashboard. I skal have telemetri uden at eksportere følsomme data. Vi kører typisk på fire kernemetrics: latenstid, accuracy drift over faste eval-samplinger, ressourceforbrug og regressioner udløst af spec-edits. Den sidste har overrasket os, især når tool-politikker bliver for aggressive.
En kort POC-tjekliste
- Definér scenariet og et lille eval-sæt med ground truth. Ikke stort, bare stabilt.
- Vælg lokal model og engine per mål-hardware. Start simpelt, fx Gemma4 via Ollama eller vLLM.
- Skriv første TOML-spec og kør LLM-guided spec search i en kontrolleret pipeline. Log gate-beslutningerne.
- Sæt observability op fra dag 1: latency, accuracy drift, ressourceprofil, rollback-test.
- Læg en plan for opdatering og signering af vægte og spec. Test rollback på koldstart.
- Kør POC i 8–12 uger med to devs og en ML-ingeniør. Mål på cost, latenstid og compliance-lempelser.
Governance, compliance og dataansvar
On-device fjerner ikke sporbarhedsbehovet. Tværtimod. Hvis agenter må kalde værktøjer, skal hvert tool-kald kunne følges tilbage. Krypter lagring lokalt, brug som minimum rollebaseret adgang og gerne attributbaseret styring til de følsomme connectors.
Hjælper on-device mod GDPR-udfordringer? Nogle, ja: data forbliver lokalt, mindre deling med tredjepart. Men modellicenser til vægte og træningsdata er stadig et emne, og logge kan indeholde persondata. Husk også, at lærerfasen (search-time) involverer en cloud-model i forskernes opsætning, så afklar datapolitik præcist ved optimering. Drift kan være 100 procent lokal, men optimering kræver klare rammer.
Kontekst og konkurrence
OpenJarvis bygger videre på forskerholdets “Intelligence Per Watt”-arbejde: lokale modeller håndterede allerede 88,7 procent af single-turn chat og reasoning ved interaktiv latenstid, og effektiviteten forbedrede sig 5,3× fra 2023 til 2025. Det passer ind i en bredere bevægelse: Apple Foundation Models på enheder, et modnende Ollama-økosystem og flere runtime-motorer, der barberer overhead.
Sideløbende ser vi forskning i agentadfærd – MIT CSAIL og Harvard SEAS har fx brugt en “Battleship”-opsætning til at studere, hvordan agenter stiller bedre spørgsmål. Det konkurrerer ikke med OpenJarvis som framework, men peger på, at agenters spørgeteknik ofte er flaskehalsen – ikke kun modellen. Godt at huske, når et POC føles dumt uden at man ved hvorfor.
Hvor lander vi hos Snilld
OpenJarvis rammer noget rigtigt: en praktisk, deklarativ tilgang, der løfter lokale modeller tæt på cloud uden at låse jer til en bestemt motor. I praksis vil en hybrid-arkitektur være mest robust de næste 12 måneder: edge-first til realtid og privat data, cloud til tunge læringsfaser og specialværktøjer. Vi bruger interne scripts til at sammenligne latenstid og nøjagtighed på Mac M-maskiner kontra DGX og har skabeloner til TOML-specs og CI-checks – det gør adoptionen mindre skrøbelig.
Roadmap, hvis vi skulle vælge: 1) vælg ét forretningskritisk flow med reel smerte fra ventetid eller cost, 2) byg en lille POC på 8–12 uger, 3) kør LLM-guided spec search med stram gate og audits, 4) mål konsekvent på cost, latenstid og fejltyper, 5) planlæg rollout med signering, rollback og hardwareprofil pr. site. Ikke fancy. Bare disciplineret.
Usikkerheder vi holder øje med
Benchmark-reproducerbarhed: Vi vil gerne se uafhængige gentagelser af de rapporterede cirka 800× cost og cirka 4× latenstid på andre workloads og hardware. Amortisering af læreromkostning skal tjekkes mod rigtige brugsmønstre.
Engine-detaljer: Hvilke præcise quantization-formater, batching og KV-cache-opsætninger blev brugt per engine i evalueringen? De ting flytter nålen. Også energimålinger på små edge-maskiner mangler ofte i litteraturen, selv om det er centralt for drift.
Sikkerhedsmodellen ved drift: signering af vægte, håndtering af secrets for connectors og robuste rollback-procedurer i feltet. Vi efterlyser også flere offentlige cases for gate-konfiguration og failure modes, når lærerens forslag skaber utilsigtede regressioner.
Konklusion
Hvad er nyt? OpenJarvis gør on-device agenter, hukommelse og læring praktisk med en samlet, deklarativ spec og en søgetidslærer, der løfter kvaliteten – uden at binde driften til skyen. Hvem vinder tidligt? Dem med høj volumen, stram compliance og lav tolerancetærskel for forsinkelser. Er det plug-and-play? Nej. Men tættere på end sidste år. Mest overraskende for os er, hvor meget der hentes ved at optimere på tværs af primitives. Resten opdager man først, når man sidder med det i hænderne.
