MoTA · Mixture of Tuned Adapters

Tiny tuned specialists.Running together.Anywhere.

Train a tiny specialist for every AI job in your app: one sorts support tickets, one redacts personal info, one routes tool calls. They all run at the same time, on one small model, on one GPU, or right in the user's browser. Same answers as running each one alone. Nothing extra to host.

01

One model to run

All your specialists share a single small base model that loads once. Adding your tenth specialist doesn't add a tenth model. There's still just one.

02

Megabytes, not models

Each specialist is a tiny add-on file called an adapter: a few megabytes, not a whole model. The shared base is ~450 MB; a specialist is ~4 MB.

03

Same answers, zero tradeoff

A specialist gives exactly the same answers in a swarm as it does running alone. Running together changes the speed, never the output.

See it run

Watch a swarm work

Pick 2, 4, or 8 specialists, run them together or one at a time, and watch the clock. The answers never change; only the wait does. Two modes: many separate tasks at once, or one support ticket that fans out to the whole desk and comes back as a single record.

Mode
Specialists
Run
Generating…0.0s
together 1.2s·one at a time 1.6s1.4× faster

4 separate requests, 4 specialists, one shared model. All answering at once.

01Triage0.8B · 3.9 MB
in: I was charged twice this month, please refund one of them
0/2 tok
02PII Redactor0.8B · 3.9 MB
in: Hey it's Maria Chen, reach me at maria@acme.io or 555-0148
0/21 tok
03Tool Router0.8B · 3.9 MB
in: Schedule a call with Dana next Tuesday at 2pm
0/2 tok
04Date Normalizer0.8B · 3.8 MB
in: today=2026-07-25 | next tuesday 2pm
0/4 tok

Representative run scripted from real specialist outputs on Qwen3.5-0.8B. The base model (~450 MB) loads once; each specialist adds ~4 MB. Runs in the Node SDK today; browser support is next.

The problem

Every AI feature is another model

Want AI to sort tickets, redact personal info, and route tool calls? Today that's three models to download, run, and pay for, or one big general model doing three jobs it was never trained for. Each new feature makes your app heavier.

The swarm way

Specialists share one model

In a swarm, each job gets its own tiny specialist, and every specialist shares the same small base model instead of needing its own. One model in memory does all the jobs at once, on a server, a laptop, or right in the browser. Your tenth AI feature costs a few megabytes, not another deployment.

How it works

Three steps to a swarm

Specialists are trained ahead of time, registered once, and ready whenever your app needs them. Nothing trains while your app is running.

01

Tune your specialists

Teach each one its job with Gerbil Tune: feed it examples, get back a small add-on file in minutes. A ticket sorter, a redactor, a router: one specialist each.

Gerbil Tune
02

Register them by name

One line per specialist: registerAdapter(name, source). Gerbil fetches the add-on file once and keeps it ready on the GPU.

API docs
03

They all just run

Send a batch of prompts and name a specialist for each one. They all answer at the same time, sharing the one base model already in memory.

See the API
~450 MB
The whole base model
loads once, shared by every specialist
~4 MB
Each added specialist
a tiny add-on file, not a second model
1 → 32
Streams at once, one laptop
same answers · measured on M4 Max
Quick start

The API is two calls

registerAdapter loads a specialist once, by name. generateBatch takes your prompts plus the specialist for each one. You can mix specialists and the plain base model in the same call.

Every specialist's output is verified to match what it would produce running alone: same answers, zero quality tradeoff. Available in the Node SDK today; browser support is coming.

Full API surface
swarm.ts
01import { WebGPUEngine } from "@tryhamster/gerbil/gpu";
02
03const engine = await WebGPUEngine.create({
04 repo: "mlx-community/Qwen3.5-0.8B-4bit", // the shared base, loads ONCE
05});
06
07// Register each specialist once. Factors are packed into
08// shared GPU buffers; any number of lanes can run them.
09await engine.registerAdapter("support-router", "hf:acme/support-router-lora");
10await engine.registerAdapter("pii-redactor", "hf:acme/pii-redactor-lora");
11
12// One pass. adapters[i] picks each prompt's specialist;
13// null runs the bare base. Same answers as running alone.
14const results = await engine.generateBatch(
15 [routePrompt, draftPrompt, redactPrompt, summaryPrompt],
16 {
17 adapters: ["support-router", null, "pii-redactor", null],
18 sampling: { temperature: 0 },
19 },
20);

Best for jobs you can split up

  • Sorting and routing: tickets, emails, tool calls
  • Pulling many fields out of one document at once
  • Working through a pile of records in parallel
  • Asking several specialists and keeping the best answer
  • Agents that explore a few approaches at the same time

Not a frontier model

Thirty-two small specialists running at once don't add up to one big brain. Open-ended reasoning, long creative work, broad general knowledge: that's still a job for a frontier model.

For the many production jobs you can split up, a swarm of tuned specialists on your own hardware is faster, cheaper, private, and works offline.

Specialists are trained ahead of time. Nothing trains while your app runs.

For engineers

Under the hood

A swarm is one frozen base model plus a set of small LoRA adapters, one per job, all decoding at the same time in a single batched pass on one GPU. Adapters are packed into shared GPU buffers when you register them; each lane in the batch picks its adapter at dispatch, and lanes without one run the bare base in the same pass. Every lane is verified to produce exactly the tokens it would produce running alone. Batching raises throughput (4.31× at a batch of 32, measured on an M4 Max) and never changes the output.

MoE / MoA / MoTA

MoTA members are pre-tuned adapters, not co-trained experts and not full agents. The concurrency mechanism is batched decode itself.

MoE MoA MoTA
Unit of specializationFFN expert inside one networkFull LLM agentLoRA adapter on a shared base
Routing granularityPer token, inside the forward passPer layer of agents, in token spacePer lane, at dispatch
Members trainedJointly, at pretrainingIndependently, arbitrary vendorsIndependently, offline, on one base
Marginal member costA new pretraining runOne more full model's inferenceOne batch lane + MBs of factors
Inspectable membersNo, opaque expertsYesYes, named and individually evaluable
Concurrency mechanismNone needed (one model)None inherent (N full inferences)Batched decode itself

Datacenter serving stacks batch many adapters on big server GPUs. Gerbil runs the same idea anywhere WebGPU runs, including the browser, and lets a single request fan out inside one shared pass.

Every Tune job is a swarm member

Gerbil Tune trains specialists on a shared base, so every specialist you train today already fits in a swarm. Start with one.