想象你开了一家融合餐厅：前厅是十几个快餐档口，后厨藏着一位米其林主厨。顾客点一份薯条，快餐档口三分钟就能端上来，三块钱搞定；顾客点一道分子料理，只有主厨能完成，要等二十分钟，收费三百。如果你让主厨去炸薯条，顾客等得久、你付的工资高；如果你让档口做分子料理，菜品直接翻车。聪明的老板会请一个传菜经理：一眼看出这道菜该走哪个厨房。这篇文章要讲的小语言模型（SLM）和大语言模型（LLM），正是这两类厨师——一个轻快便宜、适合端侧高频，一个渊博强大、擅长复杂推理。我们会一起看清它们的差异、各自的战场，以及如何用“分层路由”让它们协同工作，把成本和体验都优化到极致。

岗位关联

对 AI 从业者而言，理解 SLM 与 LLM 的场景边界是设计真实系统的基本功——它决定了你的方案在延迟、成本、隐私三个维度上是否经得起规模化检验。

目录
  1. 可视化演示
  2. 模型特性对比
  3. SLM适用场景
  4. LLM适用场景
  5. 核心判定维度
  6. 分层路由策略
  7. 工程落地挑战
  8. 生态发展趋势
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

展示SLM与LLM多维度对比、分层路由策略及三种部署方案，切换模式理解小模型与大模型的适用场景。

本节配有交互动效（进入视口后自动加载，约 3KB）。

'+captions.compare+'

模型特性对比

想象你经营的融合餐厅里，最忙的一天来了五百桌客人。快餐档口的厨师可以在三分钟内炸好薯条，站在吧台后面随取随走；而米其林主厨在后方厨房里，花二十分钟做一道精致的法式浓汤。这两类厨师就是 SLM 与 LLM 的缩影：前者身材小、动作快、成本低；后者知识渊博、处理复杂菜肴游刃有余，但慢且贵。作为老板，必须先看清两者的差异，才能决定什么时候让谁上场。

从业者看模型，通常从四个维度入手：延迟（出餐速度）、成本（菜价和人工）、隐私（客人是否介意自己的口味被记录）、能力上限（这道菜的复杂度是否超出档口的水平）。SLM 的优势恰好落在前三个——模型小，推理快，数据可以留在本地；LLM 的优势则在第四个——它的参数量巨大，见过更多“菜谱”，在复杂推理和多步规划上更从容。

延迟是第一个显性指标。端侧部署的 SLM 无需把数据传到云端服务器，省掉了网络传输时间；而 LLM 推理需要在大参数网络上逐个生成 token，整体延迟可以拆成三部分：

快餐档口就在客人面前现炸，连传菜都省了；米其林厨房在中央厨房，还要冷链配送。这就是端侧 SLM 和云端 LLM 在延迟上最本质的差距，也是后续所有场景决策的起点。

T总=T传输+T队列+T生成=DB+T队列+Nv生成T_{\text{总}} = T_{\text{传输}} + T_{\text{队列}} + T_{\text{生成}} = \frac{D}{B} + T_{\text{队列}} + \frac{N}{v_{\text{生成}}}
通俗说明：一碗面从下单到上桌的时间，等于服务员跑腿时间 + 排队等灶时间 + 厨师烹饪时间。端侧 SLM 把“服务员跑腿”（传输）压缩到几乎为零，自然快得肉眼可见。
  1. 传输时延数据从终端往返服务器消耗的时间，取决于数据量与带宽。
    DB\frac{D}{B}
  2. 队列时延请求在服务端等待 GPU 空闲所消耗的时间。
    T队列T_{\text{队列}}
  3. 生成时延模型逐个生成 N 个 token 的总耗时，与生成速度成反比。
    Nv生成\frac{N}{v_{\text{生成}}}

SLM适用场景

快餐档口绝不是“低端”的代名词。在商场这种高频客流场所，它反而是主力营收来源：点单快、出餐快、翻台率高。SLM 的适用场景，恰恰是在那些“量巨大、时延敏感”的战场上——边缘部署、高频调用、隐私敏感、实时响应。

所谓边缘部署，就是把模型塞进手机、门锁、车载盒子这类算力有限的设备里。模型小意味着内存占用少、功耗低、首次启动快。高频调用场景如语音助手的唤醒词识别，每秒可能发生几十次，如果每次都走云端，网络开销和费用都不可接受。隐私敏感场景则更直白：人脸特征、家庭语音、健康数据，能不出设备就绝不出设备。

