两台 DGX Spark，承载一个科室的“数字员工编制”

我先联网查这条消息的原始出处 —— 重点是 “两台 DGX Spark 撑起一个科室数字员工” 这个具体案例。

两台 DGX Spark 装下一个科室的 “数字员工编制”：桌面级私有化 AI 的真实边界

这套方案的价值在于把 “数据不出科室” 和 “用上最新大模型” 这两件原本互斥的事同时办成，算力多强并不是它的重点。 NVIDIA 英伟达中国 11 月 9 日发布的客户案例显示，NVIDIA 初创加速计划会员企业听微（产品名 createrole）用两台 NVIDIA DGX Spark 组成桌面集群，为不能上云的客户交付完整的数字员工体系：每台 128GB 统一内存、GB10 Grace Blackwell 超级芯片，两台之间通过 ConnectX-7 网卡直连、用 NCCL 通信协同运行。交付形态从 “立项 — 机房排期 — 服务器上架 — 专线接入，按月计算”，变成 “当天开箱、当天部署、验收即物理断网”。听微创始人兼 CEO 朱朝华的说法是：“两台设备就是一个科室的 AI 编制。这件事以前做不到，现在是我们的标准交付。” 这句话需要准确理解：这里的 “编制” 是一个比喻，并不是人力岗位编制；官方也没有给出 “两台设备顶几个人的工作量” 这种量化数字。

一、先把 “数字员工” 和 “编制” 这两个词说清

概念	实际含义	不要误读成
数字员工	有独立身份、长期记忆，配备一台自己的沙盒电脑，能跑命令、写文件、交付产物	聊天机器人、问答助手
到点自动干活	待办事项到点自动醒来执行，可充当秘书统一分派任务	7×24 不间断常驻服务
一个科室的编制	一个科室规模的应用与智能体，全部跑在桌上两台设备上	替代科室若干个人力岗位
拔线可用	部署完成、验收后可物理断网运行	断网后还能在线更新模型和知识
私有化	模型服务与应用全栈整合在客户可掌控的环境中	只是把模型权重拷到本地

第三行是关键：“编制” 描述的是容量单位，并不是裁员指标。 官方稿里没有任何 “节省多少人”“替代多少工时” 的数字，这类换算不应该由读者自己补上。

二、以前为什么做不成：三个卡点，最后一个最致命

云 API 直接被排除。 客户要求不能调用云端 API，不能把材料传到任何外部服务，部分场景验收后还要求物理断网。这是硬约束，并不是偏好。
私有化交付周期按月计算。 客户机房排期、服务器上架、专线接入，这套流程走完往往要几个月。
不少核心科室根本没有机房使用权限。 这一条最容易被忽略：AI 项目卡在基础设施这一环，原因并不在模型选型，而在于科室连申请机柜的资格都没有。

前两条靠钱和时间能解决，第三条只能靠把基础设施 “缩小到能放在桌上”。这就是两台 DGX Spark 出现的直接原因。

三、两台怎么拼成一个集群

项目	规格	对这条案例的意义
芯片	GB10 Grace Blackwell 超级芯片	CPU 与 GPU 共享统一内存，省掉数据搬运
单机内存	128GB 统一内存	大模型与 KV Cache 装在同一块内存池里
单机 AI 算力	最高 1 PFLOP（FP4）	桌面级设备也能承担 Agent 的高频采样
内存带宽	273 GB/s	解码速度的量级保证
单机支持模型	本地推理最高约 200B 参数，微调最高约 70B	决定了 “够大、上下文够长” 这条底线
双机互联	ConnectX-7 直连 + NCCL 通信，合计最高约 405B 参数	两台设备组成 “一个集群”，并不是单纯增加两台机器
形态	150×150×50.5mm、约 1.2kg	桌上叠放两台，不需要机柜

表格里最值得记住的是双机互联那一行。两台机器不能简单相加：只有用 ConnectX-7 直连、跑 NCCL，两台设备才会被当成一个推理集群；如果用普通以太网把两台机器拼在一起，它们在模型眼里仍是两台独立设备，405B 这条上限也就不成立。

四、听微遇到的三个真问题，比算力更值得看

