Experimental dual-DGX Spark + DeepSeek-V4-Flash + n8n + Hermes stack

This is a plausible lab architecture after buying a second DGX Spark: local inference for a large model, automation that talks to business systems, and an agent runtime. It is not a supported turnkey stack.

The defensible version is narrower. You are evaluating four layers that must stay separable:

1. Fabric: two Sparks linked for distributed inference (NVIDIA clustering docs, connect-two-sparks playbook).
2. Experimental model server: a community-built OpenAI-compatible path for DeepSeek-V4-Flash (or the DSpark speculative-decoding variant) across both nodes.
3. Deterministic automation: n8n for webhooks, schedules, CRM/email/Slack side effects, validation, and human gates.
4. Judgment runtime: Hermes Agent for triage, drafting, investigation, and tool use that needs memory and multi-step reasoning (official API-server documentation, official webhook documentation).

The n8n-to-Hermes composition in this article is an illustrative integration, not a turnkey path documented or supported by either vendor. For a workflow that needs the agent result back in n8n, use Hermes’ bearer-authenticated API server. Hermes’ HMAC webhook adapter is a different event-ingress surface: it triggers an agent and delivers the result to a configured target rather than defining a general synchronous return contract for n8n.

Optional fifth layer: OpenClaw for chat-channel UX (Telegram, Slack, …), optionally launched through NemoClaw and OpenShell when you want sandbox policies. NemoClaw is currently an alpha, early-preview project rather than production-ready software. Neither layer is required for the three workflows below.

Do not auto-send customer email, file legal documents, change production infrastructure, or pay money from an agent loop. Route irreversible actions through a human approval node until you have logs, idempotency, and enough reviewed runs to trust the path.

What DeepSeek-V4-Flash changes on two Sparks

DeepSeek-V4-Flash is a Mixture-of-Experts model with 284B total parameters and 13B activated, and a 1M-token context window on the official model card. Instruct weights use FP4 for routed experts and FP8 elsewhere. That combination matters on Spark because:

• Activated parameter count stays manageable for decode cost relative to dense models of similar “headline” size.
• Long context is useful for agent workloads such as repository slices, ticket histories, and policy packs, provided you retrieve the right material and still verify claims.
• The DSpark checkpoint is the same model with a speculative-decoding module attached. Its official model-card example uses one four-GPU GB300 node, not two Sparks; the community vLLM report discussed below uses the non-DSpark checkpoint on two GB10 systems.

Treat published tokens/sec and maximum-context results as recipe-specific reports, not guarantees for your cable, driver, container, or concurrency settings. The official model cards do not document a validated dual-Spark deployment; the DSpark example uses one four-GPU GB300 node. As re-checked 2026-08-10, open vLLM issue #40969 reports a hang after the sixth or seventh request on two GB10 systems for one pinned vLLM build with FULL_AND_PIECEWISE CUDA graphs, chunked prefill, Marlin MoE, FP8 KV cache, and TP=2. It is evidence about that configuration, not every deployment. Adopt this path only as a pinned experiment with a rollback model.

Reference architecture

                    ┌─────────────────────────────┐
   Forms/CRM/Git ──►│ n8n (validate, branch, HITL) │──► Slack / CRM / email
                    └──────────────┬──────────────┘
                                   │ HTTPS + bearer auth
                                   ▼
                    ┌─────────────────────────────┐
                    │ Hermes (memory, tools, draft)│
                    └──────────────┬──────────────┘
                                   │ OpenAI-compatible /v1
                                   ▼
              ┌────────────────────────────────────────┐
              │ Spark A ◄── QSFP / RoCE ──► Spark B    │
              │ experimental community TP=2 model path │
              └────────────────────────────────────────┘

Design rules that keep this from becoming a demo:

Point Hermes (and n8n AI nodes, if you use them) at the cluster endpoint as a normal OpenAI-compatible base URL. Keep API keys on the LAN/VPN; do not put the vLLM port on the public internet.

Bring-up checklist (order matters)

1. Dual-Spark fabric

Follow NVIDIA’s playbook, not folklore:

• Same username on both nodes.
• One QSFP cable between matching ConnectX-7 ports. NVIDIA’s playbook states that full bandwidth is achievable with one cable, and documents no throughput gain from a second cable between the same two systems.
• Dedicated L3 addressing / netplan for the high-speed path; keep 10 GbE or Wi-Fi for management and internet.
• Passwordless SSH between nodes.
• Confirm interfaces show Up (ibdev2netdev / NVIDIA steps) before chasing NCCL errors.

NVIDIA Sync’s Cluster Assistant can configure ConnectX-7 and SSH for supported topologies; it does not install your inference stack for you.

2. Model server

• Select a named community recipe that pins the container/build, CUDA stack, vLLM patches, launch commands, and known limitations. Do not assemble a production command from fragments in this article.
• Verify that the recipe explicitly supports your two GB10 nodes and the exact DeepSeek-V4-Flash checkpoint. Tensor parallel size 2 is a hypothesis to test here, not an official support promise.
• Expose /v1/models and /v1/chat/completions on a private interface only.
• Record: max context you actually configure, max concurrent sequences, KV dtype, and whether speculative decoding is enabled.
• Current Hermes documentation requires a configured model context of at least 64K tokens. A lower-context serving profile does not establish compatibility with current Hermes; configure and soak-test a 64K-or-larger profile before connecting it.

Smoke-test short, long, repeated, and concurrent prompts before wiring agents. The reported dual-Spark failure appears after multiple requests, so a single “hello” proves almost nothing. This path is not production-ready until a pinned soak test passes on your hardware.

3. Hermes

