· 6 min read

En designassistent som kjører på enheten din - Ingen konto, ingen server

PinePaper 's on-device AI assistent gjør en spørsmål til en ekte scene ved hjelp av en språkmodell som kjører helt i nettleseren din. Her er arkitekturen - begrensede verktøysamtaler, to leverandører, og en ærlig konto om hva en liten modell kan og ikke kan gjøre.

Forutsetningen

De fleste AI-designverktøy sender en melding til en server, kjører en stor modell og sender koden tilbake. Det trenger en konto, en nettverksrundtur og tillit til at arbeidet ditt passerer andres infrastruktur.

Vi ønsket å vite hvor langt den andre ekstremen går: En designassistent der modellen kjører på din egen maskin. Ingen konto. Ingen opplasting. Speeden forlater aldri nettleseren. Dette bor nå i PinePapers redaktør som en eksperimentell AI / Code → Assistant-fanen, og dette innlegget er en ærlig konto om hvordan det fungerer og hvor det blir kort.

Hvorfor ikke bare spørre modellen for kode?

Den åpenbare tilnærmingen er å be on-device-modellen om å skrive JavaScript mot PinePapers API og kjøre den. Vi prøvde det. Det mislykkes.

Små modeller — de som passer på en bærbar datamaskin - har ingen kunnskap om en bestemt apps API. Spør en 0.5–2B-modell for å ringe PinePaper.create() og den improviserer: en nøkkel metoden ikke leser (en SVG-stil fill hvor API forventer color), en metode den forestillet seg, argumenter i feil form. Utgangen * ser ut som kode og stille gjør feil ting.

Så vi ber ikke om kode. Vi ber om en begrenset liste over verktøysamtaler:

[
  { "name": "pinepaper_set_background_color", "arguments": { "color": "#0F0F1A" } },
  { "name": "pinepaper_create_item", "arguments": { "itemType": "star", "x": 400, "y": 300, "radius": 90, "color": "#E74C3C", "animationType": "pulse" } }
]

Den samme ordforråd PinePapers MCP-server eksponerer for eksterne agenter - men sendt ut av en modell som kjører lokalt, og utført på lerret gjennom en liten avsender.

Gjør ugyldig utdata umulig

Nøkkeltrekket er begrenset dekoding. I stedet for å håpe at modellen produserer en gyldig form, begrenser vi * hvilke tegn det til og med har lov til å utstede: *

  • På Chromes innebygde Prompt API (Gemini Nano) passerer vi et JSON skjema som en responsbegrensning. Modellen kan bare produsere gjenstander skjemaet tillater - med additionalProperties: false, ethvert argument skjemaet ikke definerer er bokstavelig talt ikke representerbar.
  • WebLLM (en åpen modell som kjører på WebGPU), legger vi ved en EBNF grammatikk via XGrammar. Gramatikken dikterer strukturen; modellen fyller bare i verdiene.

Begge produserer samme verktøy-kall form. En liten reparasjon pass så berger nær-mangler en liten modell fortsatt gjør - en droppet name, argumenter uten wrapper- ved å utlede verktøyet fra argumentformen. Resultatet er at " trekk en grønn pentagon" blir en ekte create_item-samtale i stedet for en feil.

Bytt mellom de tre nedenfor. De to begrensede alternativene ser identiske ut formål: det er påstanden. Hva endringer mellom dem er mekanismen, ikke utfall.

Interactive demo — open in editor pp:PinePaper

To leverandører, én kontrakt

On-device AI er ikke en ting — det avhenger av nettleseren:

  • Browser AI — Chrome er innebygd Gemini Nano (window.LanguageModel). Modellen leveres med nettleseren; det er ingenting å laste ned fra oss. Dette er den mest pålitelige on-device banen i dag, fordi JSON-skema begrensning er billig og godt støttet.
  • PinePaper AIWebLLM kjører en Qwen2.5-modell i en WebGPU-nettleser. Den laster ned en modell en gang (cached deretter), og kjører deretter frakoblet.
  • Språk — ikke-engelske spørsmål oversettes til engelsk on-device først (via nettleserens innebygde oversetter), fordi de små kodeorienterte modellene er engelsk-sentriske. Den genererte scenen er den samme uansett hurtigspråk.

