让大模型“跑”在手机里：vivo蓝心端侧部署创新揭秘，性能功耗双优！

近年来，行业内不断涌现各种十亿，百亿，千亿级别的大模型，在各个领域均展现了强大的能力。而智能手机作为拥有最大用户数量的终端设备，正成为大模型实现个性化场景与服务的核心载体。然而想在移动端有限的硬件资源上部署参数量庞大的大模型，其性能，内存，功耗均面临着严峻的挑战。

我是来自 vivo AI 研究院的章苏迟，当前在 vivo AI 研究院负责大模型的在端侧的部署与业务落地。今天非常荣幸能在这里同大家分享我们 vivo 在端侧大模型端侧化过程中的解决方案与思考。

大家这几年买手机的时候，经常会听到一个概念叫做 AI 手机，相信大家对 AI 手机这个词已经不陌生了。

传统上，虽然智能手机有形形色色的 AI 功能，但实际上很多人在用的时候都会感到一些困惑，就是这些所谓的 AI 功能都是单点的，它并没有与系统有很好的结合，而且所谓的智能化 AI 体验，听起来好像也没法理解用户的意图。

所以 AI 手机实际用起来，大家最后的感受就是并没有那么智能，这也是以往 AI 手机的痛点。

随着大模型技术的发展，尤其是这几年多模态大模型不断涌现，它在各个专业领域都展现出了惊人的能力。行业正从传统的 AI 时代全面迈向大模型 AI 时代。

面对这种行业变革，我们也产生了一个想法就是，如果我们能把大模型技术与手机结合，那么势必能给用户带来更加智能、个性化的服务，全面重塑手机体验。

在手机上应用大模型云端大模型和端侧大模型这两种方案。云端大模型不会受到手机有限计算资源的影响，它的能力非常强，发挥的空间也非常大，具备相当多的优势。

但手机上还有非常多的与隐私相关的场景，比如说我们不能把一些用户的隐私数据上传到云端，此时我们就只能选择端侧化的方案。但如果选用了端侧化方案，就意味着我们要把端侧大模型塞到手机里，这听起来就有点不可思议，这真的能实现吗？

我们回溯一下这几年大模型算法的发展趋势，可以发现大模型的知识密度是在持续增强的。对于同等能力的模型，它的参数量随时间推移是呈快速下降的趋势。

比如说我们现在自研的 vivo 蓝心大模型，3B 大模型在算法能力上已经能够比肩以往的 10B 甚至几十 B 的模型，所以大模型的小型化已经成为了一种趋势，与我们将大模型落地到端侧这个诉求是正好匹配的。

我们 vivo 当前已经将大模型落地到端侧，为用户带来了更加智能和安全的体验。这里的安全指的是我们对用户隐私数据的保护。

端侧大模型在推理的过程中，它整个链路所有的数据都是纯端处理的，所以用户的任何隐私信息都不会上云，很好地保证了我们用户的隐私保护需求。

至于个人智能化的体验，我们就来看看 vivo 把端侧大模型运用在了哪些场景。当前我们把蓝心大模型运用在了很多系统应用中。

第一个就是 vivo 输入法，这是小 V 写作的功能，它主要用到了大模型的文案生成与润色能力，比如说大家在写购物评价，又或者同朋友聊天，它能帮你一键生成指定的文案和一些高情商的回复。

第二个是我们电话助手的通话摘要功能，它主要用到了蓝心大模型的总结摘要能力，它可以帮用户生成通话内容，比如说你同你的老板打了工作电话，它可以帮你总结整通电话，生成待办事项。

第三个是我们蓝心小 V 里的文本总结功能，它可以帮助你自动总结文档的主题摘要。你不需要看整篇文档，它可以帮你快速生成几百字的摘要，帮助用户快速了解文章要领。

最后一个功能就是我们录音机里的智能命名功能，它可以帮助用户自动识别录音文件内容，自动生成对应的文件名，这样可以避免用户为了找录音文件而反复听，可以省很多时间。

以上所有场景都是通过 vivo 端侧大模型实现的。

