PixelUMM vs UI-Mate-27B：一个模型绘制它所看到的，另一个则点击它

Tencent UI-Mate-27B 和 NVIDIA PixelUMM 从规格表上看似乎不相上下——270 亿参数对约 152 亿参数，两者都开放下载，也都基于 Qwen 骨干构建——但它们根本不可比。UI-Mate-27B是一个基础 GUI 智能体：它观察实时屏幕截图，根据当前屏幕上显示的内容进行规划，并为真实桌面发出结构化的鼠标和键盘操作。PixelUMM是一个无编码器的统一多模态模型，它在原始像素空间中读取图像和视频，并根据文本生成图像和视频——它能感知，也能创造，但它没有动作空间、没有光标，也无法触碰屏幕。一个作用于世界。另一个描述并描绘世界。下面的一切都源于这一区分，而它们之间的许可差异是你需要知道的第二件事。

两个实验室各自报告自己的数据，且都没有独立评估。两者都是悄然发布——而发布风格，正是相似之处真正终结的地方。

行动者与知觉者

UI-Mate-27B 仅凭自然语言指令和实时截图即可执行任务。它会基于可见状态进行推理，随着界面变化重新规划，并输出推理过程、简洁的操作描述以及结构化的计算机操作工具调用，涵盖鼠标、键盘、滚动、等待、用户交互和任务完成。其显著特性是演示引导式执行：只需向它展示一次工作流程，它就能将录制的演示适配到当前任务，并在界面已经发生变化时以当前截图为准。它基于 Qwen3.6-27B 进行微调，先采用监督微调，随后在可执行的 GUI 环境中进行在线强化学习，并通过 vLLM 以 OpenAI 兼容接口提供服务。

• 已报告的基准测试成绩 — OSWorld-Verified 平均 77.0，WindowsAgentArena 平均 66.2，OSWorkerBench 严格成功率 41.00、进度 76.86。均为腾讯自行报告，尚未复现。

• 动作空间 — 鼠标、键盘、滚动、等待、用户交互、任务完成，位于标准化坐标空间中，采用与 pyautogui 兼容的结构化调用。

• 硬件现实 — 27B 稠密模型，在腾讯自家的快速入门中通过张量并行部署于两块 GPU 上，基于 Apache-2.0 许可。

• 关于该卡片本身的一个重要提醒——UI-Mate-27B 是一个智能体检查点，而非独立的视觉对话模型。腾讯建议使用其代码仓库中提供的官方提示词、响应解析器和交互框架。若让它去执行“描述这张图片”这类任务，那你就是用错了工具。

PixelUMM 则占据着相反的一极。它的整个架构本身就是一场关于表征的论证：没有 VAE，没有视觉编码器，图像是 16×16 的像素块，视频是 4 帧的时空管状单元，经单层线性投影直接送入仅含解码器的 Transformer，并采用 Mixture-of-Transformers 设计，将共享注意力与任务专属参数配对。理解是自回归文本；生成是像素空间流匹配。共有四个检查点发布，S8-F22-R05 作为默认版本，涵盖文生图、96 帧、24 fps 的文生视频，以及两个理解方向。

这两种发布模式形成了鲜明对比

UI-Mate-27B 于 2026 年 8 月 14 日出现在 Hugging Face 上，同时附有模型卡、编号为 2608.15930 的 arXiv 预印本、项目主页、GitHub 仓库以及一份有文档记录的部署方案。从那时起到 10 月初，它累计获得了约 780 次下载和 93 个点赞——不算多，但作为一次研究型智能体的发布，各项材料齐备，实属正常。

PixelUMM 的踪迹则性质不同。其 GitHub 仓库创建于 2026 年 9 月 4 日；arXiv 预印本日期为 9 月 29 日；Hugging Face 仓库创建于 2026 年 10 月 1 日 21:40 UTC，就在该仓库最后一次提交后几分钟。没有出现关于它的 NVIDIA 博客文章、新闻稿或发布帖。该项目页面自身的 URL 路径至今仍显示为 pixelumm-project-page-preview。在撰写本文时，其下载量为零。

从中揣测意图是个错误——实验室可以先发布研究成果，再把正式发布安排在以后。真正可知的东西更有限，也更有用：一个模型有官方服务路径和十周的下载量；另一个只有一篇论文、一个代码仓库，完全没有厂商声明。

