FM、LLM、SLM怎么选？一套面向业务边界的模型选型决策框架

上个月帮一个团队做技术方案评审，产品经理上来第一句就是"直接上最火的LLM不就行了"，工程负责人当场沉默——那套系统要跑在一张消费级显卡上，LLM的参数量连部署门槛都摸不到。类似的分歧我见过太多次了，很多人把SLM、LLM、FM当成"大中小三个型号"来选模型，实际上它们根本不是同一个分类维度下的东西。如果你也在这三个缩写之间来回纠结，或者正在给项目做技术选型，这篇文章就是我踩过一圈坑之后梳理出来的判断框架。

1. 从"参数多就是能力强"这个误区说起：FM、LLM、SLM到底是什么关系

1.1 先把"基础模型"这个概念锚定清楚

FM的全称是Foundation Model，中文通常叫基础模型。它的核心定义不是"参数特别多"，而是"在大规模数据上预训练、具备通用能力、可以通过微调等后续手段适配到不同下游任务的模型底座"。这个底座可以处理文本，也可以处理图像、语音、甚至表格数据，所以FM是一个很宽泛的概念，它描述的是模型的"生态位"——处于整个应用体系的底层，上面可以长出一堆针对具体任务的专用模型。

我之前跟一个做视觉的同事聊天，他说自己用"FM"做图像分割，又听别人说"LLM"做文本生成，一度以为FM是某个神秘的模型。其实把视线拉高一点就明白了：语言模型只是基础模型里的一个重要分支，还有很多非语言类的基础模型同样在业务里发挥着作用。所以FM不是一个型号，更像是一个"物种"的分类级别，它描述的是"这个模型是不是干通用预训练底座这件事的"。

1.2 LLM是"参数规模特别大"的语言专用选手

LLM全称Large Language Model，大语言模型。它在FM这个大类里，特指以自然语言为核心能力、参数量动辄几十亿上百亿起步的模型。LLM的特点在于大规模预训练之后出现了一些小模型不具备的"涌现能力"，比如复杂推理、多步规划、遵循复杂指令、上下文学习等。这也是为什么很多人一提到AI就会联想到LLM，因为它的表现足够惊艳，通用性足够强。

但LLM的"大"也直接带来问题：显存怎么都不够用、推理延迟高、单次请求成本贵。尤其是在金融、医疗这些对数据隐私极度敏感的行业，把数据送到第三方API本身就是一件需要打很多问号的事情，私有化部署里LLM的资源消耗又会把项目成本拉得很高。这是我后来深刻体会到的一件事：模型的能力不是免费午餐，每一项能力背后都有对应的基础设施账单。

1.3 SLM不是"低配版"，而是"为边界划出来的特型选手"

SLM全称Small Language Model，也就是小语言模型。它和LLM在分类维度上是同一轴的——都是语言模型，区别主要在于参数规模和与之对应的资源开销。但这里最容易踩的认知误区是：把SLM当成"能力缩水的弱模型"。实际上，近年开源的SLM系列里，很多几亿到几十亿参数的模型在特定任务上的表现已经逼近甚至看齐更大体量的LLM。

SLM的本质是"用更聪明的训练策略换参数效率"。它往往没有LLM那么庞大的知识覆盖面，但在某个限定领域里，通过蒸馏、领域预训练、高质量指令微调，可以把能力密度做得很高。打个比方：LLM像一个储备了海量知识的全科医生，什么病都能聊几句；SLM则像一个深耕某一科的专科医生，领域内的判断很可能比全科医生更精准、更快、更便宜。选型的关键从来不是"它有多大"，而是"你的业务边界在哪"。

2. 参数之外的另一笔账：成本、速度与延迟的真实权衡

2.1 训练成本：从电费到数据清洗都在烧钱

很多人选型时只盯着模型效果跑分，却忽略了落地成本。先说训练端：一个千亿参数级别的LLM从零开始预训练，所需算力资源对于绝大多数团队来说是完全不现实的，通常需要数百甚至上千张专用加速卡连续训练数周，这一笔算力费用就能劝退很多人。而SLM的预训练或微调成本通常只有LLM的零头，单机多卡甚至消费级硬件都能跑。

我见过一个很典型的需求：团队想做一个法律文书辅助审核系统，最初方案是拉一个千亿级LLM做微调，结果方案评审时算了算显存和训练时长，直接缩减到一个几十亿参数的SLM。最后的效果反而不错，因为法律条款和文书结构是高度模式化的，小模型把训练数据吃透之后很稳定，而且训练一轮只要几个小时，迭代起来非常灵活。这件事给我的教训是：先算资源账，再讨论效果账。

2.2 推理成本的量化差距：一次请求差出几个数量级

推理阶段的成本差距比训练阶段更容易被低估。粗略估算，参数规模每增加一个数量级，显存占用和单次推理计算量也随之大幅增长。以常见的半精度部署方式为例，显存占用大约等于参数量乘以2字节——一个70亿参数的模型，光是把权重放进显存就需要14GB左右，加上运行时中间变量和KV Cache，实际需求往往是权重的2到3倍。这还没有算上批量并发请求时的吞吐问题。

