At a more technical level, what do you suggest? Training a small LLM on Python code exclusively? And then one on general CS/algorithms, which you'll also need? I don't think the current transformer architectures would compose as you suggest.
With what I know about how LLMs work now, I guess I am suggesting more specific variants. Qwen3.8 has a 2.4T version and a 27B version. I understand that to mean that they are the same architecture, just one version has a massive training set and the other has a very small subset. So, it seems very possible that variants of 27B could be generated that tune it for specific things by selecting different training data from the large corpus. One model for Python, another for Swift, another for research, another for creative writing, etc.
I think you're right that current architectures don't compose like that - but I feel like that's a result of the focus on MOAR DATA, and a "race for AGI" - if we set those ideas aside, a more composable architecture seems very possible.
> I understand that to mean that they are the same architecture, just one version has a massive training set and the other has a very small subset.
No. It means that the one model has 2.4 trillion parameters while the other has only 27 billion. I don't know the details about their architecture or training, but presumably they used the same or similar training sets for both and a conceptually similar architecture, scaled down. I'd guess they also have some techniques to re-use some of the work done for the big model for the smaller versions (if anyone knows more about this I'd be interested). The architectures cannot be identical by definition because then the parameter count would be the same. Subsetting the data to such narrow fields as you describe could risk losing some edge, there are a lot of emergent capabilities in those models and I don't think that emergence is fully understood yet. There are subject-specific models, but for far broader subject areas than you suggested, like coding or math or prose.
I'm sure composability is possible in principle, I'm just sceptical that it'll be a good long-term solution, for my originally stated reason. It's basically just The Bitter Lesson again, we may gain some short-lived edge by putting more domain knowledge into the algorithm, but ultimately (these days often: surprisingly quickly) it'll be outgunned by something that just leverages raw computation better.
> it'll be outgunned by something that just leverages raw computation better.
The issue for me is that the raw computation is coming at the cost of the planet. Throwing an aircraft carrier at a problem that needs a bicycle is dumb, but because the damage to the environment required to scale up computation isn't included in the price of that computation - it's easier to just toss the aircraft carrier at every little problem.
So when I say I want to pick and choose, and use smaller models, it's because I like technology and I don't want to hate LLMs, but I also like the planet and don't want LLMs to continue to accelerate environmental collapse.
It's a noble cause, but there are probably bigger levers to pull than the model size if you care about environmental impact.
If you're running Qwen3.8-27B on energy-efficient hardware like a Mac or a DGX Spark instead of an API (likely running on H100s), I'm sure you're having much more of an impact than you would by switching to, say, a 9B coding-only model on the same hardware. The thing is, I think you won't be able to go orders of magnitude smaller, because a lot of the usefulness of LLMs comes from emergent smartness, and you typically need a minimum amount of complexity to see such emergent phenomena (and I think we're pretty far from understanding this kind of emergence, much further than from the next model generation that annihilates the current one on benchmarks yet again).
