TL;DR: Use nanochat to learn how a language model is trained, evaluated, and turned into a chat interface. Start with its educational CPU recipe and a recorded source revision. If you want a useful assistant immediately, start with an existing model instead. A training demonstration is not a fixed-price replacement for a hosted AI service.

What you’ll be able to do after this guide:

• Prepare an isolated nanochat checkout and identify its CPU dependencies.
• Follow the training stages and diagnose missing data or checkpoints.
• Decide whether a larger training experiment is worth budgeting for.

Honest take: nanochat is a good learning project when understanding the training pipeline is the goal. For everyday chat, use an established inference workflow before considering training your own model.

This is a source-based setup guide, checked November 1, 2026. We inspected the official repository and command definitions; we did not train a model, rent a GPU, or measure completion time for this article. The walkthrough uses Bash on a Linux learning environment. It is not a claim that the same shell commands work in native Windows PowerShell.

What are you actually installing?

The official nanochat repository contains a compact language-model training and inference project. Its scope includes tokenization, pretraining, evaluation, supervised fine-tuning, and interaction with the resulting model. That makes it a different starting point from downloading an already trained assistant.

The source code uses the MIT license. Keep its copyright and license notice when redistributing covered code. That license does not automatically establish the rights for every external dataset, dependency, or checkpoint you might introduce. Check those separately before moving an experiment into a commercial product.

Here is the practical decision before installing anything:

Your immediate goal	Recommended starting point	Evidence of success
Understand training stages	nanochat educational recipe	You can explain the inputs and outputs of each stage
Use a local assistant today	Existing model plus inference runtime	It completes your own small acceptance tasks
Adapt a model to a narrow task	Evaluate fine-tuning an existing model	Held-out task performance improves
Offer a shared service	First define quality and operations requirements	Recovery, access control, and workload tests pass

For the second path, our Ollama overview is a more relevant entry point. For adaptation rather than training from scratch, see the Unsloth fine-tuning guide. Neither alternative removes the need to evaluate the output on your own task.

Step 1: record the source revision before setup

Create a fresh directory for the experiment. Do not use a checkout containing another person’s uncommitted changes. The following commands pin the revision inspected for this article rather than silently following tomorrow’s default branch:

git clone https://github.com/karpathy/nanochat.git nanochat-learning
cd nanochat-learning
git switch --detach 92d63d4e8bb4df75c3b71618f31ddde2378b2bcd
git rev-parse HEAD
git status --short

Expected checks: the revision output matches the full hash above, and a fresh checkout has no tracked modifications. Detached HEAD is intentional here: it preserves a reproducible reference. If you want to change the experiment, create your own branch before editing and record the patch with the run notes.

Pinning source does not make the entire experiment immutable. External data can change, package availability can change, and hardware differs. Keep the lockfile and record the actual environment as well. This distinction matters when a tutorial from a different month points to an older dataset or uses flags that have since changed.

Step 2: prepare the CPU environment

Install uv using the method appropriate for your machine from the official uv installation guide. Confirm uv --version works before continuing. Keeping installation separate from training makes a missing package manager easier to diagnose.

The pinned project dependency file declares Python 3.10 or later and separate CPU and GPU extras. It pins PyTorch 2.9.1 in this revision. Use the project’s dependency definition instead of installing a random current torch build into an unrelated environment.

uv venv --python 3.11
uv sync --extra cpu --locked
source .venv/bin/activate
python --version
python -c "import torch; print(torch.__version__); print(torch.cuda.is_available())"

Python 3.11 is the interpreter selection for this example, not a claim that it is the only supported version. The checks should print the environment’s Python and torch versions. On a CPU-only setup, a false CUDA availability result is expected. It does not mean that dependency installation failed.

Do not combine the CPU and GPU extras to try to cover every possibility. They are mutually exclusive in the project configuration. If resolution fails, record the interpreter version, operating system, architecture, and complete error. Fix that environment issue before proceeding to training; creating a model will not repair a broken torch import.

No single RAM or disk number is promised here. Dataset downloads, tokenizer work, training state, and checkpoints all contribute to the requirement. Inspect available storage and memory on the machine you will actually use. If this is your only work computer, choose a time when an experiment consuming its resources will not interrupt essential work.

Step 3: inspect the educational recipe before launching it

Read runs/runcpu.sh. The maintainer presents it as an educational CPU or MPS example with limited expected model quality. Its small training configuration is a learning route, not evidence that a laptop can cheaply reproduce a modern commercial assistant.

sed -n '1,160p' runs/runcpu.sh
df -h .

Read the storage path in the script as well as the commands. At this revision the recipe sets its own NANOCHAT_BASE_DIR under the user’s home directory. An environment value exported before running it does not override that assignment. If you need another disk, make and document an intentional edit to the recipe or execute its stages manually with your chosen directory.

For an unmodified educational run, after reviewing those choices:

mkdir -p run-notes
git rev-parse HEAD > run-notes/source-revision.txt
uv --version > run-notes/uv-version.txt
python --version > run-notes/python-version.txt
set -o pipefail
bash -e runs/runcpu.sh 2>&1 | tee run-notes/cpu-run.log

The -e option asks Bash to stop on a failing stage rather than continue through the simple command sequence. pipefail keeps a failure from being hidden by a successful tee. These are troubleshooting choices in this walkthrough. They do not turn the upstream script into a resumable workflow manager.

Watch the log and available resources. Stop deliberately if the machine cannot sustain the run; do not leave an unobserved job consuming storage just because a tutorial suggested it. No wall-clock completion promise is made here. A time mentioned in a maintainer’s comment describes that maintainer’s experiment, not your processor or operating system.