Brukeren velger motoren; alt nedstrøms - den begrensede, eksekutoren, lerretet — er identisk.

Redigerer, ikke bare genererer

En one-shot generator er ikke en assistent. For å støtte " gjør stjernen rød" må modellen vite hva som allerede er på lerretet. Så hver tur vi mate det et kompakt øyeblikksbilde av de aktuelle elementene - deres ids, typer og farger - akkurat som en server-side chat ville. " Gjør stjernen rød - deretter løser til et ekte modify_item-samtale mot elementets id. (Og fordi en liten modell noen ganger refererer til "the circle" når det betyr stjernen, løser eksekutoren uklare referanser mot live lerret.)

Samtaleloggen holdes på enheten i lokal lagring. Ikke noe om det sendes noe sted - med mindre du eksplisitt velger å dele feilaktige spørsmål, noe som hjelper oss å forbedre spørringene og grammatikken.

Når den lille modellen ikke er nok - eskalere

Her er den ærlige delen: a 0,5–2B-modellen er det svakeste nivået. Begrenset dekodingsgaranti * gyldig struktur*, men modellen må fortsatt velge riktig verktøy og fornuftige verdier, og det vil ikke alltid. Be om en pentagon og en under-spesifisert modell gir deg en heksagon; spør to ganger etter - rød - og det kan kjøre en generator i stedet.

Så arkitekturen behandler on-device som det * første * nivå, ikke den eneste. Etter noen mislykkede forsøk tilbyr assistenten å hand hele samtalen opp til Cloud-modellen — samme hensikt, samme lerret, en langt mer dyktig modell - og du fortsetter akkurat der du sluttet. Lav troskap, gratis og privat, med en ett-klikk sti til høy troskap når du trenger det.

Hva vi har lært

  • Begrenser beat questing. En bakket systemprompt hjelper; en grammatikk / skjema som gjør ugyldig utgang umulig hjelper mye mer. Den største pålitelighetshopp kom fra begrenset dekoding, ikke fra en bedre rask.
  • Modelstørrelsen dominerer fortsatt. Går fra en 0,5B til en 1,5B-modell merkbart forbedret hvor ofte assistenten plukker riktig verktøy. Det er ikke noe som gjør en liten modell til en smart.
  • Den fulle grammatikken kan være for stor. Vår første grammatikk kodet * alle * mulige operasjon - innbefatter en avgrenset lengdeveiklukke for vilkårlig tegningskode. Det var så stort at dekodet sto på siden. En kompakt grammatikk som dekker felles operasjoner er riktig standard; full overflate er opt-in.
  • Kjør det av hovedtråden. En modell som gjør forskjell på UI-tråden fryser siden. WebLLM kjører i en Web Worker slik at redaktøren forblir responsiv mens en modell laster og genererer.

Det neste

Dette er eksperimentelt og bedre. På veikartet:

  • Wider verktøydekning i den begrensede banen — mer av PinePapers operasjoner uttrykkelig uten freeform escape luke.
  • Større on-device modeller som WebGPU modell kataloger vokser, handel nedlastingsstørrelse for pålitelighet.
  • En tettere eval loop — ved hjelp av opted-in-feil rapporter til å måle som oppfordrer tripp on-device modellene og herde grammatikken mot dem.
  • En jevnere on-device → Cloud håndoff, så eskalering føles som å slå opp kvalitet dial i stedet for å bytte verktøy.

Gjennomsnittet: samme deklarative verktøy vokabular driver en modell på hver side av nettlesergrensen. En ekstern agent kaller disse verktøyene over MCP; en on-device-modell kaller de samme formene lokalt. En kontrakt, agenter der de kjører.

Prøv det i redaktøren - AI/Kode → Assistant. Det er gratis, kjører på enheten og trenger ingen konto.

Ready to create?

Start making animated GIFs, videos, and graphics — free, no signup.

Open PinePaper Editor