DGX Spark部署NemoClaw：从云端到本地Ollama与Atlas引擎实战

1. 项目概述：在DGX Spark上部署NemoClaw的完整指南

如果你手头有一台NVIDIA DGX Spark，并且想在上面跑一个既安全又强大的AI智能体，那么NemoClaw绝对是你绕不开的一个选择。NemoClaw是NVIDIA推出的一个沙盒化OpenClaw智能体框架，简单来说，它能把你的AI智能体装进一个“笼子”里运行，这个笼子会严格控制它的一举一动——每一次网络请求、文件访问，甚至是对外部的推理调用，都必须经过你事先声明的策略批准。这听起来很酷，但当你真正想在DGX Spark这台独特的ARM架构、统一内存的设备上把它跑起来时，可能会遇到一堆平台特有的“坑”。我花了几天时间，从云端推理快速上手，到本地Ollama部署，再到尝试号称性能怪兽的Atlas推理引擎，把整个过程完整走了一遍。这篇文章就是我的实战记录，包含了详细的步骤、踩过的坑，以及不同方案的性能对比数据，希望能帮你少走弯路。

2. 硬件与软件环境准备

2.1 DGX Spark硬件规格与特性

DGX Spark是一台非常特别的设备，它的配置和我们常见的x86服务器或消费级GPU有很大不同。在开始之前，你必须清楚它的“脾气”。

核心硬件规格：

• GPU: 搭载的是NVIDIA GB10（Blackwell架构），但最关键的是其128GB的统一内存。这不是传统的独立显存，而是CPU和GPU共享的HBM（高带宽内存）。这意味着模型权重、KV缓存和运行时的临时数据都共享这128GB空间，管理不当极易导致内存耗尽（OOM）和系统死锁。
• 架构: ARM64 (aarch64)。很多为x86_64预编译的软件包或Docker镜像在这里无法直接运行，必须寻找ARM版本或从源码编译。
• 存储: 3.7 TB NVMe SSD，速度足够快，不是瓶颈。
• 操作系统: 基于Ubuntu 24.04 LTS的DGX OS。

需要特别注意的“怪癖”：

1. cgroup v2问题: Ubuntu 24.04默认使用cgroup v2，但NemoClaw依赖的k3s（轻量级Kubernetes）在容器内运行时，需要兼容cgroup v1风格的路径。如果不做调整，k3s会启动失败。
2. 统一内存管理: 128GB是硬上限。同时运行Ollama和Atlas这类内存大户是绝对禁止的，会导致系统完全冻结，只能强制重启。
3. 网络隔离: 容器内的网络命名空间是隔离的。从OpenShell沙盒内部（运行在k3s Pod中）访问宿主机上运行的服务（如Ollama），不能简单地使用localhost或127.0.0.1。

2.2 软件栈与依赖安装

在开始NemoClaw之旅前，你需要确保基础软件就位。

1. Docker配置调整DGX Spark预装了Docker，但我们需要为cgroup兼容性打上补丁。最省事的方法是直接使用NemoClaw提供的工具：

# 安装NemoClaw（这会同时安装Node.js和OpenShell CLI） curl -fsSL https://nvidia.com/nemoclaw.sh | bash # 运行DGX Spark专用配置脚本 sudo nemoclaw setup-spark

这个setup-spark命令干了三件关键事：

• 修改/etc/docker/daemon.json，添加"default-cgroupns-mode": "host"，解决k3s的cgroup路径问题。
• 将当前用户加入docker组，避免后续的权限错误。
• 执行一个修复CoreDNS的脚本，解决容器内DNS解析失败的问题。

执行后，务必退出当前终端会话并重新登录（或执行newgrp docker），让用户组变更生效。

2. 验证环境重新登录后，运行以下命令确保一切正常：

# 检查Docker是否可以无sudo运行 docker ps # 检查OpenShell CLI是否安装 openshell --version

如果docker ps报权限错误，请再次确认用户组并重新登录。

3. 快速启动：使用NVIDIA云端推理

对于只是想快速体验NemoClaw，或者暂时不想在本地加载大模型的用户，使用NVIDIA的云端推理服务是最快捷的途径。整个过程5分钟内就能看到一个能对话的智能体。

3.1 获取NVIDIA API密钥

你需要一个NVIDIA开发者账号。访问 build.nvidia.com ，注册并登录后，在控制台创建一个API密钥。这个密钥将用于验证你对NVIDIA推理端点的访问权限。

