大模型在今年的落地，除了对用 AI 对已有业务进行改造和提效外，算力和推理的优化，可能是另外一项重要的实践了。这在腾讯的两个完全不同的业务上有着明显的体现。

推理成本是当下大模型落地面临的难题之一，整个 AI 行业都在探索如何高效利用计算资源，并行处理更多的推理请求。国内的云厂商也都在针对现有的推理构架做优化，甚至推出新的异构算力的解决方案。腾讯此前推出了大模型推理加速引擎 Taco-LLM，表现全面优于 vLLM 框架，吞吐性能相比前者及 TensorRT-LLM 提升 1-3 倍不等。

而腾讯乐享，作为腾讯内部孵化并使用了十余年的知识管理、学习培训和文化构建平台，开始利用 AI 对知识管理进行了深度改造，提效的同时也提高了知识的曝光、使用和迭代，AI 的加成甚至让企业知识管理这个赛道从小众成为了「热门」。

在 4 月 2 日的 Workshop 上，我们邀请到了腾讯大模型相关业务的人员，来分享大模型在腾讯业务上的探索与实践。本文整理自 Workshop 视频，略有增删。

分享嘉宾：

• 叶帆 腾讯云异构 AI 研发副总监
• 沈林玲 腾讯乐享产品资深架构师
• 李想 腾讯云互联网行业架构副总监

01

大模型倍速推理引擎 TACO-LLM 的设计与实践

分享嘉宾：腾讯云异构 AI 研发副总监  叶帆

TACO-LLM 是基于腾讯云异构计算产品推出的一款大语言模型推理加速引擎，用于提高语言模型的推理效能。在大语言模型的整个和用户的交互过程中，推理引擎是 AI 的核心引擎，负责接收用户的请求，并且将其进行处理和回应。

整个架构大概是这个样子：包括客户端、Request Pool 和 Server。Server 对应腾讯云上的云端实例, 或者是用户本地的集群节点。我们会有不同的推理服务实例。推理服务会按照既定的 API 为用户请求提供服务, 同时处理多个请求序列，然后将结果返回给用户。

推理引擎协调整个过程，负责计算及其优化和调度，以及多 GPU 的协同处理。模型以权重的形式部署在推理引擎中的 GPU 显存里, 我们常听到的如 LLAMA、国产的 chatGLM 等模型就属于这种情况。GPU 是最底层最重要的计算设备, 当然也可以使用其他加速硬件。

TACO-LLM 的主要亮点

1. 支持 OpenAI 的api输出格式。

TACO-LLM 无缝支持 OpenAI API。同时，TACO-LLM 也支持流式请求。用户可以直接通过 curl 来访问服务，就如同 ChatGPT 一样。

以下是流式输出的优点：

• 一致性：标准化的输出格式确保返回数据结构的一致性，使得输出结果更加通用
• 实时性：在文本生成过程中实时获取输出结果，无需等待完整的响应返回。
• 减少资源占用：流式输出只返回部分响应数据，减少网络传输和资源占用。

2. 支持分布式推理方案：Pipeline Parallel（流水线并行）、Tensor Parallel（张量并行）

Pipeline Parallel

• TACO-LLM 将大模型推理过程分为若干 stages, 支持高效异步执行，从而减少 GPU 空闲时间，最大化 GPU 使用效率。

Tensor Parallel

• 将一个变量分散到多个设备并共同完成某个或多个计算操作。
• 可以将 Multi-Head-Attention 的 head 切分到不同设备上计算，或者是将 MLP 的 weight 切分后使用 reduce 合并。

3. 支持 Continuous Batching（连续批处理）

在传统的批处理（如 Static Batching）中，数据会被分成大小固定的批次进行处理。每个批次内的数据会被同时送入模型进行推理，然后等待整个批次处理完成后再输出结果。基本是「同进同出」，这种方式不适合不同请求计算量不同的情况。因为短的请求需要等长的请求结束后才能一起返回。这期间模型和计算资源处于空闲状态。对于大模型的场景其实就有一些不合适，因为每个用户的请求可能都是有不一样的长短，会造成 GPU 的空泡。

Continuous Batching 技术则解决了这个问题，它允许模型在处理完当前迭代后，如果有结束的请求，则立即返回该请求。而不需要等待整个批次的请求都计算完成。这样，模型可以持续不断地工作，减少了空闲时间，提高了硬件资源的利用率。

