这几天写 @Acurast，手机接入、积分和 $ACU 用途都聊过了。
今天换个能直接点开玩的。
Acurast 最近上线了一组 Laya Demo。背后的 AI 模型没有跑在传统云服务器里，而是跑在 Acurast 网络中的一台 Android 手机上。
页面里有贪吃蛇、俄罗斯方块、Doom、邮件分类、直播评论审核和提示词注入拦截等 9 个演示，另外还开放了 API。
Laya 不是聊天机器人
Laya 属于 System One 模型。
它不会像 ChatGPT 一样写一大段回复。你给它一段内容和几个固定选项，它会直接作出选择，并返回各个选项的概率。
比如：
邮件属于收件箱、垃圾邮件还是钓鱼邮件
一条评论是否包含诈骗或恶意内容
这次提示词注入应该放行还是拦截
游戏角色下一步往哪里走
同一个模型可以处理这些看起来完全不同的任务，因为底层都是同一件事：读取当前状态，然后从给定选项里选一个。
一台手机是怎么跑的
Laya 由 ConvAI Innovations 开源，采用 Apache 2.0 许可，模型大约 800MB。
为了放到手机上运行，它被转换成 ONNX，并量化到 8 bit。整个推理过程只用手机 CPU，不需要显卡。
用户在网页里提交一次选择，页面会向 Acurast 网络中的手机发送一个 HTTP 请求。手机运行模型，再把结果传回来。
官方给出的速度大约是每次判断 0.2 到 1 秒。
玩贪吃蛇时，手机决定下一步转向；运行邮件分类时，手机判断邮件应该放进哪个类别。页面上还能看到设备所在国家、芯片信息、已经处理的决策数量，以及对应的链上记录。
这就比单纯写“手机可以提供 AI 算力”直观多了。任务发出去，手机计算，结果返回，整个过程都能实际操作。
为什么这类 AI 适合手机网络
最大的语言模型还是需要大量 GPU，单台手机替代不了数据中心。
但实际产品里，并不是所有 AI 请求都需要大模型。
客服工单分类、内容审核、垃圾邮件识别、风险标签和 Agent 的第一层判断，处理的都是短任务。每次请求彼此独立，也不需要保留很长的上下文。
这类任务可以分给不同手机同时处理。
一台手机每秒只能完成有限的判断，那就增加设备数量。Acurast 目前已经接入 33.5 万台以上的手机，覆盖 175 个以上的国家，这种分散的小任务正好能把设备数量用起来。
而且这些内容往往带有隐私。
邮件、聊天记录、客服信息和 Agent 指令不一定适合全部发给中心化 API。Acurast 会把任务交给经过硬件认证的手机，并在 TEE 环境中执行。提供设备的人不能直接读取任务里的原始数据。
这和 $ACU 有什么关系
Laya Demo 展示的不只是手机性能，也展示了 Acurast 里的计算需求从哪里来。
开发者部署模型，需要购买计算资源；手机提供任务执行能力，获得相应奖励；$ACU 用于支付网络计算、激励 Compute Provider、质押和治理。
官方在此前的 Laya 部署示例里给出的成本是每天不到 1 ACU，实际价格会跟设备、任务和当前报价变化。
单次费用不高，但这类模型处理的是连续请求。
邮件不断进入，评论不断刷新，Agent 也会重复调用判断接口。真正能形成需求的不是展示页面，而是这些模型被接入产品以后产生的长期调用。
它也有明显限制
Laya 适合做快速判断，不适合替人作最终决定。
官方测试中，邮件分类正确了 160 封里的 144 封，大约是 90%。选项超过约 20 个以后，准确率会下降。面对复杂文本和专门设计的攻击内容，它也可能判断错误。
单台手机的吞吐量同样有限。请求突然变多时，队列会开始堆积。
所以它更适合放在第一层，先完成分类、过滤和分流，再把少量复杂内容交给更大的模型或人工处理。
先让手机干它能干的活
Acurast 没有用这次 Demo 证明手机可以取代 GPU。
它证明的是另一件更具体的事：一部分真实 AI 请求不需要昂贵的大模型，也不需要一直放在中心化服务器里。
一个开放模型、一台真实手机、一次可以查到的计算任务，这条链路已经跑起来了。
接下来要看的，是开发者愿不愿意把邮件分类、内容审核、Agent 后端这些长期任务真正部署进来。设备规模已经有了，计算需求能不能跟上，才是后面更重要的数据。