AI PC Reference Architectures

A reference architecture is a component specification with the reasoning attached: every part chosen for what it contributes to running models locally, every trade-off stated, and every compatibility requirement written down as something you can check.

What these are, and what they are not

These are specifications, not tested builds. Each one is derived from published manufacturer documentation — socket, TDP, connector type, memory support, physical dimensions — and the parts are specified to work together on paper.

AI Gear Stack has not assembled these machines. Nobody here has put the cooler on the board, closed the case, or measured whether the graphics card clears the drive cage in the specific chassis you buy. That matters, because the things that break a build are rarely the things on a spec sheet: a heatsink that fouls the first memory slot, a card that is four millimetres too long for a case the manufacturer lists as supporting it, a revision of a board that ships with older firmware than the CPU requires.

So each architecture specifies components by requirement first and by example second — “an 850 W ATX 3.1 unit with a native 12V-2×6 connector” is the specification; a named model is an illustration of one. That is deliberate. It is the form of advice that stays true when a specific SKU is discontinued, and it is the honest limit of what can be established without a bench.

Every architecture ends with a verification checklist: the specific measurements and part numbers to confirm against your own basket before you place the order.

What each architecture includes

• A complete component specification: CPU, GPU, motherboard, memory, storage, power supply, cooling and case
• Why each part is there, and what we considered instead
• What the finished machine can actually run, with quantisation stated
• Where to spend more, and where not to — on an AI build the answer is almost always “more VRAM, cheaper everything else”
• Power delivery and physical clearance figures, which is where most builds go wrong
• A pre-order verification checklist, because a specification you have not checked against your own parts is a hypothesis

Why we publish these rather than tested builds

Assembling and testing every configuration would produce stronger claims, and one day it should. Until then the choice is between publishing nothing and publishing the component reasoning with its basis stated plainly.

The reasoning is the part that transfers. Which tier of card to buy, why memory capacity beats memory speed for this workload, why the CPU matters far less than it does for gaming, how much power headroom a transient-spiking GPU actually needs — none of that changes when a model number does, and all of it is establishable from documentation. What is not establishable that way is fitment in your particular case, and we say so at the point where it matters rather than in a footnote.

If you want recommendations for complete machines that ship assembled, the workstation guides cover those instead.