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

[db:作者]

演讲嘉宾 | 章苏迟
编辑 | 李忠良
策划 | AICon 全球野生智能开辟与利用大会
近年来，行业内不竭出现各类十亿，百亿，千亿级此外大模子，在各个范畴均展现了强大的才能。而智妙手机作为具有最大用户数目的终端装备，正成为大模子实现本性化场景与办事的焦点载体。但是想在移动端有限的硬件资本上摆设参数目庞大的大模子，其性能，内存，功耗均面临着严重的应战。
在 AICon2025 上海站上，来自 vivo AI 研讨院的高性能计较工程师章苏迟颁发了题为《vivo 蓝心大模子端侧轻量化摆设的创新途径》的演讲，从 vivo 已上线的营业场景动身，深度分解大模子落端进程中的焦点瓶颈题目及其对应的处理计划，包括模子参数范围挑选，性能 / 内存 / 功耗技术目标的优化等多个方面。AI 大模子重塑手机智能化体验
我是来自 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 驱动营业增加的新途径！