ServicesSix services
Services for sovereign AI operations.
What you can run on Federis, from retrieval and fine-tuning to GPU scheduling and serving, plus a three-step path to get started.
What you can run
Each service is a separately deployable part of the platform, governed by the same identity, policy and audit.
- Retrieval
-
Governed retrieval (RAG)
Search and ground answers in your own documents, with access rules applied before anything is returned.
- Connectors pull documents from object storage, APIs and feeds. Scheduled workers split them into chunks and index them in your vector and keyword stores.
- Every query is scoped to the caller's tenant and authorised sources. Revoking a source stops its content from being cited.
- Answers carry citations, and answers that are weakly grounded in the retrieved text are refused.
- Databases are queried live and never copied into the index.
- Training
-
Fine-tuning and training
Fine-tune open models on approved data without it leaving your boundary.
- Notebook workspaces (JupyterLab and browser VS Code) with approved images, resource limits, idle shutdown and egress denied by default.
- Full, LoRA and QLoRA fine-tuning runs as Kubernetes jobs. Only datasets that passed checksum verification and a second person's approval can be used.
- Each run records its base model, dataset, image, settings and metrics, plus a hash that makes the run reproducible.
- A finished model enters the catalog as a candidate and needs model-risk approval before it can be served.
- Scheduling
-
GPU scheduling and capacity
Share a fixed pool of GPUs between teams and jobs without losing track of who used what.
- GPU training jobs are admitted through Kueue queues with a quota per pool, so work waits its turn instead of failing.
- Idle workspaces stop on their own after their idle limit, and new GPU work is refused once a tenant's budget is used up.
- Model deployments scale with demand through KEDA autoscaling.
- On bare metal, hardware inventory and firmware policy checks run over Redfish, down to the accelerators.
- Serving
-
Model serving
Serve approved models through one API, with fallbacks when a target fails.
- vLLM on Ray Serve for language models, and NVIDIA Triton for text, image and video generation backends.
- Fine-tuned LoRA adapters attach to a running base model and detach again, with no redeploy.
- The gateway adds priority queues, fallback paths and circuit breakers in front of every runtime.
- Only models that cleared approval are served, and a suspended model is refused on every route.
- Agents
-
Agents and workflows
Build agents and multi-step workflows on top of the governed platform.
- Federis Studio: a visual canvas, a Copilot that drafts a workflow from a plain request, templates and a multi-agent runtime.
- Integrations with apps and MCP servers, with human approval before a risky action runs.
- On Federis, every run uses deployed models and the platform's policy, guardrails, retrieval and audit.
- Documents
-
Document and multimodal processing
Let people attach real files to a conversation, not just text.
- Text extraction from documents in common formats through Apache Tika.
- OCR for scanned PDFs and images.
- The service reports exactly what it can do, so the chat only offers features that are actually served.
Getting started
From first workshop to a running, supported platform in three steps.
-
Planning and sovereignty scoping
Our team works with your compliance and platform architects to build a sovereign boundary profile. Data sensitivity classifications, such as secret and top secret, are mapped to authorised physical server topologies.
-
Declarative GitOps bootstrapping
Engineers deploy target configurations using declarative GitOps manifests. The setup establishes system cells, configures workload identities and starts local vector endpoints.
-
Operations and maintenance lifecycle
Choose from flexible enterprise support packages, from standard developer updates to fully managed zero-trust operational pipelines. Our engineers keep systems updated and running 24/7.
Sized to your use case, not to a rack
The Federis control plane is light. It can run on minimal infrastructure, even an everyday system, and the footprint follows the model use case it serves. Add nodes only when availability or throughput calls for it.
Start small
One machine
Run the control plane on a single everyday system next to the model you already use.
Match the use case
Fit to the model
A small model needs a small footprint. Capacity grows with the model and the workload, not before.
Scale to clusters
HA when needed
For a highly available production setup, for example:
- 3 control plane nodes (e.g. 8 vCPUs, 32 GB RAM, 200 GB SSD each)
- 2 redundant GPU nodes (e.g. 16 vCPUs, 64 GB RAM, 1 TB model cache each)
- Kubernetes v1.28+
Plan your sovereign deployment
Share your target environment and we will help you size it and scope the boundary.
- Runs on everyday hardware
- Sized to the model
- Scales to HA clusters