讲的是小语言模型SLM的定义核心优势与适用场景分析，对比大模型在成本延迟隐私方面的差异。你会学到SLM和LLM的界定标准、SLM在成本延迟隐私方面的优势、SLM的能力边界、以及什么场景该选SLM而非LLM，适用场景包括需要选择合适规模语言模型做端侧AI应用选型的场景。面向需要做语言模型选型评估SLM和LLM差异的架构师，帮你快速掌握核心要点并应用到实际项目中实现高效落地。

学习提示

需要学习小语言模型(SLM)定义与优势，理解大模型能力边界是构建AI应用的前提。本篇涵盖Transformer架构、预训练/微调/RLHF、Prompt工程，帮助你掌握大模型原理与应用。

目录
  1. 可视化演示
  2. AI 应用场景
  3. Python 演示
  4. 常见误区
  5. 面试题

可视化演示

状态—

讲的是小语言模型SLM的定义核心优势与适用场景分析，对比大模型在成本延迟隐私方面的差异。你会学到SLM和LLM的界定标准、SLM在成本延迟隐私方面的优势、SLM的能力边界、以及什么场景该选SLM而非LLM，适用场景包括需...

定义与界定：SLM到底是什么

你家楼下那家社区面包店的"身份"由什么决定？不是装修风格，不是营业时间，而是它的生产规模——烤箱多大、每天揉多少面团、库存周转多少。在AI行业里，模型的身份同样由一个硬指标定义：参数量（Parameters）。

所谓参数，可以理解为模型神经元之间连接的"权重"，每一个参数就是模型脑子里记住的一条"配方比例"。小语言模型（SLM，Small Language Model）通常指参数量在1亿到100亿之间的模型；而大语言模型（LLM，Large Language Model）动辄千亿甚至万亿参数。一百亿参数是什么概念？如果把每个参数比作一行面包配方，SLM的配方本大概一本书厚，而LLM的配方本可以堆满整座图书馆。

参数规模还连带决定了训练数据的体量。LLM需要数百亿甚至数万亿的token（可以粗略理解为"词语碎片"）来喂饱庞大的记忆系统；SLM则只需千亿级token，就能在特定领域练出够用的手艺。token这个抽象概念，可以理解为"面粉的颗粒"——大厂磨了满满一仓库，够全城吃一年；小作坊每天现磨一袋，刚好够今天卖给街坊。

参数量一百亿是SLM与LLM的分水岭——左边是小而美的社区店，右边是大而全的中央工坊。

