大模型在陌陌的推理与应用

导读 本文将分享陌陌如何利用大模型技术革新其业务与研发流程。

主要内容包括以下几个部分：

1. AI 应用范式更新

2. 大模型高效推理

3. 大模型应用平台

4. 未来展望

5. 总结

6. Q&A

分享嘉宾｜陈玉祥 挚文集团 算法工程专家

编辑整理｜王文海

内容校对｜李瑶

出品社区｜DataFun

---

01

AI应用范式更新

首先来看一下大模型能帮助我们解决哪些问题。

如上图，若由人来观察，能轻易分辨出图中男性在女性的右边。然而程序要如何知晓？若采用传统的机器学习方案，通常会启用一个模型，首先识别男性的位置，接着识别女性的位置，随后编写代码对框选区域进行判断，进而判断框选图像的像素相对位置。而到了新一代的大模型就非常简便了，直接向大模型提问，就能够得到精准的答案。

传统的企业 AI 应用通常呈现如下模式：从需求开始，然后到模型、数据，再经过训练/微调，直至最终完成部署应用。传统情形下，企业内部往往借助 BERT 模型来处理 NLP 相关问题，利用 YOLO 模型解决 CV 类问题，其产出形式包括 logits、embedding 和对内容的打标等等。从业务类型来看，主要涵盖内容安全、内容理解、内容分类以及内容表征。

陌陌作为社交平台，面临的内容安全挑战颇为严峻，像涉黄、涉政以及广告诈骗等内容的识别任务艰巨。内容理解相对较为直观，鉴于陌陌存在内容推荐机制，无论是直播、Feed 流，还是社交关系推荐，都要求对内容进行深入且精准的刻画。内容分类并非独立的业务主线，其更多是服务于内容安全与内容理解这前两个业务领域，起到辅助与支撑的作用。而内容表征对应的是 embedding，在整个业务体系中占据着相当重要的地位，发挥着广泛且关键的作用。最常见的应用就是在推荐领域中的召回，这时就需要借助诸如 BERT、YOLO 或其它一些 NLP、CV 模型，将内容转化为向量，接着利用向量数据库来进行线上数据的召回。本质上就是运用向量去计算两个浮点数组的内积，然后计算距离，再进行倒排操作。这就是传统的 AI 应用。

大模型出现后，企业 AI 应用发生了哪些变化呢？最直观的感受就是 text in text out，整体流程其实依然和传统流程一致，不过模型从之前的 BERT、YOLO 替换成了 LLM。相应地，整个交互体系也由之前的 logits、embedding 和 label  转变成了纯 text。要是存在多模态数据的话，那就是多模态数据加上 prompt，这也等同于 text，而企业内部应用最终大概率输出的还是 text。并且，其服务的业务体系依旧是之前那些，并没有太大改变。

但实际上，真到使用的时候，就会发现并非那么简单。还是回到最初的问题，即便可以正确输出结果“男性在女性的右边”，可这样的结果在企业内是无法直接使用的，因为企业内部所有的应用交互，本质上都是基于程序和接口来进行的。然而大模型输出的只是一段文本，还要对这段文本进一步去理解之后才能运用起来。所以仍会回归到原有的体系中，借助大模型输出 logits、embedding 和 label。毕竟 logits、embedding、label 这套体系经过了多年的积累与沉淀，整个业务体系都是依据之前模型输出的这些内容构建而成的。

若要突破之前的体系框架，比如让大模型输出 hidden states，通过诸如三层 MLP 进行降维处理得到 256 维的 embedding，或是提取出某两个 token 的 logits 来计算出一些简单结果，像判断是与否这种分类情况，还有 structured output 等操作。在 AI 大模型出现之后，我们应充分发挥其能力，并非仅仅局限于兼容旧有业务体系，而是运用其新的能力构建全新的业务流程，以此快速解决线上业务所面临的各类问题。

在这整套流程最终上线之后，我们能够察觉到两个明显的趋势。

第一是更智能，这一特点尤为显著，我们近期快速上线了几十个基于开源大语言模型的应用，之所以能够如此快速且大量地上线这些应用，关键就在于它相较于之前的那些模型，在准确性方面确实有了很大的提升。

