LexiSuite Docs
HomeLive demoDownload

Ternary models in Training

Status, 11/11/2026: experimental. Loading ternary GGUF files and decoding them on the CPU is tested. The GPU kernels have not been run on a card, training covers a single layer on the CPU, and conversion has not been run on a full model. Ternary models recall facts worse than the model they were made from.

Ternary conversion and recovery are opt-in. They run in a separate managed job store and do not change normal GGUF inference, LoRA training, or the rest of the classic Panel. Only authenticated administrators may use the controls.

Use

  1. Open Training → Guided training tasks → Ternary: convert, continue training, export, serve. Import the source model into the managed library and the calibration/training dataset into Models or Uploads first.
  2. Select Convert to ternary or Continue training (ternary). Use Check memory fit to request the native planner's current free VRAM/RAM fit, selected rank, and micro-batch. A run that does not fit is rejected, rather than silently spilling onto CPU or borrowing a guessed memory budget.
  3. Explicitly confirm memory use and quality implications, then start the job. The Panel invokes lexi-train ternary convert|recover --job PATH only for the selected task. The worker receives a JSON job file under the Panel's own lexi-ml/train/ternary-runs directory.
  4. Refresh the page to inspect native progress (step/total, loss, time left). Use Stop to write a durable cooperative STOP request. A worker that does not cooperate is terminated by its supervisor. Use Resume from a saved checkpoints/latest.json to create a new run, preserving the original.
  5. Use Export GGUF on a completed run. A new native ternary export job must produce a readable, regular GGUF artifact inside its own run directory. Export never overwrites the original. Use Serve only on a verified export; confirm the target instance restart. The existing instance-control service saves the new model and restarts LexiEngine, with a setting rollback attempted if the restart is not confirmed.

Worker integration contract

The installed native CLI implements lexi-train ternary convert|recover|export --job <path> --plan as a read-only preflight returning version-1 JSON with fit (card, host, no-fit), rank, micro_batch, and required_device_bytes, available_device_bytes, required_host_bytes, available_host_bytes. The last four fields must reflect available memory at preflight, not a fixed profile. Missing, invalid, stale, or contradictory worker reports prevent starting a run. The Panel calls preflight again at submission; a preview is not permission to bypass the later admission check.

For execution the worker reads the job JSON, writes native artifacts beneath out_dir, and streams JSONL progress to stdout, e.g. {"event":"progress","step":3,"total_steps":20,"loss":2.4,"eta_seconds":70}. Plain step=3 loss=2.4 eta_seconds=70 records are also understood. Completion requires a {"event":"done","artifact":"..."} record and an actual nonempty regular artifact under the managed run folder. A successful process exit on its own is not proof of a completed model. Workers may checkpoint under their run's checkpoints/latest.json, and must honor STOP between units of work. The Panel's durable results survive a Panel reload; if a Panel process is restarted mid-job, liveness is uncertain and the job is marked interrupted instead of falsely completed.

The endpoints are POST /api/training/ternary/plan|start|stop|resume|serve and GET /api/training/ternary/run?id=...|runs. The form UI uses the same authenticated server-side POST/CSRF protection as other classic training forms.

Quality and limitations

Ternary costs most on factual recall. Compare held-out loss and factual question performance against the original before deploying; the Panel does not claim equivalent model quality or runtime speed. A completed export must still be supported by the installed LexiEngine ternary backend and pass its load-time memory and format checks. GPU, Windows, and macOS execution require native workers and engine builds on those systems; the Panel does not claim hardware qualification from a local file or a planning report alone.

The ternary CLI and memory planner are delivered by their respective parallel work packages. If either is not installed with the stated preflight and job contract, the Panel refuses to run rather than guessing support. Automatic adoption of checkpoints after an unverified crash is deliberately disabled.

← UpdatingFirst Boot →