Matilda, on your GPUs
The models we train in Melbourne, trained further for your domain and delivered into your data centre, so you take the weights, the serving stack, the whole API, or the entire product. It runs behind your own perimeter, on hardware you already have or on a cluster we build for you, air-gapped if the work demands it.
- Melbourne
- Where the models are trained
- Ours
- The weights are ours to hand over
- Your domain
- What we continue training it on
- Five
- Levels of hand-over
Take the stack as far down as you want it
Each level contains the ones before it, and most teams start at the API and move down when their accreditation asks them to, so nobody has to take the whole thing to get started. Plenty of deployments never touch level one, because the racks are already there.
- 01
Hardware
The cluster the rest of it stands on.
Design, build, and validation for the machine itself, on NVIDIA or AMD, to the same blueprint we run for our own training and serving. Where you already have capacity, you skip this level and we start at the weights instead.
- Cluster design and sizing
- Fabric, storage, and provisioning
- Platform and GPU runtimes
- Validated handover against gates
We build it, you own it
Organisations standing up AI capacity for the first time, or adding a tier a cloud cannot give them.
- 02
Weights
The tensors, and the licence to run them.
Model weights, tokenizer, reference inference configs, and the eval harness we use internally, which you serve the way your ML platform already serves models, with nothing else of ours entering your network.
- safetensors + tokenizer
- Reference inference configs
- Internal eval harness
- Commercial licence
You run everything
Teams with their own inference platform and the people to run it.
- 03
Serving stack
A vLLM build tuned to your silicon.
Everything above, plus the serving layer we run in production, meaning the vLLM configuration, kernels, quantised variants, and batching profiles, all benchmarked against the GPUs actually in your racks rather than a reference machine.
- Container images + Helm charts
- Tuned vLLM configuration
- Quantised variants
- Throughput and latency benchmarks
You run the cluster
Platform teams that want production throughput without owning the tuning.
- 04
Matilda API
The whole API, on an endpoint you own.
Everything above, plus the Matilda API itself, covering chat, streaming, structured output, files, agents, sessions, key issuance, and usage accounting, which is the same surface our SDKs already speak, pointed at your hostname instead of ours.
- Full Matilda API surface
- Client and Agent SDK compatibility
- Key issuance and usage metering
- Admin and audit APIs
You run the service
Engineering orgs that want the platform, not the plumbing.
- 05
Whitelabel surfaces
Your name over the whole product.
Everything above, plus the applications, meaning web chat, the desktop workspace, and the CLI, rebranded, wired to your identity provider, and pointed at your own deployment, so what your staff open in the morning is yours rather than ours.
- Web chat, desktop, and CLI
- Your brand on your domain
- SSO through your IdP
- Admin console and policy controls
You run as little as you like
Organisations rolling AI out to everyone, not only to engineers.
The machine as well, built to the same blueprint
Most organisations that want a model inside the perimeter do not yet have anywhere to put it. We design, build, and validate the cluster too, to the same blueprint we run for MC-1 and MC-2, so what lands in your data centre is the architecture our own models are trained and served on rather than a reference design nobody has had to live with.
Both platforms, both in production
NVIDIA
CUDAWe run NVIDIA accelerators in production for inference, and where NVIDIA is what your estate is standardised on, that is what we build for you. It is the most mature serving path in the industry and we treat it as a default rather than an exception.
AMD
ROCmOur own production serving fleet runs on AMD, and getting vLLM to perform properly on ROCm is work most teams start and then abandon. We have done it at cluster scale, which is what makes an AMD estate a first-class option here rather than a compromise.
The two behave differently under training and under serving, and part of the design work is placing each workload where its platform is strongest. Whichever one is already in your racks is the one we support.
We wrote the book on inference
Serving a model well means changing the layers underneath it, and the reason we can do that is that we have taken them apart. What runs in production are our own builds of vLLM and SGLang, tuned for the accelerators underneath them.
- mainarchA from-scratch Rust inference stack for AMD GPUs that talks straight to the Linux kernel driver, with no ROCm, HIP, or HSA runtime anywhere in the path.Read it on GitHub
- From Tin to TokensA free textbook on building an inference stack from scratch: attention kernels, a paged KV cache, the scheduler, multi-GPU collectives, quantisation, and the apparatus that proves any of it works.Read it on GitHub
Compute and accelerators
Nodes sized to the work on whichever accelerator platform you are standardised on, with the training tier kept separate from the serving tier so one workload never lands on the other.
Network fabric
Switching, RoCE, and the NIC layer configured from version control rather than tuned by hand at the console, so the fabric is reproducible along with everything else.
Storage
A shared filesystem and S3-compatible object storage for model weights, datasets, checkpoints, and the observability trail, sized so training does not starve serving.
Bare-metal provisioning
Network boot, image build, and out-of-band control, so a node that is racked and plugged in provisions itself from inventory instead of being installed by a person.
Platform
Kubernetes, GitOps reconciliation, secrets management, an internal registry, and the GPU runtimes, all installed from playbooks that live in a repository.
Observability
Metrics, logs, and traces from the switch port up to the token, stored on the same infrastructure so the evidence never leaves the room either.
Built twice, on purpose
The environment is defined in playbooks rather than in somebody's shell history, and the way we prove that is by building it, wiping it, and building it again from the same playbooks.
The first pass brings the cluster to spec and exposes whatever automation is still missing. Then the machines are flashed back to bare metal and the same playbooks run again, which is the pass that proves there is no snowflake state left in the building. That is the difference between a cluster that was installed once and a cluster you can rebuild on a bad day.
- Every node joined and ready
- Networking and cluster DNS healthy
- Storage pools and classes present
- GPUs allocatable on every accelerator node
- Database, cache, and serving suites passing
- Saturation and failover exercised under load
Your domain, trained into the weights
Retrieval and adapters attach context to a general model at its edges, and they hold up until the task gets genuinely hard. We continue training Matilda itself on your domain and your task, working inside the network rather than around it, so the capability ends up in the weights rather than in the prompt.
Where the change lands
- PromptingThe instruction you send
- RetrievalWhat sits in the context window
- AdaptersA thin layer over attention
- Continued trainingThe weights, and how the model reasons
Each has its place, and retrieval will always matter for facts that change by the hour, but a task the model has to be genuinely good at belongs in the weights.
Domain-adaptive training
We keep training Matilda on your corpus, so the vocabulary, the document shapes, and the conventions of your field are native to it rather than explained to it on every request.
Task post-training
Supervised training on how the work is actually done in your organisation, drawn from the examples and decisions your people have already produced.
Preference and reinforcement
Training against your own judgements and, where the task allows, against a working environment, so the model learns the calls your experts make rather than only the format they write in.
Continuous training
The model keeps learning as your work changes, on a retraining cycle you set, rather than freezing on the day it was handed over.
Sized to your hardware
Distillation down to a model your GPUs can actually hold, keeping the behaviour you trained for instead of the parameter count.
Observation inside the model
Monitoring points between layers that report what the model is doing while it does it, which is what makes an open weight space something your assurance team can inspect.
We trained Matilda, so we know what each stage does
Matilda exists because we trained it ourselves from a base model up, which means we know what each stage of training changes and what it costs to run. Post-training is not one recipe, and the strategy that suits a bank is not the one that suits a defence workload, so choosing it is most of the skill.
The work also needs a cluster, and for material that cannot leave the country, it needs that cluster and the people running it to be here. A model trained specifically for adversarial security review is a different piece of work from one trained to read case notes, and both are the kind of thing we would take on.
It runs on your hardware, not ours
The deployment runs on your hardware, inside your network, under your change process, and the claims below are ones your security team can check for themselves rather than take on trust.
It does not call us
The deployment is built to run without reaching us for anything, so there is no usage telemetry and no licence check against our servers, and your network team can see exactly what it does and does not talk to.
Air-gapped where you need it
Where the accreditation requires it, the deployment is delivered offline, and model updates and patches arrive the same way, signed and verifiable without a network connection.
Your data stays put
Prompts, completions, documents, embeddings, and logs stay on your hardware, and none of it is sent back to us or used to train anything.
Your identity, your keys
Bring your own IdP for single sign-on, your own KMS or HSM for secrets, and your own SIEM for the audit stream, all under your control rather than ours.
You choose what changes
Updates land when your change process says they land, so nothing updates itself underneath you and nothing expires without warning.
Your operators, our engineers
Runbooks, dashboards, and alerts you own and can read, with a named engineer at Maincode to escalate to when you need one.
Built for work that cannot leave the building
- Defence and national security
- Isolated networks and long accreditation cycles
- Banking and financial services
- Customer data under obligations that name the boundary
- Government and critical infrastructure
- Onshore residency and a control set your assessors know
- Health and medical research
- Patient and participant data that stays in the institution
Australian-made, all the way down
It matters who trained the model, who built the weights, and where your traffic goes, and those questions have short answers here, which is the whole reason this offering can exist.
- Maincode, in Melbourne, on hardware we own and operate
- We train them ourselves, which is what makes handing them over possible
- Australian, incorporated and headquartered in Melbourne
- It stays on your hardware, so it is never ours to hold
- Ours, the MC-2 AI Factory in a Melbourne data centre
- A named engineer in Melbourne, in your timezone
Built for the assessment
A deployment inside your perimeter is your system, so the authority to operate is yours to hold, and our job is to supply what your assessors ask us for while they work through it.
- Architecture and data-flow documentation for the deployed system
- Control mapping for the components we ship
- Software bill of materials and signed release artefacts
- Configuration baselines for the environment as installed
- An engineer on the call with your assessors
From the first call to the first token
A Matilda deployment is an infrastructure project rather than a signup, and it moves at the speed of your change board and your assessors, so we plan it that way from the start.
- 01
Scope
What the work is, what it is classified at, and what silicon you already have, and if it turns out you do not need on-premises at all, this is the call where we say so.
- 02
Design
A reference architecture for your environment, covering model sizes, node counts, network topology, identity, and where the audit stream lands, which your security team reviews before anything is ordered.
- 03
Install
We deploy alongside your platform team, on your change process, and whether the site is connected, isolated, or fully air-gapped, the artefacts are the same, with only the delivery differing.
- 04
Accredit
We supply the evidence pack and sit with your assessors while they work through it, and while you hold the authority to operate, our job is to keep the questions cheap to answer.
- 05
Operate
Model updates on your schedule, benchmarked before they land, with a rollback path, and a named engineer to escalate to rather than a ticket queue.
Before you bring it inside
The questions security and procurement ask, answered before the first call, with the rest in the docs.
Bring the model to the work
Tell us what the work is and what you are running on, and we will tell you whether Matilda fits and at which level, including when the answer is that you do not need any of this.