Large Language Models vs Small Language Models

大语言模型与小语言模型

ByteByteGo

2026年6月24日

AI编写代码。谁来保障质量？（赞助）

AI辅助开发改变了代码的编写方式，但对许多团队而言，测试和治理尚未跟上。Tricentis AI Workspace弥补了这一差距，为质量工程领导者提供了一个统一的平台，用于在软件开发生命周期（SDLC）中构建、编排和治理AI质量代理，从代码风险分析和测试自动化到性能验证，确保质量决策持续进行，而非最后才做出。减少由AI生成代码引入的错误，增强对所交付内容的信心。

了解团队如何使用AI Workspace为AI驱动的开发带来结构，缩短交付时间表，同时不牺牲对业务成果的信心。

[查看Tricentis AI Workspace的实际应用](#)

苹果公司最雄心勃勃的AI功能在iPhone上运行，仅需约1GB的内存。而同一家公司在其自己的云服务器上运行一个更大的模型，两者在架构选择上几乎在“transformer”之外的所有方面都存在差异。

这种分裂在谷歌、微软和Meta也有所体现，其中一个小模型系列针对设备，而另一个大模型系列针对数据中心。

小语言模型和大语言模型是针对不同约束条件的不同工程响应，这些差异从模型运行的位置、目标硬件以及训练方式开始。

在本文中，我们将通过模型设计的三个层次探讨这些约束条件，分析每种方法带来的权衡，并研究将小模型和大模型结合使用的生产系统。

免责声明：本文基于来自各种来源的公开信息。如果您发现任何不准确之处，请留言评论。

基础

在探讨这两类模型之间的差异之前，明确它们的相同之处是有帮助的。

小语言模型和大语言模型都是基于Transformer的解码器模型，通过堆叠相同的基本计算块的多层构建而成。每个块执行一个注意力操作，确定哪些先前的标记对预测下一个标记最为重要，随后通过一个宽的中间层混合这些信息进行前馈计算。模型在生成下一个标记的概率分布之前，会重复这个块三十次或更多次。

这两类模型都经历类似的训练阶段。它们首先在大型文本语料库上进行预训练，模型通过数十亿个示例学习预测下一个标记。通常，它们接着在特定的指令模式上进行监督微调，许多模型还会经历基于人类反馈的强化学习，这决定了模型如何处理歧义并在对话中保持帮助性。

模型的大小指的是其参数数量，这些参数是在训练过程中调整的已学习权重。2026年，一个小模型通常有5亿到140亿个参数。而大模型有数十亿到数百亿个参数，有时甚至更多。

• 训练预算：较小的预算会促使团队通过数据质量和蒸馏来提高效率，而不是单纯依赖规模。

部署目标决定了后续的一切。

在手机上运行的模型，其内存预算以单个千兆字节为单位，电池预算以毫安为单位，延迟预算以毫秒为单位。而在数据中心运行的模型则处于一个更为宽松的环境中，关注点在于吞吐量、批处理效率和每请求成本，但其资源上限绝对值要高出几个数量级。

推理经济学是第二个压力源。

训练模型是一次性成本，在模型生命周期的开始阶段支付，而提供模型服务则是一个重复性成本，每次有人使用模型时都要支付。对于高流量的产品，推理成本会迅速超过训练成本，因此，为高推理量设计的团队会愿意在前期投入更多的训练计算资源，以节省后续数十亿次请求的推理计算资源。

训练预算则是第三个压力源。

训练一个前沿的大型模型可能需要花费数百万美元，而大多数专注于小型模型的团队所拥有的预算只是这个数额的一小部分，较小的预算迫使他们做出选择。这些团队必须寻找超越原始规模的其他杠杆，通常这意味着更智能的训练数据、从更大的模型中进行蒸馏，以及更高效的训练方法。

这三个约束相互强化，而不是孤立地起作用。为手机设计的模型每个请求的推理预算较小，通常训练预算也较小，而为数据中心设计的模型在所有三个维度上则正好相反。其结果是在同一空间中形成了两个截然不同的设计区域。

实际上是谁在审查所有这些AI生成的代码？（赞助内容）

当开发人员使用AI生成数千行未经验证的代码时，你可能会面临代码库的混乱局面。审查步骤成为团队的瓶颈，而唯一阻止细微错误进入生产环境的最后防线。

Greptile 会结合完整的仓库上下文对每个PR进行审查，并通过评论、反应和合并内容逐步学习团队的惯例。它会标记真正的代码问题，并提出符合团队风格的修复建议，而不是泛泛的最佳实践。

✅ 最近推出的 TREX 不仅阅读你的代码，还会运行你的代码。Greptile 在沙箱中执行更改，并返回截图、日志和追踪信息，作为实际发生问题的证明。

✅ 从终端进行审查。Greptile CLI 在你打开 PR 之前就可以在本地运行相同的审查。

✅ 被 NVIDIA、Scale AI 和 Brex 的工程团队信任。

✅ 现已与 Claude Code 集成：通过 /plugin 安装。

✅ 开源免费。

查看为什么开发人员喜爱 Greptile →

架构

架构差异从对推理的一个快速观察开始。

在生成过程中，模型必须保留之前每个 token 的键和值，因为注意力机制是通过将当前 token 与所有之前的 token 进行比较来工作的。这个存储的集合称为 KV 缓存，其大小随着对话长度的增加而线性增长。对于长生成任务，缓存通常会主导内存带宽和存储，比参数本身的影响更大。

这个单一的事实决定了小型模型架构的设计方式。

在原始的 Transformer 设计中，每个注意力头都有自己的键和值，这种安排被称为多头注意力。对于长序列来说，由此产生的缓存占用空间会变得非常大，足以主导模型的内存消耗。

分组查询注意力直接攻击了这个问题。查询头的数量保持不变，但多个查询共享一个键值对。一个拥有三十二个查询头的模型可能只使用八个键值组，这在质量损失最小的情况下，将缓存占用空间减少了四分之一。Llama、Qwen、Gemma 以及大多数现代小型模型默认使用分组查询注意力，许多大型模型也已采用这种技术，因为这种数学方法在大规模应用中也有帮助。

一些小型模型更进一步。Gemma 2 在不同层中将滑动窗口注意力与全注意力交错使用，因此某些层只关注最近几千个标记，而不是全部上下文。这以牺牲一些长距离推理能力为代价，显著减小了缓存占用。苹果的设备端模型在多个解码器层之间共享其键值缓存，在多个位置重复使用相同的存储状态。

这些架构决策都服务于同一个目标，即减少推理的运行时成本，而当模型必须在只有几 gigabytes 内存的设备上运行时，这正是最重要的限制因素。

训练

即使两个模型具有相同的架构，它们的能力也可能大不相同，这取决于它们所训练的数据以及训练的方式。

目前小型模型训练的最先进技术由以下三种技术定义：

• 数据筛选：经过精心挑选和人工生成的训练数据可以替代原始数据的大量体积。

• 知识蒸馏：较小的学生模型通过模仿较大教师模型的输出分布来学习，而不仅仅是从原始文本中学习。

• 过度训练：现代小型模型看到的训练数据量远多于计算最优比例所建议的数量，以训练成本换取推理效率的提升。

第一种技术是数据筛选。2023 年，微软的一个研究团队发表了一篇名为“Textbooks Are All You Need”的论文。他们使用大约七 billion 个经过仔细筛选的代码和人工生成的教科书风格数据，训练了一个 13 亿参数的编码模型。该模型的表现与使用数百 billion 个原始网络抓取数据训练的模型相当甚至更好。至少在某些能力上，训练数据的质量可以替代训练数据的体积。Phi 系列模型在此基础上不断推进，现代的 Phi-4 模型继续高度重视人工生成数据的质量，作为其主要的杠杆。

第二种技术是知识蒸馏。

小模型，称为学生模型，通过模仿大模型（称为教师模型）的输出分布来学习，而不仅仅是从原始文本中学习。更丰富的训练信号帮助学生模型学习那些仅凭底层语料库难以学习的模式。Gemma 2 使用这种方法训练其九 billion 参数的模型，而其二十七 billion 参数的版本则是从头开始训练的。

第三种技术是相对于计算最优的过度训练。

在2022年，DeepMind发表的Chinchilla论文指出，在固定的计算预算下，最佳模型来自于参数数量和训练数据之间的平衡，大致是每个参数对应二十个训练数据标记。现代的小型模型有意地使用远多于这个比例的训练数据。一个拥有30亿参数的模型在训练过程中可能会看到许多万亿个标记，这远远超过了Chinchilla所建议的最佳数量。一旦模型被部署，每提高一个百分点的质量，就能在数十亿次请求中节省推理计算资源，因此团队会在训练上投入更多，以在部署时节省更多资源。

部署

设计选择的最后一层涉及模型如何在实际硬件上执行。目前主导的两种技术是量化，它减少了每个参数的存储成本，以及KV缓存管理，它减少了生成过程中的运行时成本。

量化是指使用更少的位数来存储每个参数。一个标准的预训练模型将每个参数存储为十六位浮点数，将其减少到八位可以将内存占用减少一半，减少到四位则可以再减少一半。后训练方法实现起来更快，但在激进的位宽下往往会导致质量下降，而量化感知训练则在保持质量的同时，需要更复杂的训练过程。

硬件映射是下一个需要考虑的因素。苹果的神经引擎与NVIDIA Jetson的特性不同，而NVIDIA Jetson又与数据中心的H100不同，模型设计会根据目标硬件进行调整。Phi-4-mini针对消费级GPU进行了优化。Gemma 3 4B版本在NVIDIA Jetson Orin上运行，用于机器人和嵌入式系统中的边缘AI部署。苹果的3B模型在iPhone的神经引擎上运行，假设设备同时处理其他工作负载。

KV缓存管理是第二个主要杠杆，它直接与架构部分相关。缓存存储了生成过程中每个先前标记的键和值，其大小决定了模型在运行时使用的内存量。分组查询注意力通过减少键值头的数量来攻击这一问题，而苹果的设备端模型更进一步，通过在多个解码器层之间共享缓存来减少内存使用。

这些部署决策建立在之前所有内容的基础上。同样有助于缩小KV缓存的架构选择也使得量化更容易，而同样用于生成强大小型模型的训练方法也使得模型能够承受激进的压缩。

权衡

小型模型在MMLU和HumanEval等标准基准测试中表现良好。实际应用中的表现则更加多样化。三个差距通常最为重要：

• 泛化差距：小型模型在训练分布之外的表现更脆弱。

• 推理差距：多步骤问题仍然更倾向于大型模型，尽管这一差距正在缩小。

• 知识上限：参数充当内存，因此小型模型在能存储的内容上存在硬性上限。

第一个差距是泛化能力。

小型模型在训练分布之外往往更脆弱，它们在执行与训练期间看到的任务相似的任务时表现优异，但在面对意外任务时则表现出弱点。在一个大量训练于代码的小型模型上，它在代码任务上表现良好，但可能在一种不寻常风格的创意写作上遇到困难。在一个训练于合成教科书数据的小型模型上，它在教科书风格的问题上表现良好，但在面对真实用户发送的混乱和模糊提示时可能会表现不佳。

第二个差距是多步骤推理。

对于需要跨多个标记进行推理链的问题，大型模型仍然具有明显的优越性。由于逐步推理技术和专注于推理的微调方法，这一差距正在逐渐缩小，但在参数数量非常少的情况下，天花板依然存在。Phi-4 在数学推理方面表现优异，正是因为微软通过训练数据设计优化了这一能力，而通用的小型模型通常会表现出更明显的差距。

第三个差距是世界知识。

参数作为一种形式的内存，大型模型可以存储更多的事实、更多的命名实体、更多的隐晦引用以及更广泛的多语言覆盖。小型模型在知识存储方面存在根本性的上限，因为存储需要参数，而参数需要内存。对于需要广泛事实回忆的应用，小型模型通常会搭配一个外部知识源，当需要时模型会查询该知识源，因为试图将所有这些知识都放入参数中，会使模型超出其预算。

混合系统

2026 年最有趣的设计问题是，很少有人会问该使用哪种模型。更有用的问题是，如何将多个模型组合成一个系统，使每个模型都能发挥其最强的优势。大多数生产环境中的设置都出现了三种模式。

• 路由：小型模型直接处理请求，遇到较难的请求时升级到大型模型处理。

• 保护机制：小型模型在大型模型的核心工作周围过滤或分类输入或输出。

• 草稿生成：小型快速模型生成候选标记，由更大的模型批量验证。

最常见的模式是路由。

如果请求在小型模型的能力范围内，它会直接处理该请求；当请求难度超过其自信处理范围时，它会升级到大型模型处理。这种模式类似于分布式系统中的缓存层级，其中快速、廉价的层级处理常见情况，而较慢、更昂贵的层级处理其余情况。路由模型本身通常是一个小型分类模型，用于决定采取哪条路径。

第二种模式是保护机制。

小型模型位于大型模型之前，用于在昂贵的计算运行之前过滤或分类输入，检查是否存在不安全内容、分类请求意图或删除应保持私密的信息。通常还有一个小型模型位于输出端，在响应返回给用户之前执行类似的检查。这些保护模型便宜、快速且专业，这使它们非常适合这一角色。

第三种模式是草稿生成，有时也称为推测解码。

小型快速模型生成候选标记，而更大、能力更强的模型批量验证这些标记。当验证结果一致时，系统可以实现小型模型的吞吐量和大型模型的质量。苹果的设备端系统正是出于这个原因，同时使用了草稿模型和其基础模型。这种方法听起来像是一个变通手段，但它已经成为生产推理系统的标准做法。

选择模型类别并不是大多数产品决策的正确框架。围绕多个模型类别设计系统才是正确的框架，有趣的设计工作发生在组合层、路由逻辑、回退行为以及模型之间的协调中。

结论

我们最初提出的问题是“小型模型与大型模型”，而这个问题更有用的版本实际上是“哪些约束条件决定了每个模型的设计”。模型的大小是这些约束条件的后续结果，而不是设计的起点。

从这些约束条件中，产生了三个层次的设计选择：

• 架构通过诸如分组查询和滑动窗口注意力等注意力变体进行适应，从而减少KV缓存的大小。

• 训练通过高质量的合成数据、从更大的教师模型中进行知识蒸馏，以及相对于计算最优比例的有意过训练进行适应。

• 部署通过量化、KV缓存管理以及仔细的硬件映射进行适应。每一层都相互强化，结果是在同一空间中形成了两个不同的设计区域。

小型模型在其规模下能力非常强，但它们在泛化能力、多步推理和广泛的世界知识方面存在实际的上限。生产系统通过组合使用这两类模型来处理这一问题，通常使用小型模型处理常见情况，使用大型模型处理更复杂的请求，有时还会使用多个小型模型作为路由器、防护措施和草案生成器，围绕一个更大的核心模型运行。

对于正在选择模型的工程师来说，正确的起点是约束条件，而不是基准测试。真正重要的问题是关于部署目标、推理预算以及生产环境中请求分布的形状。

参考资料：

• Apple Intelligence Foundation Language Models Tech Report 2025

• Apple Intelligence Foundation Language Models

• Updates to Apple’s On-Device and Server Foundation Language Models

• Introducing Apple’s On-Device and Server Foundation Models

• Recurrent Drafter for Fast Speculative Decoding

• Recurrent Drafter

• Deploying Transformers on the Apple Neural Engine

• Textbooks Are All You Need (Phi-1)

• Textbooks Are All You Need

• Phi-4 Technical Report

• Phi-4-mini-instruct model card

• Running Phi-4 Locally with Microsoft Foundry Local

• Gemma 2: Improving Open Language Models at a Practical Size

• Gemma 2 Technical Report

• Lightweight, Multimodal, Multilingual Gemma 3 Models Are Streamlined for Performance

• GQA: Training Generalized Multi-Query Transformer Models from Multi-Head Checkpoints

• GQA paper on ACL Anthology

• Fast Transformer Decoding: One Write-Head is All You Need (Multi-Query Attention)

• Training Compute-Optimal Large Language Models (Chinchilla)

• Chinchilla Scaling: A replication attempt

• Reconciling Kaplan and Chinchilla Scaling Laws

• Attention Is All You Need

• Distilling the Knowledge in a Neural Network