Computer Use Agent本地化：Perplexity Computer与DGX Spark部署实践

2025 年的 AI 行业有一个很明显的转向模型不再满足于“坐在聊天框里回答问题”而是开始接管鼠标和键盘。Perplexity Computer 就是这一波“电脑操作型 Agent”里的代表产品——它能看懂屏幕内容自己移动光标、点击按钮、填写表单替用户完成真实的网页操作。过去这类能力几乎只能跑在云端依赖厂商的 API 和远程推理集群而近期出现了一个非常值得关注的信号Perplexity Computer 在 NVIDIA DGX Spark 上实现了完全本地运行的现场演示。这件事的意义不在于“某个新产品能跑起来”这么简单。它真正触及的问题是 Agent 的“感知—决策—执行—验证”完整回路能不能从云端迁回自己的硬件边界之内。如果成立那么隐私保护、离线可用性、单次调用成本、可定制程度这几个关键变量都会发生变化。这篇文章我会先讲清楚 Perplexity Computer 和 DGX Spark 各自是什么再拆解“完全本地运行”到底解决了什么问题然后给出在 DGX Spark 上复现同类能力的部署架构、配置示例和验证方法。无论你是正在选型 Agent 基础设施的工程师还是想把手头的开源视觉语言模型跑成“能操作电脑的 Agent”的研究者这篇文章都值得读完。1. 为什么“Perplexity Computer 本地运行”值得关注先看现状。今天的 Agent 产品大多是这样工作的用户在网页上发一个任务云端集群里的模型“看到”远程浏览器截图输出操作指令再通过云端 API 把点击、输入、滚动这些动作下发到浏览器。整个过程有三层依赖网络依赖任何一步断网Agent 就无法工作。数据依赖屏幕截图、表单内容、Cookie、业务数据都要经过云端。成本依赖每一步操作都是一次大模型推理按 token 计费长时间任务成本很高。这还不是最麻烦的。企业场景里很多系统本身就在内网不允许外部 API 访问金融、医疗、政务场景对数据出境和第三方调用有严格限制。结果就是云端的 Computer Use Agent 再强到了这些场景里根本落不了地。DGX Spark 这类设备的出现恰好改变了算力前提。它把数据中心级别的多模态推理能力压缩进了一台桌面设备128GB 统一内存足以加载和运行几十亿到几百亿参数级别的视觉语言模型。也就是说完整跑一个“能看屏幕、能操作浏览器”的 Agent不再需要托管的 GPU 集群。所以“Perplexity Computer 在 DGX Spark 上完全本地运行”的现场演示本质上是一次架构可行性的验证。它回答了一个很实际的问题如果把 Agent 的整个推理回路放在本地硬件上体验是否可接受工程上是否可复制。如果你正在做 Agent 应用、RPA 替代方案、企业知识库助手或者只是对多模态模型部署感兴趣这篇文章里讲的部署思路和坑基本都能直接用上。2. 基础概念Perplexity Computer 与 DGX Spark 分别是什么2.1 Perplexity Computer能“看屏操作”的电脑使用型 Agent先区分两个容易混淆的概念聊天助手和电脑使用型 Agent。聊天助手的交互边界是聊天框用户问一句模型答一句它无法替用户去浏览器里做任何事。电脑使用型 Agent 则完全不同它面对的不是文本对话而是整个图形界面。它的工作方式非常接近一个真实用户对屏幕截图获得当前的视觉状态由视觉语言模型理解界面布局和元素输出一个动作决策比如“点击搜索框”“输入关键词”“按回车”由执行框架把动作翻译成浏览器自动化指令再次截图验证动作是否生效进入下一个循环。Perplexity Computer 是 Perplexity 在这条路线上的产品。它的定位偏消费者场景比如让 Agent 帮你查询信息、预订服务、填写表单、完成商品对比。这类产品对用户的直接价值是把“知道怎么做”变成“直接替你做”。这里必须说明一个重要的技术现实Perplexity Computer 的完整模型权重和服务端实现并未完全开源。所谓“在 DGX Spark 上完全本地运行”更稳妥的理解是它验证了同类 Computer Use Agent 完全可以在本地硬件上闭环。普通团队要在自己的 DGX Spark 上复现这套能力通常的做法是组合一个开源视觉语言模型如 Qwen2.5-VL、InternVL 等加一个开源 Computer Use 框架再加上容器化的浏览器环境。这也是我后面部署示例采用的思路。2.2 DGX Spark把数据中心算力搬进个人工位DGX Spark 是 NVIDIA 在 GTC 2025 上正式公布的桌面级 AI 超级计算机最初以 Project DIGITS 的名字亮相。它面向的不是普通游戏玩家而是 AI 开发者、数据科学家和工程团队——目标是在个人工位上跑出接近数据中心的模型推理能力。从公开参数看它的核心配置包括配置项公开信息核心芯片GB10 Grace Blackwell 超级芯片统一内存128GBCPU 与 GPU 共享AI 算力FP4 精度下约 1 PFLOPS每秒千万亿次模型能力可运行最高 200B 参数规模的模型量化后互联扩展支持 ConnectX 组网多机扩展操作系统DGX OSLinux 内核这里真正关键的一点是 128GB 统一内存。跑 Computer Use 类 Agent 最吃资源的其实不是算力而是上下文和视觉 token 的堆积。一个任务执行几十步每步都有一张截图截图经过视觉编码器后会产生大量 token这些 token 都要留在上下文里。DGX Spark 的大内存让这种长任务的上下文窗口可以开得足够大这是普通显卡工作站很难做到的。还有一个工程上很容易被忽略的点**DGX Spark 的 Grace CPU 是 ARM 架构不是常见的 x86。**这意味着你在上面跑的任何容器镜像、Python 轮子、推理库都必须兼容 ARM64。这个限制直接影响部署选型后面我会专门讲。2.3 两者组合的技术含义把 Perplexity Computer 和 DGX Spark 放在一起看技术含义很清晰Agent 的完整推理回路第一次可以不依赖云端。Perplexity Computer 解决了“Agent 如何理解屏幕并操作电脑”的问题DGX Spark 解决了“本地硬件能否承载这种推理负载”的问题。两者结合等于把一条完整的软件链路装进了一台本地设备。对开发者来说这意味着三件事可以开发完全离线工作的 Agent 应用可以对模型和提示词做深度定制而不是只能调云端 API敏感数据从第一步截屏到最终结果都留在本地硬件边界内。3. 环境准备与前置条件在 DGX Spark 上跑本地 Computer Use Agent需要先确认环境满足以下条件。版本信息建议以你拿到的实际设备为准这里重点讲通用思路。3.1 系统与驱动检查DGX Spark 出厂自带 DGX OS本质上是为 AI 工作负载定制的 Linux 发行版。部署前先检查系统版本和驱动状态# 查看操作系统版本 cat /etc/os-release # 查看 NVIDIA 驱动和 CUDA 是否正常 nvidia-smi # 查看 CPU 架构确认是 ARM64 uname -m如果nvidia-smi能正常输出 GPU 信息和驱动版本说明驱动和 CUDA 环境基本可用。架构确认这一步不要跳过后面所有容器镜像都要根据架构结果来选。3.2 NVIDIA Container Toolkit容器里使用 GPU 依赖 NVIDIA Container Toolkit。确认工具已安装并且 Docker 能识别 GPU# 验证容器能否访问 GPU docker run --rm --runtimenvidia \ -e NVIDIA_VISIBLE_DEVICESall \ nvidia/cuda:12.4.0-base-ubuntu22.04 \ nvidia-smi如果这条命令能输出 GPU 信息说明 Docker GPU 链路通畅。如果提示 runtime 不存在需要先安装 NVIDIA Container Toolkit。3.3 模型权重准备本地跑的模型权重可以从 Hugging Face 或 ModelScope 下载。Computer Use 场景需要视觉语言模型建议优先选择支持屏幕截图理解的开源 VLM。# 使用 huggingface-cli 下载模型权重 huggingface-cli download \ --resume-download \ Qwen/Qwen2.5-VL-7B-Instruct \ --local-dir /data/models/qwen2.5-vl-7b-instruct下载完成后建议对权重目录做一次文件完整性和大小检查避免推理时才发现权重损坏。# 查看模型文件大小和目录结构 du -sh /data/models/qwen2.5-vl-7b-instruct find /data/models/qwen2.5-vl-7b-instruct -type f | head -203.4 推理运行时选型本地推理最常用的方案是 vLLM它吞吐高、兼容 OpenAI 接口很方便 Agent 框架对接。DGX Spark 是 ARM64 架构选镜像时要注意使用linux/arm64版本或者选择官方提供 ARM 支持的镜像。如果某些推理库没有预编译 ARM 轮子可以考虑源码编译但要预留足够的编译时间。4. 核心部署架构与配置示例4.1 架构分层一个本地 Computer Use Agent 的部署架构可以拆成四层模型推理层vLLM 或类似运行时加载 VLM提供 OpenAI 兼容的推理接口Agent 决策层负责解析任务、调用模型输出动作、维护对话历史浏览器执行层运行容器化的 Chromium 浏览器提供 VNC 或截图接口给 Agent 调用安全隔离层限制 Agent 能访问的域名、路径和系统资源。四层之间通过本地网络通信全部运行在同一台 DGX Spark 上。用 Docker Compose 管理是最省事的方案因为模型、Agent、浏览器天然适合容器化。4.2 Docker Compose 编排示例创建一个工作目录和一个docker-compose.yml把推理服务和浏览器服务编排在一起# 文件路径/opt/computer-use/docker-compose.yml services: vllm-server: image: vllm/vllm-openai:latest platform: linux/arm64 command: --model /models/qwen2.5-vl-7b-instruct --max-model-len 32768 --gpu-memory-utilization 0.85 --trust-remote-code --port 8000 runtime: nvidia environment: - NVIDIA_VISIBLE_DEVICESall volumes: - /data/models:/models - /data/hf_cache:/root/.cache/huggingface ports: - 8000:8000 shm_size: 16gb restart: unless-stopped browser: image: selenium/standalone-chromium:latest platform: linux/arm64 ports: - 4444:4444 - 7900:7900 environment: - SE_SCREEN_WIDTH1440 - SE_SCREEN_HEIGHT900 - SE_SCREEN_DEPTH24 shm_size: 2gb restart: unless-stopped这段配置里有三个容易踩坑的点第一platform: linux/arm64直接声明了平台架构避免 Docker 在 ARM 设备上拉取 x86 镜像后运行失败。第二shm_size对浏览器服务和推理服务都很关键。Chromium 的共享内存默认很小容易导致页面崩溃vLLM 在处理长上下文时也会用到共享内存。第三--gpu-memory-utilization 0.85表示 vLLM 最多使用 85% 的 GPU 内存做模型缓存留出余量给运行时开销。不要调到 1.0否则后续视觉编码或上下文增长时可能直接 OOM。启动服务cd /opt/computer-use docker compose up -d查看服务日志docker compose logs -f vllm-server4.3 Agent 配置示例Agent 决策层的配置通常包含模型地址、浏览器连接信息、任务策略和安全边界。下面是一个参考配置# 文件路径/opt/computer-use/agent-config.yaml agent: name: local-computer-use-demo model: base_url: http://127.0.0.1:8000/v1 model_name: qwen2.5-vl-7b-instruct max_tokens: 2048 temperature: 0.1 browser: type: selenium remote_url: http://127.0.0.1:4444/wd/hub headless: false viewport: width: 1440 height: 900 policy: max_steps: 30 screenshot_interval: 1.0 allowlist_domains: - example-internal.com - localhost denylist_domains: - mail.example.com这里有几个关键设计temperature: 0.1。操作类任务需要确定性温度越低动作越稳定不建议用太高的温度max_steps: 30。限制单次任务的最大操作步数防止 Agent 陷入死循环allowlist_domains和denylist_domains。这是安全边界只允许 Agent 访问白名单内的域名比事后审计可靠得多。4.4 Agent 进程管理生产环境建议用 systemd 管理 Agent 的生命周期保证崩溃后自动重启# 文件路径/etc/systemd/system/computer-use-agent.service [Unit] DescriptionLocal Computer Use Agent Afterdocker.service Requiresdocker.service [Service] Restartalways WorkingDirectory/opt/computer-use ExecStart/usr/local/bin/computer-use-agent --config /opt/computer-use/agent-config.yaml ExecStop/bin/kill -TERM $MAINPID [Install] WantedBymulti-user.target启用服务sudo systemctl daemon-reload sudo systemctl enable computer-use-agent sudo systemctl start computer-use-agent5. 现场演示流程拆解从任务下发到操作闭环前面搭好了环境这一节拆解一次典型的“本地 Computer Use Agent”现场演示会经历什么。理解这个闭环比单纯跑通一个 demo 更有价值。5.1 演示任务选择现场演示最适合选一个可预期、可观察、能在一分钟内完成的任务比如让 Agent 打开本地的测试网页在搜索框输入关键词点击搜索结果然后返回页面标题。任务太复杂会让现场等待时间过长任务太简单又看不出 Agent 的能力。5.2 感知阶段截图与视觉编码任务下发给 Agent 后第一步是获取浏览器当前画面。Selenium 或 Playwright 这类工具可以拿到页面截图截图传给 VLM 的视觉编码器转成视觉 token。这一步的观察点是截图的清晰度和浏览器窗口尺寸。窗口太小会导致文字模糊模型很容易把按钮位置识别错。建议在演示前固定浏览器 viewport不要随意缩放。5.3 决策阶段模型输出动作指令视觉 token 和用户任务拼成一个多模态请求发给本地 vLLM 服务。模型输出结果是结构化的动作指令一般包括动作类型、目标元素描述和必要参数{ thought: 当前页面有搜索框位于页面左上角, action: click_and_type, target: search_input, value: DGX Spark }这里值得关注的性能指标是首 token 延迟和单步推理耗时。在本地推理时这两个数字直接影响用户体感。如果单步推理超过 10 秒Agent 操作浏览器就会出现明显的“卡顿感”。5.4 执行阶段动作翻译与浏览器操作模型输出动作后由 Agent 框架翻译成浏览器自动化调用。比如click_and_type会变成一组坐标定位、鼠标点击、键盘输入操作。这一步最容易出错的地方是元素定位——模型根据截图判断的坐标和页面实际 DOM 可能有偏差尤其遇到动态加载的页面元素时。5.5 验证阶段截图回环与失败重试动作执行完后Agent 会再次截图并把新画面放进上下文判断上一个动作是否达到了预期效果。这是整个闭环里最容易出问题的环节页面内容加载慢截图时内容还没渲染出来弹窗遮挡了目标元素上下文过长导致模型忽略了关键视觉信息。正确做法是在动作执行后增加一个固定等待时间比如 1 到 2 秒再截图验证。这个等待时间就是配置里screenshot_interval参数的用途。5.6 演示成功的判断标准一次成功的现场演示至少要同时满足三个条件Agent 能理解任务并生成符合页面结构的操作序列单步操作真实生效浏览器画面发生对应变化整个过程中推理链路稳定没有出现 OOM、断连、重复点击。如果只是想验证“本地运行”最直观的展示方式是**在断网或隔离网络环境下Agent 依然能完整跑完任务。**这能证明推理不依赖云端是整个演示最有力的证据。6. 运行验证与效果评估6.1 检查推理服务状态部署完成后先验证推理服务是否就绪curl -s http://127.0.0.1:8000/v1/models | python3 -m json.tool预期输出是一个 JSON 数组里面包含已加载的模型名称{ object: list, data: [ { id: qwen2.5-vl-7b-instruct, object: model, created: 1710000000, owned_by: vllm } ] }如果返回空数组或连接失败优先检查 vLLM 容器是否还在运行以及端口映射是否正常。6.2 用 Python 脚本做服务就绪检测Agent 进程启动时可能比推理服务更快导致请求失败。建议在 Agent 启动前加一个就绪检测脚本# 文件路径/opt/computer-use/wait_for_model.py import time import sys import requests def wait_for_model(base_url: str, timeout: int 300): 等待 vLLM 推理服务就绪最多等待 timeout 秒。 就绪后返回 True超时则抛出异常。 deadline time.time() timeout while time.time() deadline: try: resp requests.get(f{base_url}/v1/models, timeout5) if resp.status_code 200 and resp.json().get(data): print(推理服务已就绪:, resp.json()[data][0][id]) return True except Exception as exc: print(等待推理服务中:, exc, flushTrue) time.sleep(5) raise TimeoutError(f推理服务在 {timeout} 秒内未就绪) if __name__ __main__: wait_for_model(sys.argv[1] if len(sys.argv) 1 else http://127.0.0.1:8000)运行方式python3 /opt/computer-use/wait_for_model.py http://127.0.0.1:80006.3 验证“是否真的跑在本地”这是整个部署最关键的验收环节。验证方法很简单断开设备的外部网络访问在纯内网环境里重新启动整套服务然后跑一次完整的 Agent 任务。如果任务仍能完成说明模型加载、视觉编码、动作执行全部在本地闭环。如果任务在断网后失败优先检查配置里是否残留了云端 API 地址、模型下载地址或外部依赖调用。6.4 关键性能指标建议在演示或测试过程中记录以下指标它们是评估本地方案是否可用的核心依据指标说明参考阈值单步推理延迟模型输出一个动作的耗时越低越好超过 10 秒体感明显卡顿上下文增长每步截图带来的 token 增量需关注是否接近 max-model-len任务成功率完整跑通任务的比例低于 70% 说明模型或配置需要调整内存占用推理服务与浏览器的内存变化接近 128GB 上限时需减小模型上下文7. 常见问题与排查思路问题现象可能原因排查方式解决方案模型加载时内存不足上下文窗口设置过大或量化精度选择不当查看 vLLM 启动日志和内存占用缩短max-model-len改用更低精度的量化权重关闭其他占用内存的进程容器启动后无法访问 GPUNVIDIA Container Toolkit 未安装或版本不匹配执行docker run --rm --runtimenvidia nvidia/cuda nvidia-smi安装或升级 NVIDIA Container Toolkit确认NVIDIA_VISIBLE_DEVICES环境变量拉取镜像后运行报 exec format error镜像架构与 ARM64 不兼容执行 docker image inspect 镜像名grep Architecture浏览器截图全黑或空白容器内 Chromium 未正常启动或 GPU 合成导致渲染异常查看浏览器容器日志通过 VNC 端口连接观察画面关闭浏览器 GPU 加速参数增加shm_sizeAgent 反复点击同一位置页面动态加载导致元素位置变化或模型上下文过长对比相邻两步的截图时间戳和 DOM 状态增加动作后等待时间清理历史截图 token降低max_steps单步推理越来越慢上下文堆积导致 prefill 耗时增长查看 vLLM 日志的 token 数和延迟统计开启自动摘要压缩上下文或拆分长任务为多个子任务Agent 访问了不该访问的地址安全边界配置缺失或白名单未生效查看 Agent 日志中的请求 URL配置allowlist_domains和denylist_domains并用代理层统一拦截8. 最佳实践与工程建议8.1 版本固定与可复现性本地部署不等于不用做版本管理。推理镜像、Agent 框架、模型权重都要做版本固定镜像使用带 tag 的地址避免latest在下次拉取时静默变化记录模型权重的 sha256 值发布前做一次完整性校验把完整的docker-compose.yml、Agent 配置和服务文件纳入 Git 仓库。8.2 安全边界设计Computer Use Agent 本质上是一个“能操作电脑的程序”安全边界必须前置设计浏览器放在独立容器中不与宿主机共享文件系统Agent 只暴露必要的本地 API 给编排系统不对公网开放使用域名白名单限制 Agent 可访问的地址涉及账号密码、Cookie、生产系统的操作必须在流程中增加人工确认步骤不要让 Agent 直接接触数据库、支付接口等高危能力。8.3 监控与日志Agent 的每一步操作都应该是可审计的。建议至少记录每步的截图文件和时间戳模型输出的原始动作指令浏览器执行结果和报错信息推理服务的延迟和内存指标。日志采用结构化格式比如 JSON line方便后续接入日志平台。截图按任务 ID 分目录保存回放问题时直接看截图序列就能定位是哪一步出了偏差。8.4 回滚策略改动模型版本或 Agent 配置前保留当前可用的镜像和配置文件副本。建议用目录快照的方式保存整套部署状态# 部署前备份当前可运行版本 cp -a /opt/computer-use /opt/computer-use-backup-$(date %Y%m%d)如果是模型权重变更保留旧权重目录或软链接切换不要原地覆盖。出问题时把软链接切回旧版本重启服务即可完成回滚。8.5 上下文管理长任务最大的敌人是上下文长度。DGX Spark 的 128GB 统一内存缓解了硬件压力但软件层面仍要做好上下文管理开启 vLLM 的自动前缀缓存对历史截图做压缩或摘要而不是无限堆叠设置单任务最大步数超过阈值强制中断并汇总结果。9. 总结与后续学习方向这篇文章真正想讲清楚的不只是“Perplexity Computer 能跑在 DGX Spark 上”这个结果而是它背后的架构判断**Computer Use Agent 的完整闭环已经可以在本地硬件上独立完成。**从 Perplexity Computer 的多模态推理到动作执行从 DGX Spark 的 128GB 统一内存到 ARM64 容器化部署整条链路都是可以复现和落地的。如果你手上有一台 DGX Spark下一步最值得做的事是先下载一个开源 VLM把 vLLM 推理服务跑起来再配合一个计算机操作框架在容器化浏览器里完成一个小任务。先跑通最小闭环再逐步增加任务复杂度。建议收藏本文部署时对照检查清单逐项验证。再往后值得深入的方向有三个一是用强化学习微调模型让 Agent 的操作成功率更高二是把多台 DGX Spark 用互联技术组网跑更大参数规模的模型三是把本地 Agent 和企业的权限体系、审计系统对接让它真正进入生产流程。最后提醒一句本地运行降低了数据外泄的风险但并没有消除 Agent 自身的操作风险。任何让模型直接控制浏览器的场景都要先过安全设计这一关。