不重叠的记分牌

两个模型都没有报告同一个基准测试结果，而这本身就是关键所在：它们解决的问题并不相同。

• 智能体式计算机操作 — UI-Mate-27B：OSWorld-Verified 77.0，WindowsAgentArena 66.2。PixelUMM：无动作空间，因此无法评分。

• 图像理解 — UI-Mate-27B：将屏幕截图作为智能体输入使用，未作为通用 VLM 进行评估。PixelUMM：MMMU 41.67、AI2D 80.12、DocVQA 90.42、ChartQA 82.96、OCRBench 78.00。

• 视频——UI-Mate-27B：无。PixelUMM：MVBench 70.53，Video-MME 57.33，LongVideoBench 59.61，LVBench 40.41。

• 生成 — UI-Mate-27B：无。PixelUMM：搭配提示词重写器时 GenEval 0.83，DPG-Bench 85.74，VBench 第 1 部分质量 84.10。

• 部署成本——UI-Mate-27B：通过 vLLM 在约两块 GPU 上运行 27B 稠密模型，外加官方评测框架。PixelUMM：约 30 GB 的分布式检查点分片、需从源码构建 FlashAttention 的 CUDA 13、用于视频路径的需授权访问的护栏模型，以及为其单独准备的第二个 Python 环境。

• 许可 — UI-Mate-27B：Apache-2.0，代码与权重。PixelUMM：代码采用 Apache-2.0，检查点适用 NVIDIA One-Way Noncommercial License。

• 规模 — 27B 密集模型对比总计约 15.2B，在 PixelUMM 自己的论文表格中标注为"8B MoT"。

唯一真正可比较的陈述是关于出处的，而且它适用于两者：上面每一个数字都出自厂商自己，没有一个是在产生它的实验室之外重新运行过的，而且这两个模型中的一个明确将自己的结果标注为初步结果。

用它们构建，以及为什么你可能两者都会用

这两者搭配使用的效果优于彼此竞争。桌面自动化技术栈需要 UI-Mate-27B 承担执行层，还需要一个能对所见内容进行推理的组件；内容或检测流水线则需要 PixelUMM 的读取与生成能力，而根本用不到光标。二者的重叠处在感知边界：UI-Mate-27B 的截图定位是任务特定的，而 PixelUMM 的是通用的——同样的像素，两种截然不同的任务。

当你确实要将多个模型相互对比运行时——让智能体对通用 VLM，或让新的研究检查点对已在生产中的那个——比较的成本通常在于集成，而不是推理：两套 API 形态、两套认证方案、两份契约。这正是路由层旨在消除的问题，也是 OrcaRouter 的设计发挥作用之处：一个密钥畅行 200+ 模型，按提供商标价以 0% 加价透传，跨提供商自动故障转移，以及用于将多个模型组合成单次调用的路由 DSL 加模型融合。如今 PixelUMM 和 UI-Mate-27B 都不在任何托管端点上，并且OrcaRouter 对两者都不提供路由——所以这里讲的是当它们上线后的工作流，而不是对当前可用性的断言。

哪一种工作用哪一个？

如果任务以点击、按键或填写表单收尾，那么这里只有一个候选者，那就是 UI-Mate-27B。它采用 Apache-2.0 许可，有 arXiv 论文和官方测试框架，而且它报告的 OSWorld 和 WindowsAgentArena 得分属于那种任何人有两块 GPU、再加一个 Windows 或 Ubuntu 测试镜像就能核实的说法——而这恰恰意味着它值得去核实，而不是直接采信。

如果任务最终以答案或图像收尾，PixelUMM 正是能做到这一点的那个，而且它首先是一个研究产物。它的论文对自身局限异常坦诚，承认由于训练数据不同，其基准比较“无法确立哪种架构更优越”。它的检查点采用非商业许可。它的优势在于架构新颖性和广度，而非最先进的指标，其直接价值在于任何研究无编码器统一模型能否在视频规模上奏效的人。下载它是为了阅读代码并运行演示；不要为了交付功能而下载它。

这个两行总结与证据给出的结论相同：一个模型能行动却不能创造，另一个模型能创造却不能行动，而两者之间在许可和成熟度上的差距，比任何参数量都更重要。