Holo3.1:把电脑操作 agent 拉回本地,赌的是延迟和隐私

概述

H Company 在 Hugging Face 官方博客发布了 Holo3.1,一个电脑操作(computer-use)模型家族。它的核心动作不在刷新榜单峰值,而在第一次放出量化权重,让同一套电脑操作能力可以跑在用户自己的设备上。这是一个方向性的选择:computer-use 这条路线的下一道坎,可能已经从”云端模型够不够强”挪到了”本地能不能跑得够快、够私密”。

值得认真对待的判断是:对相当一部分真实工作流,把 agent 留在本地的价值,已经压过了再追几个百分点榜单分的价值。Holo3.1 押的就是这个。它给了四个尺寸(0.8B、4B、9B、35B-A3B)和三种量化格式(FP8、Q4 GGUF、NVFP4),整条产品线都在为”延迟更低、数据不出网”服务,而不是为单一基准的名次服务。

发生了什么

Holo3.1 基于 Qwen 家族构建,H Company 说它在三个生产中最要紧的维度上提升了稳健性:运行环境(网页、桌面、移动)、agent 框架、以及部署目标。三件事里,后两件是这次的重点。

移动端是最明显的增量。在 AndroidWorld 上,35B-A3B 模型从 67% 升到 79.3%,更小的 4B 和 9B 变体从 58% 升到 72%。H Company 给的原因很实在:把 Holo3 从评测搬到生产时,他们反复撞到同一个问题,在一种环境里表现好,换到另一种环境(移动设备、别家的 agent 框架、不同的执行栈)就未必还成立,每一处都带来各自的分布漂移。

第二件是跨框架。Holo3.1 在原有的结构化 JSON 输出之外,原生支持了 function-calling 协议,方便团队把它塞进第三方 agent 栈。按博客说法,在 OSWorld 和它们覆盖电商、商业软件、协作流程的内部基准上,function-calling 和原生执行现在做到了接近持平;在自家的 Holotab 产品框架里,Holo3.1 比 Holo3 提升超过 25%。

最关键的是第三件:本地。这是 H Company 第一次放出量化权重,起步是 35B-A3B 的三种格式,FP8、Q4 GGUF 和 NVFP4。NVFP4 用的是 NVIDIA 的 Model Optimizer,W4A16 配置。按博客数据,这些量化几乎不掉点,FP8 和 NVFP4 在 OSWorld 上得分相同,只比全精度 BF16 低约两分;换来的速度提升不小,在 DGX Spark 上,NVFP4 W4A16 的总 token 吞吐是 FP8 的 1.41 倍、BF16 的 1.74 倍。

它还放出了面向消费级硬件的 Q4 GGUF。落地形态是这样的:agent 本身跑在用户的 Windows 或 Mac 机器上,模型要么跑在同一台机器(博客给了 Apple Silicon 的参考数据),要么跑在同一局域网内的一台 DGX Spark 上。两种情况下,执行全程留在本地,没有任何东西离开用户的网络。在 Spark 上,他们和 NVIDIA 一起做的 agent 框架优化叠加上面的 NVFP4 量化,端到端拿到约 2 倍于 FP8 基线的提速,把平均每步耗时从 6.8 秒压到 3.3 秒。

模型按四个尺寸放出:0.8B(超轻量本地 agent)、4B(低成本部署)、9B(性能与延迟平衡)、35B-A3B(追求最高性能)。量化的 FP8、NVFP4、Q4 GGUF 面向本地与边缘部署。

为何重要

把 Holo3.1 和 Claude、OpenAI 那类云端电脑操作 agent 放在一起看,差别主要落在 agent 跑在哪、屏幕截图发去哪,而非模型谁更聪明。

云端 computer-use 的工作方式是:agent 每走一步,要把当前屏幕的截图(或可访问性树)发到提供商的服务器,模型在那边决定下一个动作,再把动作发回来。这意味着两件事天然成立。第一,每一步都吃一个网络往返的延迟,步数多的任务会累积;第二,你屏幕上的一切,在那一刻都离开了你的机器。对很多场景这没问题,但对另一些场景,这两点恰恰是绕不过去的墙。

