1. 项目缘起与整体思路拆解1.1 为什么盯上了 DGX Spark GB10 这套平台第一次拿到 DGX Spark GB10 的时候我其实没抱太大期望。这台机器的定位很微妙——它不像传统数据中心里的 A100/H100 那样堆显存堆算力也不像消费级 4090 那样只图性价比。GB10 这颗芯片走的是另一条路统一内存架构加上相对克制的功耗让它特别适合放在桌边或者小机房里做推理服务。我手头这台配了 128GB 统一内存实际可用给 GPU 的差不多在 110GB 上下这个数字很关键后面选模型、算 TP 都绕不开它。我最初的需求很朴素把 Qwen3.8-27B 跑起来做本地知识库问答和代码辅助。单机跑通之后发现效果不错但上下文一拉长、并发一上来吞吐就有点顶不住。正好那阵子 DeepSeek-V4-Flash 的权重放出来了这是个 MoE 架构的模型激活参数少但总参数量大单机塞不下于是就有了双机 TP2 的想法。整个项目从单机优化一路走到双机部署中间踩的坑比我预想的多得多这篇就把完整过程摊开讲。1.2 单机与双机两条路线的取舍逻辑先说清楚为什么不是直接上双机。单机部署的优势是简单、稳定、没有机间通信开销调试起来也快。Qwen3.8-27B 用 Q8_0 量化之后权重大概在 28GB 左右加上 KV Cache 和运行时开销128GB 内存绰绰有余甚至能留出很大空间给长上下文。这种情况下硬上双机纯属自找麻烦。但 DeepSeek-V4-Flash 不一样。它的总参数量摆在那即便用 FP8 或者 Q8 量化单机 110GB 可用显存也吃不下完整权重更别说还要留 KV Cache。这时候只有两条路要么上更激进的量化把精度压到 Q4 甚至更低要么走张量并行把模型切开分到两台机器上。我选了后者原因是 Q4 量化对 MoE 模型的专家路由影响比较大实测下来回答质量掉得明显而 TP2 虽然引入通信开销但精度保持得好长期看更划算。提示TP 的切分维度是张量维度不是按层切。这意味着每一层都要做机间通信对互联带宽非常敏感。如果两台机器之间只有千兆网那基本别想跑 TP2延迟会把吞吐拖垮。1.3 整体架构与技术选型一览最终落地的方案是这样的两台 DGX Spark GB10 通过高速互联直连跑 vLLM 作为推理引擎Qwen3.8-27B 在单机上用 Q8_0 量化跑DeepSeek-V4-Flash 用 TP2 跨机部署。推理服务统一走 OpenAI 兼容接口方便上层应用切换。选 vLLM 而不是其他引擎主要看中三点一是它对 TP 的支持成熟二是 PagedAttention 对 KV Cache 的管理效率高三是社区活跃、踩坑资料多。量化方面Qwen3.8-27B 用 Q8_0 是因为它在精度和体积之间平衡得最好28GB 的体量对单机来说毫无压力。DeepSeek-V4-Flash 则用 FP8因为它的权重本身就是按 FP8 训练的直接加载不需要额外转换省事且精度损失最小。项目单机方案双机方案模型Qwen3.8-27BDeepSeek-V4-Flash量化Q8_0FP8并行无TP2显存占用约 28GB 权重 KV每机约 55GB 权重 KV适用场景长上下文、中等并发高并发、大模型推理2. 单机 Qwen3.8-27B 部署与优化实操2.1 环境准备与依赖安装的坑DGX Spark GB10 出厂自带的系统环境比较干净但驱动和 CUDA 版本需要确认。我拿到机器第一件事就是查驱动版本因为 vLLM 对 CUDA 版本有硬性要求。跑nvidia-smi看到驱动是 550 系列CUDA 12.4这个版本跑 vLLM 没问题但要注意 PyTorch 的版本必须匹配。安装依赖我推荐用 conda 建独立环境别直接动系统 Python。命令大概是这样conda create -n vllm python3.10 -y conda activate vllm pip install vllm0.6.3这里有个坑vLLM 0.6.3 对 transformers 的版本有要求如果 pip 自动装了最新版 transformers可能会报 tokenizer 相关的错。我的做法是手动锁版本pip install transformers4.45.2 tokenizers0.20.0注意DGX Spark GB10 是 ARM 架构不是 x86。有些 pip 包没有预编译的 ARM wheel会现场编译耗时很长甚至失败。遇到这种情况优先找官方提供的 ARM 版本或者用 conda-forge 的包。2.2 Qwen3.8-27B 权重下载与 Q8_0 量化处理权重下载这一步官方仓库提供了原始 FP16 权重大概 54GB。直接下 FP16 再自己量化当然可以但更省事的做法是找社区已经量化好的 Q8_0 版本。我用的就是社区维护的 Q8_0 量化权重下载下来大概 28GB省去了自己量化的时间和显存。下载的时候建议用huggingface-cli加--resume-download因为大文件下载中断是常事。命令huggingface-cli download repo_id --local-dir ./qwen3.8-27b-q8 --resume-download下载完检查一下文件完整性重点看.safetensors文件数量和config.json里的量化配置。Q8_0 的 config 里会有quantization_config字段确认quant_method是gptq或者对应的量化方法。量化处理这块如果你拿到的是 FP16 权重想自己转 Q8_0可以用llama.cpp的量化工具也可以用auto-gptq。但说实话自己量化对显存要求高DGX Spark GB10 的 128GB 统一内存虽然够但量化过程慢不如直接用现成的。我实测社区 Q8_0 版本和自量化版本在困惑度上差异很小没必要折腾。2.3 vLLM 启动参数调优与显存分配启动 Qwen3.8-27B 的 vLLM 服务核心参数就几个--tensor-parallel-size单机设为 1--gpu-memory-utilization控制显存占用比例--max-model-len控制最大上下文长度。我的启动命令python -m vllm.entrypoints.openai.api_server \ --model ./qwen3.8-27b-q8 \ --tensor-parallel-size 1 \ --gpu-memory-utilization 0.85 \ --max-model-len 32768 \ --dtype auto \ --port 8000gpu-memory-utilization设 0.85 是留出余量给系统和其他进程。设太高容易 OOM设太低浪费显存。0.85 是我试了几次之后觉得比较稳的值。max-model-len设 32768 是因为再往上 KV Cache 占用会急剧增加128GB 内存虽然大但也要给并发请求留空间。这里有个经验Q8_0 量化模型的dtype要设成auto让 vLLM 自己判断。如果强制设float16可能会因为量化权重和计算精度不匹配导致输出乱码。我一开始就踩了这个坑输出全是重复字符改成auto之后正常了。2.4 单机性能实测与瓶颈定位跑起来之后我用vllm bench做了基准测试。单机 Qwen3.8-27B Q8_0 在 32K 上下文下首 token 延迟大概 1.2 秒生成速度约 45 tokens/s。这个成绩对于本地推理来说相当不错了日常问答完全够用。但并发一上来就露馅了。同时发 8 个请求生成速度掉到 12 tokens/s首 token 延迟涨到 4 秒以上。用nvidia-smi看显存占用发现 KV Cache 吃掉了将近 40GB剩下的显存不够并行处理这么多请求。这就是单机的瓶颈显存总量固定KV Cache 和并发数直接冲突。优化方向有两个一是降低max-model-len给并发腾空间二是上双机把权重和 KV 分摊开。我选了后者因为长上下文是我的核心需求不能砍。3. DeepSeek-V4-Flash 双机 TP2 部署全流程3.1 双机互联配置与通信带宽验证双机 TP2 的第一步是把两台机器连起来。DGX Spark GB10 自带高速互联接口我用的是直连方案不经过交换机减少一层延迟。配置的时候要给两块网卡配同网段 IP比如 192.168.100.1 和 192.168.100.2子网掩码 255.255.255.0。配好之后必须验证带宽。用iperf3跑一下# 机器 A 作为服务端 iperf3 -s # 机器 B 作为客户端 iperf3 -c 192.168.100.1 -t 30实测下来带宽能跑到 200Gbps 以上延迟在微秒级。这个数字很关键因为 TP2 每层都要做 all-reduce 通信带宽不够的话通信时间会超过计算时间并行反而变慢。提示验证带宽的时候一定要跑满 30 秒以上短时间测试可能受缓存影响虚高。另外要确认两台机器的 MTU 设置一致不一致会导致分片带宽直接腰斩。3.2 DeepSeek-V4-Flash 权重准备与 FP8 加载DeepSeek-V4-Flash 的权重是 FP8 格式的官方仓库直接提供。下载下来大概 110GB 左右两台机器各存一份。这里要注意TP2 的时候每台机器加载的是模型的一部分但权重文件是完整的vLLM 会根据 TP 配置自动切分。下载命令和之前类似但文件多、体积大建议用hf_transfer加速pip install hf_transfer HF_HUB_ENABLE_HF_TRANSFER1 huggingface-cli download repo_id --local-dir ./deepseek-v4-flash加载 FP8 权重的时候vLLM 需要--dtype float8或者auto。我建议用auto让引擎自己判断。如果强制指定float8但硬件不支持会直接报错。DGX Spark GB10 对 FP8 是有原生支持的所以这块没问题。3.3 TP2 启动配置与机间通信参数双机启动比单机复杂需要指定分布式相关的参数。两台机器都要跑 vLLM通过--distributed-executor-backend指定通信后端。我的启动命令机器 Arank 0python -m vllm.entrypoints.openai.api_server \ --model ./deepseek-v4-flash \ --tensor-parallel-size 2 \ --gpu-memory-utilization 0.85 \ --max-model-len 16384 \ --dtype auto \ --distributed-executor-backend ray \ --port 8000机器 Brank 1需要设置环境变量指向 rank 0export VLLM_HOST_IP192.168.100.2 export RAY_ADDRESS192.168.100.1:6379这里的关键是 Ray 集群要先起来。在机器 A 上跑ray start --head机器 B 上跑ray start --address192.168.100.1:6379。Ray 起来之后 vLLM 才能通过它做分布式调度。注意TP2 的时候max-model-len不能设太大因为 KV Cache 是每台机器各存一半但总显存还是有限的。16384 是我实测比较稳的值再往上 KV Cache 会挤占权重空间导致 OOM。3.4 双机性能对比与扩展性分析双机跑起来之后我用同样的基准测试对比了一下。DeepSeek-V4-Flash TP2 在 16K 上下文下首 token 延迟约 2.5 秒生成速度约 30 tokens/s。单看生成速度比单机 Qwen3.8-27B 慢但这是两个不同量级的模型不能直接比。关键是并发能力。双机同时发 16 个请求生成速度还能维持在 20 tokens/s 以上首 token 延迟 5 秒左右。这个扩展性比单机好太多因为权重和 KV Cache 分摊到两台机器上每台的显存压力小了一半。指标单机 Qwen3.8-27B双机 DeepSeek-V4-Flash首 token 延迟1.2s2.5s生成速度45 tokens/s30 tokens/s8 并发生成速度12 tokens/s25 tokens/s16 并发生成速度不支持20 tokens/s最大上下文32K16K从数据看双机方案牺牲了单请求速度换来了并发能力和模型规模。如果你的场景是高并发、对单请求延迟不敏感双机 TP2 是值得的。如果只是个人用、追求低延迟单机 Qwen3.8-27B 更合适。4. 性能调优与常见问题排查实录4.1 显存溢出与 KV Cache 管理技巧显存溢出是跑大模型最常见的问题。DGX Spark GB10 的统一内存架构有个特点GPU 和 CPU 共享内存池但 vLLM 默认只认 GPU 可用部分。如果gpu-memory-utilization设太高系统进程一占内存就 OOM。我的做法是留 15% 余量也就是设 0.85。另外可以开--enable-prefix-caching复用相同前缀的 KV Cache对多轮对话场景提升明显。实测下来开了 prefix caching 之后多轮对话的首 token 延迟能降 30% 左右。还有个技巧是限制--max-num-seqs控制同时处理的请求数。默认值可能偏高导致 KV Cache 瞬间吃满。我一般设成 8 或者 16根据实际并发调整。4.2 机间通信延迟导致的吞吐下降排查双机跑了一段时间后发现吞吐偶尔会突然掉一半。查了半天发现是机间通信的问题。用ray status看集群状态发现有一台机器的网络负载异常高。排查思路是这样的先确认物理链路没问题ethtool看网卡速率和错误计数然后看 Ray 的日志有没有重传或者超时最后用nc或者iperf3复测带宽。我那次是网卡驱动的一个参数没调好导致大包分片改了 MTU 之后恢复正常。提示TP 并行对网络抖动非常敏感。如果发现吞吐不稳定优先查网络别急着调模型参数。机间通信的稳定性比带宽绝对值更重要。4.3 模型加载失败与量化格式不匹配加载 DeepSeek-V4-Flash 的时候遇到过一次报错提示量化格式不匹配。原因是 vLLM 版本对 FP8 的支持有差异老版本可能不认某些 FP8 变体。解决办法是升级 vLLM 到最新版或者手动指定--quantization fp8。Qwen3.8-27B 的 Q8_0 也遇到过类似问题。有些社区量化版本用的量化工具和 vLLM 不兼容加载的时候会报unknown quantization method。这时候要么换一个量化版本要么用 vLLM 支持的量化格式重新量化。问题现象可能原因解决方法加载报量化格式错误量化工具与 vLLM 不兼容换量化版本或重新量化输出乱码重复dtype 设置错误改为 auto吞吐突然下降机间通信抖动查网络、调 MTUOOM显存分配过高降 gpu-memory-utilization首 token 延迟高KV Cache 不足开 prefix caching4.4 长上下文场景下的稳定性保障长上下文是这套配置的核心场景但也是最容易出问题的。32K 上下文下KV Cache 占用会非常大如果并发数没控制好很容易 OOM。我的经验是长上下文场景下max-model-len和max-num-seqs要联动调整。比如 32K 上下文并发数就别超过 416K 上下文并发可以放到 8。另外建议开--swap-space把部分 KV Cache 换到 CPU 内存虽然慢一点但能避免 OOM。还有个细节是--block-size参数控制 KV Cache 的块大小。默认 16 对大多数场景够用但如果上下文特别长可以调到 32 减少块管理开销。这个参数对性能影响不大但对稳定性有帮助。5. 一些实操心得与后续扩展方向整套跑下来我最大的体会是硬件选型决定了你能跑什么模型但参数调优决定了你跑得好不好。DGX Spark GB10 这套平台的上限不低但需要花时间摸清楚它的脾气。单机和双机不是替代关系而是互补关系——单机适合低延迟、长上下文的场景双机适合高并发、大模型的场景。后续我打算试试把两个模型做成路由简单请求走单机 Qwen3.8-27B复杂请求走双机 DeepSeek-V4-Flash用一层网关做分流。这样既能保证响应速度又能处理复杂任务。另外量化方面等社区出更好的 Q6 或者 Q5 版本可以再压一压显存给 KV Cache 腾更多空间。最后分享一个小技巧vLLM 的日志级别可以调到 DEBUG能看到每个请求的 KV Cache 分配和释放情况排查显存问题的时候特别有用。命令是--log-level DEBUG平时别开太吵。
