Small Is Not Open.

The debate over AI model selection is often framed as a choice between two camps. On one side are large, proprietary models delivered through commercial APIs. On the other are smaller, open models that can be run locally, customized, and controlled by the organization using them.

There are real tradeoffs between those approaches, but the framing is misleading because it combines several independent characteristics of an AI system into a single comparison. A model can be small and proprietary. It can be large and open-weight. An organization can possess a model's weights without meaningfully controlling the system in which the model operates. It can also rely on a closed model while maintaining strong control over the application's data, permissions, evaluation process, and authority boundaries.

Most importantly, none of those characteristics establishes whether the system is reliable enough for the work it has been given.

A better way to think about model selection is to separate four questions that are often bundled together: How much capability does the task require? What parts of the model are accessible? Who controls the operating environment around the model? What evidence supports trusting the resulting system for this particular use?

These questions are related, but they are not interchangeable. Keeping them separate leads to a more useful way of thinking about AI architecture.

Model size is an operating characteristic

The distinction between a small language model and a large language model sounds precise until we try to define it.

There is no generally accepted parameter count at which an SLM becomes an LLM. Parameter count itself is also an increasingly incomplete description of capability. Training data quality, model architecture, distillation, quantization, post-training methods, mixture-of-experts designs, and specialization can all change what a model is capable of at a given size.

Microsoft's Phi-3 work is a useful example. Phi-3 Mini was a 3.8-billion-parameter model that Microsoft reported as competitive with substantially larger systems on several benchmark measures. The important lesson is not that a 3.8-billion-parameter model is equivalent to every larger model. It is that model capability cannot be inferred cleanly from parameter count alone.¹

Smaller models can offer lower latency, lower cost, and task-specific efficiency. Larger models can offer broader generalization and stronger performance on complex reasoning. The architectural mistake is turning either observation into a principle.

There is no inherent virtue in using the smallest model available, just as there is no inherent virtue in routing every problem to the most capable model available. The useful question is whether the model has enough capability for the task under the conditions in which it will actually operate. That is a measurement problem, not a philosophical one.

For a constrained extraction workflow, classification task, or narrowly defined transformation, a smaller model may be entirely sufficient. For ambiguous research synthesis, complex reasoning, or work that depends heavily on broad generalization, additional model capability may materially improve the system.

The distinction should therefore begin with the workload rather than the model category. The case for a small model is not simply that it is small. The case is that there is evidence it is enough.

That same principle also makes single-model thinking less important. Many AI architectures will benefit from using different models for different kinds of work. A smaller model may handle routine, high-volume tasks while more capable models are reserved for cases that genuinely require them. Model scale becomes one design variable among several rather than an architectural identity.

Openness is about access, not size

The second distinction is between model scale and model openness.

These characteristics are frequently associated because many downloadable models are smaller than the largest proprietary frontier models. But there is no technical requirement connecting the two. Small models can be closed. Large models can have downloadable weights. The questions are independent.

Even the term open model deserves more precision than it usually receives.

In ordinary industry conversation, a model is often described as open when its weights can be downloaded. That access is significant. It can allow organizations to host inference themselves, fine-tune the model, inspect portions of its behavior more directly, or optimize deployment for their own environment.

But open-weight and open source are not necessarily synonymous.

The Open Source Initiative's Open Source AI Definition 1.0 defines openness more broadly through the freedoms to use, study, modify, and share an AI system. It also considers access to code, parameters, and sufficiently detailed information about training data part of the preferred form for modifying the system. Under that definition, downloadable weights alone do not automatically make the full AI system open source.²

Different forms of access create different capabilities.

Access to weights may allow local deployment and fine-tuning. Access to training code can improve reproducibility. Documentation about training data can support investigation of provenance and potential bias. Intermediate checkpoints can make research into model behavior substantially easier. Stanford researchers examining open foundation models have similarly noted that access to model weights improves transparency in some respects, while access to additional artifacts such as training data and checkpoints enables forms of analysis that weights alone cannot provide.³

For architecture decisions, the useful question is therefore not simply whether a model is "open." It is what the organization can actually inspect, modify, operate, and move. That is an access question, and it still does not tell us who controls the deployed system.

Model access is not the same as operational control

Downloadable weights can provide an organization with important options. A model may be deployable within private infrastructure. Prompts and outputs may remain inside an organization's environment. The organization may control exactly when model versions change. It may be able to fine-tune the model, optimize inference, or continue operating even if the original developer changes its commercial offering. Those are meaningful advantages, and it is tempting to summarize them with a stronger claim: open models provide sovereignty.

That is only partly true. Model access can enable greater sovereignty, but sovereignty is a property of the system architecture surrounding the model, not merely of the model artifact itself.

A production AI system includes considerably more than weights. It includes the data supplied to the model, the retrieval process used to construct context, application logic, identity and permissions, prompts, tools, external services, evaluation infrastructure, policies, monitoring, update processes, and the rules governing what actions the system is permitted to take.