D(P)={SLM,if P<1010LLM,if P≥1010D(P) = \begin{cases} \text{SLM}, & \text{if } P < 10^{10} \\ \text{LLM}, & \text{if } P \ge 10^{10} \end{cases}
  1. 判别函数 $D(P)$$D$ 是给模型"贴标签"的分类器，输入是参数量 $P$，输出是模型类别。
    D(P)={SLM,if P<1010LLM,if P≥1010D(P) = \begin{cases} \text{SLM}, & \text{if } P < 10^{10} \\ \text{LLM}, & \text{if } P \ge 10^{10} \end{cases}
  2. 阈值 $10^{10}$$10^{10}$ 即一百亿，是行业大致的分界经验值，并非绝对铁律。
    threshold=1010=100 亿\text{threshold} = 10^{10} = 100\,\text{亿}
  3. 分支条件小于阈值归为SLM，否则归为LLM。实际中1B到10B存在灰色地带，常结合任务表现与部署约束综合判断。 正如不是所有"小店"都叫面包店，SLM的边界也不只是参数量一把尺子。但掌握这个分水岭，你就能在讨论模型时，一眼判断出对方是"社区店"还是"中央工坊"，这是选型的第一步。
    if P<1010→SLM,else→LLM\text{if } P < 10^{10} \rightarrow \text{SLM}, \quad \text{else} \rightarrow \text{LLM}

成本优势：社区面包店的省钱哲学

开一家社区面包店要花多少钱？一台烤箱、一个柜台、几袋面粉，加起来不过十几万。而中央工坊呢？地皮、冷链、全自动产线，动辄几个亿。这种差异，正好映照SLM与LLM的成本鸿沟。

在AI的世界里，成本分两笔账：一笔是"开店费"——训练成本；一笔是"出餐费"——推理成本。训练一个千亿参数的LLM，需要上万张高端GPU连续跑几十天，仅电费就是天文数字；而训练一个几十亿参数的SLM，用少量GPU甚至消费级显卡就能在数天内完成，两者相差几个数量级。

推理成本更是日常运营的隐形杀手。每次用户向LLM提问，模型都要把几乎所有参数计算一遍——相当于每次买一个可颂，中央工坊都要启动整条生产线。而SLM参数少，每次推理的计算量小，就像社区面包师随手从炉里取一个给你，边际成本几乎可以忽略。

总成本 = 一次性训练成本 + 单次推理成本 × 调用次数。调用量越大，推理成本的差距越致命。

Ctotal=Ctrain+N×CinferC_{\text{total}} = C_{\text{train}} + N \times C_{\text{infer}}
  1. 总成本 $C_{\text{total}}$模型从训练到持续服务发生的全部费用。
    Ctotal=Ctrain+N×CinferC_{\text{total}} = C_{\text{train}} + N \times C_{\text{infer}}
  2. 训练成本 $C_{\text{train}}$训练阶段的一次性投入，包括GPU算力、电力与数据清洗人力。
    Ctrain=GPU数量×单价×训练天数C_{\text{train}} = \text{GPU数量} \times \text{单价} \times \text{训练天数}
  3. 推理成本 $C_{\text{infer}}$每处理一次请求的算力开销，SLM的 $C_{\text{infer}}$ 远小于LLM。
    Cinfer∝参数量PC_{\text{infer}} \propto \text{参数量} P
  4. 调用次数 $N$当 $N$ 达到亿万级时，推理成本成为总成本的主项——这正是SLM大显身手的战场。 当你的产品要面向千万级用户提供实时AI能力时，选择SLM就像是选择开一家社区面包店——前面省下的"开店费"，后面省下的"出餐费"，都会变成实打实的利润空间。
    lim⁡N→∞Ctotal≈N×Cinfer\lim_{N \to \infty} C_{\text{total}} \approx N \times C_{\text{infer}}

延迟优势：三十秒与半小时的距离

在中央工坊时代，买一个可颂的完整链路是：你在手机上点单 → 订单传到城郊工厂 → 师傅排期生产 → 冷链车配送 → 快递员送到家门口。半小时算快的。社区面包店呢？推门进去，师傅从身后的炉子里夹出刚出炉的可颂，三十秒完事。

SLM与LLM的延迟差距，正是这三十秒与半小时的距离。LLM通常部署在云端数据中心，用户请求需要经历：数据上行 → 网络传输 → 云端排队 → 模型计算 → 结果下行。每一步都在消耗时间，光网络往返往往就要几十毫秒到数秒。而部署在手机或车载设备上的SLM，请求根本不需要离开设备——就像面包就在眼前，伸手就能拿到。

延迟不只是"快一点"的问题。在实时语音交互、辅助驾驶、工业控制等场景，几百毫秒的延迟就意味着体验断裂甚至安全隐患。SLM让模型推理从"远程配送"变成了"现场制作"，这是端侧AI兴起的核心动力之一。

端到端延迟 = 网络传输 + 模型推理 + 排队等待。SLM把网络和排队直接消掉，只留下本地推理的轻量时间。

Te2e=Tnet+Tinfer+TqueueT_{\text{e2e}} = T_{\text{net}} + T_{\text{infer}} + T_{\text{queue}}
  1. 端到端延迟 $T_{\text{e2e}}$从用户发出请求到收到回复的全部耗时。
    Te2e=Tnet+Tinfer+TqueueT_{\text{e2e}} = T_{\text{net}} + T_{\text{infer}} + T_{\text{queue}}
  2. 网络传输 $T_{\text{net}}$数据在设备与云端之间往返的时间，受带宽和距离影响，通常为几十到几百毫秒。
    Tnet=2×数据量带宽T_{\text{net}} = 2 \times \frac{\text{数据量}}{\text{带宽}}
  3. 推理时间 $T_{\text{infer}}$模型计算回复的时间，与参数量和序列长度强相关，SLM可低至几毫秒。
    Tinfer∝P×序列长度T_{\text{infer}} \propto P \times \text{序列长度}
  4. 排队时间 $T_{\text{queue}}$云端高峰期的请求等待。SLM本地推理天然无排队。 在端侧场景中，SLM把漫长的"配送链路"压缩成了一步"转身拿面包"。而要做到这一点，它还必须具备一个关键能力——离线也能工作，这同样是云端大模型难以企及的。
    Tqueue≈0(端侧推理)T_{\text{queue}} \approx 0 \quad (\text{端侧推理})

隐私优势：看得见的安心

你在中央工坊下单，永远不会知道订单在配送链路上经过了多少双手。而在社区面包店，师傅当着你的面揉面、烘烤，你亲眼看到食材从哪来、如何加工——这种"看得见的安心"，正是SLM隐私优势的最好写照。

当你把对话请求发送给云端LLM时，你的文本、语音、位置等敏感数据，实际上已经离开了设备，经过网络传输、第三方接口，最终到达服务商的服务器。哪怕传输过程有加密，数据依然会被服务商"看到"——就像你的订货单被配送员、分拣员、仓管员经手了一遍。而SLM运行在本地设备上，数据自始至终没有离开手机或电脑，这就把隐私泄露的链条从源头切断了。

这对医疗、金融、法律等强合规行业尤为重要。医院不能轻易把患者病历上传云端，银行不能把交易流水外发给第三方模型。SLM的"数据不出端"特性，让AI能力可以合规地嵌入这些敏感场景，既不需要复杂的脱敏流程，也不必担心中间环节的"截胡"。从用户信任的角度看，"你的数据留在你的设备上"本身就是最好的隐私承诺。

隐私风险 = 暴露的数据量 × 传输次数。SLM让传输次数趋近于零，隐私风险自然归零。

Rrisk=Edata×KtransmitR_{\text{risk}} = E_{\text{data}} \times K_{\text{transmit}}
  1. 隐私风险 $R_{\text{risk}}$敏感数据被泄露或被滥用的综合风险程度。
    Rrisk=Edata×KtransmitR_{\text{risk}} = E_{\text{data}} \times K_{\text{transmit}}
  2. 暴露数据量 $E_{\text{data}}$一次请求中涉及的敏感信息量。
    Edata=∑i敏感字段iE_{\text{data}} = \sum_{i} \text{敏感字段}_i
  3. 传输次数 $K_{\text{transmit}}$数据在设备与云端之间的往返次数。本地推理时 $K_{\text{transmit}} = 0$。
    Ktransmit=0(端侧 SLM)K_{\text{transmit}} = 0 \quad (\text{端侧 SLM})
  4. 乘性关系$R$ 是乘法而非加法——传输次数为零，哪怕数据量再大，风险也为零。 社区面包店让人安心，是因为"眼见为实"。SLM的隐私优势也是同样的逻辑：数据不出设备，信任自然建立。这种看得见的安心，正在成为很多行业拥抱AI的前提。
    if Ktransmit=0,Rrisk=0\text{if } K_{\text{transmit}} = 0, \quad R_{\text{risk}} = 0

能力边界：面包师也有不会做的蛋糕

说了SLM这么多好处，也得承认：社区面包师会做香脆的法棍、柔软的可颂、扎实的乡村面包，但如果你要一个五层翻糖婚礼蛋糕，他真不一定接得了。SLM的能力边界，就像一个手艺精专但品类有限的老师傅。

具体来看，SLM在三个维度上明显弱于LLM。第一是知识广度：LLM读过海量公共语料，上知天文下知地理；SLM的知识面往往集中在训练数据覆盖的领域，问它专业领域之外的问题，可能答非所问。第二是复杂推理：数学证明、多步逻辑链、代码调试这类任务，需要模型在"工作记忆"中做多步操作，SLM的隐层维度和上下文窗口有限，推理链条一长就容易掉链子。第三是指令遵循：LLM能严格遵循复杂的多步指令，SLM面对绕来绕去的要求，常常只完成其中的一半。

还要警惕幻觉。SLM同样会一本正经地胡说八道——它只是参数少，并不意味着更诚实。事实上，由于训练数据不足，SLM在某些领域的幻觉率可能更高。这就是为什么在医疗诊断、法律咨询等高风险场景，即使用了SLM，也必须保留兜底校验机制。

效率 = 能力 ÷ 总成本。SLM单点能力弱于LLM，但在简单任务上"能力/成本"的比值碾压LLM。

Eeff=GmodelCtotalE_{\text{eff}} = \frac{G_{\text{model}}}{C_{\text{total}}}
  1. 模型能力 $G_{\text{model}}$综合知识覆盖、推理深度、指令遵循的能力得分。
    Gmodel=αlog⁡10(P)+βG_{\text{model}} = \alpha \log_{10}(P) + \beta
  2. 总成本 $C_{\text{total}}$前文定义的训练成本与推理成本之和。
    Ctotal=Ctrain+N×CinferC_{\text{total}} = C_{\text{train}} + N \times C_{\text{infer}}
  3. 效率比 $E_{\text{eff}}$单位成本换来的能力。SLM的 $G$ 虽小，但 $C$ 更小，比值反而领先。
    GSLMCSLM≫GLLMCLLM(简单任务)\frac{G_{\text{SLM}}}{C_{\text{SLM}}} \gg \frac{G_{\text{LLM}}}{C_{\text{LLM}}} \quad (\text{简单任务})
  4. 对数规律$G$ 随参数量对数增长——能力提升的边际效应递减，这正是SLM存在的理论依据。 面包师虽然不会做翻糖蛋糕，但每天卖出几百个可颂已经足够养活一家店。理解SLM的能力边界，不是否定它，而是为了在正确的场景里，让它的每分算力都花在刀刃上。
    dGdP=αPln⁡10\frac{\mathrm{d}G}{\mathrm{d}P} = \frac{\alpha}{P \ln 10}

选型指引：推开哪一扇门

现在你站在街口，左边是社区面包店，右边是中央工坊。你进哪一扇门？答案取决于你要买什么：如果只想买两个早餐可颂，去社区店；如果要订一个三层婚礼蛋糕，还是得去中央工坊。

工程上做模型选型，同样有四个维度的考量。第一是任务复杂度：文本分类、短句改写、意图识别这类"可颂级"任务，SLM完全胜任；而长文创作、复杂代码生成这类"婚礼蛋糕级"任务，必须交给LLM。第二是数据敏感度：涉及个人隐私、商业机密的场景，优先选SLM做本地推理，这是底线。第三是预算约束：训练和推理的预算决定你能养得起哪个档次的模型——算一笔账，LLM的云端API费用在规模化后可能吞掉全部毛利。第四是离线需求：网络不稳的车载、户外、飞行场景，只有SLM离线推理才能兜底。

现实中，更聪明的做法是"混合部署"——社区店和中央工坊同时开着：简单请求由端侧SLM秒回，只有复杂请求才上云交给LLM。这样既兼顾体验与成本，又给用户"既方便又安心"的双重满足。许多主流AI产品已经采用这种分层架构，取得了很好的商业回报。

选型评分 = 权重1×任务复杂度 + 权重2×数据敏感度 + 权重3×预算充裕度。分数高倾向LLM，分数低倾向SLM。

Score=w1⋅Ttask+w2⋅Spriv+w3⋅Bbudget\text{Score} = w_1 \cdot T_{\text{task}} + w_2 \cdot S_{\text{priv}} + w_3 \cdot B_{\text{budget}}
  1. 选型评分 $\text{Score}$衡量"该用多大模型"的综合指标。
    Score=w1⋅Ttask+w2⋅Spriv+w3⋅Bbudget\text{Score} = w_1 \cdot T_{\text{task}} + w_2 \cdot S_{\text{priv}} + w_3 \cdot B_{\text{budget}}
  2. 任务复杂度 $T_{\text{task}}$任务需要的知识广度与推理深度，越复杂则 $T$ 越高。
    Ttask∈[1,10]T_{\text{task}} \in [1, 10]
  3. 数据敏感度 $S_{\text{priv}}$数据泄露的严重程度。注意：$S$ 越高越该用SLM，因此实际权重 $w_2$ 为负值。
    rule: Spriv↑⇒SLM\text{rule: } S_{\text{priv}} \uparrow \Rightarrow \text{SLM}
  4. 预算充裕度 $B_{\text{budget}}$可用于GPU与API的预算，越充裕越能承受LLM。 没有一种模型是万能的。选型的本质，是在"能力"与"成本"之间画出属于自己业务的最优线。记住那句朴素的话：买可颂去社区店，定蛋糕去工坊——混合着用，才是一个成熟"美食家"的智慧。
    rule: Bbudget↑⇒LLM\text{rule: } B_{\text{budget}} \uparrow \Rightarrow \text{LLM}

AI 应用场景

手机端离线语音助手

阶段：模型推理部署

解决的问题：传统语音助手的语音识别与意图解析依赖云端，每次唤醒都有1-2秒延迟，且对话内容会经第三方服务器，用户隐私焦虑严重。SLM在手机端本地完成唤醒词检测、意图识别和简单问答，延迟降到50毫秒以内，对话记录不再离开设备。

具体案例：某手机厂商在旗舰机型中内置30亿参数的SLM，支持离线导航、定时提醒、本地相册搜索等高频功能。实测唤醒响应从1.5秒降至0.2秒，用户满意度提升40%。这就好比社区面包店把"从下单到拿到可颂"的时间压缩到了三十秒。

相关角色：端侧AI算法工程师、移动端AI架构师

金融行业智能客服本地化部署

阶段：模型私有化部署与推理

解决的问题：银行客服涉及账户余额、转账流水等敏感信息，上传云端进行推理面临合规风险与数据泄露隐患。SLM私有化部署在银行内网，数据处理全链路不离开安全区，既满足监管要求，又提供智能问答能力。

具体案例：某城商行将SLM部署在自有服务器上，用于理财知识问答与常见业务办理指引。上线后客服人工通话时长降低35%，所有对话日志留存在内网审计系统中，审计通过率100%。这就如同社区面包店当着顾客的面烘焙，每一步都可追溯。

相关角色：AI解决方案架构师、金融AI应用开发工程师

Python 演示

python53 行
""“SLM vs LLM 选型决策器”""def recommend_model(task_complexity, data_sensitivity, budget_level, offline_required):    """根据四个维度打分，推荐使用 SLM, LLM 或混合方案。     参数均为 1-10 的整数，10 表示程度最高。    """    slm_score = 0    llm_score = 0     # 任务简单，SLM 加分；任务复杂，LLM 加分    if task_complexity <= 4:        slm_score += 3    elif task_complexity >= 7:        llm_score += 3    else:        slm_score += 1        llm_score += 1     # 数据敏感，SLM 加分    if data_sensitivity >= 7:        slm_score += 3    elif data_sensitivity >= 4:        slm_score += 1     # 预算紧张，SLM 加分；预算充足，LLM 加分    if budget_level <= 4:        slm_score += 2    elif budget_level >= 8:        llm_score += 2     # 必须离线运行，只能选 SLM    if offline_required:        slm_score += 3     if slm_score > llm_score + 1:        return “推荐方案：端侧 SLM（省成本，低延迟，隐私好）”    if llm_score > slm_score + 1:        return “推荐方案：云端 LLM（任务复杂，需要大模型通用能力）”    return “推荐方案：混合部署（简单任务走 SLM, 复杂任务走 LLM）”  def main():    print(“=== 语言模型选型决策器 ===”)    print(“请按 1-10 打分，10 表示程度最高”)    tc = int(input(“任务复杂度(1-10): ”))    ds = int(input(“数据敏感度(1-10): ”))    bl = int(input(“预算充裕度(1-10): ”))    offline = input(“是否必须离线运行(y/n): ”).strip().lower() == "y"    print(recommend_model(tc, ds, bl, offline))  if name == "main":    main()

常见误区

误区很多人觉得小模型就是把大模型砍掉一半参数的残缺品，性能差、不值得用，甚至怀疑研究SLM是走弯路。

正解SLM不是残缺品，而是为特定场景重新设计的"专才"。它牺牲知识广度和复杂推理，换取成本、延迟、隐私的优势。这就像社区面包店不做翻糖蛋糕，但可颂做得比中央工厂更好——在端侧场景，SLM的综合性价比往往碾压LLM。

为何常见：大众媒体长期渲染"模型越大越聪明"的叙事，大家默认能力与参数线性挂钩，忽略了场景匹配的重要性。

误区只要参数小于100亿就是SLM，大于就是LLM，一锤定音，不需要看别的。

正解参数量只是最直观的粗略标准，模型能力还取决于训练数据质量、架构设计和量化程度。一个用优质语料充分训练的80亿参数模型，可能比一个没训好的100亿参数模型更强；经过智能压缩的SLM在具体任务上也能超越未优化的更大模型。

为何常见：厂商宣传资料总把参数量当最大卖点，导致大众习惯用单一数字评判模型好坏。

误区既然SLM"小"，那随便一个手机、路由器、甚至单片机都能跑，完全不用考虑硬件资源。

正解虽然SLM参数少，但推理仍需内存和算力。几十亿参数的模型通常需要数GB内存，普通MCU依然跑不动。端侧部署还要考虑量化、算子优化、散热和功耗。"小"只是降低门槛，不代表没有门槛。

为何常见："小"字让人联想到"无脑运行"，忽略了工程落地的复杂约束。

误区数据不出端就万事大吉，任何隐私问题都解决了，可以高枕无忧。

正解数据不出端大大降低隐私风险，但并非绝对安全。设备可能被恶意软件攻击，模型可能被逆向提取训练记忆，用户也可能在本地被钓鱼套取信息。隐私要靠"端侧隔离 + 系统安全 + 权限管控"共同保障，SLM只是提供了最基础的一层。

为何常见：把"风险降低"误当成"风险归零"，是安全话题中最常见的思维捷径。

面试题

Q1. SLM通常指参数规模在什么量级？

单选题 · easy

  • A.十亿级参数以下← 正确答案
  • B.百亿到千亿参数
  • C.万亿级参数以上
  • D.百万级参数以下

答案：A。SLM通常指参数在1亿到100亿之间（1B-10B量级），也就是十亿级。B选项百亿到千亿已经接近甚至进入LLM门槛；C选项万亿是超大模型；D选项百万以下不是主流语言模型的量级。就像社区面包店的"烘焙规模"决定了它不属于中央工坊。

Q2. SLM端侧推理延迟低的最关键原因是？

单选题 · easy

  • A.模型参数量少
  • B.免去网络传输← 正确答案
  • C.使用更强GPU
  • D.云端并发更高

答案：B。SLM端侧推理延迟低的首要原因是模型部署在本地设备上，省去了数据上传云端的网络往返时间，相当于可颂就在柜台后不用等冷链配送。参数少是原因之一但不是最关键——如果模型在云端，参数再少也要付网络延迟；C和D则与事实相反。

Q3. 下列属于SLM优点的是？

多选题 · easy

  • A.推理成本低← 正确答案
  • B.响应延迟低← 正确答案
  • C.隐私保护强← 正确答案
  • D.知识覆盖广

答案：ABC。SLM推理成本低（参数少、算力消耗小）、响应延迟低（本地推理）、隐私保护强（数据不出端），因此选ABC。D"知识覆盖广"恰恰是大语言模型的优势，SLM在这个维度上是短板，就像社区面包店不会做翻糖蛋糕一样。

Q4. LLM单次推理成本高的根本原因是？

单选题 · mid

  • A.训练数据采集贵
  • B.参数量大计算多← 正确答案
  • C.推理框架复杂
  • D.开源授权费用高

答案：B。LLM参数规模巨大，每次推理都要激活全部参数进行计算，算力消耗量级惊人，这是根本原因。A训练数据采集贵是一次性成本；C推理框架复杂不是成本主因；D开源授权费用并非普遍现象。就像中央工坊每烤一个可颂都要开整条产线，能耗自然高。

Q5. 最适合SLM落地的场景是？

单选题 · mid

  • A.长篇小说自动撰写
  • B.手机端离线语音助手← 正确答案
  • C.复杂数学定理证明
  • D.大规模科研数据分析

答案：B。手机端离线语音助手依赖低延迟、本地隐私保护和离线可用性，是SLM的典型场景。A长篇小说需要丰富的语言创造力，C复杂数学证明需要强推理，D大规模科研数据分析需要广泛知识，这些任务更像是"婚礼蛋糕"，得去中央工坊定制。

Q6. SLM的能力边界包括以下哪些？

多选题 · mid

  • A.知识覆盖有限← 正确答案
  • B.复杂推理能力弱← 正确答案
  • C.多步指令遵循差← 正确答案
  • D.响应速度比较慢

答案：ABC。SLM的知识覆盖有限、复杂推理能力弱、多步指令遵循差，这些是相对LLM的明显短板。D"响应速度比较慢"是错误的——SLM响应恰恰更快，这是它的优势而不是能力边界，就像社区面包店出餐快但不擅长做定制蛋糕。

Q7. 某企业需处理敏感医疗数据，最优先选择SLM的原因是？

单选题 · mid

  • A.模型体积小巧
  • B.数据不出本地← 正确答案
  • C.训练速度更快
  • D.支持中文更好

答案：B。医疗数据高度敏感，SLM本地推理保证数据不离开医院内网，这是最核心的考量。A模型体积小巧是工程便利而非隐私价值；C训练速度与部署场景无关；D中文支持与隐私优势无关。就像你在社区面包店看着师傅揉面，不需要担心配方被第三家店看到。

Q8. 某App需要实时翻译且需处理复杂长句，最优架构是？

单选题 · hard

  • A.全部请求交给云端LLM
  • B.全部请求交给本地SLM
  • C.端侧SLM为主复杂句上云← 正确答案
  • D.预训练一个大模型放本地

答案：C。端侧SLM处理日常短句实现秒回，复杂长句上云交给LLM保证质量，这是业界标准的混合部署方案，兼顾延迟、成本与效果。A全云端延迟高且隐私差；B全本地SLM处理不了复杂长句；D在本地部署大模型对手机不现实。就像社区店买日常面包、工坊定婚礼蛋糕。

Q9. 关于SLM与LLM的选型，下列说法正确的是？

多选题 · hard

  • A.简单任务优先用SLM
  • B.高敏感数据优先用SLM
  • C.复杂推理任务优先用SLM← 正确答案
  • D.预算有限优先用SLM
  • E.使用批处理优化
  • F.更换新型激活函数
  • G.知识蒸馏与硬件加速
  • H.扩大上下文窗口

答案：C。智能手表算力极低，进一步压缩模型体积（知识蒸馏）并调用NPU/DSP等硬件加速指令，是唯一可行的降延迟路径。A在手表上增大批处理不现实；B换激活函数收益微乎其微；D扩大上下文窗口反而增加计算与内存负担。这就像给社区面包师换一套更趁手的小型工具，而不是让他去做更大规模的订单。