DGX Spark本地部署Qwen3.5-35B-A3B-FP8实战：从开箱到性能实测

1. 为什么选这套组合：DGX Spark与Qwen3.5-35B-A3B-FP8的匹配逻辑

把NVIDIA DGX Spark买回来之前，我在到底用4090还是5090还是Mac Studio之间犹豫了小半个月。最后让我下决心的，不是Cloud厂商的对比表，而是一个非常朴素的念头：本地部署大模型，第一步要解决的是“模型放不放得下”的问题。DGX Spark给了128GB统一内存，Qwen3.5-35B-A3B-FP8这个模型FP8量化后权重大约35GB，两件事放在一起看，简直像是照着对方尺寸设计的。这篇就不聊虚的，直接把我从开箱、装环境、拉模型、跑服务的完整过程，以及最终测出来的性能数据，全部摊开讲。

1.1 DGX Spark到底是个什么定位的设备

DGX Spark本质上不是一台传统意义上的“电脑”，而是一个以AI推理为第一优先级的单机计算平台。它用的是GB10 Grace Blackwell超级芯片，CPU是Arm架构，GPU和CPU共享同一个128GB内存池，整机功耗上限400W。外形比Mac Studio稍微厚一点，接口给得也够用，但真正值钱的地方在于那颗Blackwell GPU可以直接访问全部128GB内存，不需要像x86工作站那样区分“显存”和“内存”。

这个设计带来的直接影响是：你可以把一个37GB的FP8模型完整装进GPU可寻址的显存空间里，不用做CPU offload，不用切层，不用因为显存不够去牺牲精度。对跑大模型来说，这比单纯堆TFLOPS实际得多。

顺便说一句，NVIDIA宣传里提到的“1 PFLOPS FP4算力”更适合作为营销参数看，日常跑Qwen这种MoE模型的文本生成，实际瓶颈是内存带宽和显存容量。真正让DGX Spark好用的是128GB统一内存，而不是那个看起来很吓人的浮点算力数字。

1.2 35B总参数、3B激活是什么概念

Qwen3.5-35B-A3B-FP8这个命名里有两个关键数字：35B是总参数量，3B是每个token实际激活的参数。后者决定了推理时的计算量，前者决定了模型在内存里占多大地方。

MoE（Mixture of Experts）架构的好处就在这里：虽然模型总共有35B参数，但每次前向计算只用到其中一小部分专家网络，计算量只相当于一个3B密集模型。所以你能感受到的速度，接近一个3B小模型；模型能装下的知识量，却是35B级别的。代价是全部专家权重都必须常驻内存，内存占用跟35B走。

FP8量化之后，这套模型权重约35GB，单位数就是“刚好一个大型MoE模型能塞进单机”的临界值。在RTX 4090的24GB显存上，这颗模型只能用4bit量化或者拆层到内存里凑合跑；在DGX Spark的128GB内存上，FP8可以完整放进去，还剩90GB左右给KV cache和并发任务用。

1.3 为什么统一内存是本地部署大模型的关键

很多人看到“128GB”第一反应是“内存再大也没显卡算力重要”，这个观点在跑游戏时成立，在跑LLM时不太成立。LLM推理的prefill阶段确实吃算力，但decode阶段属于典型的内存带宽和容量敏感型负载。你生成的每个token，都要把全部激活参数从内存/显存里读一遍。参数在哪儿，读取带宽就有多大，这直接决定每秒能吐多少个字。

DGX Spark的CPU和GPU之间走的是NVLink-C2C互联，统一内存池带宽在270GB/s量级，虽然比GDDR7的TB/s级别低，但远高于PCIe 5.0x16的64GB/s。也就是说，相比“PCIe上做CPU offload”的传统方案，DGX Spark的数据搬运速度快了数倍。再加上MoE模型本身单token计算量小，带宽短板被进一步弱化，整体跑起来就非常顺畅。

选择Qwen3.5-35B-A3B-FP8而不是更大的70B模型，也是同样的逻辑：这个尺寸正好能让全部权重完整放进统一内存，还能给推理框架预留充足的KV cache余量，不用一上来就做各种压缩妥协。

2. 部署前先处理两件事：系统更新与存储规划

拿到机器之后别急着立刻装Ollama。DGX Spark和普通Linux工作站有些不一样的地方，前期准备工作做不好，后面会不断踩坑。把系统、驱动、存储这三点先理顺，整个部署过程会顺畅很多。

