理解苹果的端侧与服务器基础模型发布
无声的宣言
没有NVIDIA/CUDA税。未言明的内容与已声明的内容同样重要，而这两个词就是CUDA和NVIDIA。苹果特别强调其不依赖NVIDIA硬件或CUDA API。训练使用苹果的AXLearn（运行在TPU和Apple Silicon上），服务器模型推理运行在Apple Silicon上，而端侧API是CoreML和Metal。
为什么？苹果对NVIDIA的厌恶程度犹如千日之热。蒂姆·库克宁愿坐在数据中心用算盘做矩阵乘法，也不愿花费数百万购买NVIDIA硬件。除了个人恩怨外，这也是个好的商业策略。苹果拥有从硬件开始的完整ML堆栈，不受GPU供应短缺的限制。苹果还能通过ML任务来内部测试其硬件和软件，确保这是ML开发者想要的。
缺点是什么？苹果的硬件和软件ML工程师必须学习新框架，可能会无意中重复以前的错误。例如，苹果设备最初容易受到LeftoverLocals攻击，而NVIDIA设备则不会。如果有苹果员工在读这篇文章，我们很乐意审计AXLearn、MLX和其他你们正在开发的东西！我们的兴趣在于ML、程序分析和应用安全的交叉点，你们的框架引起了我们的兴趣。
模型
至少发布了五个模型。我们来数一数：
- 约30亿参数的端侧模型，用于摘要和写作工具等语言任务。
- 大型服务器模型，用于过于复杂无法在端侧完成的语言任务。
- 内置XCode的小型端侧代码模型，用于Swift代码补全。
- 大型服务器代码模型（“Swift Assist”），用于复杂代码生成和理解任务。
- 为Genmoji和Image Playground提供支持的扩散模型。
可能还有更多；这些没有明确说明但合理：用于语义搜索的重新排序模型，以及使用应用意图的指令跟随模型（尽管这可能只是普通的端侧模型）。
约30亿参数的端侧模型
苹果设备将获得一个约30亿参数的端侧语言模型，该模型在网络爬虫和合成数据上训练，并专门针对指令跟随进行了调优。该模型在大小上与微软的Phi-3-mini（38亿参数）和谷歌的Gemini Nano-2（32.5亿参数）相似。端侧模型将随着苹果用新数据训练而持续更新并推送到设备。
是什么模型？合理的猜测是苹果OpenELM的衍生版本。参数数量相符（30亿），训练数据相似，且论文中广泛讨论了LoRA和DoRA支持，这只有在计划部署类似苹果的系统时才有意义。几乎可以肯定不是直接的OpenELM，因为词汇表大小不匹配，且OpenELM未经过安全调优。
大型（我们猜测1300亿-1800亿）混合专家服务器模型
对于无法在设备上完成的任务，有一个在苹果私有计算云中运行在Apple Silicon服务器上的大型模型。该模型在大小和能力上与GPT-3.5相似，可能实现为混合专家模型。为什么我们对大小和MoE架构如此自信？引用的基准测试中的开源比较模型（DBRX、Mixtral）是MoE且大约是这个大小；这不仅仅是巧合。
端侧代码模型
在平台状况中引用了端侧代码模型；展示了几个集成到XCode中的类似Github Copilot行为的例子。没有关于模型的具体细节，但合理的猜测是一个20亿-70亿参数的代码模型，针对特定任务进行了微调：Swift的中间填充。该模型在Swift代码和苹果SDK（可能包括代码和文档）上训练。从演示视频来看，与XCode的集成做得很好；XCode收集本地符号和适当的上下文，以便模型更好地预测正确的文本。
服务器代码模型
品牌为“Swift Assist”，也出现在平台状况中。看起来是苹果对GitHub Copilot Chat的回应。关于模型的细节不多，但查看其演示输出，我们猜测它是一个700亿+参数的模型，专门在Swift代码、SDK和文档上训练。可能使用人工创建和合成生成的数据对指令跟随和代码生成任务进行了微调。再次强调，与XCode在提供相关上下文方面有紧密集成；视频提到自动识别和使用项目中存在的图像和音频资源。
图像扩散模型
该模型在平台状况中讨论，并通过Genmoji和Image Playground功能隐式展示。苹果在图像模型方面有大量已发表的工作，比语言模型更多（比较苹果HF页面上每种模型类型的数量）。根据其架构幻灯片，有一个基础模型和一组适配器，以提供对所需图像风格的细粒度控制。
适配器：大量的LoRA（和DoRA）
端侧模型将附带一组LoRA和/或DoRA（苹果术语中的适配器），这些适配器使端侧模型非常擅长特定任务。什么是适配器？它实际上是对原始模型权重的差异，使模型擅长特定任务（相反，在通用任务上表现较差）。由于适配器不必修改每个权重即可有效，它们可以很小（几十兆字节），而完整模型则很大（几千兆字节）。适配器还可以从基础模型中动态添加或删除，多个适配器可以堆叠在一起（例如，想象堆叠邮件回复+友好语气）。
对苹果来说，发布基础模型和适配器非常合理：发布适配器的额外成本低，并且由于完全控制操作系统和API，苹果非常清楚你在任何给定时间想要完成的实际任务。苹果承诺随着新训练数据的可用而持续更新适配器，我们想象新的适配器可以根据需要填补特定的行动利基。
一些技术细节：苹果表示他们的适配器修改多个层（可能相当于在HF的transformers中设置target_modules=“all-linear”）。适配器等级决定了它对基础模型的影响强度；相反，更高等级的适配器占用更多空间，因为它们修改更多权重。在等级=16时（从感觉角度来看是效果和适配器大小之间的合理折衷），每个适配器占用几十兆字节（相比之下，30亿基础模型占用几千兆字节），并保存在某种热缓存中以优化响应性。
假设你想立即了解更多关于适配器（基础技术，而不是苹果的具体实现）的信息。你可以通过苹果原生MLX示例或HF的transformers和PEFT包尝试。
向量数据库？
苹果没有明确说明这一点，但强烈暗示Siri的语义搜索功能是一个向量数据库；有一个明确的比较显示Siri现在基于含义而不是关键词搜索。苹果允许应用程序数据被索引，索引是多模态的（图像、文本、视频）。本地应用程序可以提供信号（如最后访问时间）给用于排序搜索结果的排名模型。
深入技术细节
训练和数据
让我们谈谈描述的一些训练技术。它们都是并行化训练非常大型语言模型的方法。本质上，这些技术是拆分和复制模型以使用大量计算和数据训练它的不同手段。以下是所用技术的快速解释，所有这些似乎对于训练如此大的模型都是标准的：
- 数据并行：每个GPU都有完整模型的副本，但被分配一块训练数据。所有GPU的梯度被聚合并用于更新权重，这些权重在模型之间同步。
- 张量并行：模型的特定部分被拆分到多个GPU上。PyTorch文档说一旦你有一个大模型或GPU通信开销成为问题，你将需要这个。
- 序列并行是最难找到的主题；我不得不挖掘到这篇论文的第6页。Transformer的部分可以被拆分为一次处理多个数据项。
- FSDP将你的模型分片到多个GPU甚至CPU上。分片减少了峰值GPU内存使用，因为不必将整个模型保存在内存中，但以同步状态的通信开销为代价。FDSP由PyTorch支持，并经常用于微调大型模型。
惊喜！苹果还使用AppleBot爬取网络进行训练。原始爬取自然包含大量垃圾、敏感数据和PII，必须在训练前过滤。确保数据质量是艰苦的工作！HuggingFace有一篇很棒的博客文章关于提高其网络爬取质量所需的内容，FineWeb。苹果必须做类似的事情来过滤掉他们的爬取垃圾。
苹果还有许可的训练数据。没有提到数据合作伙伴是谁。支付高质量数据似乎是新常态，大型科技公司与大型内容提供商（如StackOverflow、Reddit、NewsCorp）达成协议。
苹果还使用合成数据生成，这也是相当标准的做法。然而，这引发了一个问题：苹果如何生成合成数据？也许与OpenAI的合作让他们合法地清洗GPT-4输出。虽然合成数据可以创造奇迹，但它并非没有缺点——在大型合成数据语料库上训练存在遗忘问题。
优化
本节描述苹果如何优化其设备和服务器模型，使其更小，并在资源有限的设备上实现更快的推理。许多这些优化是众所周知的，并且已经存在于其他软件中，但很高兴看到关于在生产LLM中应用哪些优化的这种详细程度。
让我们从基础开始。苹果的模型使用GQA（与OpenELM的另一个匹配）。它们共享词汇表嵌入表，这意味着一些嵌入层在输入和输出之间共享以节省内存。端侧模型有一个49K令牌词汇表（与OpenELM的关键区别）。托管模型有一个100K令牌词汇表，带有语言和“技术令牌”的特殊令牌。模型词汇表意味着模型识别多少字母和短序列单词（或令牌）作为唯一。一些令牌还用于向模型发出特殊状态信号，例如提示结束、填充中间的请求、正在处理的新文件等。大词汇表使模型更容易理解某些概念和特定任务。作为比较，Phi-3的词汇表大小为32K，Llama3的词汇表为128K令牌，Qwen2的词汇表为152K令牌。大词汇表的缺点是导致更多的训练和推理时间开销。
量化和调色板化
模型通过调色板化和量化压缩到3.5比特每权重（BPW），但“实现与未压缩模型相同的准确性”。“实现相同的准确性”是什么意思？可能指的是可接受的量化损失。以下是一个PR到llama.cpp的图表，显示了截至2024年2月不同技术的最先进量化损失。我们没有被告知苹果的可接受损失是多少，但怀疑3.5 BPW压缩与16位浮点基础模型相比会有零损失。使用“相同准确性”似乎具有误导性，但我很乐意被证明是错误的。压缩还影响准确性以外的指标，因此模型的能力可能会以基准测试不易捕捉的方式降低。
什么是低位调色板化？这是苹果的压缩策略之一，在其CoreML文档中描述。理解它的最简单方法是使用其同名，图像颜色调色板。未压缩的图像存储每个像素的颜色值。一个简单的优化是选择一些在图像中最常见的颜色（比如16种）。然后图像可以编码为颜色调色板的索引和16个全颜色值。想象同样的技术应用于模型权重而不是像素，你就得到了调色板化。它有多好？苹果发布了一些2位和4位调色板化有效性的结果。2位调色板化看起来提供约6-7倍于float16的压缩，4位压缩测量为约3-4倍，只有轻微的延迟损失。我们可以大致假设3.5 BPW将从原始16比特每权重模型压缩约5-6倍。
调色板化仅适用于模型权重；在执行推理时，运行时状态是内存使用的重要来源。激活是应用某种变换函数后神经元的输出，在深度模型中存储这些可能占用大量内存，量化它们是适应更大模型进行推理的一种方式。什么是量化？它是一种将大范围（如16位）的区间映射到更小范围（如4或8位）的方法。在这个WWDC 2024视频中有一个很好的图形演示。
量化也应用于嵌入层。嵌入将输入（如单词或图像）映射到ML模型可以使用的向量。嵌入的数量/大小取决于词汇表大小，我们看到端侧模型为49K令牌。再次，量化这让我们在更少的内存中适应更大的模型，但以准确性为代价。
苹果如何做量化？CoreML文档揭示算法是GPTQ和QAT。
更快的推理
第一个优化是通过KV缓存缓存先前计算的值。LLM是下一个令牌预测器；它们总是每次生成一个令牌。通过模型重复重新计算所有先前的令牌自然涉及许多重复工作，可以通过缓存先前结果来节省！这就是KV缓存的作用。提醒一下，缓存管理是计算机科学的两个难题之一。KV缓存是HF的transformers包、llama.cpp和可能所有其他开源推理解决方案中实现的标准技术。
苹果承诺在iPhone 15上，每个提示令牌的首令牌时间为0.6毫秒，推理速度为每秒30个令牌（在令牌推测等其他优化之前）。这与当前开源模型相比如何？让我们运行一些快速基准测试！
在M3 Max Macbook Pro上，量化为Q4_K（约4.5 BPW）的phi3-mini-4k的首令牌时间约为1毫秒/提示令牌，生成约75个令牌/秒（见下文）。
苹果在性能较低的硬件上首令牌时间减少40%是一个重大成就。对于令牌生成，llama.cpp约75个令牌/秒，但再次，这是在M3 Max Macbook Pro上，而不是iPhone 15。
每秒30个令牌的速度对大多数读者来说没有太多锚点；重要的是它比阅读速度快得多，所以你不必坐着等待模型生成东西。但这只是起始速度。苹果还承诺部署令牌推测，这是一种较慢模型指导如何从较大模型获得更好输出的技术。根据在llama.cpp中实现此功能的PR中的评论，推测提供比正常推理快2-3倍的速度，因此消费者看到的真实速度可能接近每秒60个令牌。
基准测试和营销
苹果报告的基准测试中有很多好的和坏的。模型显然做得很好，但一些营销似乎专注于更高的数字而不是公平比较。首先说积极的，苹果评估其模型的人类偏好。这需要很多工作和金钱，但提供了最有用的结果。
现在，坏的：一些基准测试并不完全是苹果对苹果（双关语）。例如，比较人类满意度摘要的图表将苹果的端侧模型+适配器与基础模型Phi-3-mini进行比较。虽然端侧+适配器性能确实是用户会看到的，但公平的比较应该是苹果的端侧模型+适配器与Phi-3-mini+类似适配器。苹果本可以轻松做到这一点，但他们没有。
“人类输出有害性评估”和“安全提示人类偏好评估”显示苹果非常关心其模型生成的内容类型。再次，比较并不完全是苹果对苹果：Mistral 7B专门发布时没有审核机制（见底部的注释）。然而，其他模型是公平游戏，因为Phi-3-mini和Gemma声称有广泛的模型安全程序。
Mistral-7B表现如此差是因为它明确没有为减少有害性训练，不像其他竞争对手，后者是公平游戏。
WWDC视频中的一个片段真的让我们印象深刻。其中暗示macOS Sequoia比macOS Sonoma提供大的ML性能增益。然而，比较实际上是全权重float16模型与量化模型，性能增益是由于量化。
小字显示全权重与4位量化，但大字使其看起来像macOS Sonoma与macOS Sequoia。
其余基准测试在指令跟随、组合和摘要方面显示出令人印象深刻的结果，并通过比较基础模型与基础模型正确完成。这些基准测试对应于高级任务，如组合应用操作以实现复杂任务（指令跟随）、起草消息或电子邮件（组合）以及快速识别大文档的重要部分（摘要）。
对端侧处理和垂直集成的承诺
总体而言，苹果从UI/UX角度和最终用户立即有用的功能方面提供了非常令人印象深刻的主题演讲。技术数据发布不完整，但对于像苹果这样隐秘的公司来说相当不错。苹果还强调，完整的垂直集成使他们能够使用AI创造更好的设备体验，这有助于最终用户。
最后，苹果演示的一个重要部分我们直到现在才触及，即其整体承诺尽可能多地将AI保持在端侧，并确保云中的数据隐私。这说明了苹果的整体立场，即你是客户，而不是产品。
如果你喜欢这篇对苹果机器学习发布的综合，考虑我们可以为你的机器学习环境做什么！我们专攻结合应用和ML安全的困难、多学科问题。请联系我们以了解更多。
如果你喜欢这篇文章，分享它： Twitter LinkedIn GitHub Mastodon Hacker News