第二是更加通用。以往使用的很多模型，往往需要准备数据进行微调后才能投入使用。但新一代的开源模型，只需写提示词 prompt，就能获取结果，这使得效率得到了极大的提升。对于单个项目而言，完全可以直接选用合适的开源大模型拿来即用。

第三是具备统一的架构。不管如何进行模型选型，它们的架构都是基于 Transformer 的 Decoder Only 架构，开源模型也是如此，这样能够显著提升团队的研发效率。

此外，大模型还催生出了一些新兴应用。比如替代客服助手，大模型出现后，客服系统是最先被改造的系统。不过在陌陌内部，我们的客服系统相对没那么重要，所以这方面并没有着手去做相应改造。而在社交内容生成这块，由于陌陌本身就是社交平台，我们着实做了不少工作。还有代码和 DSL 生成，比如 GitHub Copilot。

02

大模型高效推理

接下来介绍我们是如何进行大模型推理的。一提到大模型推理，大家脑海里可能首先就会浮现出几个词，比如 PagedAttention、Flash Attention、Continuous Batching 等。PagedAttention 主要是为了解决 KV 缓存的管理问题，这和现在操作系统里的分页内存管理类似。对于 Flash Attention 是针对当下 Attention 的一种高性能算子实现。Continuous Batching 是一种连续批处理。正常来讲，搭建一个服务时，若请求逐个到来，往往就串行调用。要是想提升服务的吞吐效率，有两种常见办法：一是采用并行方式，比如多核并行、多进程或者多线程；二是采用批处理（batch）的方式，也就是组批，比如在连续批处理（continuous batching）出现之前，机器学习线上推理服务最常用的批处理手段叫动态批处理（dynamic batch）。而连续批处理（continuous batching）相比动态批处理（dynamic batch）少了等待环节，只要请求一来，就能直接进入大模型推理的整个流程当中。

除常见优化手段外，我们还做了进一步探索，有两个较有效的优化手段，一是基于 W8A8、FP8 的量化（int8 量化会影响模型性能，对性能要求严的场景不太适用）；另一个是基于内存的 Prefix Caching。

这里介绍一下量化的基本概念，简单讲就是把 float32 数转成 int8 数。转换分两步，先乘系数（因 float32 数可能超出 int8 范围），再取整、裁剪，把数限制在 -127 到 127 之间。反量化就是把整形量化值除以系数变回 float 数。

量化是有损失的，大模型出现后有很多量化算法，如 Smooth Quant 算法就是非常有效的一个算法，它综合考虑了模型效果损失和性能提升两方面。

在机器学习模型中，很多时候就是做矩阵乘法，它包含权重和激活值两部分。权重的分布通常比较均匀，坡度也很少；而激活值会有明显峰值，这些峰值对应的数一般叫离群值。以往的量化大多只对权重做量化，在进行矩阵乘法前，都得先转成比如 float32，最终矩阵乘法还是用 float32 去算。

而当激活值和权重都做了量化后（比如都量化为 int8），核心的优化点在于可以用 int8 去实现运算，理论上这样整体算力会比用 float32 时有很大提升。

具体实现时，有激活值矩阵和权重矩阵。按照前面说的方法，取两边范围进行缩小或扩大操作，通过相应公式算出每一层的系数（scale）向量，进而算出新的取值范围，最后再用公式算出新的系数。

这种量化方案在实现时，矩阵乘法可直接用 int8 进行，不用转成 int16 或 int32 来运算，能大幅提升算力，这也是英伟达 GPU 近年的演进方向。Weight Only Quant 计算密集型算子使用 FP16 算子实现本质上和 FP16 需要的算力是一致的，甚至更高。

Smooth Quant 的矩阵乘法基于 int8 进行，而之前仅权重量化的典型模式如 W4A16，要把权重从 int4 或 int8 转换后变为 FP16 算子，再进行 FP16 的矩阵乘法，这比纯 FP16 多了一步 dequant，理论上会有额外的算力损耗。我们的评测结果与之一致，W4A16 在低吞吐情况下有性能优势，而吞吐达到 10 级别 QPS 时就会成为负收益；但 int8 这种模式的收益是线性增长的。

