原创 和你一起学习的 2025-09-04 18:07 上海
有多少agent的成本已经算不过来了？
不久前，作为这波大模型浪潮中，最大的红利收割方，英伟达发了一篇论文
《Small Language Models are the Future of Agentic AI》
取代LLM，SLM才是agentic AI 的未来。
所谓SLM，即Small Language Models ，小语言模型。
这么说的原因在于，英伟达观察到，随着agentic AI 系统崛起，其实模型在多数应用中，都在执行一些少量、专门化的任务，变化很小。
而在这些系统中，SLM 已经足够强、更适合企业的基础设施、并且必然更省钱。对应SLM 崛起，异构agentic systems 也将随之崛起（一个应用同时调用不同模型）。
顺应这个趋势，英伟达也给出了把agent系统从 LLM 迁移到 SLM的转换算法（文末有英伟达推荐SLM彩蛋）。
01
为什么需要SLM？
多数LLM 活不到盈利那天
为什么需要把LLM 迁移到 SLM，英伟达给出了两个原因:
原因一：现如今消费电子普及，把模型装进手机、手表、电脑，让模型在本地运营已经成为大势所趋。
原因二：大模型的成本与营收之间，已经出现巨大GAP。2024 年，面向agent的 LLM 推理 API市场规模估计为 56 亿美元，对应的云端推理基础设施投资为570 亿美元。
也就是说，硬件成本是软件营收的10倍。而过去，我们默认的SaaS与互联网山商业模式，则是 3–4 年内回本，或者说3-4年完成设备折旧。
通过这么一个简单的算术题不难发现，按照现如今的发展模式，很多大模型应用，甚至大模型企业，根本活不到能赚钱的那一天。
既然大模型这条路，不适合所有场景，小模型SLM（这里定义为参数量低于约 100 亿）自然就要登场。甚至成为agentic AI的顶梁柱。
对agentic AI来说，多数子任务都是重复、收敛、非对话式的，最需要的是高效、可预测、低成本。而相比传统LLM，SLM的优势恰在于此。也是因此，坚持“事事都用 LLM”，实质上是在错配算力，agentic AI更需要异构体系：默认用 SLM，必要时择时少量调用 LLM。
02
SLM取代LLM，效果如何
英伟达用几个开源agent（MetaGPT、Open Operator、Cradle）做了几个实验对比，结果如下：
（1）MetaGPT
agent简介：这是一个multi-agent framework，通过模拟软件公司的协作流程（产品、架构、工程、QA），覆盖需求、设计、实现与测试等领域。
LLM 调用点：角色行动（编码/文档）、模板化提示、动态规划/推理、RAG。
SLM 替代评估：常规代码生成、样板产出、模板化结构化响应可由 SLM 胜任。更复杂的架构推理、适应性规划或调试，初期仍更依赖 LLM 的广域理解。
结论：约 60% 的查询可用专门化 SLM稳定承接。
（2)Open Operator
agent简介：工作流自动化agent，允许用工具/服务去做 API 调用、监控与编排。
LLM 调用点：意图解析、流程决策、内容生成（摘要、报告）。
SLM 替代评估：简单命令解析与路由、模板化消息生成适合 SLM。多步推理或需要长时上下文维持的对话，LLM 仍具显著优势。
结论：约 40% 的查询可用专门化 SLM可靠承接。
（3）Cradle
agent简介：通用电脑控制（GCC），让代理通过截图与模拟操作去驱动 GUI 应用。
LLM 调用点：界面理解、任务序列规划、异常处理。
SLM 替代评估：重复性的 GUI 交互流程、预学会的点击序列由 SLM 处理良好；但动态界面适配、非结构化的故障应对，仍更仰赖 LLM 的上下文理解。
结论：约 70% 的查询可用专门化 SLM稳定承接。
03
SLM 的成本与灵活性如何？
我们先看成本，英伟达发现：
推理效率：服务一个 7B SLM 在延迟/能耗/FLOPs上往往比 70–175B 便宜 10–30×；新一代推理 OS（如 NVIDIA Dynamo）专门面向高吞吐、低延迟的 SLM 云/边部署。
集群简化：SLM 通常无需或少量跨 GPU/节点并行，降低运维复杂度与成本。
微调敏捷：PEFT（如 LoRA/DoRA）或全参微调在 SLM 上只需少量 GPU 时，微调定制可在一夜之间完成。
端侧部署：本地/离线推理（如 ChatRTX）让消费级 GPU 即可低延迟运行 SLM，数据更可控。
参数利用：LLM 内部信号常呈稀疏流动，单次输入仅激活部分参数；SLM 的这类“无效成本”更低，体现更高的结构效率。
模块化系统：现实任务异质，组合多尺寸运行天然契合；主流工程框架也在吸收这种积木化理念。结合工具调用、缓存、细粒度路由，SLM 优先的架构在成本、可调试性、可部署性与任务多样性上更有优势。
围绕灵活性，英伟达则认为
因为预训练与微调成本更低，SLM 天然更灵活：更容易训练多个专家模型去覆盖不同agent子流程，快速迭代以响应新需求（新行为、新格式、新合规要求等）。
至于LLM，的确能灵活，更强大，但是agentic系统，本质上是高度指令化、由外部精密编排的人机界面 + 工具集合的网关。原本“强通才”的 LLM，在一串繁琐提示与严密上下文管理下，被限制在其能力边界的窄小一角，有大材小用的嫌疑。
此外，在典型的AI agent需要有频繁的代码交互，在此过程中，工具调用和生成内容的输出必须符合工具参数的顺序、类型和性质。在这种情况下，模型无需处理多种不同的格式，对泛化能力需求不强。而使用单一格式决策进行训练与微调的 SLM，对固定格式的响应能力其实强于LLM。
此外，SLM 还可用自洽采样、验证器反馈、工具增强等推理时技巧进一步做能力增强：例如 Toolformer（6.7B）借助 API 表现可以胜过 GPT‑3（175B）；1–3B 小模型通过结构化推理可在数学题上逼近/追平 30B+。
而放眼未来，agent里的工具/模型调用，往往伴随非常具体的上下文工程实践，这全都是未来优化专家型SLM的天然数据来源，长此以往形成的良性循环，更加有利于SLM在agent中取代LLM。
04
几个辩证观点
对于几个业内主流的LLM一定优于SML的观点，英伟达也给出了反驳。
1、scaling law背景下，同代的大模型在性能上总会压过小模型。此外，大模型的泛化能力更强。
反驳：scaling law依然有效，但是它的前提是相同架构。但即使是同代模型，LLM与SLM往往也会采用不同的模型架构。此外，小模型针对特定任务微调的难度与效果也往往更优，更重要的是大模型的泛化能力，应对的是复杂输入，但是agenticAI存在的必要性，即在于把复杂任务拆解成一系列简单可执行的子任务。
2、LLM 的推理更集中，因此更便宜，此外SLM有一系列的微调、开发、运维成本。
反驳：这个观点的确是对的，但是我们也要注意到，长期看基础设施成本在降低；最新技术优化了 SLM 的负载均衡问题，也提升部署灵活性。
05
从 LLM 到 SLM 的转换算法
以下是英伟达给出的在agentic AI系统中，把 LLM 切换为 SLM 的步骤：
第一步：收集使用数据（Secure usage data collection）
目标：获取 LLM 在智能体中实际运行的 “实战数据”，为后续 SLM 训练提供依据。
具体操作：
部署 “数据采集工具”，记录智能体所有 “非人机交互（non-HCI）的模型调用”—— 包括输入给 LLM 的提示词（prompts）、LLM 输出的响应、智能体调用外部工具（如计算器、数据库）的具体内容，还可以有选择的记录 “响应延迟”（为后续优化速度做准备）。
数据安全要求：必须搭建加密的日志采集通道，设置 “基于角色的访问权限”（避免数据泄露）；存储前需对数据 “匿名化处理”，抹除数据来源标识（如用户 ID）。
第二步：数据整理与过滤（Data curation and filtering）
目标：将 S1 收集的原始数据，处理成 “干净、安全、可用” 的 SLM 训练数据。
具体操作：
个人身份信息（PII，如身份证号、手机号）、个人健康信息（PHI，如病历）；
应用专属敏感数据（如企业内部文档、法律文件）—— 可通过自动化工具对这类数据 “改写转述”，模糊化人名、数值等细节，但保留核心信息（确保数据仍能用于训练任务）。
先积累足量数据：通常 1 万 - 10 万条数据即可满足 SLM 微调需求（SLM 规模小，无需像 LLM 那样依赖海量数据）。
核心步骤是 “去敏感化”：删除或隐藏所有可能导致泄露的敏感信息，包括：
常用手段：借助成熟的自动化数据集处理工具，自动检测、屏蔽或删除敏感数据。
第三步：任务聚类（Task clustering）
目标：从整理好的数据中，找出智能体最常处理的 “重复任务模式”，为 SLM “定向专精” 提供依据（SLM 适合针对单一 / 少数任务优化，而非通用任务）。
具体操作：
用 “无监督聚类算法”（无需人工标注，让算法自动找规律）分析 S2 处理后的数据，重点挖掘 “输入提示词” 和 “智能体动作” 中的重复模式 —— 比如，智能体可能频繁做 “识别用户意图”“提取文档关键信息”“总结特定类型报告”“生成工具调用代码” 等任务。
这些 “重复任务模式” 就是 SLM 的 “候选专精任务”，任务的细分程度（颗粒度）取决于智能体实际操作的多样性（操作越多样，任务分得越细）。
第四步：SLM 选型（SLM selection）
目标：为 S3 识别出的每个 “专精任务”，挑选最合适的基础 SLM（相当于给不同任务选 “合适的原材料”）。
选型标准（四大核心维度）：
固有能力：SLM 是否适配任务需求（如做 “代码生成” 需选有编程能力的 SLM，做 “长文本总结” 需选上下文窗口大的 SLM）；
基准性能：在该任务的行业基准测试中，SLM 的表现如何；
授权许可：SLM 的商用授权是否合规（避免法律风险）；
部署成本：SLM 的内存占用、计算资源需求（是否能在智能体的部署环境中流畅运行，如边缘设备、小型服务器）。
第五步：专家 SLM 微调（Specialized SLM fine-tuning）
目标：将 S4 选好的基础 SLM，通过训练 “量身定制” 成适配特定任务的 “专家模型”（让 SLM 在目标任务上的性能接近甚至达到 LLM 水平）。
核心训练手段：
数据准备：从 S2 的干净数据和 S3 的任务聚类结果中，提取对应任务的专属数据集。
轻量化微调：优先使用 “参数高效微调（PEFT）” 技术（如 LoRA、QLoRA），这类技术只需微调 SLM 的少量参数，能大幅降低计算成本和内存消耗，适合中小企业或资源有限的场景。
全量微调（可选）：若资源充足（算力、资金），且需要 SLM 最大程度适配任务，可对 SLM 进行 “全量微调”（调整所有参数）。
知识蒸馏（可选）：让 SLM “模仿” LLM 在目标任务上的输出 —— 用 LLM 对任务数据集的处理结果作为 “标准答案”，训练 SLM 学习 LLM 的推理逻辑和输出风格，从而把 LLM 的 “精细化能力” 迁移到 SLM 上（弥补 SLM 规模小的不足）。
第六步：迭代与优化（Iteration and refinement）
目标：让替换后的 SLM 持续适配智能体的 “使用习惯变化”，避免长期使用后性能下滑。
具体操作：
定期用新收集的数据（按 S1-S2 流程更新）重新训练 SLM，同时优化智能体中的 “任务路由模型”（负责把用户请求分配给对应专精 SLM 的模块）。
形成 “持续改进闭环”：根据新数据的情况，灵活回到 S2（重新整理数据）或 S4（重新选型 SLM），不断优化模型性能。
06
尾声
通常来说，大模型经过海量数据的训练，其参数中已经隐含了大量的知识，能够处理更广泛的任务和更复杂的上下文理解。
而小模型通常参数量较少，计算需求较低，适合在资源受限的环境中使用，但它们的知识库相对有限，无法应对跨领域的复杂问题。
在这一背景下，通过引入外部向量数据库，可以扩充其对不同主题的处理能力。如对这一方面感兴趣，可参考我们的历史RAG教程。
彩蛋
英伟达严选SLM
首先，我们必须承认scaling law依然有效，但是作为同代产品的小模型与大模型之间的性能差距，正随训练与架构改进而陡峭缩小。
更重要的是，在agent情境下，sota并非必须，我们通常只需要关注三个核心指标：常识推理、工具调用与代码生成、指令跟随。
以下几个SLM是英伟达严选推荐：
Microsoft Phi 系列：Phi‑2（27 亿）在常识推理与代码生成上可与 300 亿级别模型比肩，且推理速度提升可达 15×。
Phi‑3 small（70 亿）在语言理解、常识推理上与同代更大模型相当，代码生成可追平同代 700 亿级别模型。
NVIDIA Nemotron‑H 家族：2/4.8/9B 的混合 Mamba‑Transformer，在指令跟随与代码生成上可比肩 30B 稠密 LLM，且推理 FLOPs 低一数量级。
HuggingFace SmolLM2 系列：125M–1.7B 的紧凑模型，在语言理解、工具调用、指令跟随上与14B 不相上下，并可匹敌两年前的 70B。
NVIDIA Hymba‑1.5B：通过Mamba+注意力的混合头 SLM，在指令准确性上拔尖，吞吐量是同体量 Transformer 的 3.5×，在指令跟随上甚至超越了更大的 13B。
DeepSeek‑R1‑Distill 系列：1.5–8B 的推理模型家族（蒸馏自 DeepSeek‑R1），常识推理强，7B 变体在若干评测中胜过专有大模型（如 Claude‑3.5‑Sonnet‑1022、GPT‑4o‑0513）。
DeepMind RETRO‑7.5B：检索增强 Transformer，参数仅 7.5B，却可在语言建模上逼近 GPT‑3（175B），参数少 25×。
Salesforce xLAM‑2‑8B：在工具调用上达SOTA，甚至超过 GPT‑4o、Claude 3.5 等前沿大模型。
如果大家还有更多推荐的SLM，欢迎在评论区留言推荐。
推荐阅读
首个Nano-banana企业级多模态RAG教程，适合电商、游戏场景
向量检索快比LLM还贵？不支持S3的向量数据库，迟早要淘汰！
国内首个 LangGraph Agent 模板！Multi-Agent框架最优解
全面测评LangChain vs LangGraph：谁是agent落地最优解
Embedding无敌？是做文档处理RAG最大的幻觉（含LangExtract+Milvus教程）
