# Concurrency vs quant when VRAM is tight: step by step

Contents

# Why “Concurrency vs quant when VRAM is tight” deserves a written plan

Drop concurrent chats before dropping to a broken quant. 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 device-to-model matching 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

# Questions to ask before you buy

Will the model you need still fit after the operating system, drivers and runtime take their share?
How long are the documents people really paste, and how many people paste them at the same time?
Does the room tolerate the noise and heat of a sustained load during working hours?
Who replaces a failed fan or PSU, and how long can the team live without the box?
Is there a clear upgrade path, or will the next step require a new platform?

If any answer is unclear, rent or borrow time on similar hardware first. A week of real use teaches more than a month of reading spec sheets, and it keeps your purchase grounded in your own workload.

# 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

Review the setup again after every major model upgrade.
Publish what the assistant will refuse to do.
Measure on your own prompts before quoting any speed.
Pin driver and runtime versions together.

Published by MicroAI One (本地AI 1号网), a Shenzhen team working on local LLM hardware, software and deployment.

End