JSPARK3

I wanted an AI assistant I could run on my own hardware and use every day. Getting that working across three DGX Sparks took me from following other people’s setup guides to comparing models, changing how they run, and publishing a recipe of my own.

What the names mean. JSPARK is the broader project. The 3 in JSPARK3 tells you how many Sparks the recipe uses. The version tells you which release I am using on that hardware. JSPARK3 v1 ran GLM-5.3 Flash, and v1.1 was called Cadence. JSPARK3 v2 is Tempo, built around DeepSeek-V4.1 Flash. Tempo is the name of my serving recipe; the underlying model is still DeepSeek. A new major version marks a change in my daily driver, while smaller revisions improve that release. I want the project to stay open to whichever model works best. If another model earns that spot, a future version can use it. If I eventually move to four Sparks, that hardware family becomes JSPARK4. For now, I have three.

The project became an education in machine learning. Every bottleneck pushed me further into how these models work. Fitting a large model into the available memory meant learning about quantization: storing the model’s numerical weights with fewer bits, and understanding the tradeoffs in memory, speed, and answer quality. Using all three machines meant learning about tensor parallelism, where the computers share the work of running one model, and why communication between them can become a bottleneck of its own. Long waits before an answer sent me into prefill and caching: the work a model does to process a prompt, and the intermediate results it can reuse on the next request. These became practical questions I could investigate through code, research, and experiments. I began looking at each result in terms of memory, computation, and communication, then testing which of those was actually limiting the system.

One place to find the current version. The project hub at jakejh.com/jspark3 points to the current daily driver and keeps the earlier releases accessible. Each release page links to its own setup guide, source, and benchmarks. The original GLM/Cadence release remains on GitHub and Hugging Face. Those are also the historical repository links listed below this post. For Tempo, start at the hub and choose the current release. Its Hugging Face page hosts the recipe, and the included scripts download the pinned upstream weights and verify their hashes.

What I can realistically maintain. I am largely moving forward with JSPARK3 v2. I do not have the bandwidth right now to actively maintain a large collection of models and serving stacks. My focus will be the best available model I can get working well on three Sparks, and that choice will be the latest JSPARK3 version. Older releases will remain available with their instructions, pinned versions, and recorded results. I am not promising to keep every old recipe current with every upstream change or to backport each improvement. GLM and Cadence are part of the project’s history; DeepSeek and Tempo are where my day-to-day attention is now. Someone else may prefer an older release for their work. Keeping it available lets them make that choice without turning every past experiment into an ongoing maintenance commitment.

Learning how to test an idea. The deeper lesson was experimental discipline. A faster second run might mean a useful cache, warmed-up kernels, or simply a different answer. Comparing two recipes means checking what each benchmark counts, how long the output is, and whether the request starts with reusable state. I used coding agents to help investigate implementations and build experiments, while keeping track of the changes, measurements, and failed attempts. Our tests grew to include repeated prompts, long conversations, and timed tasks in Pi, the coding-agent interface I use. That gave me a much better basis for deciding what to try next. The project has become a practical way to study AI inference: read the research and implementation, form a hypothesis, measure it, and revise the idea when the evidence disagrees. It has also made me more careful about what I claim. Each JSPARK release should show enough of that work for someone else to understand why I chose it, reproduce it, and improve on it.