用 NVIDIA DGX Spark 部署本地大模型并做 LoRA 微调

NVIDIA DGX Spark 更像一台放在桌面上的 AI 工作站，而不是传统意义上的家用电脑。它的体积接近 Mac mini，系统是 Ubuntu Linux，硬件重点不在办公、游戏或剪视频，而在本地运行大模型、复现深度学习项目、做推理测试和轻量微调。

它的核心配置可以先放在一张表里：

和常见桌面设备相比，它的尺寸不大，但软件生态明显更偏工程化：

DGX Spark 的价值不是“把浏览器和 Office 跑得更快”，而是把一整套 AI 开发环境放到本地：模型文件、推理服务、图像生成工作流、知识库、微调框架都可以在同一台机器上跑。只要模型和依赖已经下载好，关掉网络之后，PDF、图片、文本、部分视频任务仍然可以离线处理。

flowchart LR
    A[手机 / 笔记本 / 局域网设备] -->|访问端口 8080| B[Open WebUI]
    A -->|访问端口 8188| C[ComfyUI]
    B --> D[Ollama / 本地 LLM 推理]
    C --> E[扩散模型 / LoRA / 视频生成工作流]
    D --> F[(本地模型文件)]
    E --> F
    F --> G[GB10 + 128GB 融合内存]

128GB 融合内存意味着什么

大模型能不能跑，不能只看“参数量”。真正占内存的是模型权重、KV Cache、推理框架开销、上下文长度、batch size，以及是否量化。

粗略估算时，可以先用下面的关系理解：

举几个直观例子：

所以，“支持 2000 亿参数模型”通常指量化后的推理场景，而不是用全精度训练一个 200B 模型。上下文长度一拉长，KV Cache 会快速增长；再叠加推理框架和系统占用，128GB 很快就会变得紧张。

实际使用中，小一些的模型更适合日常本地推理。例如 20B 级别模型可以达到可用状态；120B 级别模型虽然能加载，但首 token 延迟、思考时间和输出速度都会明显变慢；235B 级别、模型文件已经超过 128GB 内存边界的模型，很容易在加载或推理时被系统终止。

DGX Spark 的融合内存减少了 CPU 和 GPU 之间搬运数据的麻烦，但它的内存带宽不是高端独立显卡 GDDR 显存那种路线。对大模型来说，很多时候瓶颈不是“能不能放下”，而是“每秒能从内存里喂给计算单元多少数据”。

本地部署大语言模型：Open WebUI + Ollama

本地大语言模型最常见的组合是：

• Ollama：负责下载、管理和运行大模型；
• Open WebUI：提供类似聊天机器人的 Web 界面；
• 本地模型文件：如 gpt-oss、Qwen、Llama 等开源模型；
• 局域网访问：同一 Wi-Fi 下的电脑或手机可以通过端口访问 DGX Spark 上的服务。

典型部署流程如下：

# 安装 Ollama
curl -fsSL https://ollama.com/install.sh | sh

# 拉取模型，名称以 Ollama 模型库实际名称为准
ollama pull gpt-oss:20b
ollama pull gpt-oss:120b

# 启动一个模型
ollama run gpt-oss:20b

Open WebUI 可以用 Docker 启动：

docker run -d \
  --name open-webui \
  --restart always \
  -p 8080:8080 \
  -v open-webui:/app/backend/data \
  --add-host=host.docker.internal:host-gateway \
  -e OLLAMA_BASE_URL=http://host.docker.internal:11434 \
  ghcr.io/open-webui/open-webui:main

启动后，在浏览器访问：

http://DGX_SPARK_IP:8080

如果手机、笔记本和 DGX Spark 在同一个局域网里，也可以直接通过这个地址访问本地模型服务。这个方式适合处理私有资料：文件不需要上传到云端，模型推理发生在本地机器上。

本地推理的体验主要取决于三件事：

图像和视频生成：ComfyUI 更适合搭工作流

文本模型之外，DGX Spark 也可以跑图像生成和视频生成。开源生图工作流里，ComfyUI 是非常常见的选择。它把模型加载、提示词编码、采样器、VAE（变分自编码器）、LoRA、ControlNet 等环节拆成节点，用图形化方式连接。

安装方式大致如下：

git clone https://github.com/comfyanonymous/ComfyUI.git
cd ComfyUI

python3 -m venv .venv
source .venv/bin/activate

pip install -r requirements.txt

# 监听局域网，端口 8188
python main.py --listen 0.0.0.0 --port 8188

常见模型目录结构类似这样：

