create-llm scaffolds a PyTorch training project sized to your hardware

Four templates, and the size ladder is the decision

The templates are named by size, and the size is what determines whether the project will run on what you have.

NANO is about 1M parameters, runs on any CPU with 2GB RAM, trains in one to two minutes and expects 100 or more examples. The README positions it for a first attempt at training a language model, quick experiments, demonstrations and limited data of 100 to 1000 examples.

TINY is about 6M parameters on a CPU or a basic GPU with 4GB RAM, in five to fifteen minutes, with 1,000 or more examples. It is the prototyping tier and the one the quick-start commands use.

SMALL is about 100M parameters and asks for an RTX 3060 or better with 12GB of VRAM, one to three hours, and 10,000 or more examples. BASE is about 1B parameters, an A100 or multi-GPU, one to three days, and 100,000 or more examples.

The honest reading is that this is a teaching and prototyping ladder. What trains on a laptop in two minutes is not a model you can deploy, and the jump from 6M to 1B parameters is four orders of magnitude that no amount of scaffolding closes.

Eight pieces of infrastructure, in one command

The pitch is a list, and the list is the reason to use a scaffolder at all.

Training a language model from scratch is described as needing model architecture, with GPT, BERT or T5 as the starting points, a data preprocessing pipeline, tokenizer training, a training loop with callbacks, checkpoint management, evaluation metrics, text generation and deployment tools. The scaffolder claims all of it in one command.

What lands in the project directory is the same list made concrete: PyTorch training infrastructure, the preprocessing pipeline, tokenizer training for BPE, WordPiece or Unigram, checkpoint management with auto-save, TensorBoard integration for live monitoring, an interactive chat interface, model comparison tools and deployment scripts.

The chat interface is the part worth flagging. It is not a demo extra; it is the fastest way to find out whether a training run produced anything, and having it in the scaffold means the answer arrives before you have built a serving path.

Two optional plugins extend it, WandB for experiment tracking and HuggingFace for model sharing. Both are opt-in at generation time rather than dependencies you discover later.

The workflow is a fixed sequence, and step three needs your text

The generated project has a directory layout that matches a training run in order, and the commands are spelled out.

Generation takes a name and a template:

npx create-llm my-llm --template tiny --tokenizer bpe

Dependencies install from the generated file with `pip install -r requirements.txt`. Data goes into `data/raw/`, and the README's example is Project Gutenberg's Shakespeare text fetched with curl into `data/raw/shakespeare.txt`, with the stated tip that at least 1MB of text is needed for meaningful results.

The tokenizer comes next, `python tokenizer/train.py --data data/raw/`, which builds the vocabulary from your data. Then `python data/prepare.py` tokenizes and prepares it. Training is `python training/train.py`, with TensorBoard served by `tensorboard --logdir=logs/tensorboard` and read at http://localhost:6006.

Resuming is explicit, which is the correct default for long runs:

python training/train.py --resume checkpoints/checkpoint-1000.pt

Evaluation reads the best checkpoint rather than the last one, `python evaluation/evaluate.py --checkpoint checkpoints/checkpoint-best.pt`, and text generation is a separate script under evaluation/.

Docker removes the local install and adds a torch image

The Docker route exists so you can skip installing Node and Python, and the implementation is worth reading before you rely on it.

The image is multi-stage. The first stage is node:18-alpine, which compiles the TypeScript CLI and then prunes dev dependencies. The runtime stage is python:3.11-slim with Node 18 installed from the NodeSource repository, the CLI symlinked into /usr/local/bin, and a pip install of the stack: torch, transformers, tokenizers, tqdm, numpy, tabulate, datasets, tensorboard, matplotlib, gradio, pytest and pytest-cov.

Two observations follow from that list. pytest and pytest-cov are in the runtime image, so the test tooling ships with every scaffold container whether or not you use it. And every requirement is a lower bound with no upper pin, so two people building the image in different months get different library versions under the same tag.