3.2 初始化NemoClaw并连接云端

运行初始化向导：

nemoclaw onboard

这是一个交互式命令行向导，它会引导你完成设置：

1. 选择推理端点：从列表中选择NVIDIA Build (build.nvidia.com)。
2. 输入API密钥：粘贴你刚才在网站上创建的密钥。
3. 选择模型：从模型列表中选择Nemotron 3 Super 120B。这是目前能在单台DGX Spark上运行的、能力最强的Nemotron系列模型（1200亿总参数，120亿激活参数）。

向导完成后，NemoClaw会在后台启动一个沙盒环境，并配置好与云端服务的连接。

3.3 连接沙盒与测试

使用以下命令连接到你的智能体沙盒：

nemoclaw my-assistant connect

成功连接后，你的命令行提示符会变成sandbox@my-assistant:~$，表示你已进入隔离的沙盒环境。

在这个环境里，你可以启动OpenClaw的文本用户界面（TUI）进行交互：

openclaw tui

TUI启动后，你就可以像使用ChatGPT一样直接输入问题。或者，你也可以通过命令行快速测试：

openclaw agent --agent main --local -m "Hello, who are you?" --session-id test

如果一切顺利，你将收到来自云端Nemotron 3 Super 120B模型的回复。此时，你的智能体已经在安全沙盒中运行，并且所有推理请求都发送到了NVIDIA的云端服务器。

注意：云端推理会产生费用，具体计费方式请参考NVIDIA Build的定价页面。这种方式适合体验和轻量使用，对于长期、高频或涉及敏感数据的场景，建议转向本地推理。

4. 本地推理部署：使用Ollama

将推理从云端迁移到本地的DGX Spark GPU上，能带来零延迟、零网络依赖、完全数据隐私和零额外成本（电费除外）的巨大优势。Ollama是目前在DGX Spark上部署Nemotron模型最简便、最稳定的方案。

4.1 安装Ollama并拉取模型

Ollama提供了ARM64的安装脚本，兼容性很好。

# 安装Ollama curl -fsSL https://ollama.com/install.sh | sh # 启动Ollama服务 sudo systemctl start ollama

安装完成后，拉取Nemotron 3 Super 120B模型。这是一个约87GB的下载任务，请确保网络通畅和足够的磁盘空间。

ollama pull nemotron-3-super:120b

这个模型采用了MoE（混合专家）架构，虽然总参数量高达1200亿，但每次推理只激活约120亿参数，因此在保持强大能力的同时，获得了更快的推理速度。

4.2 配置Ollama监听地址（关键步骤）

默认情况下，Ollama服务只监听127.0.0.1（本地回环地址）。然而，NemoClaw沙盒运行在独立的容器网络命名空间中，无法直接访问宿主机的localhost。我们必须让Ollama监听所有网络接口。

# 创建systemd覆盖配置文件，设置Ollama监听所有IP sudo bash -c 'mkdir -p /etc/systemd/system/ollama.service.d && \ echo -e "[Service]\nEnvironment=\"OLLAMA_HOST=0.0.0.0\"" > /etc/systemd/system/ollama.service.d/override.conf' # 重新加载systemd配置并重启Ollama sudo systemctl daemon-reload sudo systemctl restart ollama

重启后，验证Ollama是否在正确工作：

curl http://localhost:11434/api/tags

你应该能看到返回的JSON中包含"name": "nemotron-3-super:120b"。

4.3 重新配置NemoClaw使用本地Ollama

由于本地推理端点（Ollama, vLLM）在NemoClaw当前版本中被标记为实验性功能，我们需要设置一个环境变量来启用它们。

NEMOCLAW_EXPERIMENTAL=1 nemoclaw onboard \ --endpoint ollama \ --model nemotron-3-super:120b

这个命令会重新运行配置向导，但这次它会跳过交互式问题，直接使用你指定的Ollama端点和模型。配置过程中，NemoClaw会将推理请求路由到http://host.openshell.internal:11434/v1。这个特殊的域名host.openshell.internal是由OpenShell网关解析到宿主机真实IP的，是沙盒内访问宿主服务的标准方式。

4.4 验证本地推理

再次连接沙盒并进行测试：

