Capstone: Build and Defend Your Own Local AI Platform
Twenty-seven parts have each taught one thing and asked you to measure it. This part asks for all of them together, on the machines you actually own, in a form somebody else could read and act on.
There is a reason to end this way rather than with one more technique. The failure this subject invites is not ignorance; it is a platform that works, whose owner cannot say why it is configured as it is, what it costs, what it would do under twice the load, or whether last month’s fine-tune helped. Every earlier part has been assembling the answer to that: the memory arithmetic in Part 4, the load generator in Part 9, the noise floor in Part 16, the link annotation in Part 18, the cost model in Part 23, the repeat rule in Part 26. The capstone is where they stop being exercises and become one platform with a document behind it.
Six deliverables, in order: a hardware and model plan whose every figure is arithmetic you can show; the inference service itself, with a gateway, a front-end, dashboards, authentication and a restore you have actually performed; a deployment measured against the single-machine baseline it has to beat; a small model improved by your own pipeline and evaluated honestly, regressions and all; an agentic workstation whose sandbox test passes by failing; and the report that ties them together.
What you will be able to do
Section titled “What you will be able to do”By the end of this part you should be able to:
- size a platform from arithmetic before buying or configuring anything, and name in advance the check that would catch each of your assumptions being wrong;
- run a language-model service that other people in your household use, with authentication, transport security, dashboards, an alert you have proved fires, and a backup you have restored;
- choose between a distributed architecture and a single-machine tiered design on the strength of a measurement, and defend the answer when it turns out to be the simpler one;
- improve a small model for a behaviour you care about, measure the improvement against a noise floor you established first, and report what got worse alongside what got better;
- assemble a coding workstation from local models, agents and tools, with a sandbox whose boundaries you have tested and a suite whose numbers come from enough repeats to mean something;
- write all of it up so that a reader who was not there can judge every number, reproduce the parts they care about, and see plainly what you did not measure.
What you need first
Section titled “What you need first”Everything from Levels 1 to 4, and the agent parts of Level 5. Concretely: the model shortlist from Part 4, the engines from Parts 6 to 9, the gateway from Part 9’s project, the training toolchain from Part 11, whichever improvement technique from Parts 13 to 15 your memory tier supports, the evaluation methods of Part 16, the network measurements of Part 18, at least one of the cluster or tiered designs from Parts 19 to 22, the operations practice of Part 23, and the agent work of Parts 24 to 27.
Above all, the lab notebook you started in Part 1. Every deliverable here is written from it, and the one part of the capstone that cannot be recovered late is a measurement you never recorded. If your notebook has gaps, the honest move is to say so in the report rather than to fill them from memory.
You do not need more than one computer. Every deliverable has a single-machine variant that is a complete submission, and the course has said so since Part 18. What the single-machine path asks in return is one extra paragraph: what a second machine would take on, which link it would need, and which of your own measurements says so.
How to work through it
Section titled “How to work through it”Read the overview lesson first: it lists the deliverables, the rubric you will apply to your own work, the time budget and what to reuse from each earlier project. Then do the six projects in order. The order is not arbitrary. The plan constrains the service; the service is what the deployment is measured against; the improved model is served by the service and driven by the workstation; and the report is written from all five, which is why it is last and why it is the deliverable the rubric weighs most heavily.
Expect this to take longer than the stated minutes if you are also fixing things you discover. That is the intended experience. A capstone that runs exactly to time is usually one in which nothing was tested hard enough to break.
0 / 7 lessons in this part completed
Progress tracking needs browser storage, which is unavailable here. The course works exactly the same without it.
- LessonCapstone Overview and Assessment Criteria20 min
- ProjectCapstone 1: Hardware and Model Plan 8 GB60 min
- ProjectCapstone 2: The Inference Service 8 GB90 min
- ProjectCapstone 3: Cluster or Tiered Deployment 16 GB Cluster120 min
- ProjectCapstone 4: Improve a Small Model 12 GB150 min
- ProjectCapstone 5: The Agentic Workstation 16 GB90 min
- ProjectCapstone 6: The Report 8 GB90 min