大家都说大模型落地到端侧非常难，首先我们要明白它到底难在哪里，最关键在于模型的参数量与性能指标之间的平衡。手机端的硬件资源是非常有限的，芯片算力有限，内存大小也有限，手机的功耗也是非常重要的指标。模型参数量越大，就意味着它消耗的计算量越大，它对带宽的需求也越高，功耗也就越高。

所以如何平衡模型效果与手机上的这些体验指标，是非常大的问题。如果我们把模型参数量选的非常大，那么它计算量就很高，它直接带来的问题就是速度非常慢，用户体验的延迟就会非常久。

另外也带来一个问题，就是内存占用会非常大，进而导致系统的流畅性会受到一些影响，功耗随之升高，导致我们手机掉电非常快，发热也非常严重，这些都是我们端侧化非常棘手的问题。

在识别到我们端侧的瓶颈之后，就要用技术指标量化它。这里的运行内存就是大模型在运行过程中对内存的占用，功耗是运行过程中的电流或耗电量，但大模型的性能指标我们又怎样衡量？

为了拆解清楚这个问题，我们先来简单回顾一下大模型的推理过程。

我们给大模型输入 prompt，然后它就预测出一段简单的话。这个简单的过程主要拆分为三个阶段，首先是大模型的初始化加载阶段，在这个阶段模型就要从 flash 存储读取到我们 DRAM 中。

后面的推理又拆分为两个阶段，首先是 prompt 输入大模型，然后大模型预测出第一个词，这个过程我们称为 prefill，也就是首词。在输出第一个 token 后，我们还要把 token 送回大模型，然后让大模型不断预测下一个词，这个过程是连续出词的过程，我们把它称为 decode。

所以大模型的推理性能指标主要有两个，也就是 prefill 性能和 decode 性能，我们在后续的测试以及优化过程中，需要同时关注这两个指标才行。

我们明白了用什么技术指标来量化大模型性能后，很快就对大模型进行了一次端测性能摸底，来看一下它在手机端的表现是怎样的。

这里选取的是我们蓝心的 7B 模型，在天机 9300CPU 上运行。我们开了 6 个线程，来看一下我们后面的性能指标。首先是 prefill 性能和 decode 性能都是 10 多个每秒多一点。

这里要说明一下 prefill 性能和 decode 的性能是怎样计算的。prefill 性能代表的是大模型处理输入 token 的能力，计算方式就是把输入的 prompt 数除以 prefill 过程的总耗时，比如说 19.7 token 每秒，就意味着它每秒能处理 19.7 个输入 token。输出 token 的计算方式就是把输出的 token 数除以它 decode 流程的总耗时，这里的 10.9 token 每秒就意味着它每秒能出 10.9 个 token。

再来看一下这组数据，首先是出词性能 10.9 token 每秒，换算成中文汉字大概是 14~16 字每秒，这个性能还是能满足人眼阅读的基础体验的，没有问题。但这个 prefill 性能在优化之前，我们发现它只有 19.7 token 每秒，这里的问题就非常大了。

设想一个文档总结的功能场景，我的文章假设输入有 1000 个 token，并不长，可能也就是 1400~1600 个汉字左右，可能有些文档比这个还长。如果是这样一篇文档输入到大模型，它的 prefill 耗时要多久？要 50 多秒，意味着用户总结这个文档时，需要等待 50 多秒才能出第一个词，这是绝对无法满足体验的，所以这块是我们亟需优化的指标。

功耗我们这里测出来是两点几安，而重载游戏的功耗峰值也就在一安左右，所以说功耗是非常可怕的，这对我们手机的续航和发热都有着严重的影响。最后便是内存了，实测下来 7B 模型的内存占用在 3.6GB 左右，大家知道现在主流手机的内存大概在 12GB 或 16GB 这样的规格，所以我们在端测如何选择模型的参数量，也是亟需解决的问题。

经过一次初步摸底后，我们就知道了大模型在手机端的性能指标是怎样了，接下来我们就从性能、功耗以及体积和内存来全面讲解一下，我们端侧大模型是怎样去做的。