也就是，以 token iteration 作为粒度, 可以非常灵活地对不同请求进行 batching。如果一个请求已经结束, 就可以调度另一个请求进来, 让它直接插入当前的 batch 中一同计算。这样就不会有任何空载, 可以最大程度利用 GPU 资源。

4. 支持 Paged Attention

Paged Attention 技术是一种内存管理优化方法，它在处理大型数据序列时，能够显著提高效率和性能。这项技术借鉴了计算机操作系统中虚拟内存管理的分页概念，将其应用于深度学习模型中的注意力机制。

在深度学习模型，尤其是自然语言处理（NLP）模型中，注意力机制是核心组件之一，它允许模型在处理输入数据时，对不同部分的信息赋予不同的重要性。然而，当处理长序列数据时，传统的注意力机制可能会消耗大量内存，因为它需要存储和处理所有序列中元素之间的关系。

原始方案的缺点

• Reserved fragmentation：预先保留的一部分内存空间，通常不会被使用，导致内存浪费。
• Internal fragmentation：需要根据 request 的最大长度来提前分配内存，导致浪费。
• External fragmentation:：内存空间碎片化导致无法满足连续内存分配需求，从而导致浪费。

Paged Attention

• 引入操作系统的虚拟内存中分页的思想，更加高效管理 KV cache。
• 将每个序列的 KV cache 划分为块，每个块包含固定数量 KV 对。
• 序列的连续逻辑块通过块表映射到非连续的物理块。随着新 tokens 的生成，物理块会按需分配。

5. 支持 Quantization（模型量化）

将模型的权重从 32 位浮点数（FP32）转换为 8 位整数（INT8/FP8），减少了存储需求和计算速度的提升。

低精度量化有几个显而易见的好处：

• 更少的存储开销和带宽需求，低精度成倍减少显存需求。
• 更快的计算速度，有对应的低精度 tensorcore 指令加速。
• 对模型性能影响有限，TACO-LLM 自研的量化算法最大限度保证模型性能和量化前保持一致。

TACO-LLM 如何解决大模型推理瓶颈?

目前的 Decoder 结构的大模型，实际上是采用 auto-regressive decoding process 的推理过程，是一个串行的推理过程。比如给大模型输入 my，那它会输出 name，那这个时候需要把 my name 一起输进去，然后它输出一个 is，如此循环往复。

一个 10B 的模型，如果以 FP16 精度来存储数据，会产生 20GB 的 IO，计算量大概是 20B FLOP。对于 A100 的高端显卡来说，显存带宽是 2039GB/s，FP16 的算力是 312TFLOPS，也就是说 IO 耗时是 10ms，计算耗时 0.07ms，性能基本是被限制在显存带宽上了。

业界对此有不少方案，比如降低 model size 或者减少解码步数，甚至重新设计模型的结构，但这些方案或多或少都会有一些问题。

Lookahead Decoding 是一种用于提高大语言模型（LLM）推理效率的技术。在自然语言处理中，语言模型通常需要生成文本序列，这个过程可以通过逐步生成每个 token（词或字符）来完成。传统的自回归模型（如 GPT 系列）在生成文本时，每次只生成一个 token，然后再基于已生成的序列继续生成下一个 token。这种方式虽然能够生成连贯的文本，但是效率较低，因为每个 token 的生成都需要等待前一个 token 完成。

Lookahead Decoding 技术的目的是提高这种生成过程的速度。它的核心思想是，每一次迭代不满足于只生成一个 token，而是在给出多个 token 候选的基础上，由目标模型来判定 token 的候选是否正确从而一次生成多个 token。

我们采用叫 Speculative Sampling 的预测解码的方式。用一个 draft model 来生成候选 token，然后用真正要想部署的目标大模型来验证这个生成的 token 是不是对的。那在传统的这个预测解码的方案里面，需要 draft model 具备「既快且好」的特点，但是实际上这样的 draft model 是很难获取的。

业界也有不同的类似 MedusaLLM（美杜莎）的多 token 方案，采用额外的 head 来辅助生成，但是训练需要大量资源，成本较高。而且在很多私有化场景部署中，用户的数据也是私有的，不愿意进一步开发。

基于此腾讯自研了一套高效的优化方案，Training-Free，而且开箱即用，用户无感。

