A two-Spark operating recipe comes with a patched runtime
This GLM-5.3-Flash repository coordinates a local language-model service across paired NVIDIA DGX Sparks. Its scripts prepare the machines, start a TensorFold rank on each, and expose a model API from the head system. You get a specific combination of model weights, runtime patches, and settings. Adopting it means owning that combination, including the network link and shared-memory decisions that a hosted endpoint hides.
Our checkout contained 168 files, roughly 8,197 source lines, and 3.9 MB of repository data. Those modest dimensions bear little relationship to a usable inference deployment. The README requires dedicated GB10 hardware, a direct ConnectX-7 connection, and NVIDIA's container runtime. Treat this as a recipe for hardware you already know how to operate before considering it as a reason to buy that hardware.
What happened when we ran it
Our sandbox installed commit 3fd60df in 14 seconds and completed the build in 1 second. Installation added 35 packages and occupied 37 MB. The October 16, 2026 run used an unprivileged Debian container with 3 CPUs, 8 GB of RAM, Python 3.12, and no secrets. Pip-audit reported 0 known vulnerabilities. These are repository-environment results, with no inference-throughput or model-quality measurement.
Pytest failed with exit 3 after 3 seconds, reporting 0 passed and 0 failed because no tests ran. The supplied tail follows Python's argparse error and exit methods to SystemExit: 2. It also prints that no tests ran. That proves the test command did not reach an executed suite. It does not identify the offending argument, script, or configuration, so blaming a particular import or missing system package would exceed the log.
The scan found one CI workflow, no Dockerfile, and a tests directory. Our 1-second build should not be confused with preparing NVIDIA containers, loading the checkpoint, or establishing communication between real Sparks. The README's preparation scripts handle a different deployment path. A hardware qualification must check both ranks, real requests, and recovery after a stalled or interrupted workload.
SSH and the fabric link need configuration before serving
The requirements specify key-based SSH from the head to the worker, Docker with NVIDIA runtime, and rsync. The ConnectX-7 addresses must be reachable over the intended direct link. WORKER identifies the SSH destination, while FABRIC_PEER handles the worker's fabric address when management traffic follows another route. A reachable SSH service alone does not establish a working inference transport.
The 37 MB environment from our sandbox excludes model weights and the serving image. Public checkpoint access and the optional gated Ablit path also have different credential requirements. The latter requires a Hugging Face token with access after terms acceptance. Pin the checkpoint and runtime revisions as the README describes, and preserve both ranks' logs when troubleshooting. Otherwise, a container or model change can obscure which combination produced the problem.
Precision and cached conversations compete for memory
The README defaults to quantized dense weights and an FP8 cache. It explicitly warns that this trades numerical fidelity for memory capacity and throughput. A larger context window is useful only if your actual task remains reliable at those settings. Raising precision changes the capacity available for prompts and concurrent conversations, so the settings deserve a workload decision rather than acceptance by default.
Our 8 GB CPU sandbox cannot settle those choices. The recipe manages a shared cache for active requests and retained prompt states, with optional disk spill. Issue 163 describes both ranks stalling during prompt processing on a two-Spark configuration. That is a community report about the relevant deployment path, separate from our pytest failure. Validate cancellation, cache reuse, and recovery under the traffic you intend to serve.
DFlash2 has separate terms, and API compatibility has limits
The license section identifies the default DFlash2 drafter as non-commercial. The repository's Apache license does not remove those separate model terms. The documented DRAFTER=mtp option avoids downloading DFlash2 when selected before setup, but changes the concurrency configuration. An operator needs to choose a permitted drafter before treating the default recipe as suitable for a business service.
TensorFold v0.6.0 is the base identified in the recipe, with project patches layered over it. Familiar API names also have boundaries: the README says log probabilities are refused, while several penalties are accepted and ignored. Clients expecting those controls can receive an answer without receiving the requested behavior. Check your client payloads and response handling explicitly, especially before attributing an output difference to model quality.
October issue traffic shows active work and unresolved reports
The last push was October 17, 2026. GitHub showed 446 stars and 64 open issues and PRs, including current operating reports and proposed changes. The latest-release endpoint returned no release, which says little about abandonment beside that recent push and discussion. Upstream TensorFold and this recipe also move separately, so newer upstream capabilities should not be assumed to exist in the pinned stack.
Our run's 0 executed tests leaves a clear limit on the recommendation. Try upstream TensorFold when evaluating its current engine is the goal, or llama.cpp with a supported model when broader hardware choice matters. Use this recipe when reproducing the paired-Spark GLM service is the job. Require the real machines to complete your representative conversation and recover cleanly before you make the endpoint someone else's dependency.