小米小爱同学：资源受限下，实现端侧大模型的高性能推理

采访嘉宾｜杨永杰，小米小爱同学端侧 AI 负责人

编辑｜罗燕珊

随着大模型能力持续提升，如何将其有效部署到端侧设备，成为产业界面临的重要工程挑战。手机、车载、IoT 等设备对模型体积、推理时延、功耗和更新机制都提出了极高要求，也让端侧推理成为融合系统优化、模型压缩和软硬件协同的复杂问题。

近日，InfoQ 对话小米 /小爱同学端侧 AI 负责人杨永杰，带你深入了解其团队如何从架构、系统和算法三层着手，推进大模型在端侧的工程化落地。他们通过自研推理框架实现了 180 tokens/s 的实时推理性能，借助 LoRA 插件化 + 共享基座模型 支持多业务复用，并在推理性能和资源占用上实现了极致优化。

面向未来，杨永杰认为，端侧大模型的突破将依赖两方面：一是面向大模型优化的硬件能力提升，二是模型架构的演进，比如 Linear Attention 架构。

6 月 27～28 日，在即将于北京举办的 AICon 全球人工智能开发与应用大会上，杨永杰将发表演讲《小爱同学在高性能端侧大模型推理的实践》，分享其团队自研的大模型推理框架在实际业务中的落地实践。围绕架构设计、量化策略、并行解码、跨芯片兼容、热更新策划等方面展开，结合真实的系统优化痛点，解析端侧大模型商业化的关键路径。

敬请期待：

https://aicon.infoq.cn/2025/beijing/presentation/6444

InfoQ：端侧大模型已成为当前 AI 部署的重点方向，尤其在隐私、安全和离线能力方面具备显著优势。但从您的视角看，真正实现商业化部署仍面临哪些核心技术门槛？

杨永杰： 确实现在大模型很火，端侧也被很多人看作是未来的重要方向，但在商业化落地这方面推进得还是比较慢的，这主要是受到一些客观因素的影响。

第一个方面，是端侧设备本身的资源限制。无论是算力还是带宽，相比云端来说都是比较有限的。如果要把一个大模型部署到端上，就必须对模型进行较低比特数的量化，才有可能在这些设备上运行。

但即使做了低比特量化，手机等端侧设备上可商业化部署的模型可能也难以超过 4B 参数量，且低比特量化会导致模型效果损失。在这个量化精度下，大模型的整体效果相比云端仍有较大差距。毕竟云端的资源没有这些限制，能够支持更大、更强的模型。

第二个方面是，大模型本身的发展还处于快速变化的阶段。现在模型的迭代节奏很快，几乎每隔一段时间就有新的进展。在云端，这种变化可以很快跟上，比如公司可以快速更新模型版本。

但端侧的设备毕竟在用户手上，模型更新相对滞后，往往会慢一拍。而且更新机制也受限，比如要看用户是否主动下载更新，或者依赖厂商推送更新包，整体更新策略没有云端灵活，云端完全可以由公司自主控制。

所以，从目前来看，大模型的发展还没有到一个“相对稳定”的阶段。不像传统模型发展成熟之后，各家公司会因为成本或场景要求，逐步考虑往端侧迁移。现在的端侧大模型更像是在做技术积累，是面向未来的准备。

如果将来端侧的计算能力进一步提升，或者云端模型逐渐稳定下来，那时可能就会从“探索”阶段走向“部署”阶段。尤其当部署成本成为关键因素时，端侧就会成为更有吸引力的选项。而我们现在做的更多是提前技术布局，为之后的落地做好准备。

InfoQ：您所在团队自研了大模型推理框架，并实现了超过 180 tokens/s 的端侧推理速度，在端侧这一资源受限环境下达到该指标，能否分享一下背后的系统级与模型级优化策略？

杨永杰： 是的，我们团队自研了一个用于大模型推理的框架。之所以选择自研，主要是因为目前针对端侧的大模型推理框架非常少，开源的方案更是寥寥无几，即使有，往往也是针对端侧 CPU 或 GPU 的。至于 NPU，由于各大芯片厂商通常不会开放接口，导致 NPU 上的推理框架往往只能由芯片厂商自己开发和维护。

但仅靠芯片厂商的解决方案，很多优化手段往往无法做到云端那种深度。相比之下，云端框架（如 vLLM、SGLang 等）大多是开源的，有广泛的社区贡献，优化手段也非常丰富。而端侧不仅缺少统一的框架，而且设备差异性大，各个厂商的解决方案分散、实用性强，但往往缺乏系统性打磨与性能极致优化。

我们做了从框架层全栈自研的工作，每一个模块的性能都进行了细致的优化。此外，我们也借鉴了很多来自云端的成熟优化手段，并针对端侧进行了适配和改进。

举几个例子：

• 动态输入与动态 context 支持：云端推理天然支持动态输入，而端侧的 NPU 通常只能使用静态图，输入尺寸固定。传统做法是将输入 padding 到固定长度，比如用 128 token 固定输入长度，即使真实输入只有 100 也要补足，这样会浪费大量计算资源。我们通过框架级的能力，让模型在保持静态图性能的前提下支持动态输入，自动切分输入尺寸，从而大幅提升了资源利用率和吞吐率。

