The Problem

Running large open‑source AI models today requires expensive cloud credits or proprietary on‑prem hardware that is hard to replicate. Teams that want full control over data, licensing, and uptime must design, source, and assemble a machine themselves, but no public guide bundles all mechanical, electrical, and software steps in one place.

What This Does

autonomous-computer delivers a complete, end‑to‑end “build‑your‑own AI box” kit. The repository is organized around three predefined configurations:

  • – Home rig (builds/2x/README.md) with two RTX 5090 GPUs (≈64 GB VRAM).
  • – Team rig (builds/4x/README.md) with four RTX PRO 6000 GPUs (≈384 GB VRAM).
  • – On‑prem business rack (builds/8x/README.md) with eight RTX 4090/5090 GPUs (≈192–256 GB VRAM).

Each config folder contains a Bill of Materials (bom/BoM.md), CAD files (step-models/, stl-models/), and a full photo‑by‑photo assembly guide (photos/…). The software side lives in /software, where README.md, setup.md, run-models.md, and testing.md describe OS installation, driver/BIOS tuning, and model‑serving tools such as Ollama, vLLM, or llama.cpp.

How It Is Wired

The repository is documentation‑centric; there is no executable code that orchestrates a build or runtime pipeline. Consequently, a call‑graph cannot be produced. The only “entry point” for a functional workflow is the human operator who follows the step‑by‑step guides:

  1. Mechanical build – files in builds/<size>/step_models/ (e.g., 3D File-20250815T082433Z-1-001.zip) are imported into a CAD/CNC tool to fabricate the chassis.
  2. Electrical wiring – photos in builds/<size>/photos/… and the BOM describe power and data connections.
  3. Software provisioning/software/setup.md instructs the user to install the OS, NVIDIA drivers, and the chosen model‑serving stack. No scripts automate these actions; the user runs the commands manually.

Because the repository contains only static assets and markdown, any change to the mechanical design or software instructions is isolated to the corresponding file. No hub modules or cyclic dependencies exist, but the lack of automated glue code means the “wiring” is entirely manual.

How To Use It

# 1. Clone the repo
git clone https://github.com/moses-y/autonomous-computer
cd autonomous-computer

# 2. Choose a configuration and read its guide
# Example: 2‑GPU home build
less builds/2x/README.md   # high‑level overview
less builds/2x/bom/BoM.md   # parts list
less builds/2x/step_models/Readme.md   # CAD instructions

# 3. Fabricate the chassis (follow CAD/CNC steps in the step_models folder).

# 4. Assemble hardware (photos in builds/2x/photos/... illustrate each step).

# 5. Install software (see /software)
cd software
# Follow the exact commands listed in setup.md – e.g., Ubuntu install,
# NVIDIA driver install, and pip install of vLLM/ollama as documented.

If the user wishes to run a model, they consult software/run-models.md for the exact invocation (e.g., ollama serve or vllm serve), as the file contains the concrete commands.

Real‑World Use

A data‑science team can order the parts list from builds/4x/bom/BoM.md, CNC‑print the housing, and assemble the rack in a week. After following /software/setup.md they launch vllm serve --model DeepSeek-V3 on the 4‑GPU node, exposing the model on an internal API endpoint that their downstream applications query without ever leaving the premises.

Code Health & Issues

  • Medium – Large binaries in Gitbuilds/8x/step_models/3D File-20250815T082433Z-1-001.zip (40 MB) and several .step files > 35 MB each inflate clone size. Fix: move these to Git LFS or external storage.
  • Tests present – four test files exist, but no CI pipeline (.github/ only contains issue templates). Impact: manual test execution, no gate before merge.
  • Dockerfile absent – no container definition for reproducible software setup.
  • License – MIT license present (LICENSE).
  • No committed secrets – static analysis found none.

The Bottom Line

autonomous-computer is a thorough, hardware‑first guide that lets teams build a self‑hosted AI server from scratch. Its strength is the exhaustive documentation and CAD assets; its weakness is the lack of automation—no scripts, CI, or container images—to streamline assembly or software deployment. It is best suited for organizations that already have mechanical‑fabrication capability and want full control over the hardware stack, and who are comfortable executing the manual setup steps.