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实际激活的参数。后者决定了推理时的计算量前者决定了模型在内存里占多大地方。MoEMixture 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文件下载到本地然后写一个极简的ModelfileFROM /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] EnvironmentOLLAMA_NUM_PARALLEL4 EnvironmentOLLAMA_MAX_LOADED_MODELS1 EnvironmentOLLAMA_KEEP_ALIVE30m 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_CUDAON -DCMAKE_BUILD_TYPERelease 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 2048prefill阶段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仓库却在启动时用了bfloat16vLLM可能会尝试把权重转回去浪费加载时间显存占用也会涨到70GB以上。vLLM的启动时间比Ollama和llama.cpp慢不少我第一次启动时大概花了30秒因为它在加载模型的同时还要编译一些CUDA kernel。但启动完成后的优势是并发能力更强、PagedAttention对长上下文更友好、API接口完全兼容OpenAI格式适合接入Dify、FastGPT这类应用。4.4 三种方案如何选我把差异整理成了一张表方便按实际需求对照维度Ollamallama.cppvLLM部署复杂度极低一条命令中等需编译较高需要环境匹配首次加载时间约5秒约7秒约30秒单用户decode速度30~45 tok/s35~51 tok/s32~47 tok/s长上下文支持一般好最好并发能力中等中等强API兼容性OpenAIOpenAIOpenAI调试自由度低高中我的建议是纯个人用选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-utilization0.8总占用也就45GB左右还有大量余量。5.2 上下文长度对速度和内存的影响把上下文长度从8K调到128K速度和占用变化很明显上下文长度KV cache预估占用decode速度短输入长输入下decode速度8K约0.8GB47 tok/s45 tok/s32K约3.1GB44 tok/s38 tok/s128K约12.5GB41 tok/s29 tok/s这里有个重要结论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上的实测整理了一个非严格控制的对比硬件显存/内存能否完整跑FP8单用户decode速度备注RTX 409024GB否50~70需Q4_K_M量化精度损失明显RTX 509032GB勉强需offload55~75混合量化显存还是紧张M4 Max128GB统一内存能40~60生态不如CUDADGX Spark128GB统一内存能44~51CUDA生态完整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_MODELS1和OLLAMA_NUM_PARALLEL2重启之后就没再闪退过。如果你是自定义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-size500M sudo journalctl --vacuum-time7d还建议在/etc/systemd/journald.conf里设置SystemMaxUse1G这样日志不会无限膨胀。别小看这一步很多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这套组合是我目前用过的最舒服的方案。我踩过的坑基本都写在上面了照着操作你应该比我少花一半时间。
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实际激活的参数。后者决定了推理时的计算量前者决定了模型在内存里占多大地方。MoEMixture 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文件下载到本地然后写一个极简的ModelfileFROM /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] EnvironmentOLLAMA_NUM_PARALLEL4 EnvironmentOLLAMA_MAX_LOADED_MODELS1 EnvironmentOLLAMA_KEEP_ALIVE30m 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_CUDAON -DCMAKE_BUILD_TYPERelease 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 2048prefill阶段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仓库却在启动时用了bfloat16vLLM可能会尝试把权重转回去浪费加载时间显存占用也会涨到70GB以上。vLLM的启动时间比Ollama和llama.cpp慢不少我第一次启动时大概花了30秒因为它在加载模型的同时还要编译一些CUDA kernel。但启动完成后的优势是并发能力更强、PagedAttention对长上下文更友好、API接口完全兼容OpenAI格式适合接入Dify、FastGPT这类应用。4.4 三种方案如何选我把差异整理成了一张表方便按实际需求对照维度Ollamallama.cppvLLM部署复杂度极低一条命令中等需编译较高需要环境匹配首次加载时间约5秒约7秒约30秒单用户decode速度30~45 tok/s35~51 tok/s32~47 tok/s长上下文支持一般好最好并发能力中等中等强API兼容性OpenAIOpenAIOpenAI调试自由度低高中我的建议是纯个人用选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-utilization0.8总占用也就45GB左右还有大量余量。5.2 上下文长度对速度和内存的影响把上下文长度从8K调到128K速度和占用变化很明显上下文长度KV cache预估占用decode速度短输入长输入下decode速度8K约0.8GB47 tok/s45 tok/s32K约3.1GB44 tok/s38 tok/s128K约12.5GB41 tok/s29 tok/s这里有个重要结论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上的实测整理了一个非严格控制的对比硬件显存/内存能否完整跑FP8单用户decode速度备注RTX 409024GB否50~70需Q4_K_M量化精度损失明显RTX 509032GB勉强需offload55~75混合量化显存还是紧张M4 Max128GB统一内存能40~60生态不如CUDADGX Spark128GB统一内存能44~51CUDA生态完整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_MODELS1和OLLAMA_NUM_PARALLEL2重启之后就没再闪退过。如果你是自定义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-size500M sudo journalctl --vacuum-time7d还建议在/etc/systemd/journald.conf里设置SystemMaxUse1G这样日志不会无限膨胀。别小看这一步很多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这套组合是我目前用过的最舒服的方案。我踩过的坑基本都写在上面了照着操作你应该比我少花一半时间。