# Hardware and model plan — <the platform you are building>

<!--
Purpose: the deliverable of Capstone 1. The document that says which machines you have,
         what each one will do, which models will run where, what each will cost in
         memory at the context length you will actually configure, how the models get
         onto the machines and where the plan is most likely to be wrong.
Platform: all
Minimum memory: 8 GB; this is arithmetic and a document, not a workload
Assumes: the machine and environment sections of labbook.md from Part 5, the shortlist
         from Part 4's lab, and the model reference at /reference/models/ for parameter
         counts, layer counts and key-value head counts.

Fill in every angle-bracket field and delete every comment block, including this one.
A field you cannot fill is a field to write "not recorded" in; the gap is information.
Every memory figure here is arithmetic, not a measurement, and section 7 is where you
say so and later record what the arithmetic got wrong.
-->

**Author:** <you> · **Date:** <YYYY-MM-DD> · **Tracks in play:** <S, X, M, N>

---

## 1. What this platform is for

<Three or four sentences. Who uses it, for what, and how often. Then the requirement the
plan has to meet: how many people at once, the longest prompt you expect, the longest
answer, and whether anybody is waiting for the first token or for the whole answer.>

<Write this before you look at any hardware. A plan chosen first and justified afterwards
is a purchase, not a design.>

## 2. The machines and their roles

| Machine | Track | Chip or accelerator | Memory | Memory kind | Storage free | Roles | Why this role |
| --- | --- | --- | --- | --- | --- | --- | --- |
| <name> | <S/X/M/N> | <as your system reports it> | <GB> | <unified / discrete VRAM + host> | <GB> | <prefill, decode, router, cache, storage, agent> | <one sentence> |

<Part 18 named six roles. Most home machines hold several and one machine may hold all of
them. The "why" column carries the section: "it has the most memory and the least
arithmetic throughput, so it decodes" is a reason; "it is the newest" is not.>

**Machines I do not have but the plan assumes:** <none, or name them; a plan that quietly
assumes a machine you have not bought is the commonest way this document goes wrong.>

## 3. The memory budget, per model, per machine

<One block per model you intend to run. Every figure is arithmetic from Part 4's lesson on
choosing a model for a memory budget, not a number from a forum post.>

### <model id from the course model reference>

| Field | Value | Where it comes from |
| --- | --- | --- |
| Total parameters | <n> B | model card |
| Active parameters | <n> B | model card; equal to total for a dense model |
| Layers | <n> | model card or config.json |
| Key-value heads | <n> | config.json, `num_key_value_heads`; not the query head count |
| Head dimension | <n> | config.json |
| Quantisation | <e.g. Q4_K_M, MXFP4, BF16> | your choice |
| Bytes per parameter | <from the bytes-per-parameter table> | Part 4 |
| **Weight memory** | <total parameters × bytes per parameter> GB | arithmetic |
| Context length you will configure | <n> tokens | your choice, not the trained maximum |
| Bytes per element in the cache | <2 for FP16, 1 at 8-bit, about 0.5 at 4-bit> | your engine's cache type |
| **Bytes per token of cache** | 2 × <layers> × <kv heads> × <head dim> × <bytes> = <n> | arithmetic |
| **Cache at your context** | <bytes per token × context length> GB | arithmetic |
| Concurrent conversations planned | <n> | from section 1 |
| **Cache for all of them** | <cache at context × conversations> GB | arithmetic |
| **Subtotal for this model** | <weights + cache> GB | arithmetic |

<Sliding-window and hybrid-attention models make the per-token figure an upper bound.
Say which of your models are in that category and that the real figure will be lower.>

### Headroom, per machine

| Machine | Total memory | Operating system and applications | Engine working memory | Cache growth allowance | Second model | **Left for weights** |
| --- | --- | --- | --- | --- | --- | --- |
| <name> | <GB> | <GB> | <GB> | <GB> | <GB, or none> | <GB> |

<Part 4 named four allowances and this table is them. The one people forget is the second
model: an embedding model, a reranker or a draft model is resident whenever the main model
is, and it does not become free because it is small.>

### Does it fit?

| Machine | Model | Subtotal | Left for weights | Fits? | If not, what changes |
| --- | --- | --- | --- | --- | --- |
| <name> | <model> | <GB> | <GB> | <yes / no> | <smaller quantisation, shorter context, fewer concurrent conversations, a different model> |

<A "no" here is the most useful row in the document, because you found it with arithmetic
in an afternoon rather than with an out-of-memory error at three in the morning.>

## 4. Models per role

| Role | Model | Why this one | Licence | Gated? | Fallback if it disappoints |
| --- | --- | --- | --- | --- | --- |
| Chat | <id> | <one sentence> | <from the model card> | <yes/no> | <id> |
| Coding | <id> | <one sentence> | <from the model card> | <yes/no> | <id> |
| Embedding | <id> | <one sentence> | <from the model card> | <yes/no> | <id> |
| <other> | <id> | <one sentence> | <from the model card> | <yes/no> | <id> |

<A licence read from the model card, not from a summary of it. A fine-tune you make is a
derivative work and inherits the base model's terms.>

## 5. The network plan

| From | To | Class | Rated | Measured throughput | Measured round trip | Carries |
| --- | --- | --- | --- | --- | --- | --- |
| <machine> | <machine> | <2.5 GbE, Thunderbolt, QSFP, Wi-Fi> | <from the box> | <from Part 18's lab> | <from Part 18's lab> | <per-token / per-request / load-time / client> |

<The last column decides everything. A link carrying per-token traffic has to be fast; a
link carrying load-time traffic only delays the start. A rated speed from a box is not a
measurement, which is why there are two columns.>

**Names and addressing:** <how machines find each other; no addresses in this document if
you intend to share it.>

**If you have one machine:** <say so here, and say which of the roles above would move to
a second machine first and which link class it would need. That sentence is what makes
this a plan rather than an inventory.>

## 6. Download and storage plan

| Model | Repository | Files | Size | Destination | Verified how | Downloaded on |
| --- | --- | --- | --- | --- | --- | --- |
| <id> | <publisher/repo> | <the quantisation file or the whole repo> | <GB> | <the shared library path> | <hash recorded beside the file> | <YYYY-MM-DD> |

**Total to download:** <GB> · **Free space on the library volume:** <GB> · **Headroom
after:** <GB>

**Order:** <what to download first, so that you can start working before the largest file
finishes.>

**One authoritative copy:** <where the library lives and how the other machines read it;
Part 18's shared mount, a copy per machine, or a single machine.>

## 7. Risks, and what would tell you early

| # | Risk | How likely | What it costs | The check that catches it early |
| --- | --- | --- | --- | --- |
| 1 | <e.g. the 30B model does not fit at the context I want on the 64 GB machine> | <high/medium/low> | <what you would have to change> | <the startup log's cache size, before any load test> |
| 2 | <e.g. the engine's build for my accelerator is unqualified on this chip> | | | |
| 3 | <e.g. the link I planned to carry per-request traffic measures far below its rating> | | | |

<Three is a minimum, not a target. Each risk names a check you can run before you have
built anything, which is the point of doing the plan first.>

## 8. What this plan does not know

<The figures above are arithmetic. List what will be measured later and what you have
taken from a vendor page without verifying: bandwidth, the engine's real working-memory
appetite, whether a quantisation you have not tried holds up on your tasks, whether the
NPU or the alternative backend does anything for you.>

<Come back to this section after Capstone 6 and add one line per figure that the
measurement contradicted. That comparison, between what the arithmetic predicted and what
the machine did, is the single most valuable paragraph in the whole capstone.>
