Millions of AI Models Are Coming, but Most Will Not Be New Brains

I think we will eventually have millions of AI models, but the popular picture of that future is wrong. We will not get millions of independently trained general-purpose intelligences; we will get a small number of expensive general foundations and millions of specialized derivatives, configurations, and deployments built around them.

That distinction matters because it changes what engineers should build. If you imagine a world of countless autonomous model vendors, you optimize for shopping: compare benchmarks, swap APIs, and hope a model card tells you whether “legal-contract-llm-847” is good. If you see the likely shape of the ecosystem, you optimize for composition: choose a capable base, constrain it with software, add domain adaptation where evidence supports it, and evaluate the whole system in its actual workflow.

Training a new brain is still a radically different business from specializing one

Pretraining remains the bottleneck that keeps the number of true foundation models relatively small. A competitive general model needs huge quantities of data, serious systems engineering, distributed-training expertise, evaluation infrastructure, and capital that most companies cannot justify. The Chinchilla work was a useful correction to the simplistic “just add parameters” story, but it did not make pretraining cheap. It showed that compute-optimal training requires balancing model scale and training data. That is an argument for disciplined industrial training runs, not a recipe for every vertical SaaS company to make its own universal model.

Specialization has a much lower entry cost. LoRA made the core idea painfully clear: instead of copying and updating every parameter in a pretrained model, teams can train small low-rank updates and apply them to a frozen base. In practical terms, that means a company can make a version adapted to its support taxonomy, code conventions, medical-document style, or internal query language without pretending it has built a new foundation model from scratch.

This is why the word model will become progressively less useful. A repository may contain a base checkpoint, a quantization format, a chat template, a system prompt, a retrieval connector, a tool schema, a LoRA adapter, an evaluation set, and deployment settings. Two teams can call both artifacts “our model” even if most learned parameters are identical. They may nevertheless behave differently enough in production that the distinction is operationally real.

The model ecosystem will look more like packages than like car brands

Software already gives us the right analogy. There are not millions of operating systems competing on equal footing. There are a few kernels and platforms, then an absurd number of libraries, distributions, plugins, services, forks, builds, and configurations. The quantity is real, and the variation can be valuable, but the lower layers are highly shared.

Open model infrastructure pushes in the same direction. Hugging Face describes its Hub as hosting more than two million public models, alongside datasets and applications. That count is impressive, but it should not be interpreted as two million separately invented cognitive architectures. Model repositories are versioned artifacts that can package checkpoints, configuration, metadata, and revisions; the platform intentionally makes publishing and reusing those artifacts straightforward. The explosion is partly scientific progress, but it is also the predictable result of making model distribution behave more like source-control distribution.

This is good news for engineers. A specialist does not need to beat a frontier model at everything. It needs to win a constrained contract: classify a document correctly, extract fields under a known schema, write code in a specific framework, translate a narrow jargon, or make the right routing decision cheaply and predictably. For those jobs, a smaller model can have advantages that benchmark charts systematically understate: latency, privacy, controllable failure modes, offline operation, and the ability to run near the data.

Mixture-of-experts architectures strengthen the case that specialization will happen inside models as well as between them. Switch Transformers demonstrated sparse routing: very large parameter counts can be paired with much less computation per token because only selected experts are activated. The conceptual lesson is more important than one architecture’s results. The winning unit may not be one monolithic model or one standalone specialist. It may be a router selecting among experts, adapters, tools, retrieval indexes, and policy checks.

The strongest objection: general models erase the need for specialists

The best counterargument is strong: general models keep getting better faster than organizations can build and maintain narrow alternatives. A frontier model can already handle legal text, code, customer support, image analysis, and data work reasonably well. It benefits from broad transfer: knowledge from one domain helps another, while niche teams have limited data and risk overfitting. Every extra model also creates an operational tax—versioning, security review, monitoring, deployment, red-teaming, rollback plans, and a fresh pile of obscure failures. Why operate ten mediocre specialists when one general model, plus a good prompt and tools, is better?

For many teams, that is exactly the right answer. I would not fine-tune a model to summarize meeting notes, write ordinary CRUD code, or answer generic product questions merely because fine-tuning is now accessible. A competent general model is the default, and a specialist must earn its existence with measured gains on a real workload. The industry has already created too many ceremonial “domain models” whose only differentiator is a recycled benchmark and a custom logo.

But the objection overreaches when it assumes general capability substitutes for system fit. The harder production problem is usually not answering an isolated question. It is consistently producing an answer in the permitted format, grounded in the right private context, at the required latency and cost, while knowing when to hand off, refuse, or ask for review. Base-model capability helps, but it does not remove those requirements. In fact, as general models become more capable, the value of careful specialization increases because they become powerful components worth constraining rather than chatbots worth admiring.

Engineers should build a specialization layer, not a private-model vanity project

The practical consequence is blunt: stop asking whether your company needs its own foundation model. Almost certainly, it does not. Start asking which parts of your workflow deserve a stable, testable intelligence boundary and what is the cheapest artifact that can enforce it.

• Keep a general model as the fallback and baseline. If a specialist cannot beat it on a held-out production-shaped evaluation, delete the specialist.
• Treat prompts, tool contracts, retrieval policies, adapters, quantization choices, and eval suites as versioned model components. They are part of behavior, not deployment trivia.
• Route by task economics. Use the smallest reliable component for high-volume, bounded work; reserve expensive general reasoning for ambiguity and escalation.
• Publish internal model cards that state the data boundary, intended task, known failure modes, owner, evaluation set, and rollback path.
• Measure specialization against end-to-end outcomes: accepted patches, corrected extractions, handling time, incident rate, and dollars per completed task—not a leaderboard score.

The future should not be a marketplace where engineers blindly choose among millions of mysterious AI brains. It should be an ecosystem where a few broadly capable foundations are made useful by many inspectable, replaceable, narrowly accountable components. Build the tooling, evaluation discipline, and interfaces for that ecosystem now. The teams that do will be able to use model abundance without drowning in it.