首先是体积和内存的优化。在做优化之前，我们要确定端测到底适合用多大的模型，到底用什么指标，什么标准去选择？我们认为核心决定因素是我们机型的剩余内存和性能。前面说过我们 7B 的性能能达到 10 token 每秒左右，性能已经能够满足一些阅读场景的基础体验了。

所以在手机端上选择模型时，可以认为小于等于 7B 是比较合理的区间。再结合我们手机的剩余内存，我们现在主流旗舰机型的剩余内存在 12GB 左右，从这个标准再结合大模型的内存开销来画一条线。

我们认为 12GB 机型的综合最佳选择是 3B 模型，3B 是我们端侧化比较合理的尺寸。在选定模型尺寸后，我们基于模型进行了一些轻量化处理，这里主要从权重量化以及 attention 优化两个方面展开。

首先是 attention 结构，我们最原始的蓝心 3B 模型采用 MHA 结构，也就是说它每个 query 的头对应的 key 和 value 矩阵都是不共享的。在这种情况下 key 和 value 矩阵的参数量就会非常庞大，这里就有一点问题。

我们全面测试过它的性能与效果后，采用了 GQA 这种结构，将 query 分成多组，每组共享同一个 key 和 value 矩阵。

之后就是权重量化对比浮点推理，我们采用更低比特的 4bit 的权重量化，搭配 int16 的 activation，这样对比原始的 FP16 的权重，模型体积就能降为原来的 1/4。另外我们针对 kv cache 也采用了 int8 量化，这样 kv cache 的内存占用也能进一步压缩。

经过这两种方式的轻量化后，首先模型权重的体积从 5.7GB 下降到了 1.27GB，有非常大的优化。另外值得注意的就是 kv cahce 的内存占用从每 1k 160M 降低到了 32M，也是有意义的。

这就意味着我们在端侧采用更长长度的 kv cahce，它的内存增量就不会那么大了。所以我们在端侧采用比如说 2k 或 4k 这种长度的上下文，它的内存影响就相对小很多。以上就是我们内存和体积的优化方案。

性能和功耗优化是我们整个端侧化过程中的重中之重。做过手机端 AI 推理优化的同行应该知晓，手机 SOC 针对 AI 场景专门搭载了用于神经网络加速的 NPU 芯片，对比传统的 CPU 和 GPU，NPU 有着更高的算力和更好的能效，在推理方面有着非常大的优势。

因此我们很多从业者在做端侧化优化的过程中，遇到这种要优化性能和功耗的问题，他就会脱口而出，不要用 CPU 和 GPU 了，我们去 NPU 算一下，这句话在大部分的场景都是正确的。但我们仍然要拆解清楚，针对具体的计算任务，NPU 到底是怎样发挥优势的？是不是针对任何任务，NPU 都有全方位的优势呢？

为了分析这个问题，我们先对大模型的计算任务进行了分析和拆解。由于我们 prefill 的输入是完整的 prompt，它经过 embedding 的算子后变成了多维矩阵，这个多维矩阵在后面会同 QKV 以及 MLP 里的这些矩阵参数进行运算，因此整个 prefill 过程的计算任务本质是矩阵乘法。

而 decode 的过程则不一样，decode 过程输入的是 token，token 经过 embedding 的算子处理后变成了一维向量，一维向量和后续的 QKV 以及 MLP 的 FC 进行计算后，实际上它的计算任务是矩阵向量乘法。所以 decode 过程和 prefill 过程的计算任务是有本质区别的。

接下来我们就根据这两种计算任务来实际看一下 NPU 在这两种任务上的表现究竟是怎样的。矩阵乘法是典型的计算密集型任务，它的性能同器件的算力是直接相关的。

我们简单回顾一下矩阵乘法的计算过程，比如说简单的 A 矩阵乘 B 矩阵得到 C 矩阵，如图所示 A 矩阵的 A0 到 A3 这一行，乘上 B 矩阵的 B0~B3 这一列，它得到的是 c0 这一个数。同理 c1、c2、c3 就是 a0 到 a3 乘上 B 矩阵的后面几列。