ComfyUI/
  models/
    checkpoints/       # 主模型或检查点
    diffusion_models/  # 扩散模型
    text_encoders/     # 文本编码器
    vae/               # VAE
    loras/             # LoRA 权重
    controlnet/        # ControlNet 模型
    clip/              # CLIP 相关模型

访问地址：

http://DGX_SPARK_IP:8188

图像生成比较适合本地跑，尤其是 FLUX、Qwen Image、Z-Image 等模型，生成速度和可控性都可以接受。视频生成压力会大很多，因为视频不是生成一张图，而是生成一串连续帧，还要保持时间一致性。

例如生成 10 秒、240 帧的视频，内存占用可能接近 90GB，GPU 利用率也会被拉到很高。即使 128GB 融合内存看起来很大，视频生成仍然可能把机器压到极限。

flowchart TD
    A[提示词] --> B[文本编码器]
    B --> C[扩散模型采样]
    D[LoRA / 风格权重] --> C
    E[ControlNet / 参考图 / 姿态条件] --> C
    C --> F[VAE 解码]
    F --> G[图像]
    F --> H[视频帧序列]
    H --> I[视频合成]

视频生成要重点控制这些参数：

本地视频生成更适合做实验、测试工作流和验证提示词，不适合拿来替代商业视频生成服务的即时体验。

知识图谱和本地知识库

DGX Spark 也适合做本地知识库和知识图谱。流程一般是：上传资料，解析文本，抽取实体和关系，再把结果写入图数据库或向量数据库，由大模型负责问答和增量更新。

flowchart LR
    A[PDF / 文档 / 网页 / 笔记] --> B[文本解析]
    B --> C[切分 Chunk]
    C --> D[实体抽取]
    D --> E[关系抽取]
    E --> F[(知识图谱)]
    C --> G[(向量数据库)]
    F --> H[本地问答]
    G --> H
    H --> I[LLM 生成答案]

这类应用的优势在于数据不必离开本地设备，适合处理私人笔记、内部文档、研究资料和项目代码。限制也很明显：本地模型的理解能力、抽取稳定性和推理速度，通常不如顶级商业模型；知识图谱构建还需要清洗数据、设计实体类型和关系类型，不是把文件丢进去就一定能得到高质量结构化知识。

微调不是从零训练模型

“能不能训练一个 DeepSeek R2 级别模型”这个问题，要先把预训练和微调分开。

SFT（Supervised Fine-Tuning，监督微调）是把“问题—答案”形式的数据喂给模型，让模型学会某种回答风格或任务格式。LoRA（Low-Rank Adaptation，低秩适配）进一步降低了训练成本：基础模型参数被冻结，只额外训练两个很小的低秩矩阵。

可以把 LoRA 理解成给模型外挂一个小补丁：

flowchart TD
    A[基础模型权重 W] --> B[冻结，不参与训练]
    C[训练数据] --> D[训练 LoRA 适配器]
    D --> E[低秩矩阵 A 和 B]
    B --> F[推理]
    E --> F
    F --> G[带特定能力或风格的输出]

数学上，原本要更新一个大矩阵 W，LoRA 改成只学习一个低秩增量：

W' = W + ΔW
ΔW = A × B

其中 A 和 B 的规模远小于 W。lora_rank 越大，适配器容量越强，但训练显存、训练时间和过拟合风险也会增加。常见 rank 有 8、16、32、64。rank 8 属于比较轻的改动，适合快速验证。

用 LLaMA Factory 微调 Llama 3

LLaMA Factory 是一个常用的大模型训练和微调框架，支持 Llama、Qwen、DeepSeek 等模型，也内置了多种训练配置。以 Llama 3 8B 的 LoRA 监督微调为例，可以用两个数据集快速验证效果：

安装：

git clone https://github.com/hiyouga/LLaMA-Factory.git
cd LLaMA-Factory

pip install -e ".[torch,metrics]"

一个简化版 LoRA 配置可以写成这样：

### model
model_name_or_path: meta-llama/Meta-Llama-3-8B-Instruct
trust_remote_code: true

### method
stage: sft
do_train: true
finetuning_type: lora
lora_rank: 8
lora_target: all

### dataset
dataset: identity,alpaca_en_demo
template: llama3
cutoff_len: 2048
max_samples: 1000
overwrite_cache: true
preprocessing_num_workers: 8

### output
output_dir: saves/llama3-8b/lora/identity
logging_steps: 10
save_steps: 500
plot_loss: true
overwrite_output_dir: true

### train
per_device_train_batch_size: 1
gradient_accumulation_steps: 8
learning_rate: 5.0e-5
num_train_epochs: 3.0
lr_scheduler_type: cosine
warmup_ratio: 0.1
bf16: true

