人工智能行业存在两种截然不同的发展路径：一是追求越来越大的语言模型，如GPT-4、PaLM等，它们需要庞大的服务器集群才能运行；二是面向客户端设备（如手机、笔记本）的小型模型，它们能在本地完成推理，保护隐私且响应更快。本文聚焦于后者，深入探讨设备端推理的挑战、内存墙的制约、模型大小的硬性限制，以及为何服务器端AI在效率上依然占据优势。

为什么需要本地模型

设备上人工智能的潜在用例广泛多样。人们希望摆脱拥有所有数据的科技巨头。Google、Meta、百度和字节跳动，AI 5 大领导者中的 4 家，其目前的全部盈利能力基本上都基于使用用户数据来定向广告。只要看看整个IDFA混战，就可以看出缺乏隐私对这些公司来说有多重要。设备上的AI可以帮助解决这个问题，同时还可以通过针对每个用户的独特对齐和调整来增强功能。

为较小的语言模型提供上一代大型模型的性能，是AI在过去几个月中最重要的发展之一。

一个简单、容易解决的例子是设备上的语音到文本。这是相当糟糕的，即使是目前一流的谷歌Pixel智能手机也是如此。转到基于云的模型的延迟对于自然使用来说也非常刺耳，并且在很大程度上取决于良好的互联网连接。随着OpenAI Whisper等模型在移动设备上运行，设备上语音转文本的世界正在迅速变化。（谷歌IO还表明这些功能可能很快就会得到大规模升级。）

一个更大的例子是Siri、Alexa等，作为个人助理非常糟糕。在自然语音合成AI的帮助下，大型语言模型可以解锁更多可以为您的生活提供帮助的人类和智能AI助手。从创建日历事件到总结对话再到搜索，每台设备上都会有一个基于多模态语言模型的个人助理。这些模型已经比Siri、Google Assistant、Alexa、Bixby等功能强大得多，但我们仍处于早期阶段。

在某些方面，生成式人工智能正迅速成为一种双峰分布，具有大量的基础模型和可以在客户端设备上运行的小得多的模型，获得了大部分投资，并且两者之间存在巨大鸿沟。

小提示：如果你正在开发设备端AI应用，优先考虑隐私敏感的场景（如语音助手、本地翻译），这些场景对低延迟和离线运行有刚需。

常见问题

• Q：本地模型真的能保护隐私吗？ 是的，所有推理数据都在本地处理，无需上传至云端，避免了数据被第三方滥用。但需注意，模型本身可能带有隐含偏见，需谨慎设计。
• Q：所有AI功能都适合在设备端运行吗？ 不，对于需要庞大知识库或复杂推理的任务（如全面问答、多语言实时翻译），服务器端模型依然更优。本地模型更适合轻量级、实时性强的任务。

设备上推理的基本限制

虽然设备上人工智能的前景无疑是诱人的，但有一些基本的限制使得本地推理比大多数人预期的更具挑战性。绝大多数客户端设备没有也永远不会有专用GPU，因此所有这些挑战都必须在SoC上解决。主要问题之一是GPT样式模型所需的大量内存占用和计算能力。计算要求虽然很高，但在未来5年内将通过更专业的架构、摩尔定律扩展到3nm/2nm以及芯片的3D堆叠来迅速解决。

由于英特尔、AMD、苹果、谷歌、三星、高通和联发科等公司正在进行的架构创新，最高端的客户端移动设备将配备约500亿个晶体管和超过足够的TFLOP/s用于设备上的人工智能。需要明确的是，他们现有的客户端AI翻跟斗中没有一个非常适合Transformer，但这将在几年内改变。芯片数字逻辑方面的这些进步将解决计算问题，但它们无法解决内存墙和数据重用的真正根本问题。

GPT风格的模型被训练为在给定先前标记的情况下预测下一个标记（~= 单词）。要用它们生成文本，你需要给它提示，然后让它预测下一个标记，然后将生成的标记附加到提示中，然后让它预测下一个标记，然后继续。为此，您必须在每次预测下一个标记时将所有参数从RAM发送到处理器。第一个问题是您必须将所有这些参数存储在尽可能靠近计算的地方。另一个问题是您必须能够在需要时准确地将这些参数从计算加载到芯片上。

