养龙虾，服务器别乱选

智能代理工具的普及速度之快令人难以置信。无论您使用的是OpenClaw 还是其他同类产品，我们都经常听到一些关键概念，因此我们决定编写一份指南，帮助那些想要入门的人。OpenClaw 的流行如同火箭般蹿升，如今企业部署的场景仿佛回到了上世纪 90 年代的硅谷办公室，人们在隔间里使用Sun Ultra工作站运行着重要的公司应用程序。

简单说明一下，我们撰写本文的原因之一是与AMD就我们所观察到的情况进行了讨论。同时，本文中的信息也普遍适用于多种不同的架构。

架构分离：CPU 和 GPU 的根本区别

或许我们能讨论的最重要的概念就是架构分离。读到这里的人可能会分成两类：一类人理所当然地认为事情本来就是这样运作的，另一类人则没有意识到这种分离的存在。

像OpenClaw 这样的 AI 代理框架执行两种截然不同的计算工作负载，架构分离使其优势显著。代理编排负责工具调用、工作流状态管理、API 集成、对话历史跟踪、内存操作、多代理协调以及业务逻辑执行。这是 CPU 密集型工作，主要涉及整数运算和内存访问模式——典型的经典计算。LLM（大型语言模型）推理则负责 Transformer 矩阵运算、注意力机制计算、词元生成、嵌入计算等等。这是 GPU 加速工作，主要涉及浮点矩阵乘法、内存容量和内存带宽。

为了方便大家理解，我们不妨这样解释一下。“AI代理”（例如OpenClaw）运行在CPU核心上，执行许多传统的CPU任务。而真正让这个框架成为热门话题、颠覆性创新的关键在于LLM后端。如今，LLM后端通常运行在GPU上，承担着这些工作流程中的大部分计算任务，这也是它如今如此受关注的原因。总之，这种架构划分对于应用程序的运行至关重要。

2026年初，运行OpenClaw的主流架构是搭载M4 Pro芯片的苹果Mac Mini系统。OpenClaw有自己的应用程序，使用Homebrew安装也很简单，而且在Mac上运行（尽管存在潜在的安全隐患）还能访问iMessage。这导致Mac Mini系统供不应求，人们很快意识到在云虚拟机或廉价VPS上运行OpenClaw也是可行的，而且还能获得公网IP地址（同样存在潜在的安全隐患）。

苹果Mac Mini 之所以成为 OpenClaw 的热门托管平台，另一个原因是它采用了统一内存架构，CPU 和 GPU 共享同一个内存池。这种配置允许分配更多内存来存储更大的LLM（逻辑层模型），因此本地 LLM 和内存嵌入模型可以在本地运行，而无需使用云服务提供商。正是这种部署方式造成了许多误解，人们误以为 OpenClaw 或其他 AI 代理在单台机器上运行效果最佳。实际上，大多数使用 OpenClaw 取得最佳效果的用户都运行了可以利用更多 GPU 内存的远程 LLM，但这种一体化部署方案，加上添加 API 密钥的便捷性，导致人们误以为 OpenClaw AI 代理（CPU）和 LLM 后端（GPU）是同一回事，而不是不同的计算需求。

最近，我们看到像Anthropic 这样的公司采取措施，限制其部分订阅计划中 OpenClaw 的使用，因为它变得非常受欢迎。

与此同时，新型专家模型组合的性能也得到了显著提升。这不仅促使苹果Mac Mini、Mac Studio等产品投入使用，NVIDIA也推出了基于GB10的解决方案，AMD则推出了基于Strix Halo（AMD Ryzen AI Max+ 395）的系统，用于运行AI代理。NVIDIA和AMD都配备了128GB的LPDDR5X内存，虽然其内存带宽不及PCIe GPU，但足以支持运行规模更大的模型，并实现可接受的量化精度。用户在苹果、AMD和NVIDIA的硬件上运行本地AI模型，并利用同一硬件运行OpenClaw或其他AI代理，这种一体化机器的概念得到了进一步发展，但这种模式也存在诸多弊端。

就像二十五年前硅谷的办公室隔间里运行Sun Ultra工作站一样，在开放式办公空间运行重要的AI代理也会带来诸多问题。毫不夸张地说，当员工自带硬件时，执行企业安全策略极具挑战性。边缘网络、电源供应，甚至有人带着这些小型机器离开办公室，都可能影响正常运行时间。备份和数据保留也难以实施。此外，这种分散式计算通常会导致大量计算、存储或内存资源闲置。

