miForge: Making and Changing Model Weights
The training application of miSuite. miForge makes weights — it creates a model from scratch, changes an existing one, or trains an adapter beside it — through one loop of train, test, checkpoint and repeat. Every checkpoint is a standard Hugging Face model, it needs no other application to run, and it can optionally update the weights miLLM is serving without a reload.
Part of miSuite, and fully usable on its own.
miForge makes weights. A checkpoint is a set of tensor files, and training is a process that changes tensors in graphics-card memory and writes them out. Labs do this at scale on clusters. The same mechanism works on a workstation with a small model, and miForge is that mechanism, built around one loop: push the weights in a direction defined by some domain material, test the result, save a checkpoint, repeat.
It does three things with a model, all through that loop:
| What it means | |
|---|---|
| Creates weights | Builds a new model from an architecture description and random starting values. No existing model is needed. |
| Changes weights | Updates every parameter of an existing model toward a domain. |
| Adds weights | Trains a low-rank adaptation (LoRA) adapter (Hu et al., 2021) beside a model, to keep separate or merge in later. |
Where the training signal comes from
A run learns from one of four signal sources:
| Source | Learns from | Objective |
|---|---|---|
| Corpus | Example text you supply | Supervised fine-tuning |
| Self-generation | The model’s own answers that a selector accepted | Supervised fine-tuning on the accepted answers |
| Preference pairs | A better and a worse answer to the same prompt | Direct preference optimization |
| Reward | Several answers per prompt, each scored by a grader | Group-relative policy optimization |
Selectors and graders decide what counts as good: rules, a judge model, reference answers, human review, or a combination. Every batch is recorded with where its examples came from (by content hash), which model generated them, and how many answers were accepted or rejected. Where a setting would change what is trained, miForge refuses to guess; a corpus run with no masking policy configured is refused rather than given a silent default.
Domain packs
A pack describes a domain once so many runs can reuse it: a prompt set, optional corpus and preference pairs, selector and grader configuration, a test set that measures whether the domain is improving, and a retention set of general prompts with a floor, the lowest score the model may fall to. A pack holds pinned references to versioned parts, not copies, so two runs on the same pack version trained on the same material. A guided authoring flow lets a domain expert describe what good looks like, try it on a sample, and hand it to the operator.
Runs, checkpoints and lineage
- Nothing untested is presented as a model. Each checkpoint carries the test and retention scores of the step that produced it, and it is written atomically: on disk it is either complete or absent.
- Memory is estimated first. Before anything is allocated, miForge estimates the run’s graphics-card memory and refuses a run that will not fit, showing both figures, rather than crashing twenty minutes in. With several cards, each is listed with its free memory and its own verdict, and a run can be pinned to a card by its identifier.
- Continue, branch and merge. Any checkpoint can be continued or branched, and an adapter can be merged down into its base. The checkpoint tree shows the whole lineage.
- Chains run stages in order, each starting from the last checkpoint of the one before, for a curriculum such as corpus first, then self-generation, then preference pairs.
Standalone, with standard outputs
miForge needs no other application. It loads or creates the model itself, trains in its own process and writes its own checkpoints. A checkpoint is a standard Hugging Face model directory, and an adapter is a standard Parameter-Efficient Fine-Tuning (PEFT) directory, so vLLM, Text Generation Inference, transformers or any other compatible server can use them without knowing miForge exists. Each carries a manifest (published as the checkpoint and adapter manifest schemas) recording what it is, what it came from and how it scored.
When siblings are present, miForge uses them and says so: dataset parts from miDataworks under the midataworks.dataset-version/v1 contract, and scoring through miLLM’s published scoring interface as one provider among several. When they are absent, it imports parts from your own files and scores in-process.
Optional: hot update into miLLM
Normally, improving a served model means writing a checkpoint and having the server reload it. Hot update removes the reload. miForge attaches to the weights a running miLLM server is answering from and updates them where they sit. miLLM pauses serving only while each write is in progress and keeps answering between writes. Only one trainer can hold the attachment at a time. It is the one miForge feature that needs another application, it requires privileged deployment settings, and it is off by default: an operator turns it on for a session and off again afterwards.
Agent control, with approvals
miForge runs a Model Context Protocol (MCP) server with 90 tools in 10 categories, generated from and checked against the live tool registry. Agents can read anything, validate, plan, estimate and dry-run freely, and create packs and drafts. Four kinds of action wait for a person in miForge’s Approvals view: starting graphics-card work (a run, a chain, an evaluation or a merge), attaching to a live miLLM, deleting a pack version or draft, and changing a runtime setting. miForge validates a request with the route’s own code before filing it, so an operator never approves something that would fail. An agent cannot approve its own request, and permanent deletion of archived runs is operator-only.
Status
miForge is at version 0.1.0. Under the suite’s versioning, that means the operator has not yet declared it feature-complete for its first milestone, which will be marked 0.5.0. All three run types, the four signal sources, packs, chains, checkpoints with lineage, hot update, the admin interface and the MCP server are built and have run on real hardware. Some acceptance checks are still open.
Explore miForge
- Manual: hitsainet.github.io/miForge, including domain packs, run types, checkpoints, approvals, hot update and the MCP server
- Source code: github.com/hitsainet/miForge (MIT license)
- The rest of the suite: miSuite · miStudio · miLLM · miDataworks