自2022年ChatGPT发布以来，以大模型为依托的AIGC相关的应用产品，比如ChatGPT、Midjourney、Stable Diffusion等，在社交网站的讨论热度持续攀升，引发了较大范围的好奇与关注。
目前，国内外各个科技大厂在大模型的端侧部署领域均开始布局，比如在2023年8月14日的雷军年度演讲中，雷军宣布小米已经在手机端跑通13亿参数的大模型，部分场景效果媲美云端。
什么是大模型
2017年，Google 发表一篇划时代的论文《Attention is all you need》，这是一个标志性的事件。
基于 Transformer， 2018年OpenAI推出1.1亿参数的GPT，此后谷歌、微软、Facebook等前后相继推出自己的预训练模型。
特别是2020年OpenAI推出了1750亿参数的GPT-3，轰动全球，引发了各大顶尖科研机构在大模型研究的竞赛，大模型的参数规模逐渐增加。
LLM 的基础是 Transformer 块，Transformer是一种基于自注意力机制（self-attention）的神经网络结构，被广泛应用于自然语言处理任务中，它包括编码器和解码器两个主要结构。
目前，绝大多数的大语言模型均基于这种结构搭建而成，按照结构划分可以分为仅编码器模型、仅解码器模型和编码器解码器模型。
- 仅编码器模型（Encoder-only models）: 常见于需要理解输入的任务，如句子分类和命名实体识别。
- 仅解码器模型（Decoder-only models）: 常见于生成任务，如文本生成。
- 编码器解码器模型（Encoder-decoder models）: 常见于根据输入进行生成的任务，如翻译或摘要。
近一两年，微软、谷歌、Meta、百度、阿里、腾讯等国内外研究机构就大模型领域不断进行着技术创新和新型商业模式的竞争，大量的模型持续被设计、生产并发布。
其中基于Transformer的模型显示为非灰色颜色：蓝色分支表示仅解码器模型，粉色分支表示仅编码器模型，绿色分支表示编码器解码器模型。
可以发现大模型逐步向编码器解码器和仅解码器架构发展，模型的参数尺寸持续增加，训练数据持续增加，使得模型能力大幅提高的同时也使得模型对于算力的需求呈指数级增长。
目前业界大模型的研究主要有两个方向：
- 一是起步较早的自主研发闭源的商用模型，典型代表是OpenAI的GPT系列，Google的Bard、PaLM2等。
- 另外一个就是开源界热火朝天的景象，其中10B以下的模型，经过量化压缩及优化之后基本上都能在端侧设备上部署运行。
大模型技术的基础
模型部署是帮助训练好的模型从"工厂"走入实际应用的关键步骤，部署大模型和普通模型的关键区别主要在于计算能力、存储空间、能耗等方面，由于模型本身的尺寸大、推理时需要的内存大、对算力的需求大。
因此对相关的硬件选择、模型压缩技术、算法优化技术和 SDK 开发都有着更高的要求，需要根据具体的应用场景和需求进行选择和优化。
LLM 参数量巨大，一般都在10亿（1B）以上，按照浮点数权重来计算的话，模型文件大小在 4GB以上，光是加载到内存就要占用 4GB 以上的空间，如果是在32位操作系统（严格来讲是地址位宽为32），系统的寻址空间就只有 4GB，整个内存空间全用上都装不下！
幸好现在已经是64位机的时代，大家手上用的智能手机不出意外的话基本上都是64位操作系统，理论上内存空间可以大到 64GB 任何大模型都可以装下，当然受限于硬件成本及硬盘容量的限制，64位寻址能够支持的最大内存只有几百TB。
目前主流智能手机的内存大小一般是 6GB ~ 12GB 左右，Windows系统的设备有 128GB、2TB、6TB 内存的机器，也就是说目前在我们最常用的手机和个人电脑（PC）上，已经具备加载和运行大模型的硬件条件。
对于移动端部署，硬件的选择需要考虑计算能力、功耗、存储空间、可靠性、兼容性、成本价格等多方面的因素。
模型部署区别于其他端上模型的最大之处在于大模型极高的参数量和随之而来的对计算、访存、存储的高需求。不同于训练阶段，推理时的内存占用通常由模型的权重 、kv缓存和一些其他中间结果共同构成，其中中间结果用完会尽快释放掉，占用的显存很小，可以忽略。
在大模型部署场景中，访存带宽通常为计算速度的主要限制，访存耗时甚至高达计算耗时的四百多倍。在端上运行时，batchsize通常为1，此时可以压缩模型参数存储精度的字节数，进而压缩访存时间。
模型量化技术是一种通过减少神经网络中参数的位数，从而减小模型的存储空间和计算量，提高模型的运行效率的技术，在移动端和嵌入式设备上的应用非常广泛。
常见的模型精度有FP32、FP16、INT8和INT4等，随着模型存储空间和计算量的减少，模型的精度也在下降。
Float32 (FP32) 是标准的 IEEE 32 位浮点表示。使用该数据类型，可以表示大范围的浮点数。在 FP32 中，为指数保留了 8 位，为尾数保留了 23 位，为符号保留了 1 位。
而在 Float16 (FP16) 数据类型中，指数保留 5 位，尾数保留 10 位。这使得 FP16 数字的数值范围远低于 FP32。在推理时，半精度权重通常能提供与 FP32 相似的精度，此时只需要一半的内存就能获得近似的推理结果。
同理，如果进行INT8量化，则模型大小会再次减半，如果进行INT4量化，则模型大小可以在理论上降至1/8。
在端上运行大语言模型通常采用Groupwise的INT4量化策略，Groupwise指的是将需要量化的数据分成n组，为每一组建立量化参数，当n越大，精度越高。
由于大模型运行的主要限制在访存上，反量化所额外需要的计算并不会超过访存的开销，因此整体而言此举可以大幅降低耗时。
相关进展
在终端设备上部署大模型，比如常见的Android、iOS手机、嵌入式设备、个人电脑等，我们需要解决两方面的问题：内存占用和计算速度。
内存占用决定了该设备是否能装载下模型，计算速度决定了用户体验。此外针对推理引擎的图优化、计算调度优化、资源管理优化等关键技术从多角度优化模型执行过程的计算速度。
在让大模型变小这条路上，人们做了很多尝试，先是 Meta 开源了 LLaMA，让学界和小公司可以训练自己的模型。
随后，斯坦福研究者启动了 Lamini，为每个开发者提供了从 GPT-3 到 ChatGPT 的快速调优方案。而 MLC LLM 的项目可谓一步登天，因为它能让你「在任何设备上编译运行大语言模型。
MLC LLM 为我们在各类硬件上原生部署任意大型语言模型提供了解决方案，可将大模型应用于移动端（例如 iPhone）、消费级电脑端（例如 Mac）和 Web 浏览器。
23年第二季度，陈天奇团队发布Web Stable Diffusion和WebLLM，只需一个浏览器，就能跑通大模型了。不过需要下载Chrome Canary，也就是谷歌浏览器的金丝雀版本，才可以正常运行。
- Web LLM体验地址：mlc.ai/web-llm/
- Web Stable Diffusion体验地址：mlc.ai/web-stable-...
启动浏览器之后，便打开官网的demo试玩处开始体验了，不过在第一次展开对话的时候，系统还会出现一个初始化的过程。
根据团队介绍，其核心关键技术是机器学习编译（Machine Learning Compilation，MLC）。整体方案是站在开源生态系统这个"巨人肩膀"上完成的，包括Hugging Face、来自LLaMA和Vicuna的模型变体，以及wasm和WebGPU等，并且主要流程是建立在Apache TVM Unity之上。
团队首先在TVM中bake了一个语言模型的IRModule，以此来减少了计算量和内存使用。TVM的IRModule中的每个函数都可以被进一步转换并生成可运行的代码，这些代码可以被普遍部署在任何最小TVM运行时支持的环境中（JavaScript就是其中之一）。
其次，TensorIR是生成优化程序的关键技术，通过结合专家知识和自动调度程序快速转换TensorIR程序，来提供高效的解决方案。
除此之外，团队还用到了如下一些技术：
- 启发式算法：用于优化轻量级运算符以减轻工程压力。
- int4量化技术：用来来压缩模型权重。
- 构建静态内存规划优化：来跨多层重用内存。
- 使用Emscripten和TypeScript ：构建一个在TVM web运行时可以部署生成的模块。
但Web LLM团队也表示，这个项目还有一定的优化空间，例如AI框架如何摆脱对优化计算库的依赖，以及如何规划内存使用并更好地压缩权重等。
Web LLM背后的团队是MLC.AI社区，它成立于 2022 年 6 月，并由 Apache TVM 主要发明者、机器学习领域著名的青年学者陈天奇，带领团队上线了 MLC 线上课程，系统介绍了机器学习编译的关键元素以及核心概念。
总结
综合来看，目前端上进行大模型推理的基本技术已经具备，但内存需求普遍不小于4GB，仍对设备的性能和优化能力有着较高的要求，内存容量、访存速度和计算能力共同制约了大模型在端上的整体表现。
通过对现有技术的分析和实践，我们能够直观地感受到当前端上大模型的技术壁垒和现实进展，针对这些制约因素，我们正在不断探索和优化技术方案，以提高设备的性能和优化能力，进一步减小模型尺寸，降低内存容量和访存速度的要求。
端上大模型的可行性和前景已经得到了业内的普遍认可，目前大量工程已在PC端、手机端实现大模型的离线部署，更有部分App登陆应用商店，只需下载即可畅通无阻地对话。
我们相信，在不久的将来，端上大模型推理将会成为智能应用的重要组成部分，为用户带来更加便捷、智能的体验。