More intelligence
per GPU.

02 / Evidence-based routing

Quality is specific to the task.

There is no single best model for every request. A model that writes excellent code may be the wrong choice for extracting fields from a Polish invoice. A large reasoning model may be unnecessary for classifying a support ticket.

A cheap answer is not cheap if someone has to correct it. We want model selection to follow evidence: task-level quality, cost, response time, and deployment constraints.

Use the smallest system that reliably completes the job. Escalate when the task demands more.

That is the direction for Fabryka Router: from selecting an available model to selecting a system supported by measured capability.

03 / Built around real work

Polish is a workload,
not a label.

Supporting Polish means more than generating fluent sentences. It means understanding documents, following instructions, working with local terminology, using tools, and knowing when the available evidence does not support an answer.

We want evaluations that reflect that work:

• Polish language, knowledge, and reasoning
• Document understanding and structured extraction
• Coding and tool use
• Long-context retrieval and grounded answers

An aggregate score is a starting point. What matters is whether a model can complete your task.

04 / Research discipline

Research has to earn its compute.

New ideas should start as small, controlled experiments—not expensive commitments. Our research direction is a scaling ladder: test cheaply, compare against a baseline, and scale the ideas whose improvements survive.

A better result on a small model is a reason to investigate. It is not proof that the same method will work at a larger scale.

The same standard applies to checkpoint selection, distillation, quantization, and model merging. We care about the resulting capability, cost, and reliability—not whether a technique is fashionable.

05 / Specialist models

Not every task needs
a general-purpose model.

Much of an AI workflow consists of narrow, repeatable work: classification, extraction, reranking, document cleanup, and routing. Small specialist models may handle these steps more efficiently, leaving larger models for the parts that need them.

We want to build and adapt models around useful jobs—not parameter counts.

The question is not “Can this model replace a general assistant?” It is “Can this system complete this workload reliably, at a lower total cost?”

06 / Accountable data

Better systems need
accountable data.

Distillation and fine-tuning are only as trustworthy as the data behind them. Our standard should be traceable sources, documented permissions, duplicate checks, privacy review, and evaluation data kept separate from training.

Synthetic data needs the same scrutiny. A teacher’s answer is a candidate—not ground truth.

Production feedback also needs clear boundaries. Operational measurements can guide optimization without turning customer conversations into training data. Any use of customer content for research should require explicit permission and defined handling rules.

Improving the system must not come at the expense of the people using it.

07 / Open evidence

Publish the evidence.
Including the failures.

We want technical claims to come with enough context to inspect them: the model, hardware, configuration, workload, and measurement method.

When an optimization improves throughput but harms quality, both results matter. When an experiment fails, that is worth documenting too.

A public research log should show what we tried, what changed, and what did not work. Trust should come from reproducible results—not adjectives.

08 / Where we are going

What exists.
What comes next.

This is a direction, not a claim that every part is already built.