Fine-tuning.
Customer-controlled fine-tuning and adapters on data that never leaves your boundary, with eval gates.
Adapt Aether to your domain with full and parameter-efficient fine-tuning — on data that stays in your boundary, gated by evals so a tuned model is measured before it ships.
- Category
- AI & ML
- Deployment
- Managed → air-gapped
- Governance
- IAM · encryption · audit
The model is strong out of the box. It still doesn't know your domain, your tone, or your data.
A foundation model is a generalist. Your support replies have a house style; your contracts use terms of art; your defect taxonomy is yours alone. Fine-tuning adapts the model to that — and the decision that actually matters is where the training data lives. On a hosted fine-tuning API, adapting the model means uploading your proprietary data to a third party. On Aether, fine-tuning runs inside your boundary: the data never leaves, and the tuned weights stay yours.
Full fine-tuning or adapters — pick the cost and the depth.
For a light touch — tone, format, a domain vocabulary — parameter-efficient adapters (LoRA-style) train in hours and cost a fraction, and you can keep many of them for many tasks against one base model. For deeper adaptation, full fine-tuning is there. Either way the base is an Aether model, and the result serves on the same platform with the same version pinning and observability as everything else.
Eval-gated: a tune ships because it's measured better, not because the job finished.
The failure mode of fine-tuning is shipping a model that's better on the training distribution and worse everywhere else. Aether gates every tune on your evaluation sets — quality, safety and regression checks run before promotion, and a tune that doesn't clear the bar doesn't ship. Every tune is hashed and registered, so you know exactly which data and which base produced the model in production, and you can roll back to the last good one in a click.
Fine-tune on data that never leaves the boundary, and gate the result on your own evals before it can serve.
import { aether } from "@aether/sdk";
const tune = await aether.fineTuning.create({
base: "aether-40b",
method: "lora", // or "full"
data: "lake.support_replies", // stays in your boundary
evalSet: "lake.support_eval", // gate before promotion
promoteIf: { qualityGain: ">= 0.03", safetyRegression: "none" },
});
// Serves only if it cleared the gate — else it never ships.
await tune.promote();The training data is a table in your lake, not an upload to a third party. The tune promotes only if it beats the base on your eval set without a safety regression — so "better on training data, worse in production" can't quietly ship.
Three steps to running.
Train inside your boundary; nothing leaves the perimeter.
Full fine-tuning or LoRA-style adapters for cost and speed.
Eval gates block a regression; every tune is hashed and registered.
Fine-tuning, in full.
Full fine-tuning or LoRA-style adapters for cost and speed.
Train inside your boundary; nothing leaves the perimeter.
Regression and safety evals block a bad tune from shipping.
Every tune hashed and registered for reproducibility.
Provision it in a few lines.
Every service is reachable from the same SDK, CLI and infrastructure-as-code — one identity, one bill, one audit trail across the whole catalog.
import { aether } from "@aether/sdk";
// Fine-tuning on Aether Cloud
const res = await aether.ai.fine_tuning({
model: "aether-40b",
input,
stream: true,
});
for await (const token of res) process.stdout.write(token);At a glance.
- Methods
- Full + adapters (LoRA)
- Data
- Stays in your boundary
- Gating
- Eval-gated promotion
- Versioning
- Hashed, registered
- Base
- Aether 7B / 40B / 280B
Built for real work.
Domain and tone adaptation
Task specialization
Proprietary-data customization
On one model, not stitched together.
The usual stack runs fine-tuning in one product, the model in another and the data in a third — and the seams between them are the cost. Aether Cloud runs it on the same platform that serves the model, governs your identity and deploys into your boundary, with the rest of the catalog one hop away.
No stitching a vector DB to one place, a warehouse to another and a model to a third — fine-tuning sits next to the rest of the catalog, one identity, one bill.
The provider that runs Aether runs your fine-tuning — so the data and the model never leave the same governed boundary to talk to each other.
Need a capability that isn’t here yet? The model writes and deploys it into the same boundary — the catalog is a starting point, not a ceiling.
Good to know.
Adapt Aether on data that never leaves your boundary, gated by evals — not a black-box upload.
No — training runs inside your perimeter.
Both — adapters for cost and speed, full fine-tuning for deeper adaptation.
Your boundary, your choice.
Pairs well with.
The simulation-native foundation model itself, served as an API — the core every other service builds on.
Low-latency, streaming inference for every model size, with pinned versions and structured output.
Pre-wired multi-node GPU clusters with scheduling, checkpointing and fault tolerance.
Managed notebooks wired to the data platform and GPU compute for exploration and analysis.
Model and prompt registry, evals, deployment and drift monitoring — versioned and auditable.
Build a working app, agent or simulation by describing it, deployable in a click. See Aether Studio.
Run Fine-tuning on Aether Cloud.
Customer-controlled fine-tuning and adapters on data that never leaves your boundary, with eval gates. Deployable managed, in your VPC, on-prem or fully air-gapped — talk to us about the configuration your workloads and your boundary require.