大模型在陌陌的推理与应用技术实践探索

陌陌作为深耕社交领域多年的平台，业务场景繁多，内容安全与推荐系统均高度依赖人工智能。在大模型浪潮席卷而来时，他们如何将新技术切实落地到实际业务中？本文不空谈理论，直接拆解从推理优化到应用平台的全链路实践。核心内容涵盖四大板块：AI应用范式的迭代、大模型高效推理的实现路径、应用平台的搭建心得，以及未来演进方向。

01 AI应用范式更新

先看一个直观案例：大模型如何理解“男人在女人右边”这类空间关系？传统机器学习需要先跑一个模型检测男人位置，再跑另一个模型检测女人位置，最后写代码判断两个框的像素相对坐标。而大模型只需输入图片，直接提问，就能返回准确答案。效率差距一目了然。

传统企业AI的流程通常是：需求→模型→数据→训练/微调→部署。内部NLP任务用BERT，CV任务用YOLO，产出logits、embedding、标签，服务于内容安全、理解、分类和表征。作为社交平台，陌陌在内容安全方面面临巨大挑战——涉黄、涉政、广告反诈等都必须严密监控。内容理解相对直观，推荐系统（直播、Feed流、社交关系）需要精准的内容刻画。内容分类并非独立业务，更多是支撑安全和理解。而内容表征（embedding）在整个体系中应用广泛，最常见的是推荐召回：用BERT或YOLO将内容转为向量，再通过向量数据库进行内积、距离计算和倒排。这就是传统AI的典型玩法。

大模型出现后，企业AI应用最直观的变化就是“text in text out”。流程框架基本未变，只是模型从BERT、YOLO换成了LLM，交互体系从logits、embedding、label变成了纯文本。多模态数据加上prompt本质上也是文本，最终输出大概率还是文本。服务的业务体系依旧如故。

但实际运用中没那么简单。回到最初的问题，即使大模型输出“男性在女性的右侧”，这种文本在企业内部无法直接使用——所有应用交互都基于程序和接口。大模型的文本输出仍需进一步理解才能被利用。因此最终还是要回归原有体系，借助大模型输出logits、embedding和label。毕竟这套体系已积累多年，整个业务都建立在其上。

要突破旧框架，可以让大模型输出hidden states，通过MLP降维得到256维的embedding，或提取某些token的logits做分类，或实现结构化输出。大模型问世后，不能只想着兼容旧业务，更要发挥其新能力构建新流程，快速解决线上问题。

整套流程上线后，能观察到两个显著趋势。第一是更智能：陌陌近期快速上线了几十个基于开源大模型的应用，之所以能如此高效，关键在于准确率比以往提升了一大截。第二是更通用：以前的模型常需准备数据微调，而现在的开源模型写个prompt就能直接出结果，效率极大提升。对于单个项目，直接选择合适的开源模型拿来就用。第三是统一架构：无论选用什么模型，底层都是Transformer Decoder Only架构，开源模型也不例外，团队研发效率显著提高。

大模型还催生了一批新应用。例如客服助手——但陌陌内部客服系统相对不那么重要，所以未做改造。社交内容生成方面，因为平台的社交属性，做了不少工作。还有代码和DSL生成，比如GitHub Copilot。

02 大模型高效推理

接下来看推理优化。一提到大模型推理，大家自然会想到PagedAttention、Flash Attention、Continuous Batching。PagedAttention解决了KV缓存的管理问题，类似于操作系统的分页内存管理。Flash Attention是高性能的Attention算子实现。Continuous Batching是一种连续批处理——常规服务搭建中，请求逐个到来可串行调用；要提升吞吐，要么并行（多核、多进程、多线程），要么批处理。Continuous Batching比动态批处理少了等待环节，请求一来就直接进入推理流程。

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

量化的基本概念很简单：将float32数转为int8。分两步：先乘以系数（因为float32可能超出int8范围），再取整、裁剪，限制在-127到127之间。反量化就是除以系数变回float。

量化会带来精度损失。大模型出现后涌现出许多量化算法，Smooth Quant是效果不错的一种，综合考虑了模型效果损失和性能提升。矩阵乘法包含权重和激活值两部分。权重的分布通常均匀，坡度小；而激活值则有明显峰值（离群值）。以前大多只量化权重，矩阵乘法前需转成float32计算。如果激活值和权重都量化成int8，就能直接用int8运算，整体算力比float32提升显著。

