iPhone 16 还剩一个月，微软开源新技术让手机以 6 倍速度提前跑上大模型

作者 | 微软亚洲研究院

责编 | 王启隆

出品 | AI 科技大本营（ID：rgznai100）

随着人工智能技术的飞速发展，将大语言模型(LLMs)部署到边缘设备上已成为当前 AI 领域的一个热门趋势。这一趋势不仅体现在微软 Windows 11 AI + PC 等产品中，也反映了整个行业对增强设备本地智能的追求。然而，在资源受限的端侧设备上部署庞大的语言模型并非易事，这需要在模型性能和硬件限制之间寻求平衡。

回顾过去几年的发展历程，我们可以看到端侧 AI 部署经历了几个关键阶段：

1. 早期尝试(2019-2020)：在 ChatGPT 都还没问世的那些年，研究人员主要关注如何将较小的神经网络模型（如 MobileNet）部署到移动设备上。这个阶段的主要挑战是如何在有限的计算资源下保持模型的准确性。

2. 量化技术的兴起(2020-2021)：随着模型规模的增大，量化技术开始受到广泛关注。Google 的研究团队在 TensorFlow Lite 框架中引入了动态范围量化，而 ARM 则推出了用于神经网络推理的 CMSIS-NN 库。

3. 大语言模型的挑战(2022-至今)：随着大语言模型的出现，如何在端侧设备上部署这些庞大的模型成为了新的挑战。苹果、谷歌、华为等科技巨头都在积极探索将 LLMs 部署到移动设备的方法。例如，苹果在iOS 17 中引入了本地运行的语言模型，而谷歌则在 Pixel 设备上部署了 Gemini Nano 模型，实现了部分 AI 功能的本地化。

以消费者的视角观察，今年 9 月的苹果发布会，可能就是端侧 AI 的第一次大规模面世了。但问题接踵而至：从舆情的角度来看，国行 iPhone 怎么办？不用 iPhone 和 Pixel 手机的人要怎么体验端侧大模型？从技术的角度来看，目前部署的大语言模型多会量化到低比特。而低比特 LLMs 在推理过程中需要进行低精度权重和高精度激活向量的混合精度矩阵乘法（mpGEMM）。

现有的系统由于硬件缺乏对 mpGEMM 的原生支持，不得不将权重反量化以进行高精度计算。这种间接的方式导致了显著的推理开销，并且无法随着比特数进一步降低而获得加速。

面对这些挑战，一些研究者开始思考：是否存在一种方法，可以同时解决低比特计算、混合精度问题，并且不依赖专用硬件？这种思考引导他们将目光投向了一个看似简单却颇具潜力的方向：查找表（Look-Up Table，LUT）。

查找表是计算机科学中一个古老而基础的概念。通过预先计算并存储结果，查找表可以将复杂的计算转化为简单的内存访问，这在某些情况下可以显著提高计算速度。那么，这个概念是否可以应用到大模型的端侧部署中呢？

基于这一思想，微软亚洲研究院的研究团队开发了 T-MAC（Table-based Matrix-vector multiplication Accelerator）。T-MAC 巧妙地破解替换表的概念应用到了矩阵乘法中，为端侧大模型提供了一套全新的解决方案。

在 CPU 上高效部署低比特大语言模型

当前大模型的部署普遍依赖于专用加速器，如 NPU 和 GPU 等，而 T-MAC 可以摆脱专用加速器的依赖，仅利用 CPU 部署 LLMs，推理速度甚至能够超过同一片上的专用加速器，使 LLMs 可以部署在各类包括 PC、手机、树莓派等边缘端设备。

T-MAC的关键创新在于采用基于查找表（LUT）的计算范式，而非传统的乘累加（MAC）计算范式。T-MAC 利用查找表直接支持低比特计算，从而消除了其他系统中必须的反量化（dequantization）操作，并且显著减少了乘法和加法操作的数量。

经过实验，T-MAC 展现出了卓越的性能：在配备了最新高通 Snapdragon X Elite 芯片组的 Surface AI PC 上，3B BitNet-b1.58 模型的生成速率可达每秒 48 个 token，2bit 7B llama 模型的生成速率可达每秒 30 个 token，4bit 7B llama 模型的生成速率可达每秒 20 个 token。这甚至超越了 NPU 的性能。