SLM 之所以便宜，是因为推理成本与参数量和生成的 token 数近似成正比：

需要每秒处理几千次调用的智能门锁，等于商场里一天翻台五十次的奶茶档口——它不需要米其林主厨，只需要一位动作麻利、工资便宜的“快厨”。SLM 就是这位快厨，在端侧默默扛下大量简单请求。

C推理∝M参数量×NtokenC_{\text{推理}} \propto M_{\text{参数量}} \times N_{\text{token}}
通俗说明：成本约等于“厨师数量 × 菜品数量”。档口只派 3 名厨师做 1 道菜，米其林后厨 100 名厨师做 10 道菜，后者成本以数量级上升。
  1. 参数量模型存储的权重数量，SLM 通常在 1 亿到 10 亿之间。
    M参数量M_{\text{参数量}}
  2. 生成 token 数答案被拆成的词元数量，简单任务只需寥寥数个 token。
    NtokenN_{\text{token}}
  3. 正比关系参数量和 token 数同时翻倍，推理算力成本近似翻倍。
    ∝\propto

LLM适用场景

但总有一些菜，快餐档口做不了——分子料理、烤乳猪、刺身拼盘。当客人说“帮我策划一次七日欧洲游”时，这不是查表能解决的：需要多步推理、横向联想和结构化输出。LLM 的能力上限，决定了这类复杂任务只有它接得住。

复杂推理、多步规划、创意生成、开放式知识问答，这些任务的共同点是：没有固定模板，需要综合大量上下文。LLM 通过千亿级参数，在海量语料中学会了隐式的模式，能够分解目标、逐步执行、自我修正。而 SLM 因为参数少、“视野”窄，容易在长上下文和深推理中迷失方向。

为什么参数量如此关键？一个被广泛引用的缩放定律（scaling law）告诉我们，模型能力与参数量之间存在幂律关系：

这就是为什么当客户点名要“分子料理”时，传菜经理会毫不犹豫地转向米其林主厨。虽然贵、虽然慢，但只有他能保证成品质量。LLM 兜的“底”，正是 SLM 能力上限之下的那些深水区。

L(N)=L∞+(N0N)αL(N) = L_{\infty} + \left( \frac{N_0}{N} \right)^{\alpha}
通俗说明：模型错误率随参数量 N 增大而下降，但下降速度越来越慢。就像厨师见过的菜谱越多，做新菜的把握越高，但菜谱从一万份增加到两万份时，进步就微乎其微了。
  1. 不可约损失即使模型无限大也无法消除的本质误差。
    L∞L_{\infty}
  2. 规模因子参考参数规模，决定幂律曲线的整体位置。
    N0N_0
  3. 幂律指数描述能力随规模增长的速度，α 越大提升越明显。
    α\alpha
  4. 模型损失模型预测与真实答案之间的差距，越小越好。
    L(N)L(N)

核心判定维度

传菜经理手里有一张四维检查表，每张单子都要先快速过一遍。这四个维度正是技术团队选择 SLM 还是 LLM 时的核心判定框架：延迟需求、成本预算、隐私等级、任务复杂度。

延迟需求看业务是否允许几百毫秒级别的等待；成本预算看单位请求的推理费用是否可承受；隐私等级看数据是否敏感、能否出域；任务复杂度则看当前请求是否需要多步推理。这四个维度往往互相拉扯——一个请求既想要秒回，又想要深度分析，单靠某一类模型很难同时满足，必须靠后面的分层路由来拆解。

工程上可以把历史请求按四个维度打分，再用加权求和得到决策评分：

传菜经理不需要爱因斯坦的智商，但需要这套清晰的检查清单。把四个维度的直觉判断翻译成可量化的权重，技术团队才能在不同业务线之间复制这套“点单决策”。

S=w1×1T延迟+w2×1C成本+w3×Priv+w4×CapS = w_1 \times \frac{1}{T_{\text{延迟}}} + w_2 \times \frac{1}{C_{\text{成本}}} + w_3 \times \text{Priv} + w_4 \times \text{Cap}
通俗说明：S 就是传菜经理内心的“这单值不值得走米其林”综合分。延迟要求越高、成本预算越紧，越该给 SLM 加分；隐私越敏感、任务越复杂，越该给 LLM 加分。
  1. 延迟权重延迟越小得分越高，用倒数把“越低越好”变成“越大越好”。
    1T延迟\frac{1}{T_{\text{延迟}}}
  2. 成本权重成本越低得分越高，与延迟同理。
    1C成本\frac{1}{C_{\text{成本}}}
  3. 隐私等级数据敏感性打分，越敏感越倾向本地模型。
    Priv\text{Priv}
  4. 能力需求任务复杂度打分，越复杂越倾向大模型。
    Cap\text{Cap}