• 投机推理（Speculative Decoding）优化：在云端，像 Medusa 或 Eagle 等方案通常能做到 2～3 倍的加速。而我们通过自研策略，在端侧实现了高达 7～10 倍的 decoding 加速，大幅缓解了端侧推理慢的问题。举例来说，原本在资源受限的设备上，推理速度可能只有二十几 tokens/s，通过投机推理可以提升到 200 tokens/s，这一速度已经可以媲美部分云端场景。

• 量化与指令级优化：大部分 CPU 操作通过 Neon 指令集实现加速，比如量化与反量化、sampling 采样等。

目前，我们的框架已在车载等端侧场景中实现了落地，支持包括文本和多模态在内的多个大模型能力。细节部分后续可以在大会分享时进一步展开。

InfoQ：小爱同学作为一个语音助手，承载了语音控制、多轮对话、智能家居等多种任务。端侧大模型在这些不同场景下对响应时延、并发能力有何特殊要求？这些业务需求对推理架构设计起到了怎样的约束作用？

杨永杰： 对于小爱来说，目前我们还没有非常强的并发需求，但这个在未来可能会出现。就现有业务来看，小爱一个完整的请求链路可以分为三个阶段：感知、理解和满足。也就是说，设备需要先感知到用户的输入，然后再进行语义理解，最后给出响应来满足用户需求。这个流程本身是串行执行的，所以在同一条链路上，并发的需求并不强。

当然，也不是说完全没有并发，比如有些任务可能会涉及并发执行，但这种情况目前还不多。另一方面，我们的模型能力也不仅服务于小爱本身，还会被其他业务共用，在不同业务之间就可能出现并发冲突。

为了应对这种情况，我们在架构上做了并发管理。但目前端侧设备的 NPU 本身不支持并发推理，它的硬件设计就是以串行执行为主，不像云端那样可以天然支持多个请求同时并发处理。

虽然理论上可以尝试使用 multi-batch 的方式提升并发处理效率，但在端侧这种算力受限的环境下，multi-batch 实际上的收益非常有限。我们也做过实验，因为端侧单条请求已经接近设备算力的上限，增加 batch 数反而会带来额外负担。例如，在预填阶段（prefill）已经接近满负载，再加一条并不会带来实质提升，几乎和一条条串行处理没区别。

所以相较于云端，端侧的并发能力天然就弱很多。但在实际业务调用中，我们还是会通过调度和切换机制，尽量保障各条业务链路在预期时间内完成推理，避免某条请求因为资源冲突而变得特别慢。

InfoQ：面对多任务、多业务的实际场景，您团队采用了“共享基座架构”的方案。能否大概介绍一下，该架构方案是如何支持多个业务并发推理的，同时又不牺牲系统性能？

杨永杰： 我们之所以要做共享基座架构，主要是因为端侧的资源确实有限，不仅是算力有限，存储空间和内存也很受限制。

比如一台 12GB 内存的手机，部署一个 4B 的大模型可能就需要接近 3GB 的内存。表面上看可以放两个模型，但实际上手机或车载设备上还有很多其他业务，它们也要占用内存资源。真正能留给大模型使用的空间可能连 3GB 都不到。

在这样的限制下，我们就无法为每个业务分别部署一个独立模型。所以我们采用了“共享基座模型 + 插件化能力”的思路，让多个业务共用同一个基础模型。

具体做法是，我们为所有业务统一选择一个基础的大模型，然后针对不同业务单独训练对应的 LoRA 模块。例如：

• A 业务针对这个基础模型训练一个专属的 LoRA；

• B 业务则训练另一个 LoRA。

运行时，如果是 A 业务的请求到来，我们就加载基础模型 + A 的 LoRA 进行推理；当 B 业务请求到来时，我们就卸载 A 的 LoRA，换上 B 的 LoRA。这样，在只保留一个基础模型的前提下，我们可以动态切换不同的业务能力，从而支持多个任务的并发调用。

这套方案的核心就是借助 LoRA 插件化、轻量化的特性，实现“参数共享 + 差异定制”，从而在资源有限的设备上支持多个业务。这种共享基座架构在内存利用率和扩展能力上都比较有优势。

当然，里面还有不少实现上的细节和挑战，实际落地过程并不像听起来那么简单。

InfoQ：端侧设备硬件异构严重，适配难度大。你们的推理框架在跨芯片平台部署上做了哪些模块化、通用化的设计，以确保兼容性与性能的平衡？

杨永杰： 在这方面其实我们并没有采用特别的方案。因为从整体设计思路上看，这跟传统模型框架处理多后端的问题是类似的。

到了大模型阶段，虽然模型规模变大了，但它在框架设计层面上，其实并没有本质性的变化。相反，很多大模型的优化技术，更多是针对模型本身的结构特性，或者是在框架层面做的，而与具体底层硬件绑定的程度反而没有那么深。

这也意味着，框架层可以更容易抽象出一些通用的接口，使模型能够在不同的硬件平台、不同后端之间迁移。相比传统模型框架，反而会更容易实现一定程度上的通用性和跨平台部署能力。