上图是模型量化损失的情况。以 LLaMA2 70B 模型为例，采用 W8A8 模式且用 FP8 进行量化后，其 MMLU 指标下降幅度处于千分位级别，低于 1%；若采用 int8 模式，下降幅度为 2% 左右；而 int4，也就是 W4A16，下降幅度在 1% 左右。所以在线上应用量化时，目前我们只采用了 FP8 的量化方式，因为它对线上模型性能的影响是最小的。

下面介绍 Prefix Caching。它基于一个基本假设，那就是大模型接收到的请求绝大多数时候其前缀都是一样的，比如常见的 system prompt 部分，只是 user 或者后续拼接的内容有所不同。在这种情况下，这部分对应的 KV Cache 可以缓存在 PagedAttention 管理的显存中，新请求到来时，可以直接使用缓存中的前缀，而无需再次计算，这样能够大幅减少计算量。

但这样做的一大弊端是需要的显存多。另外，大规模 KV 缓存从全局内存转至共享内存乃至寄存器时，还会占用大量显存带宽。如此情形下，若显存带宽不够用，只能购置新显卡。显存大小，可以通过扩展到内存来解决。

这就是我们的基于显存和内存实现的 Prefix Caching 方案。该方案分为两个阶段：第一阶段，也就是 Prefill 阶段，会从内存中拷贝命中的 KV Cache；第二阶段，即 Decode 阶段，把新增的 KV Cache 从显存拷贝到内存当中。

依据哈希判断是否命中前缀的 token 序列。若 GPU 中未命中，先分配足量 GPU 显存，再去 GPU 的 KV Cache 里判断，还没命中就从内存找对应 KV Cache 拷贝至 GPU 显存，其间有个名为 CacheEngine 的核心模块，它负责申请 GPU 显存空间及内存与 GPU 间的拷贝工作。Decode 阶段，先从内存申请空间，空间不足按 LRU 策略淘汰旧缓存，有空间就分配物理块并把 GPU 显存内容拷贝到 CPU 上，但此时 GPU 中的相关内容暂不删除，等下次申请 GPU 显存时才会删除。如此，若新请求命中上次内容，可直接从 GPU 获取，减少拷贝损耗。

目前，CPU 内存和 GPU 显存之间是个大瓶颈，二者通过 PCIE 连接，其带宽远低于显存带宽。

我们做了综合优化评测，限定 P99 耗时在 1.5 秒内，因线上应用是 AI 聊天场景，对耗时有较高要求。在这一限制下，用 BF16 时，QPS 仅 1.8，TPS 为 44，当时用的是 Qwen2 7B 模型，显存算力等方面都存在瓶颈。采用 Smooth Quant 的 W8A8，基于 FP8 量化，吞吐提升了一倍。直接开启基于显存的 Prefix Caching，吞吐会有一定提升，这时显存成为瓶颈。再开启内存后，吞吐有大幅提升，而压力则转移到框架层，算力也达到了瓶颈。

03

大模型应用平台

在大模型应用方面，我们没有采用 RAG，而是纯粹运用了 workflow 这种模式。我们是直接与 C 端用户进行交互，所以对可控性有着更高的要求，而业务复杂度并不高，所以选择了 workflow 模式。

从实践情况来看，我们有一个创新应用，算法同学借助这个平台的 workflow，在一个月内就迭代了 40 个版本。如果这 40 个版本依靠工程师去开发，仅需求沟通恐怕就得花费半个月时间。所以，这种模式对效率提升效果是非常显著的，只要了解大模型且有想法就能快速将想法付诸实践。

我们基于开源做了一些功能定制，其中最核心的一点是增加了预填充功能。这一功能的来源是因为 claude 先支持了 prompt prefill 功能，而其它平台似乎较少见到。仅靠系统提示控制事务灵活性不足，若在聊天的 user assistant 后加上 assistant prompt，灵活性会显著提升。借此可把控聊天剧情走向，还能在想换聊天风格时直接提示，控制准确性高。此外，利用 prompt prefill 可突破大模型的诸多限制。还有 fallback 节点，在大模型调用异常时做兜底处理，这对线上应用极为关键。此外，还对文本转语音控制提供了支持，并且支持大模型响应格式如 JSON object、JSON schema 等。

我们实现了与公司内部技术体系的集成，比如打通了公司内部 RPC 框架 MOA，存储框架 MomoStore，以及即时通讯系统 Momo IM 消息，实现了全面的效率提升，使得公司内部各体系交互更加顺畅。