如果我们不做任何优化，推导一下这个过程不难发现， A 矩阵和 B 矩阵里面有大量数据是重复访问的。这时候就会引出问题，就是整个矩阵运算过程中的访存效率非常低下，无论是 A 矩阵还是 B 矩阵都有非常大量的重复数据访问。

那么怎样去做矩阵乘法优化，最通用的策略就是对 A 矩阵和 B 矩阵进行分 tile 了，比如说我们在 CPU 上做矩阵，以 ARM 架构为例，我们通常会把这个矩阵分成 4×4 的 tile，然后把这些 tile 的数据依次落到 ARM 计算器中。

这时以我们 4×4 的 tile 去划分的话，最终我们会发现 A 矩阵和 B 矩阵的访存次数都会变为原来的 1/4。用技术指标去衡量的话，就是 A 矩阵的复用系数变为 4，B 矩阵的复用系数也是 4，这是分 tile 带来的优化。

经过这种方式优化，矩阵乘计算过程中 A 矩阵和 B 矩阵的访存量大幅度下降，整个矩阵计算的耗时会大幅度缩短。

这时候大家就想到一个问题，既然复用系数变为 4，性能有那么大的优化，我们能不能让复用系数更高一些，比如说 8 或者 16 甚至 32，这样性能不是会更快吗？但对不起，CPU 做不到这一点。我们就以 ARM64 架构的 CPU 为例，它的标准向量寄存器只有 32 个，而且每一个寄存器只有 128bit 的位宽，所以在计算矩阵生成的过程中，把复用系数提升到 4 时，你就会发现它的计算器差不多就要用完了。

你想再把复用系数往上提，会出现寄存器不够用的问题。这也是为什么 CPU 在算矩阵乘时，对比 GPU，NPU 这种专门处理矩阵乘法的硬件没有优势的原因。

那么 NPU 又是如何呢？NPU 内部的整个 MAC 阵列是非常庞大的，有 2D 甚至是 3D 的，它的高算力优势非常明显，因此计算矩阵乘过程中，可以把一次性把大量数据搬到它的整个 MAC 阵列中一次计算完，所以它的矩阵乘的复用系数是远大于 4 的。

这里用一张表来综合对比 CPU 和 NPU 的参数区别。首先以天机 9400 CPU 为例，它只有 32 个向量寄存器，每个只有 128bit 位宽，总体来说它的 INT8 算力，我们把超大核和大核全部加起来也就 2Tops 左右。

NPU 配备大规模矩阵运算单元，它的总算力早已超过了几十 Tops，所以在矩阵乘任务上， NPU 对比 CPU 是有绝对性能优势的。再加上 NPU 本身制程设计带来的低功耗优势，所以在整个 prefill 过程中，CPU 是没法同 NPU 比的。

那么 decode 阶段又如何？前文提到 decode 阶段做的是矩阵向量乘法，它和矩阵乘的最大区别就是 A 矩阵是一维向量。我们再看一下计算过程， A0 和 A3 和 B0 和 B3 的这一列做运算得到 c0。大家发现算完 c0 之后，B0~B3 这一列是不是就不参与计算了所以整个计算过程中它只被复用一次，意味着 B 的复用系数是一，是没有办法复用的。

无论你是用 CPU 算还是 NPU 算，这个复用系数是无法优化的。基于这个特性，我们代入 3B 的算力和访存的数据估算一下。这里以计算量为 5Gops 和访存量为 1.5GB 来估算，最后算出来计算耗时大概在小于 5 毫秒的水平，访存耗时在 30 毫秒水平。

通过指令的流水优化，计算耗时是可以被访存耗时隐藏的，所以整个矩阵向量乘法的性能瓶颈在访存。于是我们就可以意识到一个问题，就是 NPU 对比 CPU 在 decode 任务上是没有明显性能优势的，但 NPU 对比 CPU 还是有着功耗的优势。

综上所述，虽然结论没有变化，因为 prefill 过程 NPU 对比 CPU 还是有着很明显的性能优势，所以我们最终还是得用 NPU 去推理。