问题一：数字员工的干活质量取决于模型，而模型的底线是内存。 本地要跑参数量够大、上下文够长的模型，内存、算力、多模态能力都是硬门槛。128GB 统一内存正是为此准备的，它同时装得下模型权重和长上下文的 KV Cache。

问题二：负载不只是推理。 沙盒里的任务执行、每天夜间的记忆固化与人格演化批处理、技能考试与补习，全部要在本地闭环。这一条解释了为什么 “一个科室” 需要两台设备，而不只需要一台：白天跑交互，夜里跑批处理，两者抢的是同一份算力。

问题三：Agent 场景对推理服务的要求比聊天苛刻得多。 一个回合内模型要被采样十几轮，每轮都携带全部历史，KV Cache 命中率和解码速度直接决定任务耗时；开源模型的工具调用可靠性参差不齐，还需要工程层做额外处理。这是最容易低估的一条：聊天机器人一轮就答完，数字员工一个任务要循环十几轮，同样的模型在两种负载下的体验差一个量级。

五、交付形态变了，这才是案例的真正看点

环节	传统私有化交付	两台 DGX Spark 方案
立项到可用	按月计算	当天开箱、当天部署
基础设施	机房排期、服务器上架、专线接入	桌上两台设备
权限门槛	需要机房使用权限	核心科室可自行掌控
验收方式	逐步加固网络安全	验收即拔线断网
数据路径	需证明 “不外传”	物理上不外传
运维	客户 IT 部门接管机房设备	部署、运行、维护集中在客户可控环境

最后一行 “物理上不外传” 是这条案例最有说服力的地方。合规文件能证明 “我们承诺不传”，物理断网能证明 “我们想传也传不出去”，后者的说服力完全不同。

六、能力边界：这套方案做不到什么

断网后知识会静态化。 模型和知识库停在交付时刻，院内指南更新需要重新灌数据，不是自动同步。
200B、405B 是上限，运营落不到满配。 上下文越长、并发越高，能跑的参数量就越小，实际配置要按业务场景裁剪。
两台是一对，并不是一个可无限扩展的集群。 科室级够用，院级平台化仍需回归机房。
这是厂商案例稿，没有第三方实测。 稿件的发布方是 NVIDIA，客户是 NVIDIA 初创加速计划会员，效果描述全部来自双方自述，没有延迟、并发的第三方基准数字。
“当天交付” 取决于现场条件。 电力、网络隔离、HIS 接口对接仍需现场配合，官方表述是 “当天部署、验收断网”，没有承诺零改造。

七、同款设备在医疗场景已经不是孤例

机构	用途	关键点
香港中文大学（深圳）医院	本地部署 OpenClaw 医疗智能体，接入华佗 GPT	基于 DGX Spark 私有化算力，只读接口访问 HIS，智能体不改写原始数据
纽约大学全球 AI 前沿实验室	ICARE 放射报告评估，多智能体协同	端到端本地运行，影像数据不上云
哈佛大学 Kempner 研究所	研究约 6000 种神经元突变与癫痫机制	先单机验证工作流，再扩到大型 GPU 集群
威斯康星大学 IceCube 中微子天文台	南极现场 AI 分析中微子观测数据	极端偏远环境的本地部署

港中深医院那条尤其值得对照：它走的是 “智能体 + 私有化硬件 + 只读数据接口 + 沙箱隔离” 的组合，和听微的思路同源 ——先用架构约束把 AI 关进可控的边界，再谈它能干什么。

【相关 FAQ】

问题 1：两台 DGX Spark 真的能承载一个科室的 “数字员工编制” 吗？

回答 1：在科室级、非全院级的负载下可以。NVIDIA 官方客户案例中，听微用两台 DGX Spark 通过 ConnectX-7 直连和 NCCL 协同，把数字员工体系的模型服务与应用全栈整合在桌面集群上，实现当天部署、验收断网。但要明确：这里的 “数字员工编制” 指一个科室规模的应用容量，官方未给出等量人力换算；两台是一对固定配置，不是可无限扩展的集群。

问题 2：两台 DGX Spark 和一台有什么区别，为什么不直接用一台？