04

未来展望

未来规划主要包括以下几个方面。

首先，使用 C++ 重构推理框架。目前推理框架基于 vLLM，在增加了 Prefix Caching 并支持内存扩展后，整个框架的开销已经成为推理过程中的瓶颈。vLLM 通过 Python 实现，对象管理、框架调度都消耗大量 CPU，并且在多核性能利用方面表现欠佳，这也限制了整体效率的提升。

第二，扩展 KV Cache 空间。虽然当下已经采用内存进行了扩展，但仍然存在局限。例如，单机扩展到 2T 后就无法继续扩展了，划分到 8 张卡上空间仍不够用。所以考虑借助远程存储或者 SSD 存储来进一步扩展 KV Cache 的空间，以此满足后续使用需求。

在大模型应用方面，后续会着重增加对多模态支持的投入。目前大模型主要是以文本作为输入输出形式，之后会拓展到多模态，如图片、语音等形式，以及增加端到端的通话功能支持。

对于 RAG 和 memory 在 C 端的应用情况来看，C 端对 memory 功能的需求比较多，而对 RAG 的需求相对并不多。RAG 更偏向于 B 端应用场景，比如客服方面，但对陌陌而言客服体系建设并不是重点。我们在 C 端的相关需求更多是偏向利用传统的向量数据库，用于做推荐系统的召回工作，或者进行相似聚类等操作。

05

总结

大模型在解决公司内部复杂问题、提高推理效率及推动创新应用方面展现出巨大潜力，不仅简化了任务处理，还促进了业务增长和创新；可以通过优化技术，如量化和前缀缓存，来提升模型性能，降低延迟；结构化输出技术的应用也能显著提升业务效率；深化推理框架的优化，并探索多模态支持的可能性，持续强化大模型技术在推动企业内部研发效率和业务发展中的核心作用。

06

Q&A

Q1：结构化输出用到了什么技术？推荐哪些开源项目？

A1：推荐 vLLM，它在结构化输出方面表现出色，其内部集成了多个能实现结构化输出的项目。

Q2：拷贝开销怎么量化？

A2：拷贝开销可以通过一定方式计算出来的。通常显卡都会标明其显存带宽，比如，当一次请求的输入 prompt 包含 3000 个 token 时，由于每个 token 对应的 KV Cache 大小是已知的，所以可以算出这 3000 个 token 对应的 KV Cache 所占的空间大小，然后除以线程带宽，就能得出拷贝所耗费的时间。

Q3：性能优化基于的显卡是什么呢？

A3：我们是基于 L20 来开展相关工作的。从我们所做的评测情况来看，显存带宽对大模型推理性能有着近乎线性的影响。尤其是在 cache 使用量比较大的情况下，显存带宽越高，在同等算力的前提下，其效率提升比例基本上和显存带宽的倍数呈线性关系，简单做个除法就能大致知晓性能提升的比例。

Q4：提到的主流推荐是 DAG 加 DSL 是指召回工程实现吗？

A4：不是，整个推荐系统已做成 DAG 加 DSL 模式，包括策略如 filter 策略、boost 策略和 rerank 策略等。

Q5：用到的 W8A8 等都是 vLLM 框架自带的吗？

A5：对，都是自带的，研发重点在于把 Prefix Caching 从 GPU 扩展到内存，让内存也可用。

Q6：结构化输出的应用场景主要有哪些？能展开说说吗？

A6：常见的如打标，给 feed 流从不同维度打标，让大模型输出 JSON，指定 JSON 格式及各 key 描述，方便解析。

Q7：缓存命中率一般能达到多少？Prefix Caching 对 prefill 延迟提升有多大？

A7：命中率跟场景有关，聊天类场景下，显存加内存情况下，能达到 90%，非聊天类就看系统 prompt 占整个 prompt 的比例。

Q8：W8A8 在业务上掉点多吗？

A8：业务上掉点很少，我们做过输出内容语义分析，平均相似度在 97%，只有细微不同。

Q9：量化主要用的是哪种方式？是按 prefill 和 decode 场景划分吗？

A9：我们都是 Smooth Quant W8A8，prefill 和 decode 都会采用这种模式，也可只在 prefill 上用。

以上就是本次分享的内容，谢谢大家。