反过来看SLM，几亿参数的模型经过量化之后甚至可以塞进手机芯片。延迟也从秒级降到几十毫秒级别。我之前帮一个做客服工单分类的项目做选型，业务要求单次请求响应小于300毫秒，LLM根本做不到，换了SLM之后平均延迟才90毫秒左右，而且每秒并发吞吐量翻了十几倍。所以说，当你的业务存在实时交互、离线环境、高并发这类硬约束时，SLM往往不是"退而求其次"，而是唯一的可行解。

2.3 能力差值：不是所有任务都受益于更大模型

我见过太多人陷入"参数越大效果越好"的惯性思维，但实际测试结果经常啪啪打脸。文本分类、实体抽取、格式转换、意图识别这类"边界清晰"的任务，大模型和小模型的效果差距远没有想象中那么大。尤其是当训练数据质量足够高、标注足够准确时，一个精心微调过的SLM完全可以达到和通用LLM接近的效果。

但也有一些场景是SLM很难替代LLM的，比如开放式问答、创意文案生成、多维度的复杂推理、需要大范围常识支撑的任务。这类任务的难点在于"没有固定答案"，小模型的知识储备和推理链路不够深，容易给出逻辑断裂的回答。所以我现在的选型习惯是：把任务分成"有界"和"无界"两类，有界任务优先考虑SLM，无界任务才轮到LLM上场。

3. 按任务形态做决策：四个典型场景下的选型判断

3.1 文本分类、信息抽取类任务：直接用SLM微调

如果你的业务主体是"从一段文本里找出关键信息"或者"判断文本属于哪个类别"，比如评论正负面识别、简历信息抽取、工单自动打标，这类任务的共同点是输出空间有限、判断规则相对稳定。我最推荐的做法是找一个中文能力靠谱的小参数模型，用标注好的业务数据做指令微调。

这么做的好处很明显：第一，推理成本低，可以大方地上线覆盖面更广的业务场景；第二，迭代快，业务规则变了重新训练一轮也就一两个小时；第三，效果可控，小模型过拟合到你的业务分布之后非常稳定，不会像大模型那样"自由发挥"。

3.2 开放问答与创作类任务：LLM是刚需

如果你的产品核心是聊天助手、营销文案生成器、代码辅助工具这类"一句话根本说不清答案边界"的需求，我建议不要费劲去调SLM。开放任务的难点在于模型需要大量世界知识做底子，并且要理解用户意图中那些没说明白的潜台词。SLM在这方面的短板是结构性的，靠微调很难补齐。

当然，使用LLM也分两条路：一条是直接调用成熟API，按token计费、开发成本低、上线快；另一条是私有化部署开源LLM，用硬件成本换数据安全性。选择哪条路不取决于技术偏好，而是取决于你的业务是否允许把对话内容送出当前环境，以及你愿意为每次请求付出多少成本。

3.3 知识库问答（RAG）：LLM做大脑，SLM做服务员

这几年RAG（检索增强生成）特别火，很多人一想到知识库问答就直接上LLM。但实际落地时的最佳实践往往是混合结构：用LLM负责"读懂问题+组织答案"，用SLM负责"判断用户意图+挑选检索策略"。一个典型的例子是智能客服系统：用户问"我的快递到哪了"，小模型先做意图识别和关键信息提取，把"快递查询"这个信号送给后续流程，再由大模型把检索到的物流数据包装成自然语言回复。

这种分工还有一个额外收益：当用户问的是简单问题时，小模型可以直接给出模板化回复，完全不需要惊动大模型，整体调用成本能降一半以上。所以别把SLM和LLM放在对立面，更多情况下它们是搭档关系。

3.4 多模态任务：跳出"语言模型"的框架看FM

如果需求涉及图像理解、音视频分析、图文混合输入，这时候你需要关注的已经不是SLM还是LLM，而是更上层的FM选择。因为多模态基础模型天然就是FM这个分类里的成员，它同时对齐了文本、图像和语音的语义空间。建议你在选型时关心以下三个能力：多模态语义对齐的深度、对中文场景的支持程度、以及下游微调生态是否成熟。先确认基座模型能干这事，再考虑用小模型蒸馏还是大模型直连。

下表是我在不同项目里总结出的一个简版选型对照，供参考：

4. 落地前的三件事：评测基线、模型瘦身与部署形态

4.1 先建一套"业务私有评测集"，别拿公开跑分当尺子

我在选型时吃过最大的亏，就是拿公开榜单的跑分来预测业务效果。后来养成的习惯是：任何模型进入候选清单之前，先在我自己的业务数据上跑一遍。这个评测集不需要很大，三五百条真实场景样本就够，但样本一定要贴近线上噪音——包含用户手误的错别字、口语化的表达、模板外的说法。