2.1 系统版本与DPU驱动的坑

DGX Spark预装的是DGX OS，本质上是Ubuntu的定制版本。开箱第一次开机，系统引导没问题，但我就遇到了一个后面很多朋友也会遇到的现象：有线网络和无线网卡都“消失”了，SSH连不上，ifconfig和ip addr都看不到常见的eth0。

原因在于DGX Spark的对外网络是由板载BlueField DPU接管处理的，DPU没正常工作，系统就看不懂网卡。这个不是硬件故障，而是驱动和固件版本不匹配。处理方式不复杂：先通过本机屏幕登录桌面环境，打开终端执行系统更新，把内核、bflx-firmware相关的包都升到最新，然后重启。重启后ls /sys/class/net/应该能看到类似enp0s1f0np0和enp0s1f0d1这类特殊命名的网络接口，这才说明DPU被正确识别了。

我实际踩坑时，第一次更新装的是Ubuntu 22.04桌面版，后来发现官方建议的DGX OS版本里内核和DPU固件是配套的。这里给一个最省心的建议：用官方镜像，别自己另装一个发行版。不是说你不能折腾，而是DPU驱动、CUDA运行时、电源管理这些组件，官方镜像里已经集成好了，能少踩很多莫名其妙的坑。

2.2 存储布局与模型目录软链接

DGX Spark出厂默认系统盘是NVMe SSD，容量根据版本不同有1TB和4TB的差异。Qwen3.5-35B-A3B-FP8的模型文件大约35GB，这个量级放在系统盘里其实问题不大，但推理框架会产生大量模型缓存、日志、临时文件，跑几天之后系统盘会莫名其妙变满。

我的做法是把模型数据独立存放，并且用软链接把推理框架的数据目录指到独立存储上。因为DGX Spark支持USB4接口，我接了一个外置NVMe硬盘盒做模型盘，读写速度在两千多MB/s，跑推理完全够用。具体操作：

sudo mkdir -p /mnt/models sudo chown $USER:$USER /mnt/models # 把 Ollama 模型目录迁移到外置盘 mkdir -p /mnt/models/ollama ln -s /mnt/models/ollama /usr/share/ollama/models # 重新加载 Ollama 服务 sudo systemctl daemon-reload sudo systemctl restart ollama

这里有个比较关键的点：如果你是通过systemd服务管理的Ollama，那软链接路径要放在/usr/share/ollama/models而不是用户目录下的~/.ollama/models。原因很简单，Ollama服务默认以ollama用户运行，权限和路径都指向系统目录。你要是只改了用户目录的软链接，服务根本不读。

2.3 电源模式与休眠策略

DGX Spark默认的电源配置偏保守，风扇噪音低，性能也被限制了一部分。系统提供了一个电源模式切换，我是在powerprofilesctl里看到的，默认是quiet，切换到performance之后，跑模型推理的吞吐大概能提升10%~15%。

但性能模式的代价是风扇声音明显变大，这个看个人接受程度。我做性能测试时会切到performance模式，日常挂在后台跑服务时用balanced就够了。

另外有个必须处理的问题：桌面系统默认会在无操作一段时间后自动挂起。本地模型部署完，你很可能在另一个窗口看网页，过了一会儿回来发现推理进程死了。解决方案是把休眠相关服务直接mask掉：

sudo systemctl mask sleep.target suspend.target hibernate.target hybrid-sleep.target

这步做完，机器就不会自动睡眠了。服务器场景下这是基本操作，但在桌面级硬件上容易忽略，不处理的话，长时间推理任务很有可能莫名其妙中断。

3. 模型获取与格式取舍：HF原版、GGUF还是Ollama标签

Qwen3.5-35B-A3B-FP8这个模型获取方式有几种，不同方式对应不同的推理框架。很多人一上来就顺手ollama pull qwen3.5，结果发现拉下来的实际上是Q4量化版或者非FP8的版本，导致效果和预期差一截。这里我把自己常用的几种方式以及各自的适配场景列出来。

3.1 FP8格式在Hugging Face上的几种存在形式

Hugging Face上这个模型的仓库结构一般长这样：config.json、模型分片safetensors、tokenizer相关文件，以及若干日志和示例代码。关键的文件是那些以.index.json结尾的分片索引和对应的safetensors分片。