What should each stage leave behind?

Treat the run as a sequence of dependencies. A later stage cannot compensate for an earlier missing artifact. The following is a review worksheet, not a transcript of a run we performed:

Stage	What to verify before moving on	What failure suggests
Dataset preparation	Requested files downloaded successfully	Connectivity, storage, or incomplete downloads
Tokenizer preparation	Tokenizer artifacts and evaluation output exist	Input data or tokenizer setup problem
Base training	Training logs and saved model state exist	Runtime, resource, or configuration failure
Base evaluation	Evaluation completes against the intended checkpoint	Missing or mismatched model artifacts
Supervised fine-tuning	Chat-training checkpoint is saved	Earlier stages or training task failed
Chat inference	Selected checkpoint loads and produces a response	Wrong source, path, device, or model selection

The dataset downloader provides a useful concrete check: -n 8 requests eight training shards and additionally includes a validation shard. It does not mean eight total files. The current source points to ClimbMix and includes handling for an older data layout, so an old FineWeb-based tutorial can describe a different setup.

Read the downloader’s completion summary, not just whether the process returned to the prompt. Its source reports successful downloads individually. A partial download followed by a tokenizer error should be investigated at the data stage first. Do not immediately change model depth or training iterations in response to a missing input file.

Keep the original run log intact when trying a repair. Start a new log for the next attempt and record what changed. That simple habit prevents a later successful command from making an earlier incomplete stage disappear from your notes.

Step 4: select and check a trained chat checkpoint

Only run chat inference after supervised fine-tuning has successfully produced a checkpoint. The chat CLI source supports a device selection and a single-prompt mode. For the CPU path:

python -m scripts.chat_cli --device-type cpu --source sft \
  --prompt "What is the capital of France?"

The expected software behavior is checkpoint loading followed by an assistant response. A correct answer is an evaluation result you must observe; it is not guaranteed by the command. Save the exact prompt and output, then try a small set of other questions. One familiar fact is weak evidence of general usefulness.

The checkpoint loader maps the supervised fine-tuning source to chatsft_checkpoints. If no model tag is supplied, it selects a model automatically; the latest step is also inferred when omitted. When you have multiple experiments, record and select the intended model tag and step explicitly rather than assuming the newest experiment is the one being loaded.

A missing-checkpoint error is therefore a reason to inspect the source selection, base directory, and completed training stages. It is not a reason to download an unrelated file with a similar name. Keep tokenizer artifacts with the corresponding experiment: the loader checks vocabulary compatibility, and mixing artifacts undermines reproducibility.

How should you evaluate the result without fooling yourself?

Write a small evaluation sheet before reading the model’s responses. Include a few simple factual questions, a short instruction with a visible constraint, and one task representative of your actual interest. Define what counts as passing each item. Keep this set separate from examples you use while adjusting the run.

Record failures as specifically as successes. Did the model answer the wrong question, repeat text, violate the requested format, or fail to stop sensibly? Those are different observations. Preserve the prompt, output, revision, and checkpoint identity so that a later run can be compared fairly.

Do not call the experiment successful merely because it produces fluent text. For learning, success may mean that you traced an artifact from preprocessing to inference and understood a failure. For a useful assistant, the standard is higher: it must complete your tasks reliably enough to justify ongoing operation.

Honest verdict: when is a GPU experiment worth paying for?

Move to larger training only after you can state what the experiment will test. Perhaps you want to compare two data mixtures with the same evaluation set. Perhaps you want to understand how a change affects a particular error category. Buying more compute without that question makes it difficult to tell whether the spending taught you anything.

Build a budget from your own quote and scope. For example, as arithmetic only, an assumed $2 per hour machine used for three hours costs $6 in compute. If storage and transfer add an assumed $1, the planned total is $7. A second identical attempt makes it $14. None of these inputs is a verified provider price or nanochat training estimate.

List setup time, failed attempts, data storage, retained checkpoints, and evaluation separately. Decide the stopping condition before starting. A fixed advertised training headline cannot represent all of those choices. This guide uses no paid service and recommends no particular rental configuration.

If your interest turns toward serving an existing model, RunAIHome’s VRAM calculator can help with inference planning. Do not reuse an inference-only memory estimate as a training budget: training retains additional state, and a configuration that serves a model may not train it.

FAQ

Q: Does installing nanochat give me a ready-to-use ChatGPT replacement?

A: No. This walkthrough prepares a training project. Useful output depends on the resulting model and evaluation. Choose an existing trained model when immediate assistant quality is the priority.

Q: Can I skip training and launch the chat command?

A: Only if a compatible checkpoint and its required artifacts already exist in the expected setup. The command shown here assumes the supervised fine-tuning stage completed.

Q: Is the CPU example completely offline?

A: Initial dependency and data preparation uses network downloads. Do not describe a fresh installation as air-gapped. Plan and verify a separate offline process if that is a requirement.

Sources

• Project scope and supported workflows — nanochat
• Code license at the inspected revision
• CPU educational recipe
• Python dependencies and CPU/GPU extras
• Dataset downloader and validation-shard handling
• Chat CLI arguments
• Checkpoint selection and loading
• uv installation — Astral

Last updated November 1, 2026. Commands were checked against source revision 92d63d4e8bb4df75c3b71618f31ddde2378b2bcd. Training quality, hardware fit, and completion time require validation on your own setup.

What self-hosting actually costs

Real cost breakdowns for self-hosted AI: hardware floors, power, maintenance hours, and the honest comparison against paying for it. No spam, unsubscribe anytime.

Email address Subscribe