具体实现时，有激活值矩阵和权重矩阵。按方法取两边范围做缩放或扩宽，通过公式算出每层的系数向量，再算出新的取值范围，最后算出新系数。

在这种方案下，矩阵乘法直接使用int8，无需转int16或int32，算力大幅提升——这也是英伟达GPU近年来的演进方向。如果只量化权重（Weight Only Quant），计算密集型算子用FP16实现，本质上算力与FP16一致，甚至更高。

SmoothQuant的矩阵乘法基于int8，而之前那种W4A16模式，需将权重从int4或int8转成FP16再计算，比纯FP16多一步反量化，有额外损耗。评测结果一致：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从显存拷贝到内存。通过哈希判断前缀是否命中。若GPU未命中，先分配显存，再去GPU KV Cache判断，还没命中则从内存找对应KV Cache拷贝到GPU显存。核心模块CacheEngine负责申请GPU显存以及内存与GPU间的拷贝。Decode阶段，先从内存申请空间，空间不足按LRU淘汰，有空间就分配物理块，将GPU显存内容拷贝到CPU，但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个版本。如果依赖工程师开发，仅需求沟通就得半个月。这种模式对效率提升非常显著——只要懂大模型、有想法，就能快速落地。

基于开源做了功能定制，核心是增加预填充功能。这个灵感来自Claude的prompt prefill，其他平台很少见。仅靠系统提示控制事务灵活性不够，如果在聊天user assistant后面加assistant prompt，灵活性会大幅提升。可以掌控聊天剧情走向，想换风格直接提示，控制精准。还能突破大模型的很多限制。另外还加了fallback节点，当大模型调用异常时进行兜底，这对线上应用很关键。此外支持文本转语音控制，以及大模型响应格式（JSON object、JSON schema等）。

实现了与公司内部技术体系的集成：打通了RPC框架MOA、存储框架MomoStore、即时通讯系统Momo IM消息，全面提升了内部交互效率。

04 未来展望

未来规划主要有几个方向。

第一，用C++重构推理框架。目前基于vLLM，增加Prefix Caching并支持内存扩展后，框架开销成为瓶颈。vLLM采用Python实现，对象管理和调度消耗大量CPU，多核性能利用不佳，限制了整体效率。

第二，扩展KV Cache空间。虽然已经使用了内存扩展，但单机扩展到2T后无法继续，分到8张卡上空间仍不够。考虑借助远程存储或SSD进一步扩展。

在应用方面，后续会重点支持多模态。目前输入输出以文本为主，之后将拓展到图片、语音，以及端到端的通话功能。

至于RAG和memory在C端的应用，C端对memory需求较多，RAG需求不大。RAG更偏向B端客服场景，但陌陌客服不是重点。C端更多是用传统向量数据库做推荐召回、相似聚类等。

05 总结

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

06 Q&A

Q1：结构化输出用到了什么技术？推荐哪些开源项目？
A1：推荐vLLM，它在结构化输出方面表现出色，内部集成了多个相关项目。

Q2：拷贝开销怎么量化？
A2：可以计算。显卡标明了显存带宽，一次请求输入prompt有3000个token时，每个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，指定格式和各key描述，方便解析。

Q7：缓存命中率一般能达到多少？Prefix Caching对prefill延迟提升有多大？
A7：命中率看场景。聊天场景下，显存加内存能达到90%。非聊天场景看system prompt占整个prompt的比例。

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

Q9：量化主要用的是哪种方式？按prefill和decode场景划分吗？
A9：全是Smooth Quant W8A8，prefill和decode都用，也可以只在prefill上用。

以上就是本次分享的核心内容。

你是一名 AI 行业编辑，请围绕下面这条热点输出一份资讯解读：
热点：大模型在陌陌的推理与应用技术实践探索要求：
1. 先用一句话解释这条热点在讲什么
2. 再总结它为什么重要
3. 说明会影响哪些 AI 产品或内容方向
4. 最后给出 3 个适合资讯站使用的标题