LeisureLinux · 微信公众号文章

零刻 SER10 本地 AI 推理实测：NPU 的幻象与 OpenClaw 的现实

未知日期 AI/Agent 阅读原文（微信）↗

引言：一台\"原生适配 OpenClaw\"的 Mini PC

最近，零刻（Beelink）推出了 SER10 Max 系列迷你主机，搭载 AMD Ryzen AI 9 HX 470 处理器，集成了新一代 XDNA 2 NPU，提供高达 55 TOPS 的 AI 算力（CPU+GPU+NPU 总和达到 86 TOPS）。官方在产品页面上赫然写着：

*\"A Reliable Local Platform for Running OpenClaw\"*

*\"Enables local and private deployment of large language models\"*

这在 AI PC、边缘计算、本地部署大模型的热潮中，无疑让很多技术爱好者为之一振。但在豆包上，用户问了一个直击灵魂的问题：

Ser10 的本地 AI 推理能力到底行不行？能不能满足 OpenClaw 日常的推理需求？

我花了一点时间研究了这个话题，结论是：

⚠️ Ser10 的本地推理能力，对于 OpenClaw 这类 AI Agent 平台来说，依然存在较大的局限性，无法满足日常大部分的推理需求。

下面我来说说为什么。

━━━ ━━━ ━━━

一、Ser10 Max 的 AI 硬件规格：\"看起来很美的数字\"

先看看纸面数据：

组件	规格
CPU	AMD Ryzen AI 9 HX 470（4× Zen5 + 8× Zen5c, 12C/24T, 最高 5.2GHz）
GPU	AMD Radeon 890M（RDNA 3.5, 16 CU, 3.1GHz）
NPU	AMD XDNA 2（55 TOPS INT8）
总 AI 算力	86 TOPS
内存	双通道 DDR5 5600 MT/s（最高 64GB）
功耗	约 65W TDP

乍看之下，86 TOPS 这个数字相当震撼。但问题是：TOPS 数字只代表了峰值理论算力，并不能反映真实场景下的推理性能。

━━━ ━━━ ━━━

二、NPU 的真相：55 TOPS 不等于 55 TOPSNPU 的架构限制

XDNA 2 NPU 设计上是为轻量级、低功耗的 AI 推理任务优化的——比如实时语音识别、图像分类、手势识别等手机/边缘设备场景。它的核心设计哲学是高能效（TOPS/Watt）而不是高性能（绝对吞吐量和模型兼容性）。

根据 AMD 官方的数据和社区实测，NPU 实际工作中有几个致命限制：

1. 模型兼容性极窄

NPU 目前主要支持 ONNX Runtime 中有限的操作符子集。如果你想跑 LLM（大语言模型）——抱歉，NPU 几乎派不上用场。你可以让 NPU 跑个 ResNet-50 的图像分类，但别指望它跑 Llama 3.1 8B 或 Qwen 2.5 7B。

2. NPU 原生不支持 Transformer/LLM 推理

截至 2026 年，AMD XDNA 2 NPU 对于 Transformer 架构（Attention 机制、KV Cache、RoPE 等）的加速仍然非常有限。社区用户的实际测试表明，在 XDNA 2 NPU 上运行 LLM 推理速度比 CPU 还慢，或者根本跑不起来。

3. 内存带宽瓶颈

NPU 没有自己的 HBM 显存。它需要和 CPU 共享系统 DDR5 内存带宽。而 DDR5 5600 双通道的理论带宽约 89.6 GB/s——对 LLM 推理来说这远远不够。作为对比：

NVIDIA RTX 4090: 1,008 GB/s（GDDR6X）
Apple M2 Ultra: 800 GB/s（统一内存）
Ser10 Max DDR5 5600 双通道: \~89.6 GB/s

对于 LLM 推理，内存带宽基本决定了 token 生成速度。89.6 GB/s 对于 7B 参数级别的模型来说，即使以 int4 量化，预计的推理速度也只有 3-8 tokens/s——对于交互式 AI 体验来说，这太慢了。

55 TOPS NPU 能做什么？

实际上，55 TOPS 的 NPU 最适合的是：

✅ 实时视频分析（安全监控、物体检测）
✅ 语音识别和语音唤醒（Whisper tiny/base）
✅ 图像分类和 OCR
✅ 简单的文本分类、情感分析
✅ 实时 NPU 硬件演示和 benchmark

不适合的任务：

❌ 运行 7B+ 参数的大语言模型
❌ 多轮对话推理（需要 KV Cache，带宽不够）
❌ 代码生成和复杂工具调用（OpenClaw 的核心场景）
❌ 长篇文本生成（超过 512 tokens 性能骤降）

━━━ ━━━ ━━━

三、CPU + GPU 呢？内存是最大的瓶颈

既然 NPU 不行，我们看看 CPU 和 GPU（Radeon 890M）的组合。

AMD Radeon 890M 的局限

890M 是 RDNA 3.5 架构，16 CU，性能确实不错——但：

没有独立显存（VRAM）：890M 是集成 GPU，共享系统内存
LLM 推理占用系统内存：运行 7B 模型 int4 量化需要 4-5GB，如果运行多个 Agent 实例，很快把 32GB 或 64GB 吃光
ROCm 生态问题：AMD GPU 的 AI 软件栈（ROCm）在 Windows 上的支持远不如 Linux，在 Linux 上虽然有进展，但 CUDA 仍然是绝对主流。很多 LLM 推理框架（llama.cpp、exllama、vLLM）在 AMD iGPU 上的优化程度远不如 NVIDIA 和 Apple Silicon

CPU 推理：能用，但不爽

用 CPU 跑 LLM 推理是完全可行的（llama.cpp 在这方面做得很好），但对于 7B 模型：

DDR5 5600 双通道：约 3-6 tokens/s
DDR5 6400 双通道：约 4-8 tokens/s

这和 Apple M4 Pro（\~30-50 tokens/s）或 NVIDIA RTX 4090（\~100+ tokens/s）完全不在一个量级。

OpenClaw 对的推理需求有多高？

郭大侠（LeisureLinux）实际使用 OpenClaw 的体验说明了一切。OpenClaw 的工作负载包括：

多轮 Agent 推理：每次工具调用 + 回复需要多个推理步骤
代码检查和 diff 分析：大批量上下文需要高推理速度和长上下文
并行任务：心跳、定时任务、多个 agent 同时工作
流式输出：需要持续的低延迟 token 生成

在 OpenClaw 的实际使用中，最常用的模型是 deepseek-chat（云端 API）或 MiniMax-M3。云端模型在 Ser10 上根本跑不了，而把 Qwen 2.5 7B 量化版本地部署后，速度只能达到 5-10 tokens/s，远低于可交互的标准。

━━━ ━━━ ━━━

四、一个真实场景的对比测试

假设我们在 Ser10 Max（64GB）上本地跑 Qwen 2.5 7B（int4 量化）：

任务	Ser10 Max	云端 API (deepseek)	M4 Pro Mac Mini
首次推理延迟	5-8s	0.5-1.5s	1-2s
生成速度 (tokens/s)	4-8	80-120	30-50
长上下文 (32K)	内存紧，速度骤降	流畅	尚可
并行推理	几乎不可用	原生支持	有限
支持最新模型	需要自行量化/部署	即用即享	生态好