養龍蝦，服務器別亂選

在服務器上運行OpenClaw或AI代理才是正確的方式。

智能代理工具的普及速度之快令人難以置信。無論您使用的是OpenClaw 還是其他同類產品，我們都經常聽到一些關鍵概念，因此我們決定編寫一份指南，幫助那些想要入門的人。OpenClaw 的流行如同火箭般躥升，如今企業部署的場景仿佛回到了上世紀 90 年代的硅谷辦公室，人們在隔間里使用Sun Ultra工作站運行著重要的公司應用程序。

簡單說明一下，我們撰寫本文的原因之一是與AMD就我們所觀察到的情況進行了討論。同時，本文中的信息也普遍適用于多種不同的架構。

架構分離：CPU 和 GPU 的根本區別

或許我們能討論的最重要的概念就是架構分離。讀到這里的人可能會分成兩類：一類人理所當然地認為事情本來就是這樣運作的，另一類人則沒有意識到這種分離的存在。

OpenClaw CPU代理和LLM推理

像OpenClaw 這樣的 AI 代理框架執行兩種截然不同的計算工作負載，架構分離使其優勢顯著。代理編排負責工具調用、工作流狀態管理、API 集成、對話歷史跟蹤、內存操作、多代理協調以及業務邏輯執行。這是 CPU 密集型工作，主要涉及整數運算和內存訪問模式——典型的經典計算。LLM（大型語言模型）推理則負責 Transformer 矩陣運算、注意力機制計算、詞元生成、嵌入計算等等。這是 GPU 加速工作，主要涉及浮點矩陣乘法、內存容量和內存帶寬。

Beelink ME Pro NAS Proxmox VE 設置 OpenClaw 子代理

為了方便大家理解，我們不妨這樣解釋一下。“AI代理”（例如OpenClaw）運行在CPU核心上，執行許多傳統的CPU任務。而真正讓這個框架成為熱門話題、顛覆性創新的關鍵在于LLM后端。如今，LLM后端通常運行在GPU上，承擔著這些工作流程中的大部分計算任務，這也是它如今如此受關注的原因。總之，這種架構劃分對于應用程序的運行至關重要。

2026年初，運行OpenClaw的主流架構是搭載M4 Pro芯片的蘋果Mac Mini系統。OpenClaw有自己的應用程序，使用Homebrew安裝也很簡單，而且在Mac上運行（盡管存在潛在的安全隱患）還能訪問iMessage。這導致Mac Mini系統供不應求，人們很快意識到在云虛擬機或廉價VPS上運行OpenClaw也是可行的，而且還能獲得公網IP地址（同樣存在潛在的安全隱患）。

Beelink ME Pro NAS Proxmox VE 設置 OpenClaw 第3步

蘋果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 這樣的公司也幫助企業提高了運行效率。雖然在接下來的幾十年里，我們并非都轉向了瘦客戶機，但關鍵計算資源的部署方式確實發生了變化。

華擎機架式機箱TURIND8 2L2T，已安裝 AMD EPYC 9755

當我們討論運行OpenClaw 時，隨著代理對業務的重要性日益凸顯，它們自然而然地會遷移到數據中心，這也是如今數據中心 CPU 備受關注的原因。對于 LLM（層級模型）而言，盡管網上各種炒作文章都在強調小型和高度量化模型的優勢，但實際上，更大的模型往往能帶來更好的結果。未來幾個季度，我們將迎來單顆高端（數據中心級）GPU 功耗遠超北美普通 15A 120V 電路供電能力的時代。這些 GPU 集群能夠更快地運行大型模型，因此，僅從功率密度角度來看，LLM 的運行就必須在數據中心進行。

大家都知道我是本地AI計算的堅定支持者。我們工作室有幾TB的GPU內存用于運行本地LLM，所以我想分享一些關于托管OpenClaw的想法，這些想法是我在本地和連接到數據中心計算的各種硬件上運行OpenClaw的過程中不斷嘗試和總結出來的。

OpenClaw 的秘密：越大越好

無論是小規模部署還是大規模部署，都有其用武之地，這毋庸置疑。目前，我們工作室有15 到20 臺配備128GB LPDDR5X 統一內存的機器 24 小時全天候運行，這并非因為我們沒有其他計算平臺，而是因為我們一直在重新利用這些機器，并尋找新的用途。我們逐漸發現的一個“訣竅”是，在如此多的系統上運行 OpenClaw 代理并非明智之舉。

Minisforum MS S1 Max 內角 2

運行一個代理程序必然會帶動另一個代理程序的運行。這些代理程序可能會執行簡單的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”都對最終完成至關重要。雖然你可以讓其他智能體進行監控（希望它們能夠準確監控），但如果因為一個較小或量化程度更高的模型引入的錯誤而導致你損失半天的工作，那將非常令人沮喪。

Supermicro 4U AMD Instinct MI355X 液冷主板，OCP 2025 1

通常，用于內存其他許多任務的嵌入模型在較小的模型上就能很好地工作，因此也適用于較小的機器配置。同時，大型模型更高的可靠性才是真正讓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 年的發展歷程中幾乎一直在討論它。

技嘉B343 C40 AAJ1 AMD EPYC 4005 處理器

在服務器上運行還允許企業使用熟悉的工具，例如容器備份、容器存儲和虛擬機。它還允許將安全和網絡策略應用于整個集群。

即使是像更可靠的網絡和電力這樣的小細節，也正成為部署中不可或缺的環節。隨著人工智能代理（由更大型的模型支持）變得越來越有用，它們的重要性也日益凸顯。那些聲稱在辦公桌前運行預測市場機器人的人們，最終也會遭遇網絡或電力中斷，造成重大損失。就像傳統的金融機構一樣，他們將被迫尋求更高可靠性的托管服務，例如數據中心和服務器上的服務。這將促使他們優化延遲、運行更大的計算資源等等，就像大型交易公司長期以來一直在做的那樣。除了交易的例子之外，關鍵業務功能之所以需要在具有更高可靠性的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 代理平臺，筆者強烈建議你花些時間去嘗試一下。

*聲明：本文系原作者創作。文章內容系其個人觀點，我方轉載僅為分享與討論，不代表我方贊成或認同，如有異議，請聯系后臺。