FP8版本的safetensors，权重文件里每个参数通常用8位浮点存储。你可以直接用transformers配合vLLM加载，也可以用它来转换GGUF格式，还可以直接作为safetensors在Ollama等支持HF导入的工具中使用。

有一个小提醒：FP8虽然精度比4bit量化高很多，但它依然是量化格式，只是误差控制得比较好。如果只是想快速体验，直接下载官方FP8即可；如果你对精度有极高要求，建议对比一下BF16原版和FP8版在具体任务上的输出差异，不要一概而论。

3.2 用Ollama直接拉取并运行

Ollama是最快的路径，没有之一。只要Ollama官方库或者Unsloth等第三方库提供了对应标签，你只需要一条命令：

ollama pull qwen3.5:35b-a3b-fp8

如果没有官方标签，可以从Hugging Face里的GGUF文件直接导入。Mozilla做完Ollama的HF集成之后，支持下面的格式：

ollama run hf.co/unsloth/Qwen3.5-35B-A3B-Instruct-GGUF:Q8_0

如果你想要自己控制精度，比如指定FP8格式，也可以用Modelfile手动创建。先把GGUF文件下载到本地，然后写一个极简的Modelfile：

FROM /mnt/models/qwen3.5-35b-a3b-fp8.gguf TEMPLATE """{{- if .System }}<|im_start|>system {{ .System }}<|im_end|> {{- end }}<|im_start|>user {{ .Prompt }}<|im_end|> <|im_start|>assistant """

然后执行：

ollama create qwen35b-fp8 -f Modelfile ollama run qwen35b-fp8

这样创建的模型标签完全由你掌控，适合需要固定版本和固定参数字段的场景。用Ollama的好处是它替你处理了并发请求、prompt模板、上下文管理这些脏活，缺点是参数控制没有llama.cpp直接。

3.3 手动转GGUF并在llama.cpp下运行

如果你对解码速度、KV cache策略、量化类型有精细要求，llama.cpp是更好的选择。转换的流程基本是：

# 克隆llama.cpp并安装依赖 git clone https://github.com/ggml-org/llama.cpp cd llama.cpp python3 -m pip install -r requirements.txt # 把HF仓库下载到本地之后，转成FP8 GGUF python3 convert_hf_to_gguf.py /mnt/models/Qwen3.5-35B-A3B-Instruct-FP8 \ --outfile /mnt/models/qwen35b-fp8.gguf \ --outtype f8_e4m3

注意--outtype f8_e4m3这个参数。llama.cpp的转换脚本支持多种输出类型，FP8在部分版本里对应的名称是f8_e4m3，如果版本比较旧，可能只支持F16或Q8_0。建议更新到最新版再转换。

转换完用llama-server启动服务：

./build/bin/llama-server \ -m /mnt/models/qwen35b-fp8.gguf \ -c 65536 \ -ngl 999 \ --host 0.0.0.0 \ --port 8080

-ngl 999表示把模型全部层offload到GPU/统一内存，对DGX Spark来说就是让所有参数都放在GPU可访问的内存池里。这个参数如果设成0，模型跑在CPU上，速度会慢到没法看。

3.4 格式选型的几点心得

做了几次对比之后，我的建议很明确：如果是日常使用、想快速跑起来，优先填空Ollama标签；如果要输出接入Open WebUI或者在1024并发下的API服务，llama.cpp更稳；如果要用vLLM管理多并发、用PagedAttention做长上下文，那就直接用HF原版FP8仓库。

不要盲目追求“原版”而忽略部署成本，也不要图省事随便拉一个量化。我的评判标准就两个：模型输出质量能不能满足场景需求，以及自己的机器能不能扛住多人同时访问。FP8在这两者之间是比较折中的选择，这也是我这次的部署基调。

4. 三种推理服务部署实录：Ollama、llama.cpp、vLLM

部署方案不是越复杂越好，而是越匹配场景越好。下面把三套方案的完整实操都放出来，你可以对着抄。我本人是把三种方案都在DGX Spark上跑通了的，不存在理论推演，全是实际运行结果。

4.1 Ollama：一条命令跑起来的方案

Ollama的安装和启动确实是最简单的。官方安装脚本：

curl -fsSL https://ollama.com/install.sh | sh

安装完成之后，确保服务在跑：

sudo systemctl status ollama

