Field Note | Self-Hosted AI
What We Learned Testing One DGX Spark Versus Three Local AI Workers For Small-Business Workflows
A practical look at self-hosted AI for private document review, claim-risk checks, evidence custody, and operating checkpoints.
In local testing, one DGX Spark worked as a private owner/operator review station. Three DGX Spark units used as independent local workers provided more parallel review capacity and better thermal margin in the tested workflow.
Most AI hardware posts focus on benchmark numbers, model screenshots, or the largest model someone managed to load.
That is useful, but it is not the first question most small business owners need answered.
The better question is:
If I buy and run local AI hardware, what work might it realistically help my business do?
We tested DGX Spark units as local AI workers for ordinary business workflows: reviewing internal documents, checking claim risk, organizing evidence, turning operating notes into next actions, and measuring how much bounded work can be handled before the operator needs to pause.
This was not a cluster test. It was not a public endpoint test. It was not a production-readiness test.
It was a practical local-workflow test.
What We Tested
We compared three configurations.
| Configuration | Test status | What it represents |
|---|---|---|
| One DGX Spark | Tested | A private owner/operator review station |
| Three DGX Spark units as independent workers | Tested | Three local AI reviewers running separate jobs in parallel |
| Three DGX Spark units stacked | Not tested | A future higher-complexity configuration |
The three-unit configuration was not treated as one giant machine. Each unit ran its own local workload.
For a small business, that distinction matters. Many businesses do not need distributed inference on day one. They need multiple private review jobs handled at the same time.
The Technical Setup
These are observed local test values, not universal product claims.
| Layer | Observed value |
|---|---|
| GPU | NVIDIA GB10 |
| Memory reported by OS | 121 GiB per unit |
| Root storage reported by OS | 3.7 TB per unit |
| Operating system | Ubuntu 24.04.4 LTS |
| Kernel | Linux 6.17.0-1026-nvidia |
| Architecture | aarch64 |
| NVIDIA driver | 580.173.02 |
| Docker | Docker 29.2.1 |
| Model runtime | Ollama in Docker |
| Tested model | qwen3:14b |
| Access posture | local-only access through SSH tunnels |
| Public or LAN-wide model endpoint | not enabled |
| Cluster or distributed inference | not tested |
The model runtime was kept local. Documents were not sent to a cloud model service during these tests.
The Controls
The tests used conservative controls because the goal was repeatable business value, not a one-time maximum-load screenshot.
Controls included:
- capped document excerpts
- structured review outputs
- trusted control fields generated by the test harness
- validation of expected output format
- temperature monitoring
- power, utilization, graphics clock, P-state, and throttle-reason sampling where available
- cooldown after each run
For the productive workflow tests, document excerpts were capped at 2,400 characters.
The current conservative thermal rule used a 50 C soft threshold and a 52 C hard threshold for one-DGX productive baseline runs. That 50 C number is our early operating guard, not a claim about the manufacturer’s maximum safe temperature.
Workflow 1: Internal Document Review
Business-owner version:
You have drafts, SOPs, service notes, proposals, planning memos, handoff notes, or operating checklists. You want a second reader before you act on them or send them to someone else.
What we tested:
The model reviewed bounded excerpts from internal business documents and had to return one useful observation, one practical risk, and a bounded next-action posture.
What this showed:
One DGX Spark handled a clean four-document review queue under the conservative temperature guard. Three independent DGXs handled six document reviews in parallel with clean validation and similar total elapsed time.
Practical value:
One unit can act as a private review station for the owner. Three independent units start to feel more like a small review desk, especially when multiple documents or workstreams need attention at once.
Workflow 2: Claim-Risk Review
Business-owner version:
You are preparing a sales page, capability statement, proposal, grant response, or customer-facing summary. You want to know whether the language says too much or makes claims the evidence does not support.
What we tested:
The model reviewed draft material that had internal proof value but was not approved for external use. It had to identify risks without converting the draft into marketing copy or approving publication.
What this showed:
The workflow repeatedly produced useful claim-risk language. It also exposed a real operating lesson: if the source material contains labels similar to the required output format, the model can copy the wrong control fields unless the wrapper protects them.
Practical value:
Local AI can be useful as a second reader for overclaim risk, but it should not decide what is safe to publish. The human review gate still matters.
Workflow 3: Evidence-Custody Review
Business-owner version:
You have screenshots, notes, logs, receipts, draft records, or test results. You need to know whether they actually support the claim you want to make.
What we tested:
The model reviewed generalized evidence summaries and checkpoint-style records. It had to identify whether the proof boundary was clear and whether the evidence supported the intended interpretation.
What this showed:
The model was useful at spotting proof-boundary issues and reminding the operator not to treat internal evidence as external approval.
Practical value:
This is a strong fit for local AI because many evidence packets should remain private. The value is not just speed. It is helping the business avoid messy, unreviewed proof folders.
Workflow 4: Operating Checkpoint Review
Business-owner version:
You have a project, machine, job site, inventory process, or weekly operating plan. You want to know what is working, what is risky, and what should happen next.
What we tested:
The model reviewed checkpoint-style material containing current state, limits, known risks, and next gates.
What this showed:
The model helped identify the active operating constraint and preserve the difference between “tested,” “not tested,” and “ready.”
Practical value:
For owners who run from notes, photos, checklists, and partial updates, this workflow can turn scattered operating context into a clearer decision point.
Workflow 5: Queue Discipline And Throughput
Business-owner version:
You need to know how much useful work the system can process before it needs a pause.
What we tested:
We compared one unit processing a sequential queue against three units processing separate queues in parallel.
Observed results:
| Test | Work completed | Validation | Max temp | Peak observed load | Cooldown final | Interpretation |
|---|---|---|---|---|---|---|
| One DGX clean baseline | 4 capped document reviews | 4/4 pass | 45 C | 44.74 W / 96% GPU / P0 / 2535 MHz | 35 C | Clean owner/operator review envelope |
| One DGX higher queue | 6 capped document reviews | 6/6 pass after wrapper fix | 50 C | 55.82 W / 96% GPU / P0 / 2463 MHz | 35 C | Useful, but touched our soft threshold |
| Three independent DGXs, pass 1 | 6 capped document reviews total | 6/6 pass | 44 C | Three local workers active | 35/36/35 C | Clean parallel review lane |
| Three independent DGXs, pass 2 | 6 capped document reviews total | 6/6 pass | 45 C | Three local workers active | 35/36/35 C | Repeatable parallel review lane |
Practical value:
One unit is useful. Three independent units provide more parallel capacity and better thermal margin in this workflow, without requiring cluster claims. For a small business, that may be the more practical win.
Workflow 6: Local-Only Operating Posture
Business-owner version:
You want to review private drafts, customer notes, pricing ideas, operating records, or planning documents without sending them to an outside model service.
What we tested:
Local model serving only. Access was kept through local SSH tunnels. No public model endpoint or LAN-wide model endpoint was enabled.
What this showed:
The setup can produce useful review outputs while keeping the operating posture local. It also requires discipline: runtime setup, access control, monitoring, validation, and shutdown procedures are part of the system.
Practical value:
Self-hosted AI can offer more control over private work, but it is not “plug it in and forget it.” The operating wrapper matters as much as the hardware.
What Needed Tightening
The most useful failure was not hardware.
In one six-document run, the model completed the work, but one response copied control-field labels from the source material into the output. The business lesson is straightforward: if you want reliable outputs, do not rely only on the model to reproduce critical metadata.
The fix was to let the harness generate trusted control fields and ask the model only for the substantive business review content.
After that change, the six-document run validated cleanly, but it touched the 50 C soft threshold once. A four-document run stayed comfortably inside the current conservative guard.
What Three Independent Workers Changed
The three-unit setup did not prove distributed inference.
It proved something more immediately useful for a small team:
- separate review jobs can run in parallel
- more work can be processed within a similar review window
- each local worker can keep its own bounded output
- thermal margin improved for the clean six-document total workload
- the operator still needs to coordinate queues, monitoring, and evidence capture
That is a practical business result. It is not as flashy as a benchmark leaderboard, but it is closer to how small teams actually work.
Bottom Line
In local testing, one DGX Spark was useful as a private review station for bounded business documents. Three DGX Spark units used as independent local workers provided more parallel review capacity and better thermal margin in this workflow, without requiring cluster or distributed-inference claims.
The value came from workflow discipline:
- capped inputs
- local runtime
- structured outputs
- validation
- thermal monitoring
- human approval gates
For a small business, self-hosted AI is most compelling when it is treated as an operating tool, not a benchmark trophy.
What We Would Test Next
Before recommending more complex configurations, we would test:
- longer routine business-document queues
- meeting-notes to next-actions workflows
- field packet or job packet review
- structured JSON output handling
- document-length sensitivity
- repeatability across room and placement conditions
- the operational cost of maintaining the setup over time
Stacked configurations should wait until the simpler local-worker value is proven and the added complexity has a clear business reason.
Publication Caveat
These are local workflow-test results under conservative controls. They do not prove production readiness, certification, public endpoint readiness, controlled-data approval, cluster capability, distributed inference, or stacked-system behavior.