Self-hosted open models · LoRA fine-tuning

An open model,
live in three clicks.

Pick a model. Pick endpoint, or endpoint plus a chat interface. Deploy. Aisty sizes the GPU, provisions dedicated compute, and shows you the exact cost before you confirm. You never touch an instance type.

No instance types. No cluster config. No YAML.

The Aisty Cloud dashboard: active deployments, GPUs in use, projected monthly cost and spend so far, above a prompt to deploy a first model.
Dashboard

How it works

Three clicks. In order.

Hosting an open model usually means choosing an instance type, sizing a GPU, writing a serving config and keeping it alive. There's one right answer per model, so we do all of it for you.

  1. Pick the model

    Grab one from the catalog or bring weights from Hugging Face. Aisty reads the parameter count and picks the accelerator that fits, so you never research an instance type.

    The new deployment screen, step one, with a model dropdown set to qwen3.5-8b and a choice between an API only endpoint and an API plus hosted UI.
    Deployments / New, step 1
  2. Pick what ships

    A bare API endpoint, or an endpoint with a hosted chat UI your team can use this afternoon. Both are locked to your workspace.

    Step two, hardware and cost, showing an auto-sized A100 40GB with infrastructure at 1095 dollars a month, a 20 percent platform fee, and a 1314 dollar total.
    Deployments / New, step 2
  3. Ship it

    Approve the plan and the price. Weights pull, hardware boots, and you get a URL and a scoped API key. Dedicated compute, never shared with another tenant.

    A running deployment serving inference from its endpoint.
    Deployments / Detail

Fine-tuning

Hand it a dataset. Get a tuned model back.

Upload your data, pick a base model, and Aisty runs a single LoRA or QLoRA job. No training loop to write, no cluster to babysit. The accelerator comes from the base model size, the same as hosting.

LoRA

Adapters over a frozen base

Trains a small set of adapter weights while the base model stays put. The fast path when the model already fits its accelerator.

QLoRA

Quantised first, so it fits

Drops the base model to 4-bit before training, so a bigger model tunes on smaller hardware. Slower per step, cheaper per run.

The new training screen, choosing a base model, a dataset and a fine-tuning method.
Training / New
The hardware step for a training run, with the accelerator chosen automatically from the base model size.
Training / Hardware
A completed LoRA run on Qwen3-4B: A100 40GB, three epochs, nine minutes, 29 cents, final loss 0.8353, with the training loss curve and the downloadable adapter.
Training / Complete
  • One job, not a clusterThe run starts, finishes, and shuts itself down. Nothing keeps billing you after it's done.
  • Your data trains your modelYour dataset touches your model and nothing else. It never trains anything for another customer.
  • Hardware picked for youBase model size decides the accelerator, the same rule as hosting.
  • Serve it in one clickWhen the run lands, the tuned model deploys behind an endpoint like any other.

Catalog

Thirteen models. Every one fits.

A short list on purpose. Every model here is sized against the accelerators we run, so nothing loads and then falls over. Need something else? Bring your own weights from Hugging Face.

Model catalog with parameter count, context window and accelerator class
ModelParamsContextRuns on
Qwen 3.5 4B4B128KA100 40GB
Qwen 3.5 8B8B128KA100 40GB
Qwen 3.5 14B14B128KA100 40GB
Qwen 3.5 32B32B128KH100 80GB
Qwen 3.6 4B4B256KA100 40GB
Qwen 3.6 8B8B256KA100 40GB
Qwen 3.6 14B14B256KA100 40GB
Qwen 3.6 32B32B256KH100 80GB
DeepSeek R1 Distill 8B8B128KA100 40GB
DeepSeek R1 Distill 14B14B128KA100 40GB
Gemma 3 12B12B128KA100 40GB
Gemma 3 27B27B128KH100 80GB
Mistral Small 3.1 24B24B128KA100 40GB

Sized for single-GPU serving in fp16. That's why there's no 70B here. If we can't serve it properly, we don't list it.

EU AI Act

We carry the compliance
weight, so you don't stall.

Training a model on your own data is the easy half. The half that kills projects is being asked, months later, how that model was evaluated and on what.

So evals aren't a switch you remember to flip. Every fine-tune holds out a split, scores the model against it, and writes a structured record mapped to the EU AI Act articles it answers to, dropped beside the weights, on the run, ready to hand to whoever asks.

  • Evals on by defaultEvery fine-tune holds out a split and scores the finished model against it. Nothing to ask for, nothing to switch on.
  • A verdict, not a spreadsheetEval loss, perplexity and sample count, resolved into a plain pass judgement instead of a wall of numbers.
  • Mapped to the articlesFindings written against the EU AI Act articles they answer to, as structured JSON you can hand over.
  • Kept with the weightsThe record lives beside the model and shows on the run. Evidence and model never drift apart.
The training list, with every run and its status, method and cost.
Training / All runs

Pricing

Pay for the hours you run.

No seats. No plan to outgrow. You pay for the accelerator hours and the storage your deployment uses, billed only while it runs, and you can tear it down whenever you like. A fine-tune is charged once, for the time it takes. The price you approve is the price on the invoice.

  • Workspaces and rolesOwner, admin, editor and viewer, enforced on every route.
  • Scoped API keysLocked to a workspace, revocable, shown exactly once.
  • Object storageDatasets and model artifacts, billed per GB-month.
  • Passwordless sign-inPasskeys. No password to leak.

Pick a model.
Leave with an endpoint.