An organization may host an open-weight model on infrastructure it controls while depending heavily on external services elsewhere in that stack. It may possess the model but have weak control over the data pipelines feeding it. It may have complete infrastructure control while lacking meaningful observability into system behavior. It may also have full technical control while lacking the organizational processes needed to determine whether changes are safe.

Conversely, an application built on a proprietary model can still retain meaningful control over many of the properties that matter operationally. The organization may control the data exposed to the model, the context supplied for each interaction, the tools available to it, the permissions attached to those tools, the evaluation gates required before a model update is accepted, and the human approvals required before consequential actions occur.

Those architectures have different dependency profiles, but open and controlled are not simple synonyms.

I find it more useful to think of sovereignty as the organization's ability to make consequential operating decisions without surrendering them to the model provider. Can it decide where sensitive information travels? Can it reject a model version? Can it change models without rebuilding the entire system? Can it constrain what the system is authorized to do? Can it observe failures and intervene when behavior becomes unacceptable?

Open weights may substantially improve the organization's options. They can make local inference possible, reduce some forms of provider dependence, and support customization that would otherwise be unavailable.

But having the model is not the same thing as controlling the system.

Control is still not trust

The distinction becomes most important when operational control is mistaken for evidence of reliability.

Consider an organization that selects a small open-weight model, deploys it entirely inside its own environment, controls every model update, and ensures that sensitive data never leaves its infrastructure.

It has made a series of defensible architectural choices. It may have strong privacy characteristics and considerable operational independence.

But none of those facts tells us whether the model performs its assigned task accurately. They do not tell us whether it invents information, fails under longer contexts, behaves consistently across different classes of users, follows policy when instructions conflict, or performs adequately on unusual but important cases. The organization controls the system, but whether it should trust the system is still an open question.

The reverse can also be true. An organization may use a proprietary model through a managed service while tightly constraining the role that model plays. Perhaps it is permitted only to draft recommendations rather than execute actions. Perhaps every high-consequence output receives human review. Perhaps the organization maintains representative evaluation datasets, documents known failure modes, establishes acceptance thresholds, and re-runs those evaluations whenever the underlying model changes.

That architecture provides less control over the model itself, but it may provide far stronger evidence about whether the system is suitable for its intended use.

This is why trust should be treated as an evidentiary claim rather than a model characteristic.

NIST's Generative AI Profile for the AI Risk Management Framework takes a similarly system-oriented approach. Trustworthiness considerations are incorporated across the design, development, use, and evaluation of AI products, services, and systems rather than assigned to a model based on a single characteristic such as size or availability.⁴

A model should not be considered trustworthy in the abstract. The more defensible statement is narrower: there is sufficient evidence to trust this system for a defined use, within known operating conditions and authority boundaries.

The difference is significant. The first describes a reputation. The second describes an evaluated claim.

Once the dimensions are separated, model selection changes

Separating capability, access, control, and evidence leads to a different model-selection process.

Instead of beginning with a preferred technology category, the process begins with the work itself. What must the system do? What level of error can the application tolerate? Where may sensitive information be processed? What operating cost is sustainable? What level of control must the organization retain over updates and operation?

Those constraints define the candidate architectures. Evaluation then determines whether the candidate models are actually capable of doing the work.

A company may discover that a smaller model achieves the required performance and substantially improves latency and cost. Another may discover that its workload exposes capability gaps that make a more capable model worth the additional expense. A third may determine that both are appropriate and route different tasks according to complexity, sensitivity, or risk.

Likewise, an organization may decide that self-hosting an open-weight model is essential because of privacy or continuity requirements. Another may determine that the operational burden of hosting its own models produces little value for the application it is building. Neither conclusion can be reached from the words open or closed alone.

What matters is the relationship between the architecture and the requirements.

This also makes model evaluation part of architecture rather than a procurement exercise performed after a model has already been chosen. If a smaller model is proposed because it is cheaper, its adequacy needs to be demonstrated. If a system is described as trustworthy, there should be evidence defining the conditions under which that claim holds.

Each decision requires its own proof.

A portfolio is more useful than a camp

The long-term model architecture for many organizations is unlikely to resolve into a permanent preference for either small or large models, or for either open-weight or proprietary systems. Those categories are too coarse for the variety of work AI systems will perform. What is more likely is a portfolio.

Some workloads will benefit from small specialized models. Some will require greater general capability. Some functions will require extensive human oversight. Others may eventually earn broader authority through repeated evaluation and operational evidence.

The strategic capability is therefore not selecting the correct side of the model debate.

It is developing the ability to determine which model belongs in which part of the system, what level of access and control the application requires, and what evidence must exist before that system is trusted with greater responsibility.

That is a more demanding discipline than comparing leaderboard scores, and a more durable one.

Model families will change. Parameter counts will increase. Smaller systems will become more capable. Deployment economics will shift. Definitions of openness will continue to mature. New providers and architectures will emerge.

The questions underneath those changes are more stable.

Those questions describe different dimensions of the same architecture. Keeping them separate is what makes it possible to answer them well.