但对计算任务的分析也让我们明白了，面对各种不同的计算任务时，它有着各自的优劣势，以及我们有对应的性能分析方法，我们要理解其背后的原理，这样对从业者来说还是非常重要的。

我们最终还是选择了 NPU 去部署大模型，但事情没有这么顺利，我们很快就遇到了最大的卡点，那就是 NPU 对动态 shape 的支持不好。

比如我们假设 NPU 固定了模型的输出水平是 1000，但实际大模型输入的 token 数是随机的，可能这一次是 1000 个 token，下次是 1001 个 token。结果这 1000 个 token 是可以正常跑的，1001 个 token 是跑不了的。可如果只能接受一种长度的输入的话，它肯定没法满足我们实际场景的需要。

NPU 的推理方案到底应该怎样设计才能满足我们所有动态输入的场景？基于以前视觉推理的经验，我们非常容易就想到，它既然不支持动态输入的话，我们就把输入切一下，把 prompt 切分成若干个等长的 patch 之后再送进去做推理。

我们本来还是觉得事情挺顺利的，但马上又遇到了第二个问题，那就是整个大模型的推理过程中，是否真的能按照这种切分 patch 的方式去做呢？也就是说我们把整个 prompt 切成多段去分别做 prefill，是否它整个计算过程在数学上同完整推理是等效的？

如果它这里不等效，这么切实际上是错的，大模型可能得不到正确的结果，所以我们必须要证明这个过程的正确性。

为此我们去梳理一下大模型的结构，发现 QKV 的矩阵运算以及后面 MRP 的 FC 运算都是矩阵乘法，对这一部分的运算，prompt 无论是拆分还是整合是没有影响的，因为它是具备空间独立性的。唯一需要关注的就是 attention 结构中的 batchmatmul 和 maskinf 的计算。

为了理清楚这个问题，我们把 batchmatmul 的推理，全量推理以及分段推理的结果进行了可视化输出，如上图所示。

这里举个例子，假设我们把 prompt 分为 4 个 patch 去推理，这 4 个 patch 的推理最终计算出来的部分就是如图所示的正方形矩阵的左下角部分。

看到这个图后，我们就马上意识到一个问题，我们只算了左下角，右上角没算会不会导致计算结果错误？

不是，因为大模型的整个弹性结构中，后面有个 maskinf 的计算。它存在的意义就是在于，因为大模型的每个 token 只能同前面的 token 产生 attention 的分布，所以它要通过 mask 矩阵的运算，把右上三角的这个部分给屏蔽掉。

我们后来发现屏蔽掉的上三角部分正好是我们没有计算的部分，所以说整个分 patch 过程中带来的只计算局部数据的问题，它对最后大模型的推理过程是没有影响的。我们只计算下三角的部分，大模型最后的 prefill 计算还是正确的。

推导出这个之后，大模型的分 patch 推理的正确性就证明完毕，意味着大模型的分 patch 推理方案是成立的，可以放心往下走。这里顺着再说一句，因为这个 batchmatmul 可以只算左下角，所以如果是在做自研 CPU 推理方案，在优化 batchmatmul 算子时也可以采用这种方案，可以不用去计算整个正方形的矩阵结果，只计算左下角的部分，这样冗余的计算量会小很多，也能进一步优化性能。

然后我们在这个基础上设计了大模型的推理方案，就是把模型拆分成两个，一个叫 prefill 模型，一个叫 decode 模型。prefill 模型就只处理大模型的首词过程，而 decode 模型就只处理大模型的出词过程。

经过一系列实验，我们把 prefill 模型的 input shape 定为 128，这样综合测算下来它的效率是最高的。然后 decode 模型的 input shape 等于 1，这样它只用来处理 token 的连续出词过程。

接下来我们再把 prefill 模型和 decode 的模型做一次权重共享，这样的话它们的 DRAM 体积占用也能节省下来，并不会因为搭载了两个模型就出现两倍内存的占用。

在确定整个 NPU 的推理方案后，我们再总览一下我们大模型落端的部署链路。首先我们要对云端浮点模型进行轻量化处理，这里主要分为模型的量化、模型的转换以及 NPU 侧的编译过程。