Compose organises it by profile. The cli profile runs the scaffolder, training reserves all NVIDIA devices through a device reservation and sets CUDA_VISIBLE_DEVICES=0, chat publishes port 7860 with GRADIO_SERVER_NAME=0.0.0.0, and dev gives an interactive shell with a TTY. Named volumes keep the cache and the model checkpoints outside the container.

The Makefile wraps the same thing with build, build-all, build-cli, build-training, test, demo, clean and push.

Smart defaults do the sizing work, and warn when they cannot

The behaviour that differentiates this from a bare template is the set of checks the scaffolder runs on your behalf.

Vocabulary size is auto-detected from the trained tokenizer rather than guessed in advance. Sequence length mismatches are handled automatically. Model and data size mismatches produce a warning, which matters because a 1B-parameter model against a thousand examples is the failure mode that looks like a broken training loop rather than a bad decision. Overfitting is detected during training, and optimal hyperparameters are suggested.

Cross-platform paths are handled, and errors come with detailed diagnostic messages, which in a generated project you did not write is worth more than it sounds.

The wizard collects the four decisions in one pass: project name, template, tokenizer type and optional plugins. The quick mode passes the same values on the command line with `--template`, `--tokenizer` and `--skip-install`, so a repeat run in a script is fully specified.

Between them, these defaults are the argument for using a scaffolder rather than copying a repository. They encode the failure modes someone already hit.

The CLI is four dependencies, and the test is one scaffold run

The npm side is small, which is what you would expect from a generator.

package.json declares create-llm at version 2.2.3 with a single binary pointing at dist/index.js, requiring Node 18 or newer and npm 8 or newer. Runtime dependencies are chalk, commander, inquirer and ora: terminal colour, argument parsing, prompts and a spinner. There is no machine learning code on that side, because the CLI copies templates and runs a Python interpreter.

The test script is `node dist/index.js test-project --template nano`, with no test framework in the dependencies. That is a smoke test: it generates a NANO project and, judging by the Makefile's own version of the same check, verifies that the expected directory appeared. Useful as a packaging check, not as a regression suite for template contents.

The naming deserves attention before you script an install. The package is `create-llm` unscoped, the homepage field points at the unscoped npm page, and every badge and documentation link in the README points at a scoped package under a differently spelled author handle. Pin what you actually verified rather than what the badge says.

No GitHub releases exist, so npm is the release channel, and the version to track is the one in package.json.

MIT, four documentation files, and three Dockerfiles

The repository is MIT licensed, not archived, with the last push on 2026-09-13 and the default branch main.

There are no GitHub releases at all, which for a package distributed through npm is unremarkable but worth stating: there is no repository-side version history to consult when a scaffold changes underneath you. The changelog lives in the repository and the version lives in package.json.

The tree is documentation-heavy for a small tool. ARCHITECTURE.md, DEVELOPMENT.md, DOCKER.md, CONTRIBUTING.md and CHANGELOG.md sit at the top level, with docs/ behind them. For a project whose whole job is generating a directory tree, publishing the reasoning about that tree is a reasonable investment.

Docker gets the most attention: three Dockerfiles, the all-in-one one plus Dockerfile.cli and Dockerfile.training, a docker-compose.yml, docker-entrypoint.sh and setup-docker.sh. The split between an all-in-one image and two single-purpose ones is the practical choice, since a training image with gradio and pytest in it is a large download for a task that only needs torch.

One gap: the copy of the README here stops inside the text generation example, on the backslash after `python evaluation/generate.py`, so the generation flags and the rest of the documentation are not visible in this copy.

Editorial conclusion

Adopt create-llm if you want a working training skeleton before you have decided on an architecture, and pick the tier from the hardware you have rather than the one you want. Do not treat the generated project as production code without reading it, since the scaffold makes its own choices about hyperparameters and the README's own warning about model and data size mismatches is the first thing to watch in the logs. Resolve the npm package name before scripting installs, because the documentation links point at a scoped package under a differently spelled author handle.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. README
5. theaniketgiri/create-llm on GitHub