NVIDIA DGX Spark 部署地端 AI 工作流程：n8n 整合，兼顧效能與資料隱私

大多數小型企業對 AI 的需求都集中在幾個核心任務上，例如撰寫電子郵件、總結通話內容、閱讀發票、搜尋內部文件以及生成圖片。然而，許多企業無法將客戶資料傳送至雲端 API 進行處理。

這通常是出於資料隱私和主權的考量。診所、律師事務所或會計師可能持有受合約、法規或專業職責要求必須自行控制的記錄。一旦這些資料傳送到雲端 API，它們就會存放在他人的硬體上，甚至可能位於其他司法管轄區，並受供應商可能隨時更改的條款約束。在您自己的硬體上運行模型，能將資料保留在您的辦公室內，並讓您能夠向稽核人員精確展示資料流向。

您的 n8n 工作流程可以在不將任何位元組傳送到雲端 API 的情況下，轉錄通話、閱讀發票、回答來自您文件的問題並起草回覆。本文將展示如何從一台 NVIDIA DGX Spark 伺服器提供這些工作流程所需的所有模型，並透過一個與 OpenAI 相容的端點，讓 n8n 的 OpenAI 節點能夠直接連接。

DGX Spark 擁有 128GB 的統一記憶體，由 CPU 和 GPU 共享。如果選擇合適的模型，這足以同時載入所有這些任務。本文的大部分內容都將圍繞這一點展開。自託管 AI 入門套件讓個人能在筆記型電腦上運行本地模型，而這篇文章則更進一步：在辦公室放置一台伺服器，為整個團隊提供服務，每個任務都有專屬模型和運行程式碼。

在本文中，您將學習如何選擇能在 DGX Spark 記憶體頻寬上快速運行的模型，並使用 vLLM 在 NVFP4 格式下運行一個 35B 混合專家模型。您還會了解如何將完整的 AI 堆疊整合到一台伺服器的共享記憶體中，並透過 LiteLLM 端點路由每個任務，支援每個團隊的專屬金鑰。

最後，您將學習如何將 n8n 連接到此堆疊並建立一個無需呼叫雲端 API 的工作流程，並測量在生成圖片時聊天速度的變化。

DGX Spark 的 GB10 Grace Blackwell Superchip 以 273 GB/s 的速度讀取記憶體。當模型生成文字時，它會為每個 token 從記憶體中讀取其活躍權重，因此讀取的位元組越少，運行速度就越快。

混合專家（MoE）模型每個 token 只會啟動少數專家。Qwen3.6-35B-A3B 總共有 35B 參數，但活躍參數約為 3B。以 NVFP4（NVIDIA 的 4 位元浮點格式）儲存時，這些活躍權重僅佔密集模型的一小部分。在我的 DGX Spark 上，Qwen3.6-35B-A3B 為一個使用者每秒生成 120 個 token，在八個使用者之間總共每秒生成 359 個 token。這些數字包括模型在回答之前所寫的推理 token。

這就引出了第一個設計原則：一個強大的 MoE 模型可以處理所有文字相關任務。摘要、分類、提取、起草、編碼和閱讀螢幕截圖都交給同一個模型。每個額外的模型都意味著需要額外的容器來固定、修補和監控，因此只有當大型語言模型（LLM）無法完成任務時，才會考慮使用專業模型。

以下是保持載入在 DGX Spark 上的模型堆疊：用於聊天、編碼、視覺和提取的是 nvidia/Qwen3.6-35B-A3B-NVFP4 模型；用於嵌入（Embeddings）的是 Qwen/Qwen3-Embedding-4B；用於重新排序（Reranking）的是 Qwen/Qwen3-Reranker-0.6B；語音轉文字（Speech to text）使用 openai/whisper-large-v3-turbo；文件光學字元辨識（Document OCR）使用 zai-org/GLM-OCR；圖片生成（Image generation）使用 Tongyi-MAI/Z-Image-Turbo；文字轉語音（Text to speech）使用 hexgrad/Kokoro-82M。

堆疊中的每個模型都允許商業使用，這項規則比任何技術規則都更具挑戰性，稍後會有專門章節討論。

第一步是快取所有內容以供離線使用。堆疊必須在網路線拔掉的情況下運行，因此請下載每個模型一次並記錄您獲得的確切提交版本。這個迴圈會快取每個模型並寫入一個包含儲存庫和提交版本的鎖定檔案。當您啟動模型時，請傳遞 ，revision 參數，並帶上 models.lock 中的提交版本。

這樣 vLLM 就會提供您測試過的權重，而不是 main 目前指向的任何版本，從而避免上游變更導致權重或授權條款在您不知情的情況下被替換。

請檢查 vLLM 版本，而不是標籤。以相同方式固定容器，並檢查其內容。我第一次嘗試使用了 vLLM 的 cu130-nightly 標籤，但該標籤已停止更新，拉取的映像檔已有五個月之久，使用的是 vLLM 0.19 版本。它根本無法載入 Qwen3.6。

錯誤訊息沒有提及版本，而是顯示一個關於缺少 weight-scale 參數的 KeyError，這看起來像是損壞的檢查點。在信任映像檔之前，請先列印其中的 vLLM 版本。運作正常的映像檔是官方的 vllm/vllm-omni:v0.30.0，它搭載 vLLM 0.30.0 並支援 arm64 架構。

vLLM-Omni 是一個完整的 vLLM 版本，具有額外的圖片和語音服務模式，因此它也可以服務普通的 LLM。其預設的進入點不是 vllm serve，因此需要額外包裝一次。Kokoro-FastAPI 映像檔需要社群修復才能在 arm64 上建置，其 Dockerfile 來自 NVIDIA 開發者論壇上 swann.schilling 的文章。