做法很朴素：把同一批样本分别丢给候选模型，按照业务实际标准人工打分，最后统计准确率和关键错误占比。这件事看起来费时费力，但它能帮你避免上线之后的效果翻车。公开跑分测的是"通用能力"，而你的业务要的是"特定分布下的稳定输出"，这两者之间经常存在明显落差。

4.2 让SLM跑得更轻的瘦身手段：量化、蒸馏、LoRA

如果选了SLM，通常还要再做一轮瘦身才能真正落到资源受限的部署环境里。目前最常用的三招是量化、蒸馏和LoRA微调。

量化是最直接的压缩方式，把模型权重从FP16压到INT8或INT4，内存占用直接降到四分之一甚至更低。代价是精度会有一定损失，但配合一定程度的回退策略，多数场景是能接受的。我常用的做法是先做INT8量化观察业务指标，如果指标没有明显下滑再考虑压到INT4。

蒸馏是从大模型往小模型迁移能力的手段，用LLM的输出作为"参考答案"来训练一个更小的模型。这招在界定清晰的任务上特别管用，但千万别在开放任务上硬套，否则会得到一个小号复读机，只会输出大模型的平庸表达。

LoRA微调则是冻结原模型大部分权重、只训练一小批低秩矩阵，用极小的成本让模型适配特定领域格式。它和前面两招互不冲突，可以叠加使用：先LoRA微调把业务能力注入，再量化把体积压下来。

4.3 部署形态的取舍：端侧推理、API调用与私有化

部署形态直接由你的资源约束和安全要求决定。如果数据绝不能出内网，那就只能私有化部署，这时SLM的优势会被放大，因为一台常规服务器就能扛住相对可观的并发量。如果业务允许走公网API，且对延迟不敏感，直接使用大模型API是最省心的路径。

端侧推理则有些特殊，通常面向移动端或者IoT设备。这类环境存储和算力都很紧张，但胜在零延迟、离线可用、隐私安全。我在做端侧功能原型时，用量化到4bit的SLM跑在手机上，首次冷启动大概要两三秒，之后每次生成基本是毫秒级反馈，体验已经非常接近原生应用了。端侧模型选型的标准也和云端不全一样，要看内存占用峰值和电池消耗，而不只是跑分。

5. 选型路上容易踩的坑：我见过的翻车现场与对策

5.1 只看跑分不看业务评测，上线就被打脸

一个朋友的公司做了款内容审核辅助工具，选型时盯着几个榜单选了分数最高的模型，上线后却发现它对行业黑话和变体词完全无感，每天产生大量漏判。后来用三百条自己业务样本一测，才发现榜单Top1在自家场景里连前三都进不了。公共榜单的设计目标是广度，你的业务要的却是深度。所以哪怕再忙，也要先做私有化评测再拍板。

5.2 SLM的幻觉问题更隐蔽，但兜底设计不能省

很多人觉得SLM参数少、幻觉也少，这其实是一种错觉。SLM同样会出现编造内容的情况，只是编造的风格更像"一本正经地胡说"，因为它的知识覆盖面小，更容易把不属于训练分布的信息生硬地拼接出来。你要做的是在系统设计上补兜底机制：比如在RAG场景里强制要求模型引用检索原文，或者在生成任务后面加一道规则校验，对关键字段做合法性检查。别把纠错责任完全交给模型本身。

5.3 把蒸馏当成万金油，换了个领域瞬间失灵

蒸馏的适用范围比我当初以为的要窄得多。它要求教师模型和蒸馏后的学生模型面对的数据分布高度一致，一旦你换了一个细分领域，教师模型给出的"标准答案"就失去了参考价值。我之前试过把客服领域蒸馏出来的小模型直接用于售后投诉分析，结果关键指标比不蒸馏还差。后来学乖了：蒸馏数据必须用当前领域的真实场景重新构造，不能指望跨领域迁移。

5.4 底座模型一升级，整条链路都可能受影响

这个问题在依赖开源模型微调的项目里尤其突出。最初选定的基座模型每隔一段时间会发布新版本，你辛辛苦苦做的LoRA适配和量化参数都是基于旧版本调试的，升级之后轻则效果波动，重则直接崩溃。我的建议是：项目启动时就锁定一个基座版本号，把模型文件和微调工件一并固化到自己的模型仓库里。除非有明确的功能需求驱动，否则不要追新。追新是技术爱好者的习惯，但生产系统要的是确定性。

回头再看选型这件事，我最大的体会是：不要把SLM、LLM、FM当成同一个赛道上的三档选手，它们更像是三个不同维度的坐标——FM告诉你模型属于哪一类底座，LLM和SLM告诉你资源约束下的参数规模选择，而真正决定答案的是你的业务边界。我的习惯是先把任务边界、延迟要求、数据隐私、成本预算四个问题写在纸面上，再回头做技术选型。动手之前多花半小时把约束列清楚，后面能省下好几个月的返工时间。