过程结束后，我们就可以导出 NPU 的端侧模型，它是经过 INT4 量化的。拿到这个模型之后，我们就可以放到端侧部署执行，这里主要分为 NPU 模型的初始化，以及最后实际推理过程中的 prefill 和 decode 计算。

以上就是我们大模型端侧化的整体链路。基于之前的体积和内存、性能以及功耗的优化方案，我们来看看最终的优化效果如何。

可以看到 prefill 性能有了质的提升。在我们最新的蓝心 3B 以及天玑 9400 的 NPU 上，prefill 的性能达到了 1200 多 token 每秒，这也是得益于 NPU 的高算力，因为它计算大规模矩阵乘的效率非常高。

我们再来代入一下之前的场景，假设我们做文档总结，输入是 1000 个 token，如果我们有着 1200token 每秒的首词性能，它预测第一个词的耗时就在一秒内，这样用户体验也是比较好的。出词也是达到了 28 token 每秒，功耗成功控制在了一安以内。

前面我们讲述了大模型端侧化过程当中，针对内存、体积、性能、功耗的等等指标的一些优化方案，但我们本质还是围绕着大模型在端侧化部署的推理性能优化的角度去讨论，但实际在业务场景中，模型的推理只是其中一部分。

从业务场景全局视角来看还有很多问题没有解决，比如说实际的业务场景存在多种任务，有文本总结、文本润色以及决策类任务，单一模型是无法平衡所有场景效果的。

难不成我们要在手机里塞多个大模型吗？还有不同的场景对性能的要求都不一样，我们如何兼顾各个场景的最佳体验？

另外还有非常重要的问题，就是大模型的生产内容是如何保障安全合规，这些问题都需要我们解决。

首先针对多业务场景，我们最终决定采用 1+N 的 LoRA 架构，就是用基座模型搭配若干个 LoRA 小模型来支撑不同的业务场景，这样我们只需微调 LoRA 的权重就可以满足不同业务的需求。

而我们单一的 LoRA 模型的体积，最终也是控制在了小于 100M 的水平。这样只需管控手机中的 LoRA 模型的数量，就能将模型的体积占用限定在可控范围内，也能解决引入多个基座模型带来的体积激增问题。

大家可以看到我们 3B 模型的体积在 2GB，这就意味着在手机里内置多个基座模型是行不通的。

另一方面我们在工程架构上也做了一些设计，把不同的 LoRA 模型的切换耗时控制在了 100 毫秒左右，并且在整个切换过程中，基座模型的权重是可以藏在内存中的，也就是它可以不需要释放将近 2GB 的内存就可以实现 LoRA 的切换，很好保证了实际业务场景的性能。

此外我们针对不同的业务场景还设计了专属的优化方案。首先针对不同上下文长度的场景，我们设计了动态的 kv cache 方案。比如说我们在处理短文本任务时，可能处理的任务都是短句，它整个输入输出加起来可能也就不到 500 个 token。但我们在做文本总结场景时，它的文章因为非常长，很可能就会达到 1000 个 token 以上的长度。

那么针对这两种场景，我们就配备了不同的上下文模型。比如说针对小于 512 token 的场景，我们配备了 512 cache 的模型。在处理文本总结这种上下文长度达到 2k 的任务时，我们就切换到 2k cache 的模型。

根据 NPU 的推理特性，cache 长度越小，它的推理性能越高，我们实测 512 cache 长度模型的出词性能在 29 token 每秒，比 2k 长度还是要稍微好一些的。

也就是说我们在分别处理短句任务和长文本任务时会动态选择最合适的 cache 长度来实现性能的优化。未来我们还会支持更多配置，比如说 3k 到 4k，来应对上下文长度更高的一些场景，比如说多模态的一些场景。

另一种情况就是 prompt 重复的场景，其特点就是不同任务的 prompt 模板都是一样的，可能就是仅尾部的 token 存在区别。而当模板 token 数比较多的时候，如果我们每次推理都重复计算这个 prompt，整个计算就会显得比较冗余。

