Last Updated: 2026-10-23
A single NVIDIA DGX Spark can now run a complete local AI assistant, covering chat, speech, image and video, with a measured voice response of about 0.9 seconds. The project that does it, LocalRouter, is Apache 2.0 open source. The models it routes are not: their licences cap revenue, exclude territories and forbid hosted use, and those licence terms, not the hardware, decide what a business is allowed to ship.
What LocalRouter actually is
LocalRouter is a router and scheduler that turns one DGX Spark into a self-contained voice assistant: you speak, it answers, and it can also generate images and video on demand, all on the box. It is one small open-source program, released on GitHub on 8 October 2026 under the Apache 2.0 licence [1], that keeps a chat model and a voice loop permanently warm and loads the other models when a request needs them.
The five models sharing the machine are a 27B chat model (Qwen3.8), a streamed text-to-speech model (Fish Audio's Drama 3), Whisper large-v3-turbo for hearing, Qwen-Image 2.1 Turbo for pictures, and MiniMax H3 for short video with audio. Every tool is exposed over one MCP endpoint, so an existing agent can call speech, vision or video the way it would call any other function. That single-door design matters more than the modality list: it means the assistant is not a demo you talk at, it is infrastructure your software can use.
Consider the difference it makes to an owner comparing this with a cloud assistant. A cloud route sends every customer utterance to someone else's servers, under someone else's data terms, billed per token. This route keeps the audio, the images and the transcript inside a machine the business owns. The trade is real: the box costs real money up front, and the tested profile is narrow, which the next section quantifies.
What the repository actually measures
The project publishes its own instrumented numbers rather than announcement claims, and the headline one is the voice turn: from the end of your speech to the first audio of the reply, about 0.9 seconds median, with individual smoke runs landing between 916 and 959 milliseconds [1]. Those figures are dated 22 October 2026 on the project's own measured table, taken on the machine it calls DGX-01.
Walk through what that loop has to do, because the number is only believable once the work is visible. You finish speaking. A voice-activity gate closes your turn. Whisper transcribes it, the chat model produces a first token, and the speech model starts streaming audio for the first clause while the rest is still being written. Four stages, each of which could take a second on its own, completing in under one. That is why an interruption mid-sentence works: the loop is streaming in both directions rather than taking turns.
The rest of the measured table sets expectations for everything slower. A spoken picture request lands a finished 1024 by 1024 image in 6.3 seconds warm, with the project's own confirmation timing of 8.8 to 11.4 seconds from the end of speech. A one-second video clip takes about 24 seconds to generate; a five-second clip takes 54 seconds warm. None of that is conversational speed, and none of it needs to be: the point is that image and video generation are now a function call on the same box as the assistant.
Even getting there is measured. A fresh install took 31.5 minutes and downloaded 175.7 GB, according to the project's install log of 22 October 2026 [1]. That is a real but ordinary half-day task for someone comfortable following a documented sequence, not a research project.
The memory scheduler doing the real work
The quiet engineering achievement is that five large models coexist on one 121.7 GiB pool of unified memory, and the scheduler is what makes it safe rather than lucky. The project's memory budget [1] lists 24 GiB for chat, 42 GiB for the speech model, 3.6 GiB for Whisper and 35.2 GiB for the image model, leaving 13.7 GiB spare on the 121.7 GiB the box exposes after a full start.
The rules are simple enough to state and strict enough to matter. The image and video models never run at the same time, because each wants roughly the same large slice of memory. A video job unloads only the image model, and the chat, speech and hearing models are never evicted for a generation job, so conversation never stalls because someone asked for a picture. Each loaded model is its own process, so when one is unloaded, every byte it held comes back; a crash costs one job rather than the machine.
An owner does not need to reproduce this design, but the pattern is worth naming because it generalises: one component with a small, explicit budget deciding which expensive resource gets used next, instead of every component grabbing what it wants. The same discipline applies to attention, spend and staff time, and it is the difference between a stack that survives contact with a real business and one that works in the video.
The licence trap: open router, restricted models
Here is the part that decides whether a business can ship anything built on this, and it is not in the hardware specification. The LocalRouter program itself is Apache 2.0, which places almost no restrictions on commercial use. The models it loads carry three different, much tighter licences, each verified from the licence text itself.
The speech licence: a revenue ceiling and a hosted-service ban
The Fish Audio Community License [2], which governs the Drama 3 speech model, permits free commercial use only while your annual revenue, aggregated across you and your affiliates, stays below USD 500,000. Cross that line and continued commercial use requires a separate written licence. Independently of revenue, no licence at all is granted for offering the model as a hosted service, so a business cannot legally wrap it in a customer-facing API without negotiating one.
The video licence: territory, not revenue
The MiniMax H3 Community License [3], which governs the video model, draws its boundary by geography rather than revenue. Its applicable territory expressly excludes the European Union, the United Kingdom, the Republic of Korea and the United States. For those territories the licence offers a contact address rather than a grant, and beyond territory, commercial products generating more than USD 20 million in yearly revenue need prior written authorisation. A business operating in Britain is outside the permitted territory for the video model on day one, before revenue ever becomes relevant.
The image model's terms are the third shape: the project's own repository states its Qwen-Image packs are for non-commercial research or evaluation only under the Qwen Research License. So of the five models on the box, the router is open, the chat model's engine is Apache 2.0, and speech, video and image each carry a restriction that binds a growing business at a different point: revenue, geography, or purpose.
Model role | Governing restriction | What triggers it |
|---|---|---|
Router itself | Apache 2.0 | Effectively none |
Speech (Drama 3) | Revenue threshold, USD 500,000 per year | Growing past it; any hosted-service offering |
Video (MiniMax H3) | Territory: EU, UK, Korea, US excluded | Operating in an excluded territory; over USD 20 million yearly revenue |
Image (Qwen-Image packs) | Non-commercial research or evaluation only | Any commercial use at all |
What it is not for
LocalRouter is a single-operator machine, tested on exactly one hardware profile, and the repository says so plainly: no other profile is tested yet, and the chat and speech engines are GB10 builds whose qualification refuses other GPUs [1]. It is not a product platform. A business cannot legally resell the speech model as a hosted service on any revenue level without a separate agreement, cannot run the video model in the UK at all, and cannot use the image model commercially under the current terms.
It is also not yet a hands-off appliance. The project describes itself as an early preview under active development, expecting bugs and breaking changes. Anyone installing it is accepting licence prompts, watching downloads and following a documented sequence on their own hardware. That is a fair exchange for a technical evaluator; it is not a purchase a non-technical owner should make expecting a finished product.
The honest summary sits in one sentence: this is a development box for people building private assistants, not a licence-clean foundation for something you sell, and the gap between those two is exactly the licence stack above.
What an owner can usefully take from it
The useful move is not to buy a DGX Spark. It is to ask the licence question earlier than feels natural. From our own work running governed agents on a self-hosted server, the pattern we see is that owners evaluate whether a capability works and defer whether they may ship it, and the second question is the one that invalidates the build. In discovery conversations, the licensing of an underlying model has so far never been the thing anyone arrived asking about; it surfaces only when something built needs to leave the workshop.
So the practical artefact from this story costs nothing: before building on any model stack, write down, for each model in it, the licence name, the revenue threshold and the territory restriction, on one page. One page answers what happens when the business grows past a cap, what happens in each country it operates in, and which components would need a negotiated licence before a customer-facing launch. In the first hundred days after buying a business, that page is the difference between a demo that impresses and a capability that survives diligence. The hardware barrier to a private AI assistant has effectively fallen. The licence barrier is now the real one, and it is checked by reading, not by benchmark.
Sources
- [1] LocalRouter repository (jayleaton/localrouter), Apache 2.0, measured tables and licence notes:
- [2] Fish Audio Community License, Version 1.0, governing Drama 3:
- [3] MiniMax H3 Community License Agreement, 2 August 2026:
