A model you own, not an API you rent
We build and operate Small Specialized Language Models: intelligent systems that live in your infrastructure, know your domain and are evaluated with real criteria. Without being at the mercy of someone else's pricing, usage policy or model behaviour changing overnight.
An SSLM is a right-sized open-weight model, tuned to your domain, grounded in your knowledge and served behind a standard API. Not a chatbot on top of your documents: software with memory, evaluation and operation.
Weights, corpus and traces stay inside your perimeter. EU data residency and no queries leaving towards third parties.
Spend moves from variable cost per token to known infrastructure. Product success stops punishing the invoice.
Every version runs against scenarios with an expected answer. If a critical query breaks, the release does not ship.
Three pressures that show up once intelligence stops being a demo
This is not an ideological argument about vendors. It is what happens when an intelligent feature starts having real users, real invoices and real consequences.
The invoice scales with success
While it is a pilot, cost per token is irrelevant. At volume, the same design turns every new user into variable spend nobody budgeted for.
Your knowledge leaves the perimeter
Internal documentation, contracts, incidents and customer conversations travel to a third party. In many contexts that is no longer a preference: it is a requirement you have to justify.
You depend on decisions you don't control
Pricing, rate limits, deprecations and behaviour changes arrive without notice. Your product ends up inheriting someone else's roadmap.
What we actually build
An SSLM is not a single artifact. It is six layers, and each one is a decision that gets documented and can be audited.
Open base model
An open-weight model sized for the problem, not the largest one available. Chosen on domain quality, licence and cost to serve.
Domain corpus
Your knowledge turned into usable material: what goes in, under which permissions, under which licence and who owns its quality.
Specialization
Domain adaptation with lightweight adapters, no training from scratch. The model learns your vocabulary, your formats and how you answer.
Grounding
Retrieval over your corpus so answers cite concrete sources. We would rather it says “I don't know” than invent with confidence.
Continuous evaluation
Scenarios with expected answers, critical cases that block a release, and a report someone who doesn't write code can read.
Gateway and operation
An API compatible with the industry standard, per-project keys and metering of usage, latency and cost. Observability from day one.
When owning a model pays off
The argument is not “always self-host”. It is that there is a volume beyond which variable cost stops making sense. Move your figures and find your break-even point.
Millions of tokens processed per month, input and output combined.
Simplified model: 50/50 split between input and output, 720 service hours per month and indicative list prices. In a Discovery we replace this with your real rates and traffic.
At this volume standing up infrastructure doesn't pay yet. The honest move is to wait, or start with a tightly scoped case.
If your volume sits below the break-even point, we will say so: stay on a third-party API and come back when traffic justifies it. An SSLM that doesn't pay for itself is not a good project.
It plugs in, it doesn't embed
The SSLM lives outside your codebase and is consumed over an API compatible with the industry standard. You change the base URL and the key; the rest of your product never notices.
- A contract compatible with the clients and SDKs your team already uses. No proprietary libraries.
- It coexists with external vendors: you can route by query type, cost or criticality.
- Per-project keys, with usage metering and traces to audit who asks what.
- If you want to roll back tomorrow, you roll back. Reversibility is part of the design.
curl https://sslm.internal/v1/chat/completions \
-H "Authorization: Bearer $PROJECT_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "atlas-ops-8b",
"messages": [
{ "role": "user", "content": "..." }
]
}'Three formats, in this order
We don't sell a closed model or a bundle of hours. First we decide whether it makes sense, then we build what holds up, and we stay operating it only if that adds value.
Discovery
Weeks to answer whether an SSLM makes sense in your case, with numbers and risks on the table.
- Knowledge inventory and legal viability of the data
- Use scenarios and measurable quality criteria
- Cost model with your volume and your break-even point
- An honest recommendation, including not doing it
Build
We build the whole system: corpus, specialization, grounding, evaluation and gateway.
- Processed, traceable corpus with clear permissions
- Domain adaptation and grounding in sources
- Your own set of evaluation scenarios
- API, per-project keys and usage metering
- Documentation of the model and its limits
Operate
We support the life of the system: quality, cost, corpus evolution and handover to your team.
- Continuous evaluation and regression control
- Tracking of cost, latency and usage per project
- Corpus updates and base model versions
- Training and handover so you can run it without us
How you know it works
The hard question is not whether it answers well in a demo. It is what happens the day it answers badly and someone is waiting on the other side.
- 01
Scenarios with expected answers
We define together which questions the system has to get right and what counts as an acceptable answer. Quality stops being an opinion and becomes a number.
- 02
Critical cases that block a release
Some answers cannot fail. If one of them breaks, the version does not reach production even if everything else improved.
- 03
Answers with a source
Every answer can show which fragment of your knowledge it came from. Without a source, we prefer a clear no to a convincing invention.
- 04
Model documentation
Intended use, data, known limits and how to operate it. A document you can show a client, an auditor or a technical committee.
What people ask us before starting
- Won't it be worse than a large model?
- On general tasks, yes. In your specific domain and grounded in your knowledge, a well specialized small model usually gets more right and answers faster. We measure it before claiming it.
- Do I need a data team?
- Not to start. You need knowledge written down somewhere and someone who can say which answer is correct. We handle the rest and hand it over.
- What if a better model ships tomorrow?
- That is expected and the design assumes it. The corpus, the evaluation scenarios and the gateway are yours; the base model is replaceable. That is where value accumulates.
- How long until production?
- A Discovery is measured in weeks. A first production system with a tight scope, in months. We prefer one case genuinely solved over a whole platform half-built.
- Does it replace our current vendor?
- Not necessarily. Coexistence is the norm: your own model takes the repetitive and sensitive volume, the external vendor keeps what genuinely needs a generalist model.
- Who owns it?
- You do. Corpus, adapters, evaluation scenarios and infrastructure are yours, and handover is planned from the start. We don't build dependency on us.
See if your project fits
Request a fit check