nemoclaw my-assistant connect sandbox@my-assistant:~$ openclaw agent --agent main --local -m "请用中文告诉我，你现在使用的是本地GPU还是云端服务？" --session-id local-test

同时，你可以打开另一个终端，在宿主机上运行nvidia-smi，在智能体生成回复时，你应该能看到GPU利用率的显著上升。这证实推理确实在你的本地GB10 GPU上进行。

5. 高性能方案：集成Atlas推理引擎

如果你对推理速度有极致要求，并且愿意尝试前沿技术，那么Atlas推理引擎值得关注。根据我的测试，在Qwen3.5-35B-A3B模型上，Atlas相比vLLM能有近3倍的吞吐量提升。下面是如何在DGX Spark上为NemoClaw配置Atlas。

5.1 Atlas简介与注意事项

Atlas是一个用Rust编写的高性能推理引擎，针对NVIDIA最新的SM12.1架构（Blackwell）进行了内核级优化。但它有几个重要的前提需要了解：

• 许可证: AGPL-3.0。对于商业用途需要仔细评估合规性。
• 成熟度: 目前是Alpha 2版本，API和功能可能发生变化。
• 闭源: 你无法查看或修改其源代码。
• 内存独占:绝对不要让Atlas和Ollama同时运行！128GB的统一内存会被瞬间榨干，导致系统死机。

在开始前，请确保Ollama已停止：

sudo systemctl stop ollama

5.2 部署Atlas推理服务

1. 拉取Docker镜像Atlas的镜像非常小巧，只有约1.9GB。

docker pull avarok/atlas-alpha2:latest

2. 下载NVFP4格式的模型权重Atlas需要使用特殊的NVFP4量化格式的模型。我们以Nemotron 3 Super 120B为例。

python3 -c "from huggingface_hub import snapshot_download; snapshot_download('nvidia/NVIDIA-Nemotron-3-Super-120B-A12B-NVFP4')"

如果遇到缓存目录权限错误（因为之前可能被root身份的Docker容器写入过），执行以下命令修复：

docker run --rm -v $HOME/.cache/huggingface:/hf alpine chown -R $(id -u):$(id -g) /hf

3. 启动Atlas服务器这是一个复杂的启动命令，每个参数都至关重要：

docker run -d --name atlas \ --gpus all --ipc=host --network host \ # 授予GPU和主机网络访问权 -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 \ # KV缓存使用NVFP4格式以节省内存 --gpu-memory-utilization 0.88 \ # GPU内存使用率上限，为系统留出空间 --scheduling-policy slai \ # 调度策略 --max-seq-len 8192 \ # 最大序列长度 --max-batch-size 16 \ # 最大批处理大小 --tool-call-parser hermes \ # 工具调用解析器 --ssm-cache-slots 8 # SSM（状态空间模型）缓存槽位

启动后需要等待1-2分钟让服务完全就绪。可以用一个循环命令来检查：

while ! curl -s http://localhost:8001/health > /dev/null 2>&1; do sleep 3; echo "等待Atlas启动..."; done echo "Atlas已就绪！" curl -s http://localhost:8001/v1/models | python3 -m json.tool

4. 预热（Warmup）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":"Warmup"}],"max_tokens":32}' > /dev/null 2>&1 echo "预热请求 $i 完成" done

5.3 配置NemoClaw并修复关键配置

配置NemoClaw使用Atlas端点。由于Atlas兼容OpenAI API，我们使用vllm作为端点类型。

NEMOCLAW_EXPERIMENTAL=1 nemoclaw onboard \ --endpoint vllm \ --endpoint-url http://host.openshell.internal:8001/v1 \ --model nvidia/NVIDIA-Nemotron-3-Super-120B-A12B-NVFP4 \ --api-key dummy # Atlas不需要真正的API密钥，但字段必须提供

一个至关重要的修复：关闭推理（Reasoning）模式当前版本的Atlas（Alpha 2）与NemoClaw沙盒内集成的OpenClaw（2026.3.11）在“推理”功能上存在兼容性问题。如果开启推理模式（模型会先进行内部思考链），Atlas返回的“思考”文本会直接混入最终答案，导致输出混乱。

必须在沙盒内修改OpenClaw的配置文件：

