Native training plans and jobs

These APIs require the matching development native runtime and optional capabilities. Published Aner 0.0.5 runtime packages and the published editor do not supply these additions. This documentation publishes no runtime, editor package or model weights. See release status and Downloads for separately verified artifacts.

aner.gen adds immutable TrainingPlan, owned TrainingJob, and completed or safely stopped TrainingResult values around the existing native model trainer. Existing synchronous training, fine tuning, freezing, LoRA, checkpoint/resume and .anergen formats remain supported.

The first local executor admits one active training job per process. It is native C++ work, with no separate training subprocess, model service dependency, network swarm or automatic computer enrollment. The existing small model architecture/resource boundaries remain in force. This increment does not implement arbitrary modern pretrained imports, billion parameter training, QLoRA, a new optimizer, or distributed model aggregation.

Prepare, execute, publish

The complete example creates a native model, selects LoRA targets, builds a bounded fine tuning plan, waits for execution, and publishes both a checkpoint and adapter to new paths.

let plan = gen.fine_tune_plan(adapted, training, validation,
    steps: 100, batch: 2, rate: 0.001, seed: 71)
print(plan.memory_summary())
let job = plan.start()
let result = job.wait()
print(result.validation_loss())
result.save_model("tuned.anergen")
result.save_adapter("tuned.anerlora")

The first three inputs are a LanguageModel, training role TokenCorpus and validation role TokenCorpus sharing the exact model tokenizer. Fine tuning starts a new optimizer run and preserves parent/model/data lineage. The optional complete form adds clip_norm, warmup_steps and weight_decay, matching native training semantics. Existing immutable inputs remain unchanged.

The plan is prepared synchronously; start launches owned native work. The job captures its resource policy and uses an independent mutable training state. wait returns its result or propagates the training failure. Development inspection retains opaque handles rather than dumping data, weights, or asynchronous mutable state. Explicit summaries remain ordinary inspectable Strings.

Plan preparation rejects exact content overlap with the proposed training corpus and inherited model/tokenizer lineage before starting work. These checks do not detect paraphrases or related subjects. This job API retains the existing native next token objective; supervised CSV ingestion and gradient accumulation are not implemented by this increment.

API

Module forms are also available. Existing model methods retain their parameter labels; new training resource methods use plan, job, or result in module form.

Interruption and continuation

Training stop/checkpoint controls run at committed optimizer update boundaries. A partial update is not published as completed state. A stop request is not an immediate interrupt of every accelerator kernel. Job destruction requests stop and joins owned work; a training thread is not detached from its lifetime owner. Even an immediate stop can perform one complete optimizer update.

A safely stopped result has completed() == false. Job status is stopped when the recoverable model state is only in memory, or checkpointed when a checkpoint was published. Inspect last_checkpoint() for its actual path. Configure checkpoint output or call job.checkpoint explicitly to retain it across processes.

let durable = plan.checkpoints("checkpoints", every: 10)
let job = durable.start()
job.request_stop()
let partial = job.wait()
job.checkpoint("stopped.anergen")

let next = gen.resume_plan("stopped.anergen", training, validation, steps: 100)
let continued = next.start().wait()

The checkpoint directory must exist. Files are published to new destinations and existing files are not overwritten. Each interval, final update and requested stop saves step-XXXXXXXX.anergen using its global optimizer update count. Choose a fresh checkpoint directory for an independent run. Automatic checkpoint publication is a run obligation: a publication failure fails the job. A manual checkpoint failure is reported to that caller. Atomic complete file visibility is distinct from a power loss durability guarantee.

A native checkpoint contains the optimizer, schedule, random progression, corpus identity/order, data cursor, counters, parameter selection and implementation identity described in Checkpoint and exact resume. Exact resume checks those contracts. Changing data, policy, backend or implementation is not silently reinterpreted as exact continuation. Adapter exports alone do not contain resumable optimizer state.

Native checkpoints retain their current 64 MiB bound. Sharded large model artifacts, modern training backends and cross representation adapter deployment require their own validated compatibility paths. A .anerlora adapter is not automatically a GGUF adapter for llm.load.

These contracts preserve useful building blocks for later collaborative execution: immutable inputs, plan identities, bounded work, coherent checkpoint boundaries, and explicit outputs. They do not implement the future participation network or an aggregation algorithm.

For supervised CSV data, gradient accumulation and supported floating dense Llama imports, use pretrained Llama training. Its current calls are synchronous and do not return these bounded TrainingJob values. Return to the generative module reference for the existing model contracts.