Un asistente de diseño que funciona en su dispositivo — Sin cuenta, sin servidor
El asistente PinePaper en el dispositivo AI convierte un aviso en una escena real usando un modelo de lenguaje que funciona completamente en su navegador. Aquí está la arquitectura — llamadas de herramientas limitadas, dos proveedores, y una cuenta honesta de lo que un pequeño modelo puede y no puede hacer.
La premisa
La mayoría de las herramientas de diseño AI envían su mensaje a un servidor, ejecutan un modelo grande y envían código de vuelta. Eso necesita una cuenta, una ida y vuelta de red, y confía en que tu trabajo en progreso transita la infraestructura de otra persona.
Queríamos saber hasta qué punto va el otro extremo: Un asistente de diseño donde el modelo funciona en su propia máquina. Sin cuenta. No suba. El impulso nunca deja el navegador. Esto ahora está en vivo en el editor de PinePaper como una pestaña experimental AI / Code → Asistente, y este post es una cuenta honesta de cómo funciona y dónde se encuentra corto.
¿Por qué no pides el código al modelo?
El enfoque obvio es pedir al modelo de dispositivo para escribir JavaScript contra PinePaper API y ejecutarlo. Lo intentamos. Falla mal.
Los modelos pequeños —los que encajan en un portátil— no tienen ** ningún conocimiento del API de una aplicación específica.** Pregunte a un modelo 0,5-2B para llamar a PinePaper.create() e improvisa: una clave que el método no lee (un SVG-style fill donde el API espera color), un método que imaginó, argumentos en la forma equivocada. La salida mira como código y silenciosamente hace lo incorrecto.
Así que no pedimos código. Pedimos una lista configurada de llamadas de herramientas **
[
{ "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" } }
]
El mismo vocabulario PinePaper servidor PG1X expone a agentes externos, pero emitido por un modelo que funciona localmente, y ejecutado en el lienzo a través de un pequeño despachador.
Imposibilidad de producción inválida
El movimiento clave es Decodificación con restricciones. En lugar de esperar que el modelo produzca una forma válida, limitamos qué fichas se le permite incluso emitir:
- En Chrome incorporado Prompt API (Gemini Nano), pasamos un JSON Schema como una limitación de respuesta. El modelo sólo puede producir objetos que el esquema permite - con
additionalProperties: false, cualquier argumento que el esquema no define es literalmente inrepresentable. - En WebLLM (un modelo abierto que funciona en WebGPU), nosotros adjunta una gramática EBNF vía XGrammar. La gramática dicta la estructura; el modelo sólo llena los valores.
Ambos producen la misma forma de llamada de herramientas. Un pequeño pase de reparación entonces salva a los casi-misos un pequeño modelo todavía hace - un name caído, argumentos sin su envoltura - al inferir la herramienta de la forma de argumento. El resultado es que "hacer un pentágono verde" se convierte en una verdadera llamada create_item en lugar de un error.
Dos proveedores, un contrato
AI no es una cosa, depende del navegador:
- Browser AI — Chrome incorporado Gemini Nano (
window.LanguageModel). Los barcos modelo con el navegador; no hay nada que descargar de nosotros. Esta es la ruta más confiable en el dispositivo hoy, porque la restricción JSON-schema es barata y bien apoyada. - PinePaper AI — WebLLM ejecutando un modelo Qwen2.5 en cualquier navegador WebGPU. Se descarga un modelo una vez (encendido posteriormente), y luego se ejecuta sin conexión.
- Idiomas — los avisos no ingleses se traducen primero al inglés en el dispositivo (a través del traductor incorporado del navegador), porque los pequeños modelos orientados al código son ingleses. La escena generada es la misma independientemente del lenguaje rápido.
El usuario escoge el motor; todo abajo — la limitación, el ejecutante, el lienzo— es idéntico.
Edición, no sólo generando
Un generador de un disparo no es un asistente. Para apoyar "hacer la estrella roja", el modelo necesita saber lo que ya está en el lienzo. Así que cada turno le alimentamos una instantánea compacta de los elementos actuales — sus ids, tipos y colores— exactamente como un chat lado del servidor. "Haz la estrella roja" entonces se resuelve a una verdadera llamada modify_item contra la id del artículo. (Y debido a que un pequeño modelo a veces se refiere al "the circle" cuando significa la estrella, el ejecutante resuelve referencias borrosas contra el lienzo vivo.)
El registro de conversaciones se mantiene en su dispositivo en el almacenamiento local. Nada de eso se envía en cualquier lugar, a menos que usted opte explícitamente por compartir los avisos fallidos, lo que nos ayuda a mejorar los impulsos y la gramática.
Cuando el modelo pequeño no es suficiente — escalar
Aquí está la parte honesta: Un modelo 0,5-2B es el más débil. Constrained decoding garantiza valid structure, pero el modelo todavía tiene que elegir la herramienta correcta y los valores sensibles, y no siempre. Pida un pentágono y un modelo poco especificado le da un hexágono; pida dos veces "rojo" y podría funcionar un generador en su lugar.
Así que la arquitectura trata en el dispositivo como el nivel * primero*, no el único. Después de algunos intentos fallidos el asistente ofrece a hand toda la conversación hacia arriba al modelo Cloud — la misma intención, el mismo lienzo, un modelo mucho más capaz— y continúas exactamente donde te fuiste. Baja fidelidad, libre y privado, con un camino de un clic a la alta fidelidad cuando la necesitas.
Lo que hemos aprendido
- Constraints beat prompting. Un sistema basado ayuda; una gramática / esquema que hace imposible la salida inválida ayuda mucho más. El salto de confiabilidad más grande vino de la decodificación limitada, no de un mejor impulso.
- El tamaño del modelo sigue dominando. Pasando de un 0,5B a un modelo 1.5B mejoró notablemente con qué frecuencia el asistente elige la herramienta correcta. No hay ningún impulso que convierta un pequeño modelo en inteligente.
- La gramática completa puede ser demasiado grande. Nuestra primera gramática codificada toda posible operación, incluyendo una escotilla de escape de longitud fija para código de dibujo arbitrario. Era tan grande que la decodificación restringida aplazaba la página. Una gramática compacta que cubre las operaciones comunes es el predeterminado adecuado; la superficie completa es opt-in.
- Desvíalo del hilo principal. Un modelo haciendo inferencia en el hilo UI congela la página. WebLLM se ejecuta en un Web Worker por lo que el editor sigue siendo sensible mientras un modelo carga y genera.
¿Qué sigue
Esto es experimental y mejora. En la hoja de ruta:
- Cobertura de herramientas en el camino restringido — más de las operaciones de PinePaper expresible sin la escotilla de escape de forma libre.
- Larger on-device modelos como crecen los catálogos de modelos WebGPU, intercambiando el tamaño de descarga para la confiabilidad.
- Un bucle eval más ajustado - usando informes de fallos optados para medir lo que impulsa el viaje de los modelos en el dispositivo y endurece la gramática contra ellos.
- Un dispositivo más suave → Aparador de nube, por lo que la escalada se siente como encender el dial de calidad en lugar de cambiar las herramientas.
El a través de la línea: el mismo vocabulario de herramienta declarativa conduce un modelo a ambos lados del límite del navegador. Un agente externo llama estas herramientas sobre MCP; un modelo de dispositivo llama las mismas formas localmente. Un contrato, agentes dondequiera que corran.
Pruébalo en el editor — open AI / Code → Assistant. Es gratis, funciona en tu dispositivo y no necesita cuenta.
Ready to create?
Start making animated GIFs, videos, and graphics — free, no signup.
Open PinePaper Editor