4台DGX Spark实测DeepSeek V4.1 Flash：本地推理生产力如何？

为什么要在本地跑一个“大模型”

把 DeepSeek^广告 V4.1 Flash（社区常称 1017 版本）部署在自己桌边，而不是调用云端 API，最直接的理由是数据流向可控。B站 UP 主用 4 台 DGX Spark / GX10 串成一个环，通过 200G DAC 线互联，没有使用高速交换机——这是 NVIDIA 官方 4 卡指南之外的一条社区路线。官方推荐交换机布局，但交换机成本不低，Ring 拓扑被社区跑通后，成了更务实的选择。

这套方案跑的是 SGLang，UP 主提到社区还有 TensorRT-LLM 等新引擎在跟进，同一套硬件后续仍有优化空间。本文基于其实测数据，拆解本地推理的真实表现：生成速度、首 Token 等待、多路并发，以及四个“许愿式”任务的完成度。

DGX Spark 是 NVIDIA 面向桌面与边缘场景推出的紧凑型 AI 计算设备（社区也常以 GX10 等代号称呼同类产品），定位介于工作站与开发套件之间，强调在低功耗、小体积下提供可观的显存与算力，用于本地推理和微调。Ring 拓扑则指多台设备首尾相接形成一个逻辑环，每台只需与相邻两台直连，相比星型交换机布局节省了交换机端口与成本，代价是跨节点通信需要多跳转发；在张量并行等需要频繁全节点通信的场景下，环形互联的带宽与时延表现会直接影响推理吞吐。

生成速度：代码快于散文，但别和云端比峰值

实测数据分两个口径。关闭思考模式、16 路合计时，代码任务 369.9 Token/s，散文 317.8 Token/s；单路视角下，代码 119.8 Token/s，散文 71.2 Token/s。

代码更快的原因不难理解：代码结构规整，后续内容更可预测，推测解码有机会一次确认多个 Token。散文的自由度更高，推测命中率下降，速度自然回落。

这个数字放在横向对比里是什么位置？OpenRouter 图表显示 DeepSeek 官方端点约 63 Token/s，中转访问更慢；UP 主引用网上数据称直连官方 API 约 200 Token/s（未实测）。本地四台小机器跑到 119.8 Token/s，已经超过官方端点的公开读数，但离部分服务商的 294 Token/s 仍有距离。常用国外工具方面，Claude 约 107.1 Token/s，Codex 约 37.2 Token/s，注意这些数据来自不同环境，只能作为量级参考。

推测解码（Speculative Decoding） 是一种在不改变输出分布的前提下加速生成的技术：先由一个轻量“草稿”模型或启发式方法快速猜出后续若干个 Token，再由主模型一次性并行验证，猜对的部分直接采纳，猜错则从第一个分歧处回退。它的加速比高度依赖文本的可预测性——代码、模板化文本的命中率高，自由散文命中率低，这正好解释了实测中代码快于散文的现象。TP4 指张量并行度为 4，即把单层权重切分到 4 台设备上协同计算，是四卡集群运行大模型的常见并行策略。

首 Token 等待：长上下文是真正的门槛

本地部署的短板不在生成，而在“读资料”的阶段。实测 TTFT（从发送到第一个 Token 输出）：6 万多 Token 约 5400 Token/s，等 12 秒；26 万 Token 约 4800 Token/s，等 54 秒；100 万 Token 约 3400 Token/s，等 4 分 54 秒。

单看这些等待时间确实劝退。但 UP 主的日常用法是 DeepSeek Harness，连续任务缓存命中率基本在 90% 以上，前面算过的内容直接复用，只补算新增部分——同样一份 6 万多 Token 的资料，第二次提问只等 0.4 秒。缓存把“长上下文”的痛感大幅削平，这也是本地 Agent 工作流能跑起来的关键。

TP4 配置支持 100 万 Token 上下文。一版完整《基督山伯爵》约 59 万汉字、两兆多纯文本，分词后约 67.5 万 Token，整本放进去还剩 37 万多 Token 余量，可以继续提问或让它续写。