在内存层次结构中，在芯片上缓存频繁访问的数据在大多数工作负载中很常见。对于设备上的LLM，这种方法的问题在于参数占用的内存空间太大而无法缓存。以FP16或BF16等16位数字格式存储的参数为2个字节。即使是最小的“体面”通用大型语言模型也是LLAMA，至少有70亿个参数。较大的版本质量明显更高。要简单地运行此模型，需要至少14GB的内存（16位精度）。虽然有多种技术可以减少内存容量，例如迁移学习、稀疏化和量化，但这些技术并不是免费的，而且会影响模型的准确性。

此外，这14GB忽略了其他应用程序、操作系统以及与激活/kv缓存相关的其他开销。这直接限制了开发人员可以用来部署设备上AI的模型大小，即使他们可以假设客户端端点具有所需的计算能力。在客户端处理器上存储14GB的参数在物理上是不可能的。最常见的片上存储器类型是SRAM，即使在TSMC 3nm上，每100mm²也只有约0.6GB。

作为参考，这与即将推出的iPhone 15 Pro的A17芯片尺寸大致相同，比即将推出的M3小约25%。此外，该图没有来自辅助电路、阵列低效、NOC等的开销。大量本地SRAM将无法用于客户端推理。诸如FeRAM和MRAM之类的新兴存储器确实为隧道尽头的曙光带来了一些希望，但它们距离千兆字节规模的产品化还有很长的路要走。

层次结构的下一层是DRAM。最高端的iPhone 14 Pro Max有6GB内存，但常用iPhone有3GB内存。虽然高端PC将拥有16GB+，但大多数新销售的RAM为8GB。典型的客户端设备无法运行量化为FP16的70亿参数模型！

这就提出了问题。为什么我们不能在层次结构中再往下一层？我们能否在基于NAND的SSD而不是RAM上运行这些模型？

不幸的是，这太慢了。FP16的70亿参数模型需要14GB/s的IO才能将权重流式传输以生成1个token（~4个字符）！最快的PC存储驱动器最多为6GB/s，但大多数手机和PC都低于1GB/s。在1GB/s的情况下，在4位量化下，可以运行的最大模型仍将仅在约20亿个参数的范围内，这是在不考虑任何其他用途的情况下将SSD固定在最大值上仅用于1个应用案例。

除非你想在普通设备上等待7秒才能吐出半个字，否则将参数存储在存储器中不是一种选择。它们必须在RAM中。

小提示：量化（如int4）可以大幅减少模型体积，但会带来精度损失。在部署前务必测试量化后的模型在目标数据集上的表现，确保性能可接受。

常见问题

• Q：为什么不能直接使用缓存来加速？ 因为LLM的参数数量太大（数十亿级别），远超片上缓存容量（通常几十MB）。每次推理都必须从RAM加载全部参数，无法像传统应用那样频繁命中缓存。
• Q：未来有没有可能通过更好的存储技术解决内存墙？ 有，如FeRAM、MRAM等新型非易失性存储器有望实现更高密度和更低功耗，但距离商业化还需多年。短期内，优化模型结构和量化是更现实的手段。

模型尺寸限制

一般人每分钟阅读约250个单词。作为良好用户体验的下限，设备上的AI必须每秒生成8.33个tokens，或每120毫秒生成一次。熟练的速度读者可以达到每分钟1,000个单词，因此对于上限，设备上的AI必须能够每秒生成33.3个tokens，或每30毫秒一次。下表假定平均阅读速度的下限，而不是速读。

如果我们保守地假设正常的非AI应用程序以及激活/kv缓存消耗所有带宽的一半，那么iPhone 14上最大的可行模型大小是约10亿个FP16参数，或约40亿个int4参数。这是基于智能手机的LLM的基本限制。任何更大的产品都会排除很大一部分安装基础，以至于无法采用。

这是对本地AI可以变得多大和强大的基本限制。或许像苹果这样的公司可以利用它来追加销售更新、更昂贵、配备更先进人工智能的手机，但这还有一段时间。根据与上述相同的假设，在PC上，英特尔的顶级第13代CPU和苹果的M2的上限约为30到40亿个参数。

