Why "GPU spend narrative for finance" deserves a written plan
Three scenarios; cite your own meter. 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 3000 CNY budget tier 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.
See also Mac unified memory notes.
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
- Cap concurrent sessions before lowering quantisation.
- Photograph cable routing before closing the case.
- Leave memory headroom for the OS and the embedding model.
- Read the model licence before commercial use.
Published by MicroAI One (本地AI 1号网), a Shenzhen team working on local LLM hardware, software and deployment.