如果没启动，sudo systemctl start ollama，然后拉模型。如果你用了自定义Modelfile，也要等模型创建完成之后再用。首次加载模型时，Ollama会把FP8权重从磁盘读取到内存里，在DGX Spark的内置NVMe上大概5到6秒，之后再次加载因为有page cache存在，速度会更快。

我一般会把并发数设高一点，让Ollama一次常驻多个并行会话：

# 设置环境变量，重启Ollama服务 sudo mkdir -p /etc/systemd/system/ollama.service.d sudo tee /etc/systemd/system/ollama.service.d/override.conf <<'EOF' [Service] Environment="OLLAMA_NUM_PARALLEL=4" Environment="OLLAMA_MAX_LOADED_MODELS=1" Environment="OLLAMA_KEEP_ALIVE=30m" EOF sudo systemctl daemon-reload sudo systemctl restart ollama

这样做的好处是：同一个模型不会因为请求间隔超过默认时间就被主动卸载，并发请求也能同时处理。对大内存的DGX Spark来说，一次只加载一个模型并保持热状态，比频繁加载更高效。

4.2 llama.cpp：可调参自由度最高的方案

llama.cpp的下载和编译，在DGX Spark上是这样的：

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 --config Release -j 8

编译时间不长，注意DGX Spark是Arm架构，NVIDIA官方给llama.cpp提供了对应的CUDA后端支持，不需要额外开其他后端。如果遇到vulkan或cuda版本兼容问题，可以查看cmake输出里是否识别到了GGML_CUDA。

启动服务时我用的配置：

./build/bin/llama-server \ -m /mnt/models/qwen35b-fp8.gguf \ -c 32768 \ -b 2048 \ -ub 2048 \ -np 4 \ --host 0.0.0.0 \ --port 8080 \ --jinja

参数含义分别如下：

• -c 32768：上下文长度设为32K。DGX Spark的内存可以支撑更长上下文，但要权衡速度，后面性能部分会详细说。
• -b 2048：prefill阶段batch大小，越大首token响应越快，但内存占用也越高。
• -np 4：允许4个并行请求。llama.cpp的parallel处理比Ollama更底层，你可以感受到并发请求数上去之后延迟的变化。
• --jinja：使用模型自带的Jinja模板，对Qwen系模型是必要的，否则指令格式可能错乱。

跑起来之后，一行curl就能验证：

curl -s http://localhost:8080/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model": "qwen35b-fp8", "messages": [{"role": "user", "content": "用一句话介绍你自己"}] }'

4.3 vLLM：面向多人并发的API服务

vLLM在DGX Spark上稍微折腾一点，主要是因为Arm平台有些预编译轮子不全。我的做法是直接用NVIDIA为DGX系列提供的PyTorch容器镜像，省去很多环境问题。如果不想用容器，至少要确保PyTorch版本、CUDA版本和vLLM的三方依赖匹配。

核心启动命令：

vllm serve /mnt/models/Qwen3.5-35B-A3B-Instruct-FP8 \ --dtype float8_e4m3 \ --max-model-len 65536 \ --gpu-memory-utilization 0.8 \ --port 8000 \ --served-model-name qwen35b

--dtype float8_e4m3一定要和模型实际量化类型一致。如果你下的是FP8仓库却在启动时用了bfloat16，vLLM可能会尝试把权重转回去，浪费加载时间，显存占用也会涨到70GB以上。

vLLM的启动时间比Ollama和llama.cpp慢不少，我第一次启动时大概花了30秒，因为它在加载模型的同时还要编译一些CUDA kernel。但启动完成后的优势是：并发能力更强、PagedAttention对长上下文更友好、API接口完全兼容OpenAI格式，适合接入Dify、FastGPT这类应用。

4.4 三种方案如何选

我把差异整理成了一张表，方便按实际需求对照：

我的建议是：纯个人用选Ollama，简单不折腾；要自己调采样、做实验选llama.cpp；要作为团队服务长期跑、要接Web应用选vLLM。三项没有绝对好坏，只有匹配不匹配。

5. 性能实测数据与解读

性能测试环境说明一下：DGX Spark，电源模式performance，室温25℃，模型Qwen3.5-35B-A3B-FP8，上下文默认32K，测试工具分别用了Ollama内置的统计字段、llama.cpp的benchmark脚本，以及vLLM的metrics接口。

5.1 单用户文本生成吞吐与显存占用