一般来说，这些只是消费设备的下限。重复一遍，我们忽略了多个因素，包括使用理论IO速度（这是从未达到过的）或为简单起见激活/kv缓存。这些只会进一步提高带宽要求，并进一步限制模型尺寸。我们将在下面详细讨论明年将出现的创新硬件平台，这些平台可以帮助重塑格局，但内存墙限制了大多数当前和未来的设备。

小提示：如果你正在为手机设计AI应用，建议将模型大小控制在20亿参数以内（int4量化），并优先考虑剪枝和蒸馏技术来进一步缩小体积。

常见问题

• Q：为什么阅读速度会影响模型大小限制？ 因为用户体验要求生成速度不低于人类阅读速度。如果模型太大导致生成缓慢，用户会感到卡顿。带宽限制直接决定了每秒能传输多少参数，进而决定了模型大小。
• Q：int4量化一定能达到40亿参数吗？ 理论上是，但实际需要考虑操作系统、其他应用的内存占用，以及量化带来的精度损失。建议先用10亿FP16参数模型做原型，再逐步优化。

为什么服务器端AI获胜

由于极端的内存容量和带宽要求，生成式AI比之前的任何其他应用程序更受内存墙的影响。在客户端推理中，对于生成文本模型，批量大小(batch size)几乎始终为1。每个后续标记都需要输入先前的标记/提示，这意味着每次从内存中将参数加载到芯片上时，您只需摊销成本仅为1个生成的token加载参数。没有其他用户可以传播这个瓶颈。内存墙也存在于服务器端计算中，但每次加载参数时，它都可以分摊到为多个用户生成的多个tokens（批量大小：batch size）。

我们的数据显示，HBM内存的制造成本几乎是服务器级AI芯片（如H100或TPUv5）的一半。虽然客户端计算确实可以使用便宜得多的DDR和LPDDR内存（每GB约4倍），但内存成本无法通过多个并发推理进行分摊。批量大小不能无限大，因为这会引入另一个难题，即任何单个token都必须等待所有其他token处理完毕，然后才能附加其结果并开始生成新token。

这是通过将模型拆分到多个芯片来解决的。上图是生成20个token的延迟。方便的是，PaLM模型达到每秒6.67个标记，或每分钟约200个单词的最小可行目标，其中64个芯片以256的批大小运行推理。这意味着每次加载参数时，它会用于256个不同的推论。

FLOPS利用率随着批处理大小的增加而提高，因为FLOPS，内存墙正在得到缓解。只有将工作分配到更多芯片上，才能将延迟降低到一个合理的水平。即便如此，也只有40%的FLOPS被使用。谷歌展示了76%的FLOPS利用率，PaLM推理的延迟为85.2秒，因此内存墙显然仍然是一个重要因素。

所以服务器端的效率要高得多，但是本地模型可以扩展到什么程度呢？

小提示：在服务器端，通过批量推理可以大幅降低每token的成本。如果你的应用需要高并发（如聊天机器人），建议使用服务器方案；如果只是个人使用，本地模型更经济且隐私。

常见问题

• Q：为什么批量大小不能无限大？ 因为每个batch需要等待所有token处理完才能生成下一个token，过大的batch会导致单个请求的延迟不可接受。需要权衡吞吐量和延迟。
• Q：服务器端的HBM内存成本更高，为什么还更划算？ 因为通过批量推理，一次参数加载服务多个用户，分摊了成本。客户端每次只服务一个用户，内存成本无法摊销，导致单次推理成本更高。

总结

设备端AI虽然能解决隐私和延迟问题，但受限于内存容量和带宽，目前最多只能运行约10亿参数的FP16模型（或4倍参数的量化模型）。相比之下，服务器端通过批量推理和高带宽内存（HBM）实现了更高的效率。未来，随着新型存储器（如FeRAM、MRAM）和更先进的量化技术发展，设备端模型的能力将逐步提升，但短期内内存墙依然是主要瓶颈。开发者应根据应用场景选择合适的部署方式：隐私敏感、低延迟的任务优先考虑本地模型；高并发、复杂推理的任务则依靠云端。