# 1. 连接到你的沙盒 nemoclaw my-assistant connect # 2. 在沙盒内执行以下Python脚本，修改两个关键配置文件 python3 -c " import json, os config_paths = [ '/sandbox/.openclaw/openclaw.json', '/sandbox/.openclaw/agents/main/agent/models.json' ] for path in config_paths: 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 # 可能直接就是providers字典 for provider_name, provider_config in providers.items(): if 'models' in provider_config: for model in provider_config['models']: model['reasoning'] = False # 关键：关闭推理模式 print(f'在 {path} 的 {provider_name} 中关闭了模型 {model.get(\"id\")} 的推理模式。') with open(path, 'w') as f: json.dump(config, f, indent=2) print(f'配置文件 {path} 已更新。') except FileNotFoundError: print(f'警告: 未找到文件 {path}') except Exception as e: print(f'处理 {path} 时出错: {e}') "

执行后，退出沙盒（exit）并重新连接，使配置生效。现在再测试智能体，应该能得到清晰、正确的回复了。

重要提示：此问题仅存在于通过NemoClaw沙盒运行的OpenClaw。如果你直接在宿主机上安装OpenClaw（2026.3.13或更高版本）并连接Atlas，则无需此修复，只需在模型配置中设置"reasoning": false即可。

6. 性能基准测试与对比分析

纸上得来终觉浅，性能到底如何还得靠数据说话。我设计了一系列测试，对比了Ollama和Atlas引擎在DGX Spark上运行不同模型的性能表现。所有测试均在同一台设备、相同系统负载下进行。

6.1 测试方法与环境

• 测试脚本: 使用自定义的Python基准测试脚本，模拟不同长度的提示词（Prompt）和生成长度（Completion）。
• 性能指标:
  • 吞吐量 (tok/s): 每秒生成的令牌数，越高越好。
  • 首令牌时间 (TTFT): 从发送请求到收到第一个令牌的时间，影响交互体验。
  • 内存占用: GPU统一内存的使用量。
• 测试模型:
  • Nemotron 3 Super 120B (12B Active): 通过Ollama运行。
  • Qwen3.5-35B-A3B (3B Active): 通过Atlas运行（NVFP4量化格式）。作为对比参考。

6.2 Ollama + Nemotron 3 Super 120B 性能详测

这是最常用的本地部署方案。测试结果显示，其性能表现相当稳定。

单请求延迟测试：

测试场景	生成令牌数	总耗时	估算吞吐量	首令牌时间 (TTFT)
短回复	128 tokens	6.7 秒	~19.1 tok/s	321 毫秒
中回复	1024 tokens	51.6 秒	~19.8 tok/s	392 毫秒
长回复	4096 tokens	206.2 秒	~19.9 tok/s	400 毫秒
代码生成	2048 tokens	103.2 秒	~19.8 tok/s	458 毫秒
推理任务	256 tokens	8.4 秒	~30.5 tok/s	403 毫秒

注意：表中的“估算吞吐量”基于总令牌数除以总耗时。实际解码速度非常稳定，约51.5秒完成1024个令牌的生成，即稳态解码速度约为19.8 tok/s。TTFT在400毫秒左右，对于交互式应用来说可以接受。

并发压力测试（模拟RAG场景）：此测试模拟多个用户同时进行检索增强生成（RAG）查询的场景，提示词较长，考验系统的并发处理能力。

并发用户数	单用户吞吐量	系统总吞吐量	平均请求延迟
1	2.1 tok/s	2.1 tok/s	6.7 秒
5	1.2 tok/s	6.0 tok/s	18.9 秒
10	0.4 tok/s	4.0 tok/s	39.3 秒
20	0.5 tok/s	10.0 tok/s	66.9 秒

可以看到，随着并发数增加，单个请求的延迟显著上升，吞吐量增长并非线性。在10个并发时，系统总吞吐量达到瓶颈。对于Nemotron 3 Super 120B这样的大模型，DGX Spark更适合处理中低并发的复杂任务，而非高并发的简单问答。

GPU内存占用：运行Nemotron 3 Super 120B时，Ollama进程约占89.7 GB的统一内存。这意味着128GB中约70%被模型权重和KV缓存占用，留给系统和其它进程的空间已经不多。

6.3 Atlas + Qwen3.5-35B-A3B 性能对比

为了展示Atlas的性能潜力，我将其与通用的vLLM引擎在相同的Qwen3.5-35B-A3B模型上进行了对比。结果令人印象深刻。

