第一次把 DGX Spark 放到办公桌上的时候，我盯着这个比 Mac mini 大不了多少的机箱看了半天。说明书上写着 1 PFLOP（FP4）AI 算力、128GB 统一内存，NVIDIA 管它叫“个人 AI 超级计算机”。我习惯性打开终端敲下nvidia-smi，心里其实已经准备好迎接新设备第一次上电的各种幺蛾子。结果还真出状况了——终端直接报错，提示无法与 NVIDIA 驱动通信。这篇实践指南就从这里开始，我会把从开箱、激活、搭建环境、用大模型微调平台跑训练，再把模型压成边缘设备能跑的格式，最终部署到 Jetson AGX Orin 上完成推理的完整链路都过一遍。内容偏向动手实操，适合刚拿到 DGX Spark 的开发者、打算做本地大模型微调的人，以及在边缘设备上做模型落地的同学参考。
1. DGX Spark 到底强在哪：先弄清楚它是什么机器
1.1 它不是又一个“AI PC”，而是一台小 DGX
首先得纠正一个常见的理解偏差。DGX Spark 虽然外观像桌面工作站，但它骨子里是沿着专业 DGX 系列的设计思路走下来的。DGX 系列最核心的理念不是追求单卡游戏帧率，而是把大模型训练、微调、推理这些重型负载，从数据中心的机架里抽出来，做成一台可以放在桌面上的设备。
功耗和噪音是它给人印象最深的地方。整机峰值功耗按照官方设计控制在几百瓦以内，正常微调一个 7B 模型时，风扇声音比我桌面上原来那台游戏本还小。这一点对个人开发者来说极其重要——你不需要为了跑模型去改造办公室的供电，也不需要忍受机柜风扇的轰鸣。我实测下来，把它放在显示器旁边，几乎感觉不到它的存在。
DGX Spark 的定位很明确：它不是为了替代数据中心里 A100/H100 那种训练集群，而是覆盖“开发-微调-验证-交付”这个环节。尤其是模型从训练到边缘部署的中间地带，这是以前最容易断档的部分。本地跑不动、云端太贵、边缘又跑不了——DGX Spark 刚好把中间这层补齐了。
1.2 GB10 的底气：Grace CPU、Blackwell GPU 和 128GB 统一内存
DGX Spark 用的是 GB10 Grace Blackwell Superchip，核心组件可以拆成三块来看：
- Grace CPU：基于 ARM Neoverse V2 架构，这不是一颗普通的嵌入式 ARM 处理器，而是为数据中心设计的高性能 CPU。这就意味着整机是 aarch64 架构，后面所有软件环境的搭建都必须考虑这一点——你装包的时候不能随手拿 x86 的安装命令就往里套。
- Blackwell GPU：拥有第五代 Tensor Core，支持 FP4 精度。这个 FP4 支持很关键，官方标称的 1 PFLOP 算力就是基于 FP4 算出来的。实际做推理时，FP4 量化模型可以做到体积更小、吞吐更高。
- 128GB 统一内存：CPU 和 GPU 共享同一块内存空间，不需要像传统架构那样通过 PCIe 把数据搬来搬去。这个设计对大模型负载的好处，比表面看起来的“内存大”要深刻得多。
统一内存对大模型推理的影响可以从内存带宽的角度算一笔账。DGX Spark 的内存带宽官方标称约 273GB/s。推理时每生成一个 token，模型需要把全部权重从内存里过一遍。以 7B 模型用 Q4 量化为例，权重大约 4.5GB，理论上限就是 273÷4.5，大约 60 token/s 左右。这意味着哪怕不经过任何优化，这台机器跑 7B 级别的量化模型，速度也已经到了可以流畅对话的程度。
内存带宽决定 token 速度，内存容量决定能装多大的模型，GPU 算力决定训练和推理的计算密度。这三者合在一起，才让“桌面级 AI 开发”变得真实可用。
1.3 和 RTX 4090 工作站、Mac Studio、云 GPU 相比怎么选
很多人在选型时会纠结：我为什么不去租云 GPU，或者直接买一台 RTX 4090 工作站？我从实际使用的角度列一个对照：
| 维度 | DGX Spark | RTX 4090 工作站（128GB DDR5） | Mac Studio（M3 Ultra/128GB） | 云 GPU（如 A100） |
|---|---|---|---|---|
| 显存/内存 | 128GB 统一内存 | 24GB VRAM + 系统内存 | 128GB 统一内存 | 80GB HBM |
| 内存带宽 | 约 273GB/s | 靠 PCIe 搬运，实际有限 | 约 800GB/s | 约 2TB/s |
| 训练 7B 模型 | 可以 QLoRA，也可以小规模全参 | VRAM 容易爆，需 offload | 生态受限，CUDA 不可用 | 最大，但按时计费 |
| 推理 70B 量化模型 | 可以 | 很吃力 | 可以 | 可以但成本高 |
| 功耗 | 桌面级 | 较高 | 较低 | 不可比 |
| CUDA 生态 | 完整 | 完整 | 不支持 | 完整 |
RTX 4090 工作站的痛点在于 24GB VRAM 在大模型训练面前太容易触顶。哪怕用 offload 方案，CPU 和 GPU 之间的搬运带宽也远低于统一内存。Mac Studio 的硬件底子很好，但生态上吃不到 CUDA 的福利，很多训练框架、量化工具链在 macOS 上都有老狐狸级别的兼容问题。云 GPU 呢，按小时计费，交互式调试和反复迭代时成本累计很快，而且数据要上云，对很多企业来说这本身就是个门槛。
所以 DGX Spark 最合理的定位是：固定成本的本地 AI 开发基础设施。你为它付一次钱，之后所有的微调实验、模型验证、量化导出都可以无限次跑。
2. 首次开机到跑通训练环境：激活、驱动与 CUDA 的完整体检
2.1 激活设备：没有这一步系统是不完整的
现在到手一台 DGX Spark，插电开机后，第一件事不是急着装环境，而是完成设备激活。DGX Spark 的首次启动向导会引导你登录 NVIDIA 账号，把设备绑定到你的账户下。这一步操作类似于手机激活时登录厂商账号，目的是关联系统更新服务和开发者许可。
激活完成之后，系统会进入一个预装的 DGX OS 环境，底层是 Ubuntu 的定制版，但针对 DGX 硬件做了内核和驱动适配。建议立刻做一次系统更新，把内核、驱动、固件都升到较新版本。这一步千万别省。我遇到的大部分奇奇怪怪的问题，最后追根溯源都是出厂镜像版本太旧导致的。
如果你打开终端执行uname -m，看到的输出是aarch64，不要惊讶。整个环境是 ARM 架构，后面装软件时所有 x86 的预编译包都不能直接凑合。
2.2 开机第一碰壁：nvidia-smi 失联的排查链路
回到开头我遇到的现象。第一次执行：
nvidia-smi输出：
NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver. Make sure that the latest NVIDIA driver is installed and running.这是一个看起来吓人、实际上非常有规律的问题。核心含义是用户态的工具找不到内核态的驱动模块，也就是驱动压根没加载起来，而不是 GPU 坏了。我理出两条排查路径，分别记录一下。
先说最典型的情况：系统更新后内核版本变了，而 NVIDIA 的驱动模块没有跟随内核自动重建。检查方法：
lsmod | grep nvidia如果输出为空，说明 nvidia 模块确实没加载。再看日志：
dmesg | grep -i nvidia如果能看到类似module verification failed这类信息，多半是 Secure Boot 没有给驱动签名，或者 DKMS 没有为新内核编译驱动模块。处理方式是把驱动重新装一遍，让 DKMS 把模块编译进当前内核：
sudo apt update sudo apt install --reinstall nvidia-driver-535-server sudo reboot重启之后再看nvidia-smi，大概率就正常了。如果还是不行，检查 Secure Boot 状态。这个问题在 Ubuntu 类系统上非常经典：BIOS 开启了 Secure Boot，但是驱动签名没被系统信任，内核直接拒绝加载第三方模块。解决办法是进入 BIOS，要么关掉 Secure Boot，要么把驱动签名加入 MOK 列表。后者操作繁琐，我建议开发机就直接关掉，前提是你知道自己在做什么。
另外提醒一句，DGX Spark 出厂预装驱动一般没问题，但如果你升级了内核、或者手动装过其他驱动，这个模块不匹配的问题就很容易冒头。
2.3 aarch64 环境下的 Python 与深度学习环境搭建
系统驱动恢复正常后，接下来是 Python 环境。这里有个很多人第一反应会踩的坑：习惯性装 Anaconda。Anaconda 官方对 aarch64 的支持一直不能算及时，尤其在 PyTorch 等核心依赖的预编译版本上，经常出现官方源里找不到合适 wheel 的情况。我更推荐直接用 Miniforge 或者 uv 来管理 Python 环境，它们对 ARM 架构的支持更积极。
安装 Miniforge：
wget https://github.com/conda-forge/miniforge/releases/latest/download/Miniforge3-Linux-aarch64.sh bash Miniforge3-Linux-aarch64.sh创建虚拟环境时指定 Python 3.10 或 3.11 都行：
conda create -n llama python=3.11 conda activate llamaPyTorch 对于 aarch64 Linux 提供了官方的 CUDA wheel，直接装：
pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu128装完之后验证 CUDA 可用性：
python -c "import torch; print(torch.cuda.is_available()); print(torch.cuda.get_device_name(0))"如果输出True和同类设备名，环境就通了大半。这里再提一个 aarch64 特有的坑：bitsandbytes。做 QLoRA 微调时几乎离不开它，但它的 aarch64 兼容性曾经非常差。老版本在 ARM 上连 import 都会崩。后来版本（0.44 以上）才正式支持 aarch64。如果你用的大模型微调平台里自带的版本有问题，手动升级一下：
pip install -U bitsandbytes这一步可以省掉后面训练时无数个深夜的调试时间。
3. 用 Llama Factory 在 DGX Spark 上微调：从配置到出模型
3.1 为什么选 Llama Factory 而不是自己写训练脚本
在 DGX Spark 上做微调，技术方案不止一条：可以直接写 PyTorch 训练循环，也可以用 Hugging Face 的 PEFT/TRL 库，还可以上分布式框架。但对于大多数人的真实需求——把一个开源基座模型微调成自己的私有助手——Llama Factory 是性价比最高的选择。
它解决的是几个最烦琐的工程问题。第一，数据集格式统一。不管是 Alpaca 格式还是 ShareGPT 格式，都能直接转成训练需要的结构，不用自己写一堆数据清洗代码。第二，它内置了 QLoRA、LoRA、全参微调等多种训练策略，切换超参只需改配置文件。第三，训练和推理共享一套体系，微调完可以直接在同一个环境下对话测试效果，省掉了反复导出导入模型的中间步骤。
从训练策略上看，在 DGX Spark 这种 128GB 统一内存的机器上做 7B-14B 模型的微调，主流选择就是 QLoRA。它的核心思路是把基座模型以 4-bit 量化后冻结，只训练插入的一小部分低秩适配器参数。这样训练时的内存占用被大幅压缩，而微调效果接近全参微调。128GB 内存够跑很大的模型甚至可以考虑更大参数的模型，但 QLoRA 的训练速度更快、显存压力更小，迭代效率高得多。
3.2 一份能直接跑起来的 QLoRA 微调配置
下面给出一份我实测过的配置，模型用 Qwen2.5-7B-Instruct，数据集换成你自己的对话数据即可。配置文件用 YAML 编写：
model_name_or_path: Qwen/Qwen2.5-7B-Instruct template: qwen stage: sft finetuning_type: lora lora_rank: 64 lora_alpha: 128 lora_dropout: 0.05 dataset: my_alpaca_dataset cutoff_len: 2048 learning_rate: 1.0e-4 num_train_epochs: 1.0 per_device_train_batch_size: 2 gradient_accumulation_steps: 16 lr_scheduler_type: cosine warmup_ratio: 0.05 quantization_bit: 4 quantization_method: bitsandbytes output_dir: outputs/qwen25-7b-lora logging_steps: 10 save_steps: 200启动训练：
llamafactory-cli train config.yaml解释几个关键参数：
lora_rank: 64和lora_alpha: 128是一组配套值。rank 决定了低秩矩阵的维度，rank 越高适配器的表达能力越强，但同时训练参数量和内存占用也会上升。alpha 是缩放因子，一般设为 rank 的 1 到 2 倍。per_device_train_batch_size: 2配合gradient_accumulation_steps: 16，等效全局 batch size 是 32。小 batch 是为了降低单次前向/反向的内存峰值，梯度累积是为了保证训练的稳定性。QLoRA 对小 batch 没那么敏感，但这个组合是我在 7B 模型上测试过比较稳的。quantization_bit: 4用的是 bitsandbytes 的 4-bit 量化。这一步是把基座模型的权重压缩到 4bit，训练时仅更新 LoRA 参数。
训练过程中，日志会显示 loss 下降曲线。如果 loss 在一开始就出现剧烈震荡，先把学习率降到 5e-5；如果 loss 持续不降，检查数据集里是否混入了太多空文本或过长样本。
3.3 训练中的资源观察与调优心得
训练跑起来之后，我习惯开三个终端分别观察状态：
watch -n 1 nvidia-smiwatch -n 1 free -hnvidia-top -l 1在 DGX Spark 上，free -h看到的“内存”实际上就是 GPU 可用的那 128GB 统一内存。训练时如果你的 QLoRA 配置相对保守，会看到内存占用在 20-40GB 之间浮动，剩余部分还能同时跑点别的事。这和传统独立显存工作站完全不同。在 24GB VRAM 的机器上，你要为每 1GB 显存精打细算；在这台机器上，你可以大胆一点，把 batch size 调高，或者把 max_length 从 2048 放到 4096，都不会太心疼。
不过有一点要提醒：统一内存虽然大，但它的带宽是共享的。训练时大量连续读取权重，内存带宽会吃满，这时候如果你同时在跑别的吞吐密集型任务，整个系统的表现都会被拖慢。我实测过一边训练一边跑 70B 模型推理的场景——训练速度下降了接近三成。建议把训练和推理任务错开调度。
3.4 训练结束后的效果验证
微调完成后，模型和适配器权重都保存在outputs/qwen25-7b-lora下。不要急着导出，先在 Llama Factory 里直接做一轮对话验证：
llamafactory-cli chat --model_name_or_path Qwen/Qwen2.5-7B-Instruct --adapter_name_or_path outputs/qwen25-7b-lora --template qwen这时候你会得到一个命令行对话界面。重点检查三件事：模型是否学会了数据集里的特定表达方式，指令遵循是否稳定，有没有出现灾难性遗忘（也就是原来会的能力突然变差了）。如果发现遗忘严重，下一轮训练把 LoRA rank 调低，或者减少训练 epoch。
4. 训练完的模型如何瘦身和转换：从 Hugging Face 仓库到 GGUF 再到量化
4.1 训练产物为什么不能直接搬去边缘设备
很多人把微调完成的模型文件下载下来，直接丢到边缘设备上，然后发现要么跑不起来，要么慢到没法用。原因不复杂：Hugging Face 格式的模型本质上是给 PyTorch 运行时准备的，它需要完整的 Transformers 库、依赖的 tokenizer 配置、以及 float32/float16 的原始权重。边缘设备的内存通常只有几十 GB，而且不一定装得下整个 Python 生态。
另外，训练产物往往还带着优化器状态、LoRA 适配器等训练残留，这些在推理时完全不需要。所以正式部署前，必须做一轮“瘦身”：把模型转成推理友好的格式，并量化压缩。
LLM 领域最通用的部署格式就是 GGUF。它是 llama.cpp 社区推起来的格式，特点是单文件、自包含、支持多种量化，而且运行时依赖极小——在边缘设备上只需要一个可执行的推理引擎就能加载，不需要 Python。
4.2 从 Hugging Face 合并权重到 GGUF 转换
如果训练用了 LoRA,需要先把基座模型和 LoRA 适配器合并成一个完整的模型。在 Llama Factory 里直接执行合并：
llamafactory-cli export --model_name_or_path Qwen/Qwen2.5-7B-Instruct --adapter_name_or_path outputs/qwen25-7b-lora --template qwen --finetuning_type lora --export_dir models/qwen25-7b-merged --export_size 5 --export_legacy_format false合并完成后，models/qwen25-7b-merged就是一个结构和原始模型一致的 Hugging Face 格式模型。接下来用 llama.cpp 的转换脚本把它变成 FP16 的 GGUF：
git clone https://github.com/ggml-org/llama.cpp cd llama.cpp pip install -r requirements.txt python convert_hf_to_gguf.py ../models/qwen25-7b-merged --outfile ../models/qwen25-7b-fp16.gguf --outtype f16这一步把 PyTorch 权重文件打包成 GGUF 的二进制结构。--outtype f16表示全精度导出，文件大小大约 15GB。这个文件还不能直接上边缘设备，它太大了，需要量化。
4.3 量化等级怎么选：Q4_K_M、Q8_0 和其它
llama.cpp 自带量化工具：
llama-quantize ../models/qwen25-7b-fp16.gguf ../models/qwen25-7b-q4_k_m.gguf Q4_K_M量化原理可以理解为：把连续的 32-bit 浮点权重映射到一组离散的低位整数上，配合缩放因子尽量保留原始分布。不同量化格式的差异在于分组大小和算法：
| 量化格式 | 说明 | 适用场景 |
|---|---|---|
| Q2_K | 压得最狠，质量损失明显 | 极端小内存设备 |
| Q4_K_M | 平衡了体积和质量，主流选择 | Jetson 等边缘设备 |
| Q5_K_M | 略好于 Q4_K_M，体积略大 | 内存相对宽裕的边缘设备 |
| Q8_0 | 质量接近 FP16，体积翻倍 | 内存大、追求质量的场景 |
| FP16 | 无量化损失 | 服务器/大内存工作站 |
Q4_K_M 的 7B 模型文件大约 4.5GB，在 Jetson AGX Orin 这类 64GB 内存的设备上非常从容。我自己测试下来，Q4_K_M 在对话任务上的质量下降几乎察觉不到，尤其在已经针对特定领域做过微调的模型上，微调带来的领域能力不会有明显丢失。
经验之谈：量化之后，建议用一组和训练数据分布相近的文本计算一下困惑度，对比量化前后差异。llama.cpp 提供了校准工具：
llama-perplexity -m ../models/qwen25-7b-q4_k_m.gguf -f calibration.txt如果量化后困惑度相比原始模型漂移超过 5%，就换更高级别的量化格式，或者检查校准数据是不是和模型领域偏差太大。
5. 在 Jetson AGX Orin 上部署 llama.cpp：边缘推理的完整闭环
5.1 Orin 的环境准备与 llama.cpp 编译
拿到 Jetson AGX Orin 之后，先确认 JetPack 系统版本：
cat /etc/nv_tegra_releaseJetPack 5 或 6 都可以用，但推荐 JetPack 6，因为它自带的 CUDA 版本更新，对 llama.cpp 的兼容性更好。接着在 Orin 上克隆并编译 llama.cpp，这里要指定 CUDA 后端：
git clone https://github.com/ggml-org/llama.cpp cd llama.cpp cmake -B build -DGGML_CUDA=ON -DCMAKE_BUILD_TYPE=Release cmake --build build -j 8Orin 用的是 Ampere 架构 GPU，CUDA 支持完整，所以直接启用 CUDA 后端能获得最大的加速收益。有些人会尝试 OpenCL 或 CPU 后端，实测下来在 Orin 上都不如 CUDA 后端高效。
5.2 性能实测：模型能不能流畅对话
编译完成后，把 GGUF 文件拷贝到 Orin，直接跑 CLI 测试：
./build/bin/llama-cli -m /path/to/qwen25-7b-q4_k_m.gguf -p "你好，请介绍一下你自己。" -n 256说几个实测数据供参考。AGX Orin 64GB 版本的内存带宽约 204GB/s，理论 token 速度上限大概是 204÷4.5，约 45 token/s。实际跑 7B Q4 模型，-ngl 99全量加载到 GPU 后，生成速度大约在 28-35 token/s 之间。这个速度已经可以支撑非常流畅的实时对话。
如果要在自己的应用里接入，直接起服务模式：
./build/bin/llama-server -m /path/to/qwen25-7b-q4_k_m.gguf --host 0.0.0.0 --port 8080llama-server 现在提供的接口兼容 OpenAI API 风格，应用侧几乎零改造就能接入。
5.3 从 DGX Spark 到 Orin 的模型分发经验
模型从 DGX Spark 出来后，分发到 Orin 的方式取决于你的使用场景。最简单粗暴的是 U 盘拷贝或scp，但对于经常迭代模型的场景，我推荐直接在 DGX 上搭一个简单的目录同步：
rsync -avz --progress /models/qwen25-7b-q4_k_m.gguf user@<orin-ip>:/models/rsync 支持断点续传，几百 MB 到几个 GB 的文件传输中途断了也不怕。更进阶一点的方案是搞一个共享存储目录，DGX 导出完直接写进去，Orin 从共享目录加载。这个方案适合从开发到部署迭代非常频繁的团队。
边缘推理的价值不只是省电。它意味着数据不用出本地网络、推理不依赖公网连接、单设备就能独立提供 AI 服务。我实际把一个微调后的模型部署在 Orin 上跑了几个星期，7x24 小时稳定运行，功耗远比一台独立 GPU 服务器低，而且用户反馈响应速度完全没有因为边缘环境而打折扣。
6. 常见问题与排查备忘：给后来者的硬通货
6.1 nvidia-smi 无法通信的完整检查顺序
这个报错太常见了，我在不同设备上反复遇到，总结一个标准排查顺序：
| 步骤 | 操作 | 目的 |
|---|---|---|
| 1 | lsmod | grep nvidia | 确认驱动模块是否加载 |
| 2 | dmesg | grep -i nvidia | 查看内核日志中的驱动报错 |
| 3 | sudo modprobe nvidia | 手动加载驱动模块 |
| 4 | dkms status | 检查驱动模块与当前内核是否匹配 |
| 5 | 检查 BIOS 中 Secure Boot | 排除签名问题 |
| 6 | 重装驱动并 reboot | 让 DKMS 重新编译内核模块 |
大部分情况走到第 6 步就能解决。如果重装驱动后仍然报错，检查是不是内核版本和驱动版本差太远。NVIDIA 官方驱动有内核版本支持范围，太新的内核加上老驱动，编译失败是常有的事。
6.2 系统里莫名出现的 DXCache 目录是什么
很多人在 Windows 上看到C:\Users\你的用户名\AppData\Local\NVIDIA\DXCache里躺着几十 GB 的文件，以为是什么神秘缓存。这个目录是 NVIDIA 显卡驱动为 Direct3D 生成的着色器缓存，跟 AI 训练和模型部署没关系。它的作用是加速游戏和图形应用的加载速度。如果你磁盘空间紧张，可以放心清空，驱动会在下一次应用运行时重新生成。
反过来提醒一件事：如果你在 DGX 类设备上做开发，不要把精力花在清理这种 Windows 缓存上。真正占空间的往往是 Docker 镜像、conda 环境和训练中间产物，定期清理这几个更实在。
6.3 Ubuntu 22.04 手动装 NVIDIA 驱动的心得
DGX Spark 本身是定制的 DGX OS，驱动一般不会出大问题。但如果你在普通的 Ubuntu 22.04 机器上装 NVIDIA 驱动，想把这套流程平移到边缘开发环境的话，有几个经验值得记住。
第一，优先用ubuntu-drivers devices查看推荐的驱动版本，直接用自动安装一般最稳：
sudo ubuntu-drivers autoinstall sudo reboot第二，如果安装后开机黑屏，先按 Ctrl+Alt+F3 进文本终端，把驱动卸载重装。这通常意味着新驱动和内核模块之间不兼容，或者 X 服务器配置变了。
第三，不要在驱动安装的过程中同时折腾 CUDA toolkit 和 cuDNN。一次只做一件事，每一步都重启验证，出了问题才容易定位。我见过太多人一口气装完驱动、CUDA、cuDNN、PyTorch，然后报错都分不清是哪一层出的问题。
这条线走完整之后，我的体会是：所谓“从大模型训练到边缘推理的完整实践”，真正难的不是单个环节，而是每个环节之间的衔接。DGX Spark 恰好把训练端和开发端的体验做到了本地化，而 GGUF 和 llama.cpp 这条链路又把模型交付到边缘设备的门槛压到了最低。如果你正在做类似的事情，建议先把环境体检做扎实，再跑小模型全流程验证，最后才上大模型和复杂微调任务，顺序对了，后面就会顺很多。