启动训练：

llamafactory-cli train examples/train_lora/llama3_lora_sft.yaml

训练完成后，可以选择保留“基础模型 + LoRA 适配器”的组合，也可以把 LoRA 合并进模型权重再导出：

llamafactory-cli export examples/merge_lora/llama3_lora_sft.yaml

8B 级别模型、lora_rank: 8、batch_size: 1 的配置，对 128GB 融合内存压力不算大，训练时间可以控制在小时级。实际耗时会受数据集大小、上下文长度、是否启用 BF16、梯度累积步数和保存频率影响。

微调后的模型并不会凭空获得全新知识。它更擅长改变输出格式、回答语气、任务习惯和领域内的固定流程。如果需要让模型掌握大量新知识，通常还要结合检索增强生成 RAG（Retrieval-Augmented Generation，检索增强生成）、知识库或继续预训练。

DGX Spark 省掉了哪些环境配置麻烦

深度学习项目最容易卡住的地方，往往不是代码本身，而是环境：

flowchart TD
    A[操作系统] --> B[驱动]
    B --> C[CUDA]
    C --> D[cuDNN]
    D --> E[PyTorch]
    E --> F[Transformers / Diffusers / LLaMA Factory / ComfyUI]
    F --> G[模型文件]
    G --> H[训练或推理任务]

CUDA（Compute Unified Device Architecture，统一计算设备架构）是 NVIDIA 的 GPU 计算平台；cuDNN（CUDA Deep Neural Network library，CUDA 深度神经网络库）是面向深度学习的加速库。PyTorch、CUDA、cuDNN 之间有严格版本关系，某个项目能不能跑，经常取决于这些版本是否匹配。

DGX Spark 的优势在于 NVIDIA 提供了更完整的 AI 软件栈和玩法指南，常见 AI 负载能更快启动。对深度学习项目来说，这会明显减少环境配置时间。

但它仍然是 Linux + ARM64 设备，不是所有桌面软件都能顺利安装。例如很多 Linux 软件只提供 amd64 架构包，ARM64 版本可能不存在。Chrome 的 Linux arm64 官方包长期缺失，安装时可能直接提示架构不匹配。遇到这种问题，需要换 Chromium、Firefox、容器方案，或寻找社区构建版本。

适合和不适合的场景

DGX Spark 的定位很明确：它适合 AI 开发，不适合当万能电脑。

对独立开发者来说，DGX Spark 更适合“开发和验证”，不适合直接当线上流量服务器。线上服务通常还是会选择云 GPU、商业 API，或者端侧模型方案。单台桌面超算的并发能力有限，网络、稳定性、运维和成本都不是生产环境的最佳组合。

使用时最容易踩的坑

1. 能加载不代表体验好

120B 模型即使能加载，输出速度也可能低于阅读速度。大模型本地运行时，要同时看首 token 延迟、tokens/s、上下文长度和内存占用，而不是只看参数量。

2. 视频生成非常吃资源

图像生成相对友好，视频生成会同时消耗显存、内存和时间。分辨率、帧数、时长、采样步数稍微一加，资源占用会快速上涨。

3. LoRA 不能替代预训练

LoRA 适合让模型学会特定格式、语气和小范围任务，不适合把一个通用模型变成全新的顶级基础模型。想做行业模型，通常需要数据清洗、RAG、监督微调、评测集和安全策略一起配合。

4. ARM64 Linux 软件兼容性要提前确认

很多教程默认目标环境是 x86_64 / amd64 Linux。DGX Spark 是 ARM64，安装包、Docker 镜像、Python wheel 都可能遇到架构问题。遇到依赖错误时，要先确认是不是架构不匹配。

5. 局域网开放端口要注意权限

Open WebUI 的 8080、ComfyUI 的 8188 如果对局域网开放，最好设置账号、密码或访问控制。处理私有资料时，不要把服务端口直接暴露到公网。

最合理的定位

DGX Spark 不是一台“带 AI 功能的电脑”，而是一台桌面 AI 实验节点。它最适合做四类事情：

• 本地跑开源大语言模型，处理私有资料；
• 用 ComfyUI 搭建图像、视频生成工作流；
• 复现深度学习项目，减少环境配置时间；
• 用 LLaMA Factory 做 LoRA 微调，验证数据和模型方案。

如果目标是训练一个 DeepSeek R2 级别的基础模型，单台桌面设备远远不够；如果目标是拥有一个能放在桌上的本地 AI 开发环境，DGX Spark 的硬件和软件栈正好对应这个需求。它不是大众消费电脑，而是给研究、开发和折腾本地 AI 的人准备的算力盒子。