模型 (激活参数)	推理引擎	中位数吞吐量	首令牌时间	GPU内存占用
Qwen3.5-35B-A3B (3B)	Atlas	95.9 tok/s	~40 毫秒	10.3 GB
Qwen3.5-35B-A3B (3B)	vLLM	~31 tok/s	可变	~18 GB
Nemotron 3 Super 120B (12B)	Ollama	~19.8 tok/s	~400 毫秒	89.7 GB

关键结论：

1. 性能飞跃：Atlas在Qwen3.5-35B模型上实现了超过vLLM 3倍的吞吐量，并且TTFT极低。这得益于其针对Blackwell架构的深度优化和纯Rust实现的高效调度。
2. 内存效率：Atlas使用的NVFP4量化格式和高效的内存管理，使其内存占用仅为vLLM的57%。
3. 模型选择权衡：Nemotron 3 Super 120B虽然能力更强（激活参数是Qwen3.5-35B的4倍），但其吞吐量只有后者的约1/5，而内存占用却是近9倍。对于延迟敏感或需要一定并发能力的应用，在DGX Spark上，像Qwen3.5-35B这类更小的MoE模型搭配Atlas引擎，是比超大模型更务实、性能更优的选择。

6.4 综合选型建议

根据你的需求，可以参考以下决策路径：

• 追求极致能力，不计较速度与成本：使用NVIDIA云端Nemotron 3 Super 120B。
• 追求本地化、易用性和模型能力平衡：使用Ollama + Nemotron 3 Super 120B。这是开箱即用体验最好的方案。
• 追求本地极致推理速度与低延迟：使用Atlas + Qwen3.5-35B-A3B（或类似规模的MoE模型）。你需要接受Atlas的Alpha状态和AGPL许可证。
• 需要高并发处理简单任务：考虑在DGX Spark上部署多个更小、更快的模型实例，或者寻求集群化方案。单卡运行超大模型难以满足高并发需求。

7. 故障排除与实战经验

在部署过程中，我遇到了不少问题。这里把最常见的问题和解决方案整理出来，希望能帮你快速排雷。

7.1 系统级问题

问题：系统因内存耗尽（OOM）完全冻结

• 现象：屏幕无响应，SSH断开，只能强制按电源键重启。
• 原因：同时运行了Ollama和Atlas（或其它内存大户），128GB统一内存被瞬间占满。
• 解决：绝对不要让两个推理引擎同时运行！切换时务必先停止一个。

  # 切换到Atlas前 sudo systemctl stop ollama # 切换回Ollama前 docker stop atlas

问题：Docker权限错误

• 现象：执行docker命令时提示Permission denied (os error 13)。
• 原因：当前用户不在docker用户组中。
• 解决：确保已运行sudo nemoclaw setup-spark，并且已经重新登录终端。也可以手动处理：

  sudo usermod -aG docker $USER newgrp docker # 立即生效，或退出终端重新登录

7.2 网络与连接问题

问题：沙盒内智能体无法连接到Ollama

• 现象：在沙盒内测试时，报错failed to connect to http://host.openshell.internal:11434/v1。
• 原因1：Ollama未监听所有网络接口。已在前文通过修改systemd配置解决。
• 原因2：OpenShell网关的提供商配置未更新。即使Ollama监听0.0.0.0，网关可能仍指向旧地址。
• 解决：更新OpenShell的推理提供商配置。

  # 获取宿主机的真实IP（非127.0.0.1） HOST_IP=$(hostname -I | awk '{print $1}') # 更新名为‘ollama-local’的提供商配置（名称可能不同，可用`openshell provider list`查看） openshell provider update ollama-local --config "OPENAI_BASE_URL=http://${HOST_IP}:11434/v1" # 重新设置推理端点 openshell inference set --provider ollama-local --model nemotron-3-super:120b

问题：CoreDNS持续崩溃（CrashLoopBackOff）

• 现象：使用openshell gateway status查看时，发现CoreDNS Pod状态异常。
• 原因：k3s内部的CoreDNS试图使用Docker网桥的DNS服务器（127.0.0.11），但在容器网络命名空间内无法访问。
• 解决：NemoClaw的setup-spark脚本应该已经包含了修复。如果问题依旧，可以手动修复或重建网关：

  # 方法1：运行修复脚本（如果存在） # 方法2：销毁并重建网关（这会重启所有沙盒） openshell gateway destroy openshell gateway start

7.3 数据持久化问题