因此我们设计了一种 prompt 缓存机制，在推理之后就会将 prompt 模板部分的对应 cache 内容缓存下来。在下一次推理过程中，如果我们检测到它输入的 prompt 模板的部分 token 是一样的，就会跳过这部分计算，仅仅计算后面的非重复部分，这种策略在单一场景执行不同计算任务时就能起到性能优化的效果。

比如说当 prompt 模板为 300 个 token 时，每次推理的 prefill 耗时能节省 250 毫秒，优化也是非常显性的。

在业务实际上线过程中，我们还根据业务场景的特征为其配备了不同的性能策略。我们当前的用户场景分为两种，分别为流式上屏场景和决策场景。流式上屏场景顾名思义就是阅读类场景，用户触发功能后需要等待一段时间，屏幕去显示第一个词，后续再连续出词并上屏，比如说大家去同 GPT 对话会的过程就是这样。

阅读场景的体验指标只要满足人眼的阅读速度就可以了。因此我们在这个场景通过降低性能来进一步实现功耗优化，最终取得性能和功耗的完美平衡。我们将出词控制在了 16 token 每秒的水平，对比峰值性能虽然有所下降，但这个场景的功耗也降低了。

决策场景则是需要所有的词全部输出之后才能进行下一步处理，整个出词过程中不会同用户交互。最有代表性的场景就是 AI 自动化操作手机的场景，这种场景需要极致性能来满足快速响应需求，因此我们在该场景将大模型的推理性能推到极致。

这样根据不同场景的体验指标来设定对应的性能策略，就能在各个场景都能实现最佳体验。

最后就是安全合规的问题。我们针对大模型的安全合规设有专门的端侧审核模型，用户在实际使用端侧的过程中，针对用户的输入以及大模型的输出，我们均有审核模型进行判断，若是有不合规的内容，我们就会中途中断返回，从而保证整个过程当中内容的安全性。

我们在其他模态上也有了一些技术成果，比如说在视觉模态实现了端侧 AI 消除，单张图片的全链路处理耗时能控制在 6 秒内。在语音模态实现了超拟人音色，也就是所谓的 TTS，首次播放耗时在 300 毫秒以内，出词性能也满足了二倍速的标准，在 70 token 每秒左右。另外在视觉多模态的部分，我们实现了图文问答，单次回答的响应耗时能控制在两秒内。

我们从大模型的场景展开，再到技术指标以及场景的优化，最终这一切都是由我们 vivo AI 研究院的 AI 团队自研的 VCAP 计算加速平台作为支撑的。

针对大模型，我们对整个 VCAP 的工程架构进行了升级，在工具链以及运行时均针对大模型推理设计了专属的优化模块。比如说我们在推理时可以针对这个业务场景自由选择推理模式，它既可以是标准的推理模式，也可以是并行解码的加速模式。

另外我们还有动态 cache、prompt 缓存技术以及 LoRA 切换等特性。在硬件层面，我们支持调用 CPU 以及高通和联发科的 NPU 硬件能力。

章苏迟，vivo AI 研究院高性能计算工程师。于 vivo AI 研究院任职，主要从事 AI 高性能计算方向，负责 NN 网络在移动端的部署与性能优化，在 CPU、GPU、DSP 指令集优化和 AI 推理框架设计上有丰富经验，是 vivo 端计算解决方案 VCAP 的主力开发之一。当前正在负责 AI 大模型在移动端的部署与优化，解决大模型落端的性能和功耗问题，打造行业领先的端侧大模型能力。

首届 AICon 全球人工智能开发与应用大会（深圳站）将于 8 月 22-23 日正式举行！本次大会以 “探索 AI 应用边界” 为主题，聚焦 Agent、多模态、AI 产品设计等热门方向，围绕企业如何通过大模型降低成本、提升经营效率的实际应用案例，邀请来自头部企业、大厂以及明星创业公司的专家，带来一线的大模型实践经验和前沿洞察。一起探索 AI 应用的更多可能，发掘 AI 驱动业务增长的新路径！