人们在桌面上配备人工智能代理服务器是未来我们可能会看到的一种模式，但对于企业而言，在数据中心运行人工智能代理服务器则具有诸多优势。有些人可能认为这一切前所未有，但其实早在二十五年前，企业就已将计算资源迁移到数据中心，而像VMware 这样的公司也帮助企业提高了运行效率。虽然在接下来的几十年里，我们并非都转向了瘦客户机，但关键计算资源的部署方式确实发生了变化。

当我们讨论运行OpenClaw 时，随着代理对业务的重要性日益凸显，它们自然而然地会迁移到数据中心，这也是如今数据中心 CPU 备受关注的原因。对于 LLM（层级模型）而言，尽管网上各种炒作文章都在强调小型和高度量化模型的优势，但实际上，更大的模型往往能带来更好的结果。未来几个季度，我们将迎来单颗高端（数据中心级）GPU 功耗远超北美普通 15A 120V 电路供电能力的时代。这些 GPU 集群能够更快地运行大型模型，因此，仅从功率密度角度来看，LLM 的运行就必须在数据中心进行。

大家都知道我是本地AI计算的坚定支持者。我们工作室有几TB的GPU内存用于运行本地LLM，所以我想分享一些关于托管OpenClaw的想法，这些想法是我在本地和连接到数据中心计算的各种硬件上运行OpenClaw的过程中不断尝试和总结出来的。

OpenClaw 的秘密：越大越好

无论是小规模部署还是大规模部署，都有其用武之地，这毋庸置疑。目前，我们工作室有15 到20 台配备128GB LPDDR5X 统一内存的机器 24 小时全天候运行，这并非因为我们没有其他计算平台，而是因为我们一直在重新利用这些机器，并寻找新的用途。我们逐渐发现的一个“诀窍”是，在如此多的系统上运行 OpenClaw 代理并非明智之举。

运行一个代理程序必然会带动另一个代理程序的运行。这些代理程序可能会执行简单的shell 命令，或者打开网页浏览器会话并开始搜索，而不是使用爬虫工具。通常，AI 代理程序会并行执行这些任务。我们之所以将 OpenClaw、Turnstone、Hermes 和其他代理程序框架从 128GB LPDDR5X 节点上迁移出来，或许最重要的原因就是为了给它们分配内存，而这些内存也可能被 LLM 和 KV 缓存占用。2 月下旬，我们发现一个系统持续出现问题，原因是它打开了多个浏览器，占用了 GPU 端用于 LLM 的内存。回到代理程序 CPU 端和 LLM 后端分离的思路，这个问题就迎刃而解了。除了用于演示、文章和视频之外，我们现在已经将代理程序端与 LLM 服务端分离。

我们经常遇到的另一个问题是智能体可能会停滞不前。LLM 错误、意外输出、幻觉等等都可能导致项目失败。我们曾经有一个通宵项目因为一个较小的模型无法正确调用某个工具而停滞不前。模型偶尔会出现响应错误，诸如此类。从 gpt-oss-120b 升级到 MiniMax-M2.5 是一次巨大的能力提升。Qwen3.5-397b-a17b 也出现了，并且通过改进工具调用实现了类似的效果。当你使用 AI 智能体时，你实际上是在解决一个可靠性问题。如果你观察它们的运行，你会发现即使是小型工作流程也可能需要 100 多次 LLM 调用才能完成。在这种规模下，可靠性方程式中的每一个“9”都对最终完成至关重要。虽然你可以让其他智能体进行监控（希望它们能够准确监控），但如果因为一个较小或量化程度更高的模型引入的错误而导致你损失半天的工作，那将非常令人沮丧。

通常，用于内存其他许多任务的嵌入模型在较小的模型上就能很好地工作，因此也适用于较小的机器配置。同时，大型模型更高的可靠性才是真正让OpenClaw 这类工具从玩具变成近乎神奇的存在的原因。一个很好的例子是，使用 gpt-oss-120b 时，我们无法一次性可靠地搭建服务器。而使用 MiniMax-M2.5，除了需要提供身份验证的部分外，服务器可以自动搭建（尽管需要一些尝试和错误）。使用 Qwen3.5-397b-A17B 或之前的 Claude Code（搭配 Sonnet 4.6 和 Opus 4.6），我们已经搭建了完整的 RDMA 集群。

这与许多人的经验相符，而且新模型在运行智能体人工智能工作流程方面也取得了显著进步。这也充分说明了通过云API 连接到托管在更大型硬件上的大型模型是多么有效。

一旦你将LLM的运行位置拆分，以便运行更大的LLM，那么下一个问题就是代理应该在哪里运行。结果表明，答案往往是高性能（P核）CPU架构，如果可能的话，最好是更大的机器。

在服务器上运行OpenClaw 或 AI 代理才是正确的方式