• Install from the official Hermes quickstart and configure its model provider to the private OpenAI-compatible base URL.
• For the request-response workflows below, enable the API server, set a strong API_SERVER_KEY, keep it on a private interface, and verify GET /health (default documented port 8642). Use /v1/responses for a direct result or /v1/runs plus status polling for a long job.
• If your use case is event ingress with delivery elsewhere, use the separate webhook adapter: named routes, V2 timestamped HMAC, request IDs for deduplication, and the default port 8644. Do not mistake its acknowledgement for the agent’s output.
• Deny broad shell until you have an allowlist and a human watching logs. The API key authorizes access to the agent’s tools, not only to model text.

On DGX Spark, NemoClaw can run Hermes inside OpenShell with filesystem/network/process policies. Treat it as an alpha evaluation path, not a production security guarantee.

4. n8n

• Self-host on the same trusted network (or VPN). Prefer the patterns in n8n local OpenAI-compatible endpoints and idempotency and human gates.
• For the request-response Hermes handoff used below, configure n8n’s official HTTP Request node with bearer credentials and explicit timeouts. Keep the durable business idempotency record in n8n or the business system. Hermes’ API server supports Idempotency-Key response caching for five minutes, but that bounded transport-level window does not replace durable workflow deduplication. If you deliberately choose the separate Hermes webhook path, n8n’s Crypto node can produce the HMAC, but the signed bytes and V2 timestamp headers must exactly follow the Hermes webhook contract. The n8n ↔ Hermes webhook handoff is an illustrative design, not an official vendor integration.

Three candidate evaluation workloads

Use case A: Private support triage

Problem: Tickets contain customer text you do not want in a public model provider. Triage still needs judgment: severity, product area, duplicate detection, draft reply.

Flow:

1. Helpdesk webhook → n8n.
2. n8n validates schema, strips secrets (tokens, raw card numbers), deduplicates by ticket id.
3. n8n records a workflow-level idempotency key, then sends a minimal payload to the private Hermes API server under a narrow, versioned support-triage prompt contract with bearer authentication.
4. Hermes calls local DeepSeek-V4-Flash and returns a response. n8n parses and schema-validates the requested {severity, product, confidence, draft, needs_human} object; malformed or incomplete output goes to human review.
5. n8n branches: low confidence or needs_human → Slack approval; high confidence + allowlisted actions → update ticket fields only (still no auto-send until you graduate).

Hypothesis to test: n8n connectors and a Hermes API call may support this flow. The model endpoint remains on the private network, but outbound tools and SaaS connectors still cross that boundary and need egress controls. Evaluate whether added context improves the result; still verify the draft.

Do not: Let Hermes open arbitrary URLs from ticket text without a proxy allowlist (prompt injection).

Use case B: Long-context internal research assistant

Problem: Lawyers, ops, or eng leads need “read these 40 PDFs / this monorepo slice and produce a structured brief” without uploading the corpus to a SaaS LLM.

Flow:

1. Human drops a job folder (or n8n watches a secure inbox).
2. n8n packages metadata + retrieval hits (or Hermes tools read from an allowlisted path / RAG index).
3. Hermes runs a multi-step research prompt against DeepSeek-V4-Flash with an explicit citation schema.
4. n8n validates the response shape and places it in a review queue. Require a source path and span for every claim; humans accept or reject.

Why V4-Flash: Official 1M context and efficient long-context attention are the point, but context window ≠ accuracy. Retrieval quality and citation checks matter more than max tokens.

Do not: Auto-file regulatory reports or medical summaries. Literacy and drafting only; licensed humans sign.

Use case C: Always-on ops investigation with a chat front door

Problem: On-call wants “watch these alerts, investigate with logs, propose a runbook step” and a Telegram/Slack way to ask follow-ups without giving the model root on the fleet.

Flow:

1. n8n schedule / PagerDuty webhook collects alert fingerprints.
2. Hermes investigates using read-only tools (log query API, status endpoints) via allowlisted credentials.
3. Hermes returns: hypothesis, evidence, suggested next command (not executed).
4. Optional OpenClaw/NemoClaw channel for an on-call human to interrogate a separately configured agent runtime, with pairing allowlists (OpenClaw security basics). Do not assume OpenClaw and Hermes share a session or memory store.

Two-Spark hypothesis: concurrent investigations or a larger model/context may justify the second node. Compare with one Spark and managed inference using measured queue, quality, latency, total cost, and privacy requirements.

Do not: Auto-remediate. Suggested commands go to a human or to a tightly scoped runbook executor with its own auth.

Failure modes you should design for on day one

What “done” looks like

You can claim only the tested scope works when:

1. A pinned dual-Spark build passes repeated and concurrent soak tests, including the failure shape reported upstream; record the exact run count, context sizes, and error rate.
2. n8n → Hermes → model path is authenticated end-to-end and logged; n8n validates the returned application schema.
3. At least one named workflow runs with human approval on every external message and passes its predefined evaluation set.
4. You have a written rollback: disable the n8n-to-Hermes call, fall back to n8n-only templates, or point Hermes at a smaller local model.

Exercise

Pick use case A. Implement only: webhook validation in n8n, one versioned prompt contract through the bearer-authenticated Hermes API server, a workflow-level idempotency record, a local model call, response-schema validation, and a draft preview. Do not connect send-email. Use a representative, approved evaluation set large enough to include normal and rare cases; predefine severity agreement, unsupported-claim, edit, latency, and failure criteria. Decide from that evidence whether a second Spark or V4-Flash is justified.

Further reading

• DGX Spark: what it is
• Connect two DGX Sparks
• NemoClaw sandboxed agents on Spark
• Hermes vs n8n
• n8n ↔ Hermes webhook handoff
• Official: DeepSeek-V4-Flash model card, DeepSeek-V4-Flash-DSpark model card, Hermes API server, Hermes webhooks, n8n HTTP Request node, NVIDIA Spark clustering