NVIDIA 不希望你用一个大模型（LLM）来完成所有智能体（Agent）任务。
原因包括成本高、延迟大、系统开销重，以及 LLM 的各种限制，如部署难度、商业绑定等问题。
英伟达提出了一种「数据飞轮」方法：
通过分析实际使用数据，并根据可用工具对任务数据进行聚类和划分。
「小语言模型（SLM）已经足够强大，更适合智能体系统中的许多任务调用，且经济高效，因此它们才是智能体 AI 的未来。」
—— NVIDIA
随后，在不同工具能力的基础上，为特定任务微调对应的小语言模型。
当前，我们常常为了迁就 LLM 的使用，而调整智能体应用的设计方式。
这种“本末倒置”的局面，正是 NVIDIA 想要打破的。
NVIDIA 提出：
应根据子任务选择最合适的模型，并持续迭代优化。SLM 的训练应以实际用例和真实使用数据为依据。
「不是大语言模型，而是小语言模型，才是智能体 AI 的未来。」
—— NVIDIA
英伟达指出：
即使只是部分从 LLM 向 SLM 转移，在Agentic AI 行业也会带来重大的运营和经济影响。
当前的主流现状
绝大多数现代 AI 智能体，仍由超大语言模型（LLM）驱动。
LLM 决定了智能体何时、如何使用工具，如何规划任务流程、拆解复杂任务，并进行推理和决策。
智能体一般通过云端 API 与集中部署的 LLM 通信。
「智能体式交互，是采集用于未来改进的数据的自然路径。」
—— NVIDIA
但 LLM API 是为处理大批量、多样化请求而设计的“通用方案”。这种架构已经深深嵌入行业实践中。
NVIDIA 认为，LLM 在智能体系统中的统治地位过度且不合理，与大多数实际用例的功能需求严重不匹配。
为什么是小模型（SLM）？
优势明显：
更低的延迟
更少的内存和算力需求
显著降低的运行成本
在特定领域下，保持足够的任务性能
智能体系统通常会将复杂目标分解为多个子任务。这些子任务完全可以由专门微调过的 SLM 来高效完成。
因此，为什么不为每个子任务配备一个合适的小模型呢？
从架构设计上，让 SLM 成为默认选项，而仅在必要时才调用 LLM。
参数 ≠ 能力
在现代训练、提示工程和智能体增强技术加持下，决定性能上限的，早已不是参数规模，而是实际能力本身。
NVIDIA 指出，小模型在智能体系统中更具经济效益，原因包括：
推理效率高：调用快，响应快，能耗低
微调更灵活：适配任务更快、成本更低
易于边缘部署：适合嵌入设备、本地部署等轻量化场景
参数利用率高：不浪费计算资源，聚焦任务性能
NVIDIA 强调，在面对不同复杂度的任务和操作时，采用多种尺寸和能力的语言模型，是引入 SLM 的自然方式。
SLM 落地的现实阻碍
尽管小语言模型（SLM）在打造高效、专用的 AI 系统中潜力巨大，但它们的应用落地仍面临几项关键障碍：
1. 对 LLM 的前期投资过高
企业往往已经投入大量成本构建 LLM 中心化基础设施，短期内难以转型。
2. 评估方式不合理
SLM 的开发往往采用通用基准测试（Generic Benchmarks），这忽略了它们在具体场景下的「实际效能」。
3. 缺乏关注与话题度
相比宣传声势浩大的 LLM，SLM 较少被关注，常常被“忽略在雷达之外”。
NVIDIA 提出了一套清晰实用的转换流程，帮助你从通用大模型，过渡到高效、模块化的小语言模型智能体系统。
✅ 第一步：收集使用数据
从你现有的 LLM 系统中采集真实交互和调用数据，这一步是了解模型实际用途的关键。
✅ 第二步：数据脱敏清洗
在进入分析阶段前，确保删除或屏蔽任何敏感信息，以保护用户隐私和企业数据安全。
✅ 第三步：聚类识别任务模式
通过数据聚类算法，识别出重复出现的任务类型和操作路径，真正了解你的 AI 日常都在做什么、做得多频繁。
✅ 第四步：任务模型匹配
针对每一类常见任务，选择最合适的小语言模型架构（SLM），而不是一刀切地使用大模型。
✅ 第五步：数据集微调
为每个 SLM 准备专属的训练数据集，并进行微调，确保它能精准、高效地完成对应任务。
✅ 第六步：构建持续优化闭环
系统上线后，继续采集数据，追踪 SLM 的效果，并进行定期迭代优化，形成真正意义上的自适应智能体系统。
📌 简而言之，这不是一次性优化，而是长期演进的智能体架构设计思路。
通过这套闭环机制，企业和开发者可以持续将 LLM 中的通用能力「精炼」为多个高效可控的任务模型，让智能体真正具备“专业分工 + 协同作战”的能力。
粤ICP备14082021号
免费POC，
零成本试错
