n8n 教程：在一台 DGX Spark 上离线跑七个本地模型与完整工作流，附实测吞吐与内存数据
DGX Spark 本地模型：n8n 教程用一台机器跑七个模型，单用户 120 tok/s，但文中 LiteLLM 1.84.0 下限会放行受影响版本。
NVIDIA DGX Spark 是英伟达的桌面 AI 工作站，核心是 GB10 芯片，文中的机器配 128GB 统一内存。n8n 官方博客 10 月 19 日发表教程，演示如何在一台这样的机器上提供七个本地模型，再经一个 LiteLLM 端点统一对外，让 n8n 工作流不再调用任何云端 API。文中的单用户生成速度是 120 tok/s，来自 10 月 13 日的一次实测。
要点
- 七个模型都是 Apache 2.0 或 MIT 许可，我们在 Hugging Face 上逐个核对过。七个模型全部常驻时，机器占用 108GB 内存，剩余 13GB。
- 单用户 120 tok/s，八用户合计 359 tok/s，数字计入推理 token。生成图片期间，单用户对话从 122 tok/s 降到 38 tok/s。
- 文章推荐的「LiteLLM 1.84.0 或更高」会放行受影响的版本。9 月 30 日公告 GHSA-7hp6-4w63-5g45 覆盖 1.91.0 起、1.100.4 之前的版本，作者自用的 1.99.1 在其中。
背景
DGX Spark 这类本地方案，文章从数据隐私说起：很多小企业想用 AI 处理邮件、合同和发票，却不能把客户数据发给云端 API。英伟达官网把 DGX Spark 描述为用于构建和运行自主智能体的平台，内存带宽 273 GB/s，最高 1 PFLOP FP4。文章测试用的是 128GB 版。64GB 版只通过 OEM 伙伴发售，截至 10 月 19 日，英伟达官网的 64GB 页面仍写着「Coming Soon」，我们此前报道过它的发售安排（DGX Spark 64GB 版）。
n8n 另有一套自托管 AI 入门套件，面向一个人在笔记本上跑本地模型，套件用的是 Ollama。这篇教程走的是团队路线：一台机器服务整个办公室，每项任务配一个模型。文章还指出，GPU 与操作系统共用同一个内存池，Linux 报告的总量是 121GB。
事实部分
n8n 教程里，这套栈常驻的七个模型与许可证如下。许可证取自各模型在 Hugging Face 上的元数据。
| 用途 | 模型 | 许可证 |
|---|---|---|
| 对话、编程、视觉、抽取 | nvidia/Qwen3.6-35B-A3B-NVFP4 | Apache 2.0 |
| 向量嵌入 | Qwen/Qwen3-Embedding-4B | Apache 2.0 |
| 重排序 | Qwen/Qwen3-Reranker-0.6B | Apache 2.0 |
| 语音转文字 | openai/whisper-large-v3-turbo | MIT |
| 文档 OCR | zai-org/GLM-OCR | MIT |
| 图片生成 | Tongyi-MAI/Z-Image-Turbo | Apache 2.0 |
| 语音合成 | hexgrad/Kokoro-82M | Apache 2.0 |
文章的吞吐测试于 10 月 13 日进行，使用 vLLM 0.30.0，模型提交号固定，每用户速度取中位数：
| 并发用户 | 首 token 延迟（中位数） | 每用户 tok/s（中位数） | 合计 tok/s |
|---|---|---|---|
| 1 | 0.11 秒 | 120 | 87 |
| 4 | 0.21 秒 | 68 | 242 |
| 8 | 0.29 秒 | 47 | 359 |
单用户的合计低于每用户速度，是因为五次请求中有一次只跑了 43 tok/s。其他任务的耗时取三次的中位数：
| 任务 | 条件 | 耗时 |
|---|---|---|
| 语音合成 | 一段约 30 秒的语音 | 0.87 秒 |
| 语音转文字 | 同一段录音 | 0.58 秒 |
| 图片生成 | 1024×1024，8 步 | 12.2 秒 |
| 文档 OCR | 一页 | 1.80 秒 |
| 发票抽取 | 关闭 thinking | 0.59 秒 |
| 向量嵌入 | 32 段文本 | 0.18 秒 |
| 重排序 | 32 个候选 | 0.03 秒 |
图片生成默认跑约 48 步，每张约 72 秒；文章把步数设为 8，每张降到 12.2 秒。主模型冷启动到可服务，表中为 237 秒，正文另写 docker run 后 311 秒就绪。一段 8,537 token 的提示词，首 token 用了 1.14 秒。七个模型全部加载后占用 108GB，剩余 13GB。文章的冷启动表只列了六个服务，没有向量嵌入模型那一行。
价格方面，我们核对了以下报道：
| 项目 | 价格（美元） | 时间 | 来源 |
|---|---|---|---|
| 128GB 版，上市时的建议零售价 | 3,999 | 上市时 | STH、腾讯新闻 |
| 128GB 版，2026 年 2 月 | 4,699 | 2026 年 2 月 | 腾讯新闻、华尔街见闻 |
| 128GB 版，10 月 2 日报道的价格 | 6,950 | 2026 年 10 月 | The Register、STH |
| 64GB 版，OEM 渠道 | 4,999 起 | 10 月 23 日起 | STH、腾讯新闻 |
版本更正
n8n 教程第四步建议 LiteLLM 用 1.84.0 或更高版本，理由是 3 月有两个 PyPI 版本被投毒，而 1.84.0「修复了两个认证绕过」。我们核对了与这几个版本相关的公告，结论需要更正：
- 3 月的恶意版本。 公告 GHSA-5mg7-485q-xm76（3 月 25 日，critical）称，litellm 的 1.82.7 与 1.82.8 被上传到 PyPI，内含自动运行的恶意代码，会窃取环境中的凭据和文件。装过并运行过这两个版本的人，应按公告建议轮换 LiteLLM 环境里的全部凭据。1.84.0 不在这个区间。
- 4 月的两条认证绕过。 GHSA-jjhc-v7c2-5hh6 与 GHSA-69x8-hrgq-fjj8 的修复版本都是 1.83.0，不是 1.84.0。1.84.0 高于 1.83.0，这两条对它不构成问题，只是文章的归因不准。
- 9 月的提权公告。 GHSA-7hp6-4w63-5g45（9 月 30 日，critical，CVSS 9.9）描述的是通过复用盐密钥提权为代理管理员（proxy_admin）。已登录的内部用户可以借此在宿主机上执行任意命令，途径是 MCP stdio 端点。公告写明：1.91.0 之后的版本在默认配置下可被利用；1.87.0 到 1.90.x 仅在设置了 EXPERIMENTAL_UI_LOGIN=true 时可被利用。受影响区间为 1.91.0 起、1.100.4 之前，另有 1.101、1.102、1.103 与 1.104rc 各分支的区间。作者使用的 1.99.1 落在其中。
公告给的办法是升级。暂时无法升级的，可以设置 EXPERIMENTAL_UI_LOGIN=false，但公告提醒这也会让 CLI SSO 与 Claude Code 网关登录失效。各分支区间的上界是 1.100.4、1.101.3、1.102.2、1.103.1 与 1.104.0rc2，部署时应选不在上述任何区间内的版本，而不是停在 1.84.0。我们没有逐条核对 LiteLLM 的全部公告。
各方说法
几家独立测试者给出的数字，与 n8n 的数字处在同一量级，但测试条件不同，不能直接比较。
- ctala 基准页（10 月 6 日更新）测的是同一模型，vLLM 0.31.0，MTP k=2，128K 上下文。单用户 102.3 tok/s，四用户合计 240.0 tok/s，占用约 56GB。四用户合计与 n8n 的 242 tok/s 很接近。
- LLMRequirements（6 月 3 日）测得单路请求平均 97.4 tok/s；八路并发合计约 322 tok/s，测的是解码阶段，并启用了前缀缓存。
- SMF Clearinghouse（7 月 5 日）在图片、视频等多类任务的测试集上平均 107.3 tok/s。它的启动命令关闭了 thinking，以便与其他模型对齐。n8n 的数字包含推理 token，两者口径不同。
反方的声音也有。Devashish 的博客（7 月 7 日）写道，作者早先试过 35B-A3B，认为它「不是推理模型」，「在这些任务上失败了」，之后改用 27B 模型。这是一位用户的个人经验，没有公开的测试集，对模型的描述也与 n8n 文中计入推理 token 的做法不一致，我们无法判断谁对。Tom’s Hardware 9 月 21 日的 Mac Studio M5 Ultra 评测称，其吞吐在各项测试中约为 DGX Spark 的近四倍。评测只给了倍数，没有 DGX Spark 的绝对值，测的又是稠密模型，无法换算成 n8n 的数字。
编辑判断
这篇教程最值得搬走的是它的做法：把模型锁定到 Hugging Face 提交号，只允许一份短名单上的许可证，给每个团队发独立的 LiteLLM 虚拟密钥，并用一个真实工作流做端到端测试。这些习惯比任何一个吞吐数字都更容易用到自己的团队里。
数字要打折扣。它们来自作者一次测试，并计入了推理 token。抽取步骤只在一张干净的单页发票上验证过，作者自己也写明，扫描件或拍照件要另外测。
有一处是我们的推断，需要标明：文中整套七模型栈占用 108GB，而 64GB 版只有 64GB 内存，所以它装不下这套配置。这是按文中数字做的判断，我们没有实测。
生图的取舍最明显。图片与对话共用同一块 GPU，所以单用户对话在生图时掉到 38 tok/s。小团队可以排队生图，或把生图放到下班后。文章也建议，图片成为日常工作后，把媒体任务移到第二台机器。
价格是另一个变量。上表显示，128GB 版从 3,999 美元涨到 6,950 美元。The Register 把涨价归因于内存价格。内存紧缺的背景见 内存紧缺延续到 2028。两家中文媒体提到 2026 年 2 月的 4,699 美元那一步，其中华尔街见闻只是转述「媒体指出」。我们读到的两份英文报道（The Register、ServeTheHome）都没有提，因此没有独立确认。
怎么试
没有 DGX Spark 的团队，文章建议先从自托管 AI 入门套件开始。已经有机器的，可以先做三件事：
- 查看镜像里的 vLLM 版本。文章给的命令是
docker run --rm --entrypoint python3 <image> -c "import vllm; print(vllm.__version__)"。作者第一次用的 nightly 镜像里是 vLLM 0.19，加载不了 Qwen3.6，报错信息看起来像权重文件坏了。 - 对照上一节检查 LiteLLM 版本，不要停在「1.84.0 或更高」。
- 导入文章提供的发票识别工作流模板。它共六个节点，其中 OCR 与 Qwen3.6 抽取两步，抽取那一步关闭了 thinking。作者的单页样本中，抽取耗时从 12.1 秒降到 0.59 秒。