最近有不少开发者在讨论“本地私有化跑大模型”这件事，而一旦提到 DGX Spark，评论区总会冒出一句“满屏都是金币的味道”。这既是玩笑，也是事实：当两台 DGX Spark 同时启动、张量并行跑起 DeepSeek-V4-Flash 时，硬件成本和性能回报都足够“顶”。本文不打算只晒参数，而是把整套思路拆开：为什么需要两台、双机之间如何组网、DeepSeek-V4-Flash 怎么部署、单并发到底能输出多少 token、以及这个过程中最容易踩的报错怎么解决。
1. 背景：为什么“两台 DGX Spark”会成为话题中心
1.1 DGX Spark 是什么
DGX Spark 是 NVIDIA 面向桌面和边缘场景推出的 AI 超级计算机，采用 Grace Blackwell 架构，目标是把“数据中心级”的推理能力放到开发者工位上。它和我常用来跑 CUDA 的普通 GPU 服务器不太一样，整机是一套高度集成的 SoC 方案，统一内存容量很大，适合直接加载大语言模型。
如果你只想做 API 调用，完全不需要了解 DGX Spark。但如果你想在本地跑私有模型，不把业务数据送到外部接口，自己掌控模型权重和推理参数，那么 DGX Spark 这类设备就是很现实的选择。尤其是 DeepSeek-V4-Flash 这类推理速度较快、带思维链特征的模型，放在本地后既不用担心限流，也不用为每一轮请求反复付费。
1.2 DeepSeek-V4-Flash 为什么值得本地部署
DeepSeek-V4-Flash 从命名上就能看出来，定位是“快”。在代码生成、多轮对话、结构化输出这些场景下，它有着不错的响应速度，并且通过 API 接入时模型名必须写成deepseek-v4-flash，不能随意改成其他名称，否则会报 “the supported api model names are deepseek-v4-pro or deepseek-v4-flash” 之类的错误。
本地部署的意义在于：
- 数据不出内网，适合企业敏感代码和文档。
- 可以自由调整采样参数、系统提示词和上下文长度。
- 没有每分钟请求数限制，可以持续压测。
- 多轮对话时的思维链内容可以完整保存，方便二次分析。
但本地部署也意味着你需要自己搞定推理框架、显存管理、多机通信和模型加载。这些正是本文要展开的内容。
1.3 两台机器与“满屏金币的味道”
单台 DGX Spark 已经能跑不少十几 B 到几十 B 参数的模型，但当你面对 70B 甚至更大规模的模型时，单台机器的统一内存就会吃紧。这时把两台 DGX Spark 用高速网络连起来，通过张量并行把模型切成两半，每台分别承担一部分计算，就能在不大幅降低吞吐的前提下运行更大模型。
至于“满屏都是金币的味道”，本质上是大家对这套方案成本的一种调侃。两台设备、高速组网、机柜改造、存储配套，每一项都在花钱，但换回来的又是本地任意调用、团队共享推理能力、以及完全可控的数据闭环。所以在社区里，很多人一边说着“金币的味道”，一边已经在研究怎么组双机了。
2. 环境准备与硬件评估
2.1 单台配置认知
在开始部署前，先明确我们面对的是一个什么样的硬件平台。DGX Spark 并不是传统的 CPU + 独立显卡结构，而是把 Grace CPU 和 Blackwell GPU 封装在一起，共享统一内存。这种架构的优势是显存和内存不再割裂，模型加载时更容易塞进大容量内存；劣势是软件生态必须跟着 NVIDIA 的容器体系走，直接拿普通 GPU 服务器的部署脚本不一定能跑通。
具体规格以 NVIDIA 官网为准，我这里不展开写死参数。你需要重点确认三点：
- 设备的 CPU 架构是不是 ARM64，这决定你拉取的容器镜像平台。
- 统一内存总量是多少，因为这直接决定你能加载多大规模的模型。
- 是否支持 NVLink-C2C 或高速 RDMA 网络，因为双机张量并行非常依赖节点间通信带宽。
2.2 双机组网与互联
两台 DGX Spark 做张量并行，最关键的并不是把两台机器放进同一个机柜，而是它们之间的通信链路要足够快。模型每一层的前向计算都需要把中间结果切分给两个节点，通信时延如果太高，反而会出现“两台机器跑得比一台还慢”的情况。
我在做双机部署时，一般会按下面顺序检查网络：
- 确认两台机器在同一二层网络，IP 可以互通。
- 配置 SSH 免密登录，因为分布式推理框架需要在节点间拉起 worker 进程。
- 检查高速网络接口速率，确认 RDMA 或 RoCE 是否开启。
- 打开推理框架需要的端口，例如 Ray 的 6379 和 8265、vLLM 的 8000 等。
如果在机房没有专门的高速交换机，建议至少使用 25G 以上网卡；如果只是千兆局域网，那就不要强行做张量并行，因为通信开销会吃掉计算收益。
2.3 模型参数规模与显存估算思路
很多人会问“70B 模型到底需要多大内存”，这里可以做一个快速估算。以 FP16/BF16 精度为例，大概每 1B 参数需要 2GB 权重空间：
- 7B 模型大约需要 14GB。
- 70B 模型大约需要 140GB。
- 如果量化到 FP8，70B 大约需要 70GB。
- 如果量化到 INT4/FP4，70B 大约需要 35GB 到 40GB。
单台 DGX Spark 如果是 128GB 统一内存，跑 FP8 的 70B 模型还有余量，但跑 BF16 的 70B 就很紧张，再叠加 KV Cache 和激活值，基本放不下。这就是“两台 DGX Spark 组双机”出现的原因：一台放不下，两台刚好能分摊。
注意，张量并行并不是简单的“两台内存相加”，因为 KV Cache 也需要在节点间切分，通信过程中还会产生额外内存开销。所以实际可用容量通常要打个八折到九折。
2.4 软件栈版本说明
本文示例采用 vLLM 作为推理服务框架，因为它对 OpenAI 兼容接口支持较好，也方便通过环境变量和命令行参数控制分布式行为。但 vLLM 版本迭代很快，不同版本的参数名有所差异，比如分布式执行后端就有ray和external-launcher两种选择。
如果你的环境是纯 Ubuntu 系统，建议先装好以下基础组件：
- NVIDIA Container Toolkit，用于容器内识别计算设备。
- Docker 或 Podman，用于运行 NGC 容器。
- Python 3.10 或更高版本，用于运行评测脚本。
- vLLM 的 docker 镜像或 pip 包，推荐直接用官方镜像。
版本需要根据你的项目实际情况调整，本文示例以常见环境为例，重点演示配置思路。DGX Spark 是 ARM64 架构，拉取容器镜像时要注意平台标签，不要默认拉 x86_64 版本。
3. 部署 DeepSeek-V4-Flash 的两种方式
3.1 通过 DeepSeek API 快速接入
如果你只是想快速验证模型效果，不需要本地部署，可以直接使用 DeepSeek 开放平台 API。注意模型名必须写完整，例如：
from openai import OpenAI client = OpenAI( api_key="你的API-KEY", base_url="https://api.deepseek.com" ) resp = client.chat.completions.create( model="deepseek-v4-flash", messages=[ {"role": "user", "content": "用 Python 写一个快速排序"} ], max_tokens=1024, temperature=0.7 ) print(resp.choices[0].message.content)这里有一个容易被忽略的点：如果开启了 thinking 模式，也就是让模型输出推理过程，那么多轮对话时必须把上一轮返回的reasoning_content原样传回，否则服务端可能返回 HTTP 400，错误信息会提示:
the `reasoning_content` in the thinking mode must be passed back to the api.也就是说，API 要求你在多轮请求中保留思维链内容，这不仅是官方限制，也是为了保证推理上下文连贯。之后我们在本地部署时也会遇到同样的问题。
3.2 本地部署：单机运行 vLLM
本地部署的第一步是下载模型权重。DeepSeek-V4-Flash 可能通过 HuggingFace 或 ModelScope 分发，你需要先确认模型仓库地址，然后下载到本地目录。为了统一管理，我习惯把模型放在/models目录下。
pip install -U huggingface_hub huggingface-cli download <你的模型仓库名> \ --local-dir /models/deepseek-v4-flash如果你在中国大陆网络环境下无法访问 HuggingFace，可以改用 ModelScope：
pip install modelscope modelscope download --model <你的模型ID> \ --local_dir /models/deepseek-v4-flash模型下载完成后，先不要急着上双机，先用单机把服务跑起来，确认模型权重没问题，再进行多机扩展。
docker run --gpus all \ -v /models:/models \ -p 8000:8000 \ --ipc=host \ vllm/vllm-openai:latest \ --model /models/deepseek-v4-flash \ --tensor-parallel-size 1 \ --served-model-name deepseek-v4-flash \ --max-model-len 32768启动后看到类似Uvicorn running on http://0.0.0.0:8000的输出，就说明服务起来了。此时可以用 curl 验证：
curl -s http://127.0.0.1:8000/v1/models响应里应该能看到你配置的模型名deepseek-v4-flash。
3.3 双机张量并行部署
单机验证通过后，开始在第二台机器上重复同样的模型下载和镜像拉取操作，保证两台机器的模型权重一致。然后选择一种分布式执行后端。
如果你的 vLLM 版本较老，推荐使用 Ray。在主节点执行：
ray start --head --port=6379 --dashboard-host=0.0.0.0在第二台机器执行：
ray start --address=<主节点IP>:6379回到主节点，启动 vLLM：
vllm serve /models/deepseek-v4-flash \ --tensor-parallel-size 2 \ --distributed-executor-backend ray \ --served-model-name deepseek-v4-flash \ --host 0.0.0.0 \ --port 8000如果你的 vLLM 版本比较新，推荐使用external-launcher模式，它不需要额外启动 Ray，而是由主节点生成 worker 启动命令，你只需要把这些命令复制到第二台机器执行即可。具体操作方式如下：
vllm serve /models/deepseek-v4-flash \ --tensor-parallel-size 2 \ --distributed-executor-backend external-launcher \ --served-model-name deepseek-v4-flash \ --host 0.0.0.0 \ --port 8000vLLM 会在主节点输出 worker 命令，并把命令写入临时文件。你需要把 worker 命令复制到第二台机器执行，等两边 worker 都就绪后，主节点会继续完成模型加载和初始化。
这里特别提醒：启动命令里的--tensor-parallel-size 2表示张量并行切分成 2 份，也就是两台机器各承担一半模型权重和计算量。如果两台设备的网络带宽一般，建议先用较小的上下文长度做连通性测试，不要一上来就拉满--max-model-len。
双机启动完成后，可以通过任意一台机器的 8000 端口访问推理服务：
curl -s http://<主节点IP>:8000/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model": "deepseek-v4-flash", "messages": [ {"role": "user", "content": "用 Python 写一个快速排序"} ], "max_tokens": 512, "temperature": 0.7 }'如果返回内容包含正常的choices字段，说明双机张量并行已经跑通。
4. 性能测试：怎么测“输出多少 token”
4.1 关键指标：TTFT、TPOT、吞吐
很多人关心“单并发输出多少 token”，其实这是一个不够严谨的问法。更专业的指标有三个：
- TTFT：首 Token 生成时间，也就是从发送请求到返回第一个 token 的耗时。
- TPOT：每个输出 token 的平均生成时间，单位通常是毫秒。
- 吞吐量：整个系统在单位时间内生成的 token 数，通常用 tokens/s 表示。
单并发场景下，用户感知最明显的是 TTFT 和 TPOT，也就是“多久开始输出”和“每秒能吐多少字”。多并发场景下，系统吞吐量才是更值得关注的指标，因为并发多了以后，单请求的响应时间会明显变慢，但整体吞吐可能还在上升。
4.2 使用 vLLM 自带 benchmark
vLLM 自带了 Benchmark 脚本，可以用来做离线压测。它不需要启动服务，而是直接加载模型进行评测，适合在正式上线前评估硬件极限。
python -m vllm.benchmark.benchmark_throughput \ --model /models/deepseek-v4-flash \ --tensor-parallel-size 2 \ --input-len 512 \ --output-len 256 \ --num-prompts 100参数含义：
--input-len：输入 prompt 的长度。--output-len：期望生成的最大 token 长度。--num-prompts：请求数量，请求数越多越能反映系统压力。
注意，DGX Spark 的 ARM64 架构可能和 pip 安装的 vLLM 二进制包不完全兼容，更推荐在 NGC 容器或官方 Docker 镜像中执行 benchmark。
4.3 自写脚本测单并发输出 token 数
如果你想模拟真实调用场景，可以直接写一个 Python 脚本，通过 OpenAI SDK 请求本地服务，统计从请求发出到完整返回的时间，然后计算每秒输出 token 数。
import time from openai import OpenAI client = OpenAI( api_key="EMPTY", base_url="http://127.0.0.1:8000/v1" ) prompt = "请写一篇关于大模型部署的技术总结，不少于300字。" start = time.time() resp = client.chat.completions.create( model="deepseek-v4-flash", messages=[ {"role": "user", "content": prompt} ], max_tokens=1024, temperature=0.7 ) end = time.time() content = resp.choices[0].message.content token_count = len(resp.usage.completion_tokens) elapsed = end - start print(f"生成 token 数: {token_count}") print(f"总耗时: {elapsed:.2f}s") print(f"吞吐: {token_count / elapsed:.2f} tokens/s")如果你使用的是 DeepSeek 官方 API，并且开启了 thinking 模式，还需要在响应中取出reasoning_content并打印，方便判断推理耗时和生成耗时分别占多少比例。
4.4 结果如何解读
单并发场景下，模型的输出速度通常取决于算力和显存带宽。DGX Spark 采用统一内存架构，推理大模型时内存带宽的优势会比较明显，但要注意：双机张量并行并不是“两台机器速度翻倍”的简单关系。
- 如果两个节点之间通信开销占比不高，双机确实能提高单并发输出速度。
- 如果网络带宽不足，或者在每层计算都需要频繁交换中间结果，速度可能不升反降。
- 如果目标是提升多并发吞吐，双机的收益通常比单并发更明显。
我自己做压测时，一般会先跑 10 个请求看单并发延迟，再跑 100 个请求看系统吞吐，最后把并发数逐步提高到 8 或 16，观察 TTFT 和 TPOT 的变化趋势。不要只看一个指标，因为单并发快不代表多并发稳定。
5. 常见问题与排查思路
5.1 模型名不支持：supported api model names
问题现象：
调用 DeepSeek API 时返回：
the supported api model names are deepseek-v4-pro or deepseek-v4-flash, but...可能原因：
请求体里的model字段写错了，或者多打了空格、大小写不一致。
解决思路：
检查请求体中的模型名，必须使用deepseek-v4-pro或deepseek-v4-flash。
"model": "deepseek-v4-flash"同时检查base_url是否拼写正确，确认自己使用的是官方 API 地址而不是第三方代理。
5.2 reasoning_content 必须回传：HTTP 400
问题现象：
多轮对话时，服务端返回 HTTP 400：
the `reasoning_content` in the thinking mode must be passed back to the api.可能原因：
DeepSeek 的 thinking 模式要求，上一轮 assistant 返回的思维链内容必须原样传回，作为新一轮请求的上下文。如果你只把content传回去，丢掉了reasoning_content，服务端就会认为上下文不完整。
解决思路：
多轮对话时，把上一轮响应的reasoning_content和content一起拼装到 messages 里。
messages = [ {"role": "user", "content": "解释一下什么是张量并行"}, { "role": "assistant", "content": "张量并行是指把模型权重切分到多张卡或多台设备上。", "reasoning_content": "先解释概念，再补充通信开销说明。" }, {"role": "user", "content": "那它和流水线并行有什么区别？"} ]具体字段名要以 DeepSeek 官方文档为准，如果你的 SDK 版本不支持reasoning_content字段，可以尝试用extra_body传入，或者在本地代理层处理。
5.3 CC Switch 本地代理转发失败
问题现象：
使用 CC Switch 配置本地代理转发 Codex 请求时，日志报错：
cc switch local proxy failed while handling codex endpoint /responses. provider: deepseek; model: deepseek-v4-flash; upstream_status: http 400可能原因：
这个报错的本质不是 CC Switch 本身的问题，而是上游 DeepSeek API 拒绝了请求。上游返回 400，可能是模型名写错，也可能是没有正确处理reasoning_content，还可能是该模型不支持你当前使用的某些参数。
解决思路：
- 先绕过 CC Switch，直接用 curl 或 Python 访问 DeepSeek API，确认请求参数是否正确。
- 检查 CC Switch 配置里的 provider 和 model 是否一致。
- 如果开启了 thinking 模式，检查多轮消息中是否回传了
reasoning_content。 - 查看 DeepSeek API 返回的响应体，400 错误通常会在响应 body 里给出具体原因。
- 如果请求中带了
stream和thinking等参数，逐个去掉排查。
记住：本地代理工具只是转发层，真正校验逻辑在上游服务，所以不要只盯着代理日志，还要看上游返回的 body。
5.4 双机可以跑但速度反而变慢
问题现象：
两台机器启动成功，模型也能正常对话，但单并发生成速度比单机还慢。
可能原因：
这是张量并行最容易踩的坑。每层计算都要做 AllReduce 通信，如果网络延迟高、带宽低，通信时间会超过计算节省下来的时间。
解决思路：
- 检查两台机器之间的网络是否是高速互联。
- 尝试把大请求切小，降低每轮通信的数据量。
- 用
--max-model-len限制上下文长度，减少 KV Cache 同步压力。 - 用
--enforce-eager关闭 CUDA Graph，避免内存和编译问题。 - 确认为什么需要两台机器：如果你的模型单台内存其实装得下，只是追求速度，那双机并不是一定更快。
5.5 ARM64 与容器环境问题
| 问题现象 | 常见原因 | 解决思路 |
|---|---|---|
| 容器启动报 Exec format error | 拉取了 x86_64 镜像 | 检查平台标签，拉取 arm64 镜像 |
| 容器内看不到设备 | NVIDIA Container Toolkit 未安装 | 安装并重启 Docker，使用--gpus all |
| 模型加载 OOM | 模型精度太高或上下文过长 | 换 FP8/INT4 量化，或减小 max-model-len |
| Ray 节点连不上 | 端口未开放或防火墙拦截 | 打开 6379、8265 端口，检查安全组 |
6. DeepSeek-V4-Flash 与 GLM5.2 的选型建议
6.1 选型维度
很多开发者会纠结写代码到底选 DeepSeek-V4-Flash 还是 GLM5.2。我的建议是不要只看社区口碑，而是按下面几个维度自己测：
- 代码生成正确性：让模型写同一个算法题，检查可运行性和边界条件。
- 长上下文稳定性：粘贴一段长代码文件，看模型是否会遗漏中间内容。
- 多轮修改能力：让模型根据用户反馈反复修改代码，对比指令遵循度。
- 工具调用支持：是否有 function call，是否能稳定输出结构化参数。
- 部署成本：模型大小、显存占用、推理框架兼容性。
6.2 代码生成场景实测思路
最简单的方法是用同一组 prompt 分别请求两个模型，然后对比输出。可以用一个小脚本自动统计通过率。
prompt = "用 Python 实现一个 LRU Cache，要求 get 和 put 都是 O(1) 时间复杂度。" models = ["deepseek-v4-flash", "glm-5.2"] for model in models: resp = client.chat.completions.create( model=model, messages=[{"role": "user", "content": prompt}], max_tokens=1024, temperature=0.3 ) print(f"===== {model} =====") print(resp.choices[0].message.content) print()实际评测时，最好准备 20 道不同类型的题目，包括算法、SQL、正则表达式、Shell 脚本和 Bug 修复，然后人工或通过单测判断正确性。不要用“写一个排序”这种太简单的题目，因为所有模型都能答对，没有区分度。
6.3 结论与建议
如果你的核心诉求是“私有化部署 + 快速响应”，DeepSeek-V4-Flash 的部署生态和思维链能力可能更适合你；如果你更看重中文场景的综合表现，并且愿意在 API 或私有化方案之间做权衡，GLM5.2 也值得在你的数据集上跑一轮。
我的建议是：在正式选型之前，把两个模型都接到同一个应用框架里，用功能开关切换，内网跑一周，记录成功率、延迟和资源占用，再做决定。不要因为一个帖子就替换线上模型。
7. 最佳实践与工程建议
7.1 私有化部署边界
本地部署大模型不是简单的“下载模型 + 启动服务”，它意味着你要对模型的使用边界负责。建议从开始就做好三件事：
- 模型文件只允许服务进程访问，不开放任意文件下载。
- 推理服务通过 API Token 或网关认证保护，不暴露到公网。
- 对每个请求记录日志，包括调用方、模型、输入长度、输出长度、耗时。
如果你是企业内网使用，建议把 DGX Spark 放在受控网段，只允许应用服务器访问推理端口。
7.2 多节点推理的注意事项
双机张量并行涉及分布式系统，排查问题时要按“网络 → 端口 → SSH → 框架日志 → 模型权重”的顺序来。
- 网络不通，一切白搭。
- 端口没开，Ray 和 worker 起不来。
- SSH 免密没配置，external-launcher 模式无法拉起远端进程。
- 框架日志里通常会给出具体错误，不要只盯着终端最后几行。
- 模型权重不完整，启动时可能不报错，但生成结果会很差。
生产环境建议先写一个启动脚本，把两台的 vLLM 命令固定下来，避免每次手工输入。
7.3 成本与算力评估
“金币的味道”背后其实是成本和收益的权衡。在决定买第二台 DGX Spark 之前，先评估：
- 当前模型的参数量多大，单台内存是否真的放不下。
- 是单并发延迟敏感，还是多并发吞吐敏感。
- 是否需要数据不出内网，还是可以接受 API 调用。
- 如果选择量化，精度损失是否在业务容忍范围内。
如果只是为了跑 7B 或 14B 模型，单台设备已经足够，第二台设备可能无法带来预期的速度提升。如果目标就是 70B 级模型，那么双机张量并行才有实际意义。
7.4 日志与稳定性
推理服务跑起来之后，建议把 vLLM 的标准输出保存到日志文件，并设置进程守护。一个简单的 systemd 服务或 supervisord 配置会省很多事。遇到服务无响应时，第一件事不是重启，而是查日志。
另外，多轮对话场景下，要关注上下文长度增长速度。即使--max-model-len设置得很大，长对话也会显著增加显存占用和推理延迟，建议在应用层做 session 长度控制，比如超过一定轮数后自动压缩历史消息。
8. 总结与下一步学习路线
本文从硬件背景、双机组网、vLLM 部署、性能测试、常见报错到模型选型，梳理了一套相对完整的 DGX Spark 双机运行 DeepSeek-V4-Flash 的方案。核心要点可以归纳为：
- 两台 DGX Spark 的价值在于解决大模型放不下、单机内存不足的痛点。
- 张量并行不是“两台变一台更快的机器”，通信开销必须纳入评估。
- DeepSeek-V4-Flash 的 thinking 模式要求多轮对话回传
reasoning_content，这是 API 400 报错的高频原因。 - 性能评估不能只看“单并发输出多少 token”，要看 TTFT、TPOT 和系统吞吐。
- 模型选型必须基于自己的代码测试集，不要盲从社区结论。
接下来你可以继续学习三个方面：一是深入 vLLM 的调度原理，理解 Prefill 和 Decode 阶段对吞吐的影响；二是研究量化方案，比如 FP8 和 INT4 在 DGX Spark 上的精度与速度平衡；三是把推理服务接入自己的 CI 或开发环境，让团队真正用起来，而不是只停留在压测阶段。
如果你手头也在折腾双机推理，建议先从单机跑通开始，再逐步扩展到多节点，每次只改一个变量。这样即使出了问题，也能快速定位是网络、权重、参数还是镜像的问题。码字不易，如果这篇文章对你有帮助，可以收藏备用，也欢迎在评论区分享你的双机部署结果。
