Transcription
When it comes to AI, I think there's one term everyone is pretty familiar with: LLM. Large language model. But you'll also hear some other terms like SLM. That's small language model. And FM. That's frontier model. So, what's the difference?
Well, they're not really three separate categories. LLM, it's really the umbrella term. But we can think of SLMs as kind of the efficient specialists. And we can think of frontier models as more of the cutting edge. They're all language models, but we label them differently because we use them differently. So, let's define what each term means and then talk about some use cases that are well-suited for each model.
And we're going to start with LLMs, large language models. Now, large language models are what most people think of when they hear AI. And we're talking about models that are pretty big. They have tens of billions of parameters. And parameters here means the weights that are learned during training that determine the model's capabilities. And more parameters generally means a bit more knowledge, a bit more nuance, a bit more reasoning.
Now, LLMs, we can really think of these as being generalists. And what I mean by that is that they have broad knowledge across many domains, and they can handle sophisticated back-and-forth conversations. Now, there are a lot of different LLMs. Uh, many of them are kind of open-source models in this kind of parameter range. And they typically run in the cloud or in SaaS environments because they need large amounts of GPU memory and processing power. That's LLM.
What about SLM? Well, small, yeah, they have fewer parameters. So we might be talking about a model that has less than 10 billion parameters. So SLMs just kind of worse version of LLMs. Well, I think rather than worse, it's probably better to think of these guys as not so much generalists, but more as specialists. Today, well-tuned SLMs, they can often match or even beat these bigger models at focused tasks. So document classification or code routing or summarization and SLM can often do it faster and cheaper. Some examples of that. Well, IBM's Granite models, including the recently released Granite 4.0 that is an SLM. And then we've got some smaller open-source options as well. Like certain models that have come from Mistral.
And then, we've got FM, frontier models. Now these are often hundreds of billions of parameters and quite a bit more. And they also have deep tool integration. But it isn't just the size and the tools, because actually plenty of smaller models, they can use tools now as well. What makes frontier models frontier is that they are the most capable type of model that we have today. They have the best reasoning. They're best at complex tasks. So we can think of models that fall into this category as like Claude Sonnet and Opus would definitely fit into here. GPT-5 from OpenAI, we could put in here. And Gemini Pro from Google, these would all be considered frontier models.
Now, you might be thinking, all right. Frontier models are the most capable. Why don't I just use frontier models for everything? I mean, that's a fair question, but here's where the strategy comes in. The choice of AI model is use case-specific. So let's look at three use cases. And we're going to pick one that fits well with each of the types of models.
Let's start with small language models. So the use case I'm going to use here is document classification and routing. So here's the scenario. We've got a company and it receives thousands of documents every day. There's a whole bunch of documents coming in. There might be support tickets or insurance claims whatever. And each one of those needs to get routed to the right department and then tagged appropriately. So the documents, they come into our system, and when they get into our system, they hit, what we're going to call, the classification service that is going to process these documents. And the classification service, that is running on top of a small language model. So the service reads the documents and then it does some classification. So it figures out what the category of each document is. It figures out what the meta data of each document is. And once it's done all that, then these messages can be routed. So they get routed to whatever the appropriate queue is to process these messages. A pretty straightforward pipeline. And implementing the classification service is really a perfect job for a small language model. Let me give you some some reasons why.
One reason really comes down to to speed. So an SLM with, let's say, 3 billion parameters instead of a bigger model with maybe like 70 billion, that has simply less computation per inference. So document classification is a pretty straightforward pattern-matching exercise, and you don't need massive scale to achieve high accuracy. Another good reason comes down to cost. Fewer parameters also means less computational cost per inference. You're doing fewer calculations, which uses less memory, which requires less GPU resources. And then we've also got the advantage of governance. Now it turns out that these documents here, they contain sensitive data. And running an SLM on premise means that the data never leaves their environment. There's no external API cause. There's no questions about compliance. And for regulated industries like finance and healthcare, that's often non-negotiable. So that's why SLMs work for document classification. That's fast inference from fewer parameters. There's predictable infrastructure costs, and the data stays in-house.
All right. Next up, large language models. We're going to go with customer support as the use case here. We're a customer contacts support with an issue. So maybe their billing doesn't match what they expected, and it's tied to a a service configuration change. And there's also a history of previous tickets about related issues, just like basically some complicated stuff. So what can we do here? Well, basically, we will start with a query. Now the query comes in and it's going to hit the element that we're going to build here, which is our basic support system to process this query. And yes, the support system is running on top of a large language model.
Now the LLM, it needs to pull information from a bunch of sources. So maybe it needs to pull information from a billing database as part of this processing. Maybe we also need some of the the technical configuration data that needs to be provided as well to the system. And perhaps we'll also include the ticket history of that particular customer who has submitted the query. And that's all received into the support system. So it synthesizes all of that data, and it's going to need to understand the relationships between all of these different pieces of information. And ultimately, what we want it to do is to generate a solution at the end. So this is a much more complex pipeline than simple classification.
So why is it a good fit for LLMs? Well, a few reasons. One of the reasons really comes down just down to the breadth of this solution and what an LLM can do. Now, LLMs are likely pre-trained on broader and more diverse data sets than SLMs can store in their weights, so that corpus might span technical docs and customer service interactions. And basically, all of the domains that this task touches. And during pre-training, the model learns patterns and relationships across these different areas, where, whereas a SLM training with a specific task in mind, like document classification that might not have the same level of breadth in its training. And I think the other reason really comes down to generalization. And what I mean by generalization is that customer support queries have a pretty high variability. So different customers describe the same problems in just like completely different ways. There are a whole bunch of edge cases. And an LLM can generalize to scenarios it hasn't explicitly seen before because of its broader training has exposed it to more patterns and more variations. So it can do levels of nuanced reasoning about how concepts relate, even when the specific combination is new. So that's why LLMs work for complex customer support. There's broad pre-training across multiple domains, and there's the ability to generalize across scenarios with nuanced reasoning.
All right then finally, frontier models. Now the use case I'm going to go here with is autonomous incident response. So we've got a critical system alert that has come in at 2 AM in the morning. Don't they always seem to come in then? At least in these videos, they do. It's never 2 PM on a Tuesday when you're caffeinated and ready. Always 2 AM. So, so the application servers there may be timing out and the users can't access the servers. And that normally would wake up an on-call engineer who would investigate and fix it. But what if an AI system could handle it? So let's figure that out.
We've got an alert that has come in, and it has triggered our system, our incident response system that is now going to process and work on that alert. And the incident response system is, of course, running on a frontier model. Now, the frontier model needs to query a bunch of things. So it might query into a monitoring system, and it might need to check some logs in order to be able to process what is going on across multiple services. Then it's going to need to be able to identify the root cause of what's going on. That would be important. It needs to determine the appropriate fixes that need to be applied, and then it needs to execute that fix by calling out to a series of APIs, maybe restarting services and rolling back a deployment, something like that. So this is multi-step investigation and execution, and that's the wheelhouse of agentic systems.
Now to to ground this in a dose of reality, most teams today aren't running fully autonomous agents yet. What they're running are frontier models as more AI copilots with some guardrails built in and human sign-off. So there is also probably a human in the loop here, at least today. But the underlying capability that lives in the frontier scale model. So frontier models, they have very strong agentic capabilities. They're trained to plan multi-step workflows and then to execute them. They can break down a complex task into steps. They can call the appropriate APIs, and they can evaluate their results. Based on that, they can adjust their approach for the next step. So agentic capabilities. There's also a built-in reasoning chain into this whole flow as well. So system failures like this alert, they require multi-step investigation where each step kind of builds on what you learned before. And the chain can be pretty long and complex. And, and frontier models, they can maintain coherent reasoning across these extended chains, keeping track of what they've learned, how it connects, and then what to investigate next.
So look, when it all comes down to it. SLM, LLM and FM, they are all language models. And the choice comes down to matching capability to need. So you might use an SLM when you need speed and low cost or on-prem control. You might use an LLM when you need broad knowledge and nuanced reasoning. And you might use a frontier model when you need the absolute best complex reasoning for complex problems, essentially match the model to the task.