Centram Blog
← All posts

Forge · Overview

Centram Forge: Manufacture a Module on Your Own Laptop

Point Forge at a local dataset, train a LoRA genome on it, read the base-versus-genome answers side by side, and package a .centram-module you keep. Five stages, all of them on your machine.

Most ways to specialize a language model ask you to send your data somewhere: upload your documents, your transcripts, your customer history, and trust that the provider trains on them responsibly and hands back an endpoint you rent. Centram Forge inverts that. It runs the whole manufacturing pipeline on your own machine and emits a portable artifact you keep.

What you manufacture: a genome, packaged as a module

A genome is a set of LoRA weight deltas — the small difference between a base model and a version fine-tuned on your task. It runs from a few hundred KB to tens of MB, depending on LoRA rank and base-model size; portable and composable. A module wraps that genome with a manifest (its identity, base-model requirement, domain, I/O contract) and an evaluation card (before/after metrics on your own prompts). Forge writes both into a single .centram-module file.

The pipeline

Forge's Studio walks the same five stages whether you click through them or script them headless:

  1. Import — point at a local dataset. It is referenced into an isolated workspace and never copied off the device.
  2. Configure — base model, LoRA rank / alpha / targets, learning rate, steps, precision. Everything is editable as config-as-code, so a run is reproducible and shareable.
  3. Train — Forge drives a dedicated, isolated build daemon on your machine; logs stream into the console as the LoRA trains.
  4. Evaluate — the heart of the tool. Forge runs your test prompts through the base model and your freshly-trained genome side by side and shows the before / after: does this adaptation actually help?
  5. Package — assemble the .centram-module, ready to load into any Centram daemon.

Local-first by construction

Isolation is not a setting you remember to switch on; it is the architecture. Each project spawns its own build daemon with a private data directory and its own ports, bound to loopback. Your dataset is read inside that workspace. The only thing that can ever leave — if and when you choose to share — is a differentially-private genome delta, never the raw data.

The Lab: operate on genomes directly

Beyond a single training run, Forge's Lab exposes the genetic operators that make Centram more than a local fine-tuner. You can mutate a genome, or crossover two of them with a chosen merge strategy — linear, slerp, ties, or dare_ties. SLERP interpolates along the weight-space hypersphere to avoid the loss barrier a naive average falls into; TIES and DARE reduce interference between merged parameters. Pick an operator, pick two parents, and measure the offspring's fitness.

CLI and SDK

Everything the Studio does, the centram-forge CLI does headless: forge init, forge build, forge package. And the daemon's genome, training, and substrate APIs are reachable from Python, JavaScript, and Dart SDKs — so manufacturing a module can be a step in a CI pipeline, not just a desktop session.

The honest frame matters. Centram's larger thesis — that models can improve by exchanging genomes across a decentralized network when updates pass validation — is still only partially supported at small scale; the merge operator, not the idea, was the early bottleneck, and that is exactly what the Lab now exposes. But Forge does not depend on that thesis to be useful today. Its immediate value is concrete: a private, reproducible way to adapt a model to your data and ship the result as an artifact you own.

Go deeper

Go deeper