几乎所有服务器CPU 公司，包括那些试图进入该领域的公司，都表示服务器CPU 的供应正面临挑战。虽然在桌面端运行OpenClaw 乍听起来是个好主意，但现实情况是，它既需要在服务器上运行，也需要更大的规模。人工智能代理正以惊人的速度增长，使得企业无法像许多组织那样快速地订购用于 OpenClaw、Turnstone、Hermes 或任何其他框架的新服务器。实际上，只要有足够的容量，在服务器上运行人工智能代理就可以让你快速大规模地部署OpenClaw。此外，随着行业的不断发展，几周或几个月后，解决方案可能就会变成另一个框架。企业已经知道如何在服务器上大规模部署和编排容器和虚拟机，因此，这是一个非常成熟的模型，我们在ServeTheHome 近 17 年的发展历程中几乎一直在讨论它。

在服务器上运行还允许企业使用熟悉的工具，例如容器备份、容器存储和虚拟机。它还允许将安全和网络策略应用于整个集群。

即使是像更可靠的网络和电力这样的小细节，也正成为部署中不可或缺的环节。随着人工智能代理（由更大型的模型支持）变得越来越有用，它们的重要性也日益凸显。那些声称在办公桌前运行预测市场机器人的人们，最终也会遭遇网络或电力中断，造成重大损失。就像传统的金融机构一样，他们将被迫寻求更高可靠性的托管服务，例如数据中心和服务器上的服务。这将促使他们优化延迟、运行更大的计算资源等等，就像大型交易公司长期以来一直在做的那样。除了交易的例子之外，关键业务功能之所以需要在具有更高可靠性的ECC内存、更快的服务器、更大更快的存储、更快的网络等环境中运行，是有原因的。

尽管有些人对此有所讨论，但通过大量的性能分析，我们发现CPU 端的表现与许多传统计算场景非常相似。而 LLM 端则完全不同。去年在 FP16 上运行 Deepseek-R1 671B 模型还算不错，但考虑到 CPU 在人工智能代理工作流程中的使用情况，现在我们很难想象还能做到这一点。

一些基本原则：

P核往往更胜一筹。目前我们已经测试了多种Arm 和 x86 架构。如果您追求的是高吞吐量和低延迟，那么大容量 P 核就是最佳选择。

E核心通常能实现更高的CPU与内存核心比率。这实际上也是AMD推出E核心的原因之一。我们在此次测试中测试了Zen 5（Turin）和Zen 5c（Turin Dense）。Zen 5c通常会牺牲每个核心的缓存容量，而且通常时钟频率也低于Zen 5。它的优势在于保留了P核心的计算能力，并且时钟频率高于E核心，例如Intel Xeon 6 6700E系列。

在大多数情况下，x86 架构上的 SMT（同步多线程）技术往往能带来更高的性能。但就像传统计算一样，SMT 也并非总是最佳选择。它不如增加一个完整的核心那样高效，但我们仍然观察到它带来的持续收益。通常，我们测试中那些 SMT 效果不佳的场景，是那些需要等待整个芯片更新才能完成核心/线程间通信的场景。拥有更多线程意味着你可以构建更大的线程间通信网络。

现在在整个芯片上运行代理程序几乎是荒谬的。我们早期遇到了一些奇怪的结果，因为我们遇到了工作负载中高度串行的部分，结果发现128 个核心中有 127 个处于空闲状态。在现代服务器CPU 上，您应该在同一节点上运行多个工作负载或多个代理程序。我们甚至在一些较小的节点上进行了测试，例如AMD EPYC 8004 和 Intel Xeon 6 SoC，在大多数情况下，在这些节点上运行单个代理程序实例是愚蠢的。

使用容器或者超额配置虚拟机内存非常有用。这些都是服务器管理的基本概念，但在内存价格昂贵且供应短缺的今天，它们可以节省大量成本。

除了性能之外，能够在更可靠的基础设施上运行、拥有更好的监控、备份和配置（我们已经看到许多OpenClaw 实例被重新部署）、在实例周围部署防火墙等等，都起到了很大的帮助。对于我们的读者来说，这是一个在新兴领域引领潮流的机会。

当前市场对服务器CPU的关注是合理的。整个行业正朝着这个方向发展。推动这一趋势的关键在于，我们正迅速迈向智能体之间相互通信的时代。一些公司已经小规模地完成了原型设计，而另一些公司则已经开始大规模部署。尽管发展过程中难免会遇到一些障碍，但通过增加计算能力来扩展工作规模的能力意味着，我们将进入一个计算能力至关重要的时期。这正是导致计算、内存和存储资源稀缺的原因。如果你还没用过 OpenClaw 或其他 AI 代理平台，笔者强烈建议你花些时间去尝试一下。