本地路线把这堵墙拆了。延迟这一侧,Holo3.1 给的数字是平均每步 3.3 秒(在 Spark 上,NVFP4 加框架优化之后),没有跨公网的往返。隐私这一侧更直接:H Company 的措辞是执行全程留在本地、没有任何东西离开用户的网络。对处理客户数据、内部系统、合规受限信息的团队,“屏幕不出网”不是一个优化项,而是能不能用的前提。

但要把账算清楚:云端方案的优势同样真实,而且 Holo3.1 没有声称要抹掉它。云端模型不受用户终端算力限制,可以用更大的模型、随时升级、不需要用户配硬件。Holo3.1 本地路线的代价摆在台面上:它目前只放出了 35B-A3B 一个尺寸的量化权重,而要在本地获得博客里那 3.3 秒的体验,参照系是一台 DGX Spark,不是普通笔记本。Apple Silicon 上”跑得动”和”跑得够快可用”之间,博客只给了参考数据,没给一个谁都能照搬的结论。

所以真正的判断是:computer-use 正在从”只有一种部署形态”分叉成两条路。一条是云端托管、追求模型上限的路;另一条是本地自托管、追求延迟和数据主权的路。Holo3.1 是后一条路上目前最具体的一步,它把”本地电脑操作 agent”从一个口号变成了带尺寸、带量化格式、带速度数字的可下载产物。

对建设者的影响

如果你在做 computer-use 产品,这次发布该改变的是你的选型默认值,而不只是多一个备选模型。

先判断你属于哪一类。如果你的工作流处理的是公开网页、对延迟不敏感、也不碰敏感数据,云端 computer-use 仍然是更省心的默认,你不用为了本地化去配硬件、扛运维。但如果你撞到下面任何一条,本地路线现在值得认真评估了:数据不允许离开内网;延迟敏感、任务步数多;或者你要把能力嵌进客户自己的设备而不是你的服务器。这三种情况过去要么没得选,要么得自己拼装,Holo3.1 给了一个现成的起点。

选尺寸要对着用途选,别默认上最大的。博客把四个尺寸的定位写得很清楚:0.8B 是超轻量本地 agent,4B 是低成本部署,9B 是性能与延迟的平衡点,35B-A3B 才是追最高性能的那档。注意一个现实约束:量化权重目前只覆盖 35B-A3B。也就是说,如果你想要”小尺寸 + 量化”的极致轻量组合,现在还得自己动手,官方还没替你做到。

把 function-calling 支持当成一个集成信号。Holo3.1 原生支持了 function-calling 协议,而且和原生执行接近持平。如果你已经有一套基于工具调用的 agent 框架,接它的成本比接 Holo3 低。但近似持平不等于完全等价,真要切,在你自己的任务上跑一遍 OSWorld 之外的回归,别只信博客的内部基准。

最后,验证 3.3 秒这个数字落到你的硬件上是多少。博客那个数字的前提是 DGX Spark 加上和 NVIDIA 联合做的框架优化,且这些优化要等后续的桌面 agent 框架才落地。在 Apple Silicon 或别的消费级机器上,你拿到的步耗时会不一样。把它当成一个”本地能做到的量级”的参考,而不是你部署后必然的数字。

该忽略什么

忽略把 Holo3.1 读成”本地终于打赢云端”的叙事。博客通篇没有和 Claude、OpenAI 的 computer-use 做正面跑分对比,它比较的对象主要是自家的 Holo3 和 Qwen 3.5 家族。本地与云端是两套取舍,谈不上一场分胜负的比赛。谁更适合取决于你的延迟、隐私、硬件约束,而不是谁榜单分更高。

忽略”量化几乎不掉点所以本地随便上”的轻率结论。FP8 和 NVFP4 与 BF16 只差约两分,这个数字很漂亮,但它只覆盖了 OSWorld,而且只针对 35B-A3B。把它外推成”任何尺寸、任何任务上量化都无损”,博客并没有这么说。

也忽略移动端那组涨幅背后的过度联想。AndroidWorld 从 67% 升到 79.3% 是实打实的进步,但 79.3% 不等于在你的具体 App 上就能可靠跑通,移动环境的分布漂移正是 H Company 自己点名的难点。把它读成”移动 agent 已经成熟”会过头,读成”移动这条线第一次被认真补上”才对。

来源

1. Holo3.1:快速、本地的电脑操作 agent(H Company,Hugging Face 博客) / blog

无官方一手源；本文基于可靠二手报道（具名媒体、交叉印证）写成。