1. 项目概述在NVIDIA DGX Spark上部署NemoClaw智能体框架如果你手头有一台NVIDIA DGX Spark并且想在上面跑一个既安全又强大的AI智能体那么NemoClaw绝对是一个值得深入折腾的方案。NemoClaw本质上是NVIDIA官方推出的一个“沙盒化”OpenClaw智能体运行环境。简单来说它把OpenClaw这个能调用工具、上网搜索、执行代码的AI智能体装进了一个由OpenShell技术构建的隔离容器里。在这个沙盒里智能体的每一次网络请求、文件访问甚至模型推理调用都受到严格声明式策略的控制未经你明确允许它什么都干不了。这解决了我们在本地部署强大AI智能体时最担心的安全问题怕它乱改文件、怕它随意联网、怕它消耗资源失控。而DGX Spark作为NVIDIA面向边缘和轻量级AI推理推出的紧凑型工作站凭借其单卡128GB的统一内存和Blackwell架构的GB10 GPU成为了本地运行百亿参数级别大模型的理想平台。这个项目文档就是我把自己在DGX Spark上从零部署NemoClaw并逐一尝试云推理、Ollama本地推理以及高性能Atlas推理引擎的完整过程、踩过的坑和最终的性能数据整理成的一份实战指南。无论你是想快速体验还是追求极致的本地推理速度抑或是想深入理解这套安全架构都能在这里找到可操作的步骤和背后的原理。2. 核心架构与硬件环境解析2.1 为什么选择NemoClaw与DGX Spark的组合在开始动手之前我们先理清几个关键选择背后的逻辑。首先为什么是OpenClaw在众多AI智能体框架中OpenClaw由NVIDIA主导开发其最大特点是原生对工具调用Tool Calling和函数执行Function Calling有深度优化并且与NVIDIA的Nemotron系列模型配合默契。很多智能体框架在复杂任务规划上可能更强但OpenClaw在“理解指令、调用正确工具、返回结构化结果”这条链路上非常稳定这对于构建可靠的生产力助手至关重要。其次NemoClaw的价值在于“安全沙盒”。直接运行OpenClaw意味着它拥有和你当前用户几乎同等的权限。而NemoClaw通过OpenShell在主机上创建了一个轻量级的Kubernetesk3s环境并将OpenClaw运行在一个隔离的Pod中。这个Pod的网络出口、文件系统挂载、甚至对GPU的访问都是通过网关Gateway进行策略控制的。你可以想象成给OpenClaw套上了一个“紧身衣”它只能通过你预先批准的“管道”与外界通信。那么为什么是DGX Spark对于Nemotron 3 Super 120B这样的模型其NVFP4量化格式的权重约为67GB运行时GPU内存占用量在90GB左右。这恰好卡在DGX Spark 128GB统一内存的“舒适区”内。更大的模型如253B放不下更小的模型如30B虽然更快但能力有折损。120B参数、12B激活参数的MoE架构在能力、速度和硬件兼容性上取得了最佳平衡让单台DGX Spark就能流畅运行一个顶尖的“通用智能体”。2.2 DGX Spark的硬件特性与准备工作DGX Spark是一台非常独特的设备。它运行基于Ubuntu 24.04的DGX OS但采用的是ARM64aarch64架构。这一点至关重要因为后续所有软件包括Docker镜像都必须兼容ARM64。其128GB的HBM3e统一内存意味着CPU和GPU共享这片内存池没有传统意义上的“显存”概念这简化了内存管理但也对应用的内存使用提出了更高要求因为系统和其他进程也要占用这部分内存。在开始之前请确保你的设备满足以下条件系统更新执行sudo apt update sudo apt upgrade -y确保系统是最新状态。Docker权限你的用户需要加入docker组。通常安装脚本会处理但最好确认sudo usermod -aG docker $USER然后重新登录终端或执行newgrp docker使组生效。存储空间检查NVMe SSD的可用空间模型权重和Docker镜像会占用大量空间。df -h /确保有超过150GB的可用空间。注意DGX Spark的“怪癖”。Ubuntu 24.04默认使用cgroup v2而NemoClaw依赖的k3s在特定配置下需要cgroup v1风格的路径。直接安装可能会导致k3s启动失败。这就是项目文档中nemoclaw setup-spark命令要解决的核心问题之一。它会自动修改Docker的配置使用cgroupnshost模式来兼容。3. 快速启动使用NVIDIA云推理5分钟体验对于只是想快速验证环境、不想在本地下载近百GB模型文件的用户NVIDIA的云推理服务是最佳起点。它让你在几分钟内就能和一个运行在云端的强大模型对话感受智能体的能力。3.1 安装与基础配置第一步是安装NemoClaw命令行工具。官方提供了一键安装脚本它会自动检测并安装所需的Node.js、OpenShell CLI等依赖。curl -fsSL https://nvidia.com/nemoclaw.sh | bash安装完成后针对DGX Spark的关键一步是运行兼容性修复脚本。这个脚本不是每次安装都必须但针对Spark它能解决后续可能遇到的cgroup和权限问题。sudo nemoclaw setup-spark这个命令做了几件事1) 修改/etc/docker/daemon.json确保cgroup命名空间配置正确2) 将当前用户加入docker组3) 可能还会调整一些内核参数。执行后建议重启Docker服务并重新登录终端。3.2 接入NVIDIA云服务接下来运行引导配置命令。这会启动一个交互式向导。nemoclaw onboard向导会提示你选择推理端点这里选择NVIDIA Build (build.nvidia.com)。这是NVIDIA官方的模型API服务。输入API密钥你需要前往 build.nvidia.com 注册并获取一个API Key。将其粘贴至此。选择模型从列表中选择Nemotron 3 Super 120B。云服务会为你提供该模型的推理能力。配置完成后NemoClaw会在本地启动OpenShell网关和沙盒环境但模型的推理请求会被转发到NVIDIA的云端服务器。3.3 连接与测试智能体配置完成后连接到你创建的智能体沙盒默认名称为my-assistantnemoclaw my-assistant connect成功连接后你的终端提示符会变成sandboxmy-assistant:~$表示你已进入隔离的沙盒环境。在这个环境里你可以启动OpenClaw的文本用户界面进行交互openclaw tui或者通过命令行快速测试openclaw agent --agent main --local -m Hello, who are you and what can you do? --session-id test如果一切顺利你会收到来自Nemotron 3 Super 120B的回复。此时你已经拥有了一个功能完整、且被安全沙盒保护的AI智能体只不过它的“大脑”在云端。实操心得云推理模式非常适合初次接触和功能验证零本地负载响应速度取决于你的网络到NVIDIA服务器的延迟。但缺点也很明显持续使用会产生API费用对话内容会经过第三方服务器且完全依赖网络。对于追求隐私、零成本和稳定离线的场景我们需要将“大脑”搬回本地。4. 本地推理部署基于Ollama的方案将模型部署在本地DGX Spark上可以彻底消除网络依赖和隐私顾虑实现完全离线的智能体。Ollama是目前最流行的本地大模型运行框架之一以其易用性和丰富的模型库著称。4.1 安装Ollama与拉取模型在DGX Spark主机上注意不是在NemoClaw沙盒内安装Ollama。curl -fsSL https://ollama.com/install.sh | sh安装完成后拉取我们需要的Nemotron 3 Super 120B模型。这是一个非常大的文件约87GB下载时间取决于你的网络。ollama pull nemotron-3-super:120b注意Ollama的模型库中的nemotron-3-super:120b对应的是NVIDIA官方发布的GGUF或类似格式的量化版本。其120B总参数、12B激活参数的MoE架构能在保证较强推理能力的同时通过量化技术将其控制在单张DGX Spark显卡的可运行范围内。下载完成后验证模型是否就绪curl http://localhost:11434/api/tags你应该能看到返回的JSON数据中包含name: nemotron-3-super:120b。4.2 配置NemoClaw使用本地Ollama这里是关键步骤。我们需要让沙盒内的OpenClaw能够访问到主机上运行的Ollama服务。由于沙盒的网络是隔离的不能直接访问主机的localhost:11434。NemoClaw通过OpenShell网关提供了一个内部域名host.openshell.internal来指向主机。首先需要让Ollama监听在所有网络接口上而不仅仅是本地回环以便网关能够访问。sudo bash -c mkdir -p /etc/systemd/system/ollama.service.d \ echo -e [Service]\nEnvironment\OLLAMA_HOST0.0.0.0\ /etc/systemd/system/ollama.service.d/override.conf \ systemctl daemon-reload systemctl restart ollama重启后确认Ollama在监听0.0.0.0:11434sudo ss -tlnp | grep 11434。接下来重新运行NemoClaw的引导配置但这次指定本地端点。注意本地端点功能在文档撰写时仍标记为实验性需要设置环境变量。NEMOCLAW_EXPERIMENTAL1 nemoclaw onboard \ --endpoint ollama \ --model nemotron-3-super:120b这个命令会重新配置网关将推理请求路由到http://host.openshell.internal:11434/v1。配置完成后再次连接沙盒并测试你会发现响应来自本地GPU可以通过nvidia-smi观察到GPU利用率的波动。4.3 本地推理的优缺点与配置细节优点完全离线无网络请求数据不出本地。零持续成本一次性下载模型后无API调用费用。可控性高可以随时中断、重启调整Ollama参数。缺点与注意事项启动延迟首次启动或长时间未调用后Ollama加载模型需要时间可能导致第一次请求较慢。资源独占模型权重加载后会长期占用近90GB的GPU内存。这意味着在运行Ollama时很难再运行其他需要大量显存的应用。版本管理Ollama的模型更新可能需要重新拉取对于大模型来说耗时较长。性能调优小技巧 Ollama默认的参数可能不是最优的。你可以通过修改Ollama的启动参数来尝试提升性能例如在/etc/systemd/system/ollama.service.d/override.conf中增加GPU层数设置EnvironmentOLLAMA_NUM_GPU100这告诉Ollama尽可能多地将模型层放在GPU上。对于DGX Spark的统一内存架构通常设置为100全部即可。修改后记得sudo systemctl restart ollama。5. 高性能推理引擎Atlas深度配置与调优如果你对推理速度有极致要求那么Atlas引擎值得一试。Atlas是一个用Rust编写的高性能推理服务器针对NVIDIA最新GPU架构如Blackwell进行了内核级优化。根据社区测试在某些模型上其吞吐量能达到vLLM的3倍以上。5.1 Atlas的核心优势与前提准备Atlas并非Ollama的替代品它是一个独立的推理服务器。它的核心优势在于极致性能自定义的CUDA内核尤其擅长处理连续批处理Continuous Batching在高并发场景下优势明显。内存高效对NVFP4等量化格式支持更好内存占用通常低于同模型的其他推理框架。纯推理服务器功能专注提供标准的OpenAI兼容API易于集成。重要警告在DGX Spark上绝对不要同时运行Ollama和Atlas。两者都会试图独占大量GPU内存同时运行会导致128GB内存迅速耗尽系统完全死锁唯一的恢复方法是物理断电重启。在启动Atlas之前务必停止Ollamasudo systemctl stop ollama5.2 部署与运行Atlas服务器Atlas以Docker镜像形式分发。首先拉取镜像docker pull avarok/atlas-alpha2:latest接下来需要下载模型权重。Atlas使用Hugging Face格式的NVFP4量化权重。python3 -c from huggingface_hub import snapshot_download; snapshot_download(nvidia/NVIDIA-Nemotron-3-Super-120B-A12B-NVFP4)如果遇到缓存目录权限问题用以下命令修复docker run --rm -v $HOME/.cache/huggingface:/hf alpine chown -R $(id -u):$(id -g) /hf现在启动Atlas服务器。下面是一个针对DGX Spark优化的启动命令其中参数需要仔细理解docker run -d --name atlas \ --gpus all --ipchost --network host \ -v ~/.cache/huggingface:/root/.cache/huggingface \ avarok/atlas-alpha2:latest serve nvidia/NVIDIA-Nemotron-3-Super-120B-A12B-NVFP4 \ --port 8001 \ --kv-cache-dtype nvfp4 \ --gpu-memory-utilization 0.88 \ --scheduling-policy slai \ --max-seq-len 8192 \ --max-batch-size 16 \ --tool-call-parser hermes \ --ssm-cache-slots 8关键参数解析--gpu-memory-utilization 0.88这是最重要的参数之一。它告诉Atlas可以使用88%的可用GPU内存。对于128GB的DGX Spark这意味着约112.6GB。设置为0.88是为系统和其他进程预留了空间防止OOM。--kv-cache-dtype nvfp4指定Key-Value缓存使用NVFP4格式能显著减少自注意力机制的内存占用。--scheduling-policy slai使用Atlas特定的“SLai”调度策略针对MoE模型优化。--max-seq-len 8192最大序列长度。设置得越高KV缓存占用越大。8192是一个在能力和内存之间的平衡点。--tool-call-parser hermes指定使用Hermes格式的工具调用解析器与Nemotron模型兼容。启动后等待约90-120秒让模型加载。可以用以下命令轮询直到服务就绪while ! curl -s http://localhost:8001/health /dev/null 21; do sleep 3; done echo Atlas is ready5.3 连接NemoClaw与关键问题修复Atlas服务就绪后配置NemoClaw将其作为推理后端。由于Atlas提供OpenAI兼容的API我们使用vllm这个端点类型来连接它本质上都是兼容OpenAI API的服务器。NEMOCLAW_EXPERIMENTAL1 nemoclaw onboard \ --endpoint vllm \ --endpoint-url http://host.openshell.internal:8001/v1 \ --model nvidia/NVIDIA-Nemotron-3-Super-120B-A12B-NVFP4 \ --api-key dummy这里--api-key dummy是因为Atlas通常不需要API密钥但NemoClaw的配置流程要求此字段任意填写即可。然而这里有一个至关重要的坑点在NemoClaw沙盒内OpenClaw版本为2026.3.11如果使用Atlas并开启了模型的“推理”reasoning模式会导致模型内部思维链Chain-of-Thought的文本直接泄露到最终回复中而真正的答案却丢失了。这是因为Atlas的API响应格式与OpenClaw在此版本下的预期有细微差别。解决方案必须在沙盒内将OpenClaw的模型配置中的reasoning字段设置为false。# 1. 连接到你的沙盒 nemoclaw my-assistant connect # 2. 在沙盒内执行以下Python脚本修复配置文件 python3 -c import json, os paths_to_fix [ /sandbox/.openclaw/openclaw.json, /sandbox/.openclaw/agents/main/agent/models.json ] for path in paths_to_fix: try: with open(path, r) as f: config json.load(f) # 导航到模型配置部分 # 配置文件结构可能不同尝试几种常见路径 if models in config and providers in config[models]: providers config[models][providers] elif providers in config: providers config[providers] else: providers config # 可能直接就是provider字典 for provider_name, provider_config in providers.items(): if models in provider_config: for model in provider_config[models]: model[reasoning] False with open(path, w) as f: json.dump(config, f, indent2) print(fSuccessfully fixed: {path}) except FileNotFoundError: print(fFile not found, skipping: {path}) except Exception as e: print(fError processing {path}: {e}) 执行后退出沙盒 (exit)然后重新连接并测试应该就能得到干净、正确的回复了。重要区别如果你是在DGX Spark上直接安装OpenClaw而非通过NemoClaw沙盒并且使用的是更新的OpenClaw版本如2026.3.13那么连接到Atlas可能不需要这个修复。但对于NemoClaw沙盒内的固定版本上述修复是必须的。5.4 Atlas性能预热与监控与Ollama不同Atlas在启动后需要经过一个“预热”阶段才能达到最高性能。这是因为CUDA图CUDA Graphs需要编译。发送一些预热请求for i in {1..10}; do curl -s http://localhost:8001/v1/chat/completions \ -H Content-Type: application/json \ -d { model: nvidia/NVIDIA-Nemotron-3-Super-120B-A12B-NVFP4, messages: [{role: user, content: Say hello for warmup.}], max_tokens: 16 } /dev/null 21 echo Warmup request $i sent. sleep 1 done预热后你可以使用nvtop或nvidia-smi dmon命令来监控Atlas的GPU利用率会发现其解码阶段的利用率通常能稳定在较高水平。6. 性能基准测试与数据分析纸上得来终觉浅性能到底如何需要用数据说话。我在DGX Spark上对Ollama和Atlas两种推理后端进行了系统的基准测试测试脚本模拟了不同场景下的请求。6.1 测试方法与环境所有测试均在相同的系统环境下进行DGX SparkDGX OS (Ubuntu 24.04)Docker 29.1.3CUDA 13.0。测试时确保没有其他大型GPU进程运行。测试脚本主要测量两个核心指标TTFT (Time to First Token)从发送请求到收到第一个token的时间反映推理的“首字延迟”影响交互体验。生成速度 (Tokens/s)第一个token之后后续token的平均生成速度反映模型的“吞吐量”。测试涵盖了短响应、长文本生成、代码生成和推理任务等多种提示类型。6.2 Ollama后端性能表现使用Nemotron 3 Super 120B模型Ollama的表现如下单请求延迟与吞吐短响应 (128 tokens)TTFT约为321毫秒总耗时6.7秒平均速度约19 tokens/s注意此速度包含了TTFT实际解码速度更高。中长响应 (1024 tokens)TTFT约为392毫秒总耗时51.6秒整体平均速度约19.8 tokens/s。实际解码阶段的稳态速度约为20-21 tokens/s。长文本生成 (4096 tokens)TTFT约为400毫秒总耗时206.2秒整体平均速度约19.9 tokens/s。可以看出对于长文本Ollama能保持稳定的解码速度。代码生成任务由于代码通常结构化和可预测速度略有提升整体可达约20.3 tokens/s。并发请求测试 (RAG场景模拟) 模拟多个用户同时进行检索增强生成RAG式的短对话结果如下表所示并发用户数单用户平均速度 (tok/s)系统总吞吐 (tok/s)平均请求延迟121.121.16.1s512.519.816.3s105.222.138.7s202.818.571.4s分析Ollama在低并发下能为单个用户提供不错的响应速度。随着并发增加由于DGX Spark的算力限制每个用户的体验会显著下降延迟增加个人吞吐降低但系统总吞吐量在10个并发用户时达到峰值约22 tok/s之后因调度开销和内存带宽限制开始下降。这表明DGX Spark运行120B模型更适合中低并发场景。GPU内存占用Ollama加载Nemotron 3 Super 120B后稳定状态GPU内存占用约为89-92 GB占用了128GB统一内存的约70%。这是运行该模型的基线成本。6.3 Atlas后端性能对比由于Atlas主要优化场景是吞吐量我们对比其与Ollama在相同硬件上的表现。需要注意的是Atlas社区早期 benchmark 常使用Qwen3.5-35B-A3B这类更小的MoE模型其速度优势极其明显可达96 tok/s。但对于同样的Nemotron 3 Super 120B模型优势幅度会缩小因为计算量是主要瓶颈。实测对比 (Nemotron 3 Super 120B)Ollama稳态解码速度 ~20-21 tok/s TTFT ~400ms。Atlas稳态解码速度 ~25-28 tok/s TTFT ~350ms。Atlas带来了约30-40%的吞吐量提升TTFT也有轻微改善。提升并非数量级但对于需要处理大量文本的生产流水线累积的收益可观。内存占用对比Ollama: ~90 GBAtlas: ~85 GB Atlas通过更高效的KV缓存管理NVFP4节省了约5GB内存这为系统运行其他辅助服务留出了更多空间。核心结论对于追求极致单请求响应速度的交互式应用Ollama和Atlas的TTFT差距不大Ollama的易用性和生态是优势。对于需要高吞吐、批处理任务的场景Atlas的并发处理能力和更高的持续解码速度优势明显是更专业的选择。模型大小是关键如果未来有更小、性能更强的MoE模型如70B级别推出Atlas的性能优势比例可能会更大。6.4 性能优化建议根据测试数据给出以下调优建议交互式应用如果主要是单人或少量用户使用Ollama是更简单可靠的选择。确保OLLAMA_NUM_GPU100已设置。API服务/批处理选择Atlas。务必进行充分的预热10-20个请求并仔细调整--gpu-memory-utilization和--max-batch-size参数。--max-batch-size设置过大会导致OOM过小则无法充分利用并发能力需要根据实际请求长度和并发数寻找平衡点。内存监控始终使用nvidia-smi或nvtop监控内存使用情况。预留至少10-15GB内存给操作系统和NemoClaw/OpenShell网关防止系统不稳定。7. 故障排查与运维经验实录在实际部署和长期使用中你肯定会遇到各种问题。下面是我踩过的一些坑和解决方案希望能帮你节省时间。7.1 容器与权限类问题问题一Docker权限错误Permission denied (os error 13)现象运行docker ps或NemoClaw命令时提示权限不足。原因当前用户不在docker用户组中。解决sudo usermod -aG docker $USER然后必须退出当前终端会话并重新登录或者执行newgrp docker。仅执行命令而不刷新组信息是无效的。问题二HuggingFace缓存权限错误现象下载模型权重时提示PermissionError: [Errno 13] Permission denied: /home/user/.cache/huggingface/...。原因之前可能用sudo或Docker容器以root身份访问过该目录导致缓存目录属主变为root。解决最彻底的方法是更改目录所有权sudo chown -R $USER:$USER ~/.cache/huggingface。或者使用项目文档中的Docker命令进行修复。7.2 网络与服务连通性问题问题三OpenShell网关无法连接到Ollama现象NemoClaw配置Ollama后沙盒内测试返回连接错误。排查在主机上运行curl http://localhost:11434/api/tags确认Ollama服务本身正常。在主机上运行curl http://主机IP:11434/api/tags确认Ollama监听在0.0.0.0。在沙盒内通过nemoclaw connect尝试curl http://host.openshell.internal:11434/api/tags。如果失败说明网关DNS或路由有问题。解决确保已按前文所述配置Ollama监听0.0.0.0并重启。检查OpenShell网关状态openshell gateway status。如果异常尝试重启openshell gateway restart。有时需要手动更新网关内的提供商配置指定主机IPHOST_IP$(hostname -I | awk {print $1}) openshell provider update ollama-local --config OPENAI_BASE_URLhttp://${HOST_IP}:11434/v1问题四CoreDNS在k3s内崩溃循环 (CrashLoopBackOff)现象openshell gateway status显示k3s的CoreDNS Pod不断重启。原因k3s容器内的DNS配置指向了Docker的内部DNS (127.0.0.11)但在该网络命名空间下无法解析。解决NemoClaw提供了一个修复脚本。最直接的方法是销毁并重建网关这会重置所有配置openshell gateway destroy openshell gateway start重建后需要重新运行nemoclaw onboard进行配置。7.3 内存与资源管理问题问题五系统卡死需强制重启现象同时运行Ollama和Atlas或运行一个引擎时启动另一个内存密集型应用导致系统完全无响应。原因DGX Spark的128GB统一内存被耗尽操作系统无法回收内存导致死锁。预防与解决绝对禁止同时运行Ollama和Atlas。切换时务必先停止一个sudo systemctl stop ollama或docker stop atlas。为Atlas设置合理的--gpu-memory-utilization如0.85-0.88不要贪心设置为1.0。如果已经卡死长按电源键强制关机等待30秒后再开机。这是最后的手段。问题六Atlas启动失败提示CUDA OOM现象运行Atlas的Docker命令后容器很快退出日志显示CUDA out of memory。解决降低--gpu-memory-utilization参数值例如从0.9降至0.85。同时检查是否有其他进程占用了大量GPU内存。7.4 数据持久化与升级问题问题七沙盒重建后OpenClaw的记忆和配置丢失现象重新运行nemoclaw onboard或升级后发现之前设置的智能体人格 (soul.md)、对话历史、记忆文件 (memory.md) 全没了。原因沙盒文件系统是临时的。销毁重建后/sandbox目录下的所有内容都会丢失。解决方案定期备份备份在计划销毁或升级前连接到沙盒并打包关键数据。nemoclaw my-assistant connect tar czf /tmp/openclaw-backup-$(date %Y%m%d).tar.gz -C /sandbox .openclaw/ exit # 从主机将备份文件复制出来 openshell sandbox exec my-assistant -- cat /tmp/openclaw-backup-*.tar.gz ~/backup.tar.gz恢复创建新沙盒并配置好后连接进去恢复数据。# 将备份文件传回新沙盒 openshell sandbox exec my-assistant -- bash -c cat /tmp/restore.tar.gz ~/backup.tar.gz nemoclaw my-assistant connect tar xzf /tmp/restore.tar.gz -C /sandbox问题八无法更新沙盒内的OpenClaw版本现象想用新版本的OpenClaw功能但在沙盒内运行npm update -g openclaw失败或无网络权限。原因NemoClaw的沙盒镜像固定了OpenClaw的版本且网络策略可能禁止了非必要的出站连接以确保安全。解决等待NemoClaw项目更新其基础Docker镜像。如果你急需新版本可以考虑直接在主机上安装OpenClaw牺牲沙盒安全性但这超出了NemoClaw的范畴。8. 总结与后续探索方向经过从云到本地从Ollama到Atlas的一整套部署和测试我们可以看到在单台DGX Spark上运行一个安全、强大且高效的百亿参数AI智能体是完全可行的。NemoClaw提供的沙盒化方案为OpenClaw这类高权限需求的智能体框架提供了一个理想的安全运行环境尤其适合在开发环境或受控生产环境中使用。模型选择上的权衡Nemotron 3 Super 120B在能力上是一个“重量级选手”但其对内存的极高需求~90GB也意味着在128GB的DGX Spark上几乎没有给其他应用留出空间。如果你的应用对延迟更敏感或者需要更高的并发或许值得关注更小的MoE模型例如Nemotron 3 Nano 30B仅需~17GB NVFP4权重或者社区中其他针对推理优化的70B级别模型。在Atlas引擎上这些更小的模型有望实现百token每秒的生成速度体验将更加流畅。安全与便利的平衡NemoClaw沙盒极大地增强了安全性但也带来了复杂性比如网络配置、数据持久化和版本管理。对于纯粹的研究或个人使用如果对安全要求不是极端严格直接在主机上安装OpenClaw并连接本地Ollama/Atlas可能是更简单、更灵活的选择你可以自由升级框架、安装额外的Node.js包。但对于需要执行不可信代码或访问敏感数据的场景NemoClaw的隔离特性是不可替代的。性能调优无止境本次测试主要使用了默认或推荐参数。实际上无论是Ollama的num_ctx、num_gpu还是Atlas的--max-batch-size、--scheduling-policy都有大量的调优空间。不同的提示长度、并发模式、是否启用流式输出都会影响最终性能。建议你根据自己的实际工作负载设计更贴近现实的基准测试来找到最适合你的参数组合。最后整个NVIDIA的软件栈OpenClaw, NemoClaw, OpenShell以及Atlas这样的高性能推理引擎都处于快速迭代中。今天遇到的某些问题或限制可能在下个版本就会得到改善。保持关注项目的GitHub仓库和社区讨论是跟上节奏的最好方式。希望这份详尽的记录能帮你少走弯路更快地在你的DGX Spark上释放出大模型智能体的全部潜力。