TTFT（Time To First Token） 指从请求发出到收到第一个输出 Token 的耗时，主要由预填充（prefill）阶段决定：模型需要把整段输入上下文的 KV 缓存算出来，计算量与上下文长度近似成正比，因此上下文越长等待越久。KV 缓存命中则依赖前缀缓存（prefix caching）机制——若新请求的开头与历史请求完全一致，引擎可复用已算好的 KV 状态，只对新增部分做预填充。这正是同一份 6 万 Token 资料二次提问仅需 0.4 秒的原因，也是长上下文 Agent 工作流在本地可行的前提。

并发与多人使用：16 路是配方上限，不是体验上限

一路时是一个人用，八路时是多件事一起跑。把统一测试拉到配方设置的 16 路，每个人分到的速度会慢一些，但整组吞吐更高。

这个特性决定了适用场景：它不是给一个人追求极致响应速度的，而是给小团队共享一个内网推理池的。UP 主的判断是，四台 Spark 跑这个模型，个人和小公司内部使用“已经很实用”——模型推理留在内网，个人资料、客户合同、工作文档的流向自己掌控，少了一层对云服务的依赖。

四个压力测试：从骑车到造一座城

UP 主用四个任务检验实际生产力，提示词都极短，靠模型自行补全细节：

让提湖骑车：约 7 分多钟产出首个 HTML，腿在踩、轮子在转、身体跟着起伏，提示词只有一句话。

三维救援游戏：峡谷、缆车、风暴和目标全部由模型搭建。第一版有 bug，反馈一次后修复，修完可移动接人、转运。有意思的是 DeepSeek 把风力写进了物理计算——航向会因风力偏移，玩家得不断修正，最终救回三名乘客。

福岛从荒芜到繁华：草地铺开、小路出现、树和建筑一层层长起来，风车转动，镜头可环绕这个小世界移动。

虚构掌机官网：为一款叫“灵界”的透明掌机做产品官网，机身随滚动分成六层，可切换配色，预约弹窗在手机上也能操作。但细看就露馅了——内部没有细腻结构，电路更像几层平面玻璃叠在一起。一个 HTML 完成了形象与交互，深度有限。

部署体验：从调参数到交给 Agent

很多人对本地部署的印象还停留在对着文档调参数。UP 主现在的流程是：接电源、连 DAC 线、配好 SSH，把配方链接交给 Agent，让它部署模型，再接入 DeepSeek Harness。等机器人学会插线，连电源和网线这两步也能省掉。

1017 发布后的第二天，这套社区配方就跑起来了。从时间线看，社区适配速度已经跟得很紧。

一个值得留意的背景：UP 主提到 DeepSeek 官方记录了一次近五小时的网页和 API 部分中断。具体日期和细节原文表述含糊，但指向一个朴素论点——把推理放在家里，就少了一层对云服务可用性的依赖。这也是本地部署在 2026 年仍被反复讨论的核心动因：不是追求跑分，而是追求不被打断。

SGLang 是面向大模型推理与 Serving 的开源框架，核心特性包括 RadixAttention（用基数树管理 KV 缓存前缀复用）、高效的多路批处理调度，以及对张量并行、量化等部署形态的支持，特别适合需要高缓存命中率的多轮对话与 Agent 场景。文中提到的 TensorRT-LLM 则是 NVIDIA 自家的推理优化库，侧重算子融合、量化与内核级调优以压榨 GPU 性能。同一套硬件更换推理引擎，往往能在吞吐、首 Token 延迟上获得不同取舍，这也是社区配方持续迭代的空间所在。

结论：够用，且边界清晰

四台 DGX Spark 组成的 Ring 集群，跑 DeepSeek V4.1 Flash，在代码生成上接近 120 Token/s，缓存命中后长上下文几乎无感，16 路并发能撑起小团队共享。它的价值不在峰值性能，而在数据主权和可用性自主。代价是硬件成本、首 Token 延迟，以及复杂三维任务仍需人工反馈迭代。

对个人开发者和十人以下团队，这套方案已经跨过“可用”门槛；对追求极致吞吐的生产环境，交换机布局和更强的引擎仍是下一步。