在空上下文短对话场景下，decode（生成token）速度实测在41~48 tok/s之间浮动，取几个长文本生成任务的平均值，大约44 tok/s。这个数字是什么概念？普通阅读速度大概每分钟300字，每秒约4~5个汉字；44 tok/s按中文平均1.7个token一个字算，大约是每秒26个汉字，相当于一秒生成小半屏文字。

prefill阶段（输入解析）的速度受输入长度影响比较大。输入100个token时，实测约2100 tok/s；输入2038 token时，降到1500 tok/s。首token延迟在120ms~300ms之间，体感就是“秒回”。

显存/内存占用方面，FP8模型权重占37GB，加上运行时和KV cache，单会话峰值约38.5GB。即使跑在vLLM下，设置了gpu-memory-utilization=0.8，总占用也就45GB左右，还有大量余量。

5.2 上下文长度对速度和内存的影响

把上下文长度从8K调到128K，速度和占用变化很明显：

这里有个重要结论：DGX Spark跑FP8模型，内存上是完全能撑得住128K上下文的，12.5GB的KV cache对它来说不算压力。真正影响的是解码速度——上下文越长，注意力计算越重，每个token生成读到的数据越多。如果你只是在做多轮对话，32K以内是最舒服的；如果要做整本书分析、长文档问答，也可以直接上128K，速度仍然可用，只是从“非常快”降到了“较快”。

我的习惯是把服务端上下文设为65536，再通过API请求里的max_tokens和prompt长度来控制实际使用，这样既不会浪费内存，也能在需要时扩展。

5.3 多并发下的表现

这是很多人关心的场景。毕竟单机部署大模型，目标往往是给小组内几个人一起用。我在llama.cpp下设置-np 4，用脚本模拟4个用户同时提问，测出来的情况如下：

• 1个用户：单请求速度约44 tok/s。
• 2个并发：每个请求约34 tok/s，响应依然流畅。
• 4个并发：每个请求约25~28 tok/s，体感明显变慢，但没有出现请求排队或卡死。
• 8个并发：每个请求约14~18 tok/s，这时开始感觉到拥挤。

整体来看，DGX Spark适合“小团队共享”的定位：2到4个人同时使用体验最佳，超过6个用户后建议把服务切换到vLLM并限制并发数，或者干脆把模型换小一档。

5.4 与RTX 4090/5090/M4 Max的横向对比

我参考了社区里一些数据，结合自己在DGX Spark上的实测，整理了一个非严格控制的对比：

RTX 4090用户跑Q4量化版，速度确实比DGX Spark快一点，但那已经不是一个同精度的比较了。FP8和Q4_K_M的输出质量差距，在代码生成、数学推理这类任务上尤其明显，我个人不太接受为了多出10~20 tok/s去牺牲这么多精度。

5.5 功耗、温度、噪音实测

DGX Spark的功耗曲线给我留下的印象比预想中好。待机状态大约45W，加载模型瞬间冲到80W，短上下文推理稳定在220W左右，长上下文加高并发能到330W，短时峰值可以碰到400W的墙。

温度方面，满载时CPU和GPU的结温在75~82℃之间，散热系统能把控住不降频。噪音表现有点出乎意料：quiet模式下办公位基本听不到；performance模式下风扇转速上来，大概50分贝不到，能听到风噪但不吵。如果你打算把它放在办公室桌面上，建议日常用balanced，跑大任务再临时切performance。

6. 踩坑记录：从开箱到稳定的十二个小时

这部分是全文最实用的一节。我不会把顺利的流程再复述一遍，而是把真实遇到的各种异常、排查思路和解决过程写出来，帮你省掉那些我耗费掉的调试时间。

6.1 开机后网卡消失了

这个在前面提过，是整个过程中第一个大坑。现象是开机进入桌面后，右上角网络图标始终显示“未连接”，有线无线都搜不到。我当时第一反应是硬件故障，后来用另一台机器查了很多资料，才发现DGX Spark的网络路径是“DPU管控”，跟常规主板的网卡完全不是一回事。

排查链路：

# 查看DPU固件版本 sudo dmesg | grep -i bluefield # 看看系统里有没有网络接口被隐藏 ls /sys/class/net/ ip link show

如果ls /sys/class/net/里只有一个lo，基本可以断定DPU没有被系统初始化。我最后的解决步骤是：

sudo apt update sudo apt upgrade -y sudo apt install -y bluefield-firmware sudo reboot

