SLM 是 Small Language Model 的缩写，中文叫「小语言模型」。它和大语言模型没有一条官方分界线，业界比较务实的一种定义是：能在普通消费级设备上跑起来、且响应快到足以服务单个用户的语言模型就算小模型，达不到这个条件的就是大模型。按今天的硬件，这大致对应几亿到十几亿、最多几十亿参数这个区间。
这个词升温不是因为小模型突然变强了，而是因为大家开始意识到：在真实系统里，绝大多数模型调用根本用不上通用对话能力。
先用一句话抓住它
小模型不是「便宜的替代品」，而是「按任务选合适工具」——大部分子任务本来就不需要一个万能模型。
打个比方。公司里当然需要能应对复杂局面的资深顾问，但你不会让顾问去做每天几千次的发票分类。那件事需要的是准确、快速、稳定，而不是见多识广。系统里的模型调用也一样：判断意图属于哪一类、把一段文字转成 JSON、决定该调哪个工具——这些活重复、狭窄、格式固定，用最强的模型做纯属浪费。
为什么它在智能体时代变得重要
NVIDIA 与合作者在 2025 年的一篇立场论文里把这个观点讲得很直接：智能体系统的特征是少数几种专门任务被高频、低变化地重复调用，这正是小模型的主场。论文估算，小模型的推理成本大致是同类大模型的十分之一到三十分之一量级，延迟和能耗更低，微调可以在一夜之间完成而不是几周，还能部署到端侧获得速度和隐私上的好处。
它同时给出了一条现实路径：不是全部换成小模型，而是做异构系统——通用对话和困难推理仍然走大模型，把那些高频、模式固定的环节逐步迁移到专用小模型上。判断哪些环节可以迁移，靠的是收集真实调用日志、按工具聚类、然后针对性微调。
小模型是怎么做出来的
蒸馏是主要手段：用大模型生成高质量的输出，训练小模型去逼近它的行为，细节见知识蒸馏。
数据质量优先是另一条主线。微软 Phi 系列的做法是用精心筛选和合成的「教科书级」数据训练，证明在数据质量足够高时，小模型可以在推理类基准上超过参数量大得多的模型。这条路线也把合成数据推到了台前。
面向任务微调是落地时的关键一步：通用小模型的开箱能力有限，但用几千条本任务样本做 LoRA 后，在这一个任务上往往能追平甚至超过通用大模型。
和相关概念的区别
和量化的区别：量化是把大模型压小，参数量没变；SLM 是本来就少。同样的显存预算下，「量化后的大模型」和「全精度小模型」是真实的竞争关系，要按任务实测。
和本地模型的区别：本地模型强调的是运行位置（在你的设备上，而不是云端），小模型强调的是规模。两者高度相关但不是一回事——你也可以在本地跑一个很大的模型，只要显存够。
和 MoE 的区别：MoE 模型的激活参数量可能很小，但总参数量仍然巨大，权重要全部装进显存，所以它省的是计算不是内存，不能算小模型。
容易误解的地方
「小模型就是能力差」——在开放域对话、长程规划、复杂推理上确实差距明显。但在定义清晰的窄任务上，经过针对性微调的小模型经常和通用大模型打平，而成本差一个数量级。判断标准应该是「在我的任务上够不够用」，不是通用榜单排名。
「小模型能替代所有调用」——不能，也不必。异构系统才是常态，关键是把模型路由做对：容易的走小模型，难的升级到大模型。
「参数量小所以更安全」——不成立。小模型同样会幻觉、同样会被提示词注入，有时因为对齐训练投入更少，边界反而更脆。护栏一样要做。
什么时候该考虑它
三个信号出现时值得认真评估：调用量大且任务重复（成本占比高，收益立竿见影）；延迟敏感（本地推理省掉网络往返）；数据不能出设备（医疗、法务、端侧个人数据）。
评估的方法不复杂：先把真实调用日志按任务类型聚类，挑出占比最高、模式最固定的那几类，用几千条样本微调一个小模型，和现有大模型做 A/B。多数团队会发现，靠前的两三类任务就占了大部分调用量，把这部分迁走已经能省下可观的开支。