分层路由策略

聪明的老板不会让传菜经理“二选一”，而是让他两头都留着：简单订单走快餐档口，复杂订单走米其林后厨。这就是系统架构里的分层路由策略——SLM 处理简单任务，LLM 兜底复杂任务。

分层路由的核心是路由判定器。它接收用户请求，先让 SLM 试答，并采集 SLM 的自评置信度。如果置信度够高，直接返回；如果不够高，说明这单超出了 SLM 的能力范围，再升级给 LLM。这样既能保证大部分请求低成本快速完成，又不会让任何一个复杂问题被硬生生答错。

路由判定可以形式化为一个阈值函数：

分层路由把传菜经理提拔成了“总调度”。统计表明，80% 的常见请求根本不值得惊动米其林主厨，剩下 20% 的复杂请求由主厨稳稳兜底——成本下降一个量级，用户体验却没有明显滑坡。

Engine(q)={SLM,ConfSLM(q)≥θLLM,ConfSLM(q)<θ\text{Engine}(q) = \begin{cases}\text{SLM}, & \text{Conf}_{\text{SLM}}(q) \ge \theta \\\text{LLM}, & \text{Conf}_{\text{SLM}}(q) < \theta\end{cases}
通俗说明：Conf 是 SLM 对自己答案的“信心指数”，θ 是老板定的“及格线”。信心及格就放行，不及格就上交主厨。
  1. 用户请求 q一次具体的输入文本，例如“明天北京下雨吗”。
    qq
  2. SLM 自评置信度模型对生成答案正确性的内部评分，范围约 0 到 1。
    ConfSLM(q)\text{Conf}_{\text{SLM}}(q)
  3. 阈值 θ工程上通过验证集调参确定，θ 越高越保守、越倾向升级给 LLM。
    θ\theta
  4. 引擎选择根据置信度与阈值比较结果，返回 SLM 或 LLM。
    Engine(q)\text{Engine}(q)

工程落地挑战

餐饮协同要真正落地，麻烦事可不少：灶台不够用、菜单对不上、传菜流程本身拖慢速度、后厨没人盯火候。分层路由架构在真实系统中同样面临四座大山：资源受限、模型管理、路由延迟、监控调优。

资源受限指端侧硬件的内存和功耗是硬约束，模型必须量化压缩；模型管理指 SLM 与 LLM 的版本更新需要同步，否则路由判定和模型能力会失配；路由延迟指判定器本身也在消耗时间，如果它比直接请求云端还慢，就成了负优化；监控调优则要求持续跟踪各引擎的准确率、时延与成本，动态调整阈值。

引入路由后，系统的综合成本变成三部分加权：

开一家混合餐厅从来不是把两个厨房拼在一起那么简单。水电、动线、排班都要重新设计。但一旦搬开这四座大山，混合架构带来的成本和体验优势，是任何单一路线都无法比拟的。

C总=p×CSLM+(1−p)×CLLM+C路由C_{\text{总}} = p \times C_{\text{SLM}} + (1 - p) \times C_{\text{LLM}} + C_{\text{路由}}
通俗说明：总开销 = 简单订单比例 × 快餐成本 + 复杂订单比例 × 主厨成本 + 传菜经理的工资。路由层虽多了一笔管理费，但把 p 从 0.2 拉到 0.8，总账反而划算得多。
  1. 简单任务占比路由判定为 SLM 的请求比例，p 越接近 1 说明分层越有效。
    pp
  2. SLM 单位成本处理单个简单请求的推理费用。
    CSLMC_{\text{SLM}}
  3. LLM 单位成本处理单个复杂请求的推理费用。
    CLLMC_{\text{LLM}}
  4. 路由开销判定器本身的推理成本与延迟折合成本。
    C路由C_{\text{路由}}

生态发展趋势

未来的厨房正在发生三件大事：专用灶具越来越强（端侧芯片）、预制菜的保鲜工艺越来越成熟（模型压缩与蒸馏）、档口和后厨的边界越来越模糊（混合架构与 Agent 协作）。

端侧芯片（如 NPU、专用推理单元）不断突破，让原来只能在云端跑的模型开始在手机里高效运行；量化、剪枝、知识蒸馏让大模型“浓缩”成小模型，把 LLM 的能力下放给 SLM；混合架构取代单一大模型成为主流部署模式；多 Agent 协作则让多个 SLM 各司其职，必要时才调用一个共享的 LLM。

模型压缩是这场变革的关键推手，压缩率定义如下：

回到餐厅：未来的融合餐厅里，档口不再只会做薯条，因为主厨把拿手酱汁做成了浓缩配方教给了档口；档口之间还能互相协作，只有遇到真正的创意菜才会呼叫后厨。SLM 与 LLM 的边界，正在被生态的力量重新定义。

r=M原模型M压缩后r = \frac{M_{\text{原模型}}}{M_{\text{压缩后}}}
通俗说明：压缩率就像浓汤的浓缩倍数——10 倍浓缩意味着 1 升原汤变成 100 毫升高汤，使用时加水兑开。蒸馏后的 SLM 保留了原 LLM 的大部分能力，却小到能塞进你的手机。
  1. 原始模型大小压缩前的权重存储量，如 7B 模型约 14GB。
    M原模型M_{\text{原模型}}
  2. 压缩后模型大小量化或蒸馏后的存储量，如 4GB。
    M压缩后M_{\text{压缩后}}
  3. 压缩率两者比值，反映模型的瘦身程度。
    rr

AI 应用场景

手机端智能助手

阶段：推理部署与端云协同

解决的问题：每一次按键联想都请求云端大模型，会导致几百毫秒延迟、流量消耗和隐私泄露风险。端侧 SLM 可以在无网状态下完成热词联想和语音转写，只有语义复杂的指令才联动云端 LLM。

具体案例：主流手机输入法的语音输入，本地跑一个 3 亿参数 SLM 做语音转文字；用户说“帮我写一封辞职信”，本地模型置信度不足，自动上抛给云端 LLM 生成完整正式文本。用户感知不到切换，但体验和成本都大幅优化。

智能家居中控

阶段：边缘计算与云协同

解决的问题：开灯、设闹钟这类指令需要 200ms 内响应，且家庭语音涉及隐私，不能一直传云端。

具体案例：客厅中控盒子本地运行 SLM 识别高频指令（“调暗灯光”“设 7 点闹钟”），直接下发设备控制；遇到开放式对话（“给我讲个睡前故事”）才转发云端 LLM。断网时，基础控制依然可用。

企业客服分层处理

阶段：系统架构与成本优化

解决的问题：银行客服日均百万级请求，若全部调用 LLM API，年成本可能过千万，且响应时间无法满足服务级别协议要求。

具体案例：金融企业把 FAQ 类请求（账单查询、开户流程）先用检索增强加 SLM 快速生成；识别到客户情绪激动、问题涉及多业务联动时，再升级给 LLM 深度分析并生成安抚话术，配合人工坐席兜底。

Python 演示

python57 行
"""SLM+LLM 分层路由模拟器: 演示简单请求走小模型, 复杂请求走大模型."""  class HybridRouter:    """模拟同时挂了 SLM 与 LLM 的混合推理网关."""     def __init__(self):        self.simple_keys = ["天气", "时间", "计算", "翻译", "提醒", "闹钟"]        self.complex_keys = ["分析", "规划", "总结", "对比", "推理", "方案"]        self.slm_count = 0        self.llm_count = 0     def call_slm(self, query):        # SLM 延迟低, 成本低, 适合高频简单任务.        return {            "engine": "SLM",            "reply": "[SLM] {} 的快速答复".format(query),            "latency_ms": 45,            "cost": 0.001,        }     def call_llm(self, query):        # LLM 延迟高, 成本高, 但能处理复杂推理.        return {            "engine": "LLM",            "reply": "[LLM] 深度分析: {} 涉及多因素, 建议分三步推进...".format(query),            "latency_ms": 1800,            "cost": 0.03,        }     def route(self, query):        """路由判定: 含复杂关键词走 LLM, 否则走 SLM."""        if any(key in query for key in self.complex_keys):            self.llm_count += 1            return self.call_llm(query)        self.slm_count += 1        return self.call_slm(query)     def summary(self):        total = self.slm_count + self.llm_count        print("总请求: {} | SLM: {} | LLM: {}".format(total, self.slm_count, self.llm_count))        print("估算节省成本: {:.4f} 元".format(self.llm_count * 0.03))  if __name__ == "__main__":    router = HybridRouter()    queries = [        "今天北京的天气如何",        "帮我规划一个三亚五日游方案",        "计算 23 * 17 等于多少",        "分析这份销售数据并给出优化建议",        "下午三点提醒我开周会",    ]    for query in queries:        resp = router.route(query)        print("[{}] {} -> {}".format(resp["engine"], query, resp["reply"]))    router.summary()
目的：用关键词规则模拟分层路由，演示简单请求被 SLM 快速低成本处理、复杂请求被升级到 LLM，最终统计两类请求的比例与成本节省。
  1. class HybridRouter:定义一个混合推理网关类，内部同时持有 SLM 与 LLM 两套调用逻辑。
  2. self.complex_keys = ["分析", "规划", "总结", "对比", "推理", "方案"]复杂关键词表，命中即代表任务超出 SLM 能力上限。
  3. def route(self, query):路由判定入口，是整个分层策略的核心方法。
  4. if any(key in query for key in self.complex_keys):只要查询里包含任意复杂关键词，就升级给 LLM 兜底。
  5. self.llm_count += 1记录升级到大模型的请求数，用于事后统计成本。
  6. "latency_ms": 45,模拟 SLM 的毫秒级低延迟，与 LLM 的 1800ms 形成对照。
  7. router = HybridRouter()实例化混合路由器，等价于餐厅里新上任的“传菜经理”。
  8. resp = router.route(query)每次请求都经过路由判定，再进入对应引擎执行。

常见误区

误区初学者容易觉得 SLM 只是能力打折的 LLM。既然大模型能力更强，为什么不全部用大模型？小模型训练出来似乎没什么意义，迟早被淘汰。

正解SLM 不是 LLM 的廉价替代品，而是“不同物种”。它牺牲的是复杂推理上限，换来的是更低延迟、更高吞吐、更低成本、更强隐私。就像快餐档口和米其林主厨——档口做的薯条未必比主厨差，甚至更脆，关键是你点的是什么菜。在边缘部署、高频调用场景，SLM 是唯一可行解。

为何常见：因为评测榜单总是展示“越大分数越高”，让人忽略了真实业务中对延迟、功耗、数据驻留的刚性约束。

误区很多团队图省事，不管什么请求都统一打到 GPT-4 级别的大模型 API 上，觉得“反正智能程度高，总不会出错”。

正解实际生产中，LLM 的延迟和成本是 SLM 的数十到上百倍。高频简单请求如关键词抽取、意图识别、实体映射，用 LLM 是大炮打蚊子，既慢又贵；而且数据出域还有合规风险。分层路由的价值正在于此：把小请求留在本地，把大请求交给云端。

为何常见：在小规模验证阶段，请求量少，成本差异不明显，延迟也不敏感，很容易让人低估规模化后的巨大差距。

误区初学者以为路由判定只需要按关键词或长度做简单判断，比如“包含'分析'就走 LLM，否则走 SLM”。

正解真实的路由比这复杂得多。路由层需要评估 SLM 的置信度、上下文长度、业务优先级、模型版本失配风险，甚至需要一个专门的小分类器来预测“哪个引擎更适合当前请求”。阈值 θ 也不是拍脑袋定的，要靠验证集和线上监控动态调优。它更像传菜经理的综合经验判断，而不是一张死板的 if-else 表。

为何常见：因为“先试 SLM，不够再升级 LLM”这句话听起来很简单，掩盖了置信度评估、阈值校准和成本建模的大量细节。

误区觉得小模型就是“加载即用”，买一个开发板启动就行，不用考虑内存、功耗、算子优化。

正解端侧设备往往只有几百 MB 内存和几瓦功耗预算。SLM 仍需量化（int8/int4）、算子融合、剪枝、缓存优化，才能在真实设备上达到可用帧率，甚至还要针对特定芯片指令集做适配。一个小模型能否跑起来，和能否跑得流畅，是两个完全不同的工程命题。

为何常见：因为模型参数“小”是相对 LLM 而言的，而手机、门锁、车载 MCU 的资源与服务器 GPU 相差几个数量级。

面试题

Q1. SLM 与 LLM 相比，最突出的核心优势是？

单选题 · easy

  • A.复杂推理能力更强大
  • B.延迟更低且成本更便宜← 正确答案
  • C.多步规划能力更为突出
  • D.训练数据规模更加庞大

答案：B。SLM 的定位是“快、省、私”，它牺牲复杂推理上限换取低延迟和低成本。选项 A 和 C 是 LLM 的优势，D 与模型大小无关。就像快餐档口擅长快出餐，而不是做分子料理。

Q2. 以下哪种任务最适合交给 SLM 处理？

单选题 · easy

  • A.撰写万字行业分析报告
  • B.翻译一句简短的问候语← 正确答案
  • C.设计多智能体协作方案
  • D.求解高阶数学证明题目

答案：B。简短问候语属于高频、低复杂度任务，SLM 完全能胜任且速度快、成本低。报告撰写、方案设计、数学证明都需要复杂推理和长程规划，是 LLM 的主场。

Q3. 在“分层路由”架构中，路由判定器相当于餐厅里的？

单选题 · easy

  • A.厨房后厨的洗碗工人
  • B.负责传菜的总调度员← 正确答案
  • C.负责采购的供应商代表
  • D.给客人排队的等待区

答案：B。路由判定器负责判断每个请求该走 SLM 还是 LLM，等价于传菜经理判断每道菜该去快餐档口还是米其林后厨。洗碗工、采购员、等待区都不承担“分流决策”职责。

Q4. LLM 在复杂推理任务上优于 SLM，主要原因是？

单选题 · mid

  • A.参数规模更大模式识别强← 正确答案
  • B.训练数据语言种类更多
  • C.推理时不需要 GPU 设备
  • D.模型体积更小易于部署

答案：A。缩放定律指出，模型能力与参数量呈幂律关系，更大的参数规模带来更强的隐式模式识别和推理能力。语言种类多是次要因素，不需要 GPU 和体积小是 SLM 的优势而非 LLM 的。

Q5. 在门禁设备上部署本地语音助手，最应优先考虑？

单选题 · mid

  • A.云端千亿参数大模型服务
  • B.端侧亿级参数小模型← 正确答案
  • C.不需要部署任何模型
  • D.随机选择一个模型直接上

答案：B。门禁设备内存小、功耗低、隐私要求高，适合部署 SLM 做本地推理。云端大模型延迟高且涉及人脸等敏感数据出域，随机选模型则没有工程依据。

Q6. 请求被路由到 LLM，最可能的原因是？

单选题 · mid

  • A.当前 SLM 服务负载过高
  • B.任务含复杂推理需兜底← 正确答案
  • C.LLM 的响应速度更加快
  • D.希望降低推理的成本

答案：B。分层路由的核心原则是“SLM 打底、LLM 兜底”。路由到 LLM 通常是因为 SLM 自评置信度低于阈值，即任务复杂度超出 SLM 能力。LLM 更快、更便宜都与事实相反。

Q7. 以下哪项不是 SLM 在资源受限设备上的优势？

单选题 · hard

  • A.占用更少的内存资源
  • B.更低的运行功耗开销
  • C.更高的模型精度指标← 正确答案
  • D.更快的推理响应速度

答案：C。SLM 的优势体现在资源占用少、功耗低、响应快；但精度指标取决于具体任务，SLM 在复杂任务上精度通常低于 LLM。“更高精度”不是 SLM 的固有优势。

Q8. 下列哪些属于 SLM 的典型适用场景？

多选题 · easy

  • A.智能门锁本地人脸识别← 正确答案
  • B.手机实时语音输入功能← 正确答案
  • C.千万字长文全局深度推理
  • D.高频交易信号实时识别← 正确答案

答案：ABD。门锁人脸识别要求数据不出端，手机语音输入要求毫秒级响应，高频交易需要极低延迟，三者都适合 SLM。千万字长文全局推理需要极强长上下文理解，超出 SLM 能力上限，应交给 LLM。

Q9. “SLM 打底 + LLM 兜底”的分层路由方案，能带来哪些收益？

多选题 · mid

  • A.降低整体系统推理成本← 正确答案
  • B.减少大部分请求的延迟← 正确答案
  • C.彻底消除模型幻觉问题
  • D.保护敏感数据的隐私性← 正确答案

答案：ABD。大部分简单请求被 SLM 以低成本低延迟处理，且敏感数据不出端，因此 A、B、D 都成立。但幻觉是语言模型的通病，分层路由并不能“彻底消除”幻觉，C 过于绝对。

Q10. 关于 SLM 与 LLM 的对比，下列说法正确的是？

多选题 · hard

  • A.LLM 复杂推理强但成本延迟高← 正确答案
  • B.SLM 能力弱因此毫无使用价值
  • C.分层路由可结合两者优势← 正确答案
  • D.SLM 参数少适合端侧部署← 正确答案

答案：ACD。A 描述了 LLM 的典型权衡，C 是分层路由的核心价值，D 是 SLM 的基本特征，三者均正确。B 是典型误区——SLM 在边缘、高频、隐私敏感场景中价值极高，不能因其推理上限较低就全盘否定。