第二步是啟動核心模型。這個指令會在 vLLM 中啟動主模型。在我的 DGX Spark 上，這個模型在 docker run 執行 311 秒後即可提供服務。連接埠發布在 172.17.0.1，這是 Docker 的橋接位址，因此只有這台機器上的容器才能訪問它。VLLM_API_KEY 會讓 vLLM 拒絕任何沒有金鑰的請求。

在 DGX Spark 上最重要的旗標是 ，gpu-memory-utilization 0.32，它將此模型的記憶體使用量限制在大約三分之一。其他模型需要其餘的記憶體。，kv-cache-dtype fp8 將 KV 快取所需的記憶體減半，因此相同的預算可以容納更多的上下文。

，moe-backend marlin 選擇了量化專家層的核心。草稿模型的專家未經量化，因此 ，speculative-config 設定了自己的 moe_backend。，speculative-config 啟用多 token 預測（MTP）。

模型會預先草擬三個 token，並一次性檢查它們。，reasoning-parser 和 ，tool-call-parser 必須與模型系列匹配。當工具呼叫失敗時，請在歸咎於模型之前檢查這些旗標。

檢查啟動日誌以了解 vLLM 選擇的核心。我的運行中出現了這些行：「Using MarlinNvFp4LinearKernel for NVFP4 GEMM」、「Using 'MARLIN' NvFp4 MoE backend out of potential backends: ['FLASHINFER_TRTLLM', 'FLASHINFER_CUTEDSL', ...]」。

最後一個警告對於您如何在 DGX Spark 上解讀「NVFP4」很重要。使用此 vLLM 建置，權重以 4 位元儲存，但計算以 16 位元運行。您仍然可以獲得大部分好處，因為生成 token 受限於從記憶體讀取權重，而 4 位元權重只有四分之一的大小。適用於 GB10 的更快 FP4 核心可能會在以後的版本中提高這些數字。

在 DGX Spark 上，GPU 和作業系統共享一個 128GB 的記憶體池。我的機器上 Linux 報告總記憶體為 121GB。這改變了您在獨立 GPU 上可能認為理所當然的兩件事。首先，，gpu-memory-utilization 是整個記憶體池的一部分，在啟動時佔用，而不是可用記憶體的一部分。

一個沒有上限的實例會嘗試佔用幾乎所有記憶體，導致下一個模型無法啟動。其次，vLLM 會根據啟動時的可用記憶體來調整其快取大小。同時啟動兩個模型，它們會爭奪相同的記憶體。因此，請一次啟動一個模型，並等待每個模型回應其健康檢查後再啟動下一個。

如果模型因「CUDA error: out of memory」而失敗，但 free 指令顯示有大量可用記憶體，則表示 Linux 頁面快取正在佔用它。這在下載 220GB 權重後很常見。請先清除快取，然後再次啟動模型。以下是每個服務從冷啟動到準備就緒所需的時間，並先清除了頁面快取，以及它佔用的記憶體量：qwen3.6 需要 237 秒和 43GB；rerank 需要 106 秒和 8GB；whisper 需要 136 秒和 8GB；ocr 需要 137 秒和 11GB；image 需要 96 秒和 20GB；tts 需要 21 秒和 3GB。

嵌入模型在 vLLM 0.30.0 上需要額外一個 ，convert embed 旗標，並在其他模型之後啟動。載入所有七個模型後，DGX Spark 使用了 108GB，還有 13GB 可用。這是一個 DGX Spark 所能容納的極限。請在任何人需要使用之前就啟動堆疊：表格中的六個服務大約需要 12 分鐘。

vLLM 也可能在啟動時因「Error in memory profiling」而失敗，這發生在 vLLM 測量可用記憶體時，另一個程序釋放記憶體。在共享記憶體上，如果另一個模型正在載入或關閉，就會發生這種情況。請在伺服器安靜下來後再次啟動模型。

第四步是設置一個統一端點。LiteLLM 為每個客戶端提供一個與 OpenAI 相容的端點。每個任務都是一個命名的路由，因此您可以在不更改任何客戶端的情況下替換路由背後的模型。LiteLLM 的開源版本也支援虛擬金鑰、團隊和預算。LiteLLM 的 config.yaml 中的每個路由都指向一個後端。

以下摘錄顯示了其中三個：主模型 qwen3.6 用於聊天、編碼、視覺和提取；whisper 用於語音轉文字；image 用於圖片生成。

請保持 drop_params: true。如果沒有它，LiteLLM 會拒絕任何設定 response_format 的圖片請求，並返回 400 錯誤，因為它沒有為自託管圖片模型映射該欄位。有了它，LiteLLM 會丟棄該欄位，而 vLLM-Omni 無論如何都會以 base64 格式返回圖片。

LiteLLM 也運行在 Docker 中。為了讓它能夠訪問後端，請在其 Compose 服務中將 host.docker.internal 映射到主機。後端只監聽 Docker 的橋接網路並需要共享金鑰，因此 LiteLLM 是辦公室網路上的唯一服務。

將 LiteLLM 指向橋接網路，而不是伺服器的區域網路位址。如果您使用區域網路位址，後端會拒絕連接，因為它們沒有在那裡監聽。

請透過映像檔摘要固定 LiteLLM，並使用 1.84.0 或更高版本。2026 年 3 月，兩個 PyPI 版本被植入後門，而 1.84.0 修正了兩個身份驗證繞過漏洞。我運行的是 1.99.1 版本。現在，任何 OpenAI 客戶端都可以針對 DGX Spark 運行。這個 Python 範例呼叫了三個不同的模型。