问题：沙盒重建后，OpenClaw的记忆和聊天记录丢失

• 现象：重新运行nemoclaw onboard或升级后，发现之前的对话历史、自定义的人格设定（soul.md）都没了。
• 原因：沙盒本质是一个临时容器。/sandbox目录下的所有数据在沙盒销毁时都会丢失。
• 解决：定期备份~/.openclaw/目录。这里提供一个手动备份与恢复的流程：

  # === 备份流程 === # 1. 连接到旧沙盒 nemoclaw my-old-assistant connect # 2. 在沙盒内打包数据 tar czf /tmp/openclaw-backup.tar.gz -C /sandbox .openclaw/ exit # 3. 从宿主机将打包文件拷贝出来 openshell sandbox exec my-old-assistant -- cat /tmp/openclaw-backup.tar.gz > ~/my-assistant-backup.tar.gz # === 恢复流程 (在新沙盒创建后) === # 1. 将备份文件拷贝进新沙盒 openshell sandbox exec my-new-assistant -- bash -c 'cat > /tmp/restore.tar.gz' < ~/my-assistant-backup.tar.gz # 2. 连接到新沙盒并解压 nemoclaw my-new-assistant connect tar xzf /tmp/restore.tar.gz -C /sandbox # 3. 确保文件权限正确（沙盒内用户是sandbox） chown -R sandbox:sandbox /sandbox/.openclaw

  建议：可以将此备份流程脚本化，并在执行可能销毁沙盒的操作前自动运行。

7.4 软件版本与兼容性

问题：无法在沙盒内更新OpenClaw版本

• 现象：想用npm update -g openclaw获取新功能，但安装失败或网络被禁止。
• 原因：NemoClaw沙盒的网络策略是严格控制的，禁止随意访问外网。此外，OpenClaw的版本被固定在NemoClaw项目构建时的Dockerfile中（例如openclaw@2026.3.11）。
• 解决：你无法在沙盒内直接升级。需要等待NemoClaw项目本身发布新版本，其中包含了更新后的OpenClaw。关注NVIDIA官方GitHub仓库的Release。

问题：nemoclaw onboard向导中看不到Ollama等本地选项

• 现象：运行向导时，只列出了“NVIDIA Build”和“NCP”等云端选项。
• 原因：本地推理端点功能被标记为“实验性”，默认隐藏。
• 解决：在运行命令前设置环境变量NEMOCLAW_EXPERIMENTAL=1。

  NEMOCLAW_EXPERIMENTAL=1 nemoclaw onboard

8. 维护与优化建议

经过一段时间的运行，为了保持系统稳定高效，我有以下几点经验分享：

1. 监控统一内存使用情况养成使用htop或nvidia-smi监控内存的习惯。记住一个简单的公式：已用内存 + 模型内存 < 120GB（为系统预留8GB左右）。一旦接近临界值，就要考虑停止不必要的服务或选择更轻量的模型。

2. 利用DGX OS的特性DGX OS是高度优化的系统。除非必要，不要随意升级内核或关键驱动（如CUDA），以免破坏NVIDIA提供的优化和兼容性。使用sudo dgx开头的命令进行系统管理通常更安全。

3. 探索模型量化如果Atlas的方案可行，积极关注NVFP4、FP8等更高效的量化格式。它们能大幅降低内存占用，从而可能让你在DGX Spark上运行更大的模型或实现更高的批处理大小。

4. 考虑混合推理策略对于生产环境，可以考虑“云-边”混合策略。将轻量、高频的查询交给本地模型（如用Atlas运行的35B模型），将极其复杂、低频率的任务路由到云端的大模型（如Nemotron 3 Super 120B）。OpenClaw框架本身支持多模型路由，可以基于查询复杂度、成本等因素进行智能调度。

5. 文档与备份记录下你所有的配置参数、修复的脚本和关键的性能数据。定期备份你的智能体配置、人格设定和重要的对话记录。这个系统的组件较多，一份清晰的运维文档能在出问题时帮你快速恢复。

最后，NemoClaw on DGX Spark是一个强大但略显复杂的组合。它把最前沿的AI智能体框架、高性能推理引擎和独特的硬件平台整合在一起。虽然搭建过程中会遇到不少挑战，但一旦跑通，你将获得一个完全受控、高性能、本地化的AI智能体开发与部署环境。希望这篇详尽的指南能成为你探索之路上的有效参考。