On-Device AI 设计助理 - 浏览器中的客户端-Side LLM (中文)

前提

大多数 AI 设计工具都会将您的提示发送到服务器,运行一个大型模型,并发送代码返回. 这需要一个账户,一个网络往返, 并相信你的工作在建转过别人的基础设施.

我们想知道另一个极端会发展到什么程度:一个设计助理,模型运行在你自己的机器上. 没有账户. 无上传. 提示永远不会离开浏览器 . 本文现作为实验性AI / Code → Assistance tab 而在PinePaper的编辑器中现场直播,此文章是对其工作方式和不足之处的诚实叙述.

为什么不直接问模型代码?

显而易见的方法是要求在线设备模型针对PinePaper的API编写JavaScript并运行. 我们试过了. 失败了.

小型型号—— 那些适合笔记本电脑的.. 对特定应用的API不知情。 ** 请用0.5–2B模型调用PinePaper.create(),它即兴地:一种方法不读的键(一种SVG-风格的fill,其中API期望color),一种它想象的方法,是错误的形状的参数. 输出看起来像代码,默默地做错事.

所以我们不问代码. 我们要求一份受限制的工具电话清单:**

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

同样的词汇PinePaper的MCP服务器暴露于外部代理—— 但被本地运行的模型发射出来然后通过一个小调度器在画布上执行.

使输出无效

键动是受约束的解码。 而不是希望这个模型能产生一个有效的形状, 我们约束着它,甚至允许它发出什么信号: *

在Chrome的内置Prompt API(Gemini Nano)上,我们通过一个JSON Schema作为响应约束. 该模型只能产生计划允许的物体—— 与 additionalProperties: false,任何没有定义的参数在字面上都是无法表达的.
在WebLLM(一个在WebGPU上运行的开放式模型)上,我们通过XGrammar附加了一个EBNF语法. 语法支配结构;模型只填充值.

两者都产生相同的工具调用形状. 一个小的修补通道然后打捞一个小模型丢弃的 name, 参数没有包装.. 从参数形状推断工具. 结果是"画一个绿色五角星"变成了真正的create_item调用而不是错误.

切换在下面三个之间. 两个受限制的选项看起来完全相同目的:即索赔. 它们之间的改变是机制,而不是结果.

两个供应商,一个合同

设备AI不是一回事.. 它取决于浏览器 :

浏览器AI - Chrome的内置Gemini Nano(window.LanguageModel). 带浏览器的模型船;我们没有下载的东西. 这是今天最可靠的在Device路径,因为JSON-schema的制约是便宜的,并且得到了很好的支持.
页:1 WebLLM在任何WebGPU浏览器中运行一个Qwen2.5模型. 它下载过一次模型(之后被删除),然后运行下线.
语语 - 非英语提示首先被翻译为英语 on-device(通过浏览器的内置翻译),因为面向代码的小型模型都是以英语为中心的. 生成的场景无论是否迅速语言都是一样的.

用户选择引擎;下游的一切—— 约束执行者画布完全一样.

编辑,不只是生成

一发发电机不是助手. 为了支持"让星星红",模型需要知道画布上已经有什么. 因此,每个转弯,我们给它一个紧凑的快照当前的项目其标识、类型和颜色—— 就像服务器侧聊天一样. "让星星红"之后就解决了真正的modify_item对项目ID的呼叫. (又因为一个小模型有时在表示恒星时指的是"the"(the circle),执行者对活画布解决模糊的引用. )

谈话记录保存在您的设备上 ** 本地存储 . 没有任何关于它的信息被发送到任何地方除非你明确选择分享失败的提示, 这帮助我们改进提示和语法.

当这个小模型还不够的时候.. 升级

以下是诚实的部分:a 0.5–2B模式是最弱的一级. 限制解码保证 *有效结构 *,但模型仍然需要选择正确的工具和明智的价值观,它不会总是. 问一个五边形和一个规格不足的模型会给你一个六边形;问两次"红色",它可能会运行一个生成器代替.

因此,建筑将在线设备视为 * 第一级,而不是唯一的一级. 经过几次失败的尝试后,助理提议把整个对话交给云模式*—— 同样的意图,同样的画布, 一个更有能力的模型—— 你继续原地走. 忠诚度低,自由与私人, 有一条一击路径到高度忠诚当你需要它.

我们学到的

约束被催促。 一个基于系统的提示有帮助;一个使无效输出无法实现的语法/schema有更大的帮助. 最大的一次可靠性跳跃来自受限制的解码,而不是来自更好的快速.
模式大小仍然占主导地位。 从0.5B型到1.5B型明显改进了助理选择正确工具的频率. 没有将一个小模型变成聪明模型的提示.
完整的语法可能太大。 我们的第一个语法编码每一个可能的操作 - 包括用于任意绘图码的边长逃生舱门. 如此之大以至于受限制的解码使页面停滞. 覆盖共同操作的紧凑语法是正确的默认;完整的表面是选入的.
离开主线一个在UI线上进行推断的模型会冻结页面. WebLLM在Web Worker中运行,因此编辑器在模型加载和生成时保持响应性.

接下来呢

这是实验性改进. 在路线图上:

限制路径中的Wider工具覆盖 - 更多PinePaper的操作在无自由形式逃生舱舱门的情况下可以显示.
Larger on-device models 随着WebGPU 型号目录的增长,交易下载大小以获取可靠性.
一个更紧的eval循环 - 使用选择的失败报告来衡量哪些会触发测试模型的绊脚石并强化针对它们的语法.
一个更平滑的设备 ~ 云手交, 所以升级感觉像是打开质量拨号而不是切换工具.

通过线:相同的声明工具词汇驱动浏览器边界两侧的模型. 一个外部代理在MCP之上调用这些工具;一个在线设备模型在当地调用相同的形状. 一份合同, 代理他们运行的地方.

一个运行在您的设备上的设计助理—— 没有账户, 没有服务器

前提