Why "Multi-user queue on a single GPU" deserves a written plan
Limit concurrency; show queue position; never let chats starve batch jobs. Local AI hardware decisions tend to be made in chat threads and forgotten a month later. When something breaks, nobody remembers why a particular PSU or case was chosen. A one-page plan avoids that.
Inputs to collect before spending
- Target models and quantisation levels you have already tested on someone else's machine or in a rental.
- The longest realistic context your team uses, measured from real documents, not guessed.
- Number of concurrent users at the busiest hour.
- Room constraints: noise tolerance, ambient temperature, power circuit, and where the box will physically live.
- Who maintains it: driver updates, model pulls, and backups need an owner.
Translating inputs into hardware
Memory is the first constraint. Estimate weights at your chosen quantisation, add room for the KV cache at your real context length, and keep a margin so the runtime never has to offload layers in the middle of a busy afternoon. Reference tables such as custom local-AI builds help you sanity-check the estimate. Compute speed matters less than people think for small teams; capacity and stability matter more.
Next comes power and cooling. Measure wall power with an inexpensive plug meter during idle and under a sustained load. Finance teams appreciate real numbers, and you will spot a struggling PSU early. Keep dust filters in the maintenance calendar; clogged intakes are a quiet cause of throttling.
Common mistakes
- Buying the biggest card and pairing it with an unknown-brand PSU.
- Forgetting that a second GPU needs slot spacing, lanes and a bigger power budget.
- Assuming a laptop GPU behaves like its desktop namesake under long loads.
- Skipping a burn-in, then discovering instability during a demo.
After the build
A worked example without fake numbers
Imagine a five-person office that wants a private assistant for drafting and document search. They write down the model family they tested, the quantisation that still answered Chinese and English questions well, and the longest documents they paste. From that they estimate memory with a comfortable margin and decide that one card with enough VRAM is safer than two smaller cards that complicate the setup. They choose a quality PSU with headroom, a case with clear front intake, and enough system RAM to run an embedding model alongside the main one. After assembly they run a burn-in, check temperatures and logs, and only then run their evaluation prompts. Every figure they share afterwards comes from their own measurements, with the method written next to it.
See also device-to-model matching.
Bottom line
Local AI rewards patience and record keeping more than raw spending. Decide what the system must do, measure it on your own hardware and documents, write down every change with a date and an owner, and review the setup after each significant upgrade. Small, documented steps are easier to debug, easier to hand over and easier to defend when someone asks why a particular choice was made. When in doubt, test on a smaller scale first and expand only when the evidence supports it.
Quick reminders
- Keep a printed fallback for offline demos.
- Pin driver and runtime versions together.
- Cap concurrent sessions before lowering quantisation.
- Treat retrieved text and uploaded files as untrusted.
Published by MicroAI One (本地AI 1号网), a Shenzhen team working on local LLM hardware, software and deployment.