面向 AI 智能体的小语言模型，是按 NVIDIA 的工作定义参数量大约在 100 亿以下的紧凑模型，用来接手智能体中那些范围窄、反复出现的步骤：选择工具、抽取字段、给请求分类、整理回复格式。NVIDIA Research 在《Small Language Models are the Future of Agentic AI》一文中提出，这类模型足以胜任其中大多数步骤，更 适合这些步骤，运行成本也更低。我们同意论文的大部分观点，我们自己的测量也在一个明确的任务上支持它的核心主张。我们的限定都属于工程问题：每个步骤需要多大的模型，哪些优化能守住质量标准，以及调用量达到多少时，运行自己的模型会比前沿模型 API 更划算。
本文先按原文梳理论文的论证，再说明我们的证据在哪些地方与之一致、我们会补充哪些细节、截至 2026 年 10 月有哪些开放模型系列适合智能体工作，以及小语言模型如何用于企业智能体。
什么是面向 AI 智能体的小语言模型？
面向 AI 智能体的小语言模型（SLM），是小到可以在普通设备或单台中等配置服务器上运行、并针对智能体交给语言模型的窄任务做过训练或调优的模型。NVIDIA 的论文按运行位置来定义 SLM：能装进常见的消费级电子设备，推理延迟又低到足以实际服务单个用户的智能体请求。按参数量，作者表示，以 2025 年的情况，他们愿意把大多数 100 亿参数以下的模型视为 SLM。
智能体每完成一项任务，都会向语言模型发出许多请求。其中一些 API 调用需要开放式推理或对话。更多的则很窄：选一个工具并填好参数，从文档里抽取字段，给请求分类，总结一条记录，按固定结构返回 JSON。小模型适合的正是这些窄的 API 调用。
“小语言模型”是论文用的说法，也是大家搜索时用的词。在我们自己的工作中，我们按模型做什么来描述结果：一个任务专用模型，为一项工作而训练，规模定在能守住这项工作质量标准的最小模型。
NVIDIA 的论文主张什么？
这是一篇立场论文，作者是 NVIDIA Research 和佐治亚理工学院的 Peter Belcak 及其七位同事（arXiv 2506.02153，2025 年 6 月 2 日首次发布，第 3 版发布于 2026 年 9 月 22 日）。用论文自己的话说，它的核心主张是 SLM "sufficiently powerful, inherently more suitable, and necessarily more economical for many invocations in agentic systems, and are therefore the future of agentic AI"（足够强大、天然更合适，而且在智能体系统的许多调用中必然更经济，因此是智能体 AI 的未来）。
论文用三个观点支撑这一主张：
| 观点 | 主张要点 | 主要依据 |
|---|---|---|
| V1，能力 | 小模型能处理大多数智能体请求 | Phi、Nemotron-H、SmolLM2 和 xLAM-2 的已发表结果 |
| V2，适配 | 小模型更适合智能体工作 | 任务窄、格式严格、可以混用模型 |
| V3，经济性 | 小模型在大多数智能体请求上成本更低 | 服务成本更低，微调更快 |
展开来说，论文认为 SLM 原则上足以完成智能体应用中的语言建模任务，在智能体系统中天然比 LLM 更适合运营，并且在智能体系统的绝大多数语言模型用途上必然更经济。在能力方面，它引用了 Phi、Nemotron-H、SmolLM2 、Hymba、DeepSeek-R1-Distill、RETRO 和 xLAM-2 的已发表结果。在经济性方面，它认为服务一个 7B 模型在延迟、能耗和 FLOPs 上比 70B 到 175B 的模型便宜 10 到 30 倍，而微调一个小模型只需几个 GPU 小时。
论文中针对智能体的论证，主要落在四点上：
- 智能体只用到模型的一小部分能力。 论文把智能体描述为一个经过大量指令约束、由外部编排的语言模型入口，并认为针对选定提示词适当微调过的小模型就足够了。
- 智能体每次都需要同一种输出格式。 工具调用和要被程序解析的输出必须符合严格的结构。用单一格式训练出的模型，比偶尔换一种格式作答的通用模型更适合这项工作。
- 智能体可以混用模型。 智能体代码发出的每个请求都可以交给不同的模型，所以论文主张采用异构系统：默认使用 SLM，只在必要时有选择地少量调用 LLM。
- 智能体的流量就是训练数据。 每一条被记录下来的模型请求都是日后改进的天然数据来源，这让训练一个专家小模型成为部署智能体的自然一步。
论文最后给出了一个从 LLM 转换到 SLM 的六步算法：安全地记录智能体对模型的请求，整理数据并去除个人和敏感信息，把请求聚类成反复出现的任务，挑选候选小模型，针对每项任务进行微调，再定期用新数据重新训练。附录估算了三个开源智能体中可以由专门化 SLM 可靠处理的 LLM 查询比例：MetaGPT 约 60%，Open Operator 约 40%，Cradle 约 70%。
论文也回应了批评者。它承认，在通用语言理解上，同代的大模型胜过小模型，但它回应说，小模型可以很容易地针对具体任务微调，达到所需的可靠性。在经济性上它更谨慎。对于“集中部署的 LLM 靠规模经济仍然更便宜”这 一反方观点，论文称之为 "a valid view, with the exact economical considerations being highly case-specific"（一个合理的观点，具体的经济考量高度取决于个案），并表示这个问题尚无定论。
我们的证据在哪些地方与论文一致？
在一个明确的任务上，我们的测量支持论文关于能力和经济性的观点：为这项工作训练的模型，以通用模型一小部分的规模守住了质量标准，而成本上的优势来自两个维度。
训练过的模型在一个基准上得分高于托管专有模型。 我们的 QMSum 研究（arXiv 2609.25028）在完整的 281 条查询测试集上，用同一套实现为基于查询的会议摘要打分。参数量为 4.06 亿和 12 亿的训练模型分别得到 36.33 和 35.41 的 ROUGE-1。五个托管专有模型以零样本方式、在同一条简洁提示词下运行，得分在 27.89 到 32.43 之间。这些限制很重要：托管模型写出的答案更长，这在基于参考文本重合度的指标上会拉大差距；研究没有做人工评估或事实性评估；结论仅限于 QMSum 和自动指标。QMSum 上最强的已发表系统在各自论文中报告的分数更高，最高为 38.82 ROUGE-1。
训练比规模更重要。 在同一个 12 亿参数的基础模型内，用模型推理时实际读取的检索转录片段进行微调，使 ROUGE-1 提高了 5.29（95% 区间为 +4.02 到 +6.56）。用同样方式训练的 4.06 亿参数模型得到 36.33，而 12 亿参数系统为 35.41，QMSum 无法在统计上区分这一差异，而前者的推理峰值内存不到后者的一半。在一个任务上，这正是论文对批评者的回应：为任务训练的小模型能达到任务所需的可靠性。
支出集中在智能体反复执行的任务上。 在 OpenRouter 截至 2026 年 10 月 12 日的 30 天公开数据中，分类、抽取和转换合计占已分类模型支出的 20.8%，而在这些任务里，闭源前沿模型占到前十名模型支出的 75% 到 87%。论文所说的智能体交给语言模型的，正是这类范围窄、可检验的工作。这些数据描述的是市场活动：它指出了该从哪里着手，每个买家仍需测算自己能省下多少。
成本从两个维度下降。 论文的经济性论证建立在每个 token 的价格上，因为更小的模型服务成本更低。训练过的模型每项任务发送的 token 也更少。论文描述的智能体，靠精心编写的提示词和细致编排的上下文管理维持运转；一旦把这些提示词里反复出现的指令、流程和示例训练进模型，它们就不必再发送，只剩下每个请求自己的数据。训练过的模型还可以直接作答，不需要冗长的推理过程。第二项节省有多大，取决于每条提示词中有多少是重复的固定内容，以及您当前的模型是否对推理 token 计费。前沿模型 API 已经通过提示词缓存对重复输入打折，所以和缓存做得好的方案相比，输入端的节省会小一些。我们的开放权重模型与前沿模型对比按标价完整演算了这两个维度。
我们会对论文补充哪些限定？
论文指明了方向。一个团队要把小模型放进生产环境的智能体，仍有三个工程和经济问题需要回答，每一个都要在自己的任务上通过测量来确定。
模型应该多小。 论文的定义给 出了上限：任何能装进消费级设备的模型。在这个上限之内，合适的规模因步骤而异。在我们的 QMSum 研究中，4.06 亿参数模型与 12 亿参数模型的差距落在该基准的分辨范围之内；而论文自己的案例研究，把规划、调试和错误恢复留给了更大的模型。规模是评估得出的结果：用您的示例训练两三个不同规模的候选模型，保留能守住质量标准的最小那个。
哪些优化能守住标准。 论文提到了微调、推理时计算、工具使用和路由。我们的结果补充了一点：训练数据必须和智能体实际收到的输入一致。一个已公开发布的 4.06 亿参数摘要模型，在输入从长篇转录换成我们流程提供的检索片段后，ROUGE-1 下降了 6.30；用新的输入对它微调后，损失得以恢复。只要智能体的检索、工具或提示词发生变化，它的输入就会随之改变，所以专家模型要用它现在看到的输入重新训练。检索、量化和路由都会影响成本和质量，每一项都要用同一套评估集来检验。
成本交叉点在哪里。 论文没有给出答案，而这正是该问的问题。小模型每个 token 的服务成本更低，但一个专用模型还要承担训练、托管、负载均衡和运维人员的成本，论文也承认这高度取决于个案。调用量低的时候，前沿模型 API 往往总成本更低。前沿实验室也提供低价档位，按每个 token 计价可能比托管的开放模型还便宜；面对这些档位，优势就在于每项任务更少的 token 和质量。交叉点是一个调用量，您可以在动手构建之前，用当前的 token 用量和价格，借助单任务成本计算器估算出来。
该测量什么。 论文指出，小模型的开发沿用了和 LLM 相同的通用基准，并把这列为推广的障碍之一。排行榜分数很 难说明智能体某一个步骤的表现。请用智能体自己的请求和预期输出建立评估集，用它给每个候选模型打分，不论大小。我们的领域专用 LLM 评估指南以 QMSum 研究的流程为实例，说明了具体做法。
面向 AI 智能体的最佳小语言模型有哪些？
对智能体的某个步骤来说，最好的小语言模型，是用您自己的示例训练之后能守住质量标准、且许可证允许您使用的最小模型。作为起步候选，下面这些开放模型系列都发布了 100 亿参数以下的规模，并在各自的模型卡上写明了面向智能体的功能（2026 年 10 月 30 日查阅）：
| 系列（开发方） | 100 亿参数以下的规模 | 许可证 | 上下文窗口 | 模型卡上写明的智能体功能 |
|---|---|---|---|---|
| Qwen3.5（阿里巴巴 Qwen 团队） | 0.8B、2B、4B、9B | Apache 2.0 | 262,144 tokens | "Qwen3.5 excels in tool calling capabilities" |
| Gemma 4（Google DeepMind） | E2B、E4B（有效参数 2.3B 和 4.5B） | Apache 2.0 | 128K tokens | "native function-calling support" |
| Ministral 3（Mistral AI） | 3B、8B | Apache 2.0 | 256k tokens | "native function calling and JSON outputting" |
| Granite 4.2（IBM） | 3B、8B | Apache 2.0 | 128K tokens，可扩展到 512K | 把工具调用和智能体工作流列为擅长方向 |
| Nemotron 3 Nano 4B（NVIDIA） | 4B | NVIDIA Nemotron Open Model License | 最多 262K tokens | 推理可关闭；提供工具调用的推荐参数 |
| SmolLM3（Hugging Face） | 3B | Apache 2.0 | 以 64k 训练，借助 YaRN 可达 128k | "SmolLM3 supports tool calling!" |
新版本发布得很频繁（Granite 4.2 的模型卡写明发布日期为 2026 年 8 月 25 日），所以看任何榜单都要留意日期，这一份也不例外。许可证也各不相同。这些系列大多采用 Apache 2.0，而 NVIDIA 的模型使用它自己的开放模型许可证，商用前请先阅读条款。如果想从企业角度比较许可证和规模，请参阅我们的企业小模型对比。
比模型卡更重要的是三项检查：
- 格式。 用您的示例训练之后，模型能否准确输出您要的工具调用或 JSON 格式？
- 推理。 关闭推理后，它还能守住您的质量标准吗？其中几款模型默认会先思考再作答，而推理 token 会计入每项任务的成本。
- 许可证。 许可证是否允许您的用途，包括在商业产品中提供该模型的服务？
小语言模型能用于企业智能体了吗？
对于范围窄、反复出现、可检验的步骤，面向企业智能体的小语言模型已经可以使用，前提是每个步骤都用企业自己的示例训练和评估过。它们带来三项实际好处：每项任务成本更低；延迟低到足以支撑串联多个步骤的智能体；部署位置可以自主选择，因为小模型既能放在托管服务上，也能放进企业自己的云或本地机房。论文中的转换步骤也带来企业层面的要求：加密日志并按角色控制访问，在任何数据变成训练数据之前先去除个人和敏感信息。
企业智能体仍然需要大模型。开放式对话、跨多个步骤的规划和不寻常的请求，可以继续交给前沿模型，由训练过的专家模型承担大部分调用量，这正是论文推荐的异构设计。关于在本地运行小模型，请参阅面向企业的小语言模型。关于在大小模型之间路由，请参阅 SLM 优先架构。
如何把 AI 智能体从 LLM 迁移到小语言模型？
从一个反复出现的步骤开始，把它记录下来，等训练过的模型在您的评估中守住标准后再切换：
- 记录智能体对模型的请求。 为在后台运行的步骤记录输入、输出和工具调用，同时设置访问控制并去除个人数据。
- 找出反复出现的步骤。 把请求归为重复出现的任务，例如工具选择、抽取、分类或总结某一类文档。
- 先挑调用量最大、结果可检验的任务。 调用量决定能省多少，可检验的输出则给出清晰的质量标准。
- 在训练之前建立评估集。 为真实请求收集预期输出，用同样的方法给当前模型和每个候选模型打分。
- 训练两三个规模，保留能守住标准的最小模型。
- 把这个步骤路由给专家模型。 其余部分继续使用大模型，当这个步骤的输入变化时重新训练。
这沿用了论文的算法，只是把评估集提到了最前面。关于什么时候一项任务值得拥有自己的模型，请参阅基础模型与任务专用模型。
Ertas 是一家应用型 AI 实验室，为此提供自适应模型端点：一个用您的智能体工作训练的模型，通过兼容 OpenAI 的 API 提供服务，每次发布新版本前都要经过评估。新版本在后台用您的智能体流量训练，按您的评估打分，只有经您批准才会上线。如果新版本没有达到标准，当前模型继续服务。它可以由 Ertas 托管，也可以部署在您自己的云上或本地，您的数据始终保持私密。该端点目前仅限受邀企业使用，我们正在开发一个更简化的版本，让更多企业可以接入。关于这个循环如何运作，请参阅面向 AI 智能体的持续学习。
常见问题
什么样的模型算小语言模型？
NVIDIA 的论文按运行位置来定义：能装进常见的消费级设备，响应速度又足以服务单个用户的智能体。按参数量，作者把界线定在 2025 年时的大约 100 亿。各家厂商对这个标签用得比较宽松，比较两种说法之前，先弄清“小”具体指什么。
小语言模型能做工具调用吗？
能。截至 2026 年 10 月，Qwen3.5、Gemma 4、Ministral 3、Granite 4.2 和 SmolLM3 都在模型卡上写明支持工具调用或函数调用，NVIDIA 的论文也引用了 Salesforce 的 xLAM-2-8B，称其在工具调用上超过 GPT-4o 和 Claude 3.5。请测试您的智能体实际使用的格式；如果基础模型偏离这个格式，就用您自己的工具结构来训练它。
小语言模型会在 AI 智能体中取代 LLM 吗？
论文认为在许多步骤上会。它估计，三个开源智能体中有 40% 到 70% 的 LLM 查询可以转给专门化的小模型。开放式的工作仍归大模型：对话、规划，以及从意外状态中恢复。论文推荐的设计是两者混用。
小语言模型有哪些例子？
Qwen3.5-4B、Gemma 4 E4B、Ministral 3 8B、Granite 4.2 3B 和 SmolLM3-3B 都是开放权重的小语言模型。任务专用的例子是我们 QMSum 研究中的 4.06 亿参数会议摘要模型，它只为一项工作而训练，并随论文一同发布。
小语言模型用于 AI 智能体更便宜吗？
按每个 token 计算，通常更便宜：论文认为服务一个 7B 模型在延迟、能耗和计算量上比 70B 到 175B 的模型便宜 10 到 30 倍。按每项任务计算，训练过的模型发送的 token 也更少，因为每条提示词里重复的指令已经训练进模型。总成本取决于调用量，因为专用模型要承担训练和托管成本。单任务成本计算器可以用您的数据算出交叉点。
简短版
NVIDIA 的论文认为，智能体向语言模型提出的大多数请求范围窄且反复出现，为这些步骤训练的小模型能力足够、更合适，也更便宜。在一个明确的任务上，我们的结果与之一致：一个训练过的 4.06 亿参数模型与规模约为它三倍的模型之间的差距落在基准的分辨范围之内，两个训练模型在 ROUGE-1 上都高于五个托管专有模型，相关限制见上文。悬而未决的是工程和经济问题：每个步骤的合适规模，能守住标准的优化手段，以及调用量达到多少时自己的模型会比 API 更划算。这些问题都由您自己的评估集来回答。
想看更全面的比较，请参阅开放权重模型与前沿模型。
资料来源（2026 年 10 月 30 日查阅）：Belcak 等人，"Small Language Models are the Future of Agentic AI"（arXiv 2506.02153v3，2026 年 9 月 22 日）及其 NVIDIA Research 页面；模型卡：Qwen3.5-4B、Gemma 4 E4B、Ministral 3 8B、Granite 4.2 8B、Nemotron 3 Nano 4B 和 SmolLM3-3B。我们的研究：QMSum 研究和 OpenRouter 结构化任务报告。