Login AI
Deploying sovereign models inside your perimeter
We deploy open LLMs inside your perimeter: hardware sizing, quantization, data isolation, and a mode without external APIs. Accuracy matches the cloud on typical tasks.
Open models run on your hardware, and data stays inside the perimeter.
Pricing
from ₽3,000,000
per project
This is the lower bound of a project. We scope the exact quote after a brief: it depends on volume and the number of integrations.
Capabilities
Data inside the perimeter
Requests and documents never reach an external provider: the model runs on your hardware.
Hardware sizing
We size GPU, memory, and throughput for the model and peak load, with no guesswork headroom.
Quantization
We compress the model to fit available memory and measure the quality drop on your tasks.
Fallback loop
Under overload a request falls back to the cloud by rules instead of failing with an error.
From request to result
1
Requirements audit
We fix the model, tasks, and constraints: where accuracy matters and where speed is enough.
2
Hardware sizing
We size GPU and memory for the model and load, and price ownership against the cloud.
3
Deployment
We bring up inference, set isolation and observability, and close external calls.
4
Quality benchmarks
We compare the local model with the cloud one on your task set and record the gap.
Check if it fits you
Good fit
Data must not leave
Regulatory or commercial limits ban an external API: the model stays inside.
Predictable load
The peak is known: hardware is sized for it, not for an abstract maximum.
Not a fit
You need the latest frontier model
If the task needs a model not available as open weights, the local option will not fit.
No GPU and no site
Without dedicated hardware, deployment turns into a separate infrastructure project.
What you get
0
requests to an external API
Requests and internal documents were handled by a local model; external calls out of the perimeter were eliminated.
Local by default
Data in the perimeter
Documents, correspondence, and requests are handled on your hardware. Data stays in the perimeter, so external calls disappear.
Hardware amortization
Predictable cost
A token bill is replaced by hardware amortization and power. The cost becomes predictable and stays flat under peak load.
The local network
Latency without the provider
The model answers from the local network, so latency stops depending on the provider. Network jitter disappears.
A planned update
Version control
A model update is planned and tested on your own task set. Version control stays with you, so production holds zero surprises.
What the delivery includes
A task and model audit
A task and model audit shows where maximum accuracy matters and where speed is enough. The configuration choice rests on facts.
Hardware sizing
We count GPU, memory, and throughput for the model and peak load. Hardware sizing sets the performance ceiling.
Quantization and measurement
We compress the weights to fit memory and measure the drop on your tasks. Quantization and measurement show the price of compression.
An isolation loop
External calls closed, rights, logs, and spare replicas configured. An isolation loop keeps data inside.
Acceptance
We compare with the cloud model on your set and hand the metrics to your team. Acceptance confirms the result before operations start.
How the system is built
Perimeter isolation
External calls are closed: documents, correspondence, and requests are handled on your hardware, and only agreed metrics leave the perimeter.
Local inference
Inference runs from the internal network, so the answer arrives on a local network path. Provider status and external channel jitter stay out of the picture, and you get steady response time under load.
Quantization for the hardware
Quantization compresses the weights to fit the card memory, and it adds a measured quality drop. We measure that drop on your tasks, so you see the real price of compression on your own dataset.
A planned update
A new model version is planned and tested on your set, then rolled out as a canary by plan. Production receives predictable changes, and you control the version and the rollout moment.
Where the solution pushes back
- 01
Open models trail on complex reasoning
Open models trail frontier on complex reasoning: where maximum accuracy is required, the local option loses.
- 02
A stalled GPU stops the loop
Hardware and its upkeep are on you: a stalled GPU stops the whole loop, so spare capacity has to be planned.
- 03
Quantization lowers quality
Quantization saves memory and adds a quality drop: measure it on your own data, because on other datasets the drop looks different.
- 04
A model update is a project
A model update is a separate project: prompt retraining, repeat benchmarks, and canary rollout run as sequential stages.
- 05
The cost of hardware
We size the cost of hardware up front, spare capacity and downtime included. Owning hardware includes spare capacity for peak load.
- 06
Power and cooling
Over the long run power and cooling give a visible share of the bill. Power and cooling are counted together with the cost of ownership.
- 07
Model updates
Moving prompts and repeating benchmarks during a model update is a separate project. Model updates are a separate budget line.
- 08
Loop operations
Monitoring, on-call, and GPU-failure response land on your team. Loop operations need people and a support process.
Technologies
The technologies we use in our work and their role in a project.
Models and runtime
Open models Qwen and Llama run on vLLM inside Kubernetes, with state and cache stored in PostgreSQL.
Cost calculator
This is an indicative range, not a quote. We scope the exact estimate after a brief: it depends on volume and the number of integrations.
Nodes
Model size
Fine-tuning
Add-ons
Support
Year one: updates and monitoring, a reply within 2 business days.
Service
Deploying sovereign models inside your perimeter
The estimate covers our team's work. Hardware, third-party service licences and travel are added on request.
Estimated cost
₽4M
Timeline
8 wk
Frequently asked questions
Will accuracy match the cloud?
On typical tasks yes; on complex reasoning open models are weaker. We show benchmarks before you choose.
What hardware is needed?
It depends on the model and load: from one GPU for a pilot to a cluster under flow. We size it in advance.
Can we mix local and cloud?
Yes. Simple and closed requests run locally; complex ones go to the cloud by rules and with de-identification.
How long does the launch take?
A pilot on one GPU takes two to three weeks; a production loop starts at eight weeks.
Who is responsible for the hardware?
You own the perimeter and the hardware; we own the architecture and the launch. Upkeep and spare capacity can move to us under a separate agreement.
What about model updates?
An update is a project of its own: we move the prompts, repeat the benchmarks, and roll out the new version with a canary, not a weights swap overnight.
What teams add to this service
Ready to discuss your task?
Leave a request – we'll get back with a proposal and a preliminary estimate.
Contact us