· 6 min read

Um assistente de design que executa em seu dispositivo — sem conta, sem servidor

O assistente on-device AI do PinePaper transforma um prompt em uma cena real usando um modelo de linguagem que é executado inteiramente em seu navegador. Aqui está a arquitetura — chamadas de ferramentas restritas, dois provedores e uma conta honesta do que um pequeno modelo pode e não pode fazer.

A premissa

A maioria das ferramentas de design AI envia seu prompt para um servidor, executa um modelo grande e envia o código de volta. Isso precisa de uma conta, uma viagem de ida e volta à rede, e confie que o seu trabalho em andamento transita a infra-estrutura de outra pessoa.

Queríamos saber até onde vai o outro extremo: ** um assistente de design onde o modelo é executado em sua própria máquina.** Nenhuma conta. Sem upload. O prompt nunca sai do navegador. Este é agora ao vivo no editor do PinePaper como um experimental AI / Code → Assistant tab, e este post é uma conta honesta de como ele funciona e onde fica aquém.

Porque não pedir o código ao modelo?

A abordagem óbvia é pedir ao modelo on-device para escrever JavaScript contra o API do PinePaper e executá-lo. Já tentámos. Falha mal.

Modelos pequenos — os que se encaixam em um laptop — têm nenhum conhecimento do API de um aplicativo específico. Peça a um modelo 0.5-2B para chamar PinePaper.create() e ele improvisa: uma chave que o método não lê (um fill estilo SVG onde o API espera color), um método que ele imaginou, argumentos na forma errada. A saída * parece * como código e silenciosamente faz a coisa errada.

Então não pedimos código. Pedimos uma lista restrita de chamadas de ferramentas:**

[
  { "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" } }
]

O mesmo vocabulário do PinePaper MCP server expõe a agentes externos — mas emitido por um modelo rodando localmente, e executado na tela através de um pequeno despachante.

Tornando impossível o resultado inválido

A jogada da chave é ** decodificação restrita.** Em vez de esperar que o modelo produza uma forma válida, nós restringimos que tokens é permitido até mesmo emitir:

  • No Chrome's built-in Prompt API (Gemini Nano), passamos um JSON Schema como uma restrição de resposta. O modelo só pode produzir objetos que o esquema permite — com additionalProperties: false, qualquer argumento que o esquema não define é literalmente irrepresentável.
  • Em WebLLM (um modelo aberto rodando em WebGPU), nós anexar uma gramática ** EBNF** via XGrammar. A gramática dita a estrutura; o modelo apenas preenche os valores.

Ambos produzem a mesma forma de chamada de ferramentas. Uma pequena passagem de reparo salva os quase perdidos que um modelo minúsculo ainda faz — um name caído, argumentos sem o embrulho — ao inferir a ferramenta da forma do argumento. O resultado é que "desenhe um pentágono verde" torna-se uma chamada create_item real em vez de um erro.

Dois prestadores, um contrato

O AI no dispositivo não é uma coisa — depende do navegador:

  • Browser AI — O Chrome's built-in ** Gemini Nano** (window.LanguageModel). O modelo funciona com o navegador; não há nada para baixar de nós. Este é o caminho no dispositivo mais confiável hoje, porque a restrição JSON-schema é barato e bem suportado.
  • PinePaper AIWebLLM executando um modelo Qwen2.5 em qualquer navegador WebGPU. Ele baixa um modelo uma vez (cached depois disso), então é executado offline.
  • Línguas — prompts não-inglês são traduzidos para o inglês no dispositivo primeiro (através do tradutor embutido do navegador), porque os pequenos modelos orientados a código são centrados em inglês. A cena gerada é a mesma independentemente da linguagem pronta.

O usuário escolhe o motor; tudo a jusante — a restrição, o executor, a tela — é idêntico.

Edição, não apenas gerando

Um gerador não é um assistente. Para suportar "fazer a estrela vermelha", o modelo precisa saber o que já está na tela. Assim, cada turno nós alimentamos um instantâneo compacto dos itens atuais — seus ids, tipos e cores — exatamente como um bate-papo do lado do servidor faria. "Faça a estrela vermelha" então resolve para uma chamada modify_item real contra o ID do item. (E porque um pequeno modelo às vezes se refere ao "the circle" quando significa a estrela, o executor resolve referências fuzzy contra a tela ao vivo.)

O registro de conversa é mantido ** em seu dispositivo** no armazenamento local. Nada sobre ele é enviado para qualquer lugar — a menos que você opte explicitamente por compartilhar prompts fracassados, o que nos ajuda a melhorar os prompts e a gramática.

Quando o modelo pequeno não é suficiente — aumente

Aqui está a parte honesta: um modelo 0,5-2B é o nível mais fraco. A decodificação restrita garante * estrutura válida*, mas o modelo ainda tem que escolher a ferramenta certa e valores sensíveis, e nem sempre. Peça um pentágono e um modelo sub-especificado dá-lhe um hexágono; peça duas vezes para "vermelho" e ele pode executar um gerador em vez disso.

Assim, a arquitetura trata on-disvice como o first tier, não o único. Após algumas tentativas falhadas, o assistente oferece- se para ** entregar toda a conversa ao modelo Cloud** — mesma intenção, mesma tela, um modelo muito mais capaz — e você continua exatamente de onde parou. Baixa fidelidade, gratuita e privada, com um caminho de um clique para alta fidelidade quando você precisa.

O que aprendemos

  • Constraints beat promting. Um prompt de sistema fundamentado ajuda; uma gramática/esquema que torna impossível a saída inválida ajuda muito mais. O salto de confiabilidade único maior veio de decodificação restrita, não de um melhor prompt.
  • ** O tamanho do modelo ainda domina. Indo de um 0.5B para um modelo 1.5B visivelmente melhorou a frequência com que o assistente escolhe a ferramenta certa. Não há nenhum prompt que transforma um modelo minúsculo em um inteligente.
  • ** A gramática completa pode ser muito grande.** Nossa primeira gramática codificada every possível operação — incluindo uma escotilha de escape de comprimento limitado para código de desenho arbitrário. Era tão grande que a decodificação restringida parou a página. Uma gramática compacta cobrindo as operações comuns é o padrão certo; a superfície completa é opt-in.
  • ** Execute o fio principal.** Um modelo que faz inferência na linha UI congela a página. WebLLM é executado em um Web Worker para que o editor permaneça responsivo enquanto um modelo carrega e gera.

E agora

Isto é experimental e melhorar. No roteiro:

  • A cobertura da ferramenta wider no caminho restrito — mais operações do PinePaper expressíveis sem a escotilha de escape freeform.
  • Modelos on-device Larger à medida que os catálogos de modelos WebGPU crescem, negociando tamanho de download para confiabilidade.
  • Um laço eval mais apertado — usando relatórios de falha opted-in para medir o que leva a tropeçar nos modelos no dispositivo e endurecer a gramática contra eles.
  • Um dispositivo mais suave → Transferência de nuvem, então a escalada parece aumentar o mostrador de qualidade em vez de mudar as ferramentas.

A linha: o mesmo vocabulário de ferramenta declarativa dirige um modelo em ambos os lados do limite do navegador. Um agente externo chama essas ferramentas de MCP; um modelo on-dispositivo chama as mesmas formas localmente. Um contrato, agentes onde quer que corram.

Experimente no editor - abra AI / Código → Assistente. É gratuito, roda em seu dispositivo, e não precisa de conta.

Ready to create?

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

Open PinePaper Editor