Model assignment
Assigning each task to a model by capability, data protection, speed, cost and availability.
Factory is designed to assign tasks to a local or external model based on capability, data protection, speed, cost and availability. The compute load can be spread across several compute nodes.
In brief: Factory is the layer between the application and the models. It is designed to assign tasks to a model, balance load, use defined fallback models and measure quality. The application accesses it through a unified interface.
Assigning each task to a model by capability, data protection, speed, cost and availability.
Local and external models are addressed through a shared interface.
Model capabilities are tested against the task before assignment.
Several compute nodes and models can share the load. Additional components and testing may be needed.
If a model fails, another model can take over according to an agreed rule. This is not an availability guarantee.
Quality, cost and response time are to be measured per model and task and displayed in Studio.
We do not disclose internal rules, weightings or algorithms.
| Criterion | Question | Example |
|---|---|---|
| Task | Classify, extract, summarise, answer, research? | Classification does not need a large model |
| Capability | Can the model handle this task in this language and quality? | Swiss German transcription |
| Privacy policy | Which data may go to which operating location? | Process contracts locally according to the verified data class |
| Speed | How quickly does the answer need to arrive? | Phone: seconds; report: minutes |
| Cost | How much may the task cost? | Bulk classification at low cost, individual cases with precision |
| Availability | Is the model reachable right now and not overloaded? | Fallback to a second model |
The architecture is designed for additional compute nodes. More computing power or capabilities may require additional components, testing and adjustments.
How the compute nodes are set up is explained under AI infrastructure.
Local, specialised and external models. We name specific models and versions in the project, not publicly.
No – we do not promise absolute figures. Fallback and load balancing are designed to absorb outages; we define the scope for each project.
Yes, via the data protection or task rule in Studio: for example, “local only” for certain data classes.
Publicly, we show the principle, layers and data flow at a high level. Internal topology, routing rules, security rules and version states stay internal.
We state the maturity of each building block openly. Phrases such as “is designed to” describe the architecture, not a client deployment. Studio, Agents and parts of Factory run in our own development and operating environment and are continuously extended. Further operating models, multiple nodes and private and local installations will follow step by step.
We review your tasks, data protection requirements and costs and propose a model strategy.