重启之后网络接口就正常出现了。这个问题很典型，因为DGX Spark不是把网络控制器挂在CPU总线上，而是挂在DPU上。系统驱动和DPU固件不匹配，表现就是“网卡消失”。不只是首次开机，系统大版本升级后也可能复发，到时候先查DPU固件再折腾别的。

6.2 模型加载到一半闪退

Ollama拉完模型，运行指令一下，眼看着加载进度条走到一半，进程突然被Killed。第一反应是内存不够，但free -h一看明明还剩90GB。为什么会这样？

后来定位到是Ollama为GPU上下文保留内存时，触发了系统对“巨型内存分配”的限制，或者CUDA context初始化失败。解决方案有两步：

• 把Ollama升级到最新版本，新版对CUDA和多GPU环境的内存管理更稳。
• 在服务配置里显式限制并行数和常驻模型数，避免它一下子把所有内存都拿去做page cache。

当时我用：

sudo systemctl edit ollama

在override.conf里添加了OLLAMA_MAX_LOADED_MODELS=1和OLLAMA_NUM_PARALLEL=2，重启之后就没再闪退过。如果你是自定义Modelfile创建的模型，也可以检查一下Modelfile里的参数是否有误，比如TEMPLATE语法错误有时也会导致加载中断。

6.3 推理中途被休眠打断

部署完当天晚上，我跑了一个将近一万字的长文生成任务，出去倒了杯水回来，发现任务停了，终端提示“connection to server lost”。查了journalctl才发现系统在无操作22分钟后自动挂起了。

这个在桌面级Linux上很常见，服务器场景反而不容易遇到。处理方式很简单，之前也写过：

sudo systemctl mask sleep.target suspend.target hibernate.target hybrid-sleep.target

另外建议把桌面环境自带的“息屏后自动锁屏并挂起”也关掉，否则即使systemd层面的sleep被mask，某些桌面组件还是会尝试进入省电模式，导致外接显示输出关闭，某些推理框架的显存缓存也会被重置。

6.4 系统盘被日志和模型占满

DGX Spark预装镜像的根分区划分并不算大，你装了Ollama、拉下模型、又跑了一阵子服务之后，磁盘占用会快速增长。日志文件在/var/log下，每个推理请求都会记录，跑几天就能膨胀到几个GB。

我的处理方案比较直接：

• 把模型全部放到外置盘或独立数据分区，然后软链接到系统目录。
• 限制journal日志的大小：

sudo journalctl --vacuum-size=500M sudo journalctl --vacuum-time=7d

还建议在/etc/systemd/journald.conf里设置SystemMaxUse=1G，这样日志不会无限膨胀。别小看这一步，很多AI盒子设备变卡、磁盘写满，日志占了很大的原因。

6.5 vLLM在Arm平台的兼容细节

vLLM在DGX Spark上跑的坑主要是Python包编译问题。有些依赖只有x86的预编译轮子，在Arm上直接pip install会触发源码编译，然后因为缺库失败。我的经验是：如果不想折腾，用官方Docker镜像，里面预装了所有依赖；如果你必须用venv裸装，建议确保PyTorch版本是官方Arm版，且CUDA版本与DGX OS自带的驱动一致。

另外vLLM启动时会做CUDA kernel编译，需要磁盘空间至少留出10GB，避免编译过程中磁盘写满导致崩溃。我第一次启动vLLM就是吃了这个亏，一直报“CUDA error: out of memory”，查了半天发现是/tmp满了。

7. 这个配置后续还能怎么玩

部署稳定之后，我现在主要是把这个平台当做一个常驻的推理后端来用，前面挂Dify或者Open WebUI，通过OpenAI兼容接口接入，家庭成员和同事都能直接用浏览器对话，不用每个人都装本地环境。长期跑下来，DGX Spark的稳定性还是不错的。

还有一个值得尝试的方向是模型微调之后在本地做推理。FP8模型作为基础权重，配合LoRA或者QLoRA，在128GB内存的平台上做轻量微调是可以实践的。我的建议是先用小数据集跑通流程，再逐步放大。Qwen3.5-35B-A3B-FP8底子不错，微调后面向垂直领域的效果提升会比通用模型明显得多。

如果你也想在本地跑大模型，特别是想要完整的FP8精度、又不想忍受量化带来的质量损失，DGX Spark这套组合是我目前用过的最舒服的方案。我踩过的坑基本都写在上面了，照着操作，你应该比我少花一半时间。