回答 2：关键在于互联方式和内存总量。单台 DGX Spark 是 128GB 统一内存、本地推理最高约 200B 参数；两台经 ConnectX-7 直连并用 NCCL 通信后，可协同支持最高约 405B 参数，并被当成一个集群。数字员工的负载不只有推理，还包括沙盒任务执行、夜间记忆固化与人格演化批处理，一台设备同时扛白天交互和夜间批处理会互相抢资源。

问题 3：为什么 “数据不出科室” 必须靠 DGX Spark 这类桌面设备，不能用私有云？

回答 3：因为很多核心科室根本没有机房使用权限。NVIDIA 案例里明确写到，传统私有化交付要经历机房排期、服务器上架、专线接入，周期按月计算，AI 项目往往卡在基础设施这一环。两台 DGX Spark 把数据中心级算力缩到桌面，部署、运行、维护都在客户可直接掌控的环境里，验收后还能物理断网，这正是 “数据不出科室” 最硬的证明方式。

问题 4：DGX Spark 跑数字员工，最大的技术难点是算力还是别的？

回答 4：难点更多在 Agent 场景的推理特性上，算力并不是主要问题。NVIDIA 案例指出，一个回合内模型要被采样十几轮、每轮携带全部历史，KV Cache 命中率和解码速度直接决定任务耗时；同时开源模型的工具调用可靠性参差不齐，需要工程层做额外处理。DGX Spark 的 128GB 统一内存和 273GB/s 带宽解决的是 “装得下、解得动”，工程问题仍要靠应用侧处理。

问题 5：两台 DGX Spark 断网后还能正常干活吗？

回答 5：能干活，但不能更新。数字员工的模型权重、记忆库、技能包都在本地，物理断网后推理与任务执行照常进行，这正是验收断网方案的设计目的。代价是知识静态化：院内指南更新、模型升级都需要重新灌数据，不会自动同步；所以 “用上最新 AI” 指的是交付那一刻的最新，不是持续在线的最新。

问题 6：这套 “两台 DGX Spark + 数字员工” 的方案适合什么样的科室？

回答 6：适合数据敏感、但没有机房权限、又确实有高频文本与流程工作的科室。典型场景是病历与报告整理、知识检索、任务分派与批处理 —— 港中深医院用同款硬件做 OpenClaw 医疗智能体，跑的就是病历预填、体检报告批量生成这类活。反过来，如果科室需要跨院区共享算力、要接大量并发用户，两台 DGX Spark 的容量会成为瓶颈，应该考虑院级机房方案。

【参考资料】

[2026-11-11]（NVIDIA DGX Spark 在高校与科研机构的应用：纽约大学 ICARE、哈佛 Kempner 研究所、IceCube 中微子天文台）NVIDIA 英伟达

[2026-11-09]（两台 DGX Spark，承载一个科室的 “数字员工编制”）NVIDIA 英伟达中国

[2026-07-31]（Serve LLMs with SGLang on DGX Spark：DGX Spark 支持模型与内存配置）NVIDIA Build

[2026-03-14]（业内首个！香港中文大学（深圳）医院本地部署 OpenClaw，基于 DGX Spark 私有化硬件）香港中文大学（深圳）医学院

【免责声明】

本文基于 NVIDIA 官方博客客户案例、NVIDIA 开发者文档与医疗机构公开报道整理，非商业推广，也不构成采购或技术选型建议。文中 “数字员工编制” 为案例方的比喻表述，不指代人力岗位编制，官方未提供任何等量人力或工时换算数据；本文亦未作此类推算。案例效果（当天部署、验收断网等）为厂商与客户自述，未见第三方基准测试，实际交付受现场电力、网络隔离、院内系统接口与合规审查影响。DGX Spark 的 1 PFLOP FP4、128GB 统一内存、约 200B 参数推理上限、双机约 405B 参数等均为厂商公布规格，属理论上限，实际可跑模型规模随上下文长度与并发数下降。文中所列其他机构部署情况来自各自公开材料，与听微案例无合作关系，仅作同类场景参照。物理断网可确保数据不外传，但同时意味着模型与知识库无法在线更新，使用者需自行评估知识时效性风险。

本文来自作者[频域织元]投稿，不代表乌兰科技网立场，如若转载，请注明出处：https://www.wlcbnews.com/shangye/202611/1692.html