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.
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.
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.
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.
Watch the specialists answer at once
Pick 2, 4, or 8 specialists. Run them the swarm way, all in one batched pass, or one at a time the old way, and watch the clock. Same answers either way; only the speed changes. Try both modes: many separate tasks at once, or one ticket that fans out to a whole desk of specialists and folds back into a single record.
4 independent requests, 4 specialists, one loaded base model — all answering in the same batched pass.
Representative run — scripted from real specialist outputs on Qwen3.5-0.8B. One base (~450 MB) loads once; each specialist adds ~4 MB. The Node engine runs this live today; in-browser batched decode is coming next.
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.
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.
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.
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 TuneRegister 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 docsThey 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 APIThe 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 surface01import { WebGPUEngine } from "@tryhamster/gerbil/gpu";02
03// GERBIL_BATCH=4 GERBIL_BATCH_LORA=104const engine = await WebGPUEngine.create({05 repo: "mlx-community/Qwen3.5-0.8B-4bit", // the shared base, loads ONCE06});07
08// Register each specialist once. Factors are packed into09// shared GPU buffers; any number of lanes can run them.10await engine.registerAdapter("support-router", "hf:acme/support-router-lora");11await engine.registerAdapter("pii-redactor", "hf:acme/pii-redactor-lora");12
13// One batched pass. adapters[i] picks lane i's specialist;14// null lanes decode the bare base. All concurrent, all token-exact.15const results = await engine.generateBatch(16 [routePrompt, draftPrompt, redactPrompt, summaryPrompt],17 {18 adapters: ["support-router", null, "pii-redactor", null],19 sampling: { temperature: 0 },20 },21);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.
The precise claim
A swarm is one frozen base model plus N rank-16 LoRA adapters, each tuned for one job, all decoding concurrently in a single batched pass on one GPU. Adapter factors are packed into shared GPU buffers at registration; each batch lane selects its adapter at dispatch, and mixed adapter/bare-base lanes share one forward pass. Every lane is verified token-exact against the same adapter decoding solo: batching changes aggregate throughput (4.31× at B=32, measured on an M4 Max), never the tokens.
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 specialization | FFN expert inside one network | Full LLM agent | LoRA adapter on a shared base |
| Routing granularity | Per token, inside the forward pass | Per layer of agents, in token space | Per lane, at dispatch |
| Members trained | Jointly, at pretraining | Independently, arbitrary vendors | Independently, offline, on one base |
| Marginal member cost | A new pretraining run | One more full model's inference | One batch lane + MBs of factors |
| Inspectable members | No, opaque experts | Yes | Yes, named and individually evaluable |
| Concurrency mechanism | None needed (one model) | None inherent (N full inferences) | Batched decode itself |
Datacenter stacks like S-LoRA and Punica batch many adapters on CUDA servers. Gerbil runs the same idea anywhere WebGPU runs, including the browser, and adds intra-request fan-out in one shared batched 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.