当部署 llama-2-7b-4bit 模型时，尽管使用 NPU 可以生成每秒 10.4 个 token，但 CPU 在 T-MAC 的助力下，仅使用两核便能达到每秒 12.6 个 token，最高甚至可以飙升至每秒 22 个 token。都远超人类的平均阅读速度，相比于原始的 llama.cpp 框架提升了 4 至 5 倍。

即使在较低端的设备如 Raspberry Pi 5 上，T-MAC 针对 3B BitNet-b1.58 也能达到每秒 11 个 token 的生成速率。T-MAC 也具有显著的功耗优势：达到相同的生成速率，T-MAC 所需的核心数仅为原始 llama.cpp 的 1/4 至 1/6，降低能耗的同时也为其它应用留下计算资源。

值得注意的是，T-MAC 的计算性能会随着比特数的降低而线性提高，这一现象在基于反量化去实现的 GPU 和 NPU 中是难以观察到的。但 T-MAC 能够在 2 比特下实现单核每秒 10 个 token，四核每秒 28 个 token，大大超越了 NPU 的性能。

图 1 BitNet on T-MAC vs llama.cpp on Apple M2

图 2 在不同端侧设备 CPU（Surface Laptop 7, NVIDIA AGX Orin, Apple M2-Ultra）的各核数下，T-MAC 和 llama.cpp 的 token 生成速度可达 llama.cpp 的 4-5 倍。达到相同的生成速率，T-MAC 所需的核心数仅为原始 llama.cpp 的 1/4 至 1/6。

矩阵乘不需乘，只需查表 (LUT)

对于低比特参数 (weights)，T-MAC 将每一个比特单独进行分组（例如，一组 4 个比特），这些比特与激活向量相乘，预先计算所有可能的部分和，然后使用 LUT 进行存储。之后，T-MAC 采用移位和累加操作来支持从1到4的可扩展位数。通过这种方法，T-MAC 抛弃了 CPU 上效率不高的 FMA（乘加）指令，转而使用功耗更低效率也更高的 TBL/PSHUF（查表）指令。

图 3 混合精度 GEMV 基于现有反量化的实现范式 vs T-MAC 基于查找表的新范式

以比特为核心的计算，取代以数据类型为核心的计算

传统的基于反量化的计算，实际上是以数据类型为核心的计算，这种方式需要对每一种不同的数据类型单独定制。每种激活和权重的位宽组合，如 W4A16（权重 int4 激活 float16）和 W2A8，都需要特定的权重布局和计算内核。例如，W3 的布局需要将 2 位和另外 1 位分开打包，并利用不同的交错或混洗方法进行内存对齐或快速解码。然后，相应的计算内核需要将这种特定布局解包到硬件支持的数据类型进行执行。

而 T-MAC 通过从比特的视角观察低比特矩阵乘计算，只需为单独的一个比特设计最优的数据结构，然后通过堆叠的方式扩展到更高的 2/3/4 比特。同时，对于不同精度的激活向量（float16/float32/int8），仅有构建表的过程需要发生变化，在查表的时候不再需要考虑不同的数据结构。

图 4 以比特为核心的查表计算混合精度 GEMV

同时，传统基于反量化的方法，从 4-比特降低到 3/2/1-比特时，尽管内存占用更少，但是计算量并未减小，而且由于反量化的开销不减反增，性能反而可能会更差。但 T-MAC 的计算量随着比特数降低能够线性减少，从而在更低比特带来更好加速，为最新的工作 BitNet, EfficientQAT 等发布的 1-比特/ 2-比特模型提供了高效率的部署方案。

图 5 GEMV 使用不同端侧设备 CPU 的单核，T-MAC 在 4 到 1 比特的混合精度 GEMV 算子相较 llama.cpp 加速 3 - 11 倍。T-MAC 的 GEMM 耗时能随着比特数减少线性减少，而基于反量化的 llama.cpp 无法做到（1 比特 llama.cpp 的算子性能由其 2 比特实现推算得到）。

高度优化的算子实现

基于比特为核心的计算具有许多优势，但将其实现在 CPU 上仍具有不小的挑战：(i)与激活和权重的连续数据访问相比，表的访问是随机的。表在快速片上内存中的驻留对于最终的推理性能尤为重要，(ii) 然而，片上内存是有限的，查找表（LUT）方法相比传统的 mpGEMV 增大了片上内存的使用。这是因为查找表需要保存激活向量与所有可能的位模式相乘的结果。这比激活本身要多得多。