优化方案设计思路

• 面向通用性设计
• 提高性能的关键在于充分挖掘 GPU 冗余算力（bottleneck 在访存上）
• 途径是前向计算产生多个 token，在序列维增加并行度
• LLM 模型由 decoding process 转变为 validation process(并行），validate 提前获取的 decoding candidate tokens
• 通过 Lookahead Cache 来获取 decoding candidates

整体方案分为两大部分

1.基于批处理的 Lookahead Cache：

• 一次预测批量请求；
• 根据 batch-size 和各个请求的命中率，对 copy_len 自适应惩罚；
• 基于森林的多分支预测方法；

有点类似于项目数据库的思想，但是更加轻量。基于这样的 insight：当前生成的内容很有可能在之前的问题或者已经生成的内容中出现过，如果当前生成的内容的前序可以匹配的话，更有可能输出历史上出现过的一致的短语。

对于像内容摘要、总结评论、代码生成等垂直领域，天然具备这样的特性。具体来说，会在一个 batch 内对每个序列维护自己的一个 local cache，共享全局一个 global cache。推理的时候会根据 match 的长度来查询缓存，然后通过预设的 copy 的程度来给出预测，每次迭代会根据当前序列预测的命中率来自适应调整中间的超参。

分词上我们相比原始的线性分词，采用了森林分词法。

多分支有多种结果候选，提⾼迭代命中率；

• 树结构多样可以结合词法，语法，将对应的 pattern 做动态的更新拟合；
• 每⼀个请求按照各种树结构的权重采样，最终通过命中情况，来调整各种树结构的概率。
• 可以通过简易地随机森林来⾃学习这个过程，甚⾄可以在线学习（在 CPU 上进⾏）；

• 基于 Paged Attention；
• 借鉴融合 FlashAttention，节省显存同时解耦片上资源；
• Lookahead 将向量和矩阵运算，转化为矩阵和矩阵的运算，有效 leverage GPU tensor-core 加速；
• 在 Head 维使用 Double Buffer，实现访存与计算 overlap，同时将片上资源与 head-size 大小解耦。

优化策略总结

1. 提⾼Lookahead Cache 命中率，减少⽆效计算

• 通过森林分词，有效提高 decoding candidate tokens 的命中长度，从而减少无效计算。
• 通过 Tree Attention，合并相同前序 candidate tokens 的计算，减少重复计算。
• 自适应 candidate tokens 长度，各序列按自身情况灵活调整（命中率、并发度、自适应惩罚），避免过载 GPU 冗余算力。

2. 提⾼算⼒天花板

• 序列维增加的并行度可有效 leverage tensorcore，提高理论算力上限，并使得性能下限和单 token 解码持平。
• 将片上资源使用（SRAM、registers, etc.）和序列长度解耦，有效提升长序列性能。
• 通过双 buffer 设计提高 ILP，有效隐藏 IO 开销。

TACO-LLM 性能效果

1. Duoble buffer 加速效果

在各种 size 下，使用 head 维 double buffer 技术，耗时明显减少，最大加速 1.77x。

2. 加速上限分析

• 大多投机采样的加速方法，只在低并发（batch-size=1）时，才有加速效果。
• TACO-LLM 的方案，一直到 batch-size=128 时，都保持较高的加速潜力。以 batch-size=128 的加速上限为 5.12x 为例，假设 lookahead=7 时，平均只命中了 3.5 个 token，那么将有 2.88x 的加速。

3. 端到端性能

同 batch size 下，TACO-LLM 全面优于 vllm。

• chatglm2-6b-32k，相比 vllm 最大提升 3.17x，相比 NVIDIA TensorRT-LLM 最大提升 1.77x
• baichuan2-13b，相比 vllm 最大提升 1.44x，相比 NVIDIA TensorRT-LLM 最大提升 3.0x
• codellama-13b，相比 vllm 最大提升 2.47x，相比 NVIDIA TensorRT-LLM 最大提升 3.71x

NVIDIA TensorRT-LLM 在长序列场景下存在一些限制。例如：

• NVIDIA TensorRT-LLM 在长序列场景下 tensor 数目限制了 batchsize 的大小
• NVIDIA TensorRT-LLM 在输入 tokens 小于 2k 时，由于显存的限制，最大的 batchsize 只能到 32
• 在 codellama-13b 场景下，NVIDIA TensorRT-LLM 只有在 batchsize=1 时才有性能优势。

02

腾讯乐享基于AI大模型的应用与实践

分享嘉宾：腾讯乐享 资深产品架构师 沈林玲

腾讯乐享：智能化组织学习协作平台

腾讯乐享 2008 年在腾讯内部诞生，经过 15 年的发展，目前已经是腾讯核心的知识学习和沟通平台。95% 的员工每天主动访问，腾讯宝库 80% 的原创知识都在乐享，以及超过 150 万篇的内部沉淀文章。

2017 年产品正式对外开放，目前为止注册企业数超过 30 万，超过 100 个细分行业在使用。

乐享主要解决三个核心场景的问题：知识管理、学习培训和文化建设。

AI 场景落地探索

目前主要围绕四个环节落地探索：

1. 智能写作

核心目的是降低员工在企业内部的创作门槛，高效完成内容的修缮和规范。

从员工层面，日常的培训工作、内容营销等，需要投入大量的精力去创作、审核。而对于平台运营者来说，企业内部的知识，因为创作成本高，生产和更新频率降低，让平台最终从「低质量」走向「不可用」。乐享核心就是先解决员工的创作成本，有具体的指令可以对文档进行总结和扩写、以及语言的专业化处理等。

2. 智能生成

内容生成主要是切入以下内容领域：课程制作、生成音频文章和课程、生成知识点、生成考题、以及更多内容生成能力。

员工可以直接导入文本，让 AI 根据内容出题，还能进行多模态的内容的搜索，帮助员工直达他需要了解的知识内容，从而盘活内容知识平台。

对于一些长文档，也可以利用 AI 生成摘要，帮助员工快速去了解相关的信息，提高信息获取效率。

3. 智能问答

解决的是平台内容利用率低的痛点。传统的检索获取信息的链路冗长，且每一步都可能存在信息衰减和失真，平台内容没法实时有效地迭代，最终从「低质量」走向「不可用」。

而乐享将大模型能力和企业内部知识整合到一起，无需训练模型即可快速搭建企业问答专家。可理解企业知识后直接以自然语言直接回复成员问题，缩短信息获取链路，提高内容曝光。

在课程问答上，AI 助手可以实时解答学员的提问，降低学员的提问门槛，同时也解放了讲师资源，让讲师可以专注于课程内容的打磨。

4. 智能学习

主要是还原员工的知识学习场景，打破时空限制。比如用 AI 代替讲师，尤其是一些培训场景比较多的企业，可以自定义数字形象，实现 AI 陪练，并且将员工的学习、练习、考试以及调研等有机集合在一起。并且可以实现 AI 打分，记录在案随时进行复盘。

03

Workshop 交流：为什么大模型落地这么难

Q：腾讯在知识管理+大模型领域有什么新思考？大模型对此有什么赋能？

沈林玲：知识管理以前是一个比较小众和专业的领域，很多企业内部都会做一些简单的知识管理，比如网盘的文档分享等，但在知识的生命周期管理上相对弱一些。

有了大模型之后，这个赛道越来越火。很多知识密集型的企业，会有意识地用 AI 进行知识管理的提效。甚至于有些团队，本来之前没有做知识管理，但是现在有了 AI 的辅助，可以一步跨越原有的知识管理体系，客户也都有预算进行成本投入，核心是看乐享能够提供的价值，和最终解决了哪些问题。

乐享作为专业的知识管理 SaaS 应用，在知识管理每个环节会基于大模型进行提效以及体验升级。比如说知识问答这一块，我们就收到了很多不同行业的客户的需求，互联网、零售、工业能源、金融、出行等，都对这块有强需求。

Q：看到之前举例 A10 * 16 部署 72B，目前腾讯云部署 100B 以内的模型主流是用什么卡？

叶帆：我们部署尺寸大的模型，有几个原则：

第一，能不跨机，尽量不要跨机。跨机会涉及到相对较慢的节点间通信，当对模型做TP切分时，性能衰减会很厉害。所以会建议客户尽量把大模型部署在显存大的卡上。此外我们会有一些软件方面的技术，对模型做量化，模型的尺寸会减少，更容易满足当下显卡的实际需求。

30B 以上的模型，建议直接部署在 L20 显卡上，目前腾讯云还是会持续提供异构的显卡系列，除了目前的 L20 系列，后续也会上 hopper 架构的新显卡，满足不同用户的需求。

Q：谈一谈大模型商业化的难题，我们看到很多人在聊大模型应用，为什么到头来落地和商业化看上去都不是很理想，能否说明原因？

李想：看一个应用场景能不能落地，主要看两个方面，一个是应用场景所需要投入的人力物力，包括开发的工作量，以及是要为场景开发新的模型，还是基于已有的模型做微调，这是一个很重要的考核指标。

另外要看这个场景对准确率的要求高不高，有些场景对输出结果的准确率要求没那么高，相对落地就容易些。

如果说一个场景需要的人力投入少，对准确性要求又没有那么高，商业化落地是比较容易的。比如说乐享的场景里提到的制作课程、考题等，对内容的生成准确率要求没有那么高，就会容易些。但是像 SaaS 领域，财税报销、税控和电子签约等，大模型现在的幻觉问题不可控，有数字错误都会引发严重的后果，这个落地就相对困难一些。

Q：目前大模型有哪些典型的实际落地场景？

李想：智能客服应该是大语言模型出来后落地最快的一个场景，传统的智能客服主要依赖于规则设置和匹配来实现客户服务，而结合了大语言模型和向量数据库的技术，可以显著提升对上下文的理解能力和回答的精确度。

通过将专业知识整合到向量数据库中，大语言模型能够提炼出问题的本质，并将其向量化，以便在向量数据库中检索相关信息。这种方法不仅能够更准确地回答客户的问题，还能够将专业知识有效地融入到问答过程中。

与传统的智能客服相比，这种结合了大型语言模型和向量数据库的技术在效果上有了显著的提升。它不仅能够更好地理解客户的需求，还能够提供更为精准和个性化的服务。因此，这种技术的应用前景十分广阔，有望在未来的客户服务领域发挥更大的作用。

第二个场景，就是数据类服务商。

在当前的数据处理和分析领域，团队也服务了比较多的 SaaS 应用服务商。其中，数据服务提供商扮演着重要的角色，他们为客户提供专利检索、法律信息检索和企业信息检索等服务。这些客户通常已经拥有自己的数据资源，但在过去，他们主要依赖于传统的查询和搜索技术，如基于 ES（Elasticsearch）等底层组件，来进行数据的检索和分析。

然而，随着开源模型的兴起，这些数据服务提供商开始基于开源模型进行微调（SFT），以更好地适应自己的数据和需求。通过这种方式，他们能够提供更加精准的数据检索服务，满足客户对于数据服务的更高要求。

此外，数据分析领域，尤其是 BI（商业智能）领域，也呈现出火热的发展态势。在这个领域中，虽然存在一些开源工具，如 Text2SQL 等，但其效果并不总是令人满意。因此，对于企业来说，要想在这个领域取得突破，就需要投入更多的人力资源和技术力量。

以腾讯为例，其在内部进行 BI 分析时，会基于自己的数据资源和常用的私有 SQL 数据进行大量的微调。通过这种方式，腾讯能够在其大型模型上实现更加精准和高效的数据分析，从而提升整体的服务质量和效率。

总的来说，无论是数据服务提供商还是数据分析领域的企业，都需要不断地投入人力和技术资源，以适应不断变化的市场需求和提高服务质量。通过精准的微调和优化，他们能够更好地理解和处理数据，为客户提供更加优质的服务。

在细分应用场景中，我们可以看到一些领域直接利用大型语言模型的API来实现特定的功能，这样的做法相对简单，不需要进行复杂的微调和向量数据库的结合。例如，在内容生成领域，考题生成可以直接调用大模型的 API 来完成，这大大减少了人力和财力的投入。

此外，在人力资源（HR）领域，自动生成简历评估的工具也得到了广泛的应用。这些工具能够快速分析简历内容，并给出评估结果，从而提高 HR 部门的工作效率。同样，在会议和企业直播等场景中，会议总结的功能也得到了实现，帮助参与者快速把握会议要点，提高工作和沟通的效率。

这些应用场景的落地相对容易，因为它们直接利用了大型语言模型的能力，而无需进行过多的定制化开发。这样的做法不仅节省了成本，也加快了产品从概念到实际应用的转化速度。