Search

What are you looking for?

Search our services, use cases and practical insights.

Enter at least 2 characters

Popular starting points

AI explained simply

Small or large, open-weight or proprietary AI model?

The most capable model is not automatically the best choice. The right model meets the task's quality threshold with acceptable cost and an operating model that fits the organisation.

The short answer

Model choice balances task quality, language and modalities, latency, cost, context needs, data processing, adaptability and operational responsibility. A small language model (SLM) can be a better fit for narrowly bounded language tasks than a larger LLM.

In brief

  • Large models often cover more tasks but generally require more time and budget.
  • A small language model (SLM) can be faster, cheaper and easier to run locally or on controlled infrastructure for clearly bounded tasks.
  • Open weights provide more technical control but transfer more operational and security work to the organisation.
  • Selection should use in-house evals and account for a later model change.

What do small and large mean?

Model size is not a universal quality measure. There is no universally binding parameter threshold separating a small language model (SLM) from a large language model (LLM); the terms describe a relative size and capability class. Larger or more capable models may handle complex instructions and varied tasks better. For stable classification, extraction or short summaries, a smaller specialised model can be equally good or more appropriate.

  • Task quality on real cases
  • Response time and available throughput
  • Cost per completed case rather than token price alone
  • Required languages, modalities, context and tool support

When does an SLM fit, and when does an LLM fit?

The decision should follow the tested task rather than the acronym. SLMs typically require less memory and compute, respond faster and are more feasible on devices or controlled infrastructure. Larger LLMs often provide broader language coverage, transfer and handling of complex instructions, but require more cost and operational capacity.

A smaller model is not automatically more privacy-friendly: deployment, data flow, logging and contract still determine that. Nor is a larger model automatically better. Both must be compared on the same representative cases and explicit failure boundaries.

When does an SLM fit, and when does an LLM fit?
Decision questionSLM often fitsLarger LLM often fits
TaskStable extraction, classification or tightly defined short textsVariable tasks, complex instructions or broad language coverage
OperationLow latency, edge, device or controlled self-hostingScalable managed service or capable infrastructure
Quality riskNarrow and readily testable task spaceDifficult cases requiring more context and generalisation
Useful testDoes the SLM reliably clear the defined minimum quality?Does the measurable quality gain justify cost and dependency?

How do open-weight and proprietary services differ?

With available model weights, an organisation can control hosting and technical configuration more directly. That does not necessarily mean the training data, licence or development are fully open. A managed proprietary service reduces infrastructure work but creates dependencies on contracts, regions, interfaces and product changes.

  • Review the licence and permitted uses precisely
  • Assign hosting, updates, security and scaling responsibilities
  • Assess data flow and available regions for each service
  • Keep prompts, evals and configuration exportable

Which criteria belong in a model comparison?

Public benchmarks are an indicator but rarely represent your process, language and failure impact. Companies need a versioned test set and must assess technical and contractual requirements together.

  • Correctness, completeness and stability for the specific task
  • Critical failure types and behaviour when information is missing
  • Latency, availability, limits and total cost
  • Data processing, retention, training and subprocessors
  • Version pinning, change notices and fallback options

Why can a model portfolio make sense?

Not every request needs the same level of capability. A platform can route simple tasks to a smaller model and difficult cases to a stronger one. This requires clear rules and evals; otherwise routing only adds complexity and hides quality differences.

  1. Step 1

    Set minimum quality

    Define acceptable performance and prohibited failures for each task class.

  2. Step 2

    Compare candidates

    Test models under identical data, prompt and tool conditions.

  3. Step 3

    Include operations

    Assess cost, latency, outages, updates and support.

  4. Step 4

    Preserve replaceability

    Avoid unnecessary coupling of application logic, evals and data access to one model.

Example from day-to-day business

Example: two models in a document process

A small language model (SLM) extracts standard fields from a high volume of documents. Only ambiguous cases and complex reasoning go to a more capable LLM. Both are checked against the same domain rules; critical deviations are sent to a specialist. The company measures cost and quality per case, not just model pricing.

What to remember

Choose the smallest operationally suitable SLM or LLM that reliably clears your quality threshold. Keep the comparison reproducible and plan for change from the start.

Sources and further reading

These primary sources provide further detail on definitions, technical foundations or responsible use.

Content reviewed

Would you like to apply this to your situation?

Together, we clarify what makes sense for your process, data and systems – in plain language and without unnecessary complexity.

Discuss Your Project