MG-SGLoRA adaptation

MG-SGLoRA is our internal framework for adapting models without retraining everything from scratch. The goal is to keep updates sparse, targeted, and reversible.

Why sparse adaptation

Large models are expensive to retrain and easy to damage. We care about:

• making small, controlled changes,
• isolating those changes per tenant or workload,
• rolling back quickly when an idea fails.

High-level idea

Instead of one monolithic fine-tune, we maintain a base model (Eunoia) and apply a set of sparse, composable updates:

type AdaptationConfig = {
  baseModel: "eunoia-v1";
  dataset: string; // pointer to internal data
  objective: "helpdesk" | "research" | "internal-tools";
  sparsityTarget: number; // how much of the network we touch
};

An adaptation job might look like:

const job = await client.adapt.start({
  baseModel: "eunoia-v1",
  dataset: "s3://bucket/internal-support-data",
  method: "mg-sglora",
  objective: "helpdesk",
  sparsityTarget: 0.02, // touch ~2% of parameters
});

await job.wait();

const tunedModelId = job.outputModelId;

Operational view

From an operations perspective, each adaptation:

• has a clear owner and scope,
• produces metrics against shared benchmarks,
• is tracked in a registry with dependencies and rollback steps.

Internal vs external

Right now MG-SGLoRA is used only by SHV teams on internal data. Questions we need to answer before exposing anything:

• how to prevent one tenant's update from bleeding into others,
• how to give people useful flexibility without opening easy attack surfaces,
• how to price adaptation honestly given compute costs.

Until we have good answers, this remains an internal tool with external behaviour documented, but not promised.