如果你正在部署或优化大语言模型推理服务，特别是面对千亿参数、超长上下文和复杂 MoE 架构时，是否感觉性能优化已经触及了硬件天花板？当业界都在追逐最新硬件时，腾讯混元 AI Infra 团队却给出了一个不同的答案：在相对“落后”的 Hopper 架构 GPU 上，通过全栈深度优化，依然能让 Hy3 Preview 这样的旗舰模型实现极致的推理性能。
这不仅仅是几个算子层面的“小修小补”，而是一场从算子、并行策略、缓存、调度到量化的系统性重构。本文将深入拆解腾讯混元 AI Infra 团队如何将 Hy3 Preview 模型的推理性能推向极限。无论你是 AI 推理引擎的开发者、大模型应用架构师，还是对高性能计算感兴趣的研究者，这篇文章都将为你揭示一套在硬件约束下实现性能突围的完整方法论和实战细节。
1. 这篇文章真正要解决的问题
大模型推理性能优化，远不止是“换张更好的显卡”那么简单。随着模型参数突破千亿、上下文长度迈向百万级别，推理效率已成为决定模型能否规模化落地的生死线。更大的模型、更长的序列、更复杂的混合专家架构，在带来能力跃升的同时，也对算力、显存和通信带宽提出了近乎苛刻的要求。
腾讯混元 Hy3 Preview 作为新一代旗舰模型，采用了 GQA + MoE 的混合架构，并原生支持 256K 超长上下文，专为 Agent、代码生成等复杂场景设计。然而，其主部署平台 NVIDIA Hopper 架构 GPU，在算力、显存和互联带宽上，相比业界更主流的 Blackwell 系列存在明显劣势。这意味着，团队必须在“硬件条件有限”这个硬约束下，将推理性能优化到极致，才能满足服务等级协议并实现成本最优。
因此，本文要解决的核心问题是：在硬件并非顶级、模型又极其复杂的情况下，如何通过系统性的全栈优化，实现大模型推理性能的质变？这不仅仅是某个单一技术的胜利，而是一套涵盖算子、并行、缓存、调度、量化的组合拳。对于开发者而言，理解这套优化思路，远比记住几个具体的加速比数字更有价值，因为它揭示了在面对类似性能瓶颈时，可以从哪些维度进行思考和突破。
2. 基础概念与核心原理
在深入技术细节前，我们需要明确几个关键概念，这有助于理解后续优化方案的设计动机。
Hy3 Preview 模型架构：它是腾讯混元系列的新一代大模型，核心特点是采用了GQA和MoE的混合架构。GQA 降低了注意力机制的内存开销，而 MoE 则通过稀疏激活（每次只激活部分专家网络）来扩展模型总参数规模，同时控制单次推理的计算量。这种架构在带来强大能力的同时，也引入了路由、专家负载均衡等新的计算和通信开销。
推理性能关键指标：
- TTFT：首 Token 延迟。指用户提交请求到收到模型第一个输出 Token 所需的时间，直接影响用户体验。Prefill 阶段（处理输入提示词）的性能对此指标至关重要。
- TPOP：每输出 Token 时间。指模型稳定生成阶段，产出每个 Token 的平均耗时，决定了服务的吞吐能力。
- 吞吐量：单位时间内模型能够处理的 Token 总数，是衡量服务成本效益的核心。
硬件背景：Hopper 架构的挑战：Hopper GPU 在本次优化中是作为“约束条件”出现的。相比 Blackwell，其算力相对较低，显存更紧凑，并且缺乏超节点高速互联能力。这意味着优化不能依赖“暴力堆硬件”，而必须精打细算，最大化每一份硬件资源的利用率。
优化的核心矛盾：大模型推理本质上是计算密集型、内存带宽密集型和通信密集型任务的混合体。优化目标就是在三者之间找到最佳平衡点，避免任何一方成为瓶颈。例如，过度追求计算并行可能带来巨大的通信开销；过度压缩显存可能引入精度损失或增加计算复杂度。
3. 性能优化的五大核心维度
混元 AI Infra 团队的优化工作可以归纳为五个相互关联的维度，它们共同构成了一个完整的性能优化体系。
3.1 算子优化：从通用到极致定制
算子是计算的基本单元。针对 Hy3 Preview 模型和 Hopper 硬件的特点，团队对关键算子进行了深度重写。
动态调度负载均衡的 Attention：传统静态的split-kv策略在 batch 内请求长度差异大时面临两难：为长序列设置大的拆分粒度会导致短序列的额外开销；为短序列设置小的拆分粒度又无法充分利用长序列的并行性。解决方案是动态调度：将所有请求按统一的 Tile 粒度拆分，然后通过贪心算法将 Tile 任务均匀分配到各个计算线程块上。每个 Attention Kernel 根据全局任务映射表领取工作，最终由 Combine Kernel 统一合并结果。这从源头解决了负载不均问题，在混合长度 batch 场景下实现了 1.59x ~ 1.76x 的加速。
双 BF16 重构 FP32 计算的 Router GEMM：在 MoE 路由等对数值精度敏感的模块，传统做法是 BF16 激活乘以 FP32 权重，但这在 Hopper 上效率低下。团队创新性地将 FP32 权重在离线阶段拆分为一个高位 BF16 张量和一个低位残差 BF16 张量。推理时，执行两次高效的 BF16 Tensor Core 矩阵乘，再进行一次线性组合来逼近 FP32 的精度。整个过程激活保持 BF16，无需类型转换，在保证精度的同时获得了相比 FP32 cuBLAS 实现 2.86x ~ 3.22x 的加速。
全算子流水线重构的 FusedMoE：MoE 层包含路由、门控、专家计算、聚合等多个阶段，传统实现需要多次启动 Kernel 和显存读写。团队将其重构为一个融合的流水线 Kernel：
- 路由与索引预处理在共享内存中完成，预分配专家输出空间。
- 直接通过路由索引读取输入，省去显式的 Gather 数据搬运。
- 取消 Warp 专业化，由同一组线程完成计算和访存，提升硬件利用率。
- 所有中间结果在寄存器或共享内存中流转，仅在最终聚合后写回显存。
- 通过 PDL 技术实现无气泡的流水线执行。 这套方案在 TP=8 场景下相比主流方案获得了 1.5x – 1.6x 的加速。
3.2 算子融合：将碎片化计算“打包”执行
当多个轻量级算子连续执行时，频繁的 Kernel 启动和显存读写会成为主要瓶颈。融合的核心思想是“一次加载，连续计算，一次写回”。
Fused Rope+Norm+[Hadamard]+Quant+Store KV：在 QKV 投影之后，通常需要依次进行旋转位置编码、层归一化、可选的哈达玛积、量化，最后写入 KV Cache。这些操作都是逐元素的，计算强度低，但访存频繁。将其融合为一个 Kernel 后，数据从显存加载到寄存器，在芯片上完成所有变换，最终只写回一次量化后的 KV Cache。这项优化带来了约 5 倍的加速。
Fused AllReduce+Norm+Add：在张量并行训练或推理中，经常需要在通信（AllReduce）后进行残差连接和层归一化。传统做法是三个独立的操作。团队将其融合为一个 NVLink 原生的原子操作：RMSNorm(AllReduce(x) + residual, weight)。针对不同场景提供了高吞吐和低延迟两个版本，最高实现了 1.68x 的加速。
采样融合算子：传统的采样后处理链包含十多个小 Kernel（温度缩放、Top-K、Top-P、Softmax 等），每个都要访问巨大的词表显存。融合方案将其压缩为 1-2 个 Kernel，实现全词表单次加载、GPU 内部完成惩罚计算、局部堆归并 Top-K 等优化，相比 vLLM 和 FlashInfer 的采样算子，性能提升分别达到 5.5x 和 2.5x。
Gemm+Comm 细粒度通算融合：在 Prefill 阶段的张量并行+序列并行场景中，计算和通信的串行执行效率低下。方案将 SM 资源划分为“计算 SM”和“通信 SM”。计算 SM 每完成一个 Tile 的计算，就通过信号量通知通信 SM 立即发起 Reduce-Scatter 操作，实现了 Tile 级别的计算-通信重叠。同时，在 Kernel 内部实现了 Load、MMA、Epilogue 三级流水，进一步隐藏后处理开销。在 (64k, 4096, 1024) 的矩阵形状下，端到端加速比达到 1.68x。
3.3 并行策略优化：让计算和通信更“聪明”
并行策略决定了计算和负载如何在多个设备上分布。错误的策略会导致严重的计算冗余或通信瓶颈。
Prefill 并行策略：TPSP：在 Hy3 Preview 上，纯张量并行会带来三重问题：Element-wise 算子在所有卡上重复计算；AllReduce 通信量巨大；MoE 的 Grouped GEMM 被切分得过窄，计算效率低。解决方案是引入序列并行，将序列维度也进行切分，并结合前述的通信-计算融合、通信量化等技术，系统性压缩 TTFT。在 32K 序列的 Prefill 场景下，TTFT 降低了 24.5%。
Decode 并行策略：DP+EP：Decode 阶段面临显存和算力的双重压力。单机显存被模型权重大量占用，留给 KV Cache 的空间有限，限制了并发数。同时，小 Batch 下的 MoE 计算是访存瓶颈。方案采用数据并行 + 专家并行的跨节点混合架构。通过专家并行将权重分布到多台机器，腾出单机显存用于 KV Cache，提升并发。同时，跨节点聚合 Batch Size，使 MoE 计算进入计算瓶颈区，最大化 Tensor Core 利用率。配合异步专家负载均衡等技术，端到端吞吐提升了 15.7% ~ 44.7%。
3.4 多级缓存与异步调度：榨干系统每一毫秒
多级缓存体系：长上下文场景下，重复的公共前缀计算是巨大的浪费。仅依赖 GPU 显存做 Prefix Cache 容量有限，且无法跨实例复用。团队构建了GPU → CPU → 分布式 KVStore三级缓存体系。新请求先查询缓存，命中则直接加载，跳过 Prefill；新生成的 KV Cache 会异步下沉到更廉价的 CPU 内存甚至外部存储中，供后续请求复用。这在不增加 GPU 显存占用的前提下，极大扩展了有效缓存容量，降低了重复计算。
MTP 与异步调度优化：传统异步调度假设每轮生成一个 Token，CPU 可以提前准备下一轮输入。但多层 MTP 会导致下一轮的序列长度动态变化，CPU 必须等待 GPU 验证结果才能准备数据，产生同步气泡。优化方案解除了 CPU 对真实长度的同步依赖：CPU 总是按最大可能长度准备数据；在下一轮 GPU 计算开始前，再用上一轮的真实结果进行修正。这使得 CPU 准备工作可以完全与 GPU 计算重叠，消除了 5~10ms 的 CPU 气泡，端到端性能提升 10%~20%。
3.5 量化与稀疏化：用精度换空间的智慧博弈
W4A8 量化：直接应用低比特量化会带来严重的精度损失。团队通过三级联调方案在 AngelSlim 框架中实现了精度无损的 W4A8 量化：
- GPTQ 权重重建：基于 Hessian 逆进行逐层误差补偿，减少 INT4 权重量化损失。
- 激活平滑与旋转变换：平滑激活值的离群点，并对 Attention 的 Q/K 进行在线哈达玛变换，将离群值打散，抑制量化误差。
- QAT 轻量化微调：在训练中模拟量化噪声，仅更新量化参数，让模型自适应。 最终在精度损失小于 1% 的情况下，实现了端到端吞吐 28%+ 的提升。
稀疏注意力：标准自注意力的复杂度随序列长度呈二次方增长，是长上下文 Prefill 的主要瓶颈。团队提出了Stem 稀疏注意力算法，核心是智能选择重要的 Key-Value 对进行计算。
- Token Position-Decay：基于因果注意力中头部 Token 影响更大的洞察，为序列头部的 Query 分配更多的预算，尾部则激进剪枝。
- Output-Aware Metric：不仅看注意力分数，还将 Value 向量的模长作为信息贡献度的度量，避免选择高注意力但低信息量的 Token。 结合高效的 HPC-BSA 算子，该方案仅用 25% 的计算预算，就在 128K 上下文上实现了接近稠密注意力的精度，并将 Prefill 延迟降低了 3.6 倍。
4. 优化成果与数据验证
任何优化都需要用数据说话。混元团队在严格的测试环境下验证了上述方案的综合效果：
- 测试环境：Hopper 架构 GPU，96GB 显存。
- 测试数据：5000 条真实数据，平均输入长度 68K，最大 192K；平均输出长度 0.9K，最大 64K；缓存理论命中率 80%。
- 性能约束：TPOP ≤ 50ms, TTFT ≤ 4s。
- 精度目标：W8A8C8（权重8bit，激活8bit，计算8bit）。
在这一系列苛刻条件下，通过五大维度的联合优化，Hy3 Preview 模型成功达到了所有性能目标。具体到各个子项，如前文所述，都取得了显著的加速比。这证明了一套系统性的、软硬件协同的优化方法，能够有效突破单一硬件瓶颈，释放大模型的推理潜力。
5. 对开发者的启示与最佳实践
从腾讯混元的这次深度优化中，我们可以提炼出对大模型推理优化具有普适性的最佳实践：
- ** profiling 驱动，定位真实瓶颈**：优化前必须进行详尽的性能剖析，分清是计算瓶颈、内存带宽瓶颈还是通信瓶颈。不同阶段（Prefill/Decode）、不同模型架构（Dense/MoE）、不同硬件下的瓶颈可能完全不同。
- 算子融合是性价比最高的优化之一：对于由多个轻量级、访存密集型算子组成的计算链，融合能极大减少 Kernel 启动和显存访问开销。应优先识别并融合模型中的这类模式。
- 并行策略需与模型架构和硬件匹配：没有放之四海而皆准的并行策略。TP、PP、DP、SP、EP 需要根据模型结构（如 MoE 的专家数）、硬件拓扑（NVLink、网络带宽）和请求特征（Batch Size、序列长度）进行精细设计和组合。
- 缓存设计应分层分级：利用 GPU 显存、CPU 内存、SSD/网络存储构建多级缓存体系，是应对长上下文、高并发成本的关键。缓存策略（淘汰、加载、一致性）需要精心设计。
- 量化与稀疏化需以精度为锚点：低比特量化和稀疏化是必然趋势，但必须配套精度恢复技术。GPTQ、SmoothQuant、AWQ 以及类似 OAM 的智能稀疏策略，是保证应用效果不下降的前提。
- 系统协同优化大于局部最优：单个算子的极致优化可能被低效的调度或通信所抵消。需要具备系统视角，从数据流、任务调度、内存管理、通信同步等多个层面进行协同设计。
6. 总结与展望
腾讯混元 AI Infra 对 Hy3 Preview 的优化实践，是一次在既定硬件条件下追求极致性能的典范。它清晰地展示了大模型推理优化不是一个单点问题，而是一个需要贯穿算子、编译、并行、调度、存储、通信等多个层次的系统工程。
对于大多数团队而言，可能无法进行如此深度的内核级定制开发，但其中的优化思想是相通的：识别瓶颈、减少冗余、重叠计算、高效复用。无论是选择 vLLM、TGI 等开源推理引擎，还是基于 PyTorch 自研服务，都可以从这些维度审视自己的系统。
展望未来，随着模型规模的进一步扩大和交互式应用对低延迟要求的不断提高，推理优化将继续向更极致的软硬件协同方向发展，例如更激进的量化方案、更高效的投机解码算法、跨集群的全局调度与缓存等。理解本次优化中涉及的技术点，将为应对下一阶段的性能挑战打下坚实的基础。建议收藏本文，作为大模型推理性能优化的一份系统性参考指南。