所以我们的策略也是在此基础上，进行模块化、后端解耦的设计，来适应多种端侧芯片平台的部署需求。

InfoQ：在性能优化方面，你们使用了如低比特量化、并行解码、带宽控制等技术。实际工程中，这些优化组合的优先级是如何确定的？是否有一些踩过的坑可以分享？

杨永杰： 我们现在在做优化时，基本上不同的技术是可以同时作用的，不会出现只能用 A 而不能用 B 的情况。比如你提到的低比特量化、并行解码、带宽控制，这些技术我们都是尽可能组合使用的。

以并行解码为例，我们内部可能有多种策略，比如策略 A 和策略 B，我们不仅能分别使用，也可以将它们融合在一起。我们会优先实现那些技术价值较大、适用面更广、和其他手段之间没有冲突的优化方式。

这背后的一个判断标准是——这个优化能不能在多个业务场景中复用，以及它是否容易与其他优化组合应用。如果能覆盖更多业务，或者实现起来不增加系统复杂度，我们就会优先采用。

当然，未来也可能出现某些技术只适用于特定业务的情况，比如某项优化只对 A 业务有效，对 B 业务没有意义。遇到这种情况，我们会把该能力封装成业务可选的配置项。部署时会提示这个业务适合用什么技术，但我们也会尽量避免让这种“特定绑定”的优化太多，否则会让框架变复杂，降低整体的可维护性和易用性。

因此在框架设计上，我们做了模块化、分层解耦的处理。比如你在上层调用一个能力时，底层的适配逻辑已经统一封装好了，不需要上层关心用的是哪套后端逻辑，开发时也不需要为每种技术写一套逻辑。

举一个更具体的例子：我们也实现了 prompt cache。它能缓存用户输入的 prompt 前缀，减少重复计算。但不是所有业务都需要用。比如有些业务 prompt 很短，不缓存也无所谓；有些业务每次都要带一大段前缀，那我们就建议他开启 cache。

这项功能的配置也非常简单，就是在部署配置文件里启用相关参数，工程人员不需要额外操作。你只需要告诉系统缓存哪个 prompt、存在哪个地址即可，整个流程对使用方是透明的。

当然，效果上也会因业务而异。有的业务用 cache 后能省几十个 token 的计算；有的长 prompt 场景则能节省上百 token，推理延迟可能能减少上百毫秒甚至几百毫秒。我们一般会根据对业务的了解，给出推荐的优化策略。

InfoQ：结合当前产业需求与技术路径，未来您认为端侧大模型最具突破性的方向或潜力业务场景会在哪里？下一阶段技术突破的核心目标可能集中在什么方向？

杨永杰： 前面提到的挑战有相当一部分其实都来自于端侧硬件算力不足。这也直接导致我们在部署时要做很多取舍，比如低比特量化、严格的资源控制等，都是为了适配端侧有限的计算能力。

但这些优化都有上限。举例来说，现在即便我们可以在一些设备上跑起 7B 的大模型，但无法真正落地，因为它运行时会占用太多资源，比如功耗高，或挤占了其他业务的资源，导致系统卡顿。这些问题在端侧是很现实的。

所以我认为未来一个关键的突破方向，其实在于硬件本身的进步。这也是很多芯片厂商已经在做的事情——类似于当年传统模型兴起时，芯片厂商纷纷推出支持的 NPU。现在大模型热度已持续两年多，新一代面向大模型的端侧芯片很可能即将出现。

一旦这类硬件可用，端侧模型的能力会大幅增强，更多业务也就有机会真正落地。

另一个值得关注的方向，是模型架构本身的变化。当前主流大模型基本都基于 Transformer 架构，它是自回归式的，这带来了一个问题：当 context 变长时，资源占用会随之显著增加，特别是要保存 KV cache 时，内存和算力压力都会不断上升。

现在业界在探索的一类新方向是 Linear Attention，代表性架构如 Mamba、RWKV，它们尝试在保持模型能力的同时，减少对内存的增长需求。

这类架构的一个优势是：内存使用与输入长度无关，可以更好地支持长文本推理，特别适合资源敏感的端侧场景。虽然目前这类架构的效果整体还不如 Transformer，但由于研究热度高、论文持续涌现，我个人也很期待未来会有实用级别的突破。

尤其在端侧业务中，比如小爱目前的交互长度普遍不长，主要是一问一答形式，但我们也看到一些新趋势，像多模态任务的输入长度会变得很长。

通过自研推理框架实现了 180 tokens/s 的实时推理性能，借助 LoRA 插件化 + 共享基座模型 支持多业务复用，并在推理性能和资源占用上实现了极致优化。

例如：一张图片转成 token 可能就有 64 个；视频场景中，多个帧一起输入时，输入长度会成倍增长，context 就会迅速拉长。这种情况下，传统 Transformer 对资源的需求就成了瓶颈，而 Linear Attention 的方向可能会是一个很好的解法。

所以总结来看，一个是硬件层面的能力突破，一个是模型架构的算